1. 27 Aug, 2008 1 commit
    • Ayaz Abdulla's avatar
      forcedeth: fix checksum flag · edcfe5f7
      Ayaz Abdulla authored
      
      
      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: default avatarAyaz 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      edcfe5f7
  2. 07 Aug, 2008 4 commits
  3. 29 Jul, 2008 1 commit
  4. 15 Jul, 2008 1 commit
  5. 04 Jul, 2008 1 commit
    • Tobias Diedrich's avatar
      forcedeth: fix lockdep warning on ethtool -s · 97bff095
      Tobias Diedrich authored
      
      
      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: default avatarTobias Diedrich <ranma+kernel@tdiedrich.de>
      Cc: Ayaz Abdulla <aabdulla@nvidia.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      97bff095
  6. 28 Jun, 2008 1 commit
  7. 10 Jun, 2008 1 commit
  8. 30 May, 2008 3 commits
  9. 22 May, 2008 1 commit
  10. 25 Apr, 2008 2 commits
  11. 17 Apr, 2008 1 commit
  12. 12 Apr, 2008 1 commit
    • Ayaz Abdulla's avatar
      forcedeth: mac address fix · a376e79c
      Ayaz Abdulla authored
      
      
      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: default avatarAyaz Abdulla <aabdulla@nvidia.com>
      Cc: "Yinghai Lu" <yhlu.kernel@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
      a376e79c
  13. 04 Apr, 2008 1 commit
  14. 28 Mar, 2008 1 commit
    • Ingo Molnar's avatar
      forcedeth: fix locking bug with netconsole · bd6ca637
      Ingo Molnar authored
      
      
      While using netconsole on forcedeth, lockdep noticed the following locking
      bug:
      
      =================================
      [ INFO: inconsistent lock state ]
      2.6.24-rc6 #6
      Signed-off-by: default avatarIngo 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: default avatarIngo Molnar <mingo@elte.hu>
      Cc: Ayaz Abdulla <aabdulla@nvidia.com>
      Cc: Jeff Garzik <jeff@garzik.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      bd6ca637
  15. 25 Mar, 2008 1 commit
  16. 17 Mar, 2008 1 commit
    • Ayaz Abdulla's avatar
      forcedeth: limit tx to 16 · 3b446c3e
      Ayaz Abdulla authored
      
      
      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: default avatarAyaz Abdulla <aabdulla@nvidia.com>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      3b446c3e
  17. 11 Feb, 2008 2 commits
  18. 06 Feb, 2008 3 commits
  19. 03 Feb, 2008 6 commits
  20. 28 Jan, 2008 1 commit
    • Al Viro's avatar
      forcedeth endianness bugs · 5bb7ea26
      Al Viro authored
      
      
      * misannotation: struct register_test members are actually host-endian
      * bug: cpu_to_le64(n) >> 32 instead of cpu_to_le32(n >> 32) in setting
      ->bufhigh and similar for ->buflow (take low bits, _then_ convert to
      little-endian, not the other way round).
      * bug: setup_hw_rings() should not convert to little-endian at all (we
      feed the result to writel(), not store in shared data structure), let
      alone try to play with shifting and masking little-endian values.  Introduced
      when setup_hw_rings() went in, screwed both 64bit case and the old code for
      32bit rings it had replaced.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      5bb7ea26
  21. 09 Jan, 2008 1 commit
    • Björn Steinbrink's avatar
      [FORCEDETH]: Fix reversing the MAC address on suspend. · 2e3884b5
      Björn Steinbrink authored
      
      
      For cards that initially have the MAC address stored in reverse order,
      the forcedeth driver uses a flag to signal whether the address was
      already corrected, so that it is not reversed again on a subsequent
      probe.
      
      Unfortunately this flag, which is stored in a register of the card,
      seems to get lost during suspend, resulting in the MAC address being
      reversed again. To fix that, the MAC address needs to be written back
      in reversed order before we suspend and the flag needs to be reset.
      
      The flag is still required because at least kexec will never write
      back the reversed address and thus needs to know what state the card
      is in.
      Signed-off-by: default avatarBjörn Steinbrink <B.Steinbrink@gmx.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2e3884b5
  22. 23 Nov, 2007 2 commits
  23. 25 Oct, 2007 1 commit
  24. 17 Oct, 2007 2 commits