Since 2.6.36-rc1, non-root users of vhost-net fail to attach
if they are in any cgroups.

The reason is that when qemu uses vhost, vhost wants to attach
its thread to all cgroups that qemu has.  But we got the API backwards,
so a non-priveledged process (Qemu) tried to control
the priveledged one (vhost), which fails.

Fix this by switching to the new cgroup_attach_task_all,
and running it from the vhost thread.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

This reverts commit de6be6c1.

After some discussion with Jarek Poplawski and Eric Dumazet, we've
decided that this change is incorrect.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

vortex_ioctl() was grabbing vortex_private::lock around its call to
generic_mii_ioctl().  This is no longer necessary since there are more
specific locks which the mdio_{read,write}() functions will obtain.
Worse, those functions do not save and restore IRQ flags when locking
the MII state, so interrupts will be enabled when generic_mii_ioctl()
returns.

Since there is currently no need for any function to call
mdio_{read,write}() while holding another spinlock, do not change them
to save and restore IRQ flags but remove the specification of ordering
between vortex_private::lock and vortex_private::mii_lock.
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There's something very important I forgot to tell you.
 What?

 Don't cross the GRO streams.
 Why?

 It would be bad.
 I'm fuzzy on the whole good/bad thing. What do you mean, "bad"?

 Try to imagine all the Internet as you know it stopping instantaneously
  and every bit in every packet swapping at the speed of light.
 Total packet reordering.
 Right. That's bad. Okay. All right. Important safety tip. Thanks, Hubert

The simplest way to stop this is just avoid doing GRO on the second port.
Very few Marvell boards support two ports per ring, and GRO is just
an optimization.
Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

mdiobus resources must be released on exit
Signed-off-by: NDenis Kirjanov <dkirjanov@kernel.org>
Acked-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Its currently illegal to call kthread_stop(NULL)
Reported-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Acked-by: NTejun Heo <tj@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The 5 GHz CTL indexes were not being read for all hardware
devices due to the masking out through the CTL_MODE_M mask
being one bit too short. Without this the calibrated regulatory
maximum values were not being picked up when devices operate
on 5 GHz in HT40 mode. The final output power used for Atheros
devices is the minimum between the calibrated CTL values and
what CRDA provides.

Cc: stable@kernel.org [2.6.27+]
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The EEPROM is compressed on AR9003, upon decompression
the wrong upper limit was being used for the block which
prevented the 5 GHz CTL indexes from being used, which are
stored towards the end of the EEPROM block. This fix allows
the actual intended regulatory limits to be used on AR9003
hardware.

Cc: stable@kernel.org [2.6.36+]
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Michael reported that p54* never really entered power
save mode, even tough it was enabled.

It turned out that upon a power save mode change the
firmware will set a special flag onto the last outgoing
frame tx status (which in this case is almost always the
designated PSM nullfunc frame). This flag confused the
driver; It erroneously reported transmission failures
to the stack, which then generated the next nullfunc.
and so on...

Cc: <stable@kernel.org>
Reported-by: NMichael Buesch <mb@bu3sch.de>
Tested-by: NMichael Buesch <mb@bu3sch.de>
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This avoids a NULL pointer dereference as reported here:

	https://bugzilla.redhat.com/show_bug.cgi?id=625889

When the WARN condition is hit in ieee80211_get_tx_rate, it will return
NULL.  So, we need to check the return value and avoid dereferencing it
in that case.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Cc: stable@kernel.org
Acked-by: NBob Copeland <me@bobcopeland.com>

pcnet_cs:
    add new_id: "KENTRONICS KEP-230" 10Base-T PCMCIA card.
