Bug 53071 - Problems with gpe13 interrupt storm on HP Compaq 6710b and Samsung 700Z5C.
Summary: Problems with gpe13 interrupt storm on HP Compaq 6710b and Samsung 700Z5C.
Status: CLOSED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: BIOS (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Aaron Lu
URL:
Keywords:
: 85881 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-01-26 13:38 UTC by James.Dutton
Modified: 2016-07-01 10:24 UTC (History)
20 users (show)

See Also:
Kernel Version: 3.7.4
Subsystem:
Regression: No
Bisected commit-id:


Attachments
acpidump -b (48.61 KB, application/octet-stream)
2013-01-26 13:38 UTC, James.Dutton
Details
acpidump > acpi.out (225.66 KB, text/plain)
2013-02-20 09:42 UTC, James.Dutton
Details
Fujitsu Lifebook ah544 dmi.log Manufacturer: FUJITSU Product Name: LIFEBOOK AH544 (12.20 KB, text/x-log)
2014-10-23 11:06 UTC, SPROg
Details
acpidump for Lv Zheng (406.81 KB, application/octet-stream)
2014-10-23 11:08 UTC, SPROg
Details
Patch for Fujitsu Lifebook AH544. [DBG PATCH 6/5] (672 bytes, application/octet-stream)
2014-10-23 12:12 UTC, SPROg
Details
Samsung-700Z5C acpidmp -b (20.87 KB, application/octet-stream)
2014-10-24 06:30 UTC, James.Dutton
Details
Samsung 700Z5C dmidecode --dump-bin (2.87 KB, application/octet-stream)
2014-10-24 06:31 UTC, James.Dutton
Details
[PATCH] ACPI: Add GPE quirks for SATA PIN4 detection. (1.98 KB, patch)
2014-10-28 03:10 UTC, Lv Zheng
Details | Diff
Fujitsu A544 dmidecode (11.99 KB, text/plain)
2015-03-04 13:07 UTC, Colin Law
Details
Fujitsu A544 acpidump (378.25 KB, text/plain)
2015-03-04 13:08 UTC, Colin Law
Details

Description James.Dutton 2013-01-26 13:38:49 UTC
Created attachment 91841 [details]
acpidump -b

Some more detailed context can be found here:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/887793

    Scope (_GPE)
    {
        Method (_L13, 0, NotSerialized)
        {
            If (LEqual (PFLV, FDTP))
            {
                Return (Zero)
            }

            Store (Zero, GPE3)
            Or (GL08, 0x10, GL08)
            Notify (\_SB.PCI0.SAT0, 0x82)
            Return (Zero)
        }
    }

This is the DSDT code for GPE13 on a Samsung Series 7 700Z5C laptop.
There error reported by the Linux kernel is:
 ev_queue_notify_reques: No notify handler for Notify, ignoring (SAT0, 82)

Now, my question is:
How do I find out what device is causing the GPE13 interrupt and why?
How do I work out what code (which device register bit to reset) I have to put in this Notify handler in order to silence the interrupt storm?
Comment 1 Aaron Lu 2013-02-20 09:32:43 UTC
(In reply to comment #0)
> Created an attachment (id=91841) [details]
> acpidump -b

Can you please attach the table as hex dump?
acpidump > acpi.out

> 
> Some more detailed context can be found here:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/887793
> 
>     Scope (_GPE)
>     {
>         Method (_L13, 0, NotSerialized)
>         {
>             If (LEqual (PFLV, FDTP))
>             {
>                 Return (Zero)
>             }
> 
>             Store (Zero, GPE3)
>             Or (GL08, 0x10, GL08)
>             Notify (\_SB.PCI0.SAT0, 0x82)

The SAT0 is very likely to be the sata controller.

>             Return (Zero)
>         }
>     }
> 
> This is the DSDT code for GPE13 on a Samsung Series 7 700Z5C laptop.
> There error reported by the Linux kernel is:
>  ev_queue_notify_reques: No notify handler for Notify, ignoring (SAT0, 82)
> 
> Now, my question is:
> How do I find out what device is causing the GPE13 interrupt and why?

You can try to see the disassembled asl code, to find which device has the _PRW package that claims the 0x13 GPE bit.

> How do I work out what code (which device register bit to reset) I have to
> put
> in this Notify handler in order to silence the interrupt storm?
Comment 2 James.Dutton 2013-02-20 09:42:54 UTC
Created attachment 93741 [details]
acpidump > acpi.out

acpidump > acpi.out

as requested
Comment 3 devsk 2013-03-18 13:45:54 UTC
Any updates on this bug? This is a major PITA to work around and we don't what we are disabling by disbaling gpe13.
Comment 4 Aaron Lu 2013-03-19 05:57:27 UTC
(In reply to comment #3)
> Any updates on this bug? This is a major PITA to work around and we don't
> what
> we are disabling by disbaling gpe13.

No I'm afraid.

I don't know what is causing GPE 13 being set, and notification value 0x82 is not defined anywhere in ACPI spec for SATA controller.

Even we write a notification handler for SATA controller(SAT0), that wouldn't stop the GPE gets set, unless we know what is causing it. I don't know where to find such information, sorry.
Comment 5 Richard Moore 2013-04-12 21:40:00 UTC
Just a confirmation that I'm experiencing this too, see https://bugzilla.novell.com/show_bug.cgi?id=812603 for details of the laptop model etc. if there's anything else I can provide that might help, let me know.
Comment 6 Aaron Lu 2013-07-09 06:13:02 UTC
Does this problem occur right after boot without doing anything or after doing something?
Comment 7 Aaron Lu 2013-08-12 09:11:05 UTC
ping
Comment 8 James.Dutton 2013-08-12 12:17:51 UTC
The problem occurs right after boot, without doing anything, except log in.
Does anyone have any technical contacts within Samsung that we could talk to in order to find out what GPE 13 value 0x82 is?
Comment 9 sirus20x6 2014-03-04 23:17:37 UTC
have this problem on samsung chronos 7 17.3" 700Z7c-s01us
I'm on arch linux, 64 bit, linux-ck kernel. disabling gpe13 brought my total idle cpu usage from 11% down to 2%
Comment 10 sirus20x6 2014-03-04 23:19:42 UTC
it appears to be this bug https://patchwork.kernel.org/patch/2400621/
Comment 11 Zhang Rui 2014-06-03 03:13:14 UTC
To make sure it is the same problem stated in https://patchwork.kernel.org/patch/2400621/, will you guys please try boot with "drm_kms_helper.poll=0" and see if the problem still exists.
Comment 12 James.Dutton 2014-06-06 22:51:38 UTC
I have tested this, and  https://patchwork.kernel.org/patch/2400621/ and "drm_kms_helper.poll=0" makes no difference.
These two bugs are NOT RELATED.
Comment 13 devsk 2014-06-07 00:18:20 UTC
Why would you close the bug with CODE_FIX? Is this bug fixed? Can I have the patch for 3.14.5 pls?
Comment 14 James.Dutton 2014-06-07 01:26:05 UTC
No fix yet. Still waiting for a proper solution to the problem.
Comment 15 Lv Zheng 2014-07-08 06:21:05 UTC
Hi,

Pinging...

Please check if this is a duplicate bug with the following one:
https://bugzilla.kernel.org/show_bug.cgi?id=63021

Thanks
Comment 16 James.Dutton 2014-07-11 21:13:43 UTC
I can confirm that 
https://bugzilla.kernel.org/show_bug.cgi?id=63021
is not a duplicate of this bug.
That one talks about USB and gpe0D.
This problem is with gpe13.

I have checked, and changing the BIOS "USB S3 Wakeup" etc. makes no difference to my problem.
Comment 17 James.Dutton 2014-07-11 21:21:23 UTC
Still present in kernel 3.15.1
Comment 18 hongce zhang 2014-09-15 09:02:23 UTC
This interesting problem occurred after I add one SSD to replace my CD drive on Asus A53S. kernel:3.2.0-67-generic #101-Ubuntu SMP
Comment 19 hongce zhang 2014-10-02 09:29:25 UTC
I figured out my problem, but I don't know whether it is useful to solve yours. I just mentioned above I replace CD drive with a SSD holder. My problem lies on the port that connects the new SSD holder to my laptop. The definition of Pin 4 of power supply of the CD drive is different according to the manufacutures. Some are connected to GND, some are not. Pin4 seems to be used by BIOS to check whether the CD drive is installed correctly ( I guess it is so), if the new SSD holder does not have the same electric characteristics of Pin 4 as original one, GPE 13 will be triggered. So my solution is just to change for a compatible SSD holder. My laptop is Asus A53S. Hope to be helpful to your problem.
Comment 20 Lv Zheng 2014-10-08 05:49:51 UTC
(In reply to hongce zhang from comment #19)
> I figured out my problem, but I don't know whether it is useful to solve
> yours. I just mentioned above I replace CD drive with a SSD holder. My
> problem lies on the port that connects the new SSD holder to my laptop. The
> definition of Pin 4 of power supply of the CD drive is different according
> to the manufacutures. Some are connected to GND, some are not. Pin4 seems to
> be used by BIOS to check whether the CD drive is installed correctly ( I
> guess it is so), if the new SSD holder does not have the same electric
> characteristics of Pin 4 as original one, GPE 13 will be triggered. So my
> solution is just to change for a compatible SSD holder. My laptop is Asus
> A53S. Hope to be helpful to your problem.

Thanks for the investigation.
According to what you said, this is simply not a bug, but a manufacture compatibility issue.
If it doesn't trigger GPE 13 storming, it seems we could simply ignore it.
Comment 21 Lv Zheng 2014-10-17 02:43:35 UTC
Hi,

In ACPICA, if the GPE doesn't have _Lxx/_Exx and no one is registering handler for it. The GPE will automatically be disabled to prevent storming.
But for the cases listed on
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/887793

It seems there should be cases where the _Lxx/_Exx is prepared in the ACPI namespace but OSPM still cannot handle it due to lacking in the information.

So users may need to disable the GPE in order for the system to be working.

Currently we don't have such quirk mechanism because our acpi_disable_gpe() API is relying on a reference counting mechanism.
But we are adding the API to achieve this.
Please take a look at this:
http://bugs.acpica.org/show_bug.cgi?id=1102

The patchset is under an internal discussion.
So it may still need some time until it is upstreamed.

Please upload the dmidecode/acpidump outputs and the affecting GPE# here, so that when the mechanism is ready, we can add quirks for them.

Thanks
Comment 22 Lv Zheng 2014-10-23 02:48:06 UTC
pinging...
Could someone provide dmidecode for such platforms?
And try the GPE disabling quirks posted here:
https://bugzilla.kernel.org/show_bug.cgi?id=85881
Comment 23 SPROg 2014-10-23 11:06:31 UTC
Created attachment 154611 [details]
Fujitsu Lifebook ah544 dmi.log

Manufacturer: FUJITSU
Product Name: LIFEBOOK AH544

dmi for Lv Zheng

Fujitsu Lifebook ah544 have save problem with Gpe13.
And moostly the same ACPI method

Method (_L13, 0, NotSerialized)  // _Lxx: Level-Triggered GPE
        {
            Store (Zero, GPE3)
            Store (One, GPS3)
            Or (GL08, 0x10, GL08)
            Notify (\_SB.PCI0.SAT0, 0x82)
            Return (Zero)
        }
Comment 24 SPROg 2014-10-23 11:08:47 UTC
Created attachment 154621 [details]
acpidump for Lv Zheng
Comment 25 SPROg 2014-10-23 12:12:01 UTC
Created attachment 154631 [details]
Patch for Fujitsu Lifebook AH544. [DBG PATCH 6/5]
Comment 26 SPROg 2014-10-23 12:27:45 UTC
My current core 3.14.14-gentoo

Patching errors:
2)
drivers/acpi/scan.c
Searched code:
wakeup->flags.run_wake = !!(event_status & ACPI_EVENT_FLAG_HANDLE);

Existing code:
If (status == AE_OK)
devive->wakeup.flags.run_wake = !!(event_status & ACPI_EVENT_FLAG_HANDLE);

3)

drivers/acpi/acpica/evxfgpe.c
include/acpi/acpixf.h

No acpi_mark_gpe_for_wake. In 3.14.14 acpi_setup_gpe_for_wake

///////////////////////////////////////////////////////////
Compiling error
Also ACPI_EVENT_FLAG_HANDLE is undefined symbol in drivers/acpi/scan.c
Comment 27 SPROg 2014-10-23 18:40:40 UTC
(In reply to Lv Zheng from comment #21)
> Hi,
> 
> In ACPICA, if the GPE doesn't have _Lxx/_Exx and no one is registering
> handler for it. The GPE will automatically be disabled to prevent storming.
> But for the cases listed on
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/887793

Thanks, work well!=)
Comment 28 Lv Zheng 2014-10-24 01:43:18 UTC
(In reply to SPROg from comment #24)
> Created attachment 154621 [details]
> acpidump for Lv Zheng

Thanks for the patch. :-)
Comment 29 Lv Zheng 2014-10-24 01:45:37 UTC
(In reply to SPROg from comment #26)
> My current core 3.14.14-gentoo
> 
> Patching errors:
> 2)
> drivers/acpi/scan.c
> Searched code:
> wakeup->flags.run_wake = !!(event_status & ACPI_EVENT_FLAG_HANDLE);
> 
> Existing code:
> If (status == AE_OK)
> devive->wakeup.flags.run_wake = !!(event_status & ACPI_EVENT_FLAG_HANDLE);
> 
> 3)
> 
> drivers/acpi/acpica/evxfgpe.c
> include/acpi/acpixf.h
> 
> No acpi_mark_gpe_for_wake. In 3.14.14 acpi_setup_gpe_for_wake
> 
> ///////////////////////////////////////////////////////////
> Compiling error
> Also ACPI_EVENT_FLAG_HANDLE is undefined symbol in drivers/acpi/scan.c

Yes, the patch is generated on top of current linus/master branch (3.18-rc1).
Comment 30 Lv Zheng 2014-10-24 01:48:00 UTC
(In reply to SPROg from comment #27)
> (In reply to Lv Zheng from comment #21)
> > Hi,
> > 
> > In ACPICA, if the GPE doesn't have _Lxx/_Exx and no one is registering
> > handler for it. The GPE will automatically be disabled to prevent storming.
> > But for the cases listed on
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/887793
> 
> Thanks, work well!=)

OK. Thanks for the great job.

I'll add your patch into the same series of the GPE disabling and I'll send them upstream together after the internal discussion fixed.

If anyone still have other models suffering from the same issue.
Please post the dmidecode here.

Thanks and best regards
Comment 31 James.Dutton 2014-10-24 06:30:39 UTC
Created attachment 154741 [details]
Samsung-700Z5C acpidmp -b

acpidump for Samsung 700Z5C
Comment 32 James.Dutton 2014-10-24 06:31:45 UTC
Created attachment 154751 [details]
Samsung 700Z5C dmidecode --dump-bin

dmidecode --dump-bin  for Samsung 700Z5C
Comment 33 Lv Zheng 2014-10-28 03:10:40 UTC
Created attachment 155561 [details]
[PATCH] ACPI: Add GPE quirks for SATA PIN4 detection.

Hi, James

The patch is ready for you. Please check.

Thanks
Comment 34 Len Brown 2014-10-28 05:22:04 UTC
This patch is not currently upstream.
Comment 35 Lv Zheng 2014-10-28 06:20:39 UTC
(In reply to Len Brown from comment #34)
> This patch is not currently upstream.

Hi, Len

The quirk patches depend on one ACPICA patch implementing a new GPE feature.
https://bugzilla.kernel.org/show_bug.cgi?id=85881
attachment 154511 [details]
It splits GPE APIs into 3 layers:
1. top most layer: management purposes - used for quirks, debugging
2. middle layer: driver usages - used by drivers to indicate requests
3. lowest layer: driver usages - used by drivers to switch between polling/interrupt mode when at least one request has been submitted.

Currently I haven't reached an agreement with Rafael and Bob on it.
But sooner or later we'll have a proper version of it for upstream.

Thanks
Comment 36 Lv Zheng 2014-11-12 06:35:00 UTC
*** Bug 85881 has been marked as a duplicate of this bug. ***
Comment 37 Lv Zheng 2015-02-11 02:16:05 UTC
According to 85881.
This is a firmware issue and can be solved by firmware upgrade.
Let me mark it as "BIOS" issue and close it.
Comment 38 Colin Law 2015-03-03 14:46:05 UTC
(In reply to Lv Zheng from comment #37)
> According to 85881.
> This is a firmware issue and can be solved by firmware upgrade.
> Let me mark it as "BIOS" issue and close it.

I am seeing this problem (on gpe13) on a Fujitsu A544 (not AH544 mentioned above) with the latest BIOS (v1.18) running kernel 4.0-rc1-vivid on Ubuntu. Should the patches above be included in that kernel, and if so what should I do to facilitate the equivalent patches for the a544 please?
Comment 39 Lv Zheng 2015-03-04 00:03:03 UTC
(In reply to Colin Law from comment #38)
> (In reply to Lv Zheng from comment #37)
> > According to 85881.
> > This is a firmware issue and can be solved by firmware upgrade.
> > Let me mark it as "BIOS" issue and close it.
> 
> I am seeing this problem (on gpe13) on a Fujitsu A544 (not AH544 mentioned
> above) with the latest BIOS (v1.18) running kernel 4.0-rc1-vivid on Ubuntu.
> Should the patches above be included in that kernel, and if so what should I
> do to facilitate the equivalent patches for the a544 please?

The GPE storming causes are various.
Here we can only provide quirks to force disabling the storming GPE when it is not root caused.
And this should be done platform by platform .
So you need to upload the dmidecode output here so that we can generate the quirk for you.
Comment 40 Colin Law 2015-03-04 13:07:52 UTC
Created attachment 168981 [details]
Fujitsu A544 dmidecode
Comment 41 Colin Law 2015-03-04 13:08:49 UTC
Created attachment 168991 [details]
Fujitsu A544 acpidump
Comment 42 Colin Law 2015-03-04 13:09:28 UTC
Hi Lv Zheng, hopefully this is what is required.  Results from dmidecode and acpidump attached.
Comment 43 James.Dutton 2015-03-04 19:45:07 UTC
As the original person who opened this bug.
I have posted the dmidecode and acpidump, but the kernel 3.18 does not contain a fix/quirk for the gpe13 storm on my Samsung 700Z5C.

I will test a newer kernel when a fix is available for the Samsung 700Z5C.
Comment 44 Richard Moore 2015-03-22 22:13:29 UTC
This appears to be solved when using the kernel in opensuse 13.2:

rich@monster:~/src/qt-bugs/cookies> cat /proc/version 
Linux version 3.16.7-7-desktop (geeko@buildhost) (gcc version 4.8.3 20140627 [gcc-4_8-branch revision 212064] (SUSE Linux) ) #1 SMP PREEMPT Wed Dec 17 18:00:44 UTC 2014 (762f27a)

Thanks!
Comment 45 Zhang Rui 2015-06-26 01:00:58 UTC
it seems that we have a couple of people suffering from a similar problem.
For people who commented on this bug, please paste your laptop model, or else it will be confusing because this problem is platform specific, and some of you may meet different problems.
Comment 46 Colin Law 2015-06-26 08:38:02 UTC
Fujitsu A544 as already reported in comment #38.
Note this is not an AH544.
Comment 47 SPROg 2015-06-27 14:40:19 UTC
Fujitsu AH544. Reported in comment #23
Kernel 4.0.6 still suffering from this problem
Comment 48 Aaron Lu 2015-08-24 06:45:12 UTC
Do you all suffer the GPE 13 storm or other GPE number?
And did you also replace the original ODD with a SATA drive?
Comment 49 SPROg 2015-08-24 06:51:26 UTC
(In reply to Aaron Lu from comment #48)
> Do you all suffer the GPE 13 storm or other GPE number?
> And did you also replace the original ODD with a SATA drive?

Yeap. I replaced HDD with SSD, HDD moved in place of ODD.
Comment 50 Aaron Lu 2015-08-24 07:40:47 UTC
I don't think we should add quick for those systems that have an SSD/HDD inserted into a slot that is meant for ODD, if we disable the GPE, people with the normal ODD in that slot may lose functionality, unless we can be sure that no problems and/or functionality lost for those people.

I prefer not to complicate the kernel with quicks for this use case, instead, please just disable GPE 13 if you replaced the ODD with an SSD/HDD.
Comment 51 SPROg 2015-08-24 07:50:06 UTC
(In reply to Aaron Lu from comment #50)
> I prefer not to complicate the kernel with quicks for this use case,
> instead, please just disable GPE 13 if you replaced the ODD with an SSD/HDD.

I need a time (may be at holidays) to test my laptop with clean kernel and ODD.

May be it will be wise to allow disabling gpe from kernel options for this cases? Not too long ago, kernel reenabled gpe after resuming from sleep/hibernation and after boot. I forced to use scripts for disabling gpe13. Kernel patch for me was a salvation.
Comment 52 Colin Law 2015-08-24 20:28:21 UTC
I can confirm on the Fujitsu Lifebook A544 that it is GPE13, it came with an SSD fitted.  I have another A544 with a conventional hard drive and it does not exhibit the problem.
Comment 53 Aaron Lu 2015-08-25 02:27:55 UTC
(In reply to Colin Law from comment #52)
> I can confirm on the Fujitsu Lifebook A544 that it is GPE13, it came with an
> SSD fitted.  I have another A544 with a conventional hard drive and it does
> not exhibit the problem.

So for the problematic laptop A544 that has a SSD there, is it preinstalled by the vendor or installed later by you? And is there a manual describing what device is supposed to be installed there?
Comment 54 Lv Zheng 2015-08-25 03:04:36 UTC
In my opinion, if users want to disable particular GPEs to eliminate laptop hardware compliance issues, the quirk shouldn't be upstreamed to the Linux kernel this is not even a bug of BIOS, it is a problem of the use case. It should be done by the user from the user space.
But we may need some software mechanisms to disable the GPEs or fixed events when storm happens.

Currently ACPICA is able to disable no handler/method, none wakeup GPEs in the GPE core, but for this case, _L13 is prepared by BIOS in the namespace, ACPICA has no idea if it should be disabled as ACPICA doesn't know if the GPE13 has been correctly handled by the _L13. Unfortunately, _L13 cannot handle non ODD devices here.

In this situation, attachment 154511 [details] is one of the approach that can be used by the users to disable those GPEs that ACPICA core has no idea to disable. So that users can prepare such kind of safe quirk from the userspace.

Thanks and best regards
-Lv
Comment 55 Colin Law 2015-08-25 08:28:52 UTC
(In reply to Aaron Lu from comment #53)
> So for the problematic laptop A544 that has a SSD there, is it preinstalled
> by
> the vendor or installed later by you? And is there a manual describing what
> device is supposed to be installed there?

On the A544 the SSD was preinstalled by the vendor.  A 128GB SSD is available as a standard option on the A544 (or at least was so a year ago).
The problem first appeared when I upgraded the BIOS (to 1.18) to fix a separate issue, but I see now there is another update available so I will check whether that has fixed it and report back.
Comment 56 Colin Law 2015-08-25 18:24:35 UTC
It appears that the problem no longer shows itself on the Fujutsu A544, even before updating the bios, so presumably some update in the last few months fixed it.
Comment 57 Aaron Lu 2015-08-26 02:09:54 UTC
(In reply to Colin Law from comment #56)
> It appears that the problem no longer shows itself on the Fujutsu A544, even
> before updating the bios, so presumably some update in the last few months
> fixed it.

That's strange...but a good thing I think?
BTW, which kernel version and BIOS version are you using?
Comment 58 Colin Law 2015-08-26 08:10:36 UTC
Sorry, I should have said.  On A544, no longer showing the problem, kernel is 3.19.0-26 on Ubuntu 15.04 with BIOS 1.18.  I have now upgraded to 1.19 and it is still ok.
Comment 59 Aaron Lu 2015-08-26 08:41:30 UTC
(In reply to Colin Law from comment #58)
> Sorry, I should have said.  On A544, no longer showing the problem, kernel
> is 3.19.0-26 on Ubuntu 15.04 with BIOS 1.18.  I have now upgraded to 1.19
> and it is still ok.

Thanks for the info.

SPROg,
I saw you are using a newer kernel v4.0, but which BIOS version is yours? Thanks.
Comment 60 Aaron Lu 2015-08-26 08:43:43 UTC
(In reply to Aaron Lu from comment #59)
> SPROg,
> I saw you are using a newer kernel v4.0, but which BIOS version is yours?
> Thanks.

OK, just found the BIOS information from your DMI log.

BIOS Information
	Vendor: FUJITSU // Phoenix Technologies Ltd.
	Version: Version 1.17
	Release Date: 05/09/2014

Can you try to upgrade to version 1.18 or 1.19 to see if that makes any difference?
Comment 61 Colin Law 2015-09-01 08:12:38 UTC
Further to my comment #56 that the problem no longer appears on the A544 with BIOS 1.19 and kernel 3.19.0-26 I have updated to Ubuntu 15.10 Beta which has kernel 4.1.0-3 and the problem has reappeared, which seems rather odd.
Comment 62 Colin Law 2015-09-01 08:38:51 UTC
I have reverted to 3.19.0 and confirmed that the problem is not seen. I have also tried latest mainline 4.2.0 (linux-image-4.2.0-040200-generic_4.2.0-040200.201508301530_amd64.deb) and the problem appears.  It seems that it was introduced between 3.19.0 and 4.1.0.
If it would help I can try intermediate versions.
Comment 63 Aaron Lu 2015-09-01 08:54:18 UTC
I think you can test v4.0 first, depending on if that works, you can do a git bisect. git bisect will need build a lot more kernels and much more time comsuming.
Comment 64 Colin Law 2015-09-01 11:12:31 UTC
Thanks Aaron, that sounds like fun.  I have never built a kernel so I have a bit of googling to do.
Meanwhile I wonder whether others seeing this problem would like to try 3.19.0 kernel to see whether this is specific to me.
Comment 65 Colin Law 2015-09-01 13:08:44 UTC
The problem appears to have been introduced between 3.19.8-vivid and 4.0-rc1-vivid (from http://kernel.ubuntu.com/~kernel-ppa/mainline/?C=N;O=D).  I am cloning the kernel repository.
Comment 66 Colin Law 2015-09-02 13:37:55 UTC
As I feared the last 3.19 kernel (from git://kernel.ubuntu.com/ubuntu/ubuntu-vivid.git ) does not show the problem, but the first 4.0 kernel that will build using fakeroot debian/rules binary-headers binary-generic, which is

commit 636cdd7b2930ca2cdaf90eedd04fdb9fc7a8d5ec
Author: Stefan Bader <stefan.bader@canonical.com>
Date:   Thu Feb 14 09:55:49 2008 -0500

    UBUNTU: SAUCE: (no-up) ubuntu: dm-raid45

from  https://code.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/wily
does show the problem.  So don't know where to go from here.
Comment 67 Colin Law 2015-09-02 16:16:11 UTC
I have opened a new ubuntu bug to [1] track this specific problem as the previous ubuntu bug covered several different issues.

[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1491467

A bisect is on-going there.
Comment 68 Aaron Lu 2015-09-06 01:03:19 UTC
if v3.19 doesn't have the problem but v3.19.8 does, I think you can use Greg's stable git tree for the bisect since stable branch between v3.19 and v3.19.8 should have far less commits than Linus' main branch between v3.19 and v4.0.

And you can also build those v3.19.x kernels to find the first failure one and then the bisect just between v3.19.x and v3.19.(x+1).
Comment 69 Colin Law 2015-09-06 07:23:04 UTC
Aaron
I think you misread my comments.  3.19.8 does not show the problem.  4.0 is the first that does.  See comment #65 and #66.
Comment 70 Aaron Lu 2015-09-07 07:40:49 UTC
Oh I see, than the bisect would have to be between v3.19 and v4.0.
Comment 71 Lv Zheng 2015-10-09 03:00:21 UTC
*** Bug 105491 has been marked as a duplicate of this bug. ***
Comment 72 j2154468 2016-01-11 12:41:08 UTC
I am using Fujitu AH544, with rotational HDD.
BIOS update to 1.20 fixes the GPE13 issue.
Comment 73 Manuel 2016-01-15 13:20:41 UTC
I am using a Fujitsu Lifebook A544, with normal HDD and optical drive.

The high-cpu load issue is present with kernel 3.19 (Ubuntu Trusty), 4.2 (Ubuntu Wily and Fedora 23) and 4.3 (Ubuntu Xenial), with BIOS 1.18 and 1.19. Moreover, the optical drive seems to be unable to read CDs and DVDs.

After upgrading the BIOS to 1.20, the problem disappears with all the aforementioned kernels, and the optical drive is back to reading CDs and DVDs again.

I believe that the issue was known by Fujitsu itself, since it reports the bug as fixed in the BIOS 1.19-1.20 changelog.
Comment 74 Colin Law 2016-01-16 09:49:11 UTC
On the Fujitsu Lifebook A544 with SSD upgrading BIOS to 1.20 fixed this problem for me also.
Comment 75 kobayashison 2016-07-01 10:24:12 UTC
I think I discovered what trigger the GPE13.

It looks like the ODD trigger gpe13 when no disk is loaded.

If I boot with a disk loaded in the ODD (no matter the content of the disk), /sys/firmware/acpi/interrupts/gpe13 counter stay at zero and kworker is not a problem. Then, if I unload the disk, the gpe13 start growing fast and the kworker getting close to 100% of CPU load. If I soon load the disk again, the gpe13 stop growing and the kworker return to normal levels.

If I boot without a disk, the gpe13 grow very fast, kworker start to use close to 100% of CPU. Then, if I load a disk, the gpe13 stop growing but the kworker still keep going on probably because it has to deal with the big amount of "interruptions" of gpe13.

I have the origina ODD that is a slot-loading kind TSSTcorp CDDVDW SU-B08AB with firmware SC01. I upgraded it yesterday and I don't notice any difference respect to fw SC00.

I hope it can help to resolve the problem.

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