On Sun, 23 Jan 2000, Eric Youngdale wrote:
> ----- 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?
>
> > 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 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.
>
> [...]
>
> 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.
Well, unfortunately, the annoying part isn't a technical one, it's an
end-user one. Consider what happens if I try to do a ": </dev/sda" from a
bash prompt, where sda is actually a USB zip drive with no media in it.
Because of the fact that we issue lots of useless/nonsensical commands, it
takes a long time to return to the command prompt with an error message.
The SCSI core layer appears to retry the same sequences over and over
again, even tho they keep failing and indicating that there is no media
present.
This is very annoying from a user point of view, and the delays are made
worse by the time it takes to send the command down the USB line and then
do some jumping through hoops to get some sort of status information.
Because of the design of the mass storage spec, every time a command fails
I have to issue (automatically) a REQUEST_SENSE, and then process that.
It's a 2:1 ratio of actual commands to what the SCSI core asked for.
Personally, I'd like to see this fixed. I realize that there probably
isn't much call for that, but I think just ignoring valuable information
about the status of the device is a bad policy.
> 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.
That's definately a good point. My experience is that all of my devices
will correctly return CHECK_CONDITION with the right sense data for media
change.
> 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.
Allready noticed that. Actually, that an eject were some of the commands
I use for testing when I develop my USB Mass Storage driver.
Matt Dharm
--
Matthew Dharm Home: [EMAIL PROTECTED]
Engineer, Qualcomm, Inc. Work: [EMAIL PROTECTED]
I think the problem is there's a nut loose on your keyboard.
-- Greg to Customer
User Friendly, 1/5/1999
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
