NetBSD Problem Report #37403

From martin@duskware.de  Mon Nov 19 09:15:11 2007
Return-Path: <martin@duskware.de>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 54E7A63BA7F
	for <gnats-bugs@gnats.netbsd.org>; Mon, 19 Nov 2007 09:15:11 +0000 (UTC)
Message-Id: <20071119065951.1F27863B88C@narn.NetBSD.org>
Date: Mon, 19 Nov 2007 06:59:51 +0000 (UTC)
From: jpeterson275@comcast.net
Reply-To: jpeterson275@comcast.net
To: netbsd-bugs-owner@NetBSD.org
Subject: USB tape drive Illegal Requests for any use
X-Send-Pr-Version: www-1.0

>Number:         37403
>Category:       kern
>Synopsis:       USB tape drive Illegal Requests for any use
>Confidential:   no
>Severity:       non-critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Nov 19 09:20:00 +0000 2007
>Last-Modified:  Thu Oct 22 23:45:01 +0000 2009
>Originator:     Jesse Peterson
>Release:        NetBSD/amd64 4.0_RC4
>Organization:
>Environment:
NetBSD localhost 4.0_RC4 NetBSD 4.0_RC4 (GENERIC) #0: Thu Nov  8 00:11:53 PST 2007  builds@wb28:/home/builds/ab/netbsd-4-0-RC4/amd64/200711080452Z-obj/home/builds/ab/netbsd-4-0-RC4/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
This is an ATAPI Sony AIT-1 drive (SDX-420C) connected through a USB->ATAPI bridge in a LaCie enclosure.

When attempting to issue basic mt(1) commands such as rewind and offline etc. I typically get these errors:

# mt rewind
mt: /dev/nrst0: Invalid argument

Looking through the kernel messages these show up:

Nov 18 22:38:57 localhost /netbsd: st0(umass0:0:0:0):  Check Condition on CDB: 0x15 00 00 00 0c 00
Nov 18 22:38:57 localhost /netbsd: SENSE KEY:  Illegal Request
Nov 18 22:38:57 localhost /netbsd: ASC/ASCQ:  Invalid Field In Parameter List
Nov 18 22:38:57 localhost /netbsd: SKSV:  Error in Parameters, Offset 9
Nov 18 22:38:57 localhost /netbsd: 
Nov 18 22:38:57 localhost /netbsd: st0: cannot set selected mode

The same error happens for any command or any use (such as with tar, etc.) for this drive. It gets detected as such:

Nov 18 22:37:59 localhost /netbsd: umass0 at uhub4 port 2 configuration 2 interface 0
Nov 18 22:37:59 localhost /netbsd: 
Nov 18 22:38:00 localhost /netbsd: umass0: LaCie LaCie StudioDrive USB2, rev 2.00/11.06, addr 2
Nov 18 22:38:00 localhost /netbsd: umass0: using SCSI over Bulk-Only
Nov 18 22:38:00 localhost /netbsd: scsibus0 at umass0: 2 targets, 1 lun per target
Nov 18 22:38:05 localhost /netbsd: st0 at scsibus0 target 0 lun 0: <SONY, SDX-420C, 0103> tape removable
Nov 18 22:38:05 localhost /netbsd: st0: 
Nov 18 22:38:43 localhost /netbsd: density code 48, 512-byte blocks, write-enabled

uhub4 is an EHCI controller:

uhci0 at pci0 dev 16 function 0: VIA Technologies VT83C572 USB Controller (rev. 
0x81)
...
ehci0 at pci0 dev 16 function 4: VIA Technologies VT8237 EHCI USB Controller (re
v. 0x86)
ehci0: interrupting at ioapic0 pin 21 (irq 11)
ehci0: BIOS has given up ownership
ehci0: EHCI version 1.0
ehci0: companion controllers, 2 ports each: uhci0 uhci1 uhci2 uhci3
usb4 at ehci0: USB revision 2.0
uhub4 at usb4

NetBSD/amd64 4.0_RC4 (though have seen problem in 3.1 and 4.0_RC3, too, including i386):
NetBSD localhost 4.0_RC4 NetBSD 4.0_RC4 (GENERIC) #0: Thu Nov  8 00:11:53 PST 2007  builds@wb28:/home/builds/ab/netbsd-4-0-RC4/amd64/200711080452Z-obj/home/builds/ab/netbsd-4-0-RC4/src/sys/arch/amd64/compile/GENERIC amd64

