Sparc64/linux: Kernel panic on loading module

Brief summary of the problem:

Reproduces 100% of the time for me. Sometimes it happens instantaneously, sometimes modprobe takes a while (above 20 minutes in one case). No matter what, I get a kernel panic before the module is finished loading.

Hardware description:

• CPU: SPARC T4 (niagara4)
• GPU: WX 3200
• System Memory: 256GB DDR3
• Display(s): One apple cinema dport display
• Type of Display Connection: DP

System information:

• Distro name and Version: Gentoo Linux Unstable
• Kernel version: 5.15.70-gentoo
• Custom kernel: N/A
• AMD official driver version: N/A?

How to reproduce the issue:

Extremely easy to reproduce.
modprobe amdgpu and it will happen.
Interesting note, is that the module is not auto loaded on startup. But, it also doesn't with a few other components, so probably unrelated.

I know not everyone has a sparc64 machine laying around, especially with a PCIe amdgpu, so if you want/need ssh access, feel free to let me know :)

Attached files:

Error output kernel .config

Log files (for system lockups / game freezes / crashes)

• Dmesg log (Here's the log for everything before loading the module: the snippets about the driver are above)
  log
  lspci -vv

changed the description

changed the description

Have been digging into the full dmesg log. See things that may indicate this may be caused more by Linux's PCIe handling than the driver. Will open an issue upstream, will link it here when done :)

Does loading modprobe amdgpu aspm=0 help?

modprobe amdgpu aspm=0
Nope, does not seem to :/

I sent an email to the PCI mailing list upstream here. Apparently it seems the more generic PCI problems are unrelated, and it does seem to be a problem with the amdgpu driver :\

dmesg ofpci_debug=1 The mailing list folks asked for this, might be helpful :)

I'm not exactly sure what those errors mean, but it appears to be a problem reading from some registers in the GPU's MMIO register BAR. Maybe someone more familiar with SPARC can provide some advice.

This issue hasn't had any activity since 2022-10-21. The AMD driver stack changes rapidly and contains lots of shared code across products so it's possible that it has already been fixed. Please upgrade to a current stable kernel and userspace stack and try again. If you still experience this issue with the latest driver stack, please capture relevant logging and open a new issue referring back to this one.

closed