For ethernet support, we need to reserve QPs for the ethernet and
fibre channel driver.  The QPs are reserved at the end of the QP
table.  (This way we assure that they are aligned to their size)

We need to consider these reserved ranges in bitmap creation, so we
extend the mlx4 bitmap utility functions to allow reserved ranges at
both the bottom and the top of the range.
Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

To allow allocating an aligned range of consecutive QP numbers, add an
interface to reserve an aligned range of QP numbers and have the QP
allocation function always take a QP number.

This will be used for RSS support in the mlx4_en Ethernet driver and
also potentially by IPoIB RSS support.
Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

Doing 'WARN_ON(preempt_count())' was horribly horribly wrong, and would
cause tons of warnings at bootup if PREEMPT was enabled because the
initcalls currently run with the kernel lock, which increments the
preempt count.

At the same time, the warning was also insufficient, since it didn't
check that interrupts were enabled.

The proper debug function to use for something that can sleep and wants
a warning if it's called in the wrong context is 'might_sleep()'.
Reported-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch adds a mutex to the e1000e driver that would help
catch any collisions of two e1000e threads accessing hardware
at the same time.

description and patch updated by Jesse
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

the stats lock is left over from e1000, e1000e no longer
has the adjust tbi stats function that required the addition
of the stats lock to begin with.

adding a mutex to acquire_swflag helped catch this one too.
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

thanks to tglx, we're finding some interesting reentrancy issues.
this patch removes the phy read from inside a spinlock, paving
the way for removing the spinlock completely.  The phy read was
only feeding a statistic that wasn't used.
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

e1000e was apparently calling two functions that attempted to reserve
the SWFLAG bit for exclusive (to hardware and firmware) access to
the PHY and NVM (aka eeprom).  These accesses could possibly call
msleep to wait for the resource which is not allowed from interrupt
context.
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

in the process of debugging things, noticed that the swflag is not reset
by the driver after reset, and the swflag is probably not reset unless
management firmware clears it after 100ms.
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Set the hardware to ignore all write/erase cycles to the GbE region in
the ICHx NVM.  This feature can be disabled by the WriteProtectNVM module
parameter (enabled by default) only after a hardware reset, but
the machine must be power cycled before trying to enable writes.
Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
Signed-off-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
CC: arjan@linux.intel.com
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Enabling the MIB interrupts has proven to cause an
interrupt storm after 7 hours of run. We will make use of the
MIB interrupt once we have ANI supported added so for now
to cure this we disable the interrupt.

The interrupt storm can be seen as follows after 7 hours of run
as reported by  Steven Noonan <steven@uplinklabs.net>:

18:28:38          sum   1106.00
18:28:39          sum   1037.62
18:28:40          sum   1069.00
18:28:41          sum   1167.00
18:28:42          sum   1155.00
18:28:43          sum   1339.00
18:28:44          sum  18355.00
18:28:45          sum  17845.45
18:28:46          sum  15285.00
18:28:47          sum  17511.00
18:28:48          sum  17568.69
18:28:49          sum  17704.04
18:28:50          sum  18566.67
18:28:51          sum  18913.13

at 18:28:44 the MIB interrupt kicked off and caused huge
latency which can be seen even on a video he submitted:

http://www.youtube.com/watch?v=4GeCx1gZMpASigned-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

IRQs should be disabled before calling free_irq. Also flush pending
IRQs. Pasted the kernel log message for reference.

kernel: irq 17: nobody cared (try booting with the "irqpoll" option)
kernel:  [<c0252d2c>] __report_bad_irq+0x2e/0x6f
kernel:  [<c0252f22>] note_interrupt+0x1b5/0x207
kernel:  [<c025258b>] ? handle_IRQ_event+0x21/0x48
kernel:  [<c02534cb>] handle_fasteoi_irq+0x8e/0xad
kernel:  [<c0205650>] do_IRQ+0x6c/0x84
kernel:  [<c020425f>] common_interrupt+0x23/0x28
kernel:  [<c034f6f6>] ? acpi_idle_enter_simple+0x198/0x205
kernel:  [<c044686c>] ? menu_select+0x5c/0x78
kernel:  [<c0445a95>] cpuidle_idle_call+0x59/0x89
kernel:  [<c02029d7>] cpu_idle+0xae/0xcf
kernel:  [<c0543102>] rest_init+0x4e/0x50
kernel:  =======================
kernel: handlers:
kernel: [<f88fdd26>] (ath_isr+0x0/0x13a [ath9k])
kernel: Disabling IRQ #17
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Tested-by: NSteven Noonan <steven@uplinklabs.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

