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

Nate Lawson nate at root.org
Thu Feb 2 10:43:46 PST 2006


Matthew Jacob wrote:
>> 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").

There are 3 kinds of devices:

* SYNC CACHE works
* SYNC CACHE reports an error, but continues working
* SYNC CACHE just hangs, no error
* SYNC CACHE reports and error correctly, but then all subsequent 
commands time out

We're talking about the 4th case and some versions with the 3rd case, if 
it was possible to detect them without hanging (i.e. mode sense works 
and WCE properly reported).  The problem is that we have a significant 
SYNC CACHE quirk proliferation problem.

A few years ago, we had a 6-byte command quirk proliferation problem, 
until I modified USB and Firewire SIMs to report "not 6-byte capable". 
I then was able to remove dozens of quirks and we seem to have solved 
that problem.  I'm recommending we do the same thing with SYNC CACHE now.

-- 
Nate


More information about the freebsd-scsi mailing list