1. 06 May, 2004 7 commits
    • Nitin A. Kamble's avatar
      [PATCH] mxcsr patch for i386 & x86-64 · 681b6bf7
      Nitin A. Kamble authored
      This enables proper mxcsr register masking: the magic mask "0xffbf"
      is not necessarily correct for all CPU's, and there is an architected
      way to discover the proper MXCSR feature bits by examining the fxsave
      results.
      
      Please refer to IA32 Software Developer's Manual, Volume 1, Section
      11.6.6 for more details.
      681b6bf7
    • Petr Vandrovec's avatar
      [PATCH] ncpfs data corruption when using large TCP transfers · 91ddedbe
      Petr Vandrovec authored
      ncpfs was forgetting to update iovec's iov_base field whenever partial
      transmission occured. This was causing data corruption during large
      (60kB) writes.
      
      The code now also passes copy of iovec to the sock_sendmsg, so it does
      not rely on network stack updating (or not updating) passed iovec in
      case of success (or failure).
      91ddedbe
    • Andrew Morton's avatar
      [PATCH] b44 driver needs mii · cd19fd0f
      Andrew Morton authored
      cd19fd0f
    • Paul Wagland's avatar
      [PATCH] bug fix for megaraid memory leak · 4c76a6b2
      Paul Wagland authored
      I was going through the code looking for bits and pieces to pull across
      into the new LSI Logic beta megaraid driver /sys fs code and came across
      this one.
      
      LSI Logic have already fixed this issue for the 2.4 driver, and the new
      beta driver does not use the /proc filesystem at all, so no problem
      there.
      
      The problem is that resources are not freed upon certain error
      conditions in the in-kernel megaraid driver, to quote from Lester
      Hightower (who originally found the issue):
      
         "The problem occurs only in the circumstance where one reads one of
          the /proc/megaraid/hba<X>/diskdrives-ch<N> files where the card <X>
          does not have channel <N> on it.  Most people would likely not
          notice this leak in normal operation, but due to the way that we
          monitor our MegaRaid cards in our company (we read these /proc
          entries every 180s) so we found the leak rather quickly, and
          unpleasantly (when your kernel eats all your RAM)."
      
      Anyway, here is the fix, compiled and tested OK for me.
      4c76a6b2
    • Bartlomiej Zolnierkiewicz's avatar
      [PATCH] ide-disk.c: write cache handling fixes · f0d61324
      Bartlomiej Zolnierkiewicz authored
      From: Alan Cox <alan@redhat.com>, Arjan van de Ven <arjanv@redhat.com>
      
       - calculate drive->wcache for non-removable disks too
       - flush the cache before unlocking the door on removable media,
         otherwise you have a small race with the human
      f0d61324
    • Stephen Rothwell's avatar
      [PATCH] PPC64 iSeries: replace semaphores with completions · fe61f793
      Stephen Rothwell authored
      This replaces some usages of sempahores on the stack with completions.
      
      We think we have had at least one bug report that could be caused by the
      inherent race in the semaphore usage.
      fe61f793
    • Venkatesh Pallipadi's avatar
      [PATCH] bug in bigsmp CPU bringup · d1a1ac7b
      Venkatesh Pallipadi authored
      There is an bug in bigsmp sub-architecture, due to which it will not
      enable all the CPUs when the BIOS-APICIDs are not 0 to n-1 (where n is
      total number of CPUs). Particularly, only 2 CPU comes up on a system
      that has 4 CPUs with BIOS APICID as (0, 1, 6, 7).=20
      
      The bug is root caused to check_apicid_present(bit) call in smpboot.c,
      when bigsmp is expecting apicid in place of bit.
      check_apicid_present(bit) in bigsmp subarchitecture checks the bit with
      phys_id_present_map (which is actually map representing all apicids and
      not bit).
      
      One solution is to change check_apicid_present(bit) to
      check_apicid_present(apicid), in smp_boot_cpus().  But, it can affect
      all the other subarchitectures in various subtle ways.  So, here is a
      simple alternate fix (Thanks to Martin Bligh), which solves the above
      problem. 
      
      [ Confirmation from Martin:
      
           Looks fine, it's exactly the same fix we use for Summit.  Since
           we're using the other method instead of the bitmap, this check
           isn't needed, so we can just bypass it.  This way also has the
           great advantage of being isolated to the bigsmp subarch, so it only
           needs testing there ;-)
       ]
      d1a1ac7b
  2. 05 May, 2004 18 commits
  3. 04 May, 2004 4 commits
  4. 05 May, 2004 1 commit
  5. 04 May, 2004 10 commits