Hi Matt,
.... I already did switch on the logging (that is how I found the
solution).
This is the log without my patch, i.e. the blocking case (see
attachment: usb-storage-nok.log):
you see that the process usb_storage went to sleep after having received
the result
0x70000 (=DID_ERROR<<16)
which is not explicitly handled in the code:
Apr 1 15:02:31 Mahrmaid kernel: usb-storage: scsi cmd done,
result=0x70000
Apr 1 15:02:31 Mahrmaid kernel: usb-storage: *** thread sleeping.
>From here it never wakes up. After my patch (not asking for command
completion in
this case )
the process continues and everything goes fine.
On the hub question: Sorry, I bought a "advance USB 2.0 PCI Business"
PCI card. I had
no idea that there is a hub on the card (is it?) it has just got 4 USB
connectors (3
on the back, 1 inside the PC) and it seems to have a NEC chip on it.
/proc/bus/usb/devices says:
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 5
B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS= 8 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 2.40
S: Manufacturer=Linux 2.4.19-pre5 ehci-hcd
S: Product=NEC Corporation USB 2.0
S: SerialNumber=00:12.2
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=256ms
Do we have to handle other srb->results the same way? shall we introduce
a case
statement here to catch all the cases? I am not so familiar with the
SCSI emulation to
know in which cases a command completion is meaningful
and when it should no be completed. Perhaps other reactions are better.
At lease we should prevent waiting forever here.....
What do you think?
Christian
Matthew Dharm wrote:
Sorry for the repeat, but I got Christian's address wrong the first
time.
>
> Matt
>
> On Mon, Apr 01, 2002 at 11:26:52AM -0800, Matthew Dharm wrote:
> > Hrm... looking at this, should a command that ended in DID_ERROR get
> > completed? I thought it should, as the SCSI layer needs to know
that it
> > ended in error.
> >
> > So why is the SCSI layer waiting?
> >
> > Christian, can you recompile your kernel with USB Mass Storage
Verbose
> > Debugging turned on? Also, can you attach the unit directly to your
PC,
> > not to the USB 2.0 hub? There are reports that USB 2.0 hubs are not
well
> > supported yet.
> >
> > Matt
> >
> > On Mon, Apr 01, 2002 at 11:17:38AM -0800, Matthew Dharm wrote:
> > > Bjorn, is this needed?
> > >
> > > Actually, this could be notable... are we properly testing all the
codes in
> > > us->srb->result?
> > >
> > > Matt
> > >
> > > ----- Forwarded message from Christian Mahr
<[EMAIL PROTECTED]> -----
> > >
> > > Date: Mon, 01 Apr 2002 17:05:17 +0200
> > > From: Christian Mahr <[EMAIL PROTECTED]>
> > > Subject: Re: [linux-usb-devel] problems with ARCHOS jukebox
recorder 20 on USB
> > > To: David Brownell <[EMAIL PROTECTED]>,
> > > [EMAIL PROTECTED]
> > > X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-pre5 i586)
> > > List-Id: <linux-usb-devel.lists.sourceforge.net>
> > > X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH
version=2.11
> > >
> > > Hi David, hi all,
> > >
> > > I found the problem which makes the scsi_eh_1 get stuck when
connecting the
> > > ARCHOS Jukebox on th fly:
> > >
> > > The problem is that the lower layers do return a scsi-cmd with
"DID_ERROR<<16
> > > (=0x70000)", but the usb-storage insists to complete the command
instead, thus
> > > waiting forever.
> > >
> > > The following patch to usb.c does it for me.
> > >
> > > --- usb.c Mon Apr 1 16:08:31 2002
> > > +++ usb.c.org Mon Apr 1 16:07:15 2002
> > > @@ -461,9 +461,7 @@
> > > up(&(us->dev_semaphore));
> > >
> > > /* indicate that the command is done */
> > > -/*cm 01-Apr-02: allow also DID_ERROR as premature abort of
command */
> > > - if ((us->srb->result != DID_ABORT << 16)
&&
> > > (us->srb->result != DID_ERROR << 16)) {
> > > -/* original line: if (us->srb->result != DID_ABORT << 16) {
*/
> > > + if (us->srb->result != DID_ABORT << 16) {
> > > US_DEBUGP("scsi cmd done,
result=0x%x\n",
> > > us->srb->result);
> > >
set_current_state(TASK_INTERRUPTIBLE);
> > >
> > >
> > > Perhaps this is not the only error situation where a command is
not completed?
> > >
> > > At least, this solution retries the SCSI command now and the
driver becomes
> > > properly connected on the 2nd try.
> > >
> > > Who of you can introduce this change into the current code?
> > >
> > > Christian
> > >
> > >
> > > Christian Mahr wrote:
> > >
> > > > Hi David,
> > > >
> > > > I just tried 2.4.19-pre5 and I do notice the same effects:
> > > >
> > > > ps -ax (excerpt):
> > > > 3616 ? SW 0:00 [khubd]
> > > > 3646 ? Z 0:00 [cron <defunct>]
> > > > 3648 ? S 0:00 /bin/bash /etc/hotplug/usb.agent
> > > > 3667 ? D 0:00 /sbin/modprobe -vs usb-storage
> > > > 3668 ? SW 0:00 [usb-storage-0]
> > > > 3669 ? DW 0:00 [scsi_eh_1]
> > > > 3671 pts/3 R 0:00 ps ax
> > > >
> > > > So this time modprobe usb-storage and scsi_eh_1 are blocked...
> > > >
> > > > /var/log/messages gives the following:
> > > > Apr 1 11:58:50 Mahrmaid kernel: hcd.c: ehci-hcd @ 00:12.2, NEC
Corporation
> > > > USB 2.0
> > > > Apr 1 11:58:50 Mahrmaid kernel: hcd.c: PCI latency reduced to
max 34
> > > > Apr 1 11:58:50 Mahrmaid kernel: hcd.c: irq 11, pci mem ceae2000
> > > > Apr 1 11:58:50 Mahrmaid kernel: usb.c: new USB bus registered,
assigned bus
> > > > number 1
> > > > Apr 1 11:58:50 Mahrmaid kernel: ehci-dbg.c: ehci_start
hcs_params 0x2395
> > > > dbg=0 cc=2 pcc=3 ports=5
> > > > Apr 1 11:58:50 Mahrmaid kernel: ehci-dbg.c: 00:12.2: ehci_start
portroute 1
> > > > 0 1 0 0
> > > > Apr 1 11:58:50 Mahrmaid kernel: ehci-dbg.c: ehci_start
hcc_params 0x0002
> > > > caching 0 uframes 256/512/1024
> > > > Apr 1 11:58:50 Mahrmaid kernel: ehci-hcd.c: reset 80002 cmd
(park)=0
> > > > ithresh=8 period=1024 Reset HALT
> > > > Apr 1 11:58:50 Mahrmaid kernel: ehci-hcd.c: init 10000 cmd
(park)=0
> > > > ithresh=1 period=1024 HALT
> > > > Apr 1 11:58:50 Mahrmaid kernel: ehci-hcd.c: USB 2.0 support
enabled, EHCI
> > > > rev 0.95
> > > > Apr 1 11:58:50 Mahrmaid kernel: hcd.c: 00:12.2 root hub device
address 1
> > > > Apr 1 11:58:50 Mahrmaid kernel: usb.c: kmalloc IF c340f880,
numif 1
> > > > Apr 1 11:58:50 Mahrmaid kernel: usb.c: new device strings:
Mfr=3, Product=2,
> > > > SerialNumber=1
> > > > Apr 1 11:58:50 Mahrmaid kernel: usb.c: USB device number 1
default language
> > > > ID 0x0
> > > > Apr 1 11:58:50 Mahrmaid kernel: Manufacturer: Linux 2.4.19-pre5
ehci-hcd
> > > > Apr 1 11:58:50 Mahrmaid kernel: Product: NEC Corporation USB
2.0
> > > > Apr 1 11:58:50 Mahrmaid kernel: SerialNumber: 00:12.2
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: USB hub found
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: 5 ports detected
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: standalone hub
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: individual port power
switching
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: individual port
over-current
> > > > protection
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: Single TT
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: TT requires at most 8 FS
bit times
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: Port indicators are not
supported
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: power on to power good
time: 0ms
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: hub controller current
requirement:
> > > > 0mA
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: port removable status:
RRRRR
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: local power source is
good
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: no over-current
condition exists
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: enabling power on all
ports
> > > > Apr 1 11:58:50 Mahrmaid kernel: usb.c: hub driver claimed
interface c340f880
> > > >
> > > > Apr 1 11:58:50 Mahrmaid kernel: usb.c: kusbd: /sbin/hotplug add
1
> > > > Apr 1 11:59:00 Mahrmaid /USR/SBIN/CRON[3647]: (root) CMD ( rm
-f
> > > > /var/spool/cron/lastrun/cron.hourly)
> > > > Apr 1 11:59:04 Mahrmaid kernel: ehci-hub.c: GetStatus port 1
status 0x1803
> > > > POWER speed=2 CSC CONNECT
> > > > Apr 1 11:59:04 Mahrmaid kernel: hub.c: port 1, portstatus 501,
change 1, 480
> > > > Mb/s
> > > > Apr 1 11:59:04 Mahrmaid kernel: hub.c: port 1 connection change
> > > > Apr 1 11:59:04 Mahrmaid kernel: hub.c: port 1, portstatus 501,
change 1, 480
> > > > Mb/s
> > > > Apr 1 11:59:04 Mahrmaid kernel: hub.c: port 1, portstatus 501,
change 0, 480
> > > > Mb/s
> > > > Apr 1 11:59:04 Mahrmaid last message repeated 3 times
> > > > Apr 1 11:59:04 Mahrmaid kernel: hub.c: port 1, portstatus 511,
change 0, 480
> > > > Mb/s
> > > > Apr 1 11:59:04 Mahrmaid kernel: hub.c: port 1 of hub 1 not
reset yet,
> > > > waiting 10ms
> > > > Apr 1 11:59:04 Mahrmaid kernel: hub.c: port 1, portstatus 511,
change 0, 480
> > > > Mb/s
> > > > Apr 1 11:59:04 Mahrmaid kernel: hub.c: port 1 of hub 1 not
reset yet,
> > > > waiting 10ms
> > > > Apr 1 11:59:04 Mahrmaid kernel: ehci-hub.c: 00:12.2 port 1 high
speed
> > > > Apr 1 11:59:04 Mahrmaid kernel: ehci-hub.c: GetStatus port 1
status 0x1005
> > > > POWER speed=0 PE CONNECT
> > > > Apr 1 11:59:04 Mahrmaid kernel: hub.c: port 1, portstatus 503,
change 10,
> > > > 480 Mb/s
> > > > Apr 1 11:59:04 Mahrmaid kernel: hub.c: USB new device connect
on bus1/1,
> > > > assigned device number 2
> > > > Apr 1 11:59:05 Mahrmaid kernel: usb.c: kmalloc IF c340f980,
numif 1
> > > > Apr 1 11:59:05 Mahrmaid kernel: usb.c: new device strings:
Mfr=73,
> > > > Product=90, SerialNumber=110
> > > > Apr 1 11:59:05 Mahrmaid kernel: usb.c: USB device number 2
default language
> > > > ID 0x409
> > > > Apr 1 11:59:05 Mahrmaid kernel: Manufacturer: ARCHOS
> > > > Apr 1 11:59:05 Mahrmaid kernel: Product: ARCHOS USB2.0 (P4a)
> > > > Apr 1 11:59:05 Mahrmaid kernel: SerialNumber: wwww.archos.comA
> > > > Apr 1 11:59:05 Mahrmaid kernel: usb.c: unhandled interfaces on
device
> > > > Apr 1 11:59:05 Mahrmaid kernel: usb.c: USB device 2 (vend/prod
0x5ab/0x60)
> > > > is not claimed by any active driver.
> > > > Apr 1 11:59:05 Mahrmaid kernel: Length = 18
> > > > Apr 1 11:59:05 Mahrmaid kernel: DescriptorType = 01
> > > > Apr 1 11:59:05 Mahrmaid kernel: USB version = 2.00
> > > > Apr 1 11:59:05 Mahrmaid kernel: Vendor:Product =
05ab:0060
> > > > Apr 1 11:59:05 Mahrmaid kernel: MaxPacketSize0 = 64
> > > > Apr 1 11:59:05 Mahrmaid kernel: NumConfigurations = 1
> > > > Apr 1 11:59:05 Mahrmaid kernel: Device version = 11.01
> > > > Apr 1 11:59:05 Mahrmaid kernel: Device
Class:SubClass:Protocol = 00:00:00
> > > > Apr 1 11:59:05 Mahrmaid kernel: Per-interface classes
> > > > Apr 1 11:59:05 Mahrmaid kernel: Configuration:
> > > > Apr 1 11:59:05 Mahrmaid kernel: bLength = 9
> > > > Apr 1 11:59:05 Mahrmaid kernel: bDescriptorType = 02
> > > > Apr 1 11:59:05 Mahrmaid kernel: wTotalLength = 0027
> > > > Apr 1 11:59:05 Mahrmaid kernel: bNumInterfaces = 01
> > > > Apr 1 11:59:05 Mahrmaid kernel: bConfigurationValue = 02
> > > > Apr 1 11:59:05 Mahrmaid kernel: iConfiguration = 00
> > > > Apr 1 11:59:05 Mahrmaid kernel: bmAttributes = c0
> > > > Apr 1 11:59:05 Mahrmaid kernel: MaxPower = 98mA
> > > > Apr 1 11:59:05 Mahrmaid kernel:
> > > > Apr 1 11:59:05 Mahrmaid kernel: Interface: 0
> > > > Apr 1 11:59:05 Mahrmaid kernel: Alternate Setting: 0
> > > > Apr 1 11:59:05 Mahrmaid kernel: bLength = 9
> > > > Apr 1 11:59:05 Mahrmaid kernel: bDescriptorType = 04
> > > > Apr 1 11:59:05 Mahrmaid kernel: bInterfaceNumber = 00
> > > > Apr 1 11:59:05 Mahrmaid kernel: bAlternateSetting = 00
> > > > Apr 1 11:59:05 Mahrmaid kernel: bNumEndpoints = 03
> > > > Apr 1 11:59:05 Mahrmaid kernel: bInterface
Class:SubClass:Protocol =
> > > > 08:06:50
> > > > Apr 1 11:59:05 Mahrmaid kernel: iInterface = 00
> > > > Apr 1 11:59:05 Mahrmaid kernel: Endpoint:
> > > > Apr 1 11:59:05 Mahrmaid kernel: bLength =
7
> > > > Apr 1 11:59:05 Mahrmaid kernel: bDescriptorType =
05
> > > > Apr 1 11:59:05 Mahrmaid kernel: bEndpointAddress =
01 (out)
> > > > Apr 1 11:59:05 Mahrmaid kernel: bmAttributes =
02 (Bulk)
> > > > Apr 1 11:59:05 Mahrmaid kernel: wMaxPacketSize =
0200
> > > > Apr 1 11:59:05 Mahrmaid kernel: bInterval =
01
> > > > Apr 1 11:59:05 Mahrmaid kernel: Endpoint:
> > > > Apr 1 11:59:05 Mahrmaid kernel: bLength =
7
> > > > Apr 1 11:59:05 Mahrmaid kernel: bDescriptorType =
05
> > > > Apr 1 11:59:05 Mahrmaid kernel: bEndpointAddress =
82 (in)
> > > > Apr 1 11:59:05 Mahrmaid kernel: bmAttributes =
02 (Bulk)
> > > > Apr 1 11:59:05 Mahrmaid kernel: wMaxPacketSize =
0200
> > > > Apr 1 11:59:05 Mahrmaid kernel: bInterval =
01
> > > > Apr 1 11:59:05 Mahrmaid kernel: Endpoint:
> > > > Apr 1 11:59:05 Mahrmaid kernel: bLength =
7
> > > > Apr 1 11:59:05 Mahrmaid kernel: bDescriptorType =
05
> > > > Apr 1 11:59:05 Mahrmaid kernel: bEndpointAddress =
83 (in)
> > > > Apr 1 11:59:05 Mahrmaid kernel: bmAttributes =
03 (Interrupt)
> > > >
> > > > Apr 1 11:59:05 Mahrmaid kernel: wMaxPacketSize =
0002
> > > > Apr 1 11:59:05 Mahrmaid kernel: bInterval =
09
> > > > Apr 1 11:59:05 Mahrmaid kernel: usb.c: kusbd: /sbin/hotplug add
2
> > > > Apr 1 11:59:05 Mahrmaid kernel: hub.c: port 2, portstatus 100,
change 0, 12
> > > > Mb/s
> > > > Apr 1 11:59:05 Mahrmaid kernel: hub.c: port 3, portstatus 100,
change 0, 12
> > > > Mb/s
> > > > Apr 1 11:59:05 Mahrmaid kernel: hub.c: port 4, portstatus 100,
change 0, 12
> > > > Mb/s
> > > > Apr 1 11:59:05 Mahrmaid kernel: hub.c: port 5, portstatus 100,
change 0, 12
> > > > Mb/s
> > > > Apr 1 11:59:05 Mahrmaid kernel: Initializing USB Mass Storage
driver...
> > > > Apr 1 11:59:05 Mahrmaid kernel: usb.c: registered new driver
usb-storage
> > > > Apr 1 11:59:05 Mahrmaid kernel: scsi1 : SCSI emulation for USB
Mass Storage
> > > > devices
> > > > Apr 1 11:59:11 Mahrmaid kernel: ehci-hcd.c: 00:12.2 urb_dequeue
ca353840 qh
> > > > state 1
> > > > Apr 1 11:59:11 Mahrmaid kernel: hcd.c: giveback urb ca353840
status -104
> > > > Apr 1 11:59:15 Mahrmaid kernel: ehci-q.c: ep 2-in qtd token
000d8d50 -->
> > > > status -75
> > > > Apr 1 11:59:15 Mahrmaid kernel: hcd.c: giveback urb ca353840
status -75
> > > >
> > > > with these error messages -104 and -75, the whole thing gets
stuck.
> > > > /proc/scsi/scsi is incomplete:
> > > >
> > > > Host: scsi1 Channel: 00 Id: 00 Lun: 00
> > > > Vendor: Model: Rev:
> > > > Type: <NULL> ANSI SCSI revision: ffffffff
> > > >
> > > > In my understanding the origin migth be misbehavior of the drive
when
> > > > connected after start of the usb drivers.
> > > >
> > > > I believe that usb-storage might wait for something forever
which does not
> > > > happen because of errors
> > > > on lower layers. anyhow, I believe that waiting forever is wrong
here, don't
> > > > we need some timeouts here?
> > > >
> > > > How can I processd debugging? Do you want me to generate more
information?
> > > > how?
> > > > How can I attach to the modules in "d" state? can I used gdb for
this?
> > > >
> > > > Thanks for helping
> > > > Christian
> > > >
> > > > David Brownell wrote:
> > > >
> > > > > > > Do the startup problems happen when you use USB 1.1
speeds,
> > > > > > > only using an OHCI or UHCI host controller driver (not
ehci-hcd)?
> > > > > > >
> > > > > >
> > > > > > yes, same problem.
> > > > >
> > > > > Highly suggestive of a device bug/quirk ...
> > > > >
> > > > > > > http://www.archos.com/us/products/product_500277.html
> > > > > > >
> > > > > > > doesn't say the device has been USB 2.0 qualified, and
does
> > > > > > > not use the USB 2.0 logo. It's not listed on the
www.usb.org
> > > > > > > page of products that are compliant. That's suggestive
... it'd
> > > > > > > be worth contacting Archos to ask what gives. (USB 2.0
has
> > > > > > > a compliance program for good reasons ... :)
> > > > > >
> > > > > > The logo is on the drive...?
> > > > >
> > > > > The new red/blue "compliant" logo? It's not on the web page,
> > > > > which is surprising. Instead Archos has their own logo,
which
> > > > > doesn't indicate compliance ...
> > > > >
> > > > > > > Sounds somewhat right to me, I've seen that failure mode.
> > > > > > > So far nothing seems to suggest it's trouble in EHCI.
> > > > > >
> > > > > > Just want to mention: even if the drive itself misbehaves,
the driver
> > > > > > should not become stuck forever in "D " or DW" state.
> > > > > > In my situation, I have to re-boot to restart usb. Killing
the processes
> > > > > > doesn't work.
> > > > >
> > > > > Agreed; yes, that's a nasty usb-storage failure mode.
> > > > >
> > > > > > > You might try this on a more recent kernel (2.4.19-pre5?),
and try
> > > > > > > enabling mass storage debug to get more info. Matt
recently posted
> > > > > > > some rework of that exception handling code, and it's also
possible
> > > > > > > this device needs some storage quirk handling before it
behaves.
> > > > > >
> > > > > > Thanks, I am just about to try 2.4.19-pre5 (downloading this
currently).
> > > > > > Do I need to apply additional patches to this?
> > > > > > I will report on 2.4.19-pre5.
> > > > >
> > > > > I'll forward that patch, it's against pre5.
> > > > >
> > > > > - Dave
> > > >
> > > > --
> > > > Christian Mahr (privat)
[EMAIL PROTECTED]
> > > >
> > > > _______________________________________________
> > > > [EMAIL PROTECTED]
> > > > To unsubscribe, use the last form field at:
> > > > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
> > >
> > > --
> > > Christian Mahr (privat)
[EMAIL PROTECTED]
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > [EMAIL PROTECTED]
> > > To unsubscribe, use the last form field at:
> > > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
> > >
> > > ----- End forwarded message -----
> > >
> > > --
> > > Matthew Dharm Home:
[EMAIL PROTECTED]
> > > Maintainer, Linux USB Mass Storage Driver
> > >
> > > What, are you one of those Microsoft-bashing Linux freaks?
> > > -- Customer to Greg
> > > User Friendly, 2/10/1999
> >
> >
> >
> > --
> > Matthew Dharm Home:
[EMAIL PROTECTED]
> > Maintainer, Linux USB Mass Storage Driver
> >
> > Would you mind not using our Web server? We're trying to have a game
of
> > Quake here.
> > -- Greg
> > User Friendly, 5/11/1998
>
> --
> Matthew Dharm Home:
[EMAIL PROTECTED]
> Maintainer, Linux USB Mass Storage Driver
>
> You suck Stef.
> -- Greg
> User Friendly, 11/29/97
>
>
------------------------------------------------------------------------
> Part 1.2Type: application/pgp-signature
--
Christian Mahr (privat) [EMAIL PROTECTED]
Apr 1 15:02:14 Mahrmaid kernel: Initializing USB Mass Storage driver...
Apr 1 15:02:14 Mahrmaid kernel: usb.c: registered new driver
usb-storage
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: act_altsettting is 0
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: id_index calculated to be:
84
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: Array length appears to
be: 86
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: USB Mass Storage device
detected
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: Endpoints: In: 0xc9aaf4b4
Out: 0xc9aaf4a0 Int: 0xc9aaf4c8 (Period 9)
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: New GUID
05ab0060fffffffffff7d96a
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: GetMaxLUN command result
is 1, data is 0
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: Transport: Bulk
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: Protocol: Transparent SCSI
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: *** thread sleeping.
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: test usb-debug
Apr 1 15:02:14 Mahrmaid kernel: scsi1 : SCSI emulation for USB Mass
Storage devices
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: queuecommand() called
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: *** thread awakened.
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: Command INQUIRY (6 bytes)
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: 12 00 00 00 ff 00 00 00 e0
6d 95 cb
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: Bulk command S 0x43425355
T 0x21 Trg 0 LUN 0 L 255 F 128 CL 6
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: Bulk command transfer
result=0
Apr 1 15:02:14 Mahrmaid kernel: usb-storage:
usb_stor_transfer_partial(): xfer 255 bytes
Apr 1 15:02:20 Mahrmaid kernel: usb-storage: command_abort() called
Apr 1 15:02:20 Mahrmaid kernel: ehci-hcd.c: 00:12.2 urb_dequeue
c9feaca0 qh state 1
Apr 1 15:02:20 Mahrmaid kernel: hcd.c: giveback urb c9feaca0 status
-104
Apr 1 15:02:20 Mahrmaid kernel: usb-storage: usb_stor_bulk_msg()
returned -104 xferred 0/255
Apr 1 15:02:20 Mahrmaid kernel: usb-storage:
usb_stor_transfer_partial(): unknown error
Apr 1 15:02:20 Mahrmaid kernel: usb-storage: Bulk data transfer result
0x2
Apr 1 15:02:20 Mahrmaid kernel: usb-storage: Attempting to get CSW...
Apr 1 15:02:24 Mahrmaid kernel: ehci-q.c: ep 2-in qtd token 000d8d50
--> status -75
Apr 1 15:02:24 Mahrmaid kernel: hcd.c: giveback urb c9feaca0 status -75
Apr 1 15:02:24 Mahrmaid kernel: usb-storage: Bulk status result = -75
Apr 1 15:02:24 Mahrmaid kernel: usb-storage: -- transport indicates
error, resetting
Apr 1 15:02:24 Mahrmaid kernel: usb-storage: Bulk reset requested
Apr 1 15:02:31 Mahrmaid kernel: usb-storage: Soft reset: clearing
bulk-in endpoint halt
Apr 1 15:02:31 Mahrmaid kernel: usb-storage: usb_stor_clear_halt:
result=0
Apr 1 15:02:31 Mahrmaid kernel: usb-storage: Soft reset: clearing
bulk-out endpoint halt
Apr 1 15:02:31 Mahrmaid kernel: usb-storage: usb_stor_clear_halt:
result=0
Apr 1 15:02:31 Mahrmaid kernel: usb-storage: Soft reset done
Apr 1 15:02:31 Mahrmaid kernel: usb-storage: scsi cmd done,
result=0x70000
Apr 1 15:02:31 Mahrmaid kernel: usb-storage: *** thread sleeping.
--
Christian Mahr (privat) [EMAIL PROTECTED]
--- Begin Message ---
Hi Matt,
.... I already did switch on the logging (that is how I found the solution).
This is the log without my patch, i.e. the blocking case (see
attachment: usb-storage-nok.log):
you see that the process usb_storage went to sleep after having received the result
0x70000 (=DID_ERROR<<16)
which is not explicitly handled in the code:
Apr 1 15:02:31 Mahrmaid kernel: usb-storage: scsi cmd done, result=0x70000
Apr 1 15:02:31 Mahrmaid kernel: usb-storage: *** thread sleeping.
>From here it never wakes up. After my patch (not asking for command completion in
this case )
the process continues and everything goes fine.
On the hub question: Sorry, I bought a "advance USB 2.0 PCI Business" PCI card. I had
no idea that there is a hub on the card (is it?) it has just got 4 USB connectors (3
on the back, 1 inside the PC) and it seems to have a NEC chip on it.
/proc/bus/usb/devices says:
T: Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=480 MxCh= 5
B: Alloc= 0/800 us ( 0%), #Int= 0, #Iso= 0
D: Ver= 2.00 Cls=09(hub ) Sub=00 Prot=01 MxPS= 8 #Cfgs= 1
P: Vendor=0000 ProdID=0000 Rev= 2.40
S: Manufacturer=Linux 2.4.19-pre5 ehci-hcd
S: Product=NEC Corporation USB 2.0
S: SerialNumber=00:12.2
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA
I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub
E: Ad=81(I) Atr=03(Int.) MxPS= 2 Ivl=256ms
Do we have to handle other srb->results the same way? shall we introduce a case
statement here to catch all the cases? I am not so familiar with the SCSI emulation to
know in which cases a command completion is meaningful
and when it should no be completed. Perhaps other reactions are better.
At lease we should prevent waiting forever here.....
What do you think?
Christian
Matthew Dharm wrote:
Sorry for the repeat, but I got Christian's address wrong the first time.
>
> Matt
>
> On Mon, Apr 01, 2002 at 11:26:52AM -0800, Matthew Dharm wrote:
> > Hrm... looking at this, should a command that ended in DID_ERROR get
> > completed? I thought it should, as the SCSI layer needs to know that it
> > ended in error.
> >
> > So why is the SCSI layer waiting?
> >
> > Christian, can you recompile your kernel with USB Mass Storage Verbose
> > Debugging turned on? Also, can you attach the unit directly to your PC,
> > not to the USB 2.0 hub? There are reports that USB 2.0 hubs are not well
> > supported yet.
> >
> > Matt
> >
> > On Mon, Apr 01, 2002 at 11:17:38AM -0800, Matthew Dharm wrote:
> > > Bjorn, is this needed?
> > >
> > > Actually, this could be notable... are we properly testing all the codes in
> > > us->srb->result?
> > >
> > > Matt
> > >
> > > ----- Forwarded message from Christian Mahr <[EMAIL PROTECTED]> -----
> > >
> > > Date: Mon, 01 Apr 2002 17:05:17 +0200
> > > From: Christian Mahr <[EMAIL PROTECTED]>
> > > Subject: Re: [linux-usb-devel] problems with ARCHOS jukebox recorder 20 on USB
> > > To: David Brownell <[EMAIL PROTECTED]>,
> > > [EMAIL PROTECTED]
> > > X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-pre5 i586)
> > > List-Id: <linux-usb-devel.lists.sourceforge.net>
> > > X-Spam-Status: No, hits=-5.0 required=5.0 tests=UNIFIED_PATCH version=2.11
> > >
> > > Hi David, hi all,
> > >
> > > I found the problem which makes the scsi_eh_1 get stuck when connecting the
> > > ARCHOS Jukebox on th fly:
> > >
> > > The problem is that the lower layers do return a scsi-cmd with "DID_ERROR<<16
> > > (=0x70000)", but the usb-storage insists to complete the command instead, thus
> > > waiting forever.
> > >
> > > The following patch to usb.c does it for me.
> > >
> > > --- usb.c Mon Apr 1 16:08:31 2002
> > > +++ usb.c.org Mon Apr 1 16:07:15 2002
> > > @@ -461,9 +461,7 @@
> > > up(&(us->dev_semaphore));
> > >
> > > /* indicate that the command is done */
> > > -/*cm 01-Apr-02: allow also DID_ERROR as premature abort of command */
> > > - if ((us->srb->result != DID_ABORT << 16) &&
> > > (us->srb->result != DID_ERROR << 16)) {
> > > -/* original line: if (us->srb->result != DID_ABORT << 16) { */
> > > + if (us->srb->result != DID_ABORT << 16) {
> > > US_DEBUGP("scsi cmd done, result=0x%x\n",
> > > us->srb->result);
> > > set_current_state(TASK_INTERRUPTIBLE);
> > >
> > >
> > > Perhaps this is not the only error situation where a command is not completed?
> > >
> > > At least, this solution retries the SCSI command now and the driver becomes
> > > properly connected on the 2nd try.
> > >
> > > Who of you can introduce this change into the current code?
> > >
> > > Christian
> > >
> > >
> > > Christian Mahr wrote:
> > >
> > > > Hi David,
> > > >
> > > > I just tried 2.4.19-pre5 and I do notice the same effects:
> > > >
> > > > ps -ax (excerpt):
> > > > 3616 ? SW 0:00 [khubd]
> > > > 3646 ? Z 0:00 [cron <defunct>]
> > > > 3648 ? S 0:00 /bin/bash /etc/hotplug/usb.agent
> > > > 3667 ? D 0:00 /sbin/modprobe -vs usb-storage
> > > > 3668 ? SW 0:00 [usb-storage-0]
> > > > 3669 ? DW 0:00 [scsi_eh_1]
> > > > 3671 pts/3 R 0:00 ps ax
> > > >
> > > > So this time modprobe usb-storage and scsi_eh_1 are blocked...
> > > >
> > > > /var/log/messages gives the following:
> > > > Apr 1 11:58:50 Mahrmaid kernel: hcd.c: ehci-hcd @ 00:12.2, NEC Corporation
> > > > USB 2.0
> > > > Apr 1 11:58:50 Mahrmaid kernel: hcd.c: PCI latency reduced to max 34
> > > > Apr 1 11:58:50 Mahrmaid kernel: hcd.c: irq 11, pci mem ceae2000
> > > > Apr 1 11:58:50 Mahrmaid kernel: usb.c: new USB bus registered, assigned bus
> > > > number 1
> > > > Apr 1 11:58:50 Mahrmaid kernel: ehci-dbg.c: ehci_start hcs_params 0x2395
> > > > dbg=0 cc=2 pcc=3 ports=5
> > > > Apr 1 11:58:50 Mahrmaid kernel: ehci-dbg.c: 00:12.2: ehci_start portroute 1
> > > > 0 1 0 0
> > > > Apr 1 11:58:50 Mahrmaid kernel: ehci-dbg.c: ehci_start hcc_params 0x0002
> > > > caching 0 uframes 256/512/1024
> > > > Apr 1 11:58:50 Mahrmaid kernel: ehci-hcd.c: reset 80002 cmd (park)=0
> > > > ithresh=8 period=1024 Reset HALT
> > > > Apr 1 11:58:50 Mahrmaid kernel: ehci-hcd.c: init 10000 cmd (park)=0
> > > > ithresh=1 period=1024 HALT
> > > > Apr 1 11:58:50 Mahrmaid kernel: ehci-hcd.c: USB 2.0 support enabled, EHCI
> > > > rev 0.95
> > > > Apr 1 11:58:50 Mahrmaid kernel: hcd.c: 00:12.2 root hub device address 1
> > > > Apr 1 11:58:50 Mahrmaid kernel: usb.c: kmalloc IF c340f880, numif 1
> > > > Apr 1 11:58:50 Mahrmaid kernel: usb.c: new device strings: Mfr=3, Product=2,
> > > > SerialNumber=1
> > > > Apr 1 11:58:50 Mahrmaid kernel: usb.c: USB device number 1 default language
> > > > ID 0x0
> > > > Apr 1 11:58:50 Mahrmaid kernel: Manufacturer: Linux 2.4.19-pre5 ehci-hcd
> > > > Apr 1 11:58:50 Mahrmaid kernel: Product: NEC Corporation USB 2.0
> > > > Apr 1 11:58:50 Mahrmaid kernel: SerialNumber: 00:12.2
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: USB hub found
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: 5 ports detected
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: standalone hub
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: individual port power switching
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: individual port over-current
> > > > protection
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: Single TT
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: TT requires at most 8 FS bit times
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: Port indicators are not supported
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: power on to power good time: 0ms
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: hub controller current requirement:
> > > > 0mA
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: port removable status: RRRRR
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: local power source is good
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: no over-current condition exists
> > > > Apr 1 11:58:50 Mahrmaid kernel: hub.c: enabling power on all ports
> > > > Apr 1 11:58:50 Mahrmaid kernel: usb.c: hub driver claimed interface c340f880
> > > >
> > > > Apr 1 11:58:50 Mahrmaid kernel: usb.c: kusbd: /sbin/hotplug add 1
> > > > Apr 1 11:59:00 Mahrmaid /USR/SBIN/CRON[3647]: (root) CMD ( rm -f
> > > > /var/spool/cron/lastrun/cron.hourly)
> > > > Apr 1 11:59:04 Mahrmaid kernel: ehci-hub.c: GetStatus port 1 status 0x1803
> > > > POWER speed=2 CSC CONNECT
> > > > Apr 1 11:59:04 Mahrmaid kernel: hub.c: port 1, portstatus 501, change 1, 480
> > > > Mb/s
> > > > Apr 1 11:59:04 Mahrmaid kernel: hub.c: port 1 connection change
> > > > Apr 1 11:59:04 Mahrmaid kernel: hub.c: port 1, portstatus 501, change 1, 480
> > > > Mb/s
> > > > Apr 1 11:59:04 Mahrmaid kernel: hub.c: port 1, portstatus 501, change 0, 480
> > > > Mb/s
> > > > Apr 1 11:59:04 Mahrmaid last message repeated 3 times
> > > > Apr 1 11:59:04 Mahrmaid kernel: hub.c: port 1, portstatus 511, change 0, 480
> > > > Mb/s
> > > > Apr 1 11:59:04 Mahrmaid kernel: hub.c: port 1 of hub 1 not reset yet,
> > > > waiting 10ms
> > > > Apr 1 11:59:04 Mahrmaid kernel: hub.c: port 1, portstatus 511, change 0, 480
> > > > Mb/s
> > > > Apr 1 11:59:04 Mahrmaid kernel: hub.c: port 1 of hub 1 not reset yet,
> > > > waiting 10ms
> > > > Apr 1 11:59:04 Mahrmaid kernel: ehci-hub.c: 00:12.2 port 1 high speed
> > > > Apr 1 11:59:04 Mahrmaid kernel: ehci-hub.c: GetStatus port 1 status 0x1005
> > > > POWER speed=0 PE CONNECT
> > > > Apr 1 11:59:04 Mahrmaid kernel: hub.c: port 1, portstatus 503, change 10,
> > > > 480 Mb/s
> > > > Apr 1 11:59:04 Mahrmaid kernel: hub.c: USB new device connect on bus1/1,
> > > > assigned device number 2
> > > > Apr 1 11:59:05 Mahrmaid kernel: usb.c: kmalloc IF c340f980, numif 1
> > > > Apr 1 11:59:05 Mahrmaid kernel: usb.c: new device strings: Mfr=73,
> > > > Product=90, SerialNumber=110
> > > > Apr 1 11:59:05 Mahrmaid kernel: usb.c: USB device number 2 default language
> > > > ID 0x409
> > > > Apr 1 11:59:05 Mahrmaid kernel: Manufacturer: ARCHOS
> > > > Apr 1 11:59:05 Mahrmaid kernel: Product: ARCHOS USB2.0 (P4a)
> > > > Apr 1 11:59:05 Mahrmaid kernel: SerialNumber: wwww.archos.comA
> > > > Apr 1 11:59:05 Mahrmaid kernel: usb.c: unhandled interfaces on device
> > > > Apr 1 11:59:05 Mahrmaid kernel: usb.c: USB device 2 (vend/prod 0x5ab/0x60)
> > > > is not claimed by any active driver.
> > > > Apr 1 11:59:05 Mahrmaid kernel: Length = 18
> > > > Apr 1 11:59:05 Mahrmaid kernel: DescriptorType = 01
> > > > Apr 1 11:59:05 Mahrmaid kernel: USB version = 2.00
> > > > Apr 1 11:59:05 Mahrmaid kernel: Vendor:Product = 05ab:0060
> > > > Apr 1 11:59:05 Mahrmaid kernel: MaxPacketSize0 = 64
> > > > Apr 1 11:59:05 Mahrmaid kernel: NumConfigurations = 1
> > > > Apr 1 11:59:05 Mahrmaid kernel: Device version = 11.01
> > > > Apr 1 11:59:05 Mahrmaid kernel: Device Class:SubClass:Protocol = 00:00:00
> > > > Apr 1 11:59:05 Mahrmaid kernel: Per-interface classes
> > > > Apr 1 11:59:05 Mahrmaid kernel: Configuration:
> > > > Apr 1 11:59:05 Mahrmaid kernel: bLength = 9
> > > > Apr 1 11:59:05 Mahrmaid kernel: bDescriptorType = 02
> > > > Apr 1 11:59:05 Mahrmaid kernel: wTotalLength = 0027
> > > > Apr 1 11:59:05 Mahrmaid kernel: bNumInterfaces = 01
> > > > Apr 1 11:59:05 Mahrmaid kernel: bConfigurationValue = 02
> > > > Apr 1 11:59:05 Mahrmaid kernel: iConfiguration = 00
> > > > Apr 1 11:59:05 Mahrmaid kernel: bmAttributes = c0
> > > > Apr 1 11:59:05 Mahrmaid kernel: MaxPower = 98mA
> > > > Apr 1 11:59:05 Mahrmaid kernel:
> > > > Apr 1 11:59:05 Mahrmaid kernel: Interface: 0
> > > > Apr 1 11:59:05 Mahrmaid kernel: Alternate Setting: 0
> > > > Apr 1 11:59:05 Mahrmaid kernel: bLength = 9
> > > > Apr 1 11:59:05 Mahrmaid kernel: bDescriptorType = 04
> > > > Apr 1 11:59:05 Mahrmaid kernel: bInterfaceNumber = 00
> > > > Apr 1 11:59:05 Mahrmaid kernel: bAlternateSetting = 00
> > > > Apr 1 11:59:05 Mahrmaid kernel: bNumEndpoints = 03
> > > > Apr 1 11:59:05 Mahrmaid kernel: bInterface Class:SubClass:Protocol =
> > > > 08:06:50
> > > > Apr 1 11:59:05 Mahrmaid kernel: iInterface = 00
> > > > Apr 1 11:59:05 Mahrmaid kernel: Endpoint:
> > > > Apr 1 11:59:05 Mahrmaid kernel: bLength = 7
> > > > Apr 1 11:59:05 Mahrmaid kernel: bDescriptorType = 05
> > > > Apr 1 11:59:05 Mahrmaid kernel: bEndpointAddress = 01 (out)
> > > > Apr 1 11:59:05 Mahrmaid kernel: bmAttributes = 02 (Bulk)
> > > > Apr 1 11:59:05 Mahrmaid kernel: wMaxPacketSize = 0200
> > > > Apr 1 11:59:05 Mahrmaid kernel: bInterval = 01
> > > > Apr 1 11:59:05 Mahrmaid kernel: Endpoint:
> > > > Apr 1 11:59:05 Mahrmaid kernel: bLength = 7
> > > > Apr 1 11:59:05 Mahrmaid kernel: bDescriptorType = 05
> > > > Apr 1 11:59:05 Mahrmaid kernel: bEndpointAddress = 82 (in)
> > > > Apr 1 11:59:05 Mahrmaid kernel: bmAttributes = 02 (Bulk)
> > > > Apr 1 11:59:05 Mahrmaid kernel: wMaxPacketSize = 0200
> > > > Apr 1 11:59:05 Mahrmaid kernel: bInterval = 01
> > > > Apr 1 11:59:05 Mahrmaid kernel: Endpoint:
> > > > Apr 1 11:59:05 Mahrmaid kernel: bLength = 7
> > > > Apr 1 11:59:05 Mahrmaid kernel: bDescriptorType = 05
> > > > Apr 1 11:59:05 Mahrmaid kernel: bEndpointAddress = 83 (in)
> > > > Apr 1 11:59:05 Mahrmaid kernel: bmAttributes = 03 (Interrupt)
> > > >
> > > > Apr 1 11:59:05 Mahrmaid kernel: wMaxPacketSize = 0002
> > > > Apr 1 11:59:05 Mahrmaid kernel: bInterval = 09
> > > > Apr 1 11:59:05 Mahrmaid kernel: usb.c: kusbd: /sbin/hotplug add 2
> > > > Apr 1 11:59:05 Mahrmaid kernel: hub.c: port 2, portstatus 100, change 0, 12
> > > > Mb/s
> > > > Apr 1 11:59:05 Mahrmaid kernel: hub.c: port 3, portstatus 100, change 0, 12
> > > > Mb/s
> > > > Apr 1 11:59:05 Mahrmaid kernel: hub.c: port 4, portstatus 100, change 0, 12
> > > > Mb/s
> > > > Apr 1 11:59:05 Mahrmaid kernel: hub.c: port 5, portstatus 100, change 0, 12
> > > > Mb/s
> > > > Apr 1 11:59:05 Mahrmaid kernel: Initializing USB Mass Storage driver...
> > > > Apr 1 11:59:05 Mahrmaid kernel: usb.c: registered new driver usb-storage
> > > > Apr 1 11:59:05 Mahrmaid kernel: scsi1 : SCSI emulation for USB Mass Storage
> > > > devices
> > > > Apr 1 11:59:11 Mahrmaid kernel: ehci-hcd.c: 00:12.2 urb_dequeue ca353840 qh
> > > > state 1
> > > > Apr 1 11:59:11 Mahrmaid kernel: hcd.c: giveback urb ca353840 status -104
> > > > Apr 1 11:59:15 Mahrmaid kernel: ehci-q.c: ep 2-in qtd token 000d8d50 -->
> > > > status -75
> > > > Apr 1 11:59:15 Mahrmaid kernel: hcd.c: giveback urb ca353840 status -75
> > > >
> > > > with these error messages -104 and -75, the whole thing gets stuck.
> > > > /proc/scsi/scsi is incomplete:
> > > >
> > > > Host: scsi1 Channel: 00 Id: 00 Lun: 00
> > > > Vendor: Model: Rev:
> > > > Type: <NULL> ANSI SCSI revision: ffffffff
> > > >
> > > > In my understanding the origin migth be misbehavior of the drive when
> > > > connected after start of the usb drivers.
> > > >
> > > > I believe that usb-storage might wait for something forever which does not
> > > > happen because of errors
> > > > on lower layers. anyhow, I believe that waiting forever is wrong here, don't
> > > > we need some timeouts here?
> > > >
> > > > How can I processd debugging? Do you want me to generate more information?
> > > > how?
> > > > How can I attach to the modules in "d" state? can I used gdb for this?
> > > >
> > > > Thanks for helping
> > > > Christian
> > > >
> > > > David Brownell wrote:
> > > >
> > > > > > > Do the startup problems happen when you use USB 1.1 speeds,
> > > > > > > only using an OHCI or UHCI host controller driver (not ehci-hcd)?
> > > > > > >
> > > > > >
> > > > > > yes, same problem.
> > > > >
> > > > > Highly suggestive of a device bug/quirk ...
> > > > >
> > > > > > > http://www.archos.com/us/products/product_500277.html
> > > > > > >
> > > > > > > doesn't say the device has been USB 2.0 qualified, and does
> > > > > > > not use the USB 2.0 logo. It's not listed on the www.usb.org
> > > > > > > page of products that are compliant. That's suggestive ... it'd
> > > > > > > be worth contacting Archos to ask what gives. (USB 2.0 has
> > > > > > > a compliance program for good reasons ... :)
> > > > > >
> > > > > > The logo is on the drive...?
> > > > >
> > > > > The new red/blue "compliant" logo? It's not on the web page,
> > > > > which is surprising. Instead Archos has their own logo, which
> > > > > doesn't indicate compliance ...
> > > > >
> > > > > > > Sounds somewhat right to me, I've seen that failure mode.
> > > > > > > So far nothing seems to suggest it's trouble in EHCI.
> > > > > >
> > > > > > Just want to mention: even if the drive itself misbehaves, the driver
> > > > > > should not become stuck forever in "D " or DW" state.
> > > > > > In my situation, I have to re-boot to restart usb. Killing the processes
> > > > > > doesn't work.
> > > > >
> > > > > Agreed; yes, that's a nasty usb-storage failure mode.
> > > > >
> > > > > > > You might try this on a more recent kernel (2.4.19-pre5?), and try
> > > > > > > enabling mass storage debug to get more info. Matt recently posted
> > > > > > > some rework of that exception handling code, and it's also possible
> > > > > > > this device needs some storage quirk handling before it behaves.
> > > > > >
> > > > > > Thanks, I am just about to try 2.4.19-pre5 (downloading this currently).
> > > > > > Do I need to apply additional patches to this?
> > > > > > I will report on 2.4.19-pre5.
> > > > >
> > > > > I'll forward that patch, it's against pre5.
> > > > >
> > > > > - Dave
> > > >
> > > > --
> > > > Christian Mahr (privat) [EMAIL PROTECTED]
> > > >
> > > > _______________________________________________
> > > > [EMAIL PROTECTED]
> > > > To unsubscribe, use the last form field at:
> > > > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
> > >
> > > --
> > > Christian Mahr (privat) [EMAIL PROTECTED]
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > [EMAIL PROTECTED]
> > > To unsubscribe, use the last form field at:
> > > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
> > >
> > > ----- End forwarded message -----
> > >
> > > --
> > > Matthew Dharm Home: [EMAIL PROTECTED]
> > > Maintainer, Linux USB Mass Storage Driver
> > >
> > > What, are you one of those Microsoft-bashing Linux freaks?
> > > -- Customer to Greg
> > > User Friendly, 2/10/1999
> >
> >
> >
> > --
> > Matthew Dharm Home: [EMAIL PROTECTED]
> > Maintainer, Linux USB Mass Storage Driver
> >
> > Would you mind not using our Web server? We're trying to have a game of
> > Quake here.
> > -- Greg
> > User Friendly, 5/11/1998
>
> --
> Matthew Dharm Home: [EMAIL PROTECTED]
> Maintainer, Linux USB Mass Storage Driver
>
> You suck Stef.
> -- Greg
> User Friendly, 11/29/97
>
> ------------------------------------------------------------------------
> Part 1.2Type: application/pgp-signature
--
Christian Mahr (privat) [EMAIL PROTECTED]
Apr 1 15:02:14 Mahrmaid kernel: Initializing USB Mass Storage driver...
Apr 1 15:02:14 Mahrmaid kernel: usb.c: registered new driver usb-storage
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: act_altsettting is 0
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: id_index calculated to be: 84
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: Array length appears to be: 86
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: USB Mass Storage device detected
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: Endpoints: In: 0xc9aaf4b4 Out:
0xc9aaf4a0 Int: 0xc9aaf4c8 (Period 9)
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: New GUID 05ab0060fffffffffff7d96a
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: GetMaxLUN command result is 1, data is 0
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: Transport: Bulk
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: Protocol: Transparent SCSI
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: *** thread sleeping.
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: test usb-debug
Apr 1 15:02:14 Mahrmaid kernel: scsi1 : SCSI emulation for USB Mass Storage devices
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: queuecommand() called
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: *** thread awakened.
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: Command INQUIRY (6 bytes)
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: 12 00 00 00 ff 00 00 00 e0 6d 95 cb
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: Bulk command S 0x43425355 T 0x21 Trg 0
LUN 0 L 255 F 128 CL 6
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: Bulk command transfer result=0
Apr 1 15:02:14 Mahrmaid kernel: usb-storage: usb_stor_transfer_partial(): xfer 255
bytes
Apr 1 15:02:20 Mahrmaid kernel: usb-storage: command_abort() called
Apr 1 15:02:20 Mahrmaid kernel: ehci-hcd.c: 00:12.2 urb_dequeue c9feaca0 qh state 1
Apr 1 15:02:20 Mahrmaid kernel: hcd.c: giveback urb c9feaca0 status -104
Apr 1 15:02:20 Mahrmaid kernel: usb-storage: usb_stor_bulk_msg() returned -104
xferred 0/255
Apr 1 15:02:20 Mahrmaid kernel: usb-storage: usb_stor_transfer_partial(): unknown
error
Apr 1 15:02:20 Mahrmaid kernel: usb-storage: Bulk data transfer result 0x2
Apr 1 15:02:20 Mahrmaid kernel: usb-storage: Attempting to get CSW...
Apr 1 15:02:24 Mahrmaid kernel: ehci-q.c: ep 2-in qtd token 000d8d50 --> status -75
Apr 1 15:02:24 Mahrmaid kernel: hcd.c: giveback urb c9feaca0 status -75
Apr 1 15:02:24 Mahrmaid kernel: usb-storage: Bulk status result = -75
Apr 1 15:02:24 Mahrmaid kernel: usb-storage: -- transport indicates error, resetting
Apr 1 15:02:24 Mahrmaid kernel: usb-storage: Bulk reset requested
Apr 1 15:02:31 Mahrmaid kernel: usb-storage: Soft reset: clearing bulk-in endpoint
halt
Apr 1 15:02:31 Mahrmaid kernel: usb-storage: usb_stor_clear_halt: result=0
Apr 1 15:02:31 Mahrmaid kernel: usb-storage: Soft reset: clearing bulk-out endpoint
halt
Apr 1 15:02:31 Mahrmaid kernel: usb-storage: usb_stor_clear_halt: result=0
Apr 1 15:02:31 Mahrmaid kernel: usb-storage: Soft reset done
Apr 1 15:02:31 Mahrmaid kernel: usb-storage: scsi cmd done, result=0x70000
Apr 1 15:02:31 Mahrmaid kernel: usb-storage: *** thread sleeping.
--- End Message ---
