lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTimTzjHkVQGPBRXrcb6M1_xaDY_==pB5ZyB9CJpR@mail.gmail.com>
Date:	Wed, 23 Feb 2011 16:25:23 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Marcel Holtmann <marcel@...tmann.org>,
	Matthew Garrett <mjg@...hat.com>,
	"Gustavo F. Padovan" <padovan@...fusion.mobi>,
	Alan Stern <stern@...land.harvard.edu>,
	Greg Kroah-Hartman <gregkh@...e.de>
Cc:	Jeff Chua <jeff.chua.linux@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: btusb autosuspend (was Re: Linux 2.6.38-rc6)

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 <jeff.chua.linux@...il.com> 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 <mjg@...hat.com>
> 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 <mjg@...hat.com>
>    Acked-by: Marcel Holtmann <marcel@...tmann.org>
>    Signed-off-by: Gustavo F. Padovan <padovan@...fusion.mobi>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