1. 10 3月, 2009 1 次提交
  2. 27 2月, 2009 1 次提交
  3. 16 2月, 2009 1 次提交
    • T
      net: forcedeth: Fix wake-on-lan regression · 34edaa88
      Tobias Diedrich 提交于
      Commit f55c21fd ("forcedeth: call
      restore mac addr in nv_shutdown path"), which was introduced to fix
      the regression tracked at
      http://bugzilla.kernel.org/show_bug.cgi?id=11358 causes the
      wake-on-lan mac to be reversed in the shutdown path.  Apparently the
      forcedeth situation is rather messy in that the mac we need to
      writeback for a subsequent modprobe to work is exactly the reverse of
      what is needed for proper wake-on-lan.
      
      The following patch explains the situation in the comments and
      makes the call to nv_restore_mac_addr() conditional (only called if
      we are not really going for poweroff).
      
      Tobias Diedrich wrote:
      > Hmm, I had not tried WOL for some time.
      > With 2.6.29-rc3 is see the following behaviour:
      > 
      > State            WOL Behaviour
      > ------------------------------
      > shutdown         reversed MAC
      > disk/shutdown    reversed MAC
      > disk/platform    OK
      > 
      > Apparently nv_restore_mac_addr() restores the MAC in the wrong order
      > for WOL (at least for my PCI_DEVICE_ID_NVIDIA_NVENET_15).  platform
      > works, because the MAC is not touched in the nv_suspend() path.
      > 
      > A possible fix might be to only call nv_restore_mac_addr() if
      > system_state != SYSTEM_POWER_OFF.
      
      With the following patch:
      shutdown         OK
      disk/shutdown    OK
      disk/platform    OK
      kexec            OK
      Signed-off-by: NTobias Diedrich <ranma+kernel@tdiedrich.de>
      Tested-by: NPhilipp Matthias Hahn <pmhahn@titan.lahn.de>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      34edaa88
  4. 07 2月, 2009 5 次提交
  5. 06 2月, 2009 5 次提交
  6. 22 1月, 2009 1 次提交
  7. 11 1月, 2009 4 次提交
  8. 26 12月, 2008 1 次提交
  9. 23 12月, 2008 1 次提交
  10. 08 12月, 2008 1 次提交
    • W
      netdevice: Kill netdev->priv · b74ca3a8
      Wang Chen 提交于
      This is the last shoot of this series.
      After I removing all directly reference of netdev->priv, I am killing
      "priv" of "struct net_device" and fixing relative comments/docs.
      
      Anyone will not be allowed to reference netdev->priv directly.
      If you want to reference the memory of private data, use netdev_priv()
      instead.
      If the private data is not allocted when alloc_netdev(), use
      netdev->ml_priv to point that memory after you creating that private
      data.
      Signed-off-by: NWang Chen <wangchen@cn.fujitsu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b74ca3a8
  11. 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
  12. 21 11月, 2008 1 次提交
  13. 20 11月, 2008 1 次提交
  14. 04 11月, 2008 1 次提交
  15. 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
  16. 28 10月, 2008 1 次提交
  17. 25 9月, 2008 1 次提交
  18. 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
  19. 06 9月, 2008 1 次提交
  20. 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
  21. 07 8月, 2008 4 次提交
  22. 30 7月, 2008 1 次提交
  23. 15 7月, 2008 1 次提交
  24. 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
  25. 28 6月, 2008 1 次提交
  26. 11 6月, 2008 1 次提交