cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c usbdevs

[Matthew Jacob]

>> I think the tape driver (sa) does MODE SENSE as part of normal operation
>> but da does not.  (Working frm memory here).
>
> It seems like a reasonable idea to check the WCE bit before sending a sync
> cache command.  In theory it shouldn't cause any more breakage than sync
> cache itself.  The generic CAM probe code already sends a mode sense (for
> the control mode page) to detect whether the DQue bit is set.
>
> The way to implement it in the da(4) driver would be as another probe state
> in addition to the two read capacity states.  One difference is that things
> shouldn't blow up if the mode sense fails.  (In that case, we should
> probably disable sync cache.)
>
> One case this won't cover, though, is when the user changes the WCE bit
> after we probe.  That's obviously not a very common case, but the only way
> to mostly cover it would be to do a mode sense just prior to every sync
> cache command.  (We could set a bit, though, if that mode page isn't
> supported so that we don't constantly ask for a mode page that isn't
> supported.)
>
> We're also assuming that the device firmware is telling the truth about
> whether the write cache is enabled or disabled.  (Hopefully so, but you
> never know.)


Changing the WCE bit is actually pretty common. I do it all the time 
myself. Furthermore, a common scenario is the Windows enables WCE and 
then uses FUA for synchronization.

I've missed something here- other than broken devices that die 
spectacularly when the get one, why don't you just infer from a failed 
SYNCHRONIZE CACHE (e.g., "Illegal Request") that the device doesn't 
support it and stop doing it?

For example, the EMC/Clariion AX100 reports Illegal Request on 
this command. You can't use quirks to identify this device because all 
Clariions have essentially the same Vendor/Product ID ("DGC", "RAID5").