I have a Latitude E6530 running Windows 7 with updated with all drivers just a few days ago and this problem still persists:
When I connect a USB device to any of the super speed ports, the CPU usage goes up. Looking in the task manager, I can see that the items Interrupts and System are both consuming ~10 CPU. As this is a multi core machine, this essentially means that 100% of 2 threads are completely blocked.
This problem started a few years back when I did a complete driver update (I had a replacement BT card that didn't work and I thought that updating the drivers would help, unfortunately the BT card was broken and the update gave me broken USB drivers instead
If I hibernate the computer, the problem goes away after it wakes up again, but as soon as I connect a USB device to any of the USB3 ports, the problem comes back.
Any thoughts on what this is and what I can do to fix it?
I just tried the instructions in that thread. I ran the tool from Intel and it did not report that my drivers were out of date. I tried to update the drivers anyway but it did not result in any improvement
I just plugged my Android phone in my SS port to charge and the CPU load went up to 20%, split 10% on "Interrupts" and "System"
Using Windows Performance Analyzer, I was able to find out that it is ACPI.sys that was responsible for most of the interrupt related CPU usage. Any thoughts on how to drill further down into this to find out what is going on?
Sorry for the delay, were you still having trouble with the system? If so, let me see if there is anything else we can try, if anything changed let me know.
I have the same problem on a Dell Latitude E6530.
I use Windows 10 Pro 64 bits (1703).
The BIOS is up to date : version A20 (05/08/2017).
When I plug ou unplug a device on the USB 3.0 ports (right or left port), the System process goes up to ~15% CPU usage. I have to sleep/resume or reboot to have a normal CPU usage.
The CPU usage is taken by the ACPI.sys (found with Windows Performance Recorder).
This problem does not happen with USB 2.0 (rear port) or E-SATA port on right.
Sorry for the late reply. I have not been able to get any further with this problem. The problem looks exactly the same as the description below from DamienGombaultRecia. Can you think of any additional experiments that I could try to find out why this is causing problems with acpi.sys?
I looked for this problem on Internet.
The problem is caused by an interrupt storm (ACPI GPE with ID 0x0D) when your plug/unplug a USB 3.0 device after resuming the computer.
This problem was reported to Linux developpers :
GPE 0x0D interrupt storm after plugging an USB device after resume, Linux 3.8 OK, Linux 3.9 broken - Samsung NP550P5C
This problem happens on Dell Latitude E6530 but also on other computers from the same generation (Intel Series 7 chipset and Intel Core 3rd Generation CPU).
Rafael J. Wysocki (développeur chez Intel) thinks it's a bug in the BIOS :
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.
The problem was fixed with a workaround for Linux but not for Windows :
From: Rafael J. Wysocki <email@example.com>
It turns out that some BIOSes don't report wakeup GPEs through
_PRW, but use them for signaling wakeup anyway, which causes GPE
storms to occur on some systems after resume from system suspend.
This issue has been uncovered by commit d2e5f0c16ad6 (ACPI / PCI:
Rework the setup and cleanup of device wakeup) during the 3.9
Work around the problem by installing wakeup notify handlers for all
PCI devices with ACPI support (i.e. having ACPI companions) regardless
of whether or not the BIOS reports ACPI wakeup support for them. The
presence of the wakeup notify handlers alone is not harmful in any
way if there are no events for them to handle (they are simply never
executed then), but on some systems they are needed to take care of
I think the Dell developers should fix this problem with a new BIOS release.