Bug 199649 - After resume Bluetooth stopping after few seconds and high kworker proces / interrupt gpe6D
Summary: After resume Bluetooth stopping after few seconds and high kworker proces / i...
Status: RESOLVED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: Config-Interrupts (show other bugs)
Hardware: Intel Linux
: P1 normal
Assignee: Zhang Rui
URL: https://bugzilla.redhat.com/show_bug....
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-08 06:40 UTC by Bart R.
Modified: 2018-07-28 10:41 UTC (History)
2 users (show)

See Also:
Kernel Version: 4.16.5 & 4.16.6
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmidecode file (12.98 KB, text/plain)
2018-05-08 06:40 UTC, Bart R.
Details
acpidump.txt (1.32 MB, text/plain)
2018-06-10 20:09 UTC, Bart R.
Details
Add also a binary version (320.00 KB, application/x-tar)
2018-06-10 20:14 UTC, Bart R.
Details

Description Bart R. 2018-05-08 06:40:49 UTC
Created attachment 275823 [details]
dmidecode file

After updating to Fedora 28 and new kernel version 4.16.5-300 & 4.16.6-302, my Bluetooth stopping after a few seconds. It seems that is related to an interrupt storm on interrupt gpe6D. The strange thing is that before suspending/resuming interrupt gpe6D is disabled and after resuming the interupt is enabled. 

Within 1 minute more than 400k interrupts is handled bij the kernel and BLuetooth is slowly dying:
/sys/firmware/acpi/interrupts/gpe6D:  497754     STS enabled      unmasked

When I'm switching back to an old kernel 4.16.4-200, everything works as expected.
Comment 1 Bart R. 2018-05-09 19:55:36 UTC
Based on suggestion from Hans, see: https://bugzilla.redhat.com/show_bug.cgi?id=1575870#c1 I disable auto suspend on the Bluetooth device with a kernel parameter: btusb.enable_autosuspend=0.

With this option I can suspend and resume without losing the Bluetooth connection. Even the interrupt storm seems to be disappear. 

The strange thing is that when I initial start the machine without using the kernel parameter. Interrupt gpe6D is disabled by default. After suspending and resuming the system, interrupt gpe6D is enabled and caused the interrupt storm.

When I use the btusb.enable_autosuspend=0 kernel parameter and I suspend and resume the machine, then the interrupt is disabled after resuming.
Comment 2 Bart R. 2018-05-10 10:05:28 UTC
Things became more weird. After updating to kernel version kernel-core-4.16.7-300.fc28.x86_64 and remove the kernel parameter. I can suspending en resuming without any problem. But interrupt gpe6D is still enabled after resuming (disabled during initial start). Only a few thousand interrupts i noticed on gpe 6D. And the Bluetooth device is stille working

Then I boot the system with kernel kernel-core-4.16.6-302.fc28.x86_64 and removing the kernel parameter "btusb.enable_autosuspend=0". I saw the same result: gpe6D is enabled, only a few thousand interrupts and the Bluetooth device is still working. 

I'm struggling with a few questions:
- What is the causes the interrupt storm on interrupt gpe6D?
- Why is interrupt gpe6D enabled after suspending and resuming?

I try to go back to kernel version 4.16.5-300 (the initial version of fedora 28) to see if that version change the behavior of the ACPI of the machine.
Comment 3 Bart R. 2018-05-15 07:37:08 UTC
I've tested the 4.17-rc4 kernel, and the problem seems to bee resolved. Even the ACPI error that I received during the boot process are disappeared. 

When I suspend and resume the laptop, the gpe6d stays disabled and the mouse keeps working. 

/sys/firmware/acpi/interrupts/gpe6D:    1253         disabled     unmasked



I've also tested with all the 'old' 4.16 kernels and contrary to what I said last week Thursday the problem with an interrupt storm still exist, but happened at random. 

So the solution for my looks like the new 4.17-rc4 kernel. I will keep testing the next week.
Comment 4 Bart R. 2018-05-15 14:31:09 UTC
Sadly to say, but even with the new kernel the problem still exist. But again a different behavior. 

The new situation is that when I boot up the system (initial boot), than interrupt gpe6D is disabled during the whole time. 

After I suspend and resume the laptop, then the interrupt gpe6D switching continues between enabled / disabled. 

I wrote a small script to perform a date and grep . -r /sys/firmware/acpi/interrupts/. When I move the mouse, then the interrupt is disabled and when i stop moving, then the interrupt is enabled again after a few seconds. 

