summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2010-10-28cxgb3: Fix panic in free_tx_desc()Krishna Kumar1-1/+3
I got a few of these panics (on 2.6.36-rc7) when running high number of netperf sessions: BUG: unable to handle kernel paging request at 0000100000000000 IP: [<ffffffff813125f0>] skb_release_data+0xa0/0xd0 Oops: 0000 [#1] SMP Pid: 2155, comm: vhost-2115 Not tainted 2.6.36-rc7-ORG #1 49Y6512 /System x3650 M2 -[7947AC1]- RIP: 0010:[<ffffffff813125f0>] [<ffffffff813125f0>] skb_release_data+0xa0/0xd0 RSP: 0018:ffff880001803738 EFLAGS: 00010206 RAX: ffff880179b0fc00 RBX: ffff880178b441c0 RCX: 0000000000000000 RSP: 0018:ffff880001803738 EFLAGS: 00010206 RAX: ffff880179b0fc00 RBX: ffff880178b441c0 RCX: 0000000000000000 RDX: ffff880179b0fd40 RSI: 0000000000000000 RDI: 0000100000000000 RBP: ffff880001803748 R08: 0000000000000001 R09: ffff88017f117000 R10: ffff88017b990608 R11: ffff88017f117090 R12: ffff880178b441c0 R13: ffff88017f117090 R14: 0000000000000000 R15: ffff880178b441c0 FS: 0000000000000000(0000) GS:ffff880001800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000100000000000 CR3: 000000017ea64000 CR4: 00000000000026e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process vhost-2115 (pid: 2155, threadinfo ffff88017d872000, task ffff88017e954680) Stack: ffff880178b441c0 0000000000000007 ffff880001803768 ffffffff81312119 <0> 0000000000000000 0000000000000002 ffff880001803778 ffffffff813121f9 <0> ffff880001803818 ffffffffa012d14c ffffffffa02de076 ffff880001803700 Call Trace: <IRQ> [<ffffffff81312119>] __kfree_skb+0x19/0xa0 [<ffffffff813121f9>] kfree_skb+0x19/0x40 [<ffffffffa012d14c>] free_tx_desc+0x2fc/0x350 [cxgb3] [<ffffffffa02de076>] ? vhost_poll_wakeup+0x16/0x20 [vhost_net] [<ffffffffa01323db>] t3_eth_xmit+0x28b/0x380 [cxgb3] [<ffffffff8131ce47>] dev_hard_start_xmit+0x377/0x5a0 [<ffffffff81335a4a>] sch_direct_xmit+0xfa/0x1d0 [<ffffffff8131d1a9>] dev_queue_xmit+0x139/0x450 [<ffffffff81326225>] neigh_resolve_output+0x125/0x340 [<ffffffff8135a77c>] ip_finish_output+0x14c/0x320 [<ffffffff8135a9fe>] ip_output+0xae/0xc0 [<ffffffff8135620f>] ip_forward_finish+0x3f/0x50 [<ffffffff8135641f>] ip_forward+0x1ff/0x400 [<ffffffff81354789>] ip_rcv_finish+0x119/0x3e0 [<ffffffff81354c7d>] ip_rcv+0x22d/0x300 [<ffffffff8131a95b>] __netif_receive_skb+0x29b/0x570 [<ffffffff8131ba70>] ? netif_receive_skb+0x0/0x80 [<ffffffff8131bae8>] netif_receive_skb+0x78/0x80 [<ffffffffa02a96d8>] br_handle_frame_finish+0x198/0x260 [bridge] [<ffffffffa02aebc8>] br_nf_pre_routing_finish+0x238/0x380 [bridge] [<ffffffff813424bc>] ? nf_hook_slow+0x6c/0x100 [<ffffffffa02ae990>] ? br_nf_pre_routing_finish+0x0/0x380 [bridge] [<ffffffffa02afb08>] br_nf_pre_routing+0x698/0x7a0 [bridge] [<ffffffff81342414>] nf_iterate+0x64/0xa0 [<ffffffffa02a9540>] ? br_handle_frame_finish+0x0/0x260 [bridge] [<ffffffff813424bc>] nf_hook_slow+0x6c/0x100 [<ffffffffa02a9540>] ? br_handle_frame_finish+0x0/0x260 [bridge] [<ffffffffa02a9931>] br_handle_frame+0x191/0x240 [bridge] [<ffffffffa02a97a0>] ? br_handle_frame+0x0/0x240 [bridge] [<ffffffff8131a863>] __netif_receive_skb+0x1a3/0x570 [<ffffffff812ef3f6>] ? dma_issue_pending_all+0x76/0xa0 [<ffffffff8131ad32>] process_backlog+0x102/0x200 [<ffffffff8131c2d0>] net_rx_action+0x100/0x220 [<ffffffff810548ef>] __do_softirq+0xaf/0x140 [<ffffffff8100bcdc>] call_softirq+0x1c/0x30 [<ffffffff8100dfc5>] ? do_softirq+0x65/0xa0 [<ffffffff8131c6b8>] netif_rx_ni+0x28/0x30 [<ffffffffa02c305d>] tun_sendmsg+0x2cd/0x4b0 [tun] [<ffffffffa02e01af>] handle_tx+0x1df/0x340 [vhost_net] [<ffffffffa02e0340>] handle_tx_kick+0x10/0x20 [vhost_net] [<ffffffffa02de29b>] vhost_worker+0xbb/0x130 [vhost_net] [<ffffffffa02de1e0>] ? vhost_worker+0x0/0x130 [vhost_net] [<ffffffffa02de1e0>] ? vhost_worker+0x0/0x130 [vhost_net] [<ffffffff81069686>] kthread+0x96/0xa0 [<ffffffff8100bbe4>] kernel_thread_helper+0x4/0x10 [<ffffffff810695f0>] ? kthread+0x0/0xa0 [<ffffffff8100bbe0>] ? kernel_thread_helper+0x0/0x10 Code: 8b 94 24 d0 00 00 00 49 8b 84 24 d8 00 00 00 48 8d 14 10 0f b7 0a 39 d9 7f d1 48 8b 7a 10 48 85 ff 74 20 48 c7 42 10 00 00 00 00 <48> 8b 1f e8 e8 fb ff ff 48 85 db 48 89 df 75 f0 49 8b 84 24 d8 Patch below fixes the panic. cxgb4 and cxgb4vf already have this fix. Signed-off-by: Krishna Kumar <krkumar2@in.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28cxgb3: fix crash due to manipulating queues before registrationNishanth Aravamudan1-1/+1
Along the same lines as "cxgb4: fix crash due to manipulating queues before registration" (8f6d9f40476895571df039b6f1f5230ec7faebad), before commit "net: allocate tx queues in register_netdevice" netif_tx_stop_all_queues and related functions could be used between device allocation and registration but now only after registration. cxgb4 has such a call before registration and crashes now. Move it after register_netdev. Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com> Cc: eric.dumazet@gmail.com Cc: sonnyrao@us.ibm.com Cc: Divy Le Ray <divy@chelsio.com> Cc: Dimitris Michailidis <dm@chelsio.com> Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Tested-by: Nishanth Aravamudan <nacc@us.ibm.com> Acked-by: Divy Le Ray <divy@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-288390: Don't oops on starting dev queuePavel Emelyanov1-1/+0
The __NS8390_init tries to start the device queue before the device is registered. This results in an oops (snipped): [ 2.865493] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 [ 2.866106] IP: [<ffffffffa000602a>] netif_start_queue+0xb/0x12 [8390] [ 2.881267] Call Trace: [ 2.881437] [<ffffffffa000624d>] __NS8390_init+0x102/0x15a [8390] [ 2.881999] [<ffffffffa00062ae>] NS8390_init+0x9/0xb [8390] [ 2.882237] [<ffffffffa000d820>] ne2k_pci_init_one+0x297/0x354 [ne2k_pci] [ 2.882955] [<ffffffff811c7a0e>] local_pci_probe+0x12/0x16 [ 2.883308] [<ffffffff811c85ad>] pci_device_probe+0xc3/0xef [ 2.884049] [<ffffffff8129218d>] driver_probe_device+0xbe/0x14b [ 2.884937] [<ffffffff81292260>] __driver_attach+0x46/0x62 [ 2.885170] [<ffffffff81291788>] bus_for_each_dev+0x49/0x78 [ 2.885781] [<ffffffff81291fbb>] driver_attach+0x1c/0x1e [ 2.886089] [<ffffffff812912ab>] bus_add_driver+0xba/0x227 [ 2.886330] [<ffffffff8129259a>] driver_register+0x9e/0x115 [ 2.886933] [<ffffffff811c8815>] __pci_register_driver+0x50/0xac [ 2.887785] [<ffffffffa001102c>] ne2k_pci_init+0x2c/0x2e [ne2k_pci] [ 2.888093] [<ffffffff81000212>] do_one_initcall+0x7c/0x130 [ 2.888693] [<ffffffff8106d74f>] sys_init_module+0x99/0x1da [ 2.888946] [<ffffffff81002a2b>] system_call_fastpath+0x16/0x1b This happens because the netif_start_queue sets respective bit on the dev->_tx array which is not yet allocated. As far as I understand the code removing the netif_start_queue from __NS8390_init is OK, since queue will be started later on device open. Plz, correct me if I'm wrong. Found in the Dave's current tree, so he's in Cc. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28igbvf: fix panic on loadEmil Tantilov1-4/+4
Introduced by commit:e6484930d7c73d324bccda7d43d131088da697b9 net: allocate tx queues in register_netdevice Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Acked-by: Greg Rose <greg.v.rose@intel.com> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28ixgb: call pci_disable_device in ixgb_removeEmil Tantilov1-0/+1
ixgb fails to work after reload on recent kernels: rmmod ixgb (dev->current_state = PCI_UNKNOWN) modprobe ixgb (pci_enable_device will bail leaving current_state to PCI_UNKNOWN) ifup eth0 do_IRQ: 2.82 No irq handler for vector (irq -1) The issue was exposed by commit fcd097f31a6ee207cc0c3da9cccd2a86d4334785 PCI: MSI: Remove unsafe and unnecessary hardware access which avoids HW writes for power states != PCI_D0 CC: Ben Hutchings <bhutchings@solarflare.com> Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28ixgbe: DCB, fix TX hang occurring in stress condition with PFCJohn Fastabend5-10/+54
The DCB credits refill quantum _must_ be greater than half the max packet size. This is needed to guarantee that TX DMA operations are not attempted during a pause state. Additionally, the min IFG must be set correctly for DCB mode. If a DMA operation is requested unexpectedly during the pause state the HW data store may be corrupted leading to a DMA hang. The DMA hang requires a reset to correct. This fixes the HW configuration to avoid this condition. Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28e1000e: Add check for reset flags before displaying reset messageCarolyn Wyborny1-2/+5
Some parts need to execute resets during normal operation. This flag check ensures that those parts reset without needlessly alarming the user. Other unexpected resets by other parts will dump debug info and message the reset action to the user, as originally intended. Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com> Acked-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Emil Tantilov <emil.s.tantilov@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28e1000e: reset PHY after errors detectedCarolyn Wyborny3-0/+63
Some errors can be induced in the PHY via environmental testing (specifically extreme temperature changes and electro static discharge testing), and in the case of the PHY hanging due to this input, this detects the problem and resets to continue. This issue only applies to 82574 silicon. Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com> Tested-by: Emil Tantilov <emil.s.tantilov@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28pch_gbe: Select MII.David S. Miller1-0/+1
Reported-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28igb: Fix unused variable warning.Jesse Gross1-1/+0
Commit eab6d18d "vlan: Don't check for vlan group before vlan_tx_tag_present" removed the need for the adapter variable in igb_xmit_frame_ring_adv(). This removes the variable as well to avoid the compiler warning. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Jesse Gross <jesse@nicira.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28ehea: Fixing statisticsBreno Leitao2-6/+28
(Applied over Eric's "ehea: fix use after free" patch) Currently ehea stats are broken. The bytes counters are got from the hardware, while the packets counters are got from the device driver. Also, the device driver counters are resetted during the the down process, and the hardware aren't, causing some weird numbers. This patch just consolidates the packets and bytes on the device driver. Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com> Reviewed-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-28bonding: Fix lockdep warning after bond_vlan_rx_register()Jarek Poplawski1-2/+2
Fix lockdep warning: [ 52.991402] ====================================================== [ 52.991511] [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ] [ 52.991569] 2.6.36-04573-g4b60626-dirty #65 [ 52.991622] ------------------------------------------------------ [ 52.991696] ip/4842 [HC0[0]:SC0[4]:HE1:SE0] is trying to acquire: [ 52.991758] (&bond->lock){++++..}, at: [<efe4d300>] bond_set_multicast_list+0x60/0x2c0 [bonding] [ 52.991966] [ 52.991967] and this task is already holding: [ 52.992008] (&bonding_netdev_addr_lock_key){+.....}, at: [<c04e5530>] dev_mc_sync+0x50/0xa0 [ 52.992008] which would create a new lock dependency: [ 52.992008] (&bonding_netdev_addr_lock_key){+.....} -> (&bond->lock){++++..} [ 52.992008] [ 52.992008] but this new dependency connects a SOFTIRQ-irq-safe lock: [ 52.992008] (&(&mc->mca_lock)->rlock){+.-...} [ 52.992008] ... which became SOFTIRQ-irq-safe at: [ 52.992008] [<c0272beb>] __lock_acquire+0x96b/0x1960 [ 52.992008] [<c027415e>] lock_acquire+0x7e/0xf0 [ 52.992008] [<c05f356d>] _raw_spin_lock_bh+0x3d/0x50 [ 52.992008] [<c0584e40>] mld_ifc_timer_expire+0xf0/0x280 [ 52.992008] [<c024cee6>] run_timer_softirq+0x146/0x310 [ 52.992008] [<c024591d>] __do_softirq+0xad/0x1c0 [ 52.992008] [ 52.992008] to a SOFTIRQ-irq-unsafe lock: [ 52.992008] (&bond->lock){++++..} [ 52.992008] ... which became SOFTIRQ-irq-unsafe at: [ 52.992008] ... [<c0272c3b>] __lock_acquire+0x9bb/0x1960 [ 52.992008] [<c027415e>] lock_acquire+0x7e/0xf0 [ 52.992008] [<c05f36b8>] _raw_write_lock+0x38/0x50 [ 52.992008] [<efe4cbe4>] bond_vlan_rx_register+0x24/0x70 [bonding] [ 52.992008] [<c0598010>] register_vlan_dev+0xc0/0x280 [ 52.992008] [<c0599f3a>] vlan_newlink+0xaa/0xd0 [ 52.992008] [<c04ed4b4>] rtnl_newlink+0x404/0x490 [ 52.992008] [<c04ece35>] rtnetlink_rcv_msg+0x1e5/0x220 [ 52.992008] [<c050424e>] netlink_rcv_skb+0x8e/0xb0 [ 52.992008] [<c04ecbac>] rtnetlink_rcv+0x1c/0x30 [ 52.992008] [<c0503bfb>] netlink_unicast+0x24b/0x290 [ 52.992008] [<c0503e37>] netlink_sendmsg+0x1f7/0x310 [ 52.992008] [<c04cd41c>] sock_sendmsg+0xac/0xe0 [ 52.992008] [<c04ceb80>] sys_sendmsg+0x130/0x230 [ 52.992008] [<c04cf04e>] sys_socketcall+0xde/0x280 [ 52.992008] [<c0202d10>] sysenter_do_call+0x12/0x36 [ 52.992008] [ 52.992008] other info that might help us debug this: ... [ Full info at netdev: Wed, 27 Oct 2010 12:24:30 +0200 Subject: [BUG net-2.6 vlan/bonding] lockdep splats ] Use BH variant of write_lock(&bond->lock) (as elsewhere in bond_main) to prevent this dependency. Fixes commit f35188faa0fbabefac476536994f4b6f3677380f [v2.6.36] Reported-by: Eric Dumazet <eric.dumazet@gmail.com> Tested-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com> Acked-by: Eric Dumazet <eric.dumazet@gmail.com> Cc: Jay Vosburgh <fubar@us.ibm.com>
2010-10-27caif-u5500: Build config for CAIF shared mem driverAmarnath Revanna2-0/+11
Signed-off-by: Sjur Braendeland <sjur.brandeland@stericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-27caif-u5500: CAIF shared memory mailbox interfaceAmarnath Revanna1-0/+129
Signed-off-by: Sjur Braendeland <sjur.brandeland@stericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-27caif-u5500: CAIF shared memory transport protocolsjur.brandeland@stericsson.com1-0/+744
Signed-off-by: Sjur Braendeland <sjur.brandeland@stericsson.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-27drivers/isdn: delete double assignmentJulia Lawall2-5/+3
Delete successive assignments to the same location. In the first case, the hscx array has two elements, so change the assignment to initialize the second one. In the second case, the two assignments are simply identical. Furthermore, neither is necessary, because the effect of the assignment is only visible in the next line, in the assignment in the if test. The patch inlines the right hand side value in the latter assignment and pulls that assignment out of the if test. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression i; @@ *i = ...; i = ...; // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-27drivers/net/typhoon.c: delete double assignmentJulia Lawall1-1/+1
Delete successive assignments to the same location. The current definition does not initialize the respRing structure, which has the same type as the cmdRing structure, so initialize that one instead. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression i; @@ *i = ...; i = ...; // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Acked-by: David Dillow <dave@thedillows.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-27drivers/net/sb1000.c: delete double assignmentJulia Lawall1-3/+3
The other code around these duplicated assignments initializes the 0 1 2 and 3 elements of an array, so change the initialization of the rx_session_id array to do the same. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression i; @@ *i = ...; i = ...; // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-27qlcnic: define valid vlan id rangeSony Chacko1-1/+1
4095 vlan id is reserved and should not be use. Signed-off-by: Sony Chacko <sony.chacko@qlogic.com> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-27qlcnic: reduce rx ring sizeSony Chacko3-20/+21
If eswitch is enabled, rcv ring size can be reduce, as physical port is partition-ed. Signed-off-by: Sony Chacko <sony.chacko@qlogic.com> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-27qlcnic: fix mac learningamit salecha2-0/+6
In failover bonding case, same mac address can be programmed on other slave function. Fw will delete old entry (original func) associated with that mac address. Need to reporgram mac address, if failover again happen to original function. Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-27ehea: fix use after freeEric Dumazet1-5/+5
ehea_start_xmit() dereferences skb after its freeing in ehea_xmit3() to get vlan tags. Move the offending block before the potential ehea_xmit3() call. Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-27qlge: bugfix: Restoring the vlan setting.Ron Mercer1-0/+17
Signed-off-by: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com> Signed-off-by: Ron Mercer <ron.mercer@qlogic.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-27be2net: Schedule/Destroy worker thread in probe()/remove() rather than ↵Somnath Kotur1-4/+18
open()/close() When async mcc compls are rcvd on an i/f that is down (and so interrupts are disabled) they just lie unprocessed in the compl queue.The compl queue can eventually get filled up and cause the BE to lock up.The fix is to use be_worker to reap mcc compls when the i/f is down.be_worker is now launched in be_probe() and canceled in be_remove(). Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-27gianfar: Fix crashes on RX path (Was Re: [Bugme-new] [Bug 19692] New: ↵Jarek Poplawski1-3/+3
linux-2.6.36-rc5 crash with gianfar ethernet at full line rate traffic) The rx_recycle queue is global per device but can be accesed by many napi handlers at the same time, so it needs full skb_queue primitives (with locking). Otherwise, various crashes caused by broken skbs are possible. This patch resolves, at least partly, bugzilla bug 19692. (Because of some doubts that there could be still something around which is hard to reproduce my proposal is to leave this bug opened for a month.) Fixes commit: 0fd56bb5be6455d0d42241e65aed057244665e5e ("gianfar: Add support for skb recycling") Reported-by: emin ak <eminak71@gmail.com> Tested-by: emin ak <eminak71@gmail.com> Signed-off-by: Jarek Poplawski <jarkao2@gmail.com> CC: Andy Fleming <afleming@freescale.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-26drivers/atm/eni.c: Remove multiple uses of KERN_<level>Joe Perches1-3/+4
Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-26tg3: Do not call device_set_wakeup_enable() under spin_lock_bhRafael J. Wysocki1-5/+5
The tg3 driver calls device_set_wakeup_enable() under spin_lock_bh, which causes a problem to happen after the recent core power management changes, because this function can sleep now. Fix this by moving the device_set_wakeup_enable() call out of the spin_lock_bh-protected area. Reported-by: Maxim Levitsky <maximlevitsky@gmail.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-26Merge branch 'master' of ↵David S. Miller13-100/+215
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6
2010-10-26can: mcp251x: fix reception of standard RTR framesMarc Kleine-Budde1-0/+3
This patch sets the missing CAN_RTR_FLAG if a standard RTR frame is received. (For extended frames the CAN_RTR_FLAG was already set correctly.) Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-26can: flexcan: fix use after free of privMarc Kleine-Budde1-1/+2
The priv is part of the memory allocated by alloc_candev(). This patch moved the free it after last usage of priv. Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-26drivers/net: sgiseeq: fix return on errorNicolas Kaiser1-1/+1
If we continue on error, we'd likely free the IRQ that we didn't get, right? Signed-off-by: Nicolas Kaiser <nikai@nikai.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-26pch_can: depends on PCIRandy Dunlap1-1/+1
Fix pch_can build when CONFIG_PCI is not enabled. It uses pci interfaces and data structures, so it should depend on PCI. drivers/net/can/pch_can.c:1044: error: implicit declaration of function 'pci_enable_msi' drivers/net/can/pch_can.c:1079: error: implicit declaration of function 'pci_disable_msi' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-26tms380tr: Use mdelay() in tms380tr_wait().David S. Miller1-1/+1
This driver tries to do up to half-second udelay() calls, which overflows on x86-64. Reported-by: Andi Kleen <andi@firstfloor.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-25mlx4_en: Fix out of bounds array accessEli Cohen1-0/+11
When searching for a free entry in either mlx4_register_vlan() or mlx4_register_mac(), and there is no free entry, the loop terminates without updating the local variable free thus causing out of array bounds access. Fix this by adding a proper check outside the loop. Signed-off-by: Eli Cohen <eli@mellanox.co.il> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-25macb: Don't re-enable interrupts while in polling modeJoshua Hoke1-11/+16
On a busy network, the macb driver could get stuck in the interrupt handler, quickly triggering the watchdog, due to a confluence of factors: 1. macb_poll re-enables interrupts unconditionally, even when it will be called again because it exhausted its rx budget 2. macb_interrupt only disables interrupts after scheduling macb_poll, but scheduling fails when macb_poll is already scheduled because it didn't call napi_complete 3. macb_interrupt loops until the interrupt status register is clear, which will never happen in this case if the driver doesn't disable the RX interrupt Since macb_interrupt runs in interrupt context, this effectively locks up the machine, triggering the hardware watchdog. This issue was readily reproducible on a flooded network with a modified 2.6.27.48 kernel. The same problem appears to still be in the 2.6.36-rc8 driver code, so I am submitting this patch against that version. I have not tested this version of the patch except to make sure the kernel compiles. Signed-off-by: Joshua Hoke <joshua.hoke@sixnet.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-25be2net: Fix CSO for UDP packetsSomnath Kotur1-12/+8
We're setting skb->ip_summed to CHECKSUM_NONE for all non-TCP pkts, making the stack recompute checksum.This is a bug for UDP pkts for which cso must be used. Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-25be2net: Call netif_carier_off() after register_netdev()Somnath Kotur1-1/+1
Calling netif_carrier_off before register_netdev was causing the network interface to miss a linkwatch pending event leading to an inconsistent state if the link is not up when interface is initialized.This is now invoked after register_netdev. Signed-off-by: Somnath Kotur <somnath.kotur@emulex.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-25cxgb3: fix device opening error pathDivy Le Ray1-3/+5
Only negative return from bind_qsets() should be considered an error and propagated. It fixes an issue reported by IBM on P Series platform. Signed-off-by: Divy Le Ray <divy@chelsio.com> Tested-by: Nishanth Aravamudan <nacc@us.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2010-10-25iwlwifi: quiet a noisy printkDon Fry1-1/+2
Timing issues in microcode for some devices can cause a compressed BA to be sent to the driver prior to returning any a-MPDU notification. Traces show RTS-CTS is exchanged and then the timer fires which causes an empty BA to be sent which acknowledges nothing. This results in a noisy printk. Only print the message if the bitmap is non-zero. Signed-off-by: Don Fry <donald.h.fry@intel.com> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-10-25ath9k: resume aggregation immediately after a hardware resetFelix Fietkau3-4/+4
Since aggregation is usually triggered by tx completion, a hardware reset (because of beacon stuck, tx hang or baseband hang) can significantly delay the transmission of the next AMPDU (until the next tx completion event). Fix this by rescheduling aggregation after such a reset. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Cc: stable@kernel.org Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-10-25carl9170: fix scheduling while atomicChristian Lamparter1-1/+1
This patch fixes the following mishap: BUG: scheduling while atomic: wpa_supplicant/4164/0x00000002 Modules linked in: carl9170 mac80211 [...] Pid: 4164, comm: wpa_supplicant Not tainted 2.6.36-wl+ #119 Call Trace: [<c13779a9>] ? schedule+0x349/0x4c0 [<c13780d6>] ? schedule_timeout+0x106/0x1e0 [<c1037f50>] ? process_timeout+0x0/0x10 [<c1377e8d>] ? wait_for_common+0x9d/0x140 [<c1029110>] ? default_wake_function+0x0/0x10 [<f80c6080>] ? carl9170_exec_cmd+0xf0/0x250 [carl9170] [<f80c695e>] ? carl9170_set_mac_reg+0x5e/0x70 [carl9170] [<f80c3f76>] ? carl9170_op_add_interface+0x176/0x310 [carl9170] [...] rcu_read_unlock() call was erroneously placed after the sync. function carl9170_mod_virtual_mac. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-10-25b43: N-PHY: fix infinite-loop-typoRafał Miłecki1-1/+1
Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-10-25wl1251: fix module namesGrazvydas Ignotas1-3/+5
The wl1251 move accidently renamed wl1251_sdio and wl1251_spi modules to just sdio and spi. Restore proper module names. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Acked-by: Kalle Valo <kvalo@adurom.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-10-25ath9k: fix handling of rate control probe framesFelix Fietkau1-0/+6
The ath9k aggregation code was already checking the rate control probe flag to prevent starting an aggregate frame with a sampling rate. What was missing was closing an aggregate before adding a probing frame to it. Without that, rate control cannot have precise control over probing, which delays using faster rates when the channel conditions improve. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-10-25ath9k: fix crash in ath_update_survey_statsFelix Fietkau1-0/+3
If ah->curchan is uninitialized, the channel index is bogus, which leads to invalid memory access when the cycle counters are updated. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-10-25ath9k_hw: Fix divide by zero cases in paprd.Senthil Balasubramanian1-5/+9
We are not handling all divide by zero cases in paprd. Add additional checks for divide by zero cases in papard. This patch has fixes intended for kernel 2.6.36. Cc: stable@kernel.org Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-10-25ath9k_hw: Fix TX carrier leakage for IEEE compliance on AR9003 2.2Luis R. Rodriguez1-56/+135
This updates the initvals for the AR9003 2.2 chipsets. The initvals are the initial register values we use for our registers upon hardware reset. This synchs up the initvals to match what our latest recommendation from our systems engineering team. The description of changes in this update: Improves ability to support very strong Rx conditions. Enhances DFS support for AP-mode. Improves performance of Tx carrier leak calibration. Adds support for Japan channel 14 Tx filtering requirements. Improves Tx power accuracy. Impact: Update required to address degraded throughput at very short range. Update required for AP-mode DFS certification. Update required to comply to IEEE Tx carrier leak specification. May not meet expected +/- 2 dB Tx power accuracy without update. The most important fix here would be the TX carrier leakage required to comply with IEEE 802.11 specifications. The group of changes have been tested all together in one release. References: Osprey 2.2 header file ver #33 Checksums: $ ./initvals -f ar9003-2p2 0x000000004a488fc7 ar9300_2p2_radio_postamble 0x0000000046cb1300 ar9300Modes_lowest_ob_db_tx_gain_table_2p2 0x00000000e912711f ar9300Modes_fast_clock_2p2 0x0000000037ac0ee8 ar9300_2p2_radio_core 0x00000000047a7700 ar9300Common_rx_gain_table_merlin_2p2 0x0000000003f783bb ar9300_2p2_mac_postamble 0x00000000301fc841 ar9300_2p2_soc_postamble 0x000000005ec8075f ar9200_merlin_2p2_radio_core 0x0000000083372ffa ar9300_2p2_baseband_postamble 0x00000000c4f59974 ar9300_2p2_baseband_core 0x00000000e20d2e72 ar9300Modes_high_power_tx_gain_table_2p2 0x000000007fd55c70 ar9300Modes_high_ob_db_tx_gain_table_2p2 0x0000000029495000 ar9300Common_rx_gain_table_2p2 0x0000000042cb1300 ar9300Modes_low_ob_db_tx_gain_table_2p2 0x00000000c4739cd6 ar9300_2p2_mac_core 0x000000003521a300 ar9300Common_wo_xlna_rx_gain_table_2p2 0x00000000a15ccf1b ar9300_2p2_soc_preamble 0x0000000029734396 ar9300PciePhy_pll_on_clkreq_disable_L1_2p2 0x000000002d834396 ar9300PciePhy_clkreq_enable_L1_2p2 0x0000000029834396 ar9300PciePhy_clkreq_disable_L1_2p2 $ ./initvals -f ar9003-2p2 | sha1sum 0ceddb5cf66737610fb51f04cf3e9ff71870c7b4 - Cc: stable@kernel.org Cc: Yixiang Li <yixiang.li@atheros.com> Cc: Don Breslin <don.breslin@atheros.com> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-10-25carl9170: fix memory leak issue in async cmd macro wrappersChristian Lamparter1-23/+28
This patch continues where the previous commit: "carl9170: fix async command buffer leak" left off. Similar to carl9170_reboot/carl9170_powersave, the carl9170_async_regwrite* macros would leak the temporary command buffer, if __carl9170_exec_cmd fails to upload the command to the device. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-10-25carl9170: fix async command buffer leakChristian Lamparter1-6/+19
If __carl9170_exec_cmd fails to upload an asynchronous command to the device, the functions: carl9170_reboot and carl9170_powersave will leak the temporary command assembly buffer. Signed-off-by: Christian Lamparter <chunkeey@googlemail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-10-25ath5k: Properly initialize ath_common->cc_lock.Ben Greear1-0/+1
Otherwise, lockdep splats, at the least: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. Pid: 0, comm: swapper Not tainted 2.6.36-rc8-wl+ #32 Call Trace: [<c075d940>] ? printk+0xf/0x17 [<c045507a>] register_lock_class+0x5a/0x29e [<c0456af5>] __lock_acquire+0xa2/0xb8c [<c0455be2>] ? mark_lock+0x1e/0x1de [<c041a540>] ? acpi_get_override_irq+0x85/0x8c [<c0455536>] ? trace_hardirqs_off+0xb/0xd [<c0457639>] lock_acquire+0x5a/0x78 [<f8126835>] ? ath5k_ani_calibration+0x24/0x52b [ath5k] [<c075f6ed>] _raw_spin_lock_bh+0x20/0x2f [<f8126835>] ? ath5k_ani_calibration+0x24/0x52b [ath5k] [<f8126835>] ath5k_ani_calibration+0x24/0x52b [ath5k] [<c0438f99>] ? tasklet_action+0x3b/0xc6 [<f8123c2b>] ath5k_tasklet_ani+0x18/0x22 [ath5k] [<c0438fd1>] tasklet_action+0x73/0xc6 [<c043945f>] __do_softirq+0x86/0x111 [<c0439520>] do_softirq+0x36/0x5a [<c0439659>] irq_exit+0x35/0x69 [<c0403fb9>] do_IRQ+0x86/0x9a [<c04034ee>] common_interrupt+0x2e/0x40 [<c045007b>] ? do_adjtimex+0x223/0x55e [<c0408245>] ? mwait_idle+0x5c/0x6c [<c040227f>] cpu_idle+0x4e/0x6b [<c074b6e9>] rest_init+0x8d/0x92 [<c09758ea>] start_kernel+0x320/0x325 [<c09750d0>] i386_start_kernel+0xd0/0xd7 Signed-off-by: Ben Greear <greearb@candelatech.com> Acked-by: Bruno Randolf <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
generated by cgit v1.2.3 (git 2.39.0) at 2024-12-28 00:14:11 +0300