Bug 200039

We need to confirm a few things:

1. There is no active scanning ongoing
2. The device is programmed in either the white list or resolving list

In which case passive scanning shall only awake the host for devices in the list, but note that would be a bug in the controller no in the host.

1. There is no other BT traffic during the testing, there is only 1 packet be captured during each s2idle wake up test.
2. I'm not sure what do you mean about white list or resolving list. The system can be waken up by any random devices around it, only if it had paired with one device.
Ex. 1. Remove all paired devices from the BT menu
    2. Pair with Logitech M585(BT4) mouse
    3. Turn off M585
    4. Enter s2idle
    5. Turn on Logitech K375s(BT4) keyboard
    6. The system wakes up automatically.

Also reproduced on the following systems with Intel Bluetooth 8087:0aaa:
Acer Swift SF314-55	
ASUS UX333FA
Asus UX433FN
Asus UX533FD

Please let us know how we can help further with diagnosis

(In reply to Luiz Von Dentz from comment #1)
> We need to confirm a few things:
> 
> 1. There is no active scanning ongoing

As the issue happens during S3 or S2Idle, if there is active scanning, I think that can only be done by the controller.

> 2. The device is programmed in either the white list or resolving list

No, the device that sends the advertising packets has not been added to these lists.

> 
> In which case passive scanning shall only awake the host for devices in the
> list, but note that would be a bug in the controller no in the host.

If I understand you correctly, do you mean waking up from seeing a device that is in the list during passive scanning is still a controller bug?

Two things:

1) Is this issue reproduced all the time from a specific BT device or all BT devices ?
2) Can we disable the selective suspend for this BT from USB bus ?

1. This issue can be reproduced when it has been paired any BT4 devices before suspended.
2. Actually, waking up the system from selective suspend(s2idle) by BT devices is an requirement, so we can't simply disable BT during suspend.

Hi,

Just get to look carefully at the steps:
Ex. 1. Remove all paired devices from the BT menu
    2. Pair with Logitech M585(BT4) mouse
    3. Turn off M585
    4. Enter s2idle
    5. Turn on Logitech K375s(BT4) keyboard
    6. The system wakes up automatically.

It looks like an expected behavior because you turn on the device(BT mouse/keyboard) that will get to link the host, so the host will wake up.

The keyboard(Logitech K375s) is not paired with the system, and the paired mouse has been turned off.
Turn on the not-paired BT devices should not wake up the system.

>The keyboard(Logitech K375s) is not paired with the system, and the paired
>mouse has been turned off.
>Turn on the not-paired BT devices should not wake up the system.
It sounds totally making no sense to me.
Are we looking a non-paired BT device that is likely to wake the platform through BT ?
If that is the case, any BT devices around host are able to wake the platform no matter they are paired or not.
Or, I am misunderstanding anything here?

>1. This issue can be reproduced when it has been paired any BT4 devices before
>suspended.
So you turned off the BT4 device after entering S2idle then issue is happened ?

I am sorry, but it seems to me not quite clear what the reproducing steps are.

The paired mouse has been turned off before entering s2idle.
The system will be waken up by any random BT4 devices around the machine, no matter they are paired or not.

The steps mentioned above should describe what I did clearly.
    1. Remove all paired devices from the BT menu
        - No BT devices are paired with.
    2. Pair with Logitech M585(BT4) mouse
        - only this BT4 mouse is paired.
    3. Turn off M585
        - power off the BT4 mouse
    4. Enter s2idle
    5. Turn on Logitech K375s(BT4) keyboard
        - Other random BT4 devices are powered on
    6. The system wakes up automatically.
        - From the BT monitor, there is only one BT packet we got and it wakes the system up.

From the snoop logs, as i understand when the system is put to suspend - BT scan operation is active.  And hence the for any of the device found - Adv report event will be notify to host by waking up the system.

As Luiz commented above, looks like there is active scan/passive scan must have trigger the LE Scan operation. BT controller will not trigger any active/passive scan by itself. 

Request you to please confirm was there any BT LE scan operation was triggered.

No, there is no scan operation while entering s2idle.
We closed the BT dialogue and didn't run any hci commands, there is only one traffic captured by btmon during s2idle, it's advertising packet with random BT MAC.

(In reply to AceLan Kao from comment #12)
> No, there is no scan operation while entering s2idle.
> We closed the BT dialogue and didn't run any hci commands, there is only one
> traffic captured by btmon during s2idle, it's advertising packet with random
> BT MAC.

Request you to share complete btmon logs from the beginning of the test.

I've uploaded the btmon log, log from btmon, it wakes up the system 4 times by 4 packets 
https://bugzilla.kernel.org/attachment.cgi?id=276493

I didn't add any parameters, just run btmon directly.

Created attachment 278945 [details]
attachment-27797-0.html

Hi,

Thank you for your email.
Am on vacatoin from WW41.1 to WW42.3. Please expect delay in mail response.

Please contact Arnaud(arnaud.pierres@intel.com) for any technical information.

For any urgent information on please reach me  on phone +919880015016.

Thanks and Regards
Chethan

Created attachment 278947 [details]
attachment-29056-0.html

?
?Hello,

I am currently out of office

The presence of LE Advertisement reports in the btmon logs clearly suggests that there is either an Active scan or a Passive scan running. Since, the btmon logs attached are captured only during system suspend, we cannot conclude.

Please capture and attach the btmon logs for the complete flow 
(start btmon from the moment you initially pair the Logitech M585(BT4) mouse)


Thanks
Raghu

Created attachment 279021 [details]
full log of btmon

Here is the full log of btmon

1. run "sudo btmon"
2. Open BT settings dialog
3. Connect and pair with Designer Mouse(BT4)
4. Disconnect the BT mouse
5. Close the BT settings dialog
6. Enter S3
7. System wakes up in couple seconds automatically
8. Stop "sudo btmon"

Thanks for the sharing complete btmon logs.
As evident from the below log snippet, once the remote device is disconnected, the host will start a Passive scan. The filter policy is set to "Accept all advertisement" as the previously paired device in the White List (Designer Mouse) has random address:

< HCI Command: Disconnect (0x01|0x0006) plen 3            #159 [hci0] 19.853664
        Handle: 3585
        Reason: Remote User Terminated Connection (0x13)
> HCI Event: Command Status (0x0f) plen 4                 #160 [hci0] 19.855749
      Disconnect (0x01|0x0006) ncmd 1
        Status: Success (0x00)
> HCI Event: Disconnect Complete (0x05) plen 4            #161 [hci0] 19.903759
        Status: Success (0x00)
        Handle: 3585
        Reason: Connection Terminated By Local Host (0x16)
@ MGMT Event: Command Complete (0x0001) plen 10       {0x0001} [hci0] 19.903829
      Disconnect (0x0014) plen 7
        Status: Success (0x00)
        LE Address: DF:29:ED:8F:82:95 (Static)
@ MGMT Event: Device Disconnected (0x000c) plen 8     {0x0003} [hci0] 19.903852
        LE Address: DF:29:ED:8F:82:95 (Static)
        Reason: Connection terminated by local host (0x02)
@ MGMT Event: Device Disconnected (0x000c) plen 8     {0x0002} [hci0] 19.903852
        LE Address: DF:29:ED:8F:82:95 (Static)
        Reason: Connection terminated by local host (0x02)
< HCI Command: LE Set Scan Parame.. (0x08|0x000b) plen 7  #162 [hci0] 19.949197
        Type: Passive (0x00)
        Interval: 60.000 msec (0x0060)
        Window: 30.000 msec (0x0030)
        Own address type: Public (0x00)
        Filter policy: Accept all advertisement (0x00)
> HCI Event: Command Complete (0x0e) plen 4               #163 [hci0] 19.949798
      LE Set Scan Parameters (0x08|0x000b) ncmd 1
        Status: Success (0x00)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2    #164 [hci0] 19.949848
        Scanning: Enabled (0x01)
        Filter duplicates: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4               #165 [hci0] 19.951759
      LE Set Scan Enable (0x08|0x000c) ncmd 2
        Status: Success (0x00)


Since, passive scan is going on when the system is put to suspend, the system wakes up when any Advertisement report is received.

Thanks,
Raghu

(In reply to AceLan Kao from comment #18)
> Created attachment 279021 [details]
> full log of btmon
> 
> Here is the full log of btmon
> 
> 1. run "sudo btmon"
> 2. Open BT settings dialog
> 3. Connect and pair with Designer Mouse(BT4)
> 4. Disconnect the BT mouse
> 5. Close the BT settings dialog
> 6. Enter S3
> 7. System wakes up in couple seconds automatically
> 8. Stop "sudo btmon"


As explained in my previous comment, this is a normal/expected behavior as the passive scan is running in background.

Request you to close this bug.

Thanks,
Raghu

> As explained in my previous comment, this is a normal/expected behavior as
> the passive scan is running in background.

Shouldn't the kernel driver cancel any currently active passive scans during it's suspend call back methods?

I think the behavior should be normal.
When BT dialog is opened, it start accepting all advertisement, and stop receiving packet after it's closed. This behavior is easy to be observed. From the full log, packets before #219 are received when the BT dialog is opened, and #220 is received during S3.

But the issue is, the advertising packets are only be received after there is a paired BT4 device(no matter it's connected or not).
It very simple to verify.

1. remove all BT devices from BT dialog and close the BT dialog
2. run "btmon" and got nothing

1. pair non-BT4 devices(you can leave it connected) and close BT dialog
2. nothing from "btmon" if you don't touch the paired device.

1. pair BT4 devices and disconnected them(even power off them)
2. we got advertising packet from other BT4 devices.

I'm not sure if "Accept all advertisement" is the culprit, but I'm willing to know if there is any command we can try to disable it to see if it helps.

(In reply to AceLan Kao from comment #22)
> I think the behavior should be normal.
> When BT dialog is opened, it start accepting all advertisement, and stop
> receiving packet after it's closed. This behavior is easy to be observed.
> From the full log, packets before #219 are received when the BT dialog is
> opened, and #220 is received during S3.
> 
> But the issue is, the advertising packets are only be received after there
> is a paired BT4 device(no matter it's connected or not).
> It very simple to verify.
> 
> 1. remove all BT devices from BT dialog and close the BT dialog
> 2. run "btmon" and got nothing
> 
> 1. pair non-BT4 devices(you can leave it connected) and close BT dialog
> 2. nothing from "btmon" if you don't touch the paired device.
> 
> 1. pair BT4 devices and disconnected them(even power off them)
> 2. we got advertising packet from other BT4 devices.
> 
> I'm not sure if "Accept all advertisement" is the culprit, but I'm willing
> to know if there is any command we can try to disable it to see if it helps.


In the full log, you can see that after #123, MGMT command 'Add Device' is sent with Action parameter set to 'Auto-connect remote device (0x02)'. So, when pairing with a LE device, 'HCI_AUTO_CONN_ALWAYS' flag is set.

In the HCI Disconnection Complete Event handler (hci_disconn_complete_evt in net/bluetooth/hci_event.c), you can see that if the 'HCI_AUTO_CONN_ALWAYS' flag is set, LE passive scan will be started.

Since for a paired LE device, 'HCI_AUTO_CONN_ALWAYS' flag is set, when we disconnect it, LE passive scan will be started.

Setup 'HCI_AUTO_CONN_ALWAYS' flag and "Accept all advertisement" do not mean the advertising packet should wake up the system. We even powered off the paired device, but the system still be waken up by advertising packets from other random BT4 devices.

I got some questions for you and would like to figure out a feasible solution for the issue.
1. Do you have any idea about who decide to wake up the system when the advertising packet is received? Firmware or driver?
2. Do you know how windows handle this? Does the advertising packet wake up windows?
3. Is there any drawback if we remove 'HCI_AUTO_CONN_ALWAYS' flag when suspending?
Thanks.

(In reply to AceLan Kao from comment #24)
> Setup 'HCI_AUTO_CONN_ALWAYS' flag and "Accept all advertisement" do not mean
> the advertising packet should wake up the system. We even powered off the
> paired device, but the system still be waken up by advertising packets from
> other random BT4 devices.
> 
> I got some questions for you and would like to figure out a feasible
> solution for the issue.
> 1. Do you have any idea about who decide to wake up the system when the
> advertising packet is received? Firmware or driver?
> 2. Do you know how windows handle this? Does the advertising packet wake up
> windows?
> 3. Is there any drawback if we remove 'HCI_AUTO_CONN_ALWAYS' flag when
> suspending?
> Thanks.


Quoting the below paragraph under section Suspend-to-Idle from Kernel documentation (Documentation/admin-guide/pm/sleep-states.rst)
"The system is woken up from this state by in-band interrupts, so theoretically
any devices that can cause interrupts to be generated in the working state can
also be set up as wakeup devices for S2Idle."

The wakeup interrupts for the system in sleep state can be either enabled or disabled in /proc/acpi/wakeup file.  
I suppose, the USB hub to which the BT controller is attached has the 'Status' column set to 'enabled' for S-state S3.

Now, when an Advertisement packet is received by the BT controller during active/passive scan, the Advertisement Report Event is sent to the Host via HCI interface (USB transport layer). This HCI event is sent as a packet on the USB bus. Now, the USB bus wakes up the system (remote-wakeup) from suspend.

You can give the following a try and check if the advertisement reports are waking up the system from suspend:
Disable the interrupt source(device) in /proc/acpi/wakeup
Eg: If BT controller is attached to EHC2;  
echo EHC2 > /proc/acpi/wakeup [This will toggle the 'Status' column from enabled <-> disabled]

Disable the S3 wakeup in /proc/acpi/wakeup doesn't work.
Disable the wakeup from the usb devices directly doesn't work, either.
   echo disabled | sudo tee /sys/devices/pci0000:00/0000:00:14.0/usb*/power/wakeup
We also try to block the the rfkill devices by
   echo 1 | sudo tee /sys/class/rfkill/rfkill*/soft
but it still doesn't work.

The only workaround we can find is to stop the bluetooth daemon before entering S3
   sudo systemctl stop bluetooth

In Bluetooth 4.1(LE Privacy 1.1), the Private address Resolving List is maintained in the Host. Address resolution is also done by the Host. 
This requires Host intervention every time an advertisement packet with an RPA is received. 

In Bluetooth 4.2(LE Privacy 1.2), 
the Resolving List is maintained in the Controller. Since the Controller resolves the private address, the Host does not need to wake up in devices where the Host is implemented using a separate CPU. This lowers overall power consumption.

Having said that, Intel controller does support LE Privacy v1.2 feature. However Linux kernel need to enable to make use of the Link Layer privacy 
to avoid this kind of issues.

This is generic problem/behavior observed on other vendors BT controller as well that does not support LE privacy 1.2 feature. 

We highly recommend to enable LE privacy 1.2 to solve the problem.

Created attachment 279475 [details]
attachment-19423-0.html

?
?Hello,

I am currently out of office returning after US thanksgiving. Expect delayed response.

This is still an issue for me with 4.20 and an Intel AC-9260 card. If Bluetooth is on, my computer will refuse to sleep or begin to sleep before aborting. It will freeze if kept in this cycle for long enough.

(In reply to Raghuram Hegde from comment #27)
> We highly recommend to enable LE privacy 1.2 to solve the problem.

How to get this feature enabled?

After I ran:
btmgmt power off
btmgmt privacy on
btmgmt power on

The issue still occurs.

I can see that in mgmt.c's set_privacy(), HCI_PRIVACY is set and HCI_LIMITED_PRIVACY gets cleared, do they roughly translate to LE Privacy 1.2 and LE Privacy 1.1, respectively?

Created attachment 281903 [details]
attachment-27407-0.html

?
?Hello,

I will be OOO, expect delayed response.

Thanks,

Created attachment 281905 [details]
attachment-29658-0.html

Hi,

Hi,

I will be on medical leave on 18th and 19th of March 2019, for any urgent information please reach me  on phone +919880015016.

Thanks and Regards
Chethan

Regarding comment #30, is there any progress after it?
BTW, I can still see the issue by Linux kernel 5.3~rc3 on Ubuntu Eoan Ermine (development branch).

--- WORKAROUND ---

I've posted a systemd unit file and script on Unix and Linux Stack Exchange which automatically disables and re-enables the USB bluetooth device on sleep / suspend.

https://unix.stackexchange.com/questions/539762/how-do-i-suspend-sleep-while-bluetooth-is-active/539763#539763

@Tom:

The offending commit that caused this behavior is being reverted for 5.4:
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/commit/?id=1ffdb51f28e8ec6be0a2b812c1765b5cf5c44a8f

You may also need to update to latest linux-firmware.git as well if your distro has old firmware.

(In reply to Mario Limonciello from comment #35)
> @Tom:
> 
> The offending commit that caused this behavior is being reverted for 5.4:
> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth.git/
> commit/?id=1ffdb51f28e8ec6be0a2b812c1765b5cf5c44a8f
> 
> You may also need to update to latest linux-firmware.git as well if your
> distro has old firmware.

Is is actually disabling remote wakeup? Doesn't that disable RX to wakeup the host which pretty much breaks any traffic initiate from either the controller or the remote device? If that is the case we might as well remove support for auto-suspend since this would never gonna work if the controller cannot wakeup the host.

That's correct - if you can't safely decide within the btusb driver when to wakeup, the defaults shouldn't cause a machine to wakeup unnecessarily.

I think to revert that revert and enable some bluetooth initiated wakeups by default the LE stuff that shouldn't wake you up needs to get filtered.

I wonder if we could actually make the remote wakeup conditional to auto-suspend since that is what we want so in case the host suspend the device can still wakeup if auto-suspend has been enabled, so platforms which has a problem with that shall never mark BT controller to auto-suspend.

So the idea would be you don't auto-suspend the btusb device and then as a result the btusb device can't wake up?  I think the potential problem there is that the BT controller would stay powered over s2idle which should keep the USB active, and potentially prevent the SOC from reaching it's deepest state.

Not sure if I'm seeing the same bug, but my Lenovo X1 Gen7 wakes up immediately after entering S3 when a BT headphone is paired.

The Bluetooth adapter is the same: Intel 8087:0aaa
Kernel version: 5.17.7-300.fc36.x86_64

(In reply to Bernie Innocenti from comment #40)
> Not sure if I'm seeing the same bug, but my Lenovo X1 Gen7 wakes up
> immediately after entering S3 when a BT headphone is paired.

I found the same bug documented here:
https://wiki.archlinux.org/title/Lenovo_ThinkPad_X1_Carbon_(Gen_7)#S3_Suspend_Bug_with_Bluetooth_Devices