[Bug 105760] [4.17-rc1] RIP: smu7_populate_single_firmware_entry.isra.6+0x57/0xc0 [amdgpu] RSP: ffffa17901efb930

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Jul 16 17:07:03 UTC 2018


https://bugs.freedesktop.org/show_bug.cgi?id=105760

--- Comment #48 from Alex Deucher <alexdeucher at gmail.com> ---
(In reply to Thomas Martitz from comment #47)
> 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20180716/735db00c/attachment.html>


More information about the dri-devel mailing list