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:
> >>>> ERR=STALLED
> >>> 
> >>> 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
> >> logs.
> > 
> > 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.

Hi,

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?

--HPS
_______________________________________________
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Reply via email to