1. 07 6月, 2009 2 次提交
  2. 02 6月, 2009 1 次提交
  3. 02 5月, 2009 1 次提交
  4. 27 4月, 2009 1 次提交
  5. 09 4月, 2009 1 次提交
    • D
      forcedeth: Use napi_complete() not __napi_complete(). · 6c2da9c2
      David S. Miller 提交于
      It's not enough that forcedeth's interrupts are disabled,
      local cpu interrupts have to unconditionally be off
      when we remove the device from the poll list.
      
      Based upon a crash report from
      Alexander Beregalov <a.beregalov@gmail.com>:
      
       WARNING: at lib/list_debug.c:30 __list_add+0x89/0x90()
       Hardware name:
       list_add corruption. prev->next should be next (c06ea834), but was
      f70244c8. (prev=c06ea834).
       Modules linked in: w83627hf hwmon_vid i2c_nforce2
       Pid: 1436, comm: portageq Not tainted 2.6.30-rc1 #1
       Call Trace:
        [<c0129d73>] warn_slowpath+0x73/0xd0
        [<c03c6008>] ? __kfree_skb+0x38/0x90
        [<c03f9b06>] ? tcp_data_snd_check+0x26/0xe0
        [<c03fd67f>] ? tcp_rcv_established+0x2bf/0x5e0
        [<c040557a>] ? tcp_v4_rcv+0x47a/0x610
        [<c014cebd>] ? print_lock_contention_bug+0x1d/0x110
        [<c044a967>] ? _spin_unlock+0x27/0x50
        [<c040564b>] ? tcp_v4_rcv+0x54b/0x610
        [<c02d86f9>] __list_add+0x89/0x90
        [<c03ccff9>] __napi_schedule+0x29/0x60
        [<c036946d>] e1000_intr+0xbd/0x1a0
        [<c015c5de>] handle_IRQ_event+0x3e/0x120
        [<c015e190>] handle_fasteoi_irq+0x60/0xd0
        [<c0104fd4>] handle_irq+0x34/0x60
        [<c015f748>] ? rcu_irq_enter+0x8/0x40
        [<c0104b29>] do_IRQ+0x39/0xa0
        [<c03c592c>] ? skb_release_head_state+0x2c/0x60
        [<c01034ee>] common_interrupt+0x2e/0x34
        [<c02d8601>] ? list_del+0x21/0x90
        [<c014e54b>] ? trace_hardirqs_on+0xb/0x10
        [<c03cd4da>] __napi_complete+0x1a/0x30
        [<c0381971>] nv_napi_poll+0xd1/0x5c0
        [<c014e54b>] ? trace_hardirqs_on+0xb/0x10
        [<c03cd5f6>] net_rx_action+0x106/0x1b0
        [<c012e8df>] __do_softirq+0x6f/0x100
        [<c044a967>] ? _spin_unlock+0x27/0x50
        [<c015e1b8>] ? handle_fasteoi_irq+0x88/0xd0
        [<c012e9cd>] do_softirq+0x5d/0x70
        [<c012ebad>] irq_exit+0x7d/0xa0
        [<c0104b32>] do_IRQ+0x42/0xa0
        [<c012e9b7>] ? do_softirq+0x47/0x70
        [<c01034ee>] common_interrupt+0x2e/0x34
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6c2da9c2
  6. 07 4月, 2009 2 次提交
  7. 10 3月, 2009 13 次提交
  8. 27 2月, 2009 1 次提交
  9. 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
  10. 07 2月, 2009 5 次提交
  11. 06 2月, 2009 5 次提交
  12. 22 1月, 2009 1 次提交
  13. 11 1月, 2009 4 次提交
  14. 26 12月, 2008 1 次提交
  15. 23 12月, 2008 1 次提交