1. 24 2月, 2009 3 次提交
  2. 22 2月, 2009 3 次提交
  3. 20 2月, 2009 7 次提交
  4. 19 2月, 2009 8 次提交
  5. 18 2月, 2009 1 次提交
    • D
      net: Kill skb_truesize_check(), it only catches false-positives. · 92a0acce
      David S. Miller 提交于
      A long time ago we had bugs, primarily in TCP, where we would modify
      skb->truesize (for TSO queue collapsing) in ways which would corrupt
      the socket memory accounting.
      
      skb_truesize_check() was added in order to try and catch this error
      more systematically.
      
      However this debugging check has morphed into a Frankenstein of sorts
      and these days it does nothing other than catch false-positives.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      92a0acce
  6. 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
  7. 13 2月, 2009 17 次提交