linux/drivers/net, branch v2.6.34.2

ath5k: initialize ah->ah_current_channel

2010-08-02T17:30:23Z

commit b6855772f4a22c4fbdd4fcaceff5c8a527035123 upstream. ath5k assumes ah_current_channel is always a valid pointer in several places, but a newly created interface may not have a channel. To avoid null pointer dereferences, set it up to point to the first available channel until later reconfigured. This fixes the following oops: $ rmmod ath5k $ insmod ath5k $ iw phy0 set distance 11000 BUG: unable to handle kernel NULL pointer dereference at 00000006 IP: [] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k] *pde = 00000000 Oops: 0000 [#1] last sysfs file: /sys/devices/pci0000:00/0000:00:0e.0/ieee80211/phy0/index Modules linked in: usbhid option usb_storage usbserial usblp evdev lm90 scx200_acb i2c_algo_bit i2c_dev i2c_core via_rhine ohci_hcd ne2k_pci 8390 leds_alix2 xt_IMQ imq nf_nat_tftp nf_conntrack_tftp nf_nat_irc nf_cc Pid: 1597, comm: iw Not tainted (2.6.32.14 #8) EIP: 0060:[] EFLAGS: 00010296 CPU: 0 EIP is at ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k] EAX: 000000c2 EBX: 00000000 ECX: ffffffff EDX: c12d2080 ESI: 00000019 EDI: cf8c0000 EBP: d0a30edc ESP: cfa09bf4 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 Process iw (pid: 1597, ti=cfa09000 task=cf88a000 task.ti=cfa09000) Stack: d0a34f35 d0a353f8 d0a30edc 000000fe cf8c0000 00000000 1900063d cfa8c9e0 <0> cfa8c9e8 cfa8c0c0 cfa8c000 d0a27f0c 199d84b4 cfa8c200 00000010 d09bfdc7 <0> 00000000 00000000 ffffffff d08e0d28 cf9263c0 00000001 cfa09cc4 00000000 Call Trace: [] ? ath5k_hw_attach+0xc8c/0x3c10 [ath5k] [] ? __ieee80211_request_smps+0x1347/0x1580 [mac80211] [] ? nl80211_send_scan_start+0x7b8/0x4520 [cfg80211] [] ? nla_parse+0x59/0xc0 [] ? genl_rcv_msg+0x169/0x1a0 [] ? genl_rcv_msg+0x0/0x1a0 [] ? netlink_rcv_skb+0x38/0x90 [] ? genl_rcv+0x19/0x30 [] ? netlink_unicast+0x1b3/0x220 [] ? netlink_sendmsg+0x26e/0x290 [] ? sock_sendmsg+0xbe/0xf0 [] ? autoremove_wake_function+0x0/0x50 [] ? __alloc_pages_nodemask+0x106/0x530 [] ? do_lookup+0x53/0x1b0 [] ? __link_path_walk+0x9b9/0x9e0 [] ? verify_iovec+0x50/0x90 [] ? sys_sendmsg+0x1e1/0x270 [] ? find_get_page+0x10/0x50 [] ? filemap_fault+0x5f/0x370 [] ? __do_fault+0x319/0x370 [] ? sys_socketcall+0x244/0x290 [] ? do_page_fault+0x1ec/0x270 [] ? do_page_fault+0x0/0x270 [] ? syscall_call+0x7/0xb Code: 00 b8 fe 00 00 00 b9 f8 53 a3 d0 89 5c 24 14 89 7c 24 10 89 44 24 0c 89 6c 24 08 89 4c 24 04 c7 04 24 35 4f a3 d0 e8 7c 30 60 f0 <0f> b7 43 06 ba 06 00 00 00 a8 10 75 0e 83 e0 20 83 f8 01 19 d2 EIP: [] ath5k_hw_set_coverage_class+0x74/0x1b0 [ath5k] SS:ESP 0068:cfa09bf4 CR2: 0000000000000006 ---[ end trace 54f73d6b10ceb87b ]--- Reported-by: Steve Brown Signed-off-by: Bob Copeland Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

iwl3945: enable stuck queue detection on 3945

2010-08-02T17:30:19Z

commit a6866ac93e6cb68091326e80b4fa4619a5957644 upstream. We learn from http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=1834 and https://bugzilla.redhat.com/show_bug.cgi?id=589777 that 3945 can also suffer from a stuck command queue. Enable stuck queue detection for iwl3945 to enable recovery in this case. Signed-off-by: Reinette Chatre Signed-off-by: Greg Kroah-Hartman

iwlwifi: Recover TX flow stall due to stuck queue

2010-08-02T17:30:19Z

commit b74e31a9bc1013e69b85b139072485dc153453dd upstream. Monitors the internal TX queues periodically. When a queue is stuck for some unknown conditions causing the throughput to drop and the transfer is stop, the driver will force firmware reload and bring the system back to normal operational state. The iwlwifi devices behave differently in this regard so this feature is made part of the ops infrastructure so we can have more control on how to monitor and recover from tx queue stall case per device. Signed-off-by: Trieu 'Andrew' Nguyen Signed-off-by: Wey-Yi Guy Signed-off-by: Reinette Chatre Signed-off-by: Greg Kroah-Hartman

iwlagn: verify flow id in compressed BA packet

2010-08-02T17:30:18Z

commit b561e8274f75831ee87e4ea378cbb1f9f050a51a upstream. The flow id (scd_flow) in a compressed BA packet should match the txq_id of the queue from which the aggregated packets were sent. However, in some hardware like the 1000 series, sometimes the flow id is 0 for the txq_id (10 to 19). This can cause the annoying message: [ 2213.306191] iwlagn 0000:01:00.0: Received BA when not expected [ 2213.310178] iwlagn 0000:01:00.0: Read index for DMA queue txq id (0), index 5, is out of range [0-256] 7 7. And even worse, if agg->wait_for_ba is true when the bad BA is arriving, this can cause system hang due to NULL pointer dereference because the code is operating in a wrong tx queue! Signed-off-by: Shanyu Zhao Signed-off-by: Pradeep Kulkarni Signed-off-by: Reinette Chatre Signed-off-by: Greg Kroah-Hartman

bnx2: Fix hang during rmmod bnx2.

2010-08-02T17:30:17Z

commit f048fa9c8686119c3858a463cab6121dced7c0bf upstream. The regression is caused by: commit 4327ba435a56ada13eedf3eb332e583c7a0586a9 bnx2: Fix netpoll crash. If ->open() and ->close() are called multiple times, the same napi structs will be added to dev->napi_list multiple times, corrupting the dev->napi_list. This causes free_netdev() to hang during rmmod. We fix this by calling netif_napi_del() during ->close(). Also, bnx2_init_napi() must not be in the __devinit section since it is called by ->open(). Signed-off-by: Michael Chan Signed-off-by: Benjamin Li Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

3c503: Fix IRQ probing

2010-08-02T17:30:15Z

commit b0cf4dfb7cd21556efd9a6a67edcba0840b4d98d upstream. The driver attempts to select an IRQ for the NIC automatically by testing which of the supported IRQs are available and then probing each available IRQ with probe_irq_{on,off}(). There are obvious race conditions here, besides which: 1. The test for availability is done by passing a NULL handler, which now always returns -EINVAL, thus the device cannot be opened: 2. probe_irq_off() will report only the first ISA IRQ handled, potentially leading to a false negative. There was another bug that meant it ignored all error codes from request_irq() except -EBUSY, so it would 'succeed' despite this (possibly causing conflicts with other ISA devices). This was fixed by ab08999d6029bb2c79c16be5405d63d2bedbdfea 'WARNING: some request_irq() failures ignored in el2_open()', which exposed bug 1. This patch: 1. Replaces the use of probe_irq_{on,off}() with a real interrupt handler 2. Adds a delay before checking the interrupt-seen flag 3. Disables interrupts on all failure paths 4. Distinguishes error codes from the second request_irq() call, consistently with the first Compile-tested only. Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

dm9000: fix "BUG: spinlock recursion"

2010-08-02T17:30:12Z

commit 380fefb2ddabd4cd5f14dbe090481f0544e65078 upstream. dm9000_set_rx_csum and dm9000_hash_table are called from atomic context (in dm9000_init_dm9000), and from non-atomic context (via ethtool_ops and net_device_ops respectively). This causes a spinlock recursion BUG. Fix this by renaming these functions to *_unlocked for the atomic context, and make the original functions locking wrappers for use in the non-atomic context. Signed-off-by: Baruch Siach Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

libertas/sdio: 8686: set ECSI bit for 1-bit transfers

2010-08-02T17:30:12Z

commit 8a64c0f6b7ec7f758c4ef445e49f479e27fa2236 upstream. When operating in 1-bit mode, SDAT1 is used as dedicated interrupt line. However, the 8686 will only drive this line when the ECSI bit is set in the CCCR_IF register. Thanks to Alagu Sankar for pointing me in the right direction. Signed-off-by: Daniel Mack Cc: Alagu Sankar Cc: Volker Ernst Cc: Dan Williams Cc: John W. Linville Cc: Holger Schurig Cc: Bing Zhao Cc: libertas-dev@lists.infradead.org Cc: linux-wireless@vger.kernel.org Cc: linux-mmc@vger.kernel.org Acked-by: Dan Williams Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman

virtio_net: fix oom handling on tx

2010-08-02T17:29:51Z

commit 58eba97d0774c69b1cf3e5a8ac74419409d1abbf upstream. virtio net will never try to overflow the TX ring, so the only reason add_buf may fail is out of memory. Thus, we can not stop the device until some request completes - there's no guarantee anything at all is outstanding. Make the error message clearer as well: error here does not indicate queue full. Signed-off-by: Michael S. Tsirkin Signed-off-by: Rusty Russell Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

p54pci: add Symbol AP-300 minipci adapters pciid

2010-08-02T17:29:33Z

commit 50900f1698f68127e54c67fdfe829e4a97b1be2b upstream. Signed-off-by: Christian Lamparter Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman