Re: [linux-usb-devel] Disable autosuspend for scanners/printers
Am Donnerstag 09 August 2007 schrieb Alan Stern: Oliver and Pete: Is it possible to replace all those USB_QUIRK_NO_AUTOSUSPEND entries for scanners with a single class-wide entry? Which class? It would have to blanket all vendor specific devices. This is a rather broad swipe. What about printers? Just remove the autosuspend support from the driver if you really want to do this. Would a USB_QUIRK_RESET_RESUME entry suffice or do we really need NO_AUTOSUSPEND? Having no way to test, I am conservative. Besides, is RESET_RESUME the right thing to do for a device driven by usbfs? It would turn close() into an operation that can cause a reset as a side effect. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Disable autosuspend for scanners/printers
On Sun, 12 Aug 2007, Oliver Neukum wrote: Am Donnerstag 09 August 2007 schrieb Alan Stern: Oliver and Pete: Is it possible to replace all those USB_QUIRK_NO_AUTOSUSPEND entries for scanners with a single class-wide entry? Which class? It would have to blanket all vendor specific devices. This is a rather broad swipe. I was hoping there would be a specific device class for scanners. Oh well. I'm beginning to agree with Matthew Garrett that autosuspend should be disabled by default except for known-good devices and device classes... What about printers? Just remove the autosuspend support from the driver if you really want to do this. Is that good enough? If a printer is plugged in when the system boots, the delay between enumerating the device and loading the driver can be long enough for the device to get autosuspended. Would a USB_QUIRK_RESET_RESUME entry suffice or do we really need NO_AUTOSUSPEND? Having no way to test, I am conservative. Besides, is RESET_RESUME the right thing to do for a device driven by usbfs? It would turn close() into an operation that can cause a reset as a side effect. There's nothing wrong with that. The kernel makes no guarantees about what happens to a device driven by usbfs while its file is closed. The next program to open the file can't depend on finding the device in any particular state; this has always been true. Alan Stern - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Disable autosuspend for scanners/printers
Am Sonntag 12 August 2007 schrieb Alan Stern: On Sun, 12 Aug 2007, Oliver Neukum wrote: Am Donnerstag 09 August 2007 schrieb Alan Stern: Oliver and Pete: Is it possible to replace all those USB_QUIRK_NO_AUTOSUSPEND entries for scanners with a single class-wide entry? Which class? It would have to blanket all vendor specific devices. This is a rather broad swipe. I was hoping there would be a specific device class for scanners. Oh well. It is a flaw in the USB spec. I'm beginning to agree with Matthew Garrett that autosuspend should be disabled by default except for known-good devices and device classes... We could simply revert to enabling autosuspend only for those devices whose driver requests it. Most problems are with devices accessed through usbfs. What about printers? Just remove the autosuspend support from the driver if you really want to do this. Is that good enough? If a printer is plugged in when the system boots, the delay between enumerating the device and loading the driver can be long enough for the device to get autosuspended. How many devices truely crash? Would a USB_QUIRK_RESET_RESUME entry suffice or do we really need NO_AUTOSUSPEND? Having no way to test, I am conservative. Besides, is RESET_RESUME the right thing to do for a device driven by usbfs? It would turn close() into an operation that can cause a reset as a side effect. There's nothing wrong with that. The kernel makes no guarantees about what happens to a device driven by usbfs while its file is closed. The next program to open the file can't depend on finding the device in any particular state; this has always been true. In theory you are right. In theory there's no difference to practice. Before autsuspend the kernel left devices alone unless user space requested action. Regards Oliver - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Disable autosuspend for scanners/printers
On Sun, 12 Aug 2007, Oliver Neukum wrote: I'm beginning to agree with Matthew Garrett that autosuspend should be disabled by default except for known-good devices and device classes... We could simply revert to enabling autosuspend only for those devices whose driver requests it. Most problems are with devices accessed through usbfs. That's not the point. We're okay with drivers that don't support autosuspend and we're mostly okay with drivers that do. The problems seem to fall into two classes: 1. Devices with no driver. 2. Devices that can't suspend but whose driver requests autosuspend. Case 1 includes usbfs. However all devices -- other than hubs -- can fall into case 1 temporarily, if it takes longer than a few seconds to load their driver module. (Note that usbfs doesn't support autosuspend. Hence any device claimed by usbfs won't autosuspend until the device file is closed.) If a device has no driver then it's logical to assume the kernel knows nothing about how the device will behave (unless the device belongs to a known-good class). The safest course is to leave autosuspend disabled by default and let userspace enable it if desired. This leaves open the question of what to do when the first driver binds to the device or the last driver unbinds. Case 2 is harder; it includes the troublesome printers. For them we may rely on the quirks list or change the printer driver. Is that good enough? If a printer is plugged in when the system boots, the delay between enumerating the device and loading the driver can be long enough for the device to get autosuspended. How many devices truely crash? I don't know. Weren't you the person who added all those entries to the quirks list? One of the RedHat Bugzilla reports includes a usbmon log from a printer, showing that the printer disconnects itself whenever it gets a resume (and then reconnects a little later). That's almost as bad as crashing. Alan Stern - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Disable autosuspend for scanners/printers
-Original Message- From: Greg KH [EMAIL PROTECTED] Sent: 10/08/07 04:30 =There's no way we could ever get a list of all good or all bad printers, =so no matter what we do, we'd miss some :( But better to miss suspend on some than miss working altogether on others surely? I never heard an outcry on lack if suspend that compares to that from those whose USB devices stopped working when their distro upgraded the kernel. Sam - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Disable autosuspend for scanners/printers
On Fri, 10 Aug 2007, Sam Liddicott wrote: From: Greg KH [EMAIL PROTECTED] Sent: 10/08/07 04:30 =There's no way we could ever get a list of all good or all bad printers, =so no matter what we do, we'd miss some :( But better to miss suspend on some than miss working altogether on others surely? I never heard an outcry on lack if suspend that compares to that from those whose USB devices stopped working when their distro upgraded the kernel. Even if we don't handle printers right now, it would help to cover all scanners with a single class-wide quirks entry instead of lots of individual device entries. Alan Stern - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Disable autosuspend for scanners/printers
Please lets do this. It would shameful for every new device to not work until the next release of most distributions. We should either do this, or have soft blacklists that can be loaded from file, or have whitelists for suspend-ok. Sam -Original Message- From: Alan Stern [EMAIL PROTECTED] To: Oliver Neukum [EMAIL PROTECTED]; Pete Zaitcev [EMAIL PROTECTED] Cc: Matthew Garrett [EMAIL PROTECTED]; USB development list linux-usb-devel@lists.sourceforge.net Sent: 09/08/07 20:23 Subject: [linux-usb-devel] Disable autosuspend for scanners/printers Oliver and Pete: Is it possible to replace all those USB_QUIRK_NO_AUTOSUSPEND entries for scanners with a single class-wide entry? What about printers? Would a USB_QUIRK_RESET_RESUME entry suffice or do we really need NO_AUTOSUSPEND? If these devices really can't handle being suspended then it has to be prevented within the kernel; we can't rely on udev or other userspace programs to take care of it. But we could allow udev to enable autosuspend for known-good devices in these classes. Alan Stern - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Disable autosuspend for scanners/printers
On Thu, Aug 09, 2007 at 03:23:11PM -0400, Alan Stern wrote: Oliver and Pete: Is it possible to replace all those USB_QUIRK_NO_AUTOSUSPEND entries for scanners with a single class-wide entry? What about printers? My printer suspends just fine, so I don't want to do that for all printers, if possible. Not that my desktop power consumption really matters that much though... If these devices really can't handle being suspended then it has to be prevented within the kernel; we can't rely on udev or other userspace programs to take care of it. But we could allow udev to enable autosuspend for known-good devices in these classes. There's no way we could ever get a list of all good or all bad printers, so no matter what we do, we'd miss some :( thanks, greg k-h - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
