Am 28.02.23 um 10:52 schrieb Mikhail Gavrilov:
On Mon, Feb 27, 2023 at 3:22 PM Christian König
Unfortunately yes. We could clean that up a bit more so that you don't
run into a BUG() assertion, but what essentially happens here is that we
completely fail to talk to the hardware.
In this situation we can't even re-enable vesa or text console any more.
Then I don't understand why when amdgpu is blacklisted via
modprobe.blacklist=amdgpu then I see graphics and could login into
GNOME. Yes without hardware acceleration, but it is better than non
working graphics. It means there is some other driver (I assume this
is "video") which can successfully talk to the AMD hardware in
conditions where amdgpu cannot do this.
The point is it doesn't need to talk to the amdgpu hardware. What it
does is that it talks to the good old VGA/VESA emulation and that just
happens to be still enabled by the BIOS/GRUB.
And that VGA/VESA emulation doesn't need any BAR or whatever to keep the
hw running in the state where it was initialized before the kernel
started. The kernel just grabs the addresses where it needs to write the
display data and keeps going with that.
But when a hw specific driver wants to load this is the first thing
which gets disabled because we need to load new firmware. And with the
BARs disabled this can't be re-enabled without rebooting the system.
My suggestion is that if
amdgpu fails to talk to the hardware, then let another suitable driver
do it. I attached a system log when I apply "pci=nocrs" with
"modprobe.blacklist=amdgpu" for showing that graphics work right in
this case.
To do this, does the Linux module loading mechanism need to be refined?
That's actually working as expected. The real problem is that the BIOS
on that system is so broken that we can't access the hw correctly.
What we could to do is to check the BARs very early on and refuse to
load when they are disable. The problem with this approach is that there
are systems where it is normal that the BARs are disable until the
driver loads and get enabled during the hardware initialization process.
What you might want to look into is to find a quirk for the BIOS to
properly enable the nvme controller.
Regards,
Christian.
