1. 12 Jan, 2005 4 commits
  2. 10 Jan, 2005 1 commit
  3. 07 Jan, 2005 1 commit
  4. 06 Jan, 2005 3 commits
  5. 03 Jan, 2005 4 commits
    • Tom Coughlan's avatar
      [PATCH] aacraid: remove aac_handle_aif · 56d46dd5
      Tom Coughlan authored
      When aac_command_thread detects an adapter event (AifCmdDriverNotify or
      AifCmdEventNotify) it calls aac_handle_aif. This routine sets a flag,
      calls fib_adapter_complete, and returns. The bad news is that after the
      return, aac_command_thread continues to process the command and calls
      fib_adapter_complete again.
      
      Under some circumstances this causes the driver to take the device
      offline. In my case, it happens with a Dell CERC SATA with a RAID 5 in
      the "building" state:
      
      aacraid: Host adapter reset request. SCSI hang ?
      aacraid: Host adapter appears dead
      scsi: Device offlined - not ready after error recovery: host 0 channel 0
      id 0 lun 0
      SCSI error : <0 0 0 0> return code = 0x6000000
      end_request: I/O error, dev sda, sector 976537592
      
      Mark Salyzyn says the intent is for aac_handle_aif to perform some
      plug-n-play actions based on the adapter event, and return, leaving the
      command completion to the caller.
      
      The attached patch solves the problem by removing aac_handle_aif
      entirely, since it is wrong, and there is currently no code in the
      driver to actually do anything with these events.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      56d46dd5
    • Christoph Hellwig's avatar
      [PATCH] gdth: cleanup compat clutter · e22ccab2
      Christoph Hellwig authored
      This patch
      
      - removes support for 2.2.x and 2.4.x without the full dma API
        (<= 2.4.13 or 2.4.9rh)
      - makes sure we don't acquire or release unessecary locks around
        ->scsi_done - it's a small BH/softirq that doesn't care about
        the callers lock state
      - cleans up the 2.4 vs 2.6 compat code a little
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      e22ccab2
    • Randy Dunlap's avatar
      [PATCH] gdth: reduce large on-stack locals · 96f252ac
      Randy Dunlap authored
      gdth is the fourth-highest stack user (for a single function)
      in 2.6.10-rc3-bk-recent (sizes on x86-32).
      
      Reduce stack usage in gdth driver:
      reduce ioc_rescan() from 1564 to 52 bytes;
      reduce ioc_hdrlist() from 1528 to 24 bytes;
      reduce gdth_get_info() from 1076 to 300 bytes;
      Signed-off-by: default avatarRandy Dunlap <rddunlap@osdl.org>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      96f252ac
    • Jens Axboe's avatar
      [PATCH] gdth buggy page mapping · 53b2a84a
      Jens Axboe authored
      Just tripped over a bug report for the SUSE kernel where gdth would
      crash on a 32G opteron, turned out that the gdth_internal_copy() sg
      handling was really buggy. After fixing this I wanted to do the same for
      mainline, but I can see that a vain attempt was already made to fix it.
      Unfortunately it wasn't complete, and on top of that there's room for
      improvement.
      
      The current code is buggy on highmem, as page_address() will not yield a
      valid kernel address causing a NULL pointer dereference. The current
      code also doesn't unmap the sg list if it sees a NULL sl->page. In fact,
      the whole sg mapping looks really strange, why on earth would you be
      mapping the sglist for dma when you are only going to copy from it?
      
      This patch corrects both errors - correctly maps in the page, and kills
      the pci_map_sg/pci_unmap_sg calls completely. If someone could test
      this, that would be great.
      Signed-off-by: default avatarJens Axboe <axboe@suse.de>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      53b2a84a
  6. 01 Jan, 2005 3 commits
  7. 31 Dec, 2004 9 commits
  8. 01 Jan, 2005 5 commits
  9. 31 Dec, 2004 3 commits
  10. 30 Dec, 2004 1 commit
  11. 31 Dec, 2004 3 commits
  12. 30 Dec, 2004 3 commits