On 28.06.2012 09:56, Hans Petter Selasky wrote:
On Wednesday 27 June 2012 23:14:43 Alexander Motin wrote:
On 27.06.2012 23:08, Hans Petter Selasky wrote:
On Wednesday 27 June 2012 19:51:15 Alexander Motin wrote:
On 06/27/12 19:26, Hans Petter Selasky wrote:
On Wednesday 27 June 2012 18:15:24 Hans Petter Selasky wrote:

Retrying might not work, until sense is cleared, due to stalled error.

MAV: Maybe that failed prevent-allow medium removal left a sense error
that needs to be cleared.

It should be cleared by fetching sense command. As I was assured by
several people, it is SIM (controller driver, umass) obligation to fetch
sense and respectively clear it when error detected. But not sure what
should umass do if this device STALLs. May be should try to do it also.
So far I haven't see any properly fetched sense from it in provided

Are you sure? And where should the sense output be sent?

Sense output should be (and are now for working devices) sent within
reply on the original command returning with the CHECK CONDITION SCSI
status. In addition to general status fields there are space for sense
data in struct scsiio: sense_data, sense_len and sense_resid fields.

I see. UMASS already does the sense like you explain on errors, except if the
BULK endpoint is STALL'ed on a READ data. Anyway, I see that the next SCSI
command in the queue completes. And also that the previous one was successful.
So there should be no sense data to fetch.

Even if UMASS gets the sense information, will the upper layers, in this case
CAM layer, retry the CAPACITY command, which seems required to workaround a
bug the stick's firmware?

It depends on sense information (if present). Fatal errors like invalid command code are not retried. Temporal errors like device loading media could be retried many times with some delays between commands, Unknown errors like in this case are usually retried several times, depending on peripheral driver. In this case I see in logs that READ CAPACITY(10) command was unsuccessfully tried 5 times.

Alexander Motin
freebsd-usb@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Reply via email to