Re: [linux-usb-devel] 2.6.20-rc4: usb somehow broken

[icxcnika]

On Sun, 14 Jan 2007, Alan Stern wrote:

> On Sun, 14 Jan 2007, Prakash Punnoor wrote:
>
> > Am Sonntag 14 Januar 2007 10:28 schrieb Oliver Neukum:
> > > Am Sonntag, 14. Januar 2007 10:08 schrieb Prakash Punnoor:
> > > > Am Donnerstag 11 Januar 2007 18:28 schrieb Oliver Neukum:
> > > > > Am Donnerstag, 11. Januar 2007 18:20 schrieb Prakash Punnoor:
> > > > > > Hi,
> > > > > >
> > > > > > I can't scan anymore. :-( I don't know which rc kernel introduced it,
> > > > > > but this are the messages I get (w/o touching the device/usb cable
> > > > > > except pluggin it in for the first time):
> > > > > >
> > > > > > usb 1-1.2: new full speed USB device using ehci_hcd and address 4
> > > > > > ehci_hcd 0000:00:0b.1: qh ffff81007bc6c280 (#00) state 4
> > > > > > usb 1-1.2: configuration #1 chosen from 1 choice
> > > > > > usb 1-1.2: USB disconnect, address 4
> > > > > > usb 1-1.2: new full speed USB device using ehci_hcd and address 5
> > > > > > usb 1-1.2: configuration #1 chosen from 1 choice
> > > > > > usb 1-1.2: USB disconnect, address 5
> > > > > > usb 1-1.2: new full speed USB device using ehci_hcd and address 6
> > > > > > usb 1-1.2: configuration #1 chosen from 1 choice
> > > > > > usb 1-1.2: USB disconnect, address 6
> > > > > > usb 1-1.2: new full speed USB device using ehci_hcd and address 7
> > > > > > usb 1-1.2: configuration #1 chosen from 1 choice
> > > > > > usb 1-1.2: USB disconnect, address 7
> > > > > > usb 1-1.2: new full speed USB device using ehci_hcd and address 8
> > > > > > usb 1-1.2: configuration #1 chosen from 1 choice
> > >
> > > [..]
> > >
> > > > Hi, I did more tests and I was wrong about "broken". It seems more a
> > > > time-out problem, ie if I try to use sane again in short intervalls, I
> > > > will get my device working. The cause seems CONFIG_USB_SUSPEND=y. With
> > > > 2.6.20-rc5 the
> > >
> > > Have you confirmed that by using a kernel without  CONFIG_USB_SUSPEND ?
> >
> > Yes. I compiled the modules with various settings, reloaded the modules and
> > above option made the difference. I also don't get the disconnect mesages, as
> > well, w/o USB_SUSPEND.
>
> Judging from the log, it looks like the scanner cannot handle being
> suspended.  (BTW this is in violation of the USB specification -- all
> devices must be able to suspend and resume.)
>
> When the scanner is not in use, the system automatically suspends it after
> two seconds.  When you use sane the scanner is resumed, but it then
> disconnects itself and reconnects.  Sane is left trying to control the
> disconnected device instance, so of course it fails.
>
> I'm beginning to think that we need some way to deal with devices that
> cannot recover from a suspend.  Several examples have cropped up.
> Unfortunately, I can't think of anything better than a blacklist, which is
> not very satisfactory.
>
> Can anyone suggest another approach?
>
> Alan Stern

Just a thought, you could use both a blacklist approach, and a module 
paramater, or something in sysfs, to allow specifying devices that won't 
be suspend and resume compatible.

William Heimbigner
icxcnika@xxxxxxxxxx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/