Re: USB da(4) quirks deprecated
Nate Lawson wrote: On Sat, 13 Sep 2003, John-Mark Gurney wrote: Andrew Thompson wrote this message on Sat, Sep 13, 2003 at 16:33 +1200: I have just got around to trying this pen-drive again and have been trying tracking down data corruptions. If I mount the drive, write a file, umount/mount again the file is different. Is this on an ohci controller? Yes, on a Compaq N1000v laptop (nothing but trouble) usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 This is wierd in that it's the second page of the second transfer. The ohci can do up to 8k transfers in one TD, and then chain the TD's together if a larger block sized is used. Maybe you can provide him a patch that limits transfers to a single page as multi-page descriptors might be broken on his controller. I have now tried the unit on my desktop at home and it works perfect, no corruptions. It seems to be related to my laptop usb controller as Nate suggests. Andy ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB da(4) quirks deprecated
On Sat, 13 Sep 2003, John-Mark Gurney wrote: > Andrew Thompson wrote this message on Sat, Sep 13, 2003 at 16:33 +1200: > > I have just got around to trying this pen-drive again and have been > > trying tracking down data corruptions. If I mount the drive, write a > > file, umount/mount again the file is different. > > > > Using cmp I have found that there are consistent blocks of nulls in the > > written file where data should be. The block is always 0xfff bytes long > > and starts at 0x3000. I have tried many files and the offsets are > > always the same. All the other data in the file is correct and at the > > right location. > > > > 0x3000 -> 0x3fff > > 0x7000 -> 0x7fff > > 0xb000 -> 0xbfff > > 0xf000 -> 0x > > 0x13000 -> 0x13fff > > ... and so on until the end of the file ... > > > > Any suggestions? This almost certainly has nothing to do with quirks. > Is this on an ohci controller? > > I'm trying to track down mbr's problem also that appears to do the > same thing. Have you tried doing an fstat before umounting the fs? I think you mean fsync? > (There is a bug in msdosfs that doesn't sync the disk before unmount > completes.) > > This is wierd in that it's the second page of the second transfer. > The ohci can do up to 8k transfers in one TD, and then chain the TD's > together if a larger block sized is used. Maybe you can provide him a patch that limits transfers to a single page as multi-page descriptors might be broken on his controller. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB da(4) quirks deprecated
Andrew Thompson wrote this message on Sat, Sep 13, 2003 at 16:33 +1200: > I have just got around to trying this pen-drive again and have been > trying tracking down data corruptions. If I mount the drive, write a > file, umount/mount again the file is different. > > Using cmp I have found that there are consistent blocks of nulls in the > written file where data should be. The block is always 0xfff bytes long > and starts at 0x3000. I have tried many files and the offsets are > always the same. All the other data in the file is correct and at the > right location. > > 0x3000 -> 0x3fff > 0x7000 -> 0x7fff > 0xb000 -> 0xbfff > 0xf000 -> 0x > 0x13000 -> 0x13fff > ... and so on until the end of the file ... > > Any suggestions? Is this on an ohci controller? I'm trying to track down mbr's problem also that appears to do the same thing. Have you tried doing an fstat before umounting the fs? (There is a bug in msdosfs that doesn't sync the disk before unmount completes.) This is wierd in that it's the second page of the second transfer. The ohci can do up to 8k transfers in one TD, and then chain the TD's together if a larger block sized is used. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB da(4) quirks deprecated
Nate Lawson wrote:
dmesg:
umass0: SigmaTel, Inc. USBMSC Audio Player, rev 1.10/0.01, addr 3
umass0: Get Max Lun not supported (IOERROR)
Enabling quirks for device
da0 at umass-sim0 bus 0 target 0 lun 0
da0: Removable Direct Access SCSI-4 device
da0: 1.000MB/s transfers
da0: 125MB (256001 512 byte sectors: 64H 32S/T 125C)
The NO_PREVENT support has been added. Does this work for you?
{
{T_DIRECT, SIP_MEDIA_REMOVABLE, "SigmaTel", "MSCN", "*"},
/*quirks*/ DA_Q_NO_SYNC_CACHE|DA_Q_NO_PREVENT
},
Yes, it does work :)
I have just got around to trying this pen-drive again and have been
trying tracking down data corruptions. If I mount the drive, write a
file, umount/mount again the file is different.
Using cmp I have found that there are consistent blocks of nulls in the
written file where data should be. The block is always 0xfff bytes long
and starts at 0x3000. I have tried many files and the offsets are
always the same. All the other data in the file is correct and at the
right location.
0x3000 -> 0x3fff
0x7000 -> 0x7fff
0xb000 -> 0xbfff
0xf000 -> 0x
0x13000 -> 0x13fff
... and so on until the end of the file ...
Any suggestions?
Andy
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB da(4) quirks deprecated
On Sat, 9 Aug 2003, Andrew Thompson wrote:
> On Fri, 2003-08-08 at 15:41, Nate Lawson wrote:
> I have applied Kevins DA_Q_NO_PREVENT patch and now the device is
> working perfectly, here is the diff and new dmesg.
>
> Thanks Nate and Kevin for your help. Should I send a PR?
Please do and then send me the #.
> dmesg:
> umass0: SigmaTel, Inc. USBMSC Audio Player, rev 1.10/0.01, addr 3
> umass0: Get Max Lun not supported (IOERROR)
> Enabling quirks for device
> da0 at umass-sim0 bus 0 target 0 lun 0
> da0: Removable Direct Access SCSI-4 device
> da0: 1.000MB/s transfers
> da0: 125MB (256001 512 byte sectors: 64H 32S/T 125C)
> scsi_da.c.diff:
> @@ -228,6 +229,10 @@
> {T_DIRECT, SIP_MEDIA_FIXED, quantum, "VIKING 2*", "*"},
> /*quirks*/ DA_Q_NO_6_BYTE
> },
> + {
> + {T_DIRECT, SIP_MEDIA_REMOVABLE, "SigmaTel*", "MSCN*",
> "*"},
> + /*quirks*/
> DA_Q_NO_6_BYTE|DA_Q_NO_SYNC_CACHE|DA_Q_NO_PREVENT
> + },
>
> #ifdef DA_OLD_QUIRKS
> /* Below a list of quirks for USB devices supported by umass. */
The NO_PREVENT support has been added. Does this work for you?
{
{T_DIRECT, SIP_MEDIA_REMOVABLE, "SigmaTel", "MSCN", "*"},
/*quirks*/ DA_Q_NO_SYNC_CACHE|DA_Q_NO_PREVENT
},
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB da(4) quirks deprecated
Nate, I have successfully tested and the MuVo needs both DA_Q_NO_SYNC_CACHE and DA_Q_NO_PREVENT (as per PR/53094) to work. One question which pops into my mind is why the inability of a device to do a cache sync should be fatal. I suspect that most flash devices don't really even have a cache and few do anything but return an error when asked to synchronize. Why not test this when the device is initialized (and maybe PREVENT, as well) and set the device to operate accordingly from that point on,probably with a message that the device does not honor cache sync requests. This would greatly enhance the odds of a device "just working", though I may not fully understand the implications of such a change on a more global basis. In any case, the MuVo does require something beyond the norm (disabling of the prevent stuff) to work and I may be patching my driver for a long time to come. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 > Date: Thu, 7 Aug 2003 20:13:11 -0700 (PDT) > From: Nate Lawson <[EMAIL PROTECTED]> > > On Fri, 8 Aug 2003, Andrew Thompson wrote: > > Hi Nate, > > > > I have just purchased a usb pendrive/mp3 player and I am having a bit of > > trouble. > > > > I built a fresh kernel today as I saw you have been working with the da > > quirks. When I insert the drive I get: > > > > umass0: SigmaTel, Inc. USBMSC Audio Player, rev 1.10/0.01, addr 3 > > umass0: Get Max Lun not supported (IOERROR) > > da0 at umass-sim0 bus 0 target 0 lun 0 > > da0: Removable Direct Access SCSI-4 device > > da0: 1.000MB/s transfers > > da0: 125MB (256001 512 byte sectors: 64H 32S/T 125C) > > umass0: BBB reset failed, IOERROR > > umass0: BBB bulk-in clear stall failed, IOERROR > > umass0: BBB bulk-out clear stall failed, IOERROR > > umass0: BBB reset failed, IOERROR > > umass0: BBB bulk-in clear stall failed, IOERROR > > umass0: BBB bulk-out clear stall failed, IOERROR > > and so on > > Looks pretty standard. Here is more info on the possible quirks: > http://www.root.org/~nate/freebsd/quirks.html > > If I were you, I'd look first into adding one for RS_NO_CLEAR_UA in > sys/dev/usb/umass.c. See other quirks like this to get an idea. It's > also possible that the problem is "NO_SYNC_CACHE" in > sys/cam/scsi/scsi_da.c. I'm adding Kevin Oberman. He's submitted some > quirks before. The idea is to try a few similar to the surrounding ones > until something works. > > > I recompiled with "options DA_OLD_QUIRKS" and now I get > > No difference. > > The reason is that there never was a quirk for your device. "OLD" implies > there was already one there. > > -Nate > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB da(4) quirks deprecated
In article <[EMAIL PROTECTED]> you wrote: > On Fri, 2003-08-08 at 03:13, Nate Lawson wrote: >> On Fri, 8 Aug 2003, Andrew Thompson wrote: >> > Hi Nate, >> > >> > I have just purchased a usb pendrive/mp3 player and I am having a bit of >> > trouble. >> > >> > I built a fresh kernel today as I saw you have been working with the da >> > quirks. When I insert the drive I get: >> > >> > umass0: SigmaTel, Inc. USBMSC Audio Player, rev 1.10/0.01, addr 3 >> > umass0: Get Max Lun not supported (IOERROR) >> > da0 at umass-sim0 bus 0 target 0 lun 0 >> > da0: Removable Direct Access SCSI-4 device >> > da0: 1.000MB/s transfers >> > da0: 125MB (256001 512 byte sectors: 64H 32S/T 125C) >> > umass0: BBB reset failed, IOERROR >> > umass0: BBB bulk-in clear stall failed, IOERROR >> > umass0: BBB bulk-out clear stall failed, IOERROR >> > umass0: BBB reset failed, IOERROR >> > umass0: BBB bulk-in clear stall failed, IOERROR >> > umass0: BBB bulk-out clear stall failed, IOERROR >> > and so on I recently had a USB compact flash adapter that was giving me very similar errors. The problem turned out to be my USB hub. Have you tried connecting with out a hub? Larry -- Larry Baird| http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: [EMAIL PROTECTED] | TEL 407-380-0220, FAX 407-380-6080 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB da(4) quirks deprecated
On Fri, 8 Aug 2003, Andrew Thompson wrote:
> On Fri, 2003-08-08 at 15:13, Nate Lawson wrote:
> > On Fri, 8 Aug 2003, Andrew Thompson wrote:
> > > da0 at umass-sim0 bus 0 target 0 lun 0
> > > da0: Removable Direct Access SCSI-4 device
> > > da0: 1.000MB/s transfers
> > > da0: 125MB (256001 512 byte sectors: 64H 32S/T 125C)
> >
> > If I were you, I'd look first into adding one for RS_NO_CLEAR_UA in
> > sys/dev/usb/umass.c. See other quirks like this to get an idea. It's
> > also possible that the problem is "NO_SYNC_CACHE" in
> > sys/cam/scsi/scsi_da.c. I'm adding Kevin Oberman. He's submitted some
> > quirks before. The idea is to try a few similar to the surrounding ones
> > until something works.
>
> Whats the format of the quirk matching string? I put this in (with a
> printf) but it doesnt match the device.
>
> --- scsi_da.c Fri Aug 8 14:36:33 2003
> +++ /usr/src/sys/cam/scsi/scsi_da.c Fri Aug 8 15:38:47 2003
> @@ -364,6 +364,13 @@
> {T_DIRECT, SIP_MEDIA_REMOVABLE, "MITSUMI", "USB FDD",
> "*"},
> /*quirks*/ DA_Q_NO_SYNC_CACHE
> },
> +{
> +/*
> + * SigmaTel Pen Drives
> + */
> +{T_DIRECT, SIP_MEDIA_REMOVABLE, "SigmaTel", "MSCN
> 0001", "*"},
> +/*quirks*/ DA_Q_NO_SYNC_CACHE
> +},
> #endif /* DA_OLD_QUIRKS */
> };
Try "SigmaTel", "MSCN", "*". The 0001 is the version number, not part of
the product name. Also, the "#endif" shows that you are putting your test
quirk under the #ifdef. Instead it should come after the #endif so it
won't matter whether you're using "options DA_OLD_QUIRKS" or not.
-Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB da(4) quirks deprecated
On Fri, 2003-08-08 at 03:13, Nate Lawson wrote: > On Fri, 8 Aug 2003, Andrew Thompson wrote: > > Hi Nate, > > > > I have just purchased a usb pendrive/mp3 player and I am having a bit of > > trouble. > > > > I built a fresh kernel today as I saw you have been working with the da > > quirks. When I insert the drive I get: > > > > umass0: SigmaTel, Inc. USBMSC Audio Player, rev 1.10/0.01, addr 3 > > umass0: Get Max Lun not supported (IOERROR) > > da0 at umass-sim0 bus 0 target 0 lun 0 > > da0: Removable Direct Access SCSI-4 device > > da0: 1.000MB/s transfers > > da0: 125MB (256001 512 byte sectors: 64H 32S/T 125C) > > umass0: BBB reset failed, IOERROR > > umass0: BBB bulk-in clear stall failed, IOERROR > > umass0: BBB bulk-out clear stall failed, IOERROR > > umass0: BBB reset failed, IOERROR > > umass0: BBB bulk-in clear stall failed, IOERROR > > umass0: BBB bulk-out clear stall failed, IOERROR > > and so on > > Looks pretty standard. Here is more info on the possible quirks: > http://www.root.org/~nate/freebsd/quirks.html > > If I were you, I'd look first into adding one for RS_NO_CLEAR_UA in > sys/dev/usb/umass.c. See other quirks like this to get an idea. It's > also possible that the problem is "NO_SYNC_CACHE" in > sys/cam/scsi/scsi_da.c. I have tried RS_NO_CLEAR_UA, NO_GETMAXLUN, NO_START_STOP, NO_TEST_UNIT_READY, DA_Q_NO_SYNC_CACHE and DA_Q_NO_6_BYTE without any luck. Any other quirks to try? Andy ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB da(4) quirks deprecated
On Fri, 2003-08-08 at 15:41, Nate Lawson wrote:
> On Fri, 8 Aug 2003, Andrew Thompson wrote:
> > On Fri, 2003-08-08 at 03:13, Nate Lawson wrote:
> > > On Fri, 8 Aug 2003, Andrew Thompson wrote:
> > > > umass0: SigmaTel, Inc. USBMSC Audio Player, rev 1.10/0.01, addr 3
> > >
> > > If I were you, I'd look first into adding one for RS_NO_CLEAR_UA in
> > > sys/dev/usb/umass.c. See other quirks like this to get an idea. It's
> > > also possible that the problem is "NO_SYNC_CACHE" in
> > > sys/cam/scsi/scsi_da.c.
> >
> > I have tried RS_NO_CLEAR_UA, NO_GETMAXLUN, NO_START_STOP,
> > NO_TEST_UNIT_READY, DA_Q_NO_SYNC_CACHE and DA_Q_NO_6_BYTE without any
> > luck.
> >
> > Any other quirks to try?
>
> Let's see the new dmesg. As per my previous reply, I'm not confident your
> quirk was having any effect.
>
> -Nate
I had out a printf after the match function, and it was having an effect
for the quirks above.
I have applied Kevins DA_Q_NO_PREVENT patch and now the device is
working perfectly, here is the diff and new dmesg.
Thanks Nate and Kevin for your help. Should I send a PR?
dmesg:
umass0: SigmaTel, Inc. USBMSC Audio Player, rev 1.10/0.01, addr 3
umass0: Get Max Lun not supported (IOERROR)
Enabling quirks for device
da0 at umass-sim0 bus 0 target 0 lun 0
da0: Removable Direct Access SCSI-4 device
da0: 1.000MB/s transfers
da0: 125MB (256001 512 byte sectors: 64H 32S/T 125C)
scsi_da.c.diff:
-- sys/cam/scsi/scsi_da.c.orig Sat Aug 9 12:18:35 2003
+++ sys/cam/scsi/scsi_da.c Sat Aug 9 18:59:58 2003
@@ -94,7 +94,8 @@
typedef enum {
DA_Q_NONE = 0x00,
DA_Q_NO_SYNC_CACHE = 0x01,
- DA_Q_NO_6_BYTE = 0x02
+ DA_Q_NO_6_BYTE = 0x02,
+ DA_Q_NO_PREVENT = 0x04
} da_quirks;
typedef enum {
@@ -228,6 +229,10 @@
{T_DIRECT, SIP_MEDIA_FIXED, quantum, "VIKING 2*", "*"},
/*quirks*/ DA_Q_NO_6_BYTE
},
+ {
+ {T_DIRECT, SIP_MEDIA_REMOVABLE, "SigmaTel*", "MSCN*",
"*"},
+ /*quirks*/
DA_Q_NO_6_BYTE|DA_Q_NO_SYNC_CACHE|DA_Q_NO_PREVENT
+ },
#ifdef DA_OLD_QUIRKS
/* Below a list of quirks for USB devices supported by umass. */
@@ -484,7 +489,8 @@
}
if (error == 0) {
- if ((softc->flags & DA_FLAG_PACK_REMOVABLE) != 0)
+ if ((softc->flags & DA_FLAG_PACK_REMOVABLE) != 0
+ && (softc->quirks & DA_Q_NO_PREVENT) == 0)
daprevent(periph, PR_PREVENT);
} else {
softc->flags &= ~DA_FLAG_OPEN;
@@ -562,6 +568,7 @@
}
if ((softc->flags & DA_FLAG_PACK_REMOVABLE) != 0) {
+ if ((softc->quirks & DA_Q_NO_PREVENT) == 0)
daprevent(periph, PR_ALLOW);
/*
* If we've got removeable media, mark the blocksize as
@@ -978,9 +985,10 @@
sizeof(da_quirk_table)/sizeof(*da_quirk_table),
sizeof(*da_quirk_table),
scsi_inquiry_match);
- if (match != NULL)
+ if (match != NULL) {
softc->quirks = ((struct da_quirk_entry
*)match)->quirks;
- else
+ printf("Enabling quirks for device\n");
+ } else
softc->quirks = DA_Q_NONE;
/* Check if the SIM does not want 6 byte commands */
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB da(4) quirks deprecated
On Fri, 8 Aug 2003, Andrew Thompson wrote: > On Fri, 2003-08-08 at 03:13, Nate Lawson wrote: > > On Fri, 8 Aug 2003, Andrew Thompson wrote: > > > umass0: SigmaTel, Inc. USBMSC Audio Player, rev 1.10/0.01, addr 3 > > > umass0: Get Max Lun not supported (IOERROR) > > > da0 at umass-sim0 bus 0 target 0 lun 0 > > > da0: Removable Direct Access SCSI-4 device > > > da0: 1.000MB/s transfers > > > da0: 125MB (256001 512 byte sectors: 64H 32S/T 125C) > > > umass0: BBB reset failed, IOERROR > > > umass0: BBB bulk-in clear stall failed, IOERROR > > > umass0: BBB bulk-out clear stall failed, IOERROR > > > umass0: BBB reset failed, IOERROR > > > umass0: BBB bulk-in clear stall failed, IOERROR > > > umass0: BBB bulk-out clear stall failed, IOERROR > > > and so on > > > > Looks pretty standard. Here is more info on the possible quirks: > > http://www.root.org/~nate/freebsd/quirks.html > > > > If I were you, I'd look first into adding one for RS_NO_CLEAR_UA in > > sys/dev/usb/umass.c. See other quirks like this to get an idea. It's > > also possible that the problem is "NO_SYNC_CACHE" in > > sys/cam/scsi/scsi_da.c. > > I have tried RS_NO_CLEAR_UA, NO_GETMAXLUN, NO_START_STOP, > NO_TEST_UNIT_READY, DA_Q_NO_SYNC_CACHE and DA_Q_NO_6_BYTE without any > luck. > > Any other quirks to try? Let's see the new dmesg. As per my previous reply, I'm not confident your quirk was having any effect. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB da(4) quirks deprecated
On Fri, 8 Aug 2003, Andrew Thompson wrote: > Hi Nate, > > I have just purchased a usb pendrive/mp3 player and I am having a bit of > trouble. > > I built a fresh kernel today as I saw you have been working with the da > quirks. When I insert the drive I get: > > umass0: SigmaTel, Inc. USBMSC Audio Player, rev 1.10/0.01, addr 3 > umass0: Get Max Lun not supported (IOERROR) > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-4 device > da0: 1.000MB/s transfers > da0: 125MB (256001 512 byte sectors: 64H 32S/T 125C) > umass0: BBB reset failed, IOERROR > umass0: BBB bulk-in clear stall failed, IOERROR > umass0: BBB bulk-out clear stall failed, IOERROR > umass0: BBB reset failed, IOERROR > umass0: BBB bulk-in clear stall failed, IOERROR > umass0: BBB bulk-out clear stall failed, IOERROR > and so on Looks pretty standard. Here is more info on the possible quirks: http://www.root.org/~nate/freebsd/quirks.html If I were you, I'd look first into adding one for RS_NO_CLEAR_UA in sys/dev/usb/umass.c. See other quirks like this to get an idea. It's also possible that the problem is "NO_SYNC_CACHE" in sys/cam/scsi/scsi_da.c. I'm adding Kevin Oberman. He's submitted some quirks before. The idea is to try a few similar to the surrounding ones until something works. > I recompiled with "options DA_OLD_QUIRKS" and now I get > No difference. The reason is that there never was a quirk for your device. "OLD" implies there was already one there. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP: USB da(4) quirks deprecated
On Tue, 29 Jul 2003, Justin T. Gibbs wrote: > > You may have a device (USB camera, pen drive, hard drive, ...) that begins > > to get errors like ... "Synchronize cache failed, status 0x35". > > If the Sync cache fails with a "reasonable error code", then the code > that silence these errors should be enhanced rather than have a quirk > entry added. I'm committed to doing that for devices which respond in a reasonable way (whether error or success). > Just to reitterate, the quirks are there for situations that cannot > be handled in a more programatic way (e.g. a device that dies when > you send it a certain command). Please don't blindly re-enable quirks > to silence junk that winds up in syslog. I won't be re-enabling quirks except for devices which hang. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP: USB da(4) quirks deprecated
> You may have a device (USB camera, pen drive, hard drive, ...) that begins > to get errors like ... "Synchronize cache failed, status 0x35". If the Sync cache fails with a "reasonable error code", then the code that silence these errors should be enhanced rather than have a quirk entry added. Just to reitterate, the quirks are there for situations that cannot be handled in a more programatic way (e.g. a device that dies when you send it a certain command). Please don't blindly re-enable quirks to silence junk that winds up in syslog. -- Justin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP: USB da(4) quirks deprecated
Hi, "camcontrol inquiry" requires the pass driver, so if it's not already in your kernel config you might want to add it when/if you add DA_OLD_QUIRKS. Regards, > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/> On Mon, 28 Jul 2003, Nate Lawson wrote: > I have committed code to disable the USB and Firewire quirks in da(4). > Since we now have code that should handle the common case of a failure > after receiving 6 byte commands, most of them should no longer be > necessary. However, the only way to tell if a quirk is really needed is > to test the new code with the quirks disabled. You may have a device (USB > camera, pen drive, hard drive, ...) that begins to get errors like "BBB > bulk-in clear stall failed" or "Synchronize cache failed, status 0x35". > If you get these, you can enable previous behavior by adding: > > options DA_OLD_QUIRKS > > to your kernel config and recompiling. Once you do this, please send me > the output of "camcontrol inquiry da0" so I can re-enable your quirk for > good. I'm doing this as soon as possible so the unnecessary quirks can be > removed for 5.2. A similar process will take place in 4-stable after 5.2 > has been released. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
HEADSUP: USB da(4) quirks deprecated
I have committed code to disable the USB and Firewire quirks in da(4). Since we now have code that should handle the common case of a failure after receiving 6 byte commands, most of them should no longer be necessary. However, the only way to tell if a quirk is really needed is to test the new code with the quirks disabled. You may have a device (USB camera, pen drive, hard drive, ...) that begins to get errors like "BBB bulk-in clear stall failed" or "Synchronize cache failed, status 0x35". If you get these, you can enable previous behavior by adding: options DA_OLD_QUIRKS to your kernel config and recompiling. Once you do this, please send me the output of "camcontrol inquiry da0" so I can re-enable your quirk for good. I'm doing this as soon as possible so the unnecessary quirks can be removed for 5.2. A similar process will take place in 4-stable after 5.2 has been released. Thanks for your patience, Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
