1. 20 Feb, 2009 2 commits
    • Steve Glendinning's avatar
      smsc9420: fix another postfixed timeout · 9df8f4e3
      Steve Glendinning authored
      Roel Kluin recently fixed several instances where variables reach -1,
      but 0 is tested afterwards.  This patch fixes another, so the timeout
      will be correctly detected and a warning printed.
      Signed-off-by: default avatarSteve Glendinning <steve.glendinning@smsc.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9df8f4e3
    • Inaky Perez-Gonzalez's avatar
      wimax/i2400m: driver loads firmware v1.4 instead of v1.3 · 494ef10e
      Inaky Perez-Gonzalez authored
      This is a one liner change to have the driver use by default the v1.4
      of the i2400m firmware instead of v1.3. The v1.4 version of the
      firmware has been submitted to David Woodhouse for inclusion in the
      linux-firmware tree and it is already available at
      http://linuxwimax.org/Download.
      
      The reason for this change is that the 1.3 release of the user space
      software and firmware has a few issues that will make it difficult to
      use with currently deployed commercial networks such as Xohm and
      Clearwire.
      
      As well, the new 1.4 release of the user space software (which matches
      the 1.4 firmware) has intermitent issues with the 1.3 firmware.
      
      The 1.4 release in http://linuxwimax.org/Download has been widely
      deployed and tested with the codebase in 2.6.29-rc, the 1.4 firmware
      and the 1.4 user space components.
      
      We understand it is quite late in the rc process for such a change,
      but would like to ask for the change to be taken into consideration.
      
      Alternatively, a user could always force feed a 1.4 firmware into a
      driver that doesn't have this modification by:
      
      $ cd /lib/firmware
      $ mv i2400m-fw-usb-1.3.sbcf i2400m-fw-usb-1.3.real.sbcf
      $ ln -sf i2400m-fw-usb-1.4.sbc i2400m-fw-usb-1.3.sbcf
      Signed-off-by: default avatarInaky Perez-Gonzalez <inaky@linux.intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      494ef10e
  2. 19 Feb, 2009 8 commits
  3. 18 Feb, 2009 1 commit
    • David S. Miller's avatar
      net: Kill skb_truesize_check(), it only catches false-positives. · 92a0acce
      David S. Miller authored
      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: default avatarDavid S. Miller <davem@davemloft.net>
      92a0acce
  4. 16 Feb, 2009 1 commit
    • Tobias Diedrich's avatar
      net: forcedeth: Fix wake-on-lan regression · 34edaa88
      Tobias Diedrich authored
      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: default avatarTobias Diedrich <ranma+kernel@tdiedrich.de>
      Tested-by: default avatarPhilipp Matthias Hahn <pmhahn@titan.lahn.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      34edaa88
  5. 13 Feb, 2009 21 commits
  6. 11 Feb, 2009 7 commits