Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 26 Jan 2005 06:24:17 -0800 (PST)
From:      Federico Galvez-Durand <federicogalvezdurand@yahoo.com>
To:        freebsd-usb@freebsd.org
Subject:   Current problem reports assigned to you
Message-ID:  <20050126142417.92122.qmail@web61007.mail.yahoo.com>

next in thread | raw e-mail | index | archive | help
Hi Barry, I posted this sometime ago:
http://lists.freebsd.org/mailman/htdig/freebsd-usb/2004-December/000318.html

I have a ScanLogic SL11R based device.
I also hacked umass.c to solve CSWtag != CBWtag. 

http://www.del.ufrj.br/~fico/FreeBSD/hack/umass_c_200501261510.diff

Sorry I didn't submit my hack to this list before...
looking for a better solution that never came.

Anyway, my Scanlogic USBIDE mounts and reads well (I
can play mpg video files).

But I *cannot write* to this CDRW.
So far:

cdrecord -dummy -data -v -speed=2 -dev:0,0,0 test.iso

fails logging to console:
kernel: umass0: Unsupported ATAPI command 0x46

Just in case it is interesting for somebody else but
me.

Thank you for your commitment to support USB.

Fico

p.s.: 
uname -a
FreeBSD HERE.org 5.3-STABLE FreeBSD 5.3-STABLE #25:
Tue Jan 25 11:12:09 GMT-1 2005    
ME@HERE.org:/home/hacks/kernel/obj/usr/src/sys/HERE 
i386


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


    * Previous message: Current problem reports
assigned to you
    * Next message: Latest uaudio commits break
Logitech USB Headset
    * Messages sorted by: [ date ] [ thread ] [
subject ] [ author ]

More information about the freebsd-usb mailing list


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Helps protect you from nasty viruses. 
http://promotions.yahoo.com/new_mail



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050126142417.92122.qmail>