16:23:12   /sys/firmware/acpi/interrupts/gpe6D: 2797 EN enabled unmasked
16:23:18   /sys/firmware/acpi/interrupts/gpe6D: 2797 EN enabled unmasked
16:23:19   /sys/firmware/acpi/interrupts/gpe6D: 2797 EN enabled unmasked
16:23:20   /sys/firmware/acpi/interrupts/gpe6D: 2797 EN enabled unmasked
16:23:21   /sys/firmware/acpi/interrupts/gpe6D: 2876 disabled unmasked
16:23:22   /sys/firmware/acpi/interrupts/gpe6D: 2876 disabled unmasked
16:23:23   /sys/firmware/acpi/interrupts/gpe6D: 2876 disabled unmasked
16:23:24   /sys/firmware/acpi/interrupts/gpe6D: 2876 disabled unmasked
16:23:25   /sys/firmware/acpi/interrupts/gpe6D: 2876 disabled unmasked
16:23:26   /sys/firmware/acpi/interrupts/gpe6D: 2876 disabled unmasked
16:23:27   /sys/firmware/acpi/interrupts/gpe6D: 2876 disabled unmasked
16:23:28   /sys/firmware/acpi/interrupts/gpe6D: 2876 EN enabled unmasked
16:23:30   /sys/firmware/acpi/interrupts/gpe6D: 2876 EN enabled unmasked
16:23:31   /sys/firmware/acpi/interrupts/gpe6D: 2876 EN enabled unmasked
16:23:32   /sys/firmware/acpi/interrupts/gpe6D: 2876 EN enabled unmasked
16:23:33   /sys/firmware/acpi/interrupts/gpe6D: 2936 disabled unmasked
16:23:34   /sys/firmware/acpi/interrupts/gpe6D: 2936 disabled unmasked
16:23:35   /sys/firmware/acpi/interrupts/gpe6D: 2936 disabled unmasked
16:23:36   /sys/firmware/acpi/interrupts/gpe6D: 2936 disabled unmasked
16:23:37   /sys/firmware/acpi/interrupts/gpe6D: 2936 disabled unmasked
16:23:38   /sys/firmware/acpi/interrupts/gpe6D: 2936 disabled unmasked
16:23:39   /sys/firmware/acpi/interrupts/gpe6D: 2936 EN enabled unmasked
16:23:40   /sys/firmware/acpi/interrupts/gpe6D: 2936 EN enabled unmasked

Sometimes, directly after resuming this phenomenon caused an interrupt storm on interrupt gpe6D. The reason, I don't know yet. But when such a storm occurred, then I lose my blue tooth connection.
Comment 5 Zhang Rui 2018-05-30 04:56:25 UTC
please attach full acpidump output
Comment 6 Bart R. 2018-06-10 20:09:49 UTC
Created attachment 276453 [details]
acpidump.txt
Comment 7 Bart R. 2018-06-10 20:10:48 UTC
I attached an acpidump file
Comment 8 Bart R. 2018-06-10 20:14:58 UTC
Created attachment 276455 [details]
Add also a binary version
Comment 9 Zhang Rui 2018-06-25 08:53:27 UTC
            Method (_SB.PCI0.GLAN._PRW, 0, NotSerialized)
            {   
                Return (GPRW (0x6D, 0x04))
            }

            Method (_SB.PCI0.XHC._PRW, 0, NotSerialized)
            {   
                Return (GPRW (0x6D, 0x04))
            }


            Method (_SB.PCI0.XDCI._PRW, 0, NotSerialized)
            {   
                Return (GPRW (0x6D, 0x04))
            }

            Method (_SB.PCI0.HDAS._PRW, 0, NotSerialized)
            {   
                Return (GPRW (0x6D, 0x04))
            }

There are a couple of devices share this GPE as wakeup GPE, and each of them may enable this GPE when it goes into runtime suspend, with wakeup capability enabled.

I'm not sure what device your mouse is connecting with, but maybe one of these above.
And my guess is that, moving/stopping the mouse may put some device into/output runtime suspend, and thus enables/disables the wakeup GPE. And the problem should gone if you disable the runtime PM for all the devices, right?
if yes, please toggle the runtime PM switch for each individual device and see which one brings the problem.
Comment 10 Zhang Rui 2018-06-25 08:54:22 UTC
if needed, I can give you a debug patch to dump out which driver enables/disables the GPE, but this needs you to build your custom kernel.
Comment 11 Bart R. 2018-07-28 10:41:29 UTC
After installing the 4.17.7-200.fc28.x86_64 kernel I saw that the problems are disappears. After resuming the laptop, the mouse still working and the interrupts are disabled. There is no more interrupt storm anymore. 

This issue can be closed.

Note You need to log in before you can comment on or make changes to this bug.