Bug 53071

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

Created attachment 93741 [details]
acpidump > acpi.out

acpidump > acpi.out

as requested

Any updates on this bug? This is a major PITA to work around and we don't what we are disabling by disbaling gpe13.

(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.

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.

Does this problem occur right after boot without doing anything or after doing something?

ping

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?

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%

it appears to be this bug https://patchwork.kernel.org/patch/2400621/

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.

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.

Why would you close the bug with CODE_FIX? Is this bug fixed? Can I have the patch for 3.14.5 pls?

No fix yet. Still waiting for a proper solution to the problem.

Hi,

Pinging...

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

Thanks

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.

Still present in kernel 3.15.1

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

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.

(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.

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

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

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)
        }

Created attachment 154621 [details]
acpidump for Lv Zheng

Created attachment 154631 [details]
Patch for Fujitsu Lifebook AH544. [DBG PATCH 6/5]

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

(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!=)

(In reply to SPROg from comment #24)
> Created attachment 154621 [details]
> acpidump for Lv Zheng

Thanks for the patch. :-)

(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).

(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

Created attachment 154741 [details]
Samsung-700Z5C acpidmp -b

acpidump for Samsung 700Z5C

Created attachment 154751 [details]
Samsung 700Z5C dmidecode --dump-bin

dmidecode --dump-bin  for Samsung 700Z5C

Created attachment 155561 [details]
[PATCH] ACPI: Add GPE quirks for SATA PIN4 detection.

Hi, James

The patch is ready for you. Please check.

Thanks

This patch is not currently upstream.

(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

*** Bug 85881 has been marked as a duplicate of this bug. ***

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.

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

(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.

Created attachment 168981 [details]
Fujitsu A544 dmidecode

Created attachment 168991 [details]
Fujitsu A544 acpidump

Hi Lv Zheng, hopefully this is what is required.  Results from dmidecode and acpidump attached.

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.

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!

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.

Fujitsu A544 as already reported in comment #38.
Note this is not an AH544.

Fujitsu AH544. Reported in comment #23
Kernel 4.0.6 still suffering from this problem

Do you all suffer the GPE 13 storm or other GPE number?
And did you also replace the original ODD with a SATA drive?

(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.

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.

(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.

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.

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

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

(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.

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.

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

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.

(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.

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

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.

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.

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.

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.

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.

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.

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.

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).

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.

Oh I see, than the bisect would have to be between v3.19 and v4.0.

*** Bug 105491 has been marked as a duplicate of this bug. ***

I am using Fujitu AH544, with rotational HDD.
BIOS update to 1.20 fixes the GPE13 issue.

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.

On the Fujitsu Lifebook A544 with SSD upgrading BIOS to 1.20 fixed this problem for me also.

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.