I attempted and failed to turn on SCSIPI debugging to try and get further with this.
>How-To-Repeat:
Attempt to use in any way the above USB tape drive with NetBSD.
>Fix:

>Audit-Trail:
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
	netbsd-bugs@NetBSD.org
Subject: Re: kern/37403: USB tape drive Illegal Requests for any use
Date: Sun, 2 Dec 2007 20:30:38 +0100

 On Mon, Nov 19, 2007 at 09:20:00AM +0000, jpeterson275@comcast.net wrote:
 > >Number:         37403
 > >Category:       kern
 > >Synopsis:       USB tape drive Illegal Requests for any use
 > >Confidential:   no
 > >Severity:       non-critical
 > >Priority:       high
 > >Responsible:    kern-bug-people
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Mon Nov 19 09:20:00 +0000 2007
 > >Originator:     Jesse Peterson
 > >Release:        NetBSD/amd64 4.0_RC4
 > >Organization:
 > >Environment:
 > NetBSD localhost 4.0_RC4 NetBSD 4.0_RC4 (GENERIC) #0: Thu Nov  8 00:11:53 PST 2007  builds@wb28:/home/builds/ab/netbsd-4-0-RC4/amd64/200711080452Z-obj/home/builds/ab/netbsd-4-0-RC4/src/sys/arch/amd64/compile/GENERIC amd64
 > >Description:
 > This is an ATAPI Sony AIT-1 drive (SDX-420C) connected through a USB->ATAPI bridge in a LaCie enclosure.
 > 
 > When attempting to issue basic mt(1) commands such as rewind and offline etc. I typically get these errors:
 > 
 > # mt rewind
 > mt: /dev/nrst0: Invalid argument
 > 
 > Looking through the kernel messages these show up:
 > 
 > Nov 18 22:38:57 localhost /netbsd: st0(umass0:0:0:0):  Check Condition on CDB: 0x15 00 00 00 0c 00
 > Nov 18 22:38:57 localhost /netbsd: SENSE KEY:  Illegal Request
 > Nov 18 22:38:57 localhost /netbsd: ASC/ASCQ:  Invalid Field In Parameter List
 > Nov 18 22:38:57 localhost /netbsd: SKSV:  Error in Parameters, Offset 9
 > Nov 18 22:38:57 localhost /netbsd: 
 > Nov 18 22:38:57 localhost /netbsd: st0: cannot set selected mode
 > 
 > The same error happens for any command or any use (such as with tar, etc.) for this drive. It gets detected as such:
 > 
 > Nov 18 22:37:59 localhost /netbsd: umass0 at uhub4 port 2 configuration 2 interface 0
 > Nov 18 22:37:59 localhost /netbsd: 
 > Nov 18 22:38:00 localhost /netbsd: umass0: LaCie LaCie StudioDrive USB2, rev 2.00/11.06, addr 2
 > Nov 18 22:38:00 localhost /netbsd: umass0: using SCSI over Bulk-Only
 > Nov 18 22:38:00 localhost /netbsd: scsibus0 at umass0: 2 targets, 1 lun per target
 > Nov 18 22:38:05 localhost /netbsd: st0 at scsibus0 target 0 lun 0: <SONY, SDX-420C, 0103> tape removable
 > Nov 18 22:38:05 localhost /netbsd: st0: 
 > Nov 18 22:38:43 localhost /netbsd: density code 48, 512-byte blocks, write-enabled

 The problem here is that the drive appear as SCSI to the system, while it's
 really an ATAPI drive. A few things have to be handled differently between
 SCSI and ATAPI drives, and in your case the wrong code is used.
 I don't know how to handle it in the driver, as there's nothing to tell
 us here that it's an ATAPI device in an enclosure that makes it appear as
 SCSI. It would probably work if it was in an USB enclosure using the UFI
 or ATAPI protocol ...

 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --

From: Jesse Peterson <jpeterson275@comcast.net>
To: gnats-bugs@NetBSD.org
Cc: Manuel Bouyer <bouyer@antioche.eu.org>,
	kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/37403: USB tape drive Illegal Requests for any use
