Re: [linux-usb-devel] 2.6.20-rc4: usb somehow broken
> 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 pgpXMVJl8SZJz.pgp Description: PGP signature
Re: [linux-usb-devel] 2.6.20-rc4: usb somehow broken
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 lsusb.txt.bz2 Description: BZip2 compressed data pgpUiE6baYF50.pgp Description: PGP signature
Re: [linux-usb-devel] 2.6.20-rc4: usb somehow broken
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] 2.6.20-rc4: usb somehow broken
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] 2.6.20-rc4: usb somehow broken
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 lsusb.txt.bz2 Description: BZip2 compressed data pgpUiE6baYF50.pgp Description: PGP signature
Re: [linux-usb-devel] 2.6.20-rc4: usb somehow broken
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 pgpXMVJl8SZJz.pgp Description: PGP signature
Re: [linux-usb-devel] 2.6.20-rc4: usb somehow broken
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] 2.6.20-rc4: usb somehow broken
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] 2.6.20-rc4: usb somehow broken
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] 2.6.20-rc4: usb somehow broken
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] 2.6.20-rc4: usb somehow broken
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] 2.6.20-rc4: usb somehow broken
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] 2.6.20-rc4: usb somehow broken
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] 2.6.20-rc4: usb somehow broken
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] 2.6.20-rc4: usb somehow broken
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] 2.6.20-rc4: usb somehow broken
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] 2.6.20-rc4: usb somehow broken
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] 2.6.20-rc4: usb somehow broken
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 :00:0b.1: qh 81007bc6c280 (#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] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] 2.6.20-rc4: usb somehow broken
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 :00:0b.1: qh 81007bc6c280 (#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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] 2.6.20-rc4: usb somehow broken
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 :00:0b.1: qh 81007bc6c280 (#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] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] 2.6.20-rc4: usb somehow broken
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 :00:0b.1: qh 81007bc6c280 (#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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] 2.6.20-rc4: usb somehow broken
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
