LKML Archive on lore.kernel.org help / color / mirror / Atom feed
* USB autosuspend causing trouble with bluetooth @ 2015-01-18 13:30 Kirill Elagin 2015-01-20 11:03 ` Oliver Neukum 0 siblings, 1 reply; 12+ messages in thread From: Kirill Elagin @ 2015-01-18 13:30 UTC (permalink / raw) To: linux-kernel; +Cc: marcel [-- Attachment #1: Type: text/plain, Size: 869 bytes --] 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. The situation looks very similar to this thread: https://lkml.org/lkml/2014/4/2/574. As suggested, I tried `hci-tester` and I’m attaching the complete output, but, I guess, the interesting part is that with `on` in `power/control` I get: ~~~~ Inquiry (LIAC) Passed 10.254 seconds ~~~~ and with `auto` I get: ~~~~ Inquiry (LIAC) Timed out 30.365 seconds ~~~~ This is Acer 4810TG laptop with BCM2046. The kernel is 3.17.7, but I’m pretty sure I was also seeing this on 3.18.1. Bluez is 5.25. P.S. Please, CC me as I’m not a subscriber. [-- Attachment #2: hci-tester_on.log --] [-- Type: text/plain, Size: 4891 bytes --] └─# ./tools/hci-tester Reset - init Reset - setup Reset - setup complete Reset - run Reset - test passed Reset - teardown Reset - teardown complete Reset - done Read Local Version Information - init Read Local Version Information - setup Read Local Version Information - setup complete Read Local Version Information - run Read Local Version Information - test passed Read Local Version Information - teardown Read Local Version Information - teardown complete Read Local Version Information - done Read Local Supported Commands - init Read Local Supported Commands - setup Read Local Supported Commands - setup complete Read Local Supported Commands - run Read Local Supported Commands - test passed Read Local Supported Commands - teardown Read Local Supported Commands - teardown complete Read Local Supported Commands - done Read Local Supported Features - init Read Local Supported Features - setup Read Local Supported Features - setup complete Read Local Supported Features - run Read Local Supported Features - test passed Read Local Supported Features - teardown Read Local Supported Features - teardown complete Read Local Supported Features - done Read Local Extended Features - init Read Local Extended Features - setup Read Local Extended Features - setup complete Read Local Extended Features - run Read Local Extended Features - test passed Read Local Extended Features - teardown Read Local Extended Features - teardown complete Read Local Extended Features - done Read Buffer Size - init Read Buffer Size - setup Read Buffer Size - setup complete Read Buffer Size - run Read Buffer Size - test passed Read Buffer Size - teardown Read Buffer Size - teardown complete Read Buffer Size - done Read Country Code - init Read Country Code - setup Read Country Code - setup complete Read Country Code - run HCI command failed (0x01) Read Country Code - test failed Read Country Code - teardown Read Country Code - teardown complete Read Country Code - done Read BD_ADDR - init Read BD_ADDR - setup Read BD_ADDR - setup complete Read BD_ADDR - run Read BD_ADDR - test passed Read BD_ADDR - teardown Read BD_ADDR - teardown complete Read BD_ADDR - done Read Local Supported Codecs - init Read Local Supported Codecs - setup Read Local Supported Codecs - setup complete Read Local Supported Codecs - run HCI command failed (0x01) Read Local Supported Codecs - test failed Read Local Supported Codecs - teardown Read Local Supported Codecs - teardown complete Read Local Supported Codecs - done LE Read White List Size - init LE Read White List Size - setup LE Read White List Size - setup complete LE Read White List Size - run HCI command failed (0x01) LE Read White List Size - test failed LE Read White List Size - teardown LE Read White List Size - teardown complete LE Read White List Size - done LE Clear White List - init LE Clear White List - setup LE Clear White List - setup complete LE Clear White List - run HCI command failed (0x01) LE Clear White List - test failed LE Clear White List - teardown LE Clear White List - teardown complete LE Clear White List - done Inquiry (LIAC) - init Inquiry (LIAC) - setup Inquiry (LIAC) - setup complete Inquiry (LIAC) - run Inquiry (LIAC) - test passed Inquiry (LIAC) - teardown Inquiry (LIAC) - teardown complete Inquiry (LIAC) - done Create Connection - init Failed to setup lower tester user channel Create Connection - pre setup failed Create Connection - done TP/DSU/BV-02-C Reset in Advertising State - init Failed to setup upper tester user channel TP/DSU/BV-02-C Reset in Advertising State - pre setup failed TP/DSU/BV-02-C Reset in Advertising State - done Test Summary ------------ Reset Passed 0.007 seconds Read Local Version Information Passed 0.007 seconds Read Local Supported Commands Passed 0.011 seconds Read Local Supported Features Passed 0.008 seconds Read Local Extended Features Passed 0.010 seconds Read Buffer Size Passed 0.008 seconds Read Country Code Failed 0.008 seconds Read BD_ADDR Passed 0.007 seconds Read Local Supported Codecs Failed 0.009 seconds LE Read White List Size Failed 0.007 seconds LE Clear White List Failed 0.009 seconds Inquiry (LIAC) Passed 10.254 seconds Create Connection Not Run TP/DSU/BV-02-C Reset in Advertising State Not Run Total: 14, Passed: 8 (57.1%), Failed: 4, Not Run: 2 Overall execution time: 10.4 seconds [-- Attachment #3: hci-tester_auto.log --] [-- Type: text/plain, Size: 4893 bytes --] ─# ./tools/hci-tester Reset - init Reset - setup Reset - setup complete Reset - run Reset - test passed Reset - teardown Reset - teardown complete Reset - done Read Local Version Information - init Read Local Version Information - setup Read Local Version Information - setup complete Read Local Version Information - run Read Local Version Information - test passed Read Local Version Information - teardown Read Local Version Information - teardown complete Read Local Version Information - done Read Local Supported Commands - init Read Local Supported Commands - setup Read Local Supported Commands - setup complete Read Local Supported Commands - run Read Local Supported Commands - test passed Read Local Supported Commands - teardown Read Local Supported Commands - teardown complete Read Local Supported Commands - done Read Local Supported Features - init Read Local Supported Features - setup Read Local Supported Features - setup complete Read Local Supported Features - run Read Local Supported Features - test passed Read Local Supported Features - teardown Read Local Supported Features - teardown complete Read Local Supported Features - done Read Local Extended Features - init Read Local Extended Features - setup Read Local Extended Features - setup complete Read Local Extended Features - run Read Local Extended Features - test passed Read Local Extended Features - teardown Read Local Extended Features - teardown complete Read Local Extended Features - done Read Buffer Size - init Read Buffer Size - setup Read Buffer Size - setup complete Read Buffer Size - run Read Buffer Size - test passed Read Buffer Size - teardown Read Buffer Size - teardown complete Read Buffer Size - done Read Country Code - init Read Country Code - setup Read Country Code - setup complete Read Country Code - run HCI command failed (0x01) Read Country Code - test failed Read Country Code - teardown Read Country Code - teardown complete Read Country Code - done Read BD_ADDR - init Read BD_ADDR - setup Read BD_ADDR - setup complete Read BD_ADDR - run Read BD_ADDR - test passed Read BD_ADDR - teardown Read BD_ADDR - teardown complete Read BD_ADDR - done Read Local Supported Codecs - init Read Local Supported Codecs - setup Read Local Supported Codecs - setup complete Read Local Supported Codecs - run HCI command failed (0x01) Read Local Supported Codecs - test failed Read Local Supported Codecs - teardown Read Local Supported Codecs - teardown complete Read Local Supported Codecs - done LE Read White List Size - init LE Read White List Size - setup LE Read White List Size - setup complete LE Read White List Size - run HCI command failed (0x01) LE Read White List Size - test failed LE Read White List Size - teardown LE Read White List Size - teardown complete LE Read White List Size - done LE Clear White List - init LE Clear White List - setup LE Clear White List - setup complete LE Clear White List - run HCI command failed (0x01) LE Clear White List - test failed LE Clear White List - teardown LE Clear White List - teardown complete LE Clear White List - done Inquiry (LIAC) - init Inquiry (LIAC) - setup Inquiry (LIAC) - setup complete Inquiry (LIAC) - run Inquiry (LIAC) - test timed out Inquiry (LIAC) - teardown Inquiry (LIAC) - teardown complete Inquiry (LIAC) - done Create Connection - init Failed to setup lower tester user channel Create Connection - pre setup failed Create Connection - done TP/DSU/BV-02-C Reset in Advertising State - init Failed to setup upper tester user channel TP/DSU/BV-02-C Reset in Advertising State - pre setup failed TP/DSU/BV-02-C Reset in Advertising State - done Test Summary ------------ Reset Passed 0.066 seconds Read Local Version Information Passed 0.008 seconds Read Local Supported Commands Passed 0.016 seconds Read Local Supported Features Passed 0.009 seconds Read Local Extended Features Passed 0.010 seconds Read Buffer Size Passed 0.008 seconds Read Country Code Failed 0.008 seconds Read BD_ADDR Passed 0.007 seconds Read Local Supported Codecs Failed 0.007 seconds LE Read White List Size Failed 0.008 seconds LE Clear White List Failed 0.009 seconds Inquiry (LIAC) Timed out 30.365 seconds Create Connection Not Run TP/DSU/BV-02-C Reset in Advertising State Not Run Total: 14, Passed: 7 (50.0%), Failed: 5, Not Run: 2 Overall execution time: 30.5 seconds ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: USB autosuspend causing trouble with bluetooth 2015-01-18 13:30 USB autosuspend causing trouble with bluetooth Kirill Elagin @ 2015-01-20 11:03 ` Oliver Neukum 2015-01-20 12:18 ` Kirill Elagin 0 siblings, 1 reply; 12+ messages in thread From: Oliver Neukum @ 2015-01-20 11:03 UTC (permalink / raw) To: Kirill Elagin; +Cc: linux-kernel, marcel 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: USB autosuspend causing trouble with bluetooth 2015-01-20 11:03 ` Oliver Neukum @ 2015-01-20 12:18 ` Kirill Elagin 2015-01-20 12:34 ` Kirill Elagin 2015-01-20 14:06 ` Oliver Neukum 0 siblings, 2 replies; 12+ messages in thread From: Kirill Elagin @ 2015-01-20 12:18 UTC (permalink / raw) To: Oliver Neukum; +Cc: linux-kernel 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@suse.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 > > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: USB autosuspend causing trouble with bluetooth 2015-01-20 12:18 ` Kirill Elagin @ 2015-01-20 12:34 ` Kirill Elagin 2015-01-20 14:06 ` Oliver Neukum 1 sibling, 0 replies; 12+ messages in thread From: Kirill Elagin @ 2015-01-20 12:34 UTC (permalink / raw) To: Oliver Neukum; +Cc: linux-kernel I just realised I had an old USB BT-dongle so I tried it, and the trackpad was working fine with `auto` in `power/control`, so, yes, sounds like the builtin BT adapter is faulty. But here is a strange thing again: as with the keyboard I had to set `power/control` of the hub to `on` in order for the kernel to detect the dongle _and_ I also had to switch `power/control` of the dongle from `auto` to `on` in order for the kernel to notice that the dongle was plugged out. Weird. On Tue, Jan 20, 2015 at 3:18 PM, Kirill Elagin <kirelagin@gmail.com> wrote: > 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@suse.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 >> >> >> >> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: USB autosuspend causing trouble with bluetooth 2015-01-20 12:18 ` Kirill Elagin 2015-01-20 12:34 ` Kirill Elagin @ 2015-01-20 14:06 ` Oliver Neukum 2015-01-20 14:58 ` Kirill Elagin 1 sibling, 1 reply; 12+ messages in thread From: Oliver Neukum @ 2015-01-20 14:06 UTC (permalink / raw) To: Kirill Elagin; +Cc: linux-kernel On Tue, 2015-01-20 at 16:18 +0400, Kirill Elagin wrote: > 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`. Wait. There is no power/control file for the receiver before you plug it in. We are having a very big misunderstanding here. > 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`. Are you on power/control for the device or the port? If you are using the port's control file you might be switching on Port Power Off. Then of course the port will not process hotplugs. Please clarify! > > 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. That is perfectly normal. Regards Oliver PS: Please dont top-post ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: USB autosuspend causing trouble with bluetooth 2015-01-20 14:06 ` Oliver Neukum @ 2015-01-20 14:58 ` Kirill Elagin 2015-01-20 17:41 ` Oliver Neukum 0 siblings, 1 reply; 12+ messages in thread From: Kirill Elagin @ 2015-01-20 14:58 UTC (permalink / raw) To: Oliver Neukum; +Cc: linux-kernel On Tue, Jan 20, 2015 at 5:06 PM, Oliver Neukum <oneukum@suse.de> wrote: > On Tue, 2015-01-20 at 16:18 +0400, Kirill Elagin wrote: >> 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`. > > Wait. There is no power/control file for the receiver before > you plug it in. We are having a very big misunderstanding here. Sorry for not being clear. I was referring to `power/control` of the USB-device itself except for the cases when I was talking about hot-plugging issues — in those cases I was referring to the `power/control` of the root hub. I might be using terminology in a wrong way. By `power/control` of a root hub I mean `/sys/bus/usb/devices/usb<bus_number>/power/control` and by `power/control` of a device I mean `/sys/bus/usb/devices/<bus_number>-<port_number>/power/control`. >> 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`. > > Are you on power/control for the device or the port? > If you are using the port's control file you might be switching > on Port Power Off. Then of course the port will not process > hotplugs. Please clarify! In this particular case I was talking about the `power/control` of the root hub. `laptop-mode-tools` by default writes `auto` to `power/control` of _all_ the USB devices, root hubs included (even when on AC). Is it really expected that kernel might completely power off the physical USB port? Sounds weird. Here is an even more strange thing. First I set all the USB power management to the defaults (that is, `auto` for all the usb devices including root hubs). Again, the keyboard keeps working and as soon as I unplug the receiver kernel says the device was disconnected. Now if I plug the receiver back nothing happens. _But_ if I plug a flash drive in the save physical port it gets detected. So, I tried a number of other usb devices and it totally looks like USB2.0 ones are properly hot-plugged while USB1.1 devices are not. Does this sound to you like a bug in my laptop's hardware? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: USB autosuspend causing trouble with bluetooth 2015-01-20 14:58 ` Kirill Elagin @ 2015-01-20 17:41 ` Oliver Neukum 2015-01-20 19:25 ` Kirill Elagin 0 siblings, 1 reply; 12+ messages in thread From: Oliver Neukum @ 2015-01-20 17:41 UTC (permalink / raw) To: Kirill Elagin; +Cc: linux-kernel, linux-usb On Tue, 2015-01-20 at 18:58 +0400, Kirill Elagin wrote: > On Tue, Jan 20, 2015 at 5:06 PM, Oliver Neukum <oneukum@suse.de> wrote: > > On Tue, 2015-01-20 at 16:18 +0400, Kirill Elagin wrote: > >> 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`. > > > > Wait. There is no power/control file for the receiver before > > you plug it in. We are having a very big misunderstanding here. > > Sorry for not being clear. I was referring to `power/control` of the > USB-device itself except for the cases when I was talking about > hot-plugging issues — in those cases I was referring to the > `power/control` of the root hub. Please check whether you are not accidentally touching the ports linux-0dmf:/sys/bus/usb/devices/usb1/1-0:1.0/usb1-port1 At paths like this you find control files for ports, not the root hub as a device. > In this particular case I was talking about the `power/control` of the root hub. OK, so autosuspend does work if you enable it for the device but not the hub? > `laptop-mode-tools` by default writes `auto` to `power/control` of > _all_ the USB devices, root hubs included (even when on AC). Is it > really expected that kernel might completely power off the physical > USB port? Sounds weird. It can. It is a recent feature if ACPI supports that on a machine. > Here is an even more strange thing. First I set all the USB power > management to the defaults (that is, `auto` for all the usb devices > including root hubs). Again, the keyboard keeps working and as soon as > I unplug the receiver kernel says the device was disconnected. Now if > I plug the receiver back nothing happens. _But_ if I plug a flash > drive in the save physical port it gets detected. So, I tried a number > of other usb devices and it totally looks like USB2.0 ones are > properly hot-plugged while USB1.1 devices are not. Does this sound to > you like a bug in my laptop's hardware? Could be, but could also be software. Please double check where exactly an "on" is needed. Regards Oliver ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: USB autosuspend causing trouble with bluetooth 2015-01-20 17:41 ` Oliver Neukum @ 2015-01-20 19:25 ` Kirill Elagin 2015-01-20 21:47 ` Oliver Neukum 0 siblings, 1 reply; 12+ messages in thread From: Kirill Elagin @ 2015-01-20 19:25 UTC (permalink / raw) To: Oliver Neukum; +Cc: linux-kernel, linux-usb On Tue, Jan 20, 2015 at 8:41 PM, Oliver Neukum <oneukum@suse.de> wrote: > On Tue, 2015-01-20 at 18:58 +0400, Kirill Elagin wrote: >> On Tue, Jan 20, 2015 at 5:06 PM, Oliver Neukum <oneukum@suse.de> wrote: >> > On Tue, 2015-01-20 at 16:18 +0400, Kirill Elagin wrote: >> >> 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`. >> > >> > Wait. There is no power/control file for the receiver before >> > you plug it in. We are having a very big misunderstanding here. >> >> Sorry for not being clear. I was referring to `power/control` of the >> USB-device itself except for the cases when I was talking about >> hot-plugging issues — in those cases I was referring to the >> `power/control` of the root hub. > > Please check whether you are not accidentally touching the ports > linux-0dmf:/sys/bus/usb/devices/usb1/1-0:1.0/usb1-port1 > At paths like this you find control files for ports, not the > root hub as a device. > >> In this particular case I was talking about the `power/control` of the root hub. > > OK, so autosuspend does work if you enable it for the device but > not the hub? Hm, I'm pretty sure I never touched anything with `port` in its name, all the ports are set to `auto` (that's what laptop-mode-tools does). Right now I think I see three possibly unrelated issues: Issue #1. BT trackpad not working properly when connected to the builtin bluetooth adapter. ---------- The adapter is attached to a USB1.1 hub: ~~~~ # lsusb -t ... /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M |__ Port 2: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M |__ Port 2: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M |__ Port 2: Dev 2, If 2, Class=Vendor Specific Class, Driver=, 12M |__ Port 2: Dev 2, If 3, Class=Application Specific Interface, Driver=, 12M ... # cat usb3/power/control auto # cat usb3/3-*/usb3-port*/power/control auto auto # cat usb3/3-2/power/control on ~~~~ The trackpad is working fine right now. Whenever I do ~~~~ # echo auto > usb3/3-2/power/control ~~~~ and leave it alone for 5 seconds `btmon` stops showing any activity. As soon as I do ~~~~ # echo on > usb3/3-2/power/control ~~~~ the trackpad is alive again. As I mentioned this doesn’t happen when the trackpad is connected to a USB BT dongle (also USB1.1, but a different bus number). Issue #2. No hotplug with USB1.1: ---------- To see this I pick one physical port. When I plug a USB1.1 device it appears on bus 4 port 2; a USB2.0 device appears on bus 1 port 4. ~~~~ # cat usb4/power/control auto # cat usb4/4-*/usb4-port*/power/control auto auto # cat usb1/power/control auto # cat usb1/1-*/usb1-port*/power/control auto auto auto auto # journalctl -b -k -f -n 0 & [1] 8390 -- Logs begin at Fri 2015-01-02 03:13:31 MSK. -- (plug USB2.0 flash drive in) Jan 20 21:55:09 kirNote kernel: usb 4-2: USB disconnect, device number 6 Jan 20 22:00:19 kirNote kernel: usb 1-4: new high-speed USB device number 15 using ehci-pci Jan 20 22:00:19 kirNote kernel: usb 1-4: New USB device found, idVendor=0951, idProduct=1623 Jan 20 22:00:19 kirNote kernel: usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 ... (plug flash drive out) Jan 20 22:00:35 kirNote kernel: usb 1-4: USB disconnect, device number 15 (plug USB1.1 BT dongle) (nothing happens) # echo on > usb4/power/control Jan 20 22:01:09 kirNote kernel: usb 4-2: new full-speed USB device number 7 using uhci_hcd Jan 20 22:01:09 kirNote kernel: usb 4-2: New USB device found, idVendor=0a12, idProduct=0001 Jan 20 22:01:09 kirNote kernel: usb 4-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 (plug dongle out) Jan 20 22:01:26 kirNote kernel: usb 4-2: USB disconnect, device number 7 ~~~~ Issue #3. No hot-plug-out for USB1.1. -------- This issue is somewhat harder to describe as it depends on the combination of power/control of the hub and device. And there are three possible outcomes: device disconnect properly detected (both `on`), not detected at all (both `auto`), error about a port being "disabled by hub (EMI?)" in some other cases. I'm not really sure about this one and I'll get back about it later after some more experiments. I think that the first two issues are fixed by keeping all the USB1.1 hubs and the builtin BT always `on`, but I just wanted to know whether those are hardware or software bugs. Thanks for helping me investigate this! ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: USB autosuspend causing trouble with bluetooth 2015-01-20 19:25 ` Kirill Elagin @ 2015-01-20 21:47 ` Oliver Neukum 2015-01-24 9:55 ` Kirill Elagin 0 siblings, 1 reply; 12+ messages in thread From: Oliver Neukum @ 2015-01-20 21:47 UTC (permalink / raw) To: Kirill Elagin; +Cc: linux-kernel, linux-usb On Tue, 2015-01-20 at 23:25 +0400, Kirill Elagin wrote: > Hm, I'm pretty sure I never touched anything with `port` in its name, > all the ports are set to `auto` (that's what laptop-mode-tools does). Here we go. > Right now I think I see three possibly unrelated issues: > > Issue #1. BT trackpad not working properly when connected to the > builtin bluetooth adapter. > ---------- > > The adapter is attached to a USB1.1 hub: > > ~~~~ > # lsusb -t > ... > /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M > |__ Port 2: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M > |__ Port 2: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M > |__ Port 2: Dev 2, If 2, Class=Vendor Specific Class, Driver=, 12M > |__ Port 2: Dev 2, If 3, Class=Application Specific Interface, Driver=, 12M > ... > > # cat usb3/power/control > auto > > # cat usb3/3-*/usb3-port*/power/control > auto > auto Try setting this to on. > # cat usb3/3-2/power/control > on Here "auto" should work. Please try. [..] > Issue #2. No hotplug with USB1.1: > ---------- > > To see this I pick one physical port. When I plug a USB1.1 device it > appears on bus 4 port 2; a USB2.0 device appears on bus 1 port 4. > > ~~~~ > # cat usb4/power/control > auto > # cat usb4/4-*/usb4-port*/power/control > auto > auto Please set this to "on" > # cat usb1/power/control > auto > # cat usb1/1-*/usb1-port*/power/control Please set this to "on" [..] > > Issue #3. No hot-plug-out for USB1.1. > -------- > I think that the first two issues are fixed by keeping all the USB1.1 > hubs and the builtin BT always `on`, but I just wanted to know whether > those are hardware or software bugs. I suspect this is caused by outdated laptop-mode-tools. Basically setting the port controls (as opposed to hub and device controls) to "auto" tells the kernel that it may disable hotplugging to save energy. Hotunplug for devices that need remote wakeup will still work. Likewise if you disable autosuspend of the attached devices. Regards Oliver ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: USB autosuspend causing trouble with bluetooth 2015-01-20 21:47 ` Oliver Neukum @ 2015-01-24 9:55 ` Kirill Elagin 2015-01-26 17:00 ` Kirill Elagin 0 siblings, 1 reply; 12+ messages in thread From: Kirill Elagin @ 2015-01-24 9:55 UTC (permalink / raw) To: Oliver Neukum; +Cc: linux-kernel, linux-usb On Wed, Jan 21, 2015 at 12:47 AM, Oliver Neukum <oneukum@suse.de> wrote: > On Tue, 2015-01-20 at 23:25 +0400, Kirill Elagin wrote: > >> Hm, I'm pretty sure I never touched anything with `port` in its name, >> all the ports are set to `auto` (that's what laptop-mode-tools does). > > Here we go. > >> Right now I think I see three possibly unrelated issues: >> >> Issue #1. BT trackpad not working properly when connected to the >> builtin bluetooth adapter. >> ---------- >> >> The adapter is attached to a USB1.1 hub: >> >> ~~~~ >> # lsusb -t >> ... >> /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M >> |__ Port 2: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M >> |__ Port 2: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M >> |__ Port 2: Dev 2, If 2, Class=Vendor Specific Class, Driver=, 12M >> |__ Port 2: Dev 2, If 3, Class=Application Specific Interface, Driver=, 12M >> ... >> >> # cat usb3/power/control >> auto >> >> # cat usb3/3-*/usb3-port*/power/control >> auto >> auto > > Try setting this to on. > >> # cat usb3/3-2/power/control >> on > > Here "auto" should work. Please try. > [..] >> Issue #2. No hotplug with USB1.1: >> ---------- >> >> To see this I pick one physical port. When I plug a USB1.1 device it >> appears on bus 4 port 2; a USB2.0 device appears on bus 1 port 4. >> >> ~~~~ >> # cat usb4/power/control >> auto >> # cat usb4/4-*/usb4-port*/power/control >> auto >> auto > > Please set this to "on" > >> # cat usb1/power/control >> auto >> # cat usb1/1-*/usb1-port*/power/control > > Please set this to "on" I started with the defaults (`auto` everywhere) and did: ~~~~ for f in /sys/bus/usb/devices/usb*/*-*/*-port*/power/control; do echo on > $f; done ~~~~ This had absolutely _no_ effect on hotplug. As before, when I insert the keyboard receiver nothing happens until I echo `on` to `usb6/power/control`. > > [..] >> >> Issue #3. No hot-plug-out for USB1.1. >> -------- > >> I think that the first two issues are fixed by keeping all the USB1.1 >> hubs and the builtin BT always `on`, but I just wanted to know whether >> those are hardware or software bugs. > > I suspect this is caused by outdated laptop-mode-tools. I have laptop-mode-tools-1.66 and actually I initially blamed the new runtime-pm module. But it turns out, `laptop_mode` doesn't touch the ports at all. > > Basically setting the port controls (as opposed to hub and device > controls) to "auto" tells the kernel that it may disable hotplugging > to save energy. Hotunplug for devices that need remote wakeup will > still work. Likewise if you disable autosuspend of the attached devices. > > Regards > Oliver > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: USB autosuspend causing trouble with bluetooth 2015-01-24 9:55 ` Kirill Elagin @ 2015-01-26 17:00 ` Kirill Elagin 2015-01-27 18:00 ` Oliver Neukum 0 siblings, 1 reply; 12+ messages in thread From: Kirill Elagin @ 2015-01-26 17:00 UTC (permalink / raw) To: Oliver Neukum; +Cc: linux-kernel, linux-usb Things just got way worse with this hotplug thing. When the host power/control is set to `auto`, as soon as I insert the Unifying receiver one of kworkers starts eating 100% of one of the cores, according to `htop`. As soon as I `echo on` to power/control of the relevant USB hub the kworker stops doing this. This also happens with that other USB1.1 BT-dongle, so I assume any USB1.1 device would do. Also just unplugging the device is not enough, the kworker keeps eating CPU until I `echo on` to power/control. Should I start a separate thread? Right now I'm on 3.18.2-gentoo. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: USB autosuspend causing trouble with bluetooth 2015-01-26 17:00 ` Kirill Elagin @ 2015-01-27 18:00 ` Oliver Neukum 0 siblings, 0 replies; 12+ messages in thread From: Oliver Neukum @ 2015-01-27 18:00 UTC (permalink / raw) To: Kirill Elagin; +Cc: linux-kernel, linux-usb On Mon, 2015-01-26 at 21:00 +0400, Kirill Elagin wrote: > Things just got way worse with this hotplug thing. Is that a new test or did you update? > When the host power/control is set to `auto`, as soon as I insert the > Unifying receiver one of kworkers starts eating 100% of one of the But it does not enumerate the dongle, does it? > cores, according to `htop`. As soon as I `echo on` to power/control of > the relevant USB hub the kworker stops doing this. This also happens > with that other USB1.1 BT-dongle, so I assume any USB1.1 device would > do. Also just unplugging the device is not enough, the kworker keeps > eating CPU until I `echo on` to power/control. > > Should I start a separate thread? > Right now I'm on 3.18.2-gentoo. Can you tell at which kernel version this started? Regards Oliver ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2015-01-27 18:00 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-01-18 13:30 USB autosuspend causing trouble with bluetooth Kirill Elagin 2015-01-20 11:03 ` Oliver Neukum 2015-01-20 12:18 ` Kirill Elagin 2015-01-20 12:34 ` Kirill Elagin 2015-01-20 14:06 ` Oliver Neukum 2015-01-20 14:58 ` Kirill Elagin 2015-01-20 17:41 ` Oliver Neukum 2015-01-20 19:25 ` Kirill Elagin 2015-01-20 21:47 ` Oliver Neukum 2015-01-24 9:55 ` Kirill Elagin 2015-01-26 17:00 ` Kirill Elagin 2015-01-27 18:00 ` Oliver Neukum
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).