aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2009-07-12NET: Fix locking issues in PPP, 6pack, mkiss and strip line disciplines.Ralf Baechle
Guido Trentalancia reports: I am trying to use the kiss driver in the Linux kernel that is being shipped with Fedora 10 but unfortunately I get the following oops: mkiss: AX.25 Multikiss, Hans Albas PE1AYX mkiss: ax0: crc mode is auto. ADDRCONF(NETDEV_CHANGE): ax0: link becomes ready ------------[ cut here ]------------ WARNING: at kernel/softirq.c:77 __local_bh_disable+0x2f/0x83() (Not tainted) [...] unloaded: microcode] Pid: 0, comm: swapper Not tainted 2.6.27.25-170.2.72.fc10.i686 #1 [<c042ddfb>] warn_on_slowpath+0x65/0x8b [<c06ab62b>] ? _spin_unlock_irqrestore+0x22/0x38 [<c04228b4>] ? __enqueue_entity+0xe3/0xeb [<c042431e>] ? enqueue_entity+0x203/0x20b [<c0424361>] ? enqueue_task_fair+0x3b/0x3f [<c041f88c>] ? resched_task+0x3a/0x6e [<c06ab62b>] ? _spin_unlock_irqrestore+0x22/0x38 [<c06ab4e2>] ? _spin_lock_bh+0xb/0x16 [<c043255b>] __local_bh_disable+0x2f/0x83 [<c04325ba>] local_bh_disable+0xb/0xd [<c06ab4e2>] _spin_lock_bh+0xb/0x16 [<f8b6f600>] mkiss_receive_buf+0x2fb/0x3a6 [mkiss] [<c0572a30>] flush_to_ldisc+0xf7/0x198 [<c0572b12>] tty_flip_buffer_push+0x41/0x51 [<f89477f2>] ftdi_process_read+0x375/0x4ad [ftdi_sio] [<f8947a5a>] ftdi_read_bulk_callback+0x130/0x138 [ftdi_sio] [<c05d4bec>] usb_hcd_giveback_urb+0x63/0x93 [<c05ea290>] uhci_giveback_urb+0xe5/0x15f [<c05eaabf>] uhci_scan_schedule+0x52e/0x767 [<c05f6288>] ? psmouse_handle_byte+0xc/0xe5 [<c054df78>] ? acpi_ev_gpe_detect+0xd6/0xe1 [<c05ec5b0>] uhci_irq+0x110/0x125 [<c05d4834>] usb_hcd_irq+0x40/0xa3 [<c0465313>] handle_IRQ_event+0x2f/0x64 [<c046642b>] handle_level_irq+0x74/0xbe [<c04663b7>] ? handle_level_irq+0x0/0xbe [<c0406e6e>] do_IRQ+0xc7/0xfe [<c0405668>] common_interrupt+0x28/0x30 [<c056821a>] ? acpi_idle_enter_simple+0x162/0x19d [<c0617f52>] cpuidle_idle_call+0x60/0x92 [<c0403c61>] cpu_idle+0x101/0x134 [<c069b1ba>] rest_init+0x4e/0x50 ======================= ---[ end trace b7cc8076093467ad ]--- ------------[ cut here ]------------ WARNING: at kernel/softirq.c:136 _local_bh_enable_ip+0x3d/0xc4() [...] Pid: 0, comm: swapper Tainted: G W 2.6.27.25-170.2.72.fc10.i686 [<c042ddfb>] warn_on_slowpath+0x65/0x8b [<c06ab62b>] ? _spin_unlock_irqrestore+0x22/0x38 [<c04228b4>] ? __enqueue_entity+0xe3/0xeb [<c042431e>] ? enqueue_entity+0x203/0x20b [<c0424361>] ? enqueue_task_fair+0x3b/0x3f [<c041f88c>] ? resched_task+0x3a/0x6e [<c06ab62b>] ? _spin_unlock_irqrestore+0x22/0x38 [<c06ab4e2>] ? _spin_lock_bh+0xb/0x16 [<f8b6f642>] ? mkiss_receive_buf+0x33d/0x3a6 [mkiss] [<c04325f9>] _local_bh_enable_ip+0x3d/0xc4 [<c0432688>] local_bh_enable_ip+0x8/0xa [<c06ab54d>] _spin_unlock_bh+0x11/0x13 [<f8b6f642>] mkiss_receive_buf+0x33d/0x3a6 [mkiss] [<c0572a30>] flush_to_ldisc+0xf7/0x198 [<c0572b12>] tty_flip_buffer_push+0x41/0x51 [<f89477f2>] ftdi_process_read+0x375/0x4ad [ftdi_sio] [<f8947a5a>] ftdi_read_bulk_callback+0x130/0x138 [ftdi_sio] [<c05d4bec>] usb_hcd_giveback_urb+0x63/0x93 [<c05ea290>] uhci_giveback_urb+0xe5/0x15f [<c05eaabf>] uhci_scan_schedule+0x52e/0x767 [<c05f6288>] ? psmouse_handle_byte+0xc/0xe5 [<c054df78>] ? acpi_ev_gpe_detect+0xd6/0xe1 [<c05ec5b0>] uhci_irq+0x110/0x125 [<c05d4834>] usb_hcd_irq+0x40/0xa3 [<c0465313>] handle_IRQ_event+0x2f/0x64 [<c046642b>] handle_level_irq+0x74/0xbe [<c04663b7>] ? handle_level_irq+0x0/0xbe [<c0406e6e>] do_IRQ+0xc7/0xfe [<c0405668>] common_interrupt+0x28/0x30 [<c056821a>] ? acpi_idle_enter_simple+0x162/0x19d [<c0617f52>] cpuidle_idle_call+0x60/0x92 [<c0403c61>] cpu_idle+0x101/0x134 [<c069b1ba>] rest_init+0x4e/0x50 ======================= ---[ end trace b7cc8076093467ad ]--- mkiss: ax0: Trying crc-smack mkiss: ax0: Trying crc-flexnet The issue was, that the locking code in mkiss was assuming it was only ever being called in process or bh context. Fixed by converting the involved locking code to use irq-safe locks. Review of other networking line disciplines shows that 6pack, both sync and async PPP and STRIP have similar issues. The ppp_async one is the most interesting one as it sorts out half of the issue as far back as 2004 in commit http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=2996d8deaeddd01820691a872550dc0cfba0c37d Signed-off-by: Ralf Baechle <ralf@linux-mips.org> Reported-by: Guido Trentalancia <guido@trentalancia.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-12netdev: restore MTU change operationBen Hutchings
alloc_etherdev() used to install a default implementation of this operation, but it must now be explicitly installed in struct net_device_ops. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-12netdev: restore MAC address set and validate operationsBen Hutchings
alloc_etherdev() used to install default implementations of these operations, but they must now be explicitly installed in struct net_device_ops. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-11sit: fix regression: do not release skb->dst before xmitSascha Hlusiak
The sit module makes use of skb->dst in it's xmit function, so since 93f154b594fe47 ("net: release dst entry in dev_hard_start_xmit()") sit tunnels are broken, because the flag IFF_XMIT_DST_RELEASE is not unset. This patch unsets that flag for sit devices to fix this regression. Signed-off-by: Sascha Hlusiak <contact@saschahlusiak.de> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-11net: ip_push_pending_frames() fixEric Dumazet
After commit 2b85a34e911bf483c27cfdd124aeb1605145dc80 (net: No more expensive sock_hold()/sock_put() on each tx) we do not take any more references on sk->sk_refcnt on outgoing packets. I forgot to delete two __sock_put() from ip_push_pending_frames() and ip6_push_pending_frames(). Reported-by: Emil S Tantilov <emils.tantilov@gmail.com> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Tested-by: Emil S Tantilov <emils.tantilov@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-11net: sk_prot_alloc() should not blindly overwrite memoryEric Dumazet
Some sockets use SLAB_DESTROY_BY_RCU, and our RCU code correctness depends on sk->sk_nulls_node.next being always valid. A NULL value is not allowed as it might fault a lockless reader. Current sk_prot_alloc() implementation doesnt respect this hypothesis, calling kmem_cache_alloc() with __GFP_ZERO. Just call memset() around the forbidden field. Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-09cxgb3: Fix crash caused by stashing wrong netdev_queueRoland Dreier
Commit c3a8c5b6 ("cxgb3: move away from LLTX") exposed a bug in how cxgb3 looks up the netdev_queue it stashes away in a qset during initialization. For multiport devices, the TX queue index it uses is offset by the first_qset index of each port. This leads to a crash once LLTX is removed, since hard_start_xmit is called with one TX queue lock held, while the TX reclaim timer task grabs a different (wrong) TX queue lock when it frees skbs. Fix this by removing the first_qset offset used to look up the TX queue passed into t3_sge_alloc_qset() from setup_sge_qsets(). Signed-off-by: Roland Dreier <rolandd@cisco.com> Acked-by: Divy Le Ray <divy@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-09ixgbe: Fix coexistence of FCoE and Flow Director in 82599Yi Zou
Fix coexistence of Fiber Channel over Ethernet (FCoE) and Flow Director (FDIR) in 82599 and remove the disabling of FDIR when FCoE is enabled. Currently, FDIR is turned off when FCoE is enabled under the assumption that FCoE is always enabled with DCB being turned on. However, FDIR does not have to be turned off all the time when FCoE is enabled since FCoE can be enabled without DCB being turned on, e.g., use link pause only. This patch makes sure that when DCB is turned on or off, FDIR is turned on or off correspondingly; and when FCoE is enabled, it does not disable FDIR, rather, it will have FDIR set up properly so FCoE and FDIR can coexist regardless of DCB being on or off. Signed-off-by: Yi Zou <yi.zou@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-09memory barrier: adding smp_mb__after_lockJiri Olsa
Adding smp_mb__after_lock define to be used as a smp_mb call after a lock. Making it nop for x86, since {read|write|spin}_lock() on x86 are full memory barriers. Signed-off-by: Jiri Olsa <jolsa@redhat.com> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-09net: adding memory barrier to the poll and receive callbacksJiri Olsa
Adding memory barrier after the poll_wait function, paired with receive callbacks. Adding fuctions sock_poll_wait and sk_has_sleeper to wrap the memory barrier. Without the memory barrier, following race can happen. The race fires, when following code paths meet, and the tp->rcv_nxt and __add_wait_queue updates stay in CPU caches. CPU1 CPU2 sys_select receive packet ... ... __add_wait_queue update tp->rcv_nxt ... ... tp->rcv_nxt check sock_def_readable ... { schedule ... if (sk->sk_sleep && waitqueue_active(sk->sk_sleep)) wake_up_interruptible(sk->sk_sleep) ... } If there was no cache the code would work ok, since the wait_queue and rcv_nxt are opposit to each other. Meaning that once tp->rcv_nxt is updated by CPU2, the CPU1 either already passed the tp->rcv_nxt check and sleeps, or will get the new value for tp->rcv_nxt and will return with new data mask. In both cases the process (CPU1) is being added to the wait queue, so the waitqueue_active (CPU2) call cannot miss and will wake up CPU1. The bad case is when the __add_wait_queue changes done by CPU1 stay in its cache, and so does the tp->rcv_nxt update on CPU2 side. The CPU1 will then endup calling schedule and sleep forever if there are no more data on the socket. Calls to poll_wait in following modules were ommited: net/bluetooth/af_bluetooth.c net/irda/af_irda.c net/irda/irnet/irnet_ppp.c net/mac80211/rc80211_pid_debugfs.c net/phonet/socket.c net/rds/af_rds.c net/rfkill/core.c net/sunrpc/cache.c net/sunrpc/rpc_pipe.c net/tipc/socket.c Signed-off-by: Jiri Olsa <jolsa@redhat.com> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-08netpoll: Fix carrier detection for drivers that are using phylibAnton Vorontsov
Using early netconsole and gianfar driver this error pops up: netconsole: timeout waiting for carrier It appears that net/core/netpoll.c:netpoll_setup() is using cond_resched() in a loop waiting for a carrier. The thing is that cond_resched() is a no-op when system_state != SYSTEM_RUNNING, and so drivers/net/phy/phy.c's state_queue is never scheduled, therefore link detection doesn't work. I belive that the main problem is in cond_resched()[1], but despite how the cond_resched() story ends, it might be a good idea to call msleep(1) instead of cond_resched(), as suggested by Andrew Morton. [1] http://lkml.org/lkml/2009/7/7/463 Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-08Merge branch 'master' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
2009-07-08includecheck fix: include/linux, rfkill.hJaswinder Singh Rajput
fix the following 'make includecheck' warning: include/linux/rfkill.h: linux/types.h is included more than once. Signed-off-by: Jaswinder Singh Rajput <jaswinderrajput@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-08p54: tx refused but queue activeLarry Finger
In the mainline kernel, p54usb will fail because the TX queue length can become < 0. This problem has been reported as Bugzilla #13725. The failure is expressed by the following message in the logs: WARNING: at net/mac80211/tx.c:1325 ieee80211_tx+0x23c/0x298 [mac80211]() Hardware name: HP Pavilion dv2700 Notebook PC tx refused but queue active This problem has been recently observed in the wireless-testing tree, where a full solution is being tested. That fix is too invasive for 2.6.31-rcX, but the simple change supplied here will prevent the failure. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-08Atheros Kconfig needs to be dependent on WLAN_80211Jay Sternberg
Atheros top level menu needs a "depends WLAN_80211" to properly indent within menuconfig and xconfig interfaces. This is purely a visual issue but it effects all subsequent drivers. The issue is the top level menu does not include a dependency on WLAN_80211 so within the tree structure, Atheros is at the same level as WLAN_80211 but when WLAN_80211 collapsed, the menu disappears along with all subsequent drives, so it is really a subordinate. Signed-off-by: Jay Sternberg <jay.e.sternberg@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-08mac80211: fix docbookJohannes Berg
These two functions no longer exist in mac80211, so trying to insert them generates warnings in the document. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-08mac80211_hwsim: avoid NULL accessJohannes Berg
There's a race condition -- started can be set to true before channel is set due to the way mac80211 callbacks currently work (->start should probably pass the channel we would like to have initially). For now simply add a check to hwsim to avoid dereferencing the NULL channel pointer. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-08ssb: Add support for 4318EClyde McPherson
Added support for the Broadcom 4318E chipset on PCMCIA/CF cards. The 4318E can do 802.11A/B/G, only B and G mode are supported in b43. Signed-off-by: Clyde McPherson <ccmcphe@verizon.net> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-08b43: Add support for 4318EClyde McPherson
Added support for the Broadcom 4318E chipset on PCMCIA/CF cards. The 4318E can do 802.11A/B/G, only B and G mode are supported in b43. Signed-off-by: Clyde McPherson <ccmcphe@verizon.net> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-08zd1211rw: adding SONY IFU-WLM2 (054c:0257) as a zd1211b deviceHin-Tak Leung
Yevgen Kotikov reported success on the sourceforge zd1211-devs list with the following details: Brand/retail: SONY IFU-WLM2 USB-IDs: Vendor: 0x054C Device: 0x0257 chip ID: zd1211b chip 054c:0257 v4802 high 00-0b-6b AL2230_RF pa0 ----- FCC ID: unknown Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net> Tested-by: Yevgen Kotikov <yevgen.kotikov@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-08zd1211rw: 07b8:6001 is a ZD1211BPascal Terjan
On a shuttle machine here we got 07b8:6001 device, handled by zd1211rw, which does not work. Scanning is OK but association does not work, we get "direct probe to AP xxx timed out" It appears that this simple patch makes the device work perfectly. This id was already there in initial import of the driver so I don't know if it has ever been working as ZD1211 (which would mean they changed it and kept the id :( ). Signed-off-by: Pascal Terjan <pterjan@mandriva.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-08r6040: bump driver version to 0.24 and date to 08 July 2009Florian Fainelli
Signed-off-by: Florian Fainelli <florian@openwrt.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-08r6040: restore MIER register correctly when IRQ line is sharedFlorian Fainelli
When the r6040 device IRQ line is shared we will enter the driver interrupt service routine, mask off the device interrupt enable register (MIER) and return with IRQ_NONE, we would then leave the device with interrupts disabled, this patch fixes that issue. Reported-by: Steve Holland <sdh4@iastate.edu> Signed-off-by: Joe Chou <joe.chou@rdc.com.tw> Signed-off-by: Florian Fainelli <florian@openwrt.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-08ipv4: Fix fib_trie rebalancing, part 4 (root thresholds)Jarek Poplawski
Pawel Staszewski wrote: <blockquote> Some time ago i report this: http://bugzilla.kernel.org/show_bug.cgi?id=6648 and now with 2.6.29 / 2.6.29.1 / 2.6.29.3 and 2.6.30 it back dmesg output: oprofile: using NMI interrupt. Fix inflate_threshold_root. Now=15 size=11 bits ... Fix inflate_threshold_root. Now=15 size=11 bits cat /proc/net/fib_triestat Basic info: size of leaf: 40 bytes, size of tnode: 56 bytes. Main: Aver depth: 2.28 Max depth: 6 Leaves: 276539 Prefixes: 289922 Internal nodes: 66762 1: 35046 2: 13824 3: 9508 4: 4897 5: 2331 6: 1149 7: 5 9: 1 18: 1 Pointers: 691228 Null ptrs: 347928 Total size: 35709 kB </blockquote> It seems, the current threshold for root resizing is too aggressive, and it causes misleading warnings during big updates, but it might be also responsible for memory problems, especially with non-preempt configs, when RCU freeing is delayed long after call_rcu. It should be also mentioned that because of non-atomic changes during resizing/rebalancing the current lookup algorithm can miss valid leaves so it's additional argument to shorten these activities even at a cost of a minimally longer searching. This patch restores values before the patch "[IPV4]: fib_trie root node settings", commit: 965ffea43d4ebe8cd7b9fee78d651268dd7d23c5 from v2.6.22. Pawel's report: <blockquote> I dont see any big change of (cpu load or faster/slower routing/propagating routes from bgpd or something else) - in avg there is from 2% to 3% more of CPU load i dont know why but it is - i change from "preempt" to "no preempt" 3 times and check this my "mpstat -P ALL 1 30" always avg cpu load was from 2 to 3% more compared to "no preempt" [...] cat /proc/net/fib_triestat Basic info: size of leaf: 20 bytes, size of tnode: 36 bytes. Main: Aver depth: 2.44 Max depth: 6 Leaves: 277814 Prefixes: 291306 Internal nodes: 66420 1: 32737 2: 14850 3: 10332 4: 4871 5: 2313 6: 942 7: 371 8: 3 17: 1 Pointers: 599098 Null ptrs: 254865 Total size: 18067 kB </blockquote> According to this and other similar reports average depth is slightly increased (~0.2), and root nodes are shorter (log 17 vs. 18), but there is no visible performance decrease. So, until memory handling is improved or added parameters for changing this individually, this patch resets to safer defaults. Reported-by: Pawel Staszewski <pstaszewski@itcare.pl> Reported-by: Jorge Boncompte [DTI2] <jorge@dti2.net> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com> Tested-by: Pawel Staszewski <pstaszewski@itcare.pl> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-08davinci_emac: fix kernel oops when changing MAC address while interface is downPablo Bitton
Check that network interface is running before changing its MAC address. Otherwise, rxch is accessed when it's NULL - causing a kernel oops. Moreover, check that the new MAC address is valid. Signed-off-by: Pablo Bitton <pablo.bitton@gmail.com> Signed-off-by: Chaithrika U S <chaithrika@ti.com> Tested-by: Chaithrika U S <chaithrika@ti.com> [tested on DM6467 EVM] Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-08igb: set lan id prior to configuring phyAlexander Duyck
The igb driver was defaulting to using the lock for pci-e function 0 for all of the phys due to the fact that the lan id was not being set prior to initialization. This change makes it so that the function id is set prior to checking for the phy id. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-07mac80211: minstrel: avoid accessing negative indices in rix_to_ndx()Luciano Coelho
If rix is not found in mi->r[], i will become -1 after the loop. This value is eventually used to access arrays, so we were accessing arrays with a negative index, which is obviously not what we want to do. This patch fixes this potential problem. Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com> Acked-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-07cfg80211: fix refcount leakJohannes Berg
The code in cfg80211's cfg80211_bss_update erroneously grabs a reference to the BSS, which means that it will never be freed. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Cc: stable@kernel.org [2.6.29, 2.6.30] Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-07hp-wmi: fix rfkill bugJohannes Berg
Fix the third (I think) polarity error I accidentally introduced in the rfkill rewrite to make wireless work again on (certain?) HP laptops. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Tested-by: Maciej Rutecki <maciej.rutecki@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-07mac80211: fix allocation in mesh_queue_preqAndrey Yurovsky
We allocate a PREQ queue node in mesh_queue_preq, however the allocation may cause us to sleep. Use GFP_ATOMIC to prevent this. [ 1869.126498] BUG: scheduling while atomic: ping/1859/0x10000100 [ 1869.127164] Modules linked in: ath5k mac80211 ath [ 1869.128310] Pid: 1859, comm: ping Not tainted 2.6.30-wl #1 [ 1869.128754] Call Trace: [ 1869.129293] [<c1023a2b>] __schedule_bug+0x48/0x4d [ 1869.129866] [<c13b5533>] __schedule+0x77/0x67a [ 1869.130544] [<c1026f2e>] ? release_console_sem+0x17d/0x185 [ 1869.131568] [<c807cf47>] ? mesh_queue_preq+0x2b/0x165 [mac80211] [ 1869.132318] [<c13b5b3e>] schedule+0x8/0x1f [ 1869.132807] [<c1023c12>] __cond_resched+0x16/0x2f [ 1869.133478] [<c13b5bf0>] _cond_resched+0x27/0x32 [ 1869.134191] [<c108a370>] kmem_cache_alloc+0x1c/0xcf [ 1869.134714] [<c10273ae>] ? printk+0x15/0x17 [ 1869.135670] [<c807cf47>] mesh_queue_preq+0x2b/0x165 [mac80211] [ 1869.136731] [<c807d1f8>] mesh_nexthop_lookup+0xee/0x12d [mac80211] [ 1869.138130] [<c807417e>] ieee80211_xmit+0xe6/0x2b2 [mac80211] [ 1869.138935] [<c80be46d>] ? ath5k_hw_setup_rx_desc+0x0/0x66 [ath5k] [ 1869.139831] [<c80c97bc>] ? ath5k_tasklet_rx+0xba/0x506 [ath5k] [ 1869.140863] [<c8075191>] ieee80211_subif_start_xmit+0x6c9/0x6e4 [mac80211] [ 1869.141665] [<c105cf1c>] ? handle_level_irq+0x78/0x9d [ 1869.142390] [<c12e3f93>] dev_hard_start_xmit+0x168/0x1c7 [ 1869.143092] [<c12f1f17>] __qdisc_run+0xe1/0x1b7 [ 1869.143612] [<c12e25ff>] qdisc_run+0x18/0x1a [ 1869.144248] [<c12e62f4>] dev_queue_xmit+0x16a/0x25a [ 1869.144785] [<c13b6dcc>] ? _read_unlock_bh+0xe/0x10 [ 1869.145465] [<c12eacdb>] neigh_resolve_output+0x19c/0x1c7 [ 1869.146182] [<c130e2da>] ? ip_finish_output+0x0/0x51 [ 1869.146697] [<c130e2a0>] ip_finish_output2+0x182/0x1bc [ 1869.147358] [<c130e327>] ip_finish_output+0x4d/0x51 [ 1869.147863] [<c130e9d5>] ip_output+0x80/0x85 [ 1869.148515] [<c130cc49>] dst_output+0x9/0xb [ 1869.149141] [<c130dec6>] ip_local_out+0x17/0x1a [ 1869.149632] [<c130e0bc>] ip_push_pending_frames+0x1f3/0x255 [ 1869.150343] [<c13247ff>] raw_sendmsg+0x5e6/0x667 [ 1869.150883] [<c1033c55>] ? insert_work+0x6a/0x73 [ 1869.151834] [<c8071e00>] ? ieee80211_invoke_rx_handlers+0x17da/0x1ae8 [mac80211] [ 1869.152630] [<c132bd68>] inet_sendmsg+0x3b/0x48 [ 1869.153232] [<c12d7deb>] __sock_sendmsg+0x45/0x4e [ 1869.153740] [<c12d8537>] sock_sendmsg+0xb8/0xce [ 1869.154519] [<c80be46d>] ? ath5k_hw_setup_rx_desc+0x0/0x66 [ath5k] [ 1869.155289] [<c1036b25>] ? autoremove_wake_function+0x0/0x30 [ 1869.155859] [<c115992b>] ? __copy_from_user_ll+0x11/0xce [ 1869.156573] [<c1159d99>] ? copy_from_user+0x31/0x54 [ 1869.157235] [<c12df646>] ? verify_iovec+0x40/0x6e [ 1869.157778] [<c12d869a>] sys_sendmsg+0x14d/0x1a5 [ 1869.158714] [<c8072c40>] ? __ieee80211_rx+0x49e/0x4ee [mac80211] [ 1869.159641] [<c80c83fe>] ? ath5k_rxbuf_setup+0x6d/0x8d [ath5k] [ 1869.160543] [<c80be46d>] ? ath5k_hw_setup_rx_desc+0x0/0x66 [ath5k] [ 1869.161434] [<c80beba4>] ? ath5k_hw_get_rxdp+0xe/0x10 [ath5k] [ 1869.162319] [<c80c97bc>] ? ath5k_tasklet_rx+0xba/0x506 [ath5k] [ 1869.163063] [<c1005627>] ? enable_8259A_irq+0x40/0x43 [ 1869.163594] [<c101edb8>] ? __dequeue_entity+0x23/0x27 [ 1869.164793] [<c100187a>] ? __switch_to+0x2b/0x105 [ 1869.165442] [<c1021d5f>] ? finish_task_switch+0x5b/0x74 [ 1869.166129] [<c12d963a>] sys_socketcall+0x14b/0x17b [ 1869.166612] [<c1002b95>] syscall_call+0x7/0xb Signed-off-by: Andrey Yurovsky <andrey@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-07iwmc3200wifi: add Kconfig helpSamuel Ortiz
We're missing a Kconfig help for the iwmc3200wifi driver. Signed-off-by: Samuel Ortiz <samuel.ortiz@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-07ath9k: Fix leak in tx descriptorVasanthakumar Thiagarajan
When we reclaim the tx desc, we always assume that the last desc is a holding desc, which is not true, and skip it. If the tx queue is drained during channel change, internal reset and etc, the last descriptor may not be the holding descriptor and we fail to reclaim them. This results in the following two issues. 1. Tx stuck - We drop all the frames coming from upper layer due to shortage in tx desc. 2. Crash - If we fail to reclaim a tx descriptor, we miss to update the tx BA window with the seq number of the frame associated to that desc, which, at some point, result in the following crash due to an assert failure in ath_tx_addto_baw(). This patch fixes these two issues. kernel BUG at ../drivers/net/wireless/ath/ath9k/xmit.c:180! [155064.304164] invalid opcode: 0000 [#1] SMP Call Trace: [<fbc6d83b>] ? ath9k_tx+0xeb/0x160 [ath9k] [<fbbc9591>] ipv6? __ieee80211_tx+0x41/0x120 [mac80211] [<fbbcb5ae>] ? aes_i586ieee80211_master_start_xmit+0x28e/0x560 [mac80211] [<c037e501>] aes_generic? _spin_lock_irqsave+0x31/0x40 [<c02f347b>] ? dev_hard_start_xmit+0x16b/0x1c0 [<c03058b5>] ? __qdisc_run+0x1b5/0x200 [<fbbcda5a>] ? af_packetieee80211_select_queue+0xa/0x100 [mac80211] [<c02f53b7>] ? i915dev_queue_xmit+0x2e7/0x3f0 [<fbbc9b49>] ? ieee80211_subif_start_xmit+0x369/0x7a0 [mac80211] [<c031bc35>] ? ip_output+0x55/0xb0 [<c02e0188>] ? show_memcpy_count+0x18/0x60 [<c02eb186>] ? __kfree_skb+0x36/0x90 [<c02f2202>] ? binfmt_miscdev_queue_xmit_nit+0xd2/0x110 [<c02f347b>] ? dev_hard_start_xmit+0x16b/0x1c0 [<c03058b5>] ? __qdisc_run+0x1b5/0x200 [<c033bca7>] ? scoarp_create+0x57/0x2a0 [<c02f53b7>] ? bridgedev_queue_xmit+0x2e7/0x3f0 [<c03034a0>] ? eth_header+0x0/0xc0 [<c033b95f>] stp? arp_xmit+0x5f/0x70 [<c033bf4f>] ? arp_send+0x5f/0x70 [<c033c8f5>] bnep? arp_solicit+0x105/0x210 [<c02fa5aa>] ? neigh_timer_handler+0x19a/0x390 [<c013bf88>] ? run_timer_softirq+0x138/0x210 [<c02fa410>] ? ppdevneigh_timer_handler+0x0/0x390 [<c02fa410>] ? neigh_timer_handler+0x0/0x390 Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-07b43/b43legacy: fix radio LED initializationLarry Finger
Fix condition in which radio LED did not initialize correctly, and remove 4 compilation warnings. After the recent changes in rfkill, the radio LED used by b43/b43legacy did not always initialize correctly. Both b43 and b43legacy used the deprecated variable radio_enabled in struct ieee80211_conf. Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-07Wireless: nl80211, fix lock imbalanceJiri Slaby
Don't forget to unlock cfg80211_mutex in one fail path of nl80211_set_wiphy. Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2009-07-06fec: fix definition of 5272 version of FEC_X_DES_ACTIVE registerGreg Ungerer
fec: fix definition of 5272 version of FEC_X_DES_ACTIVE register The ColdFire 5272 FEC driver has a different register address map than other users of the FEC driver. And its definition of the FEC_X_DES_ACTIVE register is incorrect, it should be 0x14. The fec interface cannot transmit data with the old value. Signed-off-by: Greg Ungerer <gerg@uclinux.org> ---- Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-06fec: remove extra ";" from definition namesGreg Ungerer
Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-06Revert "p54: Use SKB list handling helpers instead of by-hand code."David S. Miller
This reverts commit a1091aae19b1d9c85d91c86915a611387f67a26b.
2009-07-06sctp: fix warning at inet_sock_destruct() while release sctp socketWei Yongjun
Commit 'net: Move rx skb_orphan call to where needed' broken sctp protocol with warning at inet_sock_destruct(). Actually, sctp can do this right with sctp_sock_rfree_frag() and sctp_skb_set_owner_r_frag() pair. sctp_sock_rfree_frag(skb); sctp_skb_set_owner_r_frag(skb, newsk); This patch not revert the commit d55d87fdff8252d0e2f7c28c2d443aee17e9d70f, instead remove the sctp_sock_rfree_frag() function. ------------[ cut here ]------------ WARNING: at net/ipv4/af_inet.c:151 inet_sock_destruct+0xe0/0x142() Modules linked in: sctp ipv6 dm_mirror dm_region_hash dm_log dm_multipath scsi_mod ext3 jbd uhci_hcd ohci_hcd ehci_hcd [last unloaded: scsi_wait_scan] Pid: 1808, comm: sctp_test Not tainted 2.6.31-rc2 #40 Call Trace: [<c042dd06>] warn_slowpath_common+0x6a/0x81 [<c064a39a>] ? inet_sock_destruct+0xe0/0x142 [<c042dd2f>] warn_slowpath_null+0x12/0x15 [<c064a39a>] inet_sock_destruct+0xe0/0x142 [<c05fde44>] __sk_free+0x19/0xcc [<c05fdf50>] sk_free+0x18/0x1a [<ca0d14ad>] sctp_close+0x192/0x1a1 [sctp] [<c0649f7f>] inet_release+0x47/0x4d [<c05fba4d>] sock_release+0x19/0x5e [<c05fbab3>] sock_close+0x21/0x25 [<c049c31b>] __fput+0xde/0x189 [<c049c3de>] fput+0x18/0x1a [<c049988f>] filp_close+0x56/0x60 [<c042f422>] put_files_struct+0x5d/0xa1 [<c042f49f>] exit_files+0x39/0x3d [<c043086a>] do_exit+0x1a5/0x5dd [<c04a86c2>] ? d_kill+0x35/0x3b [<c0438fa4>] ? dequeue_signal+0xa6/0x115 [<c0430d05>] do_group_exit+0x63/0x8a [<c0439504>] get_signal_to_deliver+0x2e1/0x2f9 [<c0401d9e>] do_notify_resume+0x7c/0x6b5 [<c043f601>] ? autoremove_wake_function+0x0/0x34 [<c04a864e>] ? __d_free+0x3d/0x40 [<c04a867b>] ? d_free+0x2a/0x3c [<c049ba7e>] ? vfs_write+0x103/0x117 [<c05fc8fa>] ? sys_socketcall+0x178/0x182 [<c0402a56>] work_notifysig+0x13/0x19 ---[ end trace 9db92c463e789fba ]--- Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-06tun/tap: Fix crashes if open() /dev/net/tun and then poll() it.Mariusz Kozlowski
Fix NULL pointer dereference in tun_chr_pool() introduced by commit 33dccbb050bbe35b88ca8cf1228dcf3e4d4b3554 ("tun: Limit amount of queued packets per device") and triggered by this code: int fd; struct pollfd pfd; fd = open("/dev/net/tun", O_RDWR); pfd.fd = fd; pfd.events = POLLIN | POLLOUT; poll(&pfd, 1, 0); Reported-by: Eugene Kapun <abacabadabacaba@gmail.com> Signed-off-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-05dsa: fix 88e6xxx statistics counter snapshottingStephane Contri
The bit that tells us whether a statistics counter snapshot operation has completed is located in the GLOBAL register block, not in the GLOBAL2 register block, so fix up mv88e6xxx_stats_wait() to poll the right register address. Signed-off-by: Stephane Contri <Stephane.Contri@grassvalley.com> Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Cc: stable@kernel.org Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-05forcedeth: Fix NAPI race.Eric Dumazet
Eric Dumazet a écrit : > Ingo Molnar a écrit : >>> The following changes since commit 52989765629e7d182b4f146050ebba0abf2cb0b7: >>> Linus Torvalds (1): >>> Merge git://git.kernel.org/.../davem/net-2.6 >>> >>> are available in the git repository at: >>> >>> master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master >> Hm, something in this lot quickly wrecked networking here - see the >> tx timeout dump below. It starts with: >> >> [ 351.004596] WARNING: at net/sched/sch_generic.c:246 dev_watchdog+0x10b/0x19c() >> [ 351.011815] Hardware name: System Product Name >> [ 351.016220] NETDEV WATCHDOG: eth0 (forcedeth): transmit queue 0 timed out >> >> Config attached. Unfortunately i've got no time to do bisection >> today. > > > > forcedeth might have a problem, in its netif_wake_queue() logic, but > I could not see why a recent patch could make this problem visible now. > > CPU0/1: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping 02 > is not a new cpu either :) > > forcedeth uses an internal tx_stop without appropriate barrier. > > Could you try following patch ? > > (random guess as I dont have much time right now) We might have a race in napi_schedule(), leaving interrupts disabled forever. I cannot test this patch, I dont have the hardware... Tested-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-05drivers/net/smsc911x.c: Fix resource size off by 1 errorJulia Lawall
The call resource_size(res) returns res->end - res->start + 1 and thus the second change is semantics-preserving. res_size is then used as the second argument of a call to request_mem_region, and the memory allocated by this call appears to be the same as what is released in the two calls to release_mem_region. So the size argument for those calls should be resource_size(size) as well. Alternatively, in the second call to release_mem_region, the second argument could be res_size, as that variable has already been initialized at the point of this call. The problem was found using the following semantic patch: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ struct resource *res; @@ - (res->end - res->start) + 1 + resource_size(res) @@ struct resource *res; @@ - res->end - res->start + BAD(resource_size(res)) // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-05pcnet_cs: add new idKen Kawasaki
add new id (RIOS System PC CARD3 ETHERNET). Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-05bnx2x: Fix the maximal values of coalescing timeouts.Eilon Greenstein
This patch properly defines the maximum values for rx/tx coalescing timeouts. Signed-off-by: Vlad Zolotarov <vladz@broadcom.com> Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-05bnx2x: Disable HC coalescing when setting timeout to zero.Eilon Greenstein
Problem reported by Flavio Leitner <fleitner@redhat.com>: When setting rx/tx coalescing timeout to the values less than 12 traffic was stopped. The FW supports coalescing in 12us granularity, and so value of less then 12 should be interpreted as disabling coalescing Signed-off-by: Vlad Zolotarov <vladz@broadcom.com> Signed-off-by: Eilon Greenstein <eilong@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-05tun: Fix device unregister raceHerbert Xu
It is currently possible for an asynchronous device unregister to cause the same tun device to be unregistered twice. This is because the unregister in tun_chr_close only checks whether __tun_get(tfile) != NULL. This however has nothing to do with whether the device has already been unregistered. All it tells you is whether __tun_detach has been called. This patch fixes this by using the most obvious thing to test whether the device has been unregistered. It also moves __tun_detach outside of rtnl_unlock since nothing that it does requires that lock. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-03be2net: fix spurious interrupt handling in intx modeSathya Perla
Occasionally we may see an interrupt without an event in the eq. In intx, we currently see the event queue and return IRQ_NONE causing a the irq to be disabled ("no one cared".) Instead, read the CEV_ISR reg to check the existence of the interrupt. Signed-off-by: Sathya Perla <sathyap@serverengines.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-03e1000e: disable K1 at 1000Mbps for 82577/82578Bruce Allan
This workaround is required for an issue in hardware where noise on the interconnect between the MAC and PHY could be generated by a lower power mode (K1) at 1000Mbps resulting in bad packets. Disable K1 while at 1000 Mbps but keep it enabled for 10/100Mbps and when the cable is disconnected. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-03e1000e: delay second read of PHY_STATUS register on failure of first readBruce Allan
Some PHYs may require two reads of the PHY_STATUS register to determine the link status. If the PHY is being accessed by another thread it is possible the first read could timeout and fail. In this case, put a delay in so the second read will pick up the correct link status. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-03e1000e: prevent NVM corruption on sectors larger than 4KBruce Allan
Limit NVM writes to 4K sections to prevent NVM corruption on larger sector allocations (up to 64K). Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-16 13:01:28 +0000