Date: Mon, 3 Dec 2007 23:19:05 -0800

 Can you expound on what is needed and this "code" is or point me to more information? I'd be interesting in finding a solution to this. I'm not sure what the "parameter list" is with regard to ASC/ASCQ and where in the source things related to this might be. I tried to turn on SCSIPI debugging unsuccessfully.

 I pulled the enclosure apart and found that the USB-to-ATA interface chip is an In-System/Cypress ISD300 ASIC. The 1394 400Mbps ports on the drive are driven by an Oxford OXF911 chip however I cannot use the firewire ports on this machine due to kern/37411.

 Thanks,
 - Jesse

 On Sun,  2 Dec 2007 19:35:03 +0000 (UTC)
 Manuel Bouyer <bouyer@antioche.eu.org> wrote:

 >  The problem here is that the drive appear as SCSI to the system, while it's
 >  really an ATAPI drive. A few things have to be handled differently between
 >  SCSI and ATAPI drives, and in your case the wrong code is used.
 >  I don't know how to handle it in the driver, as there's nothing to tell
 >  us here that it's an ATAPI device in an enclosure that makes it appear as
 >  SCSI. It would probably work if it was in an USB enclosure using the UFI
 >  or ATAPI protocol ...

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Jesse Peterson <jpeterson275@comcast.net>
Cc: gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org,
	gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/37403: USB tape drive Illegal Requests for any use
Date: Tue, 4 Dec 2007 09:37:23 +0100

 On Mon, Dec 03, 2007 at 11:19:05PM -0800, Jesse Peterson wrote:
 > Can you expound on what is needed and this "code" is or point me to more information? I'd be interesting in finding a solution to this. I'm not sure what the "parameter list" is with regard to ASC/ASCQ and where in the source things related to this might be. I tried to turn on SCSIPI debugging unsuccessfully.


 Look at src/sys/dev/scsipi/st_atapi.c, all should be there. The problem is
 that your enclosure presents to the host a scsibus, not an atapibus.

 -- 
 Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
      NetBSD: 26 ans d'experience feront toujours la difference
 --

From: Jesse Peterson <jpeterson275@comcast.net>
To: gnats-bugs@NetBSD.org
Cc: Manuel Bouyer <bouyer@antioche.eu.org>,
	kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/37403: USB tape drive Illegal Requests for any use
Date: Mon, 10 Dec 2007 19:42:38 -0800

 On Tue,  4 Dec 2007 08:40:02 +0000 (UTC)
 Manuel Bouyer <bouyer@antioche.eu.org> wrote:

 >  On Mon, Dec 03, 2007 at 11:19:05PM -0800, Jesse Peterson wrote:
 >  > Can you expound on what is needed and this "code" is or point me to more information? I'd be interesting in finding a solution to this. I'm not sure what the "parameter list" is with regard to ASC/ASCQ and where in the source things related to this might be. I tried to turn on SCSIPI debugging unsuccessfully.
 >  
 >  
 >  Look at src/sys/dev/scsipi/st_atapi.c, all should be there. The problem is
 >  that your enclosure presents to the host a scsibus, not an atapibus.

 I'm not sure why this is a problem? Is the problem that NetBSD inherently can't support ATAPI devices on pseudo-SCSI buses or is it that this particular enclosure doesn't work? The drive was sold as it is (ie, it's not an aftermarket enclosure) in this enclosure and it does work on other OSs.

 Thanks,
 - Jesse

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Jesse Peterson <jpeterson275@comcast.net>
Cc: gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org,
	gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/37403: USB tape drive Illegal Requests for any use
