On 8/3/07, Pete Zaitcev [EMAIL PROTECTED] wrote:
I am wondering if Ubuntu has better user reporting, so if Matthew
complains, it really means something.
https://bugs.launchpad.net/bugs/85488
Most of the current quirks list was assembled by Oliver from this thread IIRC.
/Amit
--
Amit
On Fri, 3 Aug 2007, Adam Kropelin wrote:
Although I have no proof immediately at hand, I suspect at a minimum HID
power class devices should be blacklisted from autosuspend. Given the
spotty USB implementations on many such devices I'd be surprised if
suspend worked reliably.
I agree
On Friday 03 August 2007, Dave Jones wrote:
Plus if you're connected to such a device for monitoring purposes you're
probably powered by it as well, so you have little to gain from suspend
even if it works.
I currently don't have any HID UPS by hand to verify, but I'd be
On Fri, Aug 03, 2007 at 05:31:52PM +0200, Jiri Kosina wrote:
Plus if you're connected to such a device for monitoring purposes you're
probably powered by it as well, so you have little to gain from suspend
even if it works.
I currently don't have any HID UPS by hand to verify, but
Dave Jones wrote:
On Fri, Aug 03, 2007 at 05:31:52PM +0200, Jiri Kosina wrote:
Plus if you're connected to such a device for monitoring purposes
you're probably powered by it as well, so you have little to gain
from suspend even if it works.
I currently don't have any HID UPS by hand to
On Fri, 03 Aug 2007 15:29:21 -0400, Chuck Ebbert [EMAIL PROTECTED] wrote:
Well, we did - with hindsight it may not have been such a great plan :)
I believe that Fedora did as well, but have disabled it in an update
kernel.
Yeah, autosuspend broke too many devices. Way too many.
Glad
On Thursday 02 August 2007, Matthew Garrett wrote:
The main
concern I have is that kernel developers just don't tend to be the sort
of people that use webcams, printers or scanners, so we're relying on
normal users to go to the effort of reporting that their device has
stopped working.
On Thursday 02 August 2007, Alan Stern wrote:
Also, building something this sweeping into a kernel driver feels like
a mistake. It ought to be more easily configurable from userspace, say
via a sysfs file.
Yeah, I could have sworn there was extensive discussion over the
creation of a sysfs
Am Freitag 03 August 2007 schrieb Matthew Garrett:
Also, we have udev rules for SANE that disables their autosuspend
settings, which handles the majority of the devices we have seen with
problems.
Several printers seem to have the issue as well, and the blacklist seems
to contain some
Matthew Garrett wrote:
On Fri, Aug 03, 2007 at 01:44:02PM +0200, Oliver Neukum wrote:
Am Freitag 03 August 2007 schrieb Matthew Garrett:
It's certainly possible to do that, but it's also possible to have a
userspace solution that whitelists devices. The question is whether the
default
On Fri, Aug 03, 2007 at 01:44:02PM +0200, Oliver Neukum wrote:
Am Freitag 03 August 2007 schrieb Matthew Garrett:
It's certainly possible to do that, but it's also possible to have a
userspace solution that whitelists devices. The question is whether the
default kernel behaviour should be
On Thu, Aug 02, 2007 at 11:01:08PM -0700, David Brownell wrote:
Seems to me it ought to be practical to organize a database that can
be consulted by an outcall from udev, disabling autosuspend on devices
which are known to be broken. The modules.usbmap syntax is an obvious
place to start
On Friday 03 August 2007, Matthew Garrett wrote:
On Fri, Aug 03, 2007 at 07:01:11AM -0700, David Brownell wrote:
Which is, as I pointed out, the wrong response. Desktoppy
people should be making their tools do more intelligent things
with new USB devices they see ... like updating
On Fri, 3 Aug 2007, Dave Jones wrote:
Interesting. Which devices did you notice failing? Was it a case that
they would sleep and not come back out of that state?
Random keyboards, even connection to EHCI/OHCI seemed to make difference.
We have been doing some experiments with Alan during
On Fri, Aug 03, 2007 at 04:43:16PM +0200, Jiri Kosina wrote:
On Fri, 3 Aug 2007, Matthew Garrett wrote:
Windows will autosuspend hubs, bluetooth devices, HID devices
Hi Matthew,
are you sure about windows suspending the HID devices in runtime? I have
never seen LEDs of USB
On Fri, Aug 03, 2007 at 07:01:11AM -0700, David Brownell wrote:
Which is, as I pointed out, the wrong response. Desktoppy
people should be making their tools do more intelligent things
with new USB devices they see ... like updating databases of
broken devices, and configuring *this* system
On Fri, Aug 03, 2007 at 10:41:13AM -0400, Alan Stern wrote:
On Fri, 3 Aug 2007, Matthew Garrett wrote:
I'm not so
enthusiastic about the Increase the timeout case - it doesn't avoid
any races, just makes them less likely. USB is likely to get loaded in
the initramfs, but we may not
On 8/3/07, Rogan Dawes [EMAIL PROTECTED] wrote:
Matthew Garrett wrote:
On Fri, Aug 03, 2007 at 01:44:02PM +0200, Oliver Neukum wrote:
Am Freitag 03 August 2007 schrieb Matthew Garrett:
It's certainly possible to do that, but it's also possible to have a
userspace solution that whitelists
On Fri, Aug 03, 2007 at 02:26:43PM +0200, Rogan Dawes wrote:
Compare that to:
My USB printer broke, guess I'd better report it to LKML.
But while this is still a likely probability, the chances are no
distribution is going to ship with CONFIG_USB_SUSPEND enabled. Breaking
people's hardware
On Fri, Aug 03, 2007 at 09:29:16AM -0700, David Brownell wrote:
On Friday 03 August 2007, Matthew Garrett wrote:
And, frankly, if I got a requestor like that every time I plugged in a
new USB device I'd be fairly unhappy.
Which is why my comment was about something else entirely!
That
Dave Jones wrote:
On Fri, Aug 03, 2007 at 04:43:16PM +0200, Jiri Kosina wrote:
On Fri, 3 Aug 2007, Matthew Garrett wrote:
Windows will autosuspend hubs, bluetooth devices, HID devices
Hi Matthew,
are you sure about windows suspending the HID devices in runtime? I
have never seen LEDs of
On Fri, Aug 03, 2007 at 04:43:16PM +0200, Jiri Kosina wrote:
are you sure about windows suspending the HID devices in runtime? I have
never seen LEDs of USB keyboard connected to windows host to go off after
some time of not using it.
Ah, sorry - on reading more closely, HID devices will
On Thu, Aug 02, 2007 at 11:06:08PM -0700, David Brownell wrote:
Sometimes when I plug in a USB device I get a dialog asking if I want to
configure it ... surely it would be possible to have that mechanism also
consult a database (part of a distro, or on some web server) fpr info
about
On Fri, Aug 03, 2007 at 09:57:45AM +0200, Oliver Neukum wrote:
Kernel developers are a diverser lot than you think ;-)
We don't enable autosuspend in drivers we can't test, except where
the lack of a kernel driver forces us to use a broad swipe. Printers
were tested, too, and most
On Fri, 3 Aug 2007, Matthew Garrett wrote:
Windows will autosuspend hubs, bluetooth devices, HID devices and CDC
devices, so I think we're safe suspending those by default.
And we know that we're not safe suspending scanners and many printers
by default. But that leaves plenty of other
On Fri, 3 Aug 2007, Matthew Garrett wrote:
Windows will autosuspend hubs, bluetooth devices, HID devices
Hi Matthew,
are you sure about windows suspending the HID devices in runtime? I have
never seen LEDs of USB keyboard connected to windows host to go off after
some time of not using it.
On Fri, Aug 03, 2007 at 10:28:19AM -0400, Alan Stern wrote:
On Fri, 3 Aug 2007, Matthew Garrett wrote:
There are two possible solutions, both involving the kernel (since
userspace can't respond in time). One is to change the default timeout
to something larger, or even disable it completely.
Am Freitag 03 August 2007 schrieb Matthew Garrett:
On Thu, Aug 02, 2007 at 11:01:08PM -0700, David Brownell wrote:
Seems to me it ought to be practical to organize a database that can
be consulted by an outcall from udev, disabling autosuspend on devices
which are known to be broken. The
On Fri, 3 Aug 2007, Matthew Garrett wrote:
This patch is exactly that - a way of getting most of the benefits of
autosuspend without any real probability of breaking hardware. If you
mean Are the distributions willing to pop up dialogs asking users to
start caring about obscure aspects of
On Fri, Aug 03, 2007 at 04:32:07PM +0200, Oliver Neukum wrote:
Am Freitag 03 August 2007 schrieb Dave Jones:
On Fri, Aug 03, 2007 at 09:57:45AM +0200, Oliver Neukum wrote:
Kernel developers are a diverser lot than you think ;-)
We don't enable autosuspend in drivers we can't
On Friday 03 August 2007, Dave Jones wrote:
On Thu, Aug 02, 2007 at 11:06:08PM -0700, David Brownell wrote:
Sometimes when I plug in a USB device I get a dialog asking if I want to
configure it ... surely it would be possible to have that mechanism also
consult a database (part of a
Am Freitag 03 August 2007 schrieb Matthew Garrett:
Which is why I didn't suggest doing that, of course. The only
one making that kind of straw man argument seems to be you.
But however you phrase it, that's effectively what it is. Does your
device work? just makes users wonder why the
On Friday 03 August 2007, Matthew Garrett wrote:
On Fri, Aug 03, 2007 at 07:37:55AM -0700, David Brownell wrote:
On Friday 03 August 2007, Matthew Garrett wrote:
Popping up a box saying Is your device broken? isn't good UI.
Which is why I didn't suggest doing that, of course. The only
On Fri, Aug 03, 2007 at 07:37:55AM -0700, David Brownell wrote:
On Friday 03 August 2007, Matthew Garrett wrote:
Popping up a box saying Is your device broken? isn't good UI.
Which is why I didn't suggest doing that, of course. The only
one making that kind of straw man argument seems to
On Friday 03 August 2007, Matthew Garrett wrote:
On Fri, Aug 03, 2007 at 02:26:43PM +0200, Rogan Dawes wrote:
Which one is more likely to conclude at some point?
Good question ... though how will it conclude is also relevant.
Compare that to:
My USB printer broke, guess I'd better
On Fri, Aug 03, 2007 at 01:32:53PM +0100, Matthew Garrett wrote:
On Fri, Aug 03, 2007 at 02:26:43PM +0200, Rogan Dawes wrote:
Compare that to:
My USB printer broke, guess I'd better report it to LKML.
But while this is still a likely probability, the chances are no
distribution is
On Fri, Aug 03, 2007 at 09:29:16AM -0700, David Brownell wrote:
On Friday 03 August 2007, Matthew Garrett wrote:
Speaking of which, what's this /dev/bus/usb/* crap on Ubuntu?
I had to undo all that on my Feisty system before any normal
/proc/bus/usb stuff would work again.
Usbfs
On Fri, 3 Aug 2007, Oliver Neukum wrote:
Devices rarely simply crash.
It's rare, but it does happen. I've seen a device get so messed up by
suspend that it needed a reset; it wouldn't be surprising to find other
devices requiring a power cycle.
Alan Stern
On Fri, Aug 03, 2007 at 10:44:35AM -0700, Greg KH wrote:
On Fri, Aug 03, 2007 at 01:32:53PM +0100, Matthew Garrett wrote:
But while this is still a likely probability, the chances are no
distribution is going to ship with CONFIG_USB_SUSPEND enabled.
I wouldn't be so sure, I was thinking
On Fri, 3 Aug 2007 10:24:16 -0400, Dave Jones [EMAIL PROTECTED] wrote:
On Fri, Aug 03, 2007 at 09:57:45AM +0200, Oliver Neukum wrote:
Kernel developers are a diverser lot than you think ;-)
We don't enable autosuspend in drivers we can't test, except where
the lack of a kernel driver
On Fri, Aug 03, 2007 at 12:34:47PM -0700, Pete Zaitcev wrote:
On Fri, 3 Aug 2007 10:24:16 -0400, Dave Jones [EMAIL PROTECTED] wrote:
On Fri, Aug 03, 2007 at 09:57:45AM +0200, Oliver Neukum wrote:
Kernel developers are a diverser lot than you think ;-)
We don't enable
On 08/03/2007 01:48 PM, Matthew Garrett wrote:
On Fri, Aug 03, 2007 at 10:44:35AM -0700, Greg KH wrote:
On Fri, Aug 03, 2007 at 01:32:53PM +0100, Matthew Garrett wrote:
But while this is still a likely probability, the chances are no
distribution is going to ship with CONFIG_USB_SUSPEND
On Fri, 3 Aug 2007 15:45:32 -0400, Dave Jones [EMAIL PROTECTED] wrote:
My experience suggests the opposite. Of the several I've tried so far,
none have worked with usb suspend.
All of mine work. I'm wondering if this has something to do with
a hub or motherboard... How should
On Fri, Aug 03, 2007 at 06:08:11PM +0200, Oliver Neukum wrote:
Am Freitag 03 August 2007 schrieb Matthew Garrett:
Which is why I didn't suggest doing that, of course. The only
one making that kind of straw man argument seems to be you.
But however you phrase it, that's
On Fri, Aug 03, 2007 at 10:44:35AM -0700, Greg KH wrote:
On Fri, Aug 03, 2007 at 01:32:53PM +0100, Matthew Garrett wrote:
On Fri, Aug 03, 2007 at 02:26:43PM +0200, Rogan Dawes wrote:
Compare that to:
My USB printer broke, guess I'd better report it to LKML.
But while
On Fri, 3 Aug 2007, Dave Jones wrote:
here's a head start for you.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243038
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246713
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243953
On Fri, Aug 03, 2007 at 05:17:24PM -0400, Alan Stern wrote:
The last report appears to be related more to the EHCI-cpufreq problem,
for which a patch was recently posted.
There seem to be multiple issues there, with at least one of them being
autosuspend related.
--
Matthew Garrett |
On Fri, Aug 03, 2007 at 05:17:24PM -0400, Alan Stern wrote:
On Fri, 3 Aug 2007, Dave Jones wrote:
here's a head start for you.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243038
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=246713
We're seeing a large number of problems with devices not appreciating
USB autosuspend, especially printers and scanners. According to
http://www.microsoft.com/whdc/system/bus/USB/USBFAQ_intro.mspx only a
subset of drivers support it in Windows XP, meaning that most devices
are probably
On Fri, Aug 03, 2007 at 12:56:13AM +0100, Matthew Garrett wrote:
We're seeing a large number of problems with devices not appreciating
USB autosuspend, especially printers and scanners. According to
http://www.microsoft.com/whdc/system/bus/USB/USBFAQ_intro.mspx only a
subset of drivers
On Thu, Aug 02, 2007 at 06:15:05PM -0700, Greg KH wrote:
Well, if you do this, then you can pretty much delete the whole quirk
table we have, right?
At the moment, yes.
And personally, I want to do better than Windows XP when it comes to
power management. This patch is only going to
On Fri, 3 Aug 2007, Matthew Garrett wrote:
On Thu, Aug 02, 2007 at 06:15:05PM -0700, Greg KH wrote:
Well, if you do this, then you can pretty much delete the whole quirk
table we have, right?
At the moment, yes.
And personally, I want to do better than Windows XP when it comes to
52 matches
Mail list logo
