1. 10 Nov, 2007 4 commits
    • Stephen Hemminger's avatar
      sky2: longer PHY delay · af043aa5
      Stephen Hemminger authored
      Increse phy delay and handle I/O errors.
      Signed-off-by: default avatarStephen Hemminger <shemminger@linux-foundation.org>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      af043aa5
    • Stephen Hemminger's avatar
      sky2: status ring race fix · ab5adecb
      Stephen Hemminger authored
      The D-Link PCI-X board (and maybe others) can lie about status
      ring entries. It seems it will update the register for last status
      index before completing the DMA for the ring entry. To avoid reading
      stale data, zap the old entry and check.
      Signed-off-by: default avatarStephen Hemminger <shemminger@linux-foundation.org>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      ab5adecb
    • Stephen Hemminger's avatar
      sky2: enable PCI config writes · ac93a394
      Stephen Hemminger authored
      On some boards, PCI configuration space access is turned off by default.
      The 2.6.24 driver doesn't turn it on, and should have.
      Signed-off-by: default avatarStephen Hemminger <shemminger@linux-foundation.org>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
      ac93a394
    • David Miller's avatar
      [FUTEX] Fix address computation in compat code. · 3c5fd9c7
      David Miller authored
      compat_exit_robust_list() computes a pointer to the
      futex entry in userspace as follows:
      
      	(void __user *)entry + futex_offset
      
      'entry' is a 'struct robust_list __user *', and
      'futex_offset' is a 'compat_long_t' (typically a 's32').
      
      Things explode if the 32-bit sign bit is set in futex_offset.
      
      Type promotion sign extends futex_offset to a 64-bit value before
      adding it to 'entry'.
      
      This triggered a problem on sparc64 running 32-bit applications which
      would lock up a cpu looping forever in the fault handling for the
      userspace load in handle_futex_death().
      
      Compat userspace runs with address masking (wherein the cpu zeros out
      the top 32-bits of every effective address given to a memory operation
      instruction) so the sparc64 fault handler accounts for this by
      zero'ing out the top 32-bits of the fault address too.
      
      Since the kernel properly uses the compat_uptr interfaces, kernel side
      accesses to compat userspace work too since they will only use
      addresses with the top 32-bit clear.
      
      Because of this compat futex layer bug we get into the following loop
      when executing the get_user() load near the top of handle_futex_death():
      
      1) load from address '0xfffffffff7f16bd8', FAULT
      2) fault handler clears upper 32-bits, processes fault
         for address '0xf7f16bd8' which succeeds
      3) goto #1
      
      I want to thank Bernd Zeimetz, Josip Rodin, and Fabio Massimo Di Nitto
      for their tireless efforts helping me track down this bug.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3c5fd9c7
  2. 09 Nov, 2007 36 commits