1. 15 Jan, 2006 1 commit
  2. 12 Jan, 2006 1 commit
    • ODonnell, Michael's avatar
      [PATCH] corruption during e100 MDI register access · ac7c6669
      ODonnell, Michael authored
      We have identified two related bugs in the e100 driver.
      
      Both bugs are related to manipulation of the MDI control register.
      
      The first problem is that the Ready bit is being ignored when writing to
      the Control register; we noticed this because the Linux bonding driver
      would occasionally come to the spurious conclusion that the link was down
      when querying Link State.  It turned out that by failing to wait for a
      previous command to complete it was selecting what was essentially a random
      register in the MDI register set.  When we added code that waits for the
      Ready bit (as shown in the patch file below) all such problems ceased.
      
      The second problem is that, although access to the MDI registers involves
      multiple steps which must not be intermixed, nothing was defending against
      two or more threads attempting simultaneous access.  The most obvious
      situation where such interference could occur involves the watchdog versus
      ioctl paths, but there are probably others, so we recommend the locking
      shown in our patch file.
      Signed-off-by: default avatarMichael O'Donnell <Michael.ODonnell@stratus.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jeff Garzik <jgarzik@pobox.com>
      Cc: John Ronciak <john.ronciak@intel.com>
      Cc: Ganesh Venkatesan <ganesh.venkatesan@intel.com>
      Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarJeff Garzik <jgarzik@pobox.com>
      ac7c6669
  3. 18 Nov, 2005 1 commit
    • Jesse Brandeburg's avatar
      [PATCH] e100: re-enable microcode with more useful defaults · 2afecc04
      Jesse Brandeburg authored
      For the four versions of hardware that we (currently) support microcode
      download on, the default configuration of our receive interrupt mitigation
      microcode was too aggressive, and caused unnecessary delays when pinging,
      and low(er) throughput on single connection latency sensitive performance
      tests.
      
      This code adds microcode support, and sets the defaults to more reasonable
      settings. It also explains the functionality in the code in more detail.
      Compile and load tested, shows expected behavior for slight delay of ping
      packets (1-2ms) when ucode is loaded, and decent interrupt moderation for
      small packets, while maintaining good throughput.
      Signed-off-by: default avatarJesse Brandeburg <jesse.brandeburg@intel.com>
      Signed-off-by: default avatarJeff Garzik <jgarzik@pobox.com>
      2afecc04
  4. 08 Nov, 2005 1 commit
  5. 11 Oct, 2005 1 commit
    • Jeff Garzik's avatar
      e100: revert CPU cycle saver microcode, it causes severe problems · 875521dd
      Jeff Garzik authored
      for certain NICs
      
      Reverting 685fac63:
      > [PATCH] e100: CPU cycle saver microcode
      >
      >
      > Add cpu cycle saver microcode to 8086:{1209/1229} other than ICH devices.
      >
      > Signed-off-by: Mallikarjuna R Chilakala <mallikarjuna.chilakala@intel.com>
      > Signed-off-by: Ganesh Venkatesan <ganesh.venkatesan@intel.com>
      > Signed-off-by: John Ronciak <john.ronciak@intel.com>
      > Signed-off-by: Jeff Garzik <jgarzik@pobox.com>
      875521dd
  6. 14 Sep, 2005 2 commits
  7. 25 Aug, 2005 6 commits
  8. 28 Jun, 2005 1 commit
  9. 27 Jun, 2005 3 commits
  10. 26 Jun, 2005 1 commit
  11. 13 May, 2005 6 commits
  12. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4