Hmm. Is there any reason we shouldn't revert commit
556ea928f78a390fe16ae584e6433dff304d3014 given the regression?
It apparently had problems before too, and caused autosuspend to be
disabled entirely, judging at least by
https://bugzilla.redhat.com/show_bug.cgi?id=528744
but there's obviously the comment about "those should be fixed now".
Apparently there are more issues.
I have no idea whether this is a USB-level issue, or a driver-level
one. There are no comments about exactly what fixed the input device
issues. So I'm adding both BT and USB people to the discussion.
Linus
On Wed, Feb 23, 2011 at 1:43 AM, Jeff Chua <[email protected]> wrote:
>
> I just encountered this reported bug using Bluetooth Intermec scanners
> and discovered that the recent kernel has the same problem as reported
> below.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=26182 ?... the bluetooth
> devices would just stop responding after a while.
>
> [ 4533.361959] btusb 8-1:1.0: no reset_resume for driver btusb?
> [ 4533.361964] btusb 8-1:1.1: no reset_resume for driver btusb?
>
> It seems to that Fedora doesn't feel this is a big problem, but for
> production systems, it's a big deal as the scanners can't connect to
> the server.
>
> Seems to relate to this commit. The workabout is to set
> usbcore.autosuspend=-1 as command line options, but as this is not
> working as intended, then it should be either be fixed or reverted.
>
> Thanks,
> Jeff.
>
>
>
> commit 556ea928f78a390fe16ae584e6433dff304d3014
> Author: Matthew Garrett <[email protected]>
> Date: ? Thu Sep 16 13:58:15 2010 -0400
>
> ? ?Bluetooth: Enable USB autosuspend by default on btusb
>
> ? ?We've done this for a while in Fedora without any obvious problems other
> ? ?than some interaction with input devices. Those should be fixed now, so
> ? ?let's try this in mainline.
>
> ? ?Signed-off-by: Matthew Garrett <[email protected]>
> ? ?Acked-by: Marcel Holtmann <[email protected]>
> ? ?Signed-off-by: Gustavo F. Padovan <[email protected]>
>
On Wed, Feb 23, 2011 at 04:25:23PM -0800, Linus Torvalds wrote:
> Hmm. Is there any reason we shouldn't revert commit
> 556ea928f78a390fe16ae584e6433dff304d3014 given the regression?
>
> It apparently had problems before too, and caused autosuspend to be
> disabled entirely, judging at least by
>
> https://bugzilla.redhat.com/show_bug.cgi?id=528744
>
> but there's obviously the comment about "those should be fixed now".
> Apparently there are more issues.
>
> I have no idea whether this is a USB-level issue, or a driver-level
> one. There are no comments about exactly what fixed the input device
> issues. So I'm adding both BT and USB people to the discussion.
I think we should revert it as it looks like there is hardware out there
that can not handle this always being enabled :(
Unless Matthew has a fix for this already?
thanks,
greg k-h
On Wed, Feb 23, 2011 at 04:25:23PM -0800, Linus Torvalds wrote:
> Hmm. Is there any reason we shouldn't revert commit
> 556ea928f78a390fe16ae584e6433dff304d3014 given the regression?
I think reverting makes sense at the moment. I haven't seen the reported
issues - I need to figure out if this is related to bus powered/self
powered devices, or what else is causing the difference.
> It apparently had problems before too, and caused autosuspend to be
> disabled entirely, judging at least by
>
> https://bugzilla.redhat.com/show_bug.cgi?id=528744
>
> but there's obviously the comment about "those should be fixed now".
> Apparently there are more issues.
Right, we were autosuspending even when there were active connections.
Marcel told me that ought to be fixed and my testing seemed to agree...
> I have no idea whether this is a USB-level issue, or a driver-level
> one. There are no comments about exactly what fixed the input device
> issues. So I'm adding both BT and USB people to the discussion.
I'll try to get time to look at this this week. Marcel, any ideas?
--
Matthew Garrett | [email protected]
Hi Linus,
* Linus Torvalds <[email protected]> [2011-02-23 16:25:23 -0800]:
> Hmm. Is there any reason we shouldn't revert commit
> 556ea928f78a390fe16ae584e6433dff304d3014 given the regression?
Go ahead and revert it, I don't have too much clue on the USB autosuspend
subsystem to be able to fix this before the 2.6.38 release.
Then we can bring this patch back together with the fix for the -next release.
--
Gustavo F. Padovan
http://profusion.mobi
On Thu, 24 Feb 2011, Matthew Garrett wrote:
> On Wed, Feb 23, 2011 at 04:25:23PM -0800, Linus Torvalds wrote:
> > Hmm. Is there any reason we shouldn't revert commit
> > 556ea928f78a390fe16ae584e6433dff304d3014 given the regression?
>
> I think reverting makes sense at the moment. I haven't seen the reported
> issues - I need to figure out if this is related to bus powered/self
> powered devices, or what else is causing the difference.
>
> > It apparently had problems before too, and caused autosuspend to be
> > disabled entirely, judging at least by
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=528744
> >
> > but there's obviously the comment about "those should be fixed now".
> > Apparently there are more issues.
>
> Right, we were autosuspending even when there were active connections.
> Marcel told me that ought to be fixed and my testing seemed to agree...
>
> > I have no idea whether this is a USB-level issue, or a driver-level
> > one. There are no comments about exactly what fixed the input device
> > issues. So I'm adding both BT and USB people to the discussion.
>
> I'll try to get time to look at this this week. Marcel, any ideas?
Take a look at Bugzilla #26182. I tried adding your address to the CC:
list, but the only address I could find that Bugzilla would accept
wasn't the same as the addresses you normally use.
Alan Stern
Am Donnerstag, 24. Februar 2011, 01:43:33 schrieb Matthew Garrett:
> On Wed, Feb 23, 2011 at 04:25:23PM -0800, Linus Torvalds wrote:
> > It apparently had problems before too, and caused autosuspend to be
> > disabled entirely, judging at least by
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=528744
> >
> > but there's obviously the comment about "those should be fixed now".
> > Apparently there are more issues.
>
> Right, we were autosuspending even when there were active connections.
> Marcel told me that ought to be fixed and my testing seemed to agree...
It kind of negates any advantage of autosuspend while the device is actually
used. My tests showed that autosuspend on btusb either works well with
active connections or not at all.
> > I have no idea whether this is a USB-level issue, or a driver-level
> > one. There are no comments about exactly what fixed the input device
> > issues. So I'm adding both BT and USB people to the discussion.
>
> I'll try to get time to look at this this week. Marcel, any ideas?
Matthew, you can set the RESET_RESUME quirk for your test
device. If it works after that, it cansupport only a limited form
of autosuspend.
HTH
Oliver