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).