> > 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.
I am not that familiar with SCSI over USB. How long is a long time?
What sequence of commands are you getting with what repeat counts?
The actual loop was originally designed to detect/deal with disks that
aren't spun up.
> 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.
This should be a trivial thing to fix, at least to some degree. Are you
working off of the 2.3 kernel, or the 2.2 kernel?
What exactly is the contents of the sense buffer that you are returning?
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
