Hi all,
We found an issue that when system enters S3, it stays in S3 for a few
seconds, and somehow it resumes automatically.
And we try below quirk which can prevent it from waking up.
drivers/usb/core/quirks.c
@@ -208,11 +208,11 @@ static const struct usb_device_id usb_quirk_list[] = {
USB_QUIRK_DISCONNECT_SUSPEND },
{ USB_DEVICE(0x12d1, 0x15c3), .driver_info =
USB_QUIRK_DISCONNECT_SUSPEND },
+ { USB_DEVICE(0x8087, 0x0025), .driver_info =
+ USB_QUIRK_DISCONNECT_SUSPEND },
Here are some findings from the system.
$ lsusb
Bus 001 Device 004: ID 8087:0025 Intel Corp.
$ lspci -nn
00:14.0 USB controller [0c03]: Intel Corporation Device [8086:a36d] (rev 01)
Jan 4 04:20:37 u-OptiPlex-7060 kernel:
[ 0.144060] v2 Added device:4b [\_SB_.PCI0.XHC_] parent PNP0A08:00 sta=0xf
[ 0.171066] pci 0000:00:14.0: [8086:a36d] type 00 class 0x0c0330
[ 0.171099] pci 0000:00:14.0: reg 0x10: [mem 0x71420000-0x7142ffff 64bit]
[ 0.171200] pci 0000:00:14.0: PME# supported from D3hot D3cold
[ 3.680297] xhci_hcd 0000:00:14.0: xHCI Host Controller
[ 3.680301] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 1
[ 3.681509] xhci_hcd 0000:00:14.0: hcc params 0x20007fc1 hci version
0x110 quirks 0x00009810
[ 3.681515] xhci_hcd 0000:00:14.0: cache line size of 64 is not supported
[ 3.681621] usb usb1: SerialNumber: 0000:00:14.0
[ 3.681989] xhci_hcd 0000:00:14.0: xHCI Host Controller
[ 3.681992] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2
[ 3.681993] xhci_hcd 0000:00:14.0: Host supports USB 3.1 Enhanced SuperSpeed
[ 3.682026] usb usb2: SerialNumber: 0000:00:14.0
===> Suspend
[31.783177] PM: Syncing filesystems ... done.
[31.784733] PM: Preparing system for sleep (mem)
[31.785444] Freezing user space processes ... (elapsed 0.001 seconds) done.
[31.786486] OOM killer disabled.
[31.786487] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[31.787597] PM: Suspending system (mem)
[31.787631] Suspending console(s) (use no_console_suspend to debug)
===> Device resumes automatically
[32.911466] wakeup_source_report_event: name:device:4b, event_count:1
[32.911467] wakeup_source_activate: name:device:4b, active_count:1
[32.911471] wakeup_source_report_event: name:0000:00:14.0, event_count:1
[32.911471] wakeup_source_activate: name:0000:00:14.0, active_count:1
[33.231056] PM: Finishing wakeup.
Any ideas? Or anything we can try?
Thanks.
Best regards,
AceLan Kao.
I use btmon to capture the bt packets when system encountered auto wake up.
Please help me to interpreter the log, I can't find anything
meaningful from those packets.
BTW, this issue is sometimes hard to reproduce, but when it happens, I
can reproduce it couple times in a row.
2018-01-18 10:37 GMT+08:00 AceLan Kao <[email protected]>:
> More findings.
> It's required to connect to some bt devices before entering S3 to
> trigger the auto wake.
>
> Below are the devices we tried, pair with headset or sending files to
> other pc, and then enter S3,
> it'll sometimes wake up automatically.
>
> Headset: Sony Ericsson MH100 Bluetooth Stereo Headset
> Bluetooth Keyboard: BLUETOOTH MULTI-DEVICE KEYBOARD K480
>
> 2018-01-08 9:24 GMT+08:00 AceLan Kao <[email protected]>:
>> Hi Marcel,
>>
>> The issue is the system automatically wakes up from S3.
>> We tried to figure out the issue and found that BT is suspicious
>> that's how the workaround comes from.
>> Also, we found that if we connect the BT antenna, the system will be
>> waken up more quickly.
>>
>> I know the quirk will disable the ability to wake up the system from
>> remote, but I have no idea how to debug it further.
>> Is there any way I could try to check if we really got a wake up
>> packet or we keep receiving random packets and trigger the wake up
>> process?
>> Thanks.
>>
>> Best regards,
>> AceLan Kao.
>>
>> 2018-01-05 22:59 GMT+08:00 Marcel Holtmann <[email protected]>:
>>> Hi AceLan,
>>>
>>>> We found an issue that when system enters S3, it stays in S3 for a few
>>>> seconds, and somehow it resumes automatically.
>>>> And we try below quirk which can prevent it from waking up.
>>>>
>>>> drivers/usb/core/quirks.c
>>>> @@ -208,11 +208,11 @@ static const struct usb_device_id usb_quirk_list[] = {
>>>> USB_QUIRK_DISCONNECT_SUSPEND },
>>>> { USB_DEVICE(0x12d1, 0x15c3), .driver_info =
>>>> USB_QUIRK_DISCONNECT_SUSPEND },
>>>> + { USB_DEVICE(0x8087, 0x0025), .driver_info =
>>>> + USB_QUIRK_DISCONNECT_SUSPEND },
>>>>
>>>> Here are some findings from the system.
>>>>
>>>> $ lsusb
>>>> Bus 001 Device 004: ID 8087:0025 Intel Corp.
>>>
>>> can we be a bit more specific here on what is going on and triage this a bit more. I have not heard of our hardware needing such a broad quirk. Also disconnecting on suspend means that we loose the support for remote wakeup and I am pretty sure that we do not want that.
>>>
>>> Regards
>>>
>>> Marcel
>>>
More findings.
It's required to connect to some bt devices before entering S3 to
trigger the auto wake.
Below are the devices we tried, pair with headset or sending files to
other pc, and then enter S3,
it'll sometimes wake up automatically.
Headset: Sony Ericsson MH100 Bluetooth Stereo Headset
Bluetooth Keyboard: BLUETOOTH MULTI-DEVICE KEYBOARD K480
2018-01-08 9:24 GMT+08:00 AceLan Kao <[email protected]>:
> Hi Marcel,
>
> The issue is the system automatically wakes up from S3.
> We tried to figure out the issue and found that BT is suspicious
> that's how the workaround comes from.
> Also, we found that if we connect the BT antenna, the system will be
> waken up more quickly.
>
> I know the quirk will disable the ability to wake up the system from
> remote, but I have no idea how to debug it further.
> Is there any way I could try to check if we really got a wake up
> packet or we keep receiving random packets and trigger the wake up
> process?
> Thanks.
>
> Best regards,
> AceLan Kao.
>
> 2018-01-05 22:59 GMT+08:00 Marcel Holtmann <[email protected]>:
>> Hi AceLan,
>>
>>> We found an issue that when system enters S3, it stays in S3 for a few
>>> seconds, and somehow it resumes automatically.
>>> And we try below quirk which can prevent it from waking up.
>>>
>>> drivers/usb/core/quirks.c
>>> @@ -208,11 +208,11 @@ static const struct usb_device_id usb_quirk_list[=
] =3D {
>>> USB_QUIRK_DISCONNECT_SUSPEND },
>>> { USB_DEVICE(0x12d1, 0x15c3), .driver_info =3D
>>> USB_QUIRK_DISCONNECT_SUSPEND },
>>> + { USB_DEVICE(0x8087, 0x0025), .driver_info =3D
>>> + USB_QUIRK_DISCONNECT_SUSPEND },
>>>
>>> Here are some findings from the system.
>>>
>>> $ lsusb
>>> Bus 001 Device 004: ID 8087:0025 Intel Corp.
>>
>> can we be a bit more specific here on what is going on and triage this a=
bit more. I have not heard of our hardware needing such a broad quirk. Als=
o disconnecting on suspend means that we loose the support for remote wakeu=
p and I am pretty sure that we do not want that.
>>
>> Regards
>>
>> Marcel
>>
Hi Marcel,
The issue is the system automatically wakes up from S3.
We tried to figure out the issue and found that BT is suspicious
that's how the workaround comes from.
Also, we found that if we connect the BT antenna, the system will be
waken up more quickly.
I know the quirk will disable the ability to wake up the system from
remote, but I have no idea how to debug it further.
Is there any way I could try to check if we really got a wake up
packet or we keep receiving random packets and trigger the wake up
process?
Thanks.
Best regards,
AceLan Kao.
2018-01-05 22:59 GMT+08:00 Marcel Holtmann <[email protected]>:
> Hi AceLan,
>
>> We found an issue that when system enters S3, it stays in S3 for a few
>> seconds, and somehow it resumes automatically.
>> And we try below quirk which can prevent it from waking up.
>>
>> drivers/usb/core/quirks.c
>> @@ -208,11 +208,11 @@ static const struct usb_device_id usb_quirk_list[]=
=3D {
>> USB_QUIRK_DISCONNECT_SUSPEND },
>> { USB_DEVICE(0x12d1, 0x15c3), .driver_info =3D
>> USB_QUIRK_DISCONNECT_SUSPEND },
>> + { USB_DEVICE(0x8087, 0x0025), .driver_info =3D
>> + USB_QUIRK_DISCONNECT_SUSPEND },
>>
>> Here are some findings from the system.
>>
>> $ lsusb
>> Bus 001 Device 004: ID 8087:0025 Intel Corp.
>
> can we be a bit more specific here on what is going on and triage this a =
bit more. I have not heard of our hardware needing such a broad quirk. Also=
disconnecting on suspend means that we loose the support for remote wakeup=
and I am pretty sure that we do not want that.
>
> Regards
>
> Marcel
>
Hi AceLan,
> We found an issue that when system enters S3, it stays in S3 for a few
> seconds, and somehow it resumes automatically.
> And we try below quirk which can prevent it from waking up.
>
> drivers/usb/core/quirks.c
> @@ -208,11 +208,11 @@ static const struct usb_device_id usb_quirk_list[] = {
> USB_QUIRK_DISCONNECT_SUSPEND },
> { USB_DEVICE(0x12d1, 0x15c3), .driver_info =
> USB_QUIRK_DISCONNECT_SUSPEND },
> + { USB_DEVICE(0x8087, 0x0025), .driver_info =
> + USB_QUIRK_DISCONNECT_SUSPEND },
>
> Here are some findings from the system.
>
> $ lsusb
> Bus 001 Device 004: ID 8087:0025 Intel Corp.
can we be a bit more specific here on what is going on and triage this a bit more. I have not heard of our hardware needing such a broad quirk. Also disconnecting on suspend means that we loose the support for remote wakeup and I am pretty sure that we do not want that.
Regards
Marcel