From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 08:12:43 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E15137B401 for ; Fri, 8 Aug 2003 08:12:43 -0700 (PDT) Received: from postal3.es.net (postal3.es.net [198.128.3.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BAF243F75 for ; Fri, 8 Aug 2003 08:12:42 -0700 (PDT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id MUA74016; Fri, 08 Aug 2003 08:12:40 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id E9E745D08; Fri, 8 Aug 2003 08:12:39 -0700 (PDT) To: Nate Lawson In-Reply-To: Message from Nate Lawson of "Thu, 07 Aug 2003 20:13:11 PDT." <20030807200629.G77081@root.org> Date: Fri, 08 Aug 2003 08:12:39 -0700 From: "Kevin Oberman" Message-Id: <20030808151239.E9E745D08@ptavv.es.net> cc: current@freebsd.org Subject: Re: USB da(4) quirks deprecated X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2003 15:12:43 -0000 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: oberman@es.net Phone: +1 510 486-8634 > Date: Thu, 7 Aug 2003 20:13:11 -0700 (PDT) > From: Nate Lawson > > 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 >