1. 09 Sep, 2005 3 commits
    • Neil Brown's avatar
      [SCSI] fix possible deadlock in scsi_lib.c · 286f3e13
      Neil Brown authored
        If a filesystem, while writing out data, decides that it is good
      to issue a cache flush on a SCSI drive (or other 'sd' device), it will
      call blkdev_issue_flush which calls ->issue_flush_fn which is
      This calls sd_issue_flush which calls sd_sync_cache, which calls
      This will (as sshdr != NULL) call
      If memory is tight, the presence of GFP_KERNEL may cause write
      requests to be sent to some filesystem to free up memory, however if
      that filesystem is waiting for the issue_flush_fn to complete, you
      could get a deadlock.
      I wonder if it might be more appropriate to use GFP_NOIO as in the
      following patch.
      I wonder if it might be even more appropriate to cope better with a
      kmalloc failure, especially as in this use, sd_sync_cache only will
      use the sense information to print out a more informative error
      Signed-off-by: default avatarNeil Brown <neilb@suse.de>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
    • Alan Stern's avatar
      [SCSI] fix callers of scsi_remove_device() who already hold the scan muted · 903f4fed
      Alan Stern authored
      This patch (as544) adds a private entry point to scsi_remove_device, for
      use when callers already own the scan_mutex.  The appropriate callers are
      modified to use the new entry point.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
    • Alan Stern's avatar
      [SCSI] add missing scan mutex to scsi_scan_target() · e517d313
      Alan Stern authored
      This patch (as543) adds a private entry point to scsi_scan_target, for use
      when the caller already owns the scan_mutex, and updates the kerneldoc for
      that routine (which was badly out-of-date).  It converts scsi_scan_channel
      to use the new entry point.  Lastly, it modifies scsi_get_host_dev to make
      it acquire the scan_mutex, necessary since the routine adds a new
      scsi_device even if it doesn't do any actual scanning.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
  2. 07 Sep, 2005 4 commits
  3. 06 Sep, 2005 11 commits
    • Brett Russ's avatar
      [PATCH] libata: Marvell SATA support (PIO mode) · 20f733e7
      Brett Russ authored
      This is my libata compatible low level driver for the Marvell SATA
      family.  Currently it successfully runs in PIO mode on a 6081 chip.
      EDMA support is in the works and should be done shortly.  Review,
      testing (especially on other flavors of Marvell), comments welcome.
      Signed-off-by: default avatarBrett Russ <russb@emc.com>
      Signed-off-by: default avatarJeff Garzik <jgarzik@pobox.com>
    • Brett Russ's avatar
      [PATCH] libata: fix pio_mask values (take 2) · 7da79312
      Brett Russ authored
      ata_get_mode_mask() uses bits 3 and 4 in the pio_mask to represent PIO
      modes 3 and 4.  The value read from the drive, which reports support
      for PIO3 and PIO4 in bits 0 and 1, is shifted left by 3 bits and OR'd
      with 0x7 (which then corresponds to PIO 2-0 in libata).  Thus, the
      drivers below need adjustments to comply with the way pio_mask is
      used.  I changed the masks from the commented values to all support
      PIO4-0, since the spec mandates that PIO0-2 are supported and there's
      no reason not to support PIO3 IMO.
      Signed-off-by: default avatarBrett Russ <russb@emc.com>
      Signed-off-by: default avatarJeff Garzik <jgarzik@pobox.com>
    • Jeff Garzik's avatar
      [kernel-doc] fix various DocBook build problems/warnings · 344babaa
      Jeff Garzik authored
      Most serious is fixing include/sound/pcm.h, which breaks the DocBook
      The other stuff is just filling in things that cause warnings.
    • James Bottomley's avatar
      [SCSI] quieten messages on scsi_execute commands · 3173d8c3
      James Bottomley authored
      scsi_io_completion() can be a bit noisy about certain conditions.
      Previously this wasn't a problem for internally generated commands,
      since they never hit it.  However, since we do all SCSI commands via
      bios, now they do.  user CD testers like magicdev are now getting not
      ready messages every time they touch the CD to see if there's anything
      in it.
      Fix this by making all scsi_execute commands REQ_QUIET and making
      scsi_finish_io() not say anything for REQ_QUIET.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
    • Christoph Hellwig's avatar
    • Christoph Hellwig's avatar
    • Christoph Hellwig's avatar
      [SCSI] fix SCSI_IOCTL_PROBE_HOST · 32993523
      Christoph Hellwig authored
      This returns always false with new-style drivers right now.  Make it
      return always true instead, as a host must be present if we are able
      to call the ioctl (without a host attached there would be no device
      node to call on..)
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
    • Anton Blanchard's avatar
      [SCSI] Universal Xport no attach blacklist · 48690405
      Anton Blanchard authored
      On Fri, Dec 13, 2002 at 12:24:39AM +1100, Anton Blanchard wrote:
      > We tested 2.5.51 on a ppc64 box, qlogic 2312 and a fastt700 array. I
      > had CONFIG_SCSI_REPORT_LUNS and unfortunately it thought the management
      > LUN was a disk:
      >   Vendor: IBM       Model: Universal Xport   Rev: 0520
      >   Type:   Direct-Access                      ANSI SCSI revision: 03
      > ...
      > SCSI device sdaj: drive cache: write through
      > SCSI device sdaj: 40960 512-byte hdwr sectors (21 MB)
      >  sdaj: unknown partition table
      > Attached scsi disk sdaj at scsi2, channel 0, id 0, lun 31
      > ...
      > end_request: I/O error, dev sdaj, sector 0
      Three years later...
      It looks like SGI use the same FC vendor and they already have a
      workaround for this issue. The following patch adds the IBM version of
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
    • Alan Stern's avatar
      [SCSI] sd: pause in sd_spinup_disk for slow USB devices · 4451e472
      Alan Stern authored
      This patch adds a delay tailored for USB flash devices that are slow to
      initialize their firmware.  The symptom is a repeated Unit Attention with
      ASC=0x28 (Not Ready to Ready transition).  The patch will wait for up to 5
      seconds for such devices to become ready.  Normal devices won't send the
      repeated Unit Attention sense key and hence won't trigger the patch.
      This fixes a problem with James Roberts-Thomson's USB device, and I've
      seen several reports of other devices exhibiting the same symptoms --
      presumably they will be helped as well.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
    • Alan Stern's avatar
      [SCSI] return success after retries in scsi_eh_tur · e47373ec
      Alan Stern authored
      The problem lies in the way the error handler uses TEST UNIT READY to
      tell whether error recovery has succeeded.  The scsi_eh_tur function
      gives up after one round of retrying; after that it decides that more
      error recovery is needed.
      However TUR is liable to report sense data indicating a retry is needed
      when in fact error recovery has succeeded.  A typical example might be
      SK=2, ASC=4, ASCQ=1 (Logical unit in process of becoming ready).  The mere
      fact that we were able to get a sensible reply to the TUR should indicate
      that the device is working well enough to stop error recovery.
      I ran across a case back in January where this happened.  A CD-ROM drive
      timed out the INQUIRY command, and a device reset fixed the blockage.
      But then the drive kept responding with 2/4/1 -- because it was spinning
      up I suppose -- until the error handler gave up and placed it offline.
      If the initial INQUIRY had received the 2/4/1 instead, everything would
      have worked okay.  It doesn't seem reasonable for things to fail just
      because the error handler had started running.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
    • James Bottomley's avatar
      [SCSI] ibmvscsi: handle large scatter/gather lists · 4dddbc26
      James Bottomley authored
      The maximum size of a scatter-gather list that the current IBM VSCSI
      Client can handle is 10.  This patch adds large scatter-gather support
      to the client so that it is capable of handling up to SG_ALL(255)
      number of requests in the scatter-gather list.
      Signed-off-by: default avatarLinda Xie <lxie@us.ibm.com>
      Acked by: Dave C Boutcher <sleddog@us.ibm.com>
      Rejections fixed up and
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
  4. 05 Sep, 2005 2 commits
  5. 04 Sep, 2005 18 commits
  6. 30 Aug, 2005 2 commits
    • James Bottomley's avatar
      [SCSI] embryonic RAID class · 61a7afa2
      James Bottomley authored
      The idea behind a RAID class is to provide a uniform interface to all
      RAID subsystems (both hardware and software) in the kernel.
      To do that, I've made this class a transport class that's entirely
      subsystem independent (although the matching routines have to match per
      subsystem, as you'll see looking at the code).  I put it in the scsi
      subdirectory purely because I needed somewhere to play with it, but it's
      not a scsi specific module.
      I used a fusion raid card as the test bed for this; with that kind of
      card, this is the type of class output you get:
      jejb@titanic> ls -l /sys/class/raid_devices/20\:0\:0\:0/
      total 0
      lrwxrwxrwx  1 root root     0 Aug 16 17:21 component-0 -> ../../../devices/pci0000:80/0000:80:04.0/host20/target20:1:0/20:1:0:0/
      lrwxrwxrwx  1 root root     0 Aug 16 17:21 component-1 -> ../../../devices/pci0000:80/0000:80:04.0/host20/target20:1:1/20:1:1:0/
      lrwxrwxrwx  1 root root     0 Aug 16 17:21 device -> ../../../devices/pci0000:80/0000:80:04.0/host20/target20:0:0/20:0:0:0/
      -r--r--r--  1 root root 16384 Aug 16 17:21 level
      -r--r--r--  1 root root 16384 Aug 16 17:21 resync
      -r--r--r--  1 root root 16384 Aug 16 17:21 state
      So it's really simple: for a SCSI device representing a hardware raid,
      it shows the raid level, the array state, the resync % complete (if the
      state is resyncing) and the underlying components of the RAID (these are
      exposed in fusion on the virtual channel 1).
      As you can see, this type of information can be exported by almost
      anything, including software raid.
      The more difficult trick, of course, is going to be getting it to
      perform configuration type actions with writable attributes.
      Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
    • Jeff Garzik's avatar
      [libata] fix ATAPI-enable typo · 6f106233
      Jeff Garzik authored
      Dumb typo spotted by Mark Lord.