Bug 202031
| Summary: | Gigabyte X299 DESIGNARE EX PCIe root port in D3 prevents ACPI hotplug | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Mika Westerberg (mika.westerberg) |
| Component: | PCI | Assignee: | drivers_pci (drivers_pci) |
| Status: | NEW --- | ||
| Severity: | normal | ||
| Priority: | P1 | ||
| Hardware: | x86-64 | ||
| OS: | Linux | ||
| Kernel Version: | v4.20-rc7 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
acpidump from the system
dmesg of the boot Output of dmidecode output of lspci -vv |
||
Created attachment 280089 [details]
dmesg of the boot
Created attachment 280091 [details]
Output of dmidecode
Created attachment 280093 [details]
output of lspci -vv
The root port in question is 1c.4. |
Created attachment 280087 [details] acpidump from the system Gigabyte X299 DESIGNARE EX PCIe root port 1c.4 is connected to Thunderbolt controller which is supposed to be hot-plugged when there is a device plugged in. However, since the root port is not marked as "hotplug capable" Linux puts it in D3 pretty soon after boot. When Thunderbolt or USB-C device is connected to the port the BIOS SMI handler gets confused because the port is in D3. This results that it does not find anything below the root port. Normally when ACPI hotplug is used the port itself is still announcing that is it "hotplug capable" so Linux knows that it should not interfere with the BIOS but this is not the case with this Ǵigabyte motherboard. It is possible that the same issue exists in other BIOSes from Gigabyte as well. Windows behavior seems to be that it does not power manage this port (well none of the root ports).