<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - [4.17-rc1] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930" href="https://bugs.freedesktop.org/show_bug.cgi?id=105760#c48">Comment # 48</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - [4.17-rc1] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930" href="https://bugs.freedesktop.org/show_bug.cgi?id=105760">bug 105760</a> from <a class="email" href="mailto:alexdeucher@gmail.com" title="Alex Deucher <alexdeucher@gmail.com>"> Alex Deucher</a> <pre>(In reply to Thomas Martitz from <a href="show_bug.cgi?id=105760#c47">comment #47</a>) > So pci_raw_set_power_state() does a pci_read_config_word() and that returns > a valid word. Yet, the device appears to be not in powerd up state later on. > How's that possible, and why does it work on Windows? > > Can I inspect Windows behavior in some way to get insight? > > Since Windows works I'm sure there must be a SW fix (or at least a > workaround) available. Perhaps just wait for a bit? In HG laptops, the d3cold control is handled by the OS rather than the driver (e.g., the driver doesn't call into APCI to handle d3cold, the pci core does). The driver just has to support the necessary callbacks to the OS to enter/leave this state when idle. Each OS interacts slightly differently with ACPI so if the OEM never validated Linux it's likely there is some slight differences in the sequencing that is causing a problem. You might try playing with the ACPI interfaces directly on Linux. There are user mode tools to interact with ACPI. Blacklist the amdgpu driver and try calling the _PR3 method for the device to power it down/up and then see if the device comes back properly.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>