Skip to content

L
linux
Switch branch/tag
  1. 06 Sep, 2005 3 commits
    • 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>
      4451e472
    • 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>
      e47373ec
    • 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>
      4dddbc26
  3. 05 Sep, 2005 22 commits
  5. 31 Aug, 2005 3 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>
      61a7afa2
    • James Bottomley's avatar
      [SCSI] attribute container final klist fixes · 2b7d6a8c
      James Bottomley authored 
      Since the attribute container deletes from a klist while it's walking
it, it is vulnerable to the problem (and fix) here:

http://marc.theaimsgroup.com/?l=linux-scsi&m=112485448830217

The attached fixes this (but won't compile without the above).

It also fixes the logical reversal in the traversal loop which meant
that we were never actually traversing the loop to hit this bug in the
first place.
Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      2b7d6a8c
    • James Bottomley's avatar
      [SCSI] correct attribute_container list usage · 53c165e0
      James Bottomley authored 
      One of the changes in the attribute_container code in the scsi-misc tree
was to add a lock to protect the list of devices per container.  This,
unfortunately, leads to potential scheduling while atomic problems if
there's a sleep in the function called by a trigger.

The correct solution is to use the kernel klist infrastructure instead
which allows lockless traversal of a list.
Signed-off-by: default avatarJames Bottomley <James.Bottomley@SteelEye.com>
      53c165e0
  7. 28 Aug, 2005 7 commits
  9. 15 Aug, 2005 3 commits
  11. 14 Aug, 2005 2 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7