Retirement of CAM_QUIRK_NOSERIAL
Ulrich Spoerlein
uspoerlein at gmail.com
Tue Sep 18 13:23:00 PDT 2007
On Sun, 16.09.2007 at 11:48:00 -0600, Scott Long wrote:
> Ulrich Spoerlein wrote:
> > On Mon, 10.09.2007 at 22:12:52 -0600, Scott Long wrote:
> >> All,
> >>
> >> The attached patch should make CAM behave properly with regard to
> >> probing device serial numbers only when the device advertises that
> >> it supports it. It will hopefully eliminate the need for the
> >> CAM_QUIRK_NOSERIAL quirk (one instance is left because of an unrelated
> >> legacy problem that may or may not be possible to fix). This should
> >> especially benefit USB-UMASS devices, where the console output should
> >> be less noisy. It might even make more devices work out-of-the-box.
> > While this patch is working fine with my USB/FW HDD enclosure, it breaks
> > my MP3 USB stick
> > kernel: umass0: <Samsung YP-U2, class 0/0, rev 2.00/10.01, addr 8> on uhub5
> > kernel: umass0: BBB reset failed, IOERROR
> > kernel: umass0: BBB bulk-in clear stall failed, IOERROR
> > kernel: umass0: BBB bulk-out clear stall failed, IOERROR
>
> Is this a regression of something that works without the patch, or is
> it something that has never worked? What happens if you use the
> NO_INQUIRY_EVPD quirk instead?
Ok, I played around a bit and with your patch applied, I have to
*remove* the quirk for my Samsung device, then it starts attaching
again. That's a good thing, right? :)
umass0: <Samsung YP-U2, class 0/0, rev 2.00/10.01, addr 2> on uhub3
da0 at umass-sim0 bus 0 target 0 lun 0
da0: <Samsung YP-U2 0100> Removable Direct Access SCSI-4 device
da0: 40.000MB/s transfers
da0: 999MB (511616 2048 byte sectors: 64H 32S/T 249C)
There are only two other devices right now, that require a SHUTTLE_INIT
quirk, perhaps they are broken by your patch, too.
Btw, why are there devices in umass.c with NO_QUIRKS set? Shouldn't
those entries be removed?
Cheers,
Ulrich Spoerlein
--
It is better to remain silent and be thought a fool,
than to speak, and remove all doubt.
More information about the freebsd-scsi
mailing list