akpm: taken from http://bugzilla.kernel.org/show_bug.cgi?id=11587

I bought the wifi dongle trust nw-3100 wich is in fact a zd1211rw.  Its
hardware id was missing in the sources, adding it made it work flawlessly.

Cc: Daniel Drake <dsd@gentoo.org>
Cc: Ulrich Kunitz <kune@deine-taler.de>
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Connectivtiy is lost after Group rekeying is done. The keytype
maintained by ath9k is reset when group key is updated. Though
sc_keytype can be reset only for broadcast key the proper fix
would be to use mac80211 provided key type from txinfo during
xmit and get rid of sc_keytype from ath9k ath_softc.
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Tested-by: NSteven Noonan <steven@uplinklabs.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently e100 uses pci_enable_wake() to clear pending wake-up events
and disable PME# during intitialization, but that function is not
suitable for this purpose, because it immediately returns error code
if device_may_wakeup() returns false for given device.

Make e100 use pci_pme_active(), which carries out exactly the
required operations, instead.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Andrey reports e1000 corruption, and that a patch in vmware's ESX fixed
it.

The EEPROM corruption is triggered by concurrent access of the EEPROM
read/write. Putting a lock around it solve the problem.

[akpm@linux-foundation.org: use DEFINE_SPINLOCK to avoid confusing lockdep]
Signed-off-by: NChristopher Li <chrisl@vmware.com>
Reported-by: NAndrey Borzenkov <arvidjaar@mail.ru>
Cc: Zach Amsden <zach@vmware.com>
Cc: Pratap Subrahmanyam <pratap@vmware.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
Cc: Bruce Allan <bruce.w.allan@intel.com>
Cc: PJ Waskiewicz <peter.p.waskiewicz.jr@intel.com>
Cc: John Ronciak <john.ronciak@intel.com>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

after

| commit f735a2a1
| Author: Tobias Diedrich <ranma+kernel@tdiedrich.de>
| Date:   Sun May 18 15:02:37 2008 +0200
|
|    [netdrvr] forcedeth: setup wake-on-lan before shutting down
|
|    When hibernating in 'shutdown' mode, after saving the image the suspend hook
|    is not called again.
|    However, if the device is in promiscous mode, wake-on-lan will not work.
|    This adds a shutdown hook to setup wake-on-lan before the final shutdown.
|
|    Signed-off-by: Tobias Diedrich <ranma+kernel@tdiedrich.de>
|    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>

my servers with nvidia ck804 and mcp55 will reverse mac address with kexec.

it turns out that we need to restore the mac addr in nv_shutdown().

[akpm@linux-foundation.org: fix typo in printk]
Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Cc: Tobias Diedrich <ranma+kernel@tdiedrich.de>
Cc: Ayaz Abdulla <aabdulla@nvidia.com>
Cc: Jeff Garzik <jeff@garzik.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

The bnx2 driver stores/uses the irq value from the pci_dev internally.
But when it stores the irq value, it has been performing an
integer demotion.  Because of the recent changes made to
arch/x86/kernel/io_apic.c, the new method in creating the irq value
(using build_irq_for_pci_dev()) has exposed this bug on x86 systems.

Because of this demotion when calling request_irq() from
bnx2_request_irq(), the driver would get a return code of -EINVAL.
This is because the kernel could not find the requested irq descriptor.
By storing the irq value properly, the kernel can find the correct
irq descriptor and the bnx2 driver can operate normally.
Signed-off-by: NBenjamin Li <benli@broadcom.com>
Signed-off-by: NMichael Chan <mchan@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This fixes kernel regression for 2.6.27-rc in
      http://bugzilla.kernel.org/show_bug.cgi?id=11547
The change to split 8390 into old isa and non-isa versions
overlooked this driver.
Signed-off-by: NStephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This reverts commit bc19d6e0, which as
Larry Finger reports causes the radio LED on his system to no longer
respond to rfkill switch events.
Reported-by: NLarry Finger <Larry.Finger@lwfinger.net>
Requested-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Byte swap the addresses in the page list for fast register work requests
to big endian to match what the HCA expectx.  Also, the addresses must
have the "present" bit set so that the HCA knows it can access them.
Otherwise the HCA will fault the first time it accesses the memory
region.
Signed-off-by: NVladimir Sokolovsky <vlad@mellanox.co.il>
Signed-off-by: NRoland Dreier <rolandd@cisco.com>

