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
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
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
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
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
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
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 <[email protected]>
Handled-By : Alexey Starikovskiy <[email protected]>
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
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
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
[email protected]
Am Sonntag, 14. Januar 2007 20:47 schrieb [email protected]:
> > 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
Am Sonntag, 14. Januar 2007 20:47 schrieb [email protected]:
> > 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
On Mon, 15 Jan 2007, Oliver Neukum wrote:
> Am Sonntag, 14. Januar 2007 20:47 schrieb [email protected]:
> > > 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
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
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
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 [email protected]:
> > > > 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
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
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
> 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