NetBSD Problem Report #12812

Received: (qmail 11591 invoked from network); 3 May 2001 07:37:25 -0000
Message-Id: <20010503073809.14BAC1110F@www.netbsd.org>
Date: Thu,  3 May 2001 00:38:09 -0700 (PDT)
From: waddell@caravan.com
Sender: nobody@netbsd.org
Reply-To: waddell@caravan.com
To: gnats-bugs@gnats.netbsd.org
Subject: Patch needed to add support for Microtech USB-SCSI-HD50 usb scsi adapter
X-Send-Pr-Version: www-1.0

>Number:         12812
>Category:       kern
>Synopsis:       Patch needed to add support for Microtech USB-SCSI-HD50 usb scsi adapter
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          closed
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu May 03 07:38:01 +0000 2001
>Closed-Date:    Fri Aug 23 07:19:43 +0000 2019
>Last-Modified:  Fri Aug 23 07:19:43 +0000 2019
>Originator:     Harry Waddell
>Release:        NetBSB-current/i-386
>Organization:
Caravan Publishing
>Environment:
NetBSD scimitar 1.5V NetBSD 1.5V (GENERIC_LAPTOP) #7: Wed May  2 23:34:24 PDT 2001     waddell@scimitar:/usr/src/sys/arch/i386/compile/GENERIC_LAPTOP i386

>Description:
The microtech USB-SCSI-HD50 seems to work, e.g. it can actually find devices 
attached to it, after applying the supplied patch below. Since 
Microtech is an OEM for shuttle, at least according to some 
linux usb pages I simply re-purposed an existing Shuttle devices 
definitions and now I get the following result:

umass0 at uhub1 port 3 configuration 1 interface 0
umass0: Microtech International, Inc. USB-SCSI-HD50, rev 1.00/1.00, addr 6
umass0: using SFF8020i over CBI
atapibus0 at umass0 channel 0: 2 targets
cd0 at atapibus0 drive 0: <PIONEER, CD-ROM DR-U12X, 1.06> type 5 cdrom removable

unfortunately, I guess one can not connect a tape drive to an atapi bus:

atapibus0 at umass0 channel 0: 2 targets
uk0 at atapibus0 drive 0: <Quantum, DLT4000, CC37> type 1 sequential removable
uk0: unknown device


>How-To-Repeat:
Attach micotech usb scsi adapter to usb port. attachment of scsi 
targets will fail. scsictl scan will not find devices.
>Fix:


Index: umass.c
===================================================================
RCS file: /cvsroot/syssrc/sys/dev/usb/umass.c,v
retrieving revision 1.61
diff -u -r1.61 umass.c
--- umass.c     2001/04/26 03:59:32     1.61
+++ umass.c     2001/05/03 07:04:01
@@ -261,6 +261,27 @@
                return (UMATCH_VENDOR_PRODUCT);
        }

