cvs commit: src/sys/cam/scsi scsi_da.c

[Nate Lawson]

mjacob at freebsd.org wrote:
>> As long as it's specific to a known external device (USB), and the 
>> user knows that running some command (device_eject umass0) will make 
>> sure it's safe, I'm ok.
> 
> Mmm.
> 
>>>> From a silly semantic point of view to get around this, we should still 
>>> support and require SYNC_CACHE on close except where devices don't 
>>> support it (and any device that hangs on a SYNC_CACHE doesn't support 
>>> it- period). On detach, devices that still need to have data commited 
>>> via an opcode that looks remarkably like SYNC_CACHE can and should 
>>> have that happen- with all the infrastructure changes that go along 
>>> with allowing devices to be detached (w/o complaint) with a live 
>>> command.
>>>
>>> Or have I missed something it what you're suggesting?
>>
>> Actually, that's a different idea I had where you set a timeout() 
>> before running SYNC_CACHE, then cancel the command if it hangs.  Not 
>> sure how to implement the idea of a cancellable device call but maybe 
>> by creating a temporary thread?
> 
> Why not just quiet SYNC_CACHE timeouts?

That's for a device that still works after a timeout.  Something about 
either GEOM, CAM, or USB hangs (or loops infinitely) and refuses to 
continue the boot if the device times out.

-- 
Nate