cvs commit: src/sys/cam/scsi scsi_da.c src/sys/dev/usb umass.c
nate at root.org
Mon Jan 30 17:00:40 PST 2006
Florent Thoumie wrote:
> On Tuesday 31 January 2006 01:24, Nate Lawson wrote:
>>I'm not concerned about the revision. I'm concerned about the vendor
>>(Generic*) and device name (STORAGE DEVICE*). Why are the *'s needed?
> Seemed common practice reading the other entries.
No, that's definitely not it. In fact, the most recent entries should
be audited to see if they really need the *'s. This wildcard might
overly match the wrong devices.
>>(Again, a PR would help track this kind of conversation as shown in
>>previous PRs about quirks. Submitters often match way too much.)
>>>Do you want me to create a PR just for tracking purposes?
>>That would be nice, especially since some of the requested info is
>>missing (dmesg, usbdevs -v). However, if you cited a email in the
>>commit msg (maybe SMTP Message-ID) such that we could find it in the
>>future, that would probably be enough. I'm not trying to create a
>>bureaucracy, just make sure we don't lose information like we used to on
>>why a quirk was added in the first place.
> I only mentioned the freebsd-usb mailing list. I'll contact Anders to get
> additional details and I (or he) will fill a PR so that we can add it to the
> It seems a lot of devices are concerned by the sync cache problem, would it be
> harmful to just remove this part of the code or could there be a way to
> detect if the device supports it or not?
Well, it's important to run SYNC_CACHE in shutdown or possibly when
unmounting a filesystem. Otherwise, data could be lost on boot.
However, I support adding a USB-specific mechanism that says SYNC_CACHE
should only be run on shutdown or device_eject, that way devices that
hang after this command is run would still work at runtime. And SCSI
devices that support multiple calls to SYNC_CACHE (i.e. most non-USB
devs) would still work too.
However, the first step is to investigate what windows and Linux do.
More information about the cvs-src