+
+       if (vendor ==  USB_VENDOR_MICROTECH  &&
+            product == USB_PRODUCT_MICROTECH_SCSIHD50
+           ) {
+
+         //                    sc->drive = SHUTTLE_EUSB;
+#if CBI_I
+               sc->wire_proto = WPROTO_CBI_I;
+               sc->cmd_proto = CPROTO_ATAPI;
+#else
+               sc->wire_proto = WPROTO_CBI;
+               sc->cmd_proto = CPROTO_ATAPI;
+#endif
+               sc->subclass = UISUBCLASS_SFF8020I;
+               sc->protocol = UIPROTO_MASS_CBI;
+               sc->quirks |= NO_TEST_UNIT_READY | NO_START_STOP;
+               return (UMATCH_VENDOR_PRODUCT);
+       }
+
+
+
        if (vendor == USB_VENDOR_MICROTECH &&
            product == USB_PRODUCT_MICROTECH_DPCM) {
                sc->wire_proto = WPROTO_CBI;


>Release-Note:
>Audit-Trail:

From: Manuel Bouyer <bouyer@antioche.lip6.fr>
To: waddell@caravan.com
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/12812: Patch needed to add support for Microtech USB-SCSI-HD50 usb scsi adapter
Date: Thu, 3 May 2001 14:06:21 +0200

 On Thu, May 03, 2001 at 12:38:09AM -0700, waddell@caravan.com wrote:
 > 
 > >Description:
 > The microtech USB-SCSI-HD50 seems to work, e.g. it can actually find devices 
 > attached to it, after applying the supplied patch below. Since 
 > Microtech is an OEM for shuttle, at least according to some 
 > linux usb pages I simply re-purposed an existing Shuttle devices 
 > definitions and now I get the following result:
 > 
 > umass0 at uhub1 port 3 configuration 1 interface 0
 > umass0: Microtech International, Inc. USB-SCSI-HD50, rev 1.00/1.00, addr 6
 > umass0: using SFF8020i over CBI
 > atapibus0 at umass0 channel 0: 2 targets
 > cd0 at atapibus0 drive 0: <PIONEER, CD-ROM DR-U12X, 1.06> type 5 cdrom removable

 Is the CD you connected a SCSI or ATAPI device ?
 If scsi devices appears as ATAPI though the USB-SCSI-HD50, this will have
 side effects (drivers do a few things differently for SCSI and ATAPI devices)

 --
 Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
 --

From: Jason R Thorpe <thorpej@zembu.com>
To: waddell@caravan.com
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/12812: Patch needed to add support for Microtech USB-SCSI-HD50 usb scsi adapter
Date: Thu, 3 May 2001 08:35:27 -0700

 On Thu, May 03, 2001 at 12:38:09AM -0700, waddell@caravan.com wrote:

  > >Synopsis:       Patch needed to add support for Microtech USB-SCSI-HD50 usb scsi adapter

  > The microtech USB-SCSI-HD50 seems to work, e.g. it can actually find devices 
  > attached to it, after applying the supplied patch below. Since 
  > Microtech is an OEM for shuttle, at least according to some 
  > linux usb pages I simply re-purposed an existing Shuttle devices 
  > definitions and now I get the following result:

 If it's actually SCSI, then you you want to attach a "scsibus" not
 an "atapibus", right?

  > umass0 at uhub1 port 3 configuration 1 interface 0
  > umass0: Microtech International, Inc. USB-SCSI-HD50, rev 1.00/1.00, addr 6
  > umass0: using SFF8020i over CBI
  > atapibus0 at umass0 channel 0: 2 targets
  > cd0 at atapibus0 drive 0: <PIONEER, CD-ROM DR-U12X, 1.06> type 5 cdrom removable
  > 
  > unfortunately, I guess one can not connect a tape drive to an atapi bus:
  > 
  > atapibus0 at umass0 channel 0: 2 targets
  > uk0 at atapibus0 drive 0: <Quantum, DLT4000, CC37> type 1 sequential removable
  > uk0: unknown device
  > 
  > 
  > >How-To-Repeat:
  > Attach micotech usb scsi adapter to usb port. attachment of scsi 
  > targets will fail. scsictl scan will not find devices.
  > >Fix:
  > 
  > 
  > Index: umass.c
  > ===================================================================
  > RCS file: /cvsroot/syssrc/sys/dev/usb/umass.c,v
  > retrieving revision 1.61
  > diff -u -r1.61 umass.c
  > --- umass.c     2001/04/26 03:59:32     1.61
  > +++ umass.c     2001/05/03 07:04:01
  > @@ -261,6 +261,27 @@
  >                 return (UMATCH_VENDOR_PRODUCT);
  >         }
  >  
  > +
  > +       if (vendor ==  USB_VENDOR_MICROTECH  &&
  > +            product == USB_PRODUCT_MICROTECH_SCSIHD50
  > +           ) {
  > +
  > +         //                    sc->drive = SHUTTLE_EUSB;
  > +#if CBI_I
  > +               sc->wire_proto = WPROTO_CBI_I;
  > +               sc->cmd_proto = CPROTO_ATAPI;
  > +#else
  > +               sc->wire_proto = WPROTO_CBI;
  > +               sc->cmd_proto = CPROTO_ATAPI;
  > +#endif
  > +               sc->subclass = UISUBCLASS_SFF8020I;
  > +               sc->protocol = UIPROTO_MASS_CBI;
  > +               sc->quirks |= NO_TEST_UNIT_READY | NO_START_STOP;
  > +               return (UMATCH_VENDOR_PRODUCT);
  > +       }
  > +
  > +
  > +
  >         if (vendor == USB_VENDOR_MICROTECH &&
  >             product == USB_PRODUCT_MICROTECH_DPCM) {
  >                 sc->wire_proto = WPROTO_CBI;
  > 
  > 
  > >Release-Note:
  > >Audit-Trail:
  > >Unformatted:

 -- 
         -- Jason R. Thorpe <thorpej@zembu.com>

From: Manuel Bouyer <bouyer@antioche.lip6.fr>
To: waddell@caravan.com
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/12812: Patch needed to add support for Microtech USB-SCSI-HD50 usb scsi adapter
Date: Fri, 4 May 2001 10:11:30 +0200

 BTW, I just added an ATAPI front-end for st in -current. Can you test it with
 your hardware ?

 Thanks !

 --
 Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
 --
Responsible-Changed-From-To: kern-bug-people->bouyer 
Responsible-Changed-By: fair 
Responsible-Changed-When: Fri Jan 4 20:14:25 PST 2002 
Responsible-Changed-Why:  
Manuel Bouyer is our ATAPI expert. 

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: fair@netbsd.org
Cc:  
Subject: Re: kern/12812
Date: Sat, 5 Jan 2002 15:34:53 +0100

 Hum, this one looks more like a USB problem rather than ATAPI too.

 I'll assign both PRs back to kern-bug-people as I don't have much
 clues about what to do in this case.

 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
 --
Responsible-Changed-From-To: kern-bug-people->augustss 
Responsible-Changed-From-To: bouyer->kern-bug-people 
Responsible-Changed-By: bouyer 
Responsible-Changed-When: Sat Jan 5 06:36:10 PST 2002 
Responsible-Changed-Why:  
Looks more like USB than ATAPI problem, and I don't have much clues
about USB.

Responsible-Changed-By: fair 
Responsible-Changed-When: Sun Jan 6 15:19:09 PST 2002 
Responsible-Changed-Why:  
Lennart is our USB expert. 

From: Chris Jones <chris@cjones.org>
To: gnats-bugs@netbsd.org
Cc:  
Subject: Re: kern/12812
Date: Thu, 25 Mar 2004 15:13:14 -0700

 This is a multi-part message in MIME format.
 --------------010401080306070803040508
 Content-Type: text/plain; charset=us-ascii; format=flowed
 Content-Transfer-Encoding: 7bit

 I think the original submitter made a mistake.  I have one of these 
 devices, and it's SCSI, not ATAPI.  The enclosed patch makes it mostly 
 work.  Note that I have no idea if UMASS_WPROTO_CBI_I is correct, but 
 UMASS_CPROTO_ATAPI is certainly wrong; UMASS_CPROTO_SCSI works much better.

 This patch may not be entirely correct, though.  The device only 
 identifies a single SCSI target, when I should have three present. 
 Here's a dmesg excerpt:

 umass0 at uhub1 port 1 configuration 1 interface 0
 umass0: Microtech International, Inc. USB-SCSI-HD50, rev 1.00/1.00, addr 2
 umass0: using SCSI over CBI
 scsibus0 at umass0: 2 targets, 1 luns per target
 scsibus0: waiting 2 seconds for devices to settle...

 Note that it says "2 targets."  I would expect more.

 Chris

 -- 
 Chris Jones               chris@cjones.org                www.cjones.org
      PGP ID 5AFDD40A

 --------------010401080306070803040508
 Content-Type: text/plain;
  name="umass.patch"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: inline;
  filename="umass.patch"

 Index: umass_quirks.c
 ===================================================================
 RCS file: /cvsroot/src/sys/dev/usb/umass_quirks.c,v
 retrieving revision 1.13
 diff -u -w -r1.13 umass_quirks.c
 --- umass_quirks.c	22 Apr 2002 12:48:40 -0000	1.13
 +++ umass_quirks.c	25 Mar 2004 22:07:47 -0000
 @@ -98,6 +98,14 @@
  	  NULL, NULL
  	},

 +        { { USB_VENDOR_MICROTECH, USB_PRODUCT_MICROTECH_SCSIHD50 },
 +          UMASS_WPROTO_CBI_I, UMASS_CPROTO_SCSI,
 +          UMASS_QUIRK_NO_START_STOP,
 +          PQUIRK_NOTUR,
 +          UMATCH_VENDOR_PRODUCT,
 +          umass_init_shuttle, NULL
 +        },
 +
  	{ { USB_VENDOR_MSYSTEMS, USB_PRODUCT_MSYSTEMS_DISKONKEY },
  	  UMASS_WPROTO_UNSPEC, UMASS_CPROTO_UNSPEC,
  	  0,

 --------------010401080306070803040508--

From: "Charles M. Hannum" <abuse@spamalicious.com>
To: Chris Jones <chris@cjones.org>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/12812
Date: Sat, 26 Jun 2004 22:46:47 +0000

 Can you retest this with -current?  If you need a "quirk" at all, you should 
 only need:

  +        { { USB_VENDOR_MICROTECH, USB_PRODUCT_MICROTECH_SCSIHD50 },
  +          UMASS_WPROTO_CBI_I, UMASS_CPROTO_SCSI,
  +          0,
  +          0,
  +          UMATCH_VENDOR_PRODUCT,
  +          umass_init_shuttle, NULL
  +        },

 which is essentially identical to the one for the Shuttle eUSB.  I'd like to 
 know if the forced modes for WPROTO and CPROTO are really necessary, though.

From: Chris Jones <chris@cjones.org>
To: "Charles M. Hannum" <abuse@spamalicious.com>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/12812
Date: Tue, 29 Jun 2004 09:10:03 -0500

 Charles M. Hannum wrote:

 > Can you retest this with -current?  If you need a "quirk" at all, you should 
 > only need:
 > 
 >  +        { { USB_VENDOR_MICROTECH, USB_PRODUCT_MICROTECH_SCSIHD50 },
 >  +          UMASS_WPROTO_CBI_I, UMASS_CPROTO_SCSI,
 >  +          0,
 >  +          0,
 >  +          UMATCH_VENDOR_PRODUCT,
 >  +          umass_init_shuttle, NULL
 >  +        },
 > 
 > which is essentially identical to the one for the Shuttle eUSB.  I'd like to 
 > know if the forced modes for WPROTO and CPROTO are really necessary, though.

 I'm in the process of moving from Montana to DC.  It's going to be a few 
 weeks, at least, before I can test it.

 Chris

 -- 
 Chris Jones               chris@cjones.org                www.cjones.org
      PGP ID 5AFDD40A

Responsible-Changed-From-To: augustss->mycroft 
Responsible-Changed-By: mycroft 
Responsible-Changed-When: Wed Jul 7 20:34:00 UTC 2004 
Responsible-Changed-Why:  
. 

From: Chris Jones <chris@cjones.org>
To: "Charles M. Hannum" <abuse@spamalicious.com>
Cc: gnats-bugs@netbsd.org
Subject: Re: kern/12812
Date: Fri, 20 Aug 2004 17:30:24 -0400

 Charles M. Hannum wrote:

 > Can you retest this with -current?  If you need a "quirk" at all, you should 
 > only need:
 > 
 >  +        { { USB_VENDOR_MICROTECH, USB_PRODUCT_MICROTECH_SCSIHD50 },
 >  +          UMASS_WPROTO_CBI_I, UMASS_CPROTO_SCSI,
 >  +          0,
 >  +          0,
 >  +          UMATCH_VENDOR_PRODUCT,
 >  +          umass_init_shuttle, NULL
 >  +        },
 > 
 > which is essentially identical to the one for the Shuttle eUSB.  I'd like to 
 > know if the forced modes for WPROTO and CPROTO are really necessary, though.

 Unfortunately, I no longer have a SCSI device to test it against.  If 
 memory serves, the device completely fails to be recognized (on any OS) 
 if it's not connected to a SCSI chain.  If there's somebody in the DC 
 area who would like to borrow it for testing, I can hand it off for a 
 while...

 Chris

 -- 
 Chris Jones               chris@cjones.org                www.cjones.org
      PGP ID 5AFDD40A

Responsible-Changed-From-To: mycroft->kern-bug-people
Responsible-Changed-By: wiz@netbsd.org
Responsible-Changed-When: Sun, 03 Sep 2006 01:13:04 +0000
Responsible-Changed-Why:
Back to role account, mycroft doesn't have commit access any longer.


State-Changed-From-To: open->closed
State-Changed-By: mrg@NetBSD.org
State-Changed-When: Fri, 23 Aug 2019 07:19:43 +0000
State-Changed-Why:
problem may be fixed, and submitter no longer had the hardware 15
years ago..  thanks!


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.