From owner-freebsd-usb@FreeBSD.ORG Fri Jan 21 01:59:16 2005 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1E8016A4CE for ; Fri, 21 Jan 2005 01:59:16 +0000 (GMT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (84-72-18-130.dclient.hispeed.ch [84.72.18.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2007343D49 for ; Fri, 21 Jan 2005 01:59:15 +0000 (GMT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [IPv6:2002:5448:1282:0:206:28ff:fed8:8dcf]) (8.13.2/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id j0L1x9p7002018NO) for ; Fri, 21 Jan 2005 02:59:12 +0100 (CET) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.13.2/FNORD) id j0L1x8Ze002017; Fri, 21 Jan 2005 02:59:08 +0100 (CET) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Fri, 21 Jan 2005 02:59:08 +0100 (CET) Message-Id: <200501210159.j0L1x8Ze002017@Mail.NOSPAM.DynDNS.dK> X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: beer set sender to bounce@NOSPAM.dyndns.dk using -f X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed from queue /tmp X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed by beer with -C /etc/mail/sendmail.cf-LOCAL From: Barry Bouwsma References: <200501101103.j0AB3ENh095604@freefall.freebsd.org> <41E32B44.90807@elischer.org> <200501111205.j0BC53T2015903@Mail.NOSPAM.DynDNS.dK> <41E42D08.90407@elischer.org> To: freebsd-usb@freebsd.org Mail-Followup-To: freebsd-usb@freebsd.org Subject: Re: Current problem reports assigned to you X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Barry Bouwsma List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2005 01:59:17 -0000 On Tue, 11 Jan 2005 11:46:16 -0800, Julian Elischer wrote: > >| a [2003/03/02] kern/48849 usb Maxtor XT5000 causes panic in boot > >I have such a device, and the only problem I've had (4.x) is minor, > >for which I added the NO_GETMAXLUN quirk. I use it all the time. > got a patch? Yes, but it doesn't address the problem -- if it exists -- that prompted the PR. -- cut'n'paste part of diff - tab damage -- danger -- --- /stand/FreeBSD4-src/source-hacks/sys/dev/usb/umass.c-NEWER-current Mon Dec 27 19:28:28 2004 +++ /stand/FreeBSD4-src/source-hacks/sys/dev/usb/umass.c Tue Dec 28 21:07 :39 2004 @@ -369,6 +384,12 @@ UMASS_PROTO_SCSI | UMASS_PROTO_BBB, NO_QUIRKS }, +/* XXX HACK */ + { USB_VENDOR_MAXTOR, USB_PRODUCT_MAXTOR_5000, RID_WILDCARD, + UMASS_PROTO_SCSI | UMASS_PROTO_BBB, + NO_GETMAXLUN + }, +/* XXX HACK */ { USB_VENDOR_MELCO, USB_PRODUCT_MELCO_DUBPXXG, RID_WILDCARD, UMASS_PROTO_SCSI | UMASS_PROTO_BBB, FORCE_SHORT_INQUIRY | NO_START_STOP | IGNORE_RESIDUE @@ -1084,7 +1106,8 @@ /* Get the maximum LUN supported by the device. */ - if ((sc->proto & UMASS_PROTO_WIRE) == UMASS_PROTO_BBB) + if ((sc->proto & UMASS_PROTO_WIRE) == UMASS_PROTO_BBB && /* XXX HACK */ + !(sc->quirks & NO_GETMAXLUN)) sc->maxlun = umass_bbb_get_max_lun(sc); else sc->maxlun = 0; > I'll add it and close the PR. You'll also need to add a couple vendor IDs to usbdevs, or the build will fail again. That's part of the giant diff I have, and as imp@ has been active on that front, I'm not sure how that is progressing. My line to add the vendor ID is surrounded by some 50 lines worth of diff, and the section of diff which adds the product is next to another vendor/product new entry that could potentially break the build. Also, the above cut-n-paste diff is part of a larger diff that makes current's umass.c a plug-in replacement for 4.x If a grep for `MAXTOR' in usbdevs returns the above added definitions, you're in luck; else it's probably easiest to apply them by hand to usbdevs from my latest diffs. All this does is (for me) to speed up boot by a good deal of time. Whether the Original Poster would still see the Original Problem, I cannot say -- perhaps it's also an interaction with the particular chipset in use. You'll need to get a followup from the OP before safely closing the PR. (There have been enough changes since that time that whatever it was could have been solved elsewhere, anyway) Also, if you're wanting to update quirk entries in umass.c, I needed to do the following to get one USB-IDE device to cooperate (in 4.x, based on -current code, not tested on other than 4.x; not sure if the original quirk entry was adequate for all devices, or if this particular adapter is more broken than normal, or if -current doesn't have this problem to start with)... (tab damage) @ -312,6 +321,9 @@ # define NO_INQUIRY 0x0400 /* Device cannot handle INQUIRY EVPD, return CHECK CONDITION */ # define NO_INQUIRY_EVPD 0x0800 +/* XXX */ + /* The device uses a weird CSW TAG. */ +# define WRONG_CSWTAG 0x1000 }; Static struct umass_devdescr_t umass_devdescrs[] = { @@ -419,7 +437,8 @@ }, { USB_VENDOR_SCANLOGIC, USB_PRODUCT_SCANLOGIC_SL11R, RID_WILDCARD, UMASS_PROTO_ATAPI | UMASS_PROTO_BBB, - NO_INQUIRY +/* XXX */ + NO_INQUIRY | WRONG_CSWTAG }, { USB_VENDOR_SHUTTLE, USB_PRODUCT_SHUTTLE_EUSB, RID_WILDCARD, UMASS_PROTO_ATAPI | UMASS_PROTO_CBI_I, @@ -1422,6 +1444,8 @@ { struct umass_softc *sc = (struct umass_softc *) priv; usbd_xfer_handle next_xfer; +/* XXX HACK */ + int Residue; KASSERT(sc->proto & UMASS_PROTO_BBB, ("%s: umass_bbb_state: wrong sc->proto 0x%02x\n", @@ -1595,7 +1619,12 @@ UGETDW(sc->csw.dCSWSignature) == CSWSIGNATURE_OLYMPUS_C1) USETDW(sc->csw.dCSWSignature, CSWSIGNATURE); - int Residue; +/* XXX HACK */ + /* Translate invalid command-status tags */ + if (sc->quirks & WRONG_CSWTAG) + USETDW(sc->csw.dCSWTag, UGETDW(sc->cbw.dCBWTag)); +/* XXX */ + Residue = UGETDW(sc->csw.dCSWDataResidue); if (Residue == 0 && sc->transfer_datalen - sc->transfer_actlen != 0) (relocation of Residue needed to quiet the 4.x compiler) Stupid adapter won't see more than 131GB-ish worth of disk, however; code for this quirk taken from NetBSD Again, no guarantee that I haven't failed to include all relevant parts of the diff needed to get a successful build. > >(I don't use EHCI due to eventual problems with it after some time; I need > >the stability, as of a few months ago) > ehci is improving.. transacions can now time out without crashing the > system.. My bad ehci/umass experience was also with NetBSD, after most of the commits from Charles Hannum that were supposed to fix the problem. I'll try again when I don't risk losing several days of work that I've been trying to complete uninterrupted for the last weeks without success. (Normal people would have thrown in the towel by now) thansk barry bouwsma