USB Mass Storage Hangs

USB Mass Storage Hangs

[Stephen Marz]

This message regards the USB mass storage driver for kernel version
2.4.18-10:

On my Dell Inspiron 7500 I have an adaptec USB 2.0 cardbus
adapter.  I plugged in a 120GB hard drive and the mass
storage driver in linux detects it and runs it fine.  The
problem comes in when I try to also plug in my CD-RW into
the cardbus adapter (it has two USB 2.0 ports).  The mass
storage driver will detect and gather information about
the drive, however it doesn't take more than two or
three minutes before the entire system hangs.  The kernel
immediately drops all knowledge of any USB device on
my system.

Anybody else notice this problem?


Thanks,

Stephen Marz

Re: USB Mass Storage Hangs

[Greg KH]

On Fri, Sep 27, 2002 at 12:38:16AM -0500, Stephen Marz wrote:
> This message regards the USB mass storage driver for kernel version
> 2.4.18-10:
> 
> On my Dell Inspiron 7500 I have an adaptec USB 2.0 cardbus
> adapter.  I plugged in a 120GB hard drive and the mass
> storage driver in linux detects it and runs it fine.  The
> problem comes in when I try to also plug in my CD-RW into
> the cardbus adapter (it has two USB 2.0 ports).  The mass
> storage driver will detect and gather information about
> the drive, however it doesn't take more than two or
> three minutes before the entire system hangs.  The kernel
> immediately drops all knowledge of any USB device on
> my system.
> 
> Anybody else notice this problem?

Is there a kernel oops anywhere?
And are both of these devices USB 2.0 devices?  If so, you might want to
try the 2.4.20-pre kernels, it has much better USB 2.0 support than the
kernel you are using.

thanks,

greg k-h

Re: USB Mass Storage Hangs

[Tommi Kyntola]

> On Fri, Sep 27, 2002 at 12:38:16AM -0500, Stephen Marz wrote:
> > This message regards the USB mass storage driver for kernel version
> > 2.4.18-10:
> > 
> > On my Dell Inspiron 7500 I have an adaptec USB 2.0 cardbus
> > adapter.  I plugged in a 120GB hard drive and the mass
> > storage driver in linux detects it and runs it fine.  The
> > problem comes in when I try to also plug in my CD-RW into
> > the cardbus adapter (it has two USB 2.0 ports).  The mass
> > storage driver will detect and gather information about
> > the drive, however it doesn't take more than two or
> > three minutes before the entire system hangs.  The kernel
> > immediately drops all knowledge of any USB device on
> > my system.
> > 
> > Anybody else notice this problem?
> 
> Is there a kernel oops anywhere?
> And are both of these devices USB 2.0 devices?  If so, you might want to
> try the 2.4.20-pre kernels, it has much better USB 2.0 support than the
> kernel you are using.

