Bug 63021
| Summary: | GPE 0x0D interrupt stormafter plugging an USB device after resume, Linux 3.8 OK, Linux 3.9 broken - Samsung NP550P5C | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Agustin Barto (abarto) |
| Component: | Power-Sleep-Wake | Assignee: | Alan Stern (stern) |
| Status: | CLOSED PATCH_ALREADY_AVAILABLE | ||
| Severity: | normal | CC: | lenb, rjw, rui.zhang, stern, tianyu.lan |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.12 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
ACPI dump with "USB S3 Wake-Up" disabled
ACPI dump with "USB S3 Wake-Up" enabled ACPI dump with "USB S3 Wake-Up" disabled ACPI dump with "USB S3 Wake-Up" enabled ACPI dump with "USB S3 Wake-Up" disabled (taken on Windows) ACPI dump with "USB S3 Wake-Up" enabled (taken on Windows) Diff between DSDT files git bisect log New git bisect log PCI / ACPI: Install wakeup notify handlers for all devices |
||
|
Description
Agustin Barto
2013-10-14 13:01:19 UTC
Created attachment 110941 [details]
ACPI dump with "USB S3 Wake-Up" enabled
please use the acpidump tool without any parameter, say "acpidump > acpidump.out". Created attachment 110951 [details]
ACPI dump with "USB S3 Wake-Up" disabled
Created attachment 110961 [details]
ACPI dump with "USB S3 Wake-Up" enabled
An annoying (and potentially dangerous) side-effect of enabling "USB S3 Wake-Up" is that the box turns itself on. I tried the latest kernel version (3.12.0-031200-generic) from Ubuntu's kernel PPA and the issue is no longer present. Nevermind, the bug is still there on 3.12.0. I had left the "USB S3 Wake-Up" option enabled by mistake. The bug is still in the NEEDINFO state. Is there anything else I can do to help? Created attachment 114811 [details]
ACPI dump with "USB S3 Wake-Up" disabled (taken on Windows)
Created attachment 114821 [details]
ACPI dump with "USB S3 Wake-Up" enabled (taken on Windows)
Added ACPI dumps taken while running Windows 7. I found a proper work-around for the problem. I noticed that the ACPI dumps differed when the "USB S3 Wake-Up" was enabled or disabled, so what I took the DSDT for when the option is enabled, recompiled it, and forced it using the instructions given in [1]. I then disabled the option (so the laptop won't turn itself on when it's in the bag). So far, I haven't seen any storms when plunging stuff into the USB3 ports and the box stays off at suspend. Now I can wait until the bug is fixed or until I manage to get rid of this piece of crap. I'd avoid Samsung laptops if I were you. They're Linux support is atrocious. I'm attaching the diff between the decompiled DSL files for when the option is enabled and disabled. Created attachment 114891 [details]
Diff between DSDT files
The diff between the decompiled DSDT files for when "USB S3 Wake-Up" is enabled or disabled.
I forgot the link [1] http://blog.michael.kuron-germany.de/2011/03/patching-dsdt-in-recent-linux-kernels-without-recompiling/ which USB S3 wakeup setting is the SETUP default? do you have the capability to apply patches to a test kernel? The default value for "USB S3 Wake-Up" is off, and that's when the problem occurs. When it is on, the issue is gone but the notebook wakes itself up. I can test patches. Since this is a regression, git bisect would be more helpful. Could you bisect between v3.8 and v3.9 and find which commit cause this issue? I've bisected the issue to this commit: 84ebc10294a3d7be4c66f51070b7aedbaa24de9b is the first bad commit commit 84ebc10294a3d7be4c66f51070b7aedbaa24de9b Author: Alan Stern <stern@rowland.harvard.edu> Date: Wed Mar 27 16:14:46 2013 -0400 USB: remove CONFIG_USB_SUSPEND option This patch (as1675) removes the CONFIG_USB_SUSPEND option, essentially replacing it everywhere with CONFIG_PM_RUNTIME (except for one place in hub.c, where it is replaced with CONFIG_PM because the code needs to be used in both runtime and system PM). The net result is code shrinkage and simplification. There's very little point in keeping CONFIG_USB_SUSPEND because almost everybody enables it. The few that don't will find that the usbcore module has gotten somewhat bigger and they will have to take active measures if they want to prevent hubs from being runtime suspended. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> CC: Peter Chen <peter.chen@freescale.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> :040000 040000 6c34605a5dd227da28e2d9178d061813387cb8d7 020ca131593abf09904bdf78b091df1ddc86958c M drivers :040000 040000 3c0bb1dfca31ef55c1a9b231499a2f42728c24a3 bf74ea11a78878475a06ec3a951d671806ee03e3 M include Created attachment 118331 [details]
git bisect log
I'm attaching the bisect log
The bisect result show this is a usb bug and so reassign to USB component. If you build a kernel without commit 84ebc10294a3 (say, a 3.8 kernel) and enable CONFIG_USB_SUSPEND in the configuration, is the problem still present? I ask because the effect of this commit is basically nothing more than forcing CONFIG_USB_SUSPEND to be always on. Therefore any bug present with the commit in place should also be present without it. I built a 3.8 with CONFIG_USB_SUSPEND and the issue was not present. I checked the commit prior to the one I mentioned, but using USB_SUSPEND and the bug is there. Given what 84ebc10294a3d7be4c66f51070b7aedbaa24de9b does, it means that the bug will only present itself when the option is on. I'll bisect again making sure the option is always on. I bisected the bug to the following commit: d2e5f0c16ad60a7208fd371233e63b73c990ece2 is the first bad commit commit d2e5f0c16ad60a7208fd371233e63b73c990ece2 Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Date: Sun Dec 23 00:02:44 2012 +0100 ACPI / PCI: Rework the setup and cleanup of device wakeup Currently, the ACPI wakeup capability of PCI devices is set up in two different places, partially in acpi_pci_bind() where runtime wakeup is initialized and partially in platform_pci_wakeup_init(), where system wakeup is initialized. The cleanup is only done in acpi_pci_unbind() and it only covers runtime wakeup. Use the new .setup() and .cleanup() callbacks in struct acpi_bus_type to consolidate that code and do the setup and the cleanup each in one place. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Yinghai Lu <yinghai@kernel.org> Acked-by: Toshi Kani <toshi.kani@hp.com> :040000 040000 54c370be3a3931892099304e234a5264c5aa7115 42a29f3fd89ad8d9326ebf5dae86e6e686fe5f38 M drivers :040000 040000 fc04f2786089b6d19a3bcefdf73d4974b2a4759b 336c2fa7235bb145da71d08672ae07d0b7894957 M include I made sure that USB_SUSPEND was on every time. I'm attaching the new bisect log. Created attachment 118741 [details]
New git bisect log
Perhaps this issue should be reassigned back to the ACPI component? Okay, go ahead. I sent an email message to Rafael Wysocki, asking him to look at this. No response yet. I think that this is a BIOS bug. What happens is that with "USB S3 Wake-Up" the BIOS doesn't report GPE 0x0D as a wakeup GPE, but still it is used for signaling wakeup after system resume. It looks like this code path hasn't been sufficiently tested by the BIOS writers. I'll attach a debug patch in the next comment, please check if it makes any difference. Created attachment 119601 [details]
PCI / ACPI: Install wakeup notify handlers for all devices
The patch should apply on top of 3.13-rc5.
The patch fixes the problem. I plugged a device into the USB3 port after resuming and it didn't cause a storm. I tried without the patch just to be safe, and the bug was still there. Patch submitted: https://patchwork.kernel.org/patch/3407631/ Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2013-12-29 17:37:15 Committer: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 2013-12-29 17:37:15 Follows: v3.13-rc5 Precedes: v3.13-rc7 PCI / ACPI: Install wakeup notify handlers for all PCI devs with ACPI closed. |