2.6.20-rc4: usb somehow broken

2.6.20-rc4: usb somehow broken

[Prakash Punnoor]

[-- Attachment #1: Type: text/plain, Size: 1487 bytes --]

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


Shouldn't the ohci module handle the scanner? The scanner is connected through 
a hub.

I don't remember how 2.6.19 handled it, or whether I used some new exotic 
setting which causes the breakage.

Well, I'll test this week-end and upload more infos then. If you already have 
some ideas in the meantime, let me know.

BTW, a usb2.0 card reader (connected through the same hub) works w/o 
problems...
-- 
(°=                 =°)
//\ Prakash Punnoor /\\
V_/                 \_V

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.20-rc4: usb somehow broken

[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
> 
> 
> Shouldn't the ohci module handle the scanner? The scanner is connected through 
> a hub.

Therefore it goes to EHCI. Can you try a direct connection?

> I don't remember how 2.6.19 handled it, or whether I used some new exotic 
> setting which causes the breakage.

Could you try 2.6.19?

> Well, I'll test this week-end and upload more infos then. If you already have 
> some ideas in the meantime, let me know.

Please test with CONFIG_USB_DEBUG

	Regards
		Oliver

Re: 2.6.20-rc4: usb somehow broken

[Prakash Punnoor]

[-- Attachment #1: Type: text/plain, Size: 2126 bytes --]

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
> >
> >
> > Shouldn't the ohci module handle the scanner? The scanner is connected
> > through a hub.
>
> Therefore it goes to EHCI. Can you try a direct connection?
>
> > I don't remember how 2.6.19 handled it, or whether I used some new exotic
> > setting which causes the breakage.
>
> Could you try 2.6.19?
>
> > Well, I'll test this week-end and upload more infos then. If you already
> > have some ideas in the meantime, let me know.
>
> Please test with CONFIG_USB_DEBUG


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 
situation seems better, ie now I don't get "no device" very less often.

So do you still want me to try above stuff?

-- 
(°=                 =°)
//\ Prakash Punnoor /\\
V_/                 \_V

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.20-rc4: usb somehow broken

[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 ?

	Regards
		Oliver

Re: 2.6.20-rc4: usb somehow broken

[Prakash Punnoor]

[-- Attachment #1: Type: text/plain, Size: 2017 bytes --]

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.

Cheers,
-- 
(°=                 =°)
//\ Prakash Punnoor /\\
V_/                 \_V

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Alan Stern]

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

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@mar.tar.cc

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

[Oliver Neukum]

Am Sonntag, 14. Januar 2007 20:47 schrieb icxcnika@mar.tar.cc:
> > 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.

Yes,
but in any case the sysfs attributes would have to populated somehow.
You'd just shift the burden. As this behavior is hopefully rare, it's
probably not worth the effort.

I can't think of anything better than a blacklist.

	Regards
		Oliver

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

[Oliver Neukum]

Am Sonntag, 14. Januar 2007 20:47 schrieb icxcnika@mar.tar.cc:
> > 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.

Upon further thought, a module parameter won't do as the problem
will arise without a driver loaded. A sysfs parameter turns the whole
affair into a race condition. Will you set the guard parameter before the
autosuspend logic strikes?
Unfortunately this leaves only the least attractive solution.

	Regards
		Oliver

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

[Alan Stern]

On Mon, 15 Jan 2007, Oliver Neukum wrote:

> Am Sonntag, 14. Januar 2007 20:47 schrieb icxcnika@mar.tar.cc:
> > > 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.
> 
> Upon further thought, a module parameter won't do as the problem
> will arise without a driver loaded. A sysfs parameter turns the whole
> affair into a race condition. Will you set the guard parameter before the
> autosuspend logic strikes?
> Unfortunately this leaves only the least attractive solution.

There could be a mixed approach: a builtin blacklist that is extensible 
via a procfs- or sysfs-based interface.

Note that we actually have two problems to contend with.  Some devices
must never be autosuspended at all (they disconnect when resuming), and
others need a reset after resuming.

Alan Stern

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

[Oliver Neukum]

Am Montag, 15. Januar 2007 17:03 schrieb Alan Stern:
> On Mon, 15 Jan 2007, Oliver Neukum wrote:

> > Upon further thought, a module parameter won't do as the problem
> > will arise without a driver loaded. A sysfs parameter turns the whole
> > affair into a race condition. Will you set the guard parameter before the
> > autosuspend logic strikes?
> > Unfortunately this leaves only the least attractive solution.
> 
> There could be a mixed approach: a builtin blacklist that is extensible 
> via a procfs- or sysfs-based interface.

If you want to ask with a lot of bug reports which blacklist was loaded,
then we could.
 
> Note that we actually have two problems to contend with.  Some devices
> must never be autosuspended at all (they disconnect when resuming), and
> others need a reset after resuming.

Do those who can be brought back with a reset need to be listed at all?
Error handling is not a bad idea.

	Regards
		Oliver

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

[Alan Stern]

On Mon, 15 Jan 2007, Oliver Neukum wrote:

> Am Montag, 15. Januar 2007 17:03 schrieb Alan Stern:
> > On Mon, 15 Jan 2007, Oliver Neukum wrote:
> 
> > > Upon further thought, a module parameter won't do as the problem
> > > will arise without a driver loaded. A sysfs parameter turns the whole
> > > affair into a race condition. Will you set the guard parameter before the
> > > autosuspend logic strikes?
> > > Unfortunately this leaves only the least attractive solution.
> > 
> > There could be a mixed approach: a builtin blacklist that is extensible 
> > via a procfs- or sysfs-based interface.
> 
> If you want to ask with a lot of bug reports which blacklist was loaded,
> then we could.

This is a "damned-if-you-do, damned-if-you-don't" situation.  Anyway, I've 
never liked the idea of loading up the kernel with a bunch of preset 
blacklist entries.  For most users that are a waste of space, and unneeded 
entries almost never get removed.

> > Note that we actually have two problems to contend with.  Some devices
> > must never be autosuspended at all (they disconnect when resuming), and
> > others need a reset after resuming.
> 
> Do those who can be brought back with a reset need to be listed at all?
> Error handling is not a bad idea.

The problem is that the system can't always tell that a reset is needed.  
There might be no symptoms at all.  For example, I've got a USB keypad 
which doesn't work right after a resume -- key presses never get sent to 
the computer.  As far as the system can tell the device is fine, though.

Alan Stern

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

[Greg KH]

On Mon, Jan 15, 2007 at 11:03:35AM -0500, Alan Stern wrote:
> On Mon, 15 Jan 2007, Oliver Neukum wrote:
> 
> > Am Sonntag, 14. Januar 2007 20:47 schrieb icxcnika@mar.tar.cc:
> > > > 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.
> > 
> > Upon further thought, a module parameter won't do as the problem
> > will arise without a driver loaded. A sysfs parameter turns the whole
> > affair into a race condition. Will you set the guard parameter before the
> > autosuspend logic strikes?
> > Unfortunately this leaves only the least attractive solution.
> 
> There could be a mixed approach: a builtin blacklist that is extensible 
> via a procfs- or sysfs-based interface.

Yes, I think this is the best solution, allow users to add their devices
to the kernel through a sysfs interface as a temporary solution, while
providing a built-in list for known broken devices.

And yeah, I hate blacklists too, but they are necessary at times :(

thanks,

greg k-h

Re: 2.6.20-rc4: usb somehow broken

[Prakash Punnoor]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

Am Sonntag 14 Januar 2007 10:28 schrieb Oliver Neukum:
>
> Have you confirmed that by using a kernel without  CONFIG_USB_SUSPEND ?

BTW, these are my USB config options, which don't seem to make problems 
anymore as long as USB_SUSPEND isn't activated:

CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=m
CONFIG_USB_DEVICEFS=y
CONFIG_USB_BANDWIDTH=y
CONFIG_USB_MULTITHREAD_PROBE=y
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_SPLIT_ISO=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_OHCI_HCD=m
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_PRINTER=m
CONFIG_USB_STORAGE=m

-- 
(°=                 =°)
//\ Prakash Punnoor /\\
V_/                 \_V

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.20-rc4: usb somehow broken

[Adrian Bunk]

On Sun, Jan 14, 2007 at 10:08:37AM +0100, Prakash Punnoor wrote:
> 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
> > >
> > >
> > > Shouldn't the ohci module handle the scanner? The scanner is connected
> > > through a hub.
> >
> > Therefore it goes to EHCI. Can you try a direct connection?
> >
> > > I don't remember how 2.6.19 handled it, or whether I used some new exotic
> > > setting which causes the breakage.
> >
> > Could you try 2.6.19?
> >
> > > Well, I'll test this week-end and upload more infos then. If you already
> > > have some ideas in the meantime, let me know.
> >
> > Please test with CONFIG_USB_DEBUG
> 
> 
> 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 
> situation seems better, ie now I don't get "no device" very less often.
>...


FYI, we already have a report of a different CONFIG_USB_SUSPEND 
regression in 2.6.20-rc:

Subject    : 'shutdown -h now' reboots the system  (CONFIG_USB_SUSPEND)
References : http://lkml.org/lkml/2006/12/25/40
Submitter  : Berthold Cogel <cogel@rrz.uni-koeln.de>
Handled-By : Alexey Starikovskiy <alexey.y.starikovskiy@linux.intel.com>
Status     : problem is being debugged



cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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

[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):

Hi,

I need "lsusb -v" for your device.

	Regards
		Oliver

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

[Prakash Punnoor]

[-- Attachment #1.1: Type: text/plain, Size: 507 bytes --]

Am Freitag 19 Januar 2007 12:29 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):
>
> Hi,
>
> I need "lsusb -v" for your device.
>
> 	Regards
> 		Oliver

Here you go.

-- 
(°=                 =°)
//\ Prakash Punnoor /\\
V_/                 \_V

[-- Attachment #1.2: lsusb.txt.bz2 --]
[-- Type: application/x-bzip2, Size: 3560 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Prakash Punnoor]

[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]

> 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):
>
Hi,

I found quickly booted into a 2.6.19-rc5 kjernel which was lying around here 
and here CONFIG_USB_SUSPEND doesn't make any problems with my scanner...

gunzip /proc/config.gz -c|grep USB|grep -v "#"
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_BANDWIDTH=y
CONFIG_USB_SUSPEND=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_SPLIT_ISO=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_PRINTER=y
CONFIG_USB_STORAGE=y

uname -a
Linux graviton 2.6.19-rc5 #74 SMP Fri Nov 24 22:59:14 CET 2006 x86_64 AMD 
Athlon(tm) 64 X2 Dual Core Processor 3800+ AuthenticAMD GNU/Linux

Do you want me to try out kernels until I find one rc which breaks or do you 
have an idea what was changed which could lead to the problem I am 
experiencing?

Cheers,
-- 
(°=                 =°)
//\ Prakash Punnoor /\\
V_/                 \_V

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]