Date: Tue, 11 Dec 2007 10:41:49 +0100

 On Mon, Dec 10, 2007 at 07:42:38PM -0800, Jesse Peterson wrote:
 > On Tue,  4 Dec 2007 08:40:02 +0000 (UTC)
 > Manuel Bouyer <bouyer@antioche.eu.org> wrote:
 > 
 > >  On Mon, Dec 03, 2007 at 11:19:05PM -0800, Jesse Peterson wrote:
 > >  > Can you expound on what is needed and this "code" is or point me to more information? I'd be interesting in finding a solution to this. I'm not sure what the "parameter list" is with regard to ASC/ASCQ and where in the source things related to this might be. I tried to turn on SCSIPI debugging unsuccessfully.
 > >  
 > >  
 > >  Look at src/sys/dev/scsipi/st_atapi.c, all should be there. The problem is
 > >  that your enclosure presents to the host a scsibus, not an atapibus.
 > 
 > I'm not sure why this is a problem? Is the problem that NetBSD inherently can't support ATAPI devices on pseudo-SCSI buses or is it that this particular enclosure doesn't work? The drive was sold as it is (ie, it's not an aftermarket enclosure) in this enclosure and it does work on other OSs.

 The problem is that the driver has no ways to know that this is an ATAPI
 device and not a SCSI one (the enclosure announce itself as SCSI). Maybe
 other OSes have specific drivers for this device, or a quirk list.

 -- 
 Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
      NetBSD: 26 ans d'experience feront toujours la difference
 --

From: Jesse Peterson <jpeterson275@comcast.net>
To: gnats-bugs@NetBSD.org
Cc: Manuel Bouyer <bouyer@antioche.eu.org>, kern-bug-people@netbsd.org,
 gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/37403: USB tape drive Illegal Requests for any use