The reset_task function in the niu driver does not reset the tx and rx
buffers properly. This leads to panic on reset. This patch is a
modified implementation of the previously posted fix.
Signed-off-by: NSantwona Behera <santwona.behera@sun.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Use TX control flag IEEE80211_TX_CTL_ASSIGN_SEQ as a request to update
the seq# for the frames. This will likely require some further cleanup
to get seq# correctly for Beacons vs. other frames and also potentially
for multiple BSSes. Anyway, this is better than ending up sending out
most frames with seq# 0.

(This is a backport of patch w/ same title already in net-next-2.6.
It is verified to fix http://bugzilla.kernel.org/show_bug.cgi?id=11394
and it should be acceptable for -rc due to the driver being new
in 2.6.27.)
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fix regression tracked as http://bugzilla.kernel.org/show_bug.cgi?id=11361
and caused by commit f735a2a1 ("[netdrvr]
forcedeth: setup wake-on-lan before shutting down") that makes network
adapters integrated into the NVidia MCP55 chipsets fail to work in kexeced
kernels.  The problem appears to be that if the adapter is put into D3_hot
during ->shutdown(), it cannot be brought back into D0 after kexec (ref.
http://marc.info/?l=linux-kernel&m=121900062814967&w=4).  Therefore, only
put forcedeth into D3 during ->shutdown() if the system is to be powered
off.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Tested-by: NYinghai Lu <yhlu.kernel@gmail.com>
Cc: Ayaz Abdulla <aabdulla@nvidia.com>
Acked-by: NJeff Garzik <jeff@garzik.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The allocated RX buffer size was 64 bytes bigger than the PCI mapped
size with no good reason. If the packet was actually using the buffer up
to its limit and if the last 64 bytes of the buffer crossed 4KB boundary
then an unmapped PCI page was accessed. The fix is to use only one
parameter for the buffer size - there is no need to differentiate
between the buffer size and the PCI mapping size since the extra 64
bytes can actually be used by the FW to align the Ethernet payload to
64 bytes.

Also updating the driver version and date
Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch sets STATUS_EXIT_PENDING on pci_remove. Otherwise
iwl4965_down may fail to uninitialize the driver.
Signed-off-by: NGregory Greenman <gregory.greenman@intel.com>
Signed-off-by: NMohamed Abbas <mohamed.abbas@intel.com>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch calls apm stop on exit and suspend. Without this patch
hardware consumes power even after driver is removed or suspended.
Signed-off-by: NGregory Greenman <gregory.greenman@intel.com>
Signed-off-by: NMohamed Abbas <mohamed.abbas@intel.com>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch "iwlwifi: do not use GFP_DMA in iwl_tx_queue_init" removes
GFP_DMA from allocation tx command buffers. GFP_DMA allows allocation
only for memory under 16M which causes allocation problems
suspend/resume flows.

Using kmalloc is temporal solution and some consistent/coherent
allocation schema will be more correct. Since iwlwifi hardware
supports 64bit address this solution should work on x86 (32 and
64bit) for now.

This patch fixes memory freeing problem in the previous patch.
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NIan Schram <ischram@telenet.be>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes rx_chain computation. The code that adjusts number of
rx chains to number supported by HW was missing. Miss configuration
causes firmware error.  Note: iwlwifi supports HW with up to 3 RX
chains (2x2, 2x3, 1x2, and 3x3 MIMO). This patch also simplifies the
whole RX chain computation.
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NMohamed Abbas <mohamed.abbas@intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes the wrong use MIMO power save values. Our TX was
configured with our MIMO power save values instead of peer's MIMO power
save values, this may affect connectivity. The peer STA/AP may not sense
our traffic at all as it doesn't have all RX chains opened.
Signed-off-by: NRon Rindjunsky <ron.rindjunsky@intel.com>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Rx chain might change during power save transitions but it doesn't
require sending Full-ROXN command to the firmware. Full-RXON requires
reconnection to an AP and thus affects user experience. The patch
avoids the Full-RXON by removing the rx_chain modification check in
iwl_full_rxon_required function.

Signed-off-by: Mohamed Abbas <mohamed.abbas@intel.com
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This enables sending of direct probes on passive channels, as long as
traffic was detected on that channel. This enables connectivity to
hidden/non broadcasting SSIDs APs on passive channels. Note 5000 HW
declares all 5.2 spectrum as passive.
Signed-off-by: NCahill Ben <ben.m.cahill@intel.com>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NRon Rindjunsky <ron.rindjunsky@intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch is a W/A for the TSF sync issue in IBSS merging. HW is not
capable to sync TSF (it's constantly little behind). This creates
constant IBSS merging upon reception of each beacon, adding and removing
station which in turn creates above 50% packet loss and thus dramatically
degrade the throughput. The W/A simply stops the driver from declaring it
has a reliable TSF value and thus eliminates IBSS merging.
Signed-off-by: NAssaf Krauss <assaf.krauss@intel.com>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NZhu Yi <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Remove chipset-specific quirk workaround; the workaround caused
unrecoverable DMA lockups when the driver was loaded following a
PXE boot.
Signed-off-by: NDhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: NMichael Brown <mbrown@fensystems.co.uk>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

pcnet_cs:
    add new ID: "corega Ether PCC-TD".
    remove duplicate ID: "IC-CARD".

axnet_cs:
    add new ID: "IO DATA ETXPCM".
Signed-off-by: NKomuro <komurojun-mbn@nifty.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

This commit dropped the setting of the default interrupt throttle rate.

commit 021230d4
Author: Ayyappan Veeraiyan <ayyappan.veeraiyan@intel.com>
Date:   Mon Mar 3 15:03:45 2008 -0800

    ixgbe: Introduce MSI-X queue vector code

The following patch adds it back.  Without this the default value of 0
causes the performance of this card to be awful.  Restoring these to the
default values yields much better performance.

This regression has been around since 2.6.25.
Signed-off-by: NAndy Gospodarek <andy@greyhouse.net>
Acked-by: NJesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
CC: stable@kernel.org [2.6.25 and later]
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

Make the "pegasus" driver scream less loudly in the face of
problems as it initializes, avoiding hundreds of messages:

 - ratelimit some key error messages
 - avoid some spurious diagnostics caused by strange codeflow

And fix one instance of goofy indentation.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

This patch addresses an issue with the locking order. ath_rx_flush_tid()
uses spin_lock/unlock_bh when IRQs are disabled in sta_notify by mac80211.

As node clean up is still pending with ath9k and this problematic portion
of the code is expected to change anyway, thinking of a proper fix may not
be worthwhile. So having this interim fix helps the users to get rid of the
kernel warning message.

Pasted the kernel warning message for reference.

kernel: ath0: No ProbeResp from current AP 00:1b:11:60:7a:3d - assume out of range
kernel: ------------[ cut here ]------------
kernel: WARNING: at kernel/softirq.c:136 local_bh_enable+0x3c/0xab()
kernel: Pid: 1029, comm: ath9k Not tainted 2.6.27-rc4-wt-w1fi-wl
kernel:
kernel: Call Trace:
kernel:  [<ffffffff802278d8>] warn_on_slowpath+0x51/0x77
kernel:  [<ffffffff80224c51>] check_preempt_wakeup+0xf3/0x123
kernel:  [<ffffffff80239658>] autoremove_wake_function+0x9/0x2e
kernel:  [<ffffffff8022c281>] local_bh_enable+0x3c/0xab
kernel:  [<ffffffffa01ab75a>] ath_rx_node_cleanup+0x38/0x6e [ath9k]
kernel:  [<ffffffffa01b2280>] ath_node_detach+0x3b/0xb6 [ath9k]
kernel:  [<ffffffffa01ab09f>] ath9k_sta_notify+0x12b/0x165 [ath9k]
kernel:  [<ffffffff802366cf>] queue_work+0x1d/0x49
kernel:  [<ffffffffa018c3fc>] add_todo+0x70/0x99 [mac80211]
kernel:  [<ffffffffa017de76>] __sta_info_unlink+0x16b/0x19e [mac80211]
kernel:  [<ffffffffa017e6ed>] sta_info_unlink+0x18/0x43 [mac80211]
kernel:  [<ffffffffa0182732>] ieee80211_associated+0xaa/0x16d [mac80211]
kernel:  [<ffffffffa0184a1a>] ieee80211_sta_work+0x4fb/0x6b4 [mac80211]
kernel:  [<ffffffff80469c58>] thread_return+0x30/0xa9
kernel:  [<ffffffffa018451f>] ieee80211_sta_work+0x0/0x6b4 [mac80211]
kernel:  [<ffffffff802362c2>] run_workqueue+0xb1/0x17a
kernel:  [<ffffffff80236be9>] worker_thread+0xd0/0xdb
kernel:  [<ffffffff8023964f>] autoremove_wake_function+0x0/0x2e
kernel:  [<ffffffff80236b19>] worker_thread+0x0/0xdb
kernel:  [<ffffffff8023954a>] kthread+0x47/0x75
kernel:  [<ffffffff80223121>] schedule_tail+0x18/0x50
kernel:  [<ffffffff8020bc49>] child_rip+0xa/0x11
kernel:  [<ffffffff80239503>] kthread+0x0/0x75
kernel:  [<ffffffff8020bc3f>] child_rip+0x0/0x11
kernel:
kernel: ---[ end trace e9bb5da661055827 ]---
Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>