Signed-off-by: NKen Kawasaki <ken_kawasaki@spring.nifty.jp>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The commit 886275ce (param: lock
if_sdio's lbs_helper_name and lbs_fw_name against sysfs changes)
introduced new fields into the if_sdio_card structure. It caused
missalignment of the if_sdio_card.buffer field and failure at driver
load time:

  ~# modprobe libertas_sdio
  [   62.315124] libertas_sdio: Libertas SDIO driver
  [   62.319976] libertas_sdio: Copyright Pierre Ossman
  [   63.020629] DMA misaligned error with device 48
  [   63.025207] mmci-omap-hs mmci-omap-hs.1: unexpected dma status 800
  [   66.005035] libertas: command 0x0003 timed out
  [   66.009826] libertas: Timeout submitting command 0x0003
  [   66.016296] libertas: PREP_CMD: command 0x0003 failed: -110

Adding explicit alignment attribute for the if_sdio_card.buffer field
fixes this problem.
Signed-off-by: NMike Rapoport <mike@compulab.co.il>
Acked-by: NMarek Vasut <marek.vasut@gmail.com>
Acked-by: NDan Williams <dcbw@redhat.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Qlge is freeing the buffers before stopping the card DMA, and
this can cause some severe error, as a EEH event on PPC.

This patch just stop the card and then free the resources.
Signed-off-by: NBreno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: NRon Mercer <ron.mercer@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Casting "pep->tx_desc_dma" to to a struct tx_desc pointer makes gcc
complain:

drivers/net/pxa168_eth.c:657: warning:
	cast to pointer from integer of different size
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The phy_mii_ioctl() function changed recently.  It now takes a struct
ifreq pointer directly.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

A couple issues here:
* Some resources weren't released.
* If alloc_etherdev() failed it would have caused a NULL dereference
  because "pep" would be null when we checked "if (pep->clk)".
* Also it's better to propagate the error codes from mdiobus_register()
  instead of just returning -ENOMEM.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

"pep->pd" isn't checked consistently in this function.  For example it's
dereferenced unconditionally on the next line after the end of the if
condition.  This function is only called from pxa168_eth_probe() and
pep->pd is always non-NULL so I removed the check.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It is possible that phylib will call adjust_link before returning
from {,of_}phy_connect(), which may cause the following [very rare,
though] oops upon reopening the device:

  Unable to handle kernel paging request for data at address 0x0000024c
  Oops: Kernel access of bad area, sig: 11 [#1]
  PREEMPT SMP NR_CPUS=2 LTT NESTING LEVEL : 0
  P1021 RDB
  Modules linked in:
  NIP: c0345dac LR: c0345dac CTR: c0345d84
  TASK = dffab6b0[30] 'events/0' THREAD: c0d24000 CPU: 0
  [...]
  NIP [c0345dac] adjust_link+0x28/0x19c
  LR [c0345dac] adjust_link+0x28/0x19c
  Call Trace:
  [c0d25f00] [000045e1] 0x45e1 (unreliable)
  [c0d25f30] [c036c158] phy_state_machine+0x3ac/0x554
  [...]

Here is why. Drivers store phydev in their private structures, e.g.
gianfar driver:

static int init_phy(struct net_device *dev)
{
	...
	priv->phydev = of_phy_connect(...);
	...
}

So that adjust_link could retrieve it back:

static void adjust_link(struct net_device *dev)
{
	...
	struct phy_device *phydev = priv->phydev;
	...
}

If the device has been opened before, then phydev->state is set to
PHY_HALTED (or undefined if the driver didn't call phy_stop()).

Now, phy_connect starts the PHY state machine before returning phydev to
the driver:

	phy_start_machine(phydev, NULL);

	if (phydev->irq > 0)
		phy_start_interrupts(phydev);

	return phydev;

The time between 'phy_start_machine()' and 'return phydev' is undefined.
The start machine routine delays execution for 1 second, which is enough
for most cases. But under heavy load, or if you're unlucky, it is quite
possible that PHY state machine will execute before phy_connect()
returns, and so adjust_link callback will try to dereference phydev,
which is not yet ready.

To fix the issue, simply initialize the PHY's state to PHY_READY during
phy_attach(). This will ensure that phylib won't call adjust_link before
phy_start().
Signed-off-by: NAnton Vorontsov <avorontsov@mvista.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Fix this error on an s390 allyesconfig build:

linux-2.6/drivers/net/caif/caif_spi.c:98:
    undefined reference to `dma_free_coherent'

Cc: Sjur Braendeland <sjur.brandeland@stericsson.com>
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If netconsole is in use, there is a possibility for deadlock in 3c59x between
boomerang_interrupt and boomerang_start_xmit.  Both routines take the vp->lock,
and if netconsole is in use, a pr_* call from the boomerang_interrupt routine
will result in the netconsole code attempting to trnasmit an skb, which can try
to take the same spin lock, resulting in deadlock.

The fix is pretty straightforward.  This patch allocats a bit in the 3c59x
private structure to indicate that its handling an interrupt.  If we get into
the transmit routine and that bit is set, we can be sure that we have recursed
and will deadlock if we continue, so instead we just return NETDEV_TX_BUSY, so
the stack requeues the skb to try again later.
Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Function qlcnic_intr has pointer to qlcnic_host_sds_ring
as second parameter not pointer to qlcnic_adapter.
Signed-off-by: NYinglin Luan <synmyth@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Function netxen_intr has pointer to nx_host_sds_ring
as second parameter not pointer to netxen_adapter.
Signed-off-by: NYinglin Luan <synmyth@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Why wouldn't kconfig symbol ISDN_DRV_AVMB1_B1PCMCIA also depend on
PCMCIA?

Fix build for PCMCIA not enabled:

ERROR: "b1_free_card" [drivers/isdn/hardware/avm/b1pcmcia.ko] undefined!
ERROR: "b1ctl_proc_fops" [drivers/isdn/hardware/avm/b1pcmcia.ko] undefined!
ERROR: "b1_reset_ctr" [drivers/isdn/hardware/avm/b1pcmcia.ko] undefined!
ERROR: "b1_load_firmware" [drivers/isdn/hardware/avm/b1pcmcia.ko] undefined!
ERROR: "b1_send_message" [drivers/isdn/hardware/avm/b1pcmcia.ko] undefined!
ERROR: "b1_release_appl" [drivers/isdn/hardware/avm/b1pcmcia.ko] undefined!
ERROR: "b1_register_appl" [drivers/isdn/hardware/avm/b1pcmcia.ko] undefined!
ERROR: "b1_getrevision" [drivers/isdn/hardware/avm/b1pcmcia.ko] undefined!
ERROR: "b1_detect" [drivers/isdn/hardware/avm/b1pcmcia.ko] undefined!
ERROR: "b1_interrupt" [drivers/isdn/hardware/avm/b1pcmcia.ko] undefined!
ERROR: "b1_alloc_card" [drivers/isdn/hardware/avm/b1pcmcia.ko] undefined!
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: Carsten Paeth <calle@calle.de>
Cc: Karsten Keil <isdn@linux-pingi.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

From: Bruce Allan <bruce.w.allan@intel.com>

The alternate MAC address feature is only supported by 80003ES2LAN and
82571 LOMs as well as a couple 82571 mezzanine cards.  Checking for an
alternate MAC address on other parts can fail leading to the driver not
able to load.  This patch limits the check for an alternate MAC address
to be done only for parts that support the feature.

This issue has been around since support for the feature was introduced
to the e1000e driver in 2.6.34.
Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
Reported-by: NFabio Varesano <fax8@users.sourceforge.net>
Cc: stable@kernel.org
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

On the e1000-devel mailing list, Nils Faerber reported latency issues with
the 82573 LOM on a ThinkPad X60.  It was found to be caused by ASPM L1;
disabling it resolves the latency.  The issue is present in kernels back
to 2.6.34 and possibly 2.6.33.
Reported-by: NNils Faerber <nils.faerber@kernelconcepts.de>
Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
Cc: stable@kernel.org
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Functions ll_temac_rx_irq and ll_temac_tx_irq
have pointer to net_device as second parameter not
pointer to temac_local.
Signed-off-by: NMichal Simek <monstr@monstr.eu>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Dont clear netdev->stats, it might give transient wrong values to
concurrent stat readers.
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Dont clear netdev->stats, it might give transient wrong values to
concurrent stat readers.
Signed-off-by: NEric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NAmit Kumar Salecha <amit.salecha@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Spin lock rds_ring->lock is used in poll routine, so other users should
use spin_lock_bh(). While posting rx buffers from netxen_nic_attach,
rds_ring->lock is not required, so cleaning it instead of fixing it by
spin_lock_bh().
Signed-off-by: NAmit Kumar Salecha <amit.salecha@qlogic.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This fixes the following opps which can occur when trying to deallocate
receive buffer pools when changing the MTU of an active ibmveth device.

Oops: Kernel access of bad area, sig: 11 [#1]
NIP: d000000004db00e8 LR: d000000004db00ac CTR: 0000000000591038
REGS: c00000007fff39d0 TRAP: 0300   Not tainted  (2.6.36-rc1)
MSR: 8000000000009032 <EE,ME,IR,DR>  CR: 22248244  XER: 00000002
DAR: 0000000000000488, DSISR: 0000000042000000
TASK = c00000007c463790[6531] 'netserver' THREAD: c00000007a154000 CPU: 0
GPR00: 0000000000000000 c00000007fff3c50 d000000004dbd360 0000000000000001
GPR04: 0000000000000001 1fffffffffffffff 000000000000043c c00000007a8e9f60
GPR08: c00000007a8e9e20 0000000000000245 0000000000000488 0000000000000000
GPR12: 00000000000000c0 c000000006d70000 c00000007bfec098 c00000007bfebc2c
GPR16: c00000007a157c78 0000000000000000 0000000000000001 0000000000000000
GPR20: 0000000000000001 0000000000000010 c000000000b51180 c00000007a8e9d90
GPR24: c00000007a8e9da0 c00000007a8e9580 00000000000005ea 00000000000002ff
GPR28: 0000000000000004 0000000000000080 c000000000a946f8 c00000007a8e9d80
NIP [d000000004db00e8] .ibmveth_remove_buffer_from_pool+0xe8/0x130 [ibmveth]
LR [d000000004db00ac] .ibmveth_remove_buffer_from_pool+0xac/0x130 [ibmveth]
Call Trace:
[c00000007fff3c50] [d000000004db00ac] .ibmveth_remove_buffer_from_pool+0xac/0x130 [ibmveth] (unreliable)
[c00000007fff3cf0] [d000000004db31dc] .ibmveth_poll+0x30c/0x460 [ibmveth]
[c00000007fff3dd0] [c00000000042c4b8] .net_rx_action+0x178/0x278
[c00000007fff3eb0] [c000000000093cf0] .__do_softirq+0x118/0x1f8
[c00000007fff3f90] [c00000000002ab3c] .call_do_softirq+0x14/0x24
[c00000007a157600] [c00000000000e3e4] .do_softirq+0xec/0x110
[c00000007a1576a0] [c000000000093394] .local_bh_enable_ip+0xb4/0xe0
[c00000007a157720] [c0000000004f0bac] ._raw_spin_unlock_bh+0x3c/0x50
[c00000007a157790] [c0000000004186e0] .release_sock+0x158/0x188
[c00000007a157840] [c000000000479660] .tcp_recvmsg+0x560/0x9b8
[c00000007a157970] [c0000000004a0d78] .inet_recvmsg+0x80/0xd8
[c00000007a157a00] [c000000000413e28] .sock_recvmsg+0x128/0x178
[c00000007a157bf0] [c0000000004164ac] .SyS_recvfrom+0xb4/0x148
[c00000007a157d70] [c000000000411f3c] .SyS_socketcall+0x274/0x360
[c00000007a157e30] [c0000000000085b4] syscall_exit+0x0/0x40
Reported-by: NRafael Camarda Silva Folco <rfolco@linux.vnet.ibm.com>
Signed-off-by: NRobert Jennings <rcj@linux.vnet.ibm.com>
Acked-by: NBrian King <brking@linux.vnet.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

ehea: Fix synchronization between HW and SW send queue

When memory is added to / removed from a partition via the Memory DLPAR
mechanism, the eHEA driver has to do a couple of things to reflect the
memory change in its own IO address translation tables. This involves
stopping and restarting the HW queues.
During this operation, it is possible that HW and SW pointer into these
queues get out of sync. This results in a situation where packets that
are attached to a send queue are not transmitted immediately, but
delayed until further X packets have been put on the queue.

This patch detects such loss of synchronization, and resets the ehea
port when needed.
Signed-off-by: NJan-Bernd Themann <themann@de.ibm.com>
Signed-off-by: NAndre Detsch <adetsch@br.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Update bnx2x version to 1.52.53-4
Signed-off-by: NYaniv Rosner <yanivr@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

PHY locking is required between two ports for some external PHYs. Since
initialization was done in the common init function (called only on the
first port initialization) rather than in the port init function, there
was in fact no PHY locking between the ports.
Signed-off-by: NYaniv Rosner <yanivr@broadcom.com>
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NSachin Sanap <ssanap@marvell.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

For 5000 series of devices, use long monitor timer to check
stuck tx queues.

This modification apply to all the 5000 series including 5300 and others.

Cc: stable@kernel.org [2.6.35]
Reported-by: Ndrago01 <drago01@gmail.com>
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Commit c96c31e4
"(drivers/net/wireless: Use wiphy_<level>)"
inadvertently changed some upper case words to
lower case.  Restore the original case.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Applying the filter flags directly as done since

commit 3474ad63
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Apr 29 04:43:05 2010 -0700

    iwlwifi: apply filter flags directly

broke 3945 under some unknown circumstances, as
reported by Alex.

Since I want to keep the direct application of
filter flags on iwlagn, duplicate the code into
both 3945 and agn and remove committing the
RXON that broke things from the 3945 version.

Cc: stable@kernel.org [2.6.35]
Reported-by: NAlex Romosan <romosan@sycorax.lbl.gov>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

These are allocated with pci_alloc_consistent, so calling
pci_dma_sync_single_for_cpu is incorrect usage of the API.  Remove this
misuse and consequently avoid the following backtrace:

WARNING: at lib/dma-debug.c:902 check_sync+0xce/0x43a()
Hardware name: 2373HU6
ipw2100 0000:02:02.0: DMA-API: device driver tries to sync DMA memory it has not allocated [device address=0x0000000034e88008] [size=8 bytes]
Modules linked in: microcode ipw2100(+) snd_seq_device ppdev libipw nsc_ircc snd_pcm lib80211 video output irda parport_pc cfg80211 parport thinkpad_acpi e1000 iTCO_wdt crc_ccitt snd_timer iTCO_vendor_support snd i2c_i801 pcspkr rfkill soundcore joydev snd_page_alloc yenta_socket radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]
Pid: 0, comm: swapper Tainted: G        W   2.6.35-wl+ #8
Call Trace:
 [<c043aa42>] warn_slowpath_common+0x6a/0x7f
 [<c05d252a>] ? check_sync+0xce/0x43a
 [<c043aaca>] warn_slowpath_fmt+0x2b/0x2f
 [<c05d252a>] check_sync+0xce/0x43a
 [<c046189a>] ? print_lock_contention_bug+0x11/0xb2
 [<c05d2b6f>] debug_dma_sync_single_for_cpu+0x47/0x49
 [<c06cbd3c>] ? ehci_irq+0x31/0x331
 [<f82a224a>] ? ipw2100_irq_tasklet+0x24/0x5e9 [ipw2100]
 [<f82a224a>] ? ipw2100_irq_tasklet+0x24/0x5e9 [ipw2100]
 [<f82a221d>] pci_dma_sync_single_for_cpu.clone.1+0x42/0x4b [ipw2100]
 [<f82a23a2>] ipw2100_irq_tasklet+0x17c/0x5e9 [ipw2100]
 [<c043fd87>] tasklet_action+0x78/0xcb
 [<c0440293>] __do_softirq+0xc4/0x183
 [<c044038d>] do_softirq+0x3b/0x5f
 [<c04404d0>] irq_exit+0x3a/0x6d
 [<c0404423>] do_IRQ+0x8b/0x9f
 [<c04038b5>] common_interrupt+0x35/0x3c
 [<c062ecfa>] ? acpi_idle_enter_simple+0xfe/0x13c
 [<c045007b>] ? exit_itimers+0x2d/0x73
 [<c062ecfc>] ? acpi_idle_enter_simple+0x100/0x13c
 [<c070bf10>] cpuidle_idle_call+0x78/0xdc
 [<c040251c>] cpu_idle+0x9b/0xb7
 [<c07b1dd2>] rest_init+0xa6/0xab
 [<c0a4b96d>] start_kernel+0x389/0x38e
 [<c0a4b0c9>] i386_start_kernel+0xc9/0xd0
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>