1. 29 5月, 2009 1 次提交
  2. 27 5月, 2009 3 次提交
    • M
      bfin_mac: fix build error due to net_device_ops convert · b63dc8fe
      Mike Frysinger 提交于
      The previous commit "convert to net_device_ops" broke the Blackfin MAC
      driver as it declared the new structure before the function it used:
        CC      drivers/net/bfin_mac.o
      drivers/net/bfin_mac.c:984: error: ‘bfin_mac_close’ undeclared here (not in a function)
      make[1]: *** [drivers/net/bfin_mac.o] Error 1
      Signed-off-by: NMike Frysinger <vapier@gentoo.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b63dc8fe
    • A
      atlx: move modinfo data from atlx.h to atl1.c · 5ad18900
      Alex Chiang 提交于
      Both atl1.c and atl2.c include atlx.h, which defines some modinfo
      stuff. But atl2.c seems like it doesn't want the modinfo data
      from atlx.h, as it defines its own.
      
      Running modinfo on atl2.ko, we get conflicting information:
      
      $ /sbin/modinfo drivers/net/atlx/atl2.ko | egrep "version|description|author"
      version:        2.2.3
      description:    Atheros Fast Ethernet Network Driver
      author:         Atheros Corporation <xiong.huang@atheros.com>, Chris Snook <csnook@redhat.com>
      version:        2.1.3
      author:         Xiong Huang <xiong.huang@atheros.com>, 	Chris Snook <csnook@redhat.com>, Jay Cliburn <jcliburn@gmail.com>
      
      Move the modinfo data out of atlx.h and into atl1.c to eliminate
      the confusion:
      
      $ /sbin/modinfo drivers/net/atlx/atl1.ko | egrep "version|description|author"
      version:        2.1.3
      author:         Xiong Huang <xiong.huang@atheros.com>, 	Chris Snook <csnook@redhat.com>, Jay Cliburn <jcliburn@gmail.com>
      description:    Atheros L1 Gigabit Ethernet Driver
      
      $ /sbin/modinfo drivers/net/atlx/atl2.ko | egrep "version|description|author"
      version:        2.2.3
      description:    Atheros Fast Ethernet Network Driver
      author:         Atheros Corporation <xiong.huang@atheros.com>, Chris Snook <csnook@redhat.com>
      Reported-by: NScott Scriven <scott.scriven@hp.com>
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Acked-by: NJay Cliburn <jcliburn@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5ad18900
    • X
      gianfar: fix babbling rx error event bug · 18a36c1a
      Xiaotian Feng 提交于
      Gianfar interrupt handler uses IEVENT_ERR_MASK to check and handle errors.
      Babbling RX error (IEVENT_BABR) should be included in IEVENT_ERROR_MASK.
      Otherwise if BABR is raised, it never gets handled nor cleared, and an
      interrupt storm results. This has been observed to happen on sending a
      burst of ethernet frames to a gianfar based board.
      Signed-off-by: NXiaotian Feng <xiaotian.feng@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      18a36c1a
  3. 26 5月, 2009 2 次提交
    • D
      r8169: avoid losing MSI interrupts · f11a377b
      David Dillow 提交于
      The 8169 chip only generates MSI interrupts when all enabled event
      sources are quiescent and one or more sources transition to active. If
      not all of the active events are acknowledged, or a new event becomes
      active while the existing ones are cleared in the handler, we will not
      see a new interrupt.
      
      The current interrupt handler masks off the Rx and Tx events once the
      NAPI handler has been scheduled, which opens a race window in which we
      can get another Rx or Tx event and never ACK'ing it, stopping all
      activity until the link is reset (ifconfig down/up). Fix this by always
      ACK'ing all event sources, and loop in the handler until we have all
      sources quiescent.
      Signed-off-by: NDavid Dillow <dave@thedillows.org>
      Tested-by: NMichael Buesch <mb@bu3sch.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f11a377b
    • F
      mac8390: fix regression caused during net_device_ops conversion · 217cbfa8
      Finn Thain 提交于
      Changeset ca17584b ("mac8390: update
      to net_device_ops") broke mac8390 by adding 8390.o to the link. That
      meant that lib8390.c was included twice, once in mac8390.c and once in
      8390.c, subject to different macros. This patch reverts that by
      avoiding the wrappers in 8390.c. They seem to be of no value since
      COMPAT_NET_DEV_OPS is going away soon.
      
      Tested with a Kinetics EtherPort card.
      Signed-off-by: NFinn Thain <fthain@telegraphics.com.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      217cbfa8
  4. 25 5月, 2009 1 次提交
  5. 22 5月, 2009 2 次提交
  6. 21 5月, 2009 7 次提交
  7. 19 5月, 2009 1 次提交
  8. 18 5月, 2009 5 次提交
    • R
      Neterion: *FIFO1_DMA_ERR set twice, should 2nd be *FIFO2_DMA_ERR? · d77dd8d2
      roel kluin 提交于
      FIFO1_DMA_ERR is set twice, the second should be FIFO2_DMA_ERR.
      Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
      Acked-by: NRam Vepa <ram.vepa@neterion.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d77dd8d2
    • G
      mv643xx_eth: fix PPC DMA breakage · eb0519b5
      Gabriel Paubert 提交于
      After 2.6.29, PPC no more admits passing NULL to the dev parameter of
      the DMA API. The result is a BUG followed by solid lock-up when the 
      mv643xx_eth driver brings an interface up. The following patch makes 
      the driver work on my Pegasos again; it is mostly a search and replace 
      of NULL by mp->dev->dev.parent in dma allocation/freeing/mapping/unmapping
      functions.
      Signed-off-by: NGabriel Paubert <paubert@iram.es>
      Acked-by: NLennert Buytenhek <buytenh@marvell.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eb0519b5
    • S
      bonding: fix link down handling in 802.3ad mode · 4cd6fe1c
      Stephen Hemminger 提交于
      One of the purposes of bonding is to allow for redundant links, and failover
      correctly if the cable is pulled. If all the members of a bonded device have
      no carrier present, the bonded device itself needs to report no carrier present
      to user space so management tools (like routing daemons) can respond.
      
      Bonding in 802.3ad mode does not work correctly for this because it incorrectly
      chooses a link that is down as a possible aggregator.
      Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4cd6fe1c
    • R
      NET: Meth: Fix unsafe mix of irq and non-irq spinlocks. · a8f492c6
      Ralf Baechle 提交于
      Mixing of normal and irq spinlocks results in the following lockdep messages
      on bootup on IP32:
      
      [...]
      Sending DHCP requests .
      ======================================================
      [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
      2.6.30-rc5-00164-g41baeef #30
      ------------------------------------------------------
      swapper/1 [HC0[0]:SC0[1]:HE0:SE0] is trying to acquire:
       (&priv->meth_lock){+.+...}, at: [<ffffffff8026388c>] meth_tx+0x48/0x43c
      
      and this task is already holding:
       (_xmit_ETHER#2){+.-...}, at: [<ffffffff802d3a00>] __qdisc_run+0x118/0x30c
      which would create a new lock dependency:
       (_xmit_ETHER#2){+.-...} -> (&priv->meth_lock){+.+...}
      
      but this new dependency connects a SOFTIRQ-irq-safe lock:
       (_xmit_ETHER#2){+.-...}
      ... which became SOFTIRQ-irq-safe at:
        [<ffffffff80061458>] __lock_acquire+0x784/0x1a14
        [<ffffffff800627e0>] lock_acquire+0xf8/0x150
        [<ffffffff800128d0>] _spin_lock+0x30/0x44
        [<ffffffff802d2b88>] dev_watchdog+0x70/0x398
        [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248
        [<ffffffff8003da5c>] __do_softirq+0xec/0x208
        [<ffffffff8003dbd8>] do_softirq+0x60/0xe4
        [<ffffffff8003dda0>] irq_exit+0x54/0x9c
        [<ffffffff80004420>] ret_from_irq+0x0/0x4
        [<ffffffff80004720>] r4k_wait+0x20/0x40
        [<ffffffff80015418>] cpu_idle+0x30/0x60
        [<ffffffff804cd934>] start_kernel+0x3ec/0x404
      
      to a SOFTIRQ-irq-unsafe lock:
       (&priv->meth_lock){+.+...}
      ... which became SOFTIRQ-irq-unsafe at:
      ...  [<ffffffff800614f8>] __lock_acquire+0x824/0x1a14
        [<ffffffff800627e0>] lock_acquire+0xf8/0x150
        [<ffffffff800128d0>] _spin_lock+0x30/0x44
        [<ffffffff80263f20>] meth_reset+0x118/0x2d8
        [<ffffffff8026424c>] meth_open+0x28/0x140
        [<ffffffff802c1ae8>] dev_open+0xe0/0x18c
        [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4
        [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28
        [<ffffffff80012e68>] do_one_initcall+0x58/0x170
        [<ffffffff804cd190>] kernel_init+0x98/0x104
        [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
      
      other info that might help us debug this:
      
      2 locks held by swapper/1:
       #0:  (rcu_read_lock){.+.+..}, at: [<ffffffff802c0954>] dev_queue_xmit+0x1e0/0x4b0
       #1:  (_xmit_ETHER#2){+.-...}, at: [<ffffffff802d3a00>] __qdisc_run+0x118/0x30c
      
      the SOFTIRQ-irq-safe lock's dependencies:
      -> (_xmit_ETHER#2){+.-...} ops: 0 {
         HARDIRQ-ON-W at:
                              [<ffffffff800614d0>] __lock_acquire+0x7fc/0x1a14
                              [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                              [<ffffffff800128d0>] _spin_lock+0x30/0x44
                              [<ffffffff802d2b88>] dev_watchdog+0x70/0x398
                              [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248
                              [<ffffffff8003da5c>] __do_softirq+0xec/0x208
                              [<ffffffff8003dbd8>] do_softirq+0x60/0xe4
                              [<ffffffff8003dda0>] irq_exit+0x54/0x9c
                              [<ffffffff80004420>] ret_from_irq+0x0/0x4
                              [<ffffffff80004720>] r4k_wait+0x20/0x40
                              [<ffffffff80015418>] cpu_idle+0x30/0x60
                              [<ffffffff804cd934>] start_kernel+0x3ec/0x404
         IN-SOFTIRQ-W at:
                              [<ffffffff80061458>] __lock_acquire+0x784/0x1a14
                              [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                              [<ffffffff800128d0>] _spin_lock+0x30/0x44
                              [<ffffffff802d2b88>] dev_watchdog+0x70/0x398
                              [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248
                              [<ffffffff8003da5c>] __do_softirq+0xec/0x208
                              [<ffffffff8003dbd8>] do_softirq+0x60/0xe4
                              [<ffffffff8003dda0>] irq_exit+0x54/0x9c
                              [<ffffffff80004420>] ret_from_irq+0x0/0x4
                              [<ffffffff80004720>] r4k_wait+0x20/0x40
                              [<ffffffff80015418>] cpu_idle+0x30/0x60
                              [<ffffffff804cd934>] start_kernel+0x3ec/0x404
         INITIAL USE at:
                             [<ffffffff80061570>] __lock_acquire+0x89c/0x1a14
                             [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                             [<ffffffff800128d0>] _spin_lock+0x30/0x44
                             [<ffffffff802d2b88>] dev_watchdog+0x70/0x398
                             [<ffffffff800433b8>] run_timer_softirq+0x1a8/0x248
                             [<ffffffff8003da5c>] __do_softirq+0xec/0x208
                             [<ffffffff8003dbd8>] do_softirq+0x60/0xe4
                             [<ffffffff8003dda0>] irq_exit+0x54/0x9c
                             [<ffffffff80004420>] ret_from_irq+0x0/0x4
                             [<ffffffff80004720>] r4k_wait+0x20/0x40
                             [<ffffffff80015418>] cpu_idle+0x30/0x60
                             [<ffffffff804cd934>] start_kernel+0x3ec/0x404
       }
       ... key      at: [<ffffffff80cf93f0>] netdev_xmit_lock_key+0x8/0x1c8
      
      the SOFTIRQ-irq-unsafe lock's dependencies:
      -> (&priv->meth_lock){+.+...} ops: 0 {
         HARDIRQ-ON-W at:
                              [<ffffffff800614d0>] __lock_acquire+0x7fc/0x1a14
                              [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                              [<ffffffff800128d0>] _spin_lock+0x30/0x44
                              [<ffffffff80263f20>] meth_reset+0x118/0x2d8
                              [<ffffffff8026424c>] meth_open+0x28/0x140
                              [<ffffffff802c1ae8>] dev_open+0xe0/0x18c
                              [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4
                              [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28
                              [<ffffffff80012e68>] do_one_initcall+0x58/0x170
                              [<ffffffff804cd190>] kernel_init+0x98/0x104
                              [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
         SOFTIRQ-ON-W at:
                              [<ffffffff800614f8>] __lock_acquire+0x824/0x1a14
                              [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                              [<ffffffff800128d0>] _spin_lock+0x30/0x44
                              [<ffffffff80263f20>] meth_reset+0x118/0x2d8
                              [<ffffffff8026424c>] meth_open+0x28/0x140
                              [<ffffffff802c1ae8>] dev_open+0xe0/0x18c
                              [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4
                              [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28
                              [<ffffffff80012e68>] do_one_initcall+0x58/0x170
                              [<ffffffff804cd190>] kernel_init+0x98/0x104
                              [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
         INITIAL USE at:
                             [<ffffffff80061570>] __lock_acquire+0x89c/0x1a14
                             [<ffffffff800627e0>] lock_acquire+0xf8/0x150
                             [<ffffffff800128d0>] _spin_lock+0x30/0x44
                             [<ffffffff80263f20>] meth_reset+0x118/0x2d8
                             [<ffffffff8026424c>] meth_open+0x28/0x140
                             [<ffffffff802c1ae8>] dev_open+0xe0/0x18c
                             [<ffffffff802c1268>] dev_change_flags+0xd8/0x1d4
                             [<ffffffff804e7770>] ip_auto_config+0x1d4/0xf28
                             [<ffffffff80012e68>] do_one_initcall+0x58/0x170
                             [<ffffffff804cd190>] kernel_init+0x98/0x104
                             [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
       }
       ... key      at: [<ffffffff80cf6ce8>] __key.32424+0x0/0x8
      
      stack backtrace:
      Call Trace:
      [<ffffffff8000ed0c>] dump_stack+0x8/0x34
      [<ffffffff80060b74>] check_usage+0x470/0x4a0
      [<ffffffff80060c34>] check_irq_usage+0x90/0x130
      [<ffffffff80061f78>] __lock_acquire+0x12a4/0x1a14
      [<ffffffff800627e0>] lock_acquire+0xf8/0x150
      [<ffffffff80012a0c>] _spin_lock_irqsave+0x60/0x84
      [<ffffffff8026388c>] meth_tx+0x48/0x43c
      [<ffffffff802d3a38>] __qdisc_run+0x150/0x30c
      [<ffffffff802c0aa8>] dev_queue_xmit+0x334/0x4b0
      [<ffffffff804e7e6c>] ip_auto_config+0x8d0/0xf28
      [<ffffffff80012e68>] do_one_initcall+0x58/0x170
      [<ffffffff804cd190>] kernel_init+0x98/0x104
      [<ffffffff8001520c>] kernel_thread_helper+0x10/0x18
      
      ..... timed out!
      IP-Config: Retrying forever (NFS root)...
      Sending DHCP requests ., OK
      [...]
      
      Fixed by converting all locks to irq locks.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      Tested-by: NAndrew Randrianasulu <randrik_a@yahoo.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a8f492c6
    • Y
      mlx4_en: Fix not deleted napi structures · 72876a60
      Yevgeny Petrilin 提交于
      Napi structures are being created each time we open a port, but when
      the port is closed the napi structure is only disabled but not removed.
      This bug caused hang while removing the driver.
      Signed-off-by: NYevgeny Petrilin <yevgenyp@mellanox.co.il>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      72876a60
  9. 17 5月, 2009 3 次提交
  10. 16 5月, 2009 13 次提交
  11. 15 5月, 2009 2 次提交