Re: amdgpu didn't start with pci=nocrs parameter, get error "Fatal error during GPU init"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux