[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #14 from AceLan Kao (acelan@gmail.com) ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #15 from Chethan T N (chethan.tumkur.narayan@intel.com) ---
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

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #16 from Mario.Limonciello@dell.com ---
?
?Hello,

I am currently out of office

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #17 from Raghuram Hegde (raghuram.hegde@intel.com) ---
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

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #18 from AceLan Kao (acelan@gmail.com) ---
Created attachment 279021
  --> https://bugzilla.kernel.org/attachment.cgi?id=279021&action=edit
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"

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #19 from Raghuram Hegde (raghuram.hegde@intel.com) ---

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

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #20 from Raghuram Hegde (raghuram.hegde@intel.com) ---
(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

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #21 from Mario Limonciello (mario_limonciello@dell.com) ---


> 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?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #22 from AceLan Kao (acelan@gmail.com) ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #23 from Raghuram Hegde (raghuram.hegde@intel.com) ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #24 from AceLan Kao (acelan@gmail.com) ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #25 from Raghuram Hegde (raghuram.hegde@intel.com) ---
(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]

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #26 from AceLan Kao (acelan@gmail.com) ---
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

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #27 from Raghuram Hegde (raghuram.hegde@intel.com) ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #28 from Mario.Limonciello@dell.com ---
?
?Hello,

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

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

tao@linux.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tao@linux.com

--- Comment #29 from tao@linux.com ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #30 from Kai-Heng Feng (kai.heng.feng@canonical.com) ---
(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?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #31 from Mario.Limonciello@dell.com ---
?
?Hello,

I will be OOO, expect delayed response.

Thanks,

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #32 from Chethan T N (chethan.tumkur.narayan@intel.com) ---
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

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

Tom Hale (tom@hale.ee) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tom@hale.ee

--- Comment #34 from Tom Hale (tom@hale.ee) ---
--- 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

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #35 from Mario Limonciello (mario_limonciello@dell.com) ---
@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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #36 from Luiz Von Dentz (luiz.dentz@gmail.com) ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #38 from Luiz Von Dentz (luiz.dentz@gmail.com) ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #39 from Mario Limonciello (mario_limonciello@dell.com) ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

Bernie Innocenti (bernie@codewiz.org) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernie@codewiz.org

--- Comment #40 from Bernie Innocenti (bernie@codewiz.org) ---
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

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.

[Bug 200039] BT advertising packet wakes up the system from S3 and suspend-to-idle

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=200039

--- Comment #41 from Bernie Innocenti (bernie@codewiz.org) ---
(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

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.