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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 20 Jan 2015 16:18:49 +0400
From:	Kirill Elagin <kirelagin@...il.com>
To:	Oliver Neukum <oneukum@...e.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: USB autosuspend causing trouble with bluetooth

I use a Logitech wireless keyboard (with a Unifying receiver) and it
keeps working fine even with `auto`.

That is, everything is OK if the receiver is plugged before
`power/control` is switched to `auto`.
But if I first set it to `auto`, then plug the receiver in, it is not
detected (nothing in dmesg). Kernel
detects it as soon as I `echo on` to the relevant `power/control`.

This laptop is too old to have USB3.0, both the receiver and BT are
attached to USB1.1 ports.
BTW I also noticed a strange thing: USB devices appear on different
buses when attached,
depending on their speed (e.g. the keyboard receiver is on bus 6 which
is USB1.1, while a
USB stick appears on bus 2 which is USB2.0 when I plug it into that
same physical port).
I’m not sure whether this is strange or normal, as I never really
payed attention.


On Tue Jan 20 2015 at 2:03:45 PM Oliver Neukum <oneukum@...e.de> wrote:
>
> On Sun, 2015-01-18 at 17:30 +0400, Kirill Elagin wrote:
> > Hello,
> >
> > Recently I started having issues with my Apple Magic Trackpad and I
> > realised that the problem was with autosuspend. Whenever I have `auto`
> > in `power/control` of my BT adapter, `btmon` shows no packets,
> > nothing. As soon as I `echo on`, all the missing packets arrive.
>
> You are not getting remote wakeups. There are two possibilities
>
> 1. the firmware of your BT adapter is faulty and the device needs to
> be added to the list of quirky devices
>
> 2. a bug in the kernel breaks remote wakeup.
>
> We need to distinguish these cases. Could you connect another device
> that uses remote wakeup (HID, CDC-ACM, ... - a keyboard or a mouse is
> easiest) to a port connected to XHCI and test autosuspend on that
> device?
>
>         Regards
>                 Oliver
>
>
>
>
--
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