[https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239507] (In reply to comment #5)> We can do two things > 1. Rebuild the RPM carefuly with CONFIG_USB_SUSPEND disabled, but without > changing anything else, see if that helps, andI think we need this anyway. There are devices that require quirks to work with it enabled, and we''ll be forever chasing those if we leave it that way.
On Tue, 19 Jun 2007 15:52:35 -0400, Chuck Ebbert <cebbert@redhat.com> wrote:> [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239507] > > (In reply to comment #5) > > We can do two things > > 1. Rebuild the RPM carefuly with CONFIG_USB_SUSPEND disabled, but without > > changing anything else, see if that helps, and > > I think we need this anyway. There are devices that require quirks > to work with it enabled, and we''ll be forever chasing those if we > leave it that way.Yeah, but that''s just for testing. In his case it may be feasible to add a quirk for the fingerprint reader, if it turns out to be a suspend and not something else. The reason I didn''t ask for usbmon trace only is that I''m always slow with parsing them and acting upon them. -- Pete
On Tue, 2007-06-19 at 15:52 -0400, Chuck Ebbert wrote:> [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239507] > > (In reply to comment #5) > > We can do two things > > 1. Rebuild the RPM carefuly with CONFIG_USB_SUSPEND disabled, but without > > changing anything else, see if that helps, and > > I think we need this anyway. There are devices that require quirks > to work with it enabled, and we''ll be forever chasing those if we > leave it that way.For F7, maybe. But we really should be looking at having it enabled for F8 and getting the devices quirked that need to be so. Otherwise, we''re going to continue to bleed battery life off. Jeremy
On Tue, 2007-06-19 at 16:27 -0400, Jeremy Katz wrote:> On Tue, 2007-06-19 at 15:52 -0400, Chuck Ebbert wrote: > > [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239507] > > > > (In reply to comment #5) > > > We can do two things > > > 1. Rebuild the RPM carefuly with CONFIG_USB_SUSPEND disabled, but without > > > changing anything else, see if that helps, and > > > > I think we need this anyway. There are devices that require quirks > > to work with it enabled, and we''ll be forever chasing those if we > > leave it that way. > > For F7, maybe. But we really should be looking at having it enabled for > F8 and getting the devices quirked that need to be so. Otherwise, we''re > going to continue to bleed battery life off.Oh, and people can opt into disabling it completely by adding usbcore.autosuspend=0 to the kernel command line iirc. I think there''s also a per-device way to do it once booted, but that''s not coming to my feeble memory at the moment Jeremy
Hi. On Wednesday 20 June 2007 06:27:04 Jeremy Katz wrote:> On Tue, 2007-06-19 at 15:52 -0400, Chuck Ebbert wrote: > > [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239507] > > > > (In reply to comment #5) > > > We can do two things > > > 1. Rebuild the RPM carefuly with CONFIG_USB_SUSPEND disabled, butwithout> > > changing anything else, see if that helps, and > > > > I think we need this anyway. There are devices that require quirks > > to work with it enabled, and we''ll be forever chasing those if we > > leave it that way. > > For F7, maybe. But we really should be looking at having it enabled for > F8 and getting the devices quirked that need to be so. Otherwise, we''re > going to continue to bleed battery life off.I''d like to see this enabled too. USB related suspend and resume problems have gone away since around 2.6.18, and I''m pretty sure that at least part of the reason is this new support. Regards, Nigel
On Wed, 20 Jun 2007 08:45:19 +1000, Nigel Cunningham <ncunning@redhat.com> wrote:> I''d like to see this enabled too. USB related suspend and resume problems have > gone away since around 2.6.18, and I''m pretty sure that at least part of the > reason is this new support.The autosuspend has little to share with normal suspend/resume. Although I suppose you can encounter a case when autosuspend helps, because the port was suspended by the time real suspend happens. On resume though, they never intersect. -- Pete
On Tue, 2007-06-19 at 16:27 -0400, Jeremy Katz wrote:> On Tue, 2007-06-19 at 15:52 -0400, Chuck Ebbert wrote: > > [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239507] > > > > (In reply to comment #5) > > > We can do two things > > > 1. Rebuild the RPM carefuly with CONFIG_USB_SUSPEND disabled, but without > > > changing anything else, see if that helps, and > > > > I think we need this anyway. There are devices that require quirks > > to work with it enabled, and we''ll be forever chasing those if we > > leave it that way. > > For F7, maybe. But we really should be looking at having it enabled for > F8 and getting the devices quirked that need to be so. Otherwise, we''re > going to continue to bleed battery life off.Of course, upstream doesn''t seem all that inclined[1] to make it so that devices can actually work. *sigh* Jeremy [1] http://thread.gmane.org/gmane.linux.usb.devel/55192
On Wed, Jun 20, 2007 at 10:29:08AM -0400, Jeremy Katz wrote: > On Tue, 2007-06-19 at 16:27 -0400, Jeremy Katz wrote: > > On Tue, 2007-06-19 at 15:52 -0400, Chuck Ebbert wrote: > > > [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239507] > > > > > > (In reply to comment #5) > > > > We can do two things > > > > 1. Rebuild the RPM carefuly with CONFIG_USB_SUSPEND disabled, but without > > > > changing anything else, see if that helps, and > > > > > > I think we need this anyway. There are devices that require quirks > > > to work with it enabled, and we''ll be forever chasing those if we > > > leave it that way. > > > > For F7, maybe. But we really should be looking at having it enabled for > > F8 and getting the devices quirked that need to be so. Otherwise, we''re > > going to continue to bleed battery life off. > > Of course, upstream doesn''t seem all that inclined[1] to make it so that > devices can actually work. *sigh* > > Jeremy > > [1] http://thread.gmane.org/gmane.linux.usb.devel/55192 Adding udev callouts as he suggests shouldn''t be difficult though should it? Dave -- http://www.codemonkey.org.uk
Dave Jones (davej@redhat.com) said:> > Of course, upstream doesn''t seem all that inclined[1] to make it so that > > devices can actually work. *sigh* > > Adding udev callouts as he suggests shouldn''t be difficult though should it?You don''t want udev callouts that simply. You want udev callouts that disable autosuspend when it''s charging, monitor the battery for fully charged state, and then enable it again. Wheeeeee. Bill
On Wed, 2007-06-20 at 13:39 -0400, Bill Nottingham wrote:> Dave Jones (davej@redhat.com) said: > > > Of course, upstream doesn''t seem all that inclined[1] to make it so that > > > devices can actually work. *sigh* > > > > Adding udev callouts as he suggests shouldn''t be difficult though should it? > > You don''t want udev callouts that simply. You want udev callouts that > disable autosuspend when it''s charging, monitor the battery for fully > charged state, and then enable it again. Wheeeeee.There''s no real way to tell if the device is fully charged or not for most devices AFAIK Jeremy
Bill Nottingham wrote:> Dave Jones (davej@redhat.com) said: >> > Of course, upstream doesn''t seem all that inclined[1] to make it so that >> > devices can actually work. *sigh* >> >> Adding udev callouts as he suggests shouldn''t be difficult though should it? > > You don''t want udev callouts that simply. You want udev callouts that > disable autosuspend when it''s charging, monitor the battery for fully > charged state, and then enable it again. Wheeeeee.You also want the user to be able to go clicky-clicky when he doesn''t want it to charge right now. Some of this sort of device do more than just charge via usb, so there are other reasons to plug them in, but I don''t necessarily want to charge them while my laptop isn''t plugged in, either. -- Peter
On Wed, Jun 20, 2007 at 01:39:47PM -0400, Bill Nottingham wrote: > Dave Jones (davej@redhat.com) said: > > > Of course, upstream doesn''t seem all that inclined[1] to make it so that > > > devices can actually work. *sigh* > > > > Adding udev callouts as he suggests shouldn''t be difficult though should it? > > You don''t want udev callouts that simply. You want udev callouts that > disable autosuspend when it''s charging, monitor the battery for fully > charged state, and then enable it again. Wheeeeee. Sure, that''s a nice end-goal, but a good first-pass that just disables suspend when inserted, and reenables it when the device is unplugged would be better than nothing no? Dave -- http://www.codemonkey.org.uk
On Tue, 19 Jun 2007 16:29:45 -0400, Jeremy Katz <katzj@redhat.com> wrote:> Oh, and people can opt into disabling it completely by adding > usbcore.autosuspend=0 to the kernel command line iirc. I think there''s > also a per-device way to do it once booted, but that''s not coming to my > feeble memory at the momentAs far as I know, there''s no parameter to switch autosuspend globally as such. You can try usbcore.autosuspend_delay=-1 and that should do it, because I do not see code checking the parameter for the range. The "autosuspend" attribute is a boolean which governs it per device, but that''s a pain to set, and it disappears on every replug. -- Pete
Hi Pete. On Wednesday 20 June 2007 09:36:42 Pete Zaitcev wrote:> On Wed, 20 Jun 2007 08:45:19 +1000, Nigel Cunningham <ncunning@redhat.com>wrote:> > > I''d like to see this enabled too. USB related suspend and resume problemshave> > gone away since around 2.6.18, and I''m pretty sure that at least part ofthe> > reason is this new support. > > The autosuspend has little to share with normal suspend/resume. Although > I suppose you can encounter a case when autosuspend helps, because the > port was suspended by the time real suspend happens. On resume though, > they never intersect.Ah ok. Sorry for the noise! Nigel