Date: Thu, 02 Feb 2006 12:23:57 -0700 From: Scott Long <scottl@samsco.org> To: Nate Lawson <nate@root.org> Cc: freebsd-scsi@freebsd.org, "Kenneth D. Merry" <ken@freebsd.org>, Matthew Jacob <mj@feral.com>, Florent Thoumie <flz@xbsd.org> Subject: Re: cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c usbdevs Message-ID: <43E25C4D.9020804@samsco.org> In-Reply-To: <43E252EC.1050803@root.org> References: <20060130202806.DCC7916A4CA@hub.freebsd.org> <43DEF43A.6090804@root.org> <20060130213338.H79194@ns1.feral.com> <200601311239.10248.flz@xbsd.org> <43E06B06.80405@root.org> <20060202175041.GA92109@nargothrond.kdm.org> <20060202095828.D97756@ns1.feral.com> <43E252EC.1050803@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Nate Lawson wrote:
> 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.
>
You're suggesting that the umass and firewire SIMs universally instruct
CAM to not send a SYNC CACHE for all targets? Easy, but I think it's
too big of a hammer. I'd like to see the da driver get modified to
check the WCE state as has been suggested.
Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43E25C4D.9020804>