1. 04 12月, 2008 1 次提交
    • E
      forcedeth: power down phy when interface is down · cb52deba
      Ed Swierk 提交于
      Bring the physical link down when the interface is down by placing the PHY
      in power-down state, unless WOL is enabled.  This mirrors the behavior of
      other drivers including e1000 and tg3.
      
      Without the patch, ifconfig down leaves the physical link up, which confuses
      datacenter users who expect the link lights both on the NIC and the switch to
      go out when they bring an interface down.
      
      Furthermore, even though the phy is powered on, autonegotiation stops working,
      so a normally gigabit link might suddenly become 100 Mbit half-duplex when the
      interface goes down, and become gigabit when it comes up again.
      
      Ayaz said:
      
        I would not include this patch until further testing is performed.  NVIDIA
        MCP chips use 3rd party PHY vendors.  By powering down the phy, it could
        have adverse affects on certain phys.
      
      Arthur Jones said:
      
        I just ran across this patch.  Tested on a Marvell 88E1121R (GigE PHY)
        and works great.  This is a very important feature for me.
      Signed-off-by: NEd Swierk <eswierk@arastra.com>
      Tested-by: NArthur Jones <ajones@riverbed.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cb52deba
  2. 21 11月, 2008 1 次提交
  3. 20 11月, 2008 1 次提交
  4. 04 11月, 2008 1 次提交
  5. 02 11月, 2008 1 次提交
    • J
      forcdeth: increase max_interrupt_work · dccd547e
      Joe Korty 提交于
      This eliminates the following often-generated warning from my 64 bit
      Opteron SMP test stand:
      
      	eth0: too many iterations (6) in nv_nic_irq
      
      According to the web, the problem is that the forcedeth driver has a
      too-low value for max_interrupt_work.  Grepping the kernel I see that
      forcedeth has the second lowest value of all ethernet drivers (ie, 6).
      Most are in the 20-40 range.  So this patch increases this a bit, from 6
      to 15 (at 15 forcedeth becomes the driver with third-lowest
      max_interrupt_work value).
      
      My test stand, which used to print out the above warnings repetitively
      whenever it was under heavy net load, no longer does so.
      Signed-off-by: NJoe Korty <joe.korty@ccur.com>
      Cc: Ayaz Abdulla <aabdulla@nvidia.com>
      Cc: Jeff Garzik <jeff@garzik.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      dccd547e
  6. 28 10月, 2008 1 次提交
  7. 25 9月, 2008 1 次提交
  8. 19 9月, 2008 1 次提交
    • Y
      forcedeth: call restore mac addr in nv_shutdown path · f55c21fd
      Yinghai Lu 提交于
      after
      
      | commit f735a2a1
      | Author: Tobias Diedrich <ranma+kernel@tdiedrich.de>
      | Date:   Sun May 18 15:02:37 2008 +0200
      |
      |    [netdrvr] forcedeth: setup wake-on-lan before shutting down
      |
      |    When hibernating in 'shutdown' mode, after saving the image the suspend hook
      |    is not called again.
      |    However, if the device is in promiscous mode, wake-on-lan will not work.
      |    This adds a shutdown hook to setup wake-on-lan before the final shutdown.
      |
      |    Signed-off-by: Tobias Diedrich <ranma+kernel@tdiedrich.de>
      |    Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
      
      my servers with nvidia ck804 and mcp55 will reverse mac address with kexec.
      
      it turns out that we need to restore the mac addr in nv_shutdown().
      
      [akpm@linux-foundation.org: fix typo in printk]
      Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
      Cc: Tobias Diedrich <ranma+kernel@tdiedrich.de>
      Cc: Ayaz Abdulla <aabdulla@nvidia.com>
      Cc: Jeff Garzik <jeff@garzik.org>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      f55c21fd
  9. 06 9月, 2008 1 次提交
  10. 27 8月, 2008 1 次提交
    • A
      forcedeth: fix checksum flag · edcfe5f7
      Ayaz Abdulla 提交于
      Fix the checksum feature advertised in device flags.  The hardware support
      TCP/UDP over IPv4 and TCP/UDP over IPv6 (without IPv6 extension headers).
      However, the kernel feature flags do not distinguish IPv6 with/without
      extension headers.
      
      Therefore, the driver needs to use NETIF_F_IP_CSUM instead of
      NETIF_F_HW_CSUM since the latter includes all IPv6 packets.
      
      A future patch can be created to check for extension headers and perform
      software checksum calculation.
      Signed-off-by: NAyaz Abdulla <aabdulla@nvidia.com>
      Cc: Jeff Garzik <jgarzik@pobox.com>
      Cc: Manfred Spraul <manfred@colorfullife.com
      Cc: <stable@kernel.org>		[2.6.25.x, 2.6.26.x]
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      edcfe5f7
  11. 07 8月, 2008 4 次提交
  12. 30 7月, 2008 1 次提交
  13. 15 7月, 2008 1 次提交
  14. 04 7月, 2008 1 次提交
    • T
      forcedeth: fix lockdep warning on ethtool -s · 97bff095
      Tobias Diedrich 提交于
      After enabling CONFIG_LOCKDEP and CONFIG_PROVE_LOCKING I get the
      following warning when ethtool -s is first called on one of the
      forcedeth ports:
      
      =================================
      [ INFO: inconsistent lock state ]
      2.6.26-rc4 #28
      ---------------------------------
      inconsistent {in-hardirq-W} -> {hardirq-on-W} usage.
      ethtool/1985 [HC0[0]:SC0[1]:HE1:SE0] takes:
       (&np->lock){++..}, at: [<ffffffffa000c5fd>] nv_set_settings+0xc8/0x3de [forcedeth]
      {in-hardirq-W} state was registered at:
        [<ffffffffffffffff>] 0xffffffffffffffff
      irq event stamp: 3606
      hardirqs last  enabled at (3605): [<ffffffff8068106f>] _spin_unlock_irqrestore+0x3f/0x68
      hardirqs last disabled at (3604): [<ffffffff80680d38>] _spin_lock_irqsave+0x13/0x46
      softirqs last  enabled at (3534): [<ffffffff80246ba5>] __do_softirq+0xbc/0xc5
      softirqs last disabled at (3606): [<ffffffff80680b33>] _spin_lock_bh+0x11/0x41
      
      other info that might help us debug this:
      2 locks held by ethtool/1985:
       #0:  (rtnl_mutex){--..}, at: [<ffffffff80596072>] rtnl_lock+0x12/0x14
       #1:  (_xmit_ETHER){-+..}, at: [<ffffffffa000c5e8>] nv_set_settings+0xb3/0x3de [forcedeth]
      stack backtrace:
      Pid: 1985, comm: ethtool Not tainted 2.6.26-rc4 #28
      Call Trace:
       [<ffffffff8025f190>] print_usage_bug+0x162/0x173
       [<ffffffff8025fa8b>] mark_lock+0x231/0x41f
       [<ffffffff802607cf>] __lock_acquire+0x4e7/0xcac
       [<ffffffff8025fe64>] ? trace_hardirqs_on+0xf1/0x115
       [<ffffffff80272c3a>] ? disable_irq_nosync+0x6f/0x7b
       [<ffffffff80261375>] lock_acquire+0x55/0x6e
       [<ffffffffa000c5fd>] ? :forcedeth:nv_set_settings+0xc8/0x3de
       [<ffffffff80680b15>] _spin_lock+0x2f/0x3c
       [<ffffffffa000c5fd>] :forcedeth:nv_set_settings+0xc8/0x3de
       [<ffffffff8058f8bb>] dev_ethtool+0x186/0xea3
       [<ffffffff8067f446>] ? mutex_lock_nested+0x243/0x275
       [<ffffffff8025df2b>] ? debug_mutex_free_waiter+0x46/0x4a
       [<ffffffff8067f469>] ? mutex_lock_nested+0x266/0x275
       [<ffffffff8058e1ce>] dev_ioctl+0x4eb/0x600
       [<ffffffff8068106f>] ? _spin_unlock_irqrestore+0x3f/0x68
       [<ffffffff80580f91>] sock_ioctl+0x1f5/0x202
       [<ffffffff802a322e>] vfs_ioctl+0x2a/0x77
       [<ffffffff802a34d6>] do_vfs_ioctl+0x25b/0x270
       [<ffffffff806807b6>] ? trace_hardirqs_on_thunk+0x35/0x3a
       [<ffffffff802a352d>] sys_ioctl+0x42/0x65
       [<ffffffff8021fffb>] system_call_after_swapgs+0x7b/0x80
      
      This is caused by the following snippet in nv_set_settings:
      
      	netif_carrier_off(dev);
      	if (netif_running(dev)) {
      		nv_disable_irq(dev);
      		netif_tx_lock_bh(dev);
      		spin_lock(&np->lock);
      		/* stop engines */
      		nv_stop_rxtx(dev);
      		spin_unlock(&np->lock);
      		netif_tx_unlock_bh(dev);
      	}
      
      Because of nv_disable_irq this is probably not really a problem
      though (I guess) and replacing the spin_lock with spin_lock_irqsave
      could keep interrupts disabled for a longer period of time because
      of delays in nv_stop_rx and nv_stop_tx.
      Signed-off-by: NTobias Diedrich <ranma+kernel@tdiedrich.de>
      Cc: Ayaz Abdulla <aabdulla@nvidia.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      97bff095
  15. 28 6月, 2008 1 次提交
  16. 11 6月, 2008 1 次提交
  17. 31 5月, 2008 3 次提交
  18. 22 5月, 2008 1 次提交
  19. 25 4月, 2008 2 次提交
  20. 18 4月, 2008 1 次提交
  21. 12 4月, 2008 1 次提交
    • A
      forcedeth: mac address fix · a376e79c
      Ayaz Abdulla 提交于
      This critical patch fixes a mac address issue recently introduced.  If the
      device's mac address was in correct order and the flag
      NVREG_TRANSMITPOLL_MAC_ADDR_REV was set, during nv_remove the flag would get
      cleared.  During next load, the mac address would get reversed because the
      flag is missing.
      
      As it has been indicated previously, the flag is cleared across a low power
      transition.  Therefore, the driver should set the mac address back into the
      reversed order when clearing the flag.
      
      Also, the driver should set back the flag after a low power transition to
      protect against kexec command calling nv_probe a second time.
      Signed-off-by: NAyaz Abdulla <aabdulla@nvidia.com>
      Cc: "Yinghai Lu" <yhlu.kernel@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      a376e79c
  22. 05 4月, 2008 1 次提交
  23. 29 3月, 2008 1 次提交
    • I
      forcedeth: fix locking bug with netconsole · bd6ca637
      Ingo Molnar 提交于
      While using netconsole on forcedeth, lockdep noticed the following locking
      bug:
      
      =================================
      [ INFO: inconsistent lock state ]
      2.6.24-rc6 #6
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ---------------------------------
      inconsistent {softirq-on-W} -> {in-softirq-W} usage.
      udevd/719 [HC0[0]:SC1[1]:HE1:SE0] takes:
       (_xmit_ETHER){-+..}, at: [<c043062e>] dev_watchdog+0x1c/0xb9
      {softirq-on-W} state was registered at:
        [<c0147f67>] mark_held_locks+0x4e/0x66
        [<c014810e>] trace_hardirqs_on+0xfe/0x136
        [<c048ae63>] _spin_unlock_irq+0x22/0x42
        [<c02ec617>] nv_start_xmit_optimized+0x347/0x37a
        [<c042c80d>] netpoll_send_skb+0xa4/0x147
        [<c042d4a6>] netpoll_send_udp+0x238/0x242
        [<c02f44f6>] write_msg+0x6d/0x9b
        [<c012c129>] __call_console_drivers+0x4e/0x5a
        [<c012c18c>] _call_console_drivers+0x57/0x5b
        [<c012c2dd>] release_console_sem+0x11c/0x1b9
        [<c012caeb>] register_console+0x1eb/0x1f3
        [<c06ae673>] init_netconsole+0x119/0x15f
        [<c069149b>] kernel_init+0x147/0x294
        [<c01058cb>] kernel_thread_helper+0x7/0x10
        [<ffffffff>] 0xffffffff
      irq event stamp: 950
      hardirqs last  enabled at (950): [<c048ae63>] _spin_unlock_irq+0x22/0x42
      hardirqs last disabled at (949): [<c048aaf7>] _spin_lock_irq+0xc/0x38
      softirqs last  enabled at (0): [<c012a29c>] copy_process+0x375/0x126d
      softirqs last disabled at (947): [<c0106d43>] do_softirq+0x61/0xc6
      
      other info that might help us debug this:
      no locks held by udevd/719.
      
      stack backtrace:
      Pid: 719, comm: udevd Not tainted 2.6.24-rc6 #6
       [<c0105c46>] show_trace_log_lvl+0x12/0x25
       [<c01063ec>] show_trace+0xd/0x10
       [<c010670c>] dump_stack+0x57/0x5f
       [<c0147505>] print_usage_bug+0x10a/0x117
       [<c0147c38>] mark_lock+0x121/0x402
       [<c01488b6>] __lock_acquire+0x3d1/0xb64
       [<c0149405>] lock_acquire+0x4e/0x6a
       [<c048a99b>] _spin_lock+0x23/0x32
       [<c043062e>] dev_watchdog+0x1c/0xb9
       [<c0133e4a>] run_timer_softirq+0x133/0x193
       [<c0130907>] __do_softirq+0x78/0xed
       [<c0106d43>] do_softirq+0x61/0xc6
       =======================
      eth1: link down
      
      The fix is to disable/restore irqs instead of disable/enable.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Cc: Ayaz Abdulla <aabdulla@nvidia.com>
      Cc: Jeff Garzik <jeff@garzik.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      bd6ca637
  24. 26 3月, 2008 1 次提交
  25. 17 3月, 2008 1 次提交
    • A
      forcedeth: limit tx to 16 · 3b446c3e
      Ayaz Abdulla 提交于
      This is a critical patch which adds a workaround for a HW bug. The patch
      will limit the number of outstanding tx packets to 16. Otherwise, the HW
      could send out packets with bad checksums.
      
      The driver will still setup the tx packets into the ring, however, will
      only set the Valid bit on 16 packets at a time.
      Signed-off-by: NAyaz Abdulla <aabdulla@nvidia.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      3b446c3e
  26. 12 2月, 2008 2 次提交
  27. 06 2月, 2008 3 次提交
  28. 03 2月, 2008 4 次提交