----- Original Message -----
From: "Matthew Dharm" <[EMAIL PROTECTED]>
To: "The Linux SCSI list" <[EMAIL PROTECTED]>
Sent: Friday, January 21, 2000 7:32 PM
Subject: READ_CAPACITY after TEST_UNIT_READY failed?
> Well, now that I've introduced myself...
>
> One odd behavior that I'm seeing is this: The first command issued to my
> USB driver upon attempting to access the device (after the initial
> detection probe) is TEST_UNIT_READY. In the case of removable media
> devices, this returns a result code of CHECK_CONDITION and I fill the
> sense data buffer with the results of a REQUEST_SENSE which I
> automatically issue in response to a failed command. The sense data
> indicates 'Media Not Present' -- which is the right answer for a ZIP drive
> with no disk in it.
It took me a bit to figure out what it was that you were seeing -
TEST_UNIT_READY is issued from a lot of places.
It looks like a problem in the SCSI disk driver in sd_init_onedisk. I
can see that a TEST_UNIT_READY will be issued - the point of the thing is to
see if the disk is spinning (if present) and be prepared to spin it up if it
isn't already spinning. The actual question of whether media is present or
not isn't used by the next section of code which does the READ_CAPACITY, so
it will blindly go ahead and try this anyways.
> The odd part is that the SCSI layer then tries to issue a READ_CAPACITY
> command. Of course, this fails too, with the same sense data. Why does
> the SCSI core issue this command? If the unit is not ready, shouldn't we
> not issue READ_CAPACITY? The SCSI core seems to pretty much ignore the
> sense data. Either that, or I'm returning it improperly.
No, you are probably returning it properly.
> Is this behavor normal? If so, I would expect that, in general, we're not
> handling removable-media devices very well.
There is always room for improvement, I guess. Some of the relevant
code in both disk and CDROM is pretty old, but as I know, nobody has
complained about this specific issue before. For that matter, I am not
aware of any serious problems involving removeable media - I am sure people
will point it out if there are issues of which I am unaware.
At first glance, I don't see much harm that could come by issuing a few
extraneous commands at boot time. If you find these especially annoying, we
can look into it some and see what we can do to reduce the number of them.
The trickiest bit about removable media handling is tracking when media
has been changed. It is essential that a UNIT_ATTENTION/CHECK_CONDITION be
returned when a media change has occurred as this is how a media change is
reported. In such cases there is quite a bit of information that is flushed
as it is no longer dependable.
Another thing you will eventually notice is that when you attempt to
mount a removeable disk, you should see commands issued to lock the door.
Once the mount count drops to 0, the door should be unlocked.
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
