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: <SigmaTel MSCN 0001> 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]"