Date: Mon, 19 Oct 2009 09:25:22 -0700

 After finally getting a chance to pick this up again I've found an (ugly) solution to this issue.

 The problem in the logs here seem to indicate a SCSI error when attempting to MODE SELECT. After some investigation into the details of that it eventually came to be that the block size was getting set to 0 and thus reported as such to the MODE SELECT SCSI command. I'm not sure if this is because the value is not between the allowed block size (2 <= blksize <= 16777215) or because the blksize is not changanble (the change mask a la PC field is not queried in the MODE SENSE) or what. What I do know is that the tape drive seems to start working great when this patch is applied:

 --- sys/dev/scsipi/st.c.orig	2008-11-19 18:50:27.000000000 -0800
 +++ sys/dev/scsipi/st.c	2009-10-19 08:48:50.000000000 -0700
 @@ -1024,10 +1024,24 @@
  	 * We're getting no hints from any direction.  Choose variable-
  	 * length blocks arbitrarily.
  	 */
 +	/*
  	st->flags &= ~ST_FIXEDBLOCKS;
  	st->blksize = 0;
  	SC_DEBUG(st->sc_periph, SCSIPI_DB3,
  	    ("Give up and default to variable mode\n"));
 +	 */
 +
 +	/* force block size */
 +	if (st->media_blksize > 0)
 +		st->flags |= ST_FIXEDBLOCKS;
 +	else
 +		st->flags &= ~ST_FIXEDBLOCKS;
 +	st->blksize = st->media_blksize;
 +	SC_DEBUG(st->sc_periph, SCSIPI_DB3,
 +		("Give up and default to media_blksize of %d\n", st->media_blksize));
 +	goto done;
 +
 +	

  done:
  	/*

 Which successfully does the MODE SELECT with the right block size (512 in this device's case).

 Now obviously this isn't good for all devices (as implemented in this patch) - just note that it works for this hardware. I'm not sure if this particular drive cannot do variable-sized blocks (in which case a drive quirk would work okay I think) or this is an artifact of the In-System ISD-300 ATAPI-to-USB SCSI over Bulk-Only adapter chip that this is using. I think it is the former because the same exact issue come ups when I use the drive over FireWire which uses an Oxford 911 IEEE1394 adapter chip (which also does SCSI over SBP-2).

 I think the right solution is to do a drive quirk only if the drive is not directly SCSI attached? While I couldn't find any definitive docs this is a somewhat modern drive (AIT-1) which makes me think variable blocks (0 size) shouldn't be a problem.

 P.S. As an aside why do ATAPI drives not do an actual MODE SELECT command? The function returns an error when it is attempted for ATAPI tape drive.

From: Jesse Peterson <jpeterson275@comcast.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/37403
Date: Thu, 22 Oct 2009 16:40:47 -0700

 After looking into this even more I've come to the conclusion that this drive
 has some quirks. The major quirk that this PR is about is its odd MODE SELECT
 block size handling. Basically one cannot set the block size to 0 (variable-
 block mode) in the MODE SELECT. One receives a CHECK CONDITION. However within
 the drive's READ BLOCK LIMITs (2 <= blksize <= 16777215) you can change the
 drive's blocking size.

 That said the st(4) drive makes an assumption/guess on variable sized blocks
 at the end of the open() call. Which of course fails and since one needs to
 open the device to ioctl() to change the block size there's a bit of a catch-
 22 in there. So the I made a patch, below, which adds a quirk to use the drive's
 MODE SENSEd media block size instead of guessing variable block size.

 Perhaps a better approach would be to try variable then fall-back on media-size
 (which has the possibility of working not just for this quirky drive but others
 with similar problems). I have a vision of a one-day unified SCSI/ATAPI tape
 driver. :)

 The manual (which describes the drive's ATAPI command interface and of most
 interest its description of the MODE SENSE and MODE SELECT commands) says that
 the drive should support a zero blocksize (variable) setting and together with
 the "fixed" bit in the READ/WRITE CDBs should be enough to use it. However
 we get CHECK CONDITIONs when I try to set it. This happens over USB Bulk-Only
 and IEEE 1394 SBP-2, so I doubt it would be any different when ATAPI-attached.

 Manual linked here:
 http://sony.storagesupport.com/node/394


 See also related PR kern/42214.

 Patch: 

 --- st.c.orig	2008-11-19 18:50:27.000000000 -0800
 +++ st.c	2009-10-22 16:34:41.000000000 -0700
 @@ -306,6 +306,13 @@
  		{0, 0, 0},			       /* minor 8-11 */
  		{0, 0, 0}			       /* minor 12-15 */
  	}}},
 +	{{T_SEQUENTIAL, T_REMOV,
 +	 "SONY", "SDX-420C", "0103"},     {ST_Q_BLKMEDIA, 0, {
 +		{0, 0, 0},			       /* minor 0-3 */
 +		{0, 0, 0},			       /* minor 4-7 */
 +		{0, 0, 0},			       /* minor 8-11 */
 +		{0, 0, 0}			       /* minor 12-15 */
 +	}}},
  };

  #define NOEJECT 0
 @@ -1020,14 +1027,24 @@
  		    ("Used media_blksize of %d\n", st->media_blksize));
  		goto done;
  	}
 -	/*
 -	 * We're getting no hints from any direction.  Choose variable-
 -	 * length blocks arbitrarily.
 -	 */
 -	st->flags &= ~ST_FIXEDBLOCKS;
 -	st->blksize = 0;
 -	SC_DEBUG(st->sc_periph, SCSIPI_DB3,
 -	    ("Give up and default to variable mode\n"));
 +	else if (st->quirks & ST_Q_BLKMEDIA)
 +	{
 +		st->flags |= ST_FIXEDBLOCKS;
 +		st->blksize = st->media_blksize;
 +		SC_DEBUG(st->sc_periph, SCSIPI_DB3,
 +			("Used media_blksize of %d\n", st->media_blksize));
 +	}
 +	else
 +	{
 +		/*
 +		 * We're getting no hints from any direction.  Choose variable-
 +		 * length blocks arbitrarily.
 +		 */
 +		st->flags &= ~ST_FIXEDBLOCKS;
 +		st->blksize = 0;
 +		SC_DEBUG(st->sc_periph, SCSIPI_DB3,
 +			("Give up and default to variable mode\n"));
 +	}

  done:
  	/*
 --- stvar.h.orig	2008-04-28 13:23:58.000000000 -0700
 +++ stvar.h	2009-10-22 16:35:17.000000000 -0700
 @@ -79,6 +79,7 @@
  #define	ST_Q_NOPREVENT		0x0020	/* does not support PREVENT */
  #define	ST_Q_ERASE_NOIMM	0x0040	/* drive rejects ERASE/w Immed bit */
  #define	ST_Q_NOFILEMARKS	0x0080	/* can only write 0 filemarks */
 +#define	ST_Q_BLKMEDIA		0x0100	/* try the media/sense block size */
  	u_int page_0_size;
  #define	MAX_PAGE_0_SIZE	64
  	struct modes modes[4];

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.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.