Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 02 Feb 2006 12:01:17 -0800
From:      Nate Lawson <nate@root.org>
To:        Scott Long <scottl@samsco.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:  <43E2650D.1060109@root.org>
In-Reply-To: <43E25C4D.9020804@samsco.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> <43E25C4D.9020804@samsco.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Scott Long wrote:
> 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.

I agree, I wasn't clear.  I meant that we should use the mode sense 
approach instead of adding quirks all the time for something that's 
endemic to a particular architecture.  But if that doesn't work, perhaps 
something specific to USB and Firewire may be appropriate.

-- 
Nate



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43E2650D.1060109>