I can still panic even the 2.4.20-pre8, by plugging in 
a usb mass storage key, mount, umount, unplug, plug back in,
mount, umount
The second umount hangs at doing something like "waiting CSW" and
after few seconds (30ish, I'd say) the kernel panics.

Reason why I havent been moaning about this since last fall, when I first 
discovered this and reported, is my lack of time to get into this and
a work-around I found that avoids it.
If I rmmod the usb-storage after I've unmounted the key and insmod back in 
before mounting it again, it works like a charm.

If someone is now interested in this topic (Matthew hasn't responded)
I can easily send the panic reports or whatever information needed.
I've tested this on atleast dozen very different boxes and the results 
were identical.

With previous kernels (say, from 2.4.17-preX to 2.4.19-preX it oopsed 
rather than paniced), I think I still have those oopses somewhere if 
anyone wants them.

Feel free to contact directly or via lkml,
Tommi Kynde Kyntola		kynde@ts.ray.fi
      "A man alone in the forest talking to himself and
       no women around to hear him. Is he still wrong?"

> 
> thanks,
> 
> greg k-h
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: USB Mass Storage Hangs

[David Brownell]

 > > And are both of these devices USB 2.0 devices?  If so, you might want to
 > > try the 2.4.20-pre kernels, it has much better USB 2.0 support than the
 > > kernel you are using.
 >
 > I can still panic even the 2.4.20-pre8, by ...

Actually, even pre8 doesn't have the updates that would matter
for something like this ... the "better" was mostly not oopsing
if you unplug a hub (it was a hub driver bug).  You'd need some
patches that aren't yet in Marcelo's tree, but which HAVE been
pasted here on LKML.  (And people who've tried them have said
the patches have improved things for them.)

Have a look at these posts, which are slightly updated versions of
what's been posted to LKML (patches in the second two):

    http://marc.theaimsgroup.com/?l=linux-usb-devel&m=103288096812331&w=2
    http://marc.theaimsgroup.com/?l=linux-usb-devel&m=103288089912220&w=2
    http://marc.theaimsgroup.com/?l=linux-usb-devel&m=103283868910428&w=2

Alternatively, try this out on 2.5.latest ... those patches give
2.4.20-pre7 (or pre8) the same EHCI code as seen in 2.5.39, but
if you try 2.5.39 you'll benefit from some usb-storage fixes too.

And of course, if you "rmmod ehci-hcd" you'd be running using the
companion controller (likely a NEC using "usb-ohci"), which might
help you figure out whether the EHCI driver is even a factor in
this case.


 > Reason why I havent been moaning about this since last fall, when I first
 > discovered this and reported, is ...

Last fall, the EHCI driver was only available to bleeding-edge hackers
who were willing to work from CVS.  To whom did you report this?  I
can confirm that any problem report from last fall wasn't made to the
right people ... I surely didn't see any such report!  :)

- Dave

Re: USB Mass Storage Hangs

[Tommi Kyntola]

>  > > And are both of these devices USB 2.0 devices?  If so, you might want to
>  > > try the 2.4.20-pre kernels, it has much better USB 2.0 support than the
>  > > kernel you are using.
>  >
>  > I can still panic even the 2.4.20-pre8, by ...
> 
> Actually, even pre8 doesn't have the updates that would matter
> for something like this ... the "better" was mostly not oopsing
> if you unplug a hub (it was a hub driver bug).  You'd need some
> patches that aren't yet in Marcelo's tree, but which HAVE been
> pasted here on LKML.  (And people who've tried them have said
> the patches have improved things for them.)
> 
> Have a look at these posts, which are slightly updated versions of
> what's been posted to LKML (patches in the second two):
> 
>     http://marc.theaimsgroup.com/?l=linux-usb-devel&m=103288096812331&w=2
>     http://marc.theaimsgroup.com/?l=linux-usb-devel&m=103288089912220&w=2
>     http://marc.theaimsgroup.com/?l=linux-usb-devel&m=103283868910428&w=2
> 
> Alternatively, try this out on 2.5.latest ... those patches give
> 2.4.20-pre7 (or pre8) the same EHCI code as seen in 2.5.39, but
> if you try 2.5.39 you'll benefit from some usb-storage fixes too.

Actually I did see those posts, it's just that I've had the exact same 
problem on uhci and ohci, and because rmmod usb-storage between
unplug and plugin avoided the problem, I figured it was solely usb-storage 
related.

Besides it appears that it's more likely to be just MSystems DiskOnKey 
related, because for example a similar Fujitsu mass storage works without 
problems.
 
> And of course, if you "rmmod ehci-hcd" you'd be running using the
> companion controller (likely a NEC using "usb-ohci"), which might
> help you figure out whether the EHCI driver is even a factor in
> this case.
>
>  > Reason why I havent been moaning about this since last fall, when I first
>  > discovered this and reported, is ...
> 
> Last fall, the EHCI driver was only available to bleeding-edge hackers
> who were willing to work from CVS.  To whom did you report this?  I
> can confirm that any problem report from last fall wasn't made to the
> right people ... I surely didn't see any such report!  :)

Not about ehci, I did mail here (twice) and to sf usb-devel 
(or usb-users-devel or similar) list, but I was only talking about 
usb-storage module and DiskOnKey because, like I said, it didn't matter 
which Xhci I used, nor on what chipsets I tried it on. Late this summer I 
talked to a person who either worked for msystems (DiskOnKey manufacturer) 
or did business with them, can't remember which, and who had dug up those 
posts, and he sent mails to Matthew Dharm without reply, as far as I know. 

I know that contacting the right people is difficult, and like I said in
my previous post was that I would've looked into this and really tried 
harder, but it's just that I didn't have the time nor the need to
as aliases with the 'rmmod usb-storage' hack avoided the problem with
DiskOnKey devices.

Let me know if you want the panic prints or other tests done. 
I'll try the 2.5.39 out, but I doubt that the results will be any 
different.

-- 
Tommi Kynde Kyntola		kynde@ts.ray.fi
      "A man alone in the forest talking to himself and
       no women around to hear him. Is he still wrong?"

Re: USB Mass Storage Hangs

[David Brownell]

> Actually I did see those posts, it's just that I've had the exact same 
> problem on uhci and ohci, and because rmmod usb-storage between
> unplug and plugin avoided the problem, I figured it was solely usb-storage 
> related.

Ah, that wasn't clear to me from your post.  There are some issues
to be dealt with still ... usb-storage error handling has to do the
scsi_eh dance, but its choreography is problematic.

- Dave


> Besides it appears that it's more likely to be just MSystems DiskOnKey 
> related, because for example a similar Fujitsu mass storage works without 
> problems.

Re: USB Mass Storage Hangs

[Oliver Neukum]

On Tuesday 01 October 2002 05:04, David Brownell wrote:
> > Actually I did see those posts, it's just that I've had the exact same
> > problem on uhci and ohci, and because rmmod usb-storage between
> > unplug and plugin avoided the problem, I figured it was solely
> > usb-storage related.
>
> Ah, that wasn't clear to me from your post.  There are some issues
> to be dealt with still ... usb-storage error handling has to do the
> scsi_eh dance, but its choreography is problematic.

In principle scsi error handling can be overridden.
Whether this is worth it, is another question.

	Regards
		Oliver