amdgpu ati radeon NetBSD-current

pfr

rvp
I gave it a go. Got a bunch of errors in the frame buffer which I can't copy and pate here.
I'll type what I saw though

breakpoint() at netbsd:breakpoint+0x5
vpanic() at netbsd:vpanic_0x173
kern_asset() at netbsd:kern_asset_0x4b
linux_pci_get_class() at netbsd:linux_pci_get_class+0xa8
amdgpu_get_bios() at amdgpu:amdgpu_get_bios+0x34
amdgpu_device_init() at amdgpu:amdgpu_device_init+0xecf
amdgpu_driver_load_kms() at amdgpu:amdgpu_driver_load_kms+0x51
drm_dev_register() at netbsd:drm_dev_register+0x166
amdgpu_attach_real() at amdgpu:amdgpu_attach_real+0xa8
config_mountroot_thread() at netbsd:config_mountroot_thread+0x60

This is what I had:

menu=Boot prompt:prompt
menu=Boot normally:rndseed /var/db/entropy-file;load amdgpu;load drmkms;load pci;load drmkms_pci;load drmkms_sched;load drmkms_ttm;load drmkms_linux;load i2cexec;load sysmon_power;boot
menu=Boot 1440p:rndseed /var/db/entropy-file;gop 5;boot
menu=Boot single user:rndseed /var/db/entropy-file;boot -s
menu=Drop to boot prompt:prompt
default=1
timeout=3
clear=1

For some reason the selection in the boot menu is not consistent. I had to add a prompt entry at the beginning as previously hitting the corresponding number to drop to prompt [4] would not work and would just boot the system.

Oh, and this also does not work:

menu=Boot 1440p:rndseed /var/db/entropy-file;gop 5;boot

rvp

pfr

menu=Boot normally:rndseed /var/db/entropy-file;load amdgpu;load drmkms;load pci;load drmkms_pci;load drmkms_sched;load drmkms_ttm;load drmkms_linux;load i2cexec;load sysmon_power;boot

No, don't load every dependency; just the non-builtin ones. (Is there even a module called pci.kmod?)
If that doesn't work, just rebuild the kernel.

pfr For some reason the selection in the boot menu is not consistent. I had to add a prompt entry at the beginning as previously hitting the corresponding number to drop to prompt [4] would not work and would just boot the system.

Bizarre.

pfr Oh, and this also does not work:

menu=Boot 1440p:rndseed /var/db/entropy-file;gop 5;boot

It should've. Crazy. (Or perhaps, just Australia...)

pfr

rvp thankfully the boot order issue was user error. I was using the arrow keys to stop the timeout instead of space and that apparently messes with the starting point of the boot menu... Go figure 🦘

This was also why I seemingly was unable to boot with the gop 5 option. It does in fact work when I don't touch the arrow keys.

Anyway, unfortunately I'm still not having luck loading the amdgpu modules successfully. I'd like to get it right using modload first before attempting to rebuild the kernel... That way I'll know exactly what needs to be enabled in the kernel, right?

@Jay if it isn't too much trouble, could you please change the title of this thread to replace NetBSD-9.3 with NetBSD-CURRENT and perhaps even delete all the comments before 2024. It doesn't seem relevant to this thread now. 🙏

rvp

pfr Anyway, unfortunately I'm still not having luck loading the amdgpu modules successfully.

I think just load drmkms_sched; load amdgpu ought to suffice. Everything else seems to be built into the kernel.

pfr That way I'll know exactly what needs to be enabled in the kernel, right?

Not really. Most of the drmkms bits get linked in implicitly.

pfr

rvp
I dropped to the boot prompts and:

> load amdgpu
> load drmkms
> boot

and got this: (not gonna type it out again)

Mind you, I did this without any /etc/xorg.conf ie. I've renamed it xorg.conf.bak
Do I need to edit my xorg.conf?

Section "Device"
        Identifier "Card0"
        Driver "wsfb"
EndSection

Should I use modesetting instead of wsfb?

rvp

pfr and got this

That's either a) we missed a reqd. module or, b) DRMKMS modules are simply not 1st-class citizens.

For a), do: modstat >before.txt; modload amdgpu; modstat >after.txt. Then, do a diff and see what new modules got loaded.

If it's b), compile a new kernel.

pfr Should I use modesetting instead of wsfb?

Yes, but only if DRMKMS driver works.

pfr

rvp do: modstat >before.txt; modload amdgpu; modstat >after.txt. Then, do a diff and see what new modules got loaded.

if diff -u before.txt after.txt has no output does that mean the files are the same? meaning its time for option B.?

rvp

pfr How did you do this test? It should be done with no load lines in /boot.cfg. Then, at least 2 modules should've been loaded: amdgpu and drmkms_sched

If it was with the load lines, then probably all the required modules got loaded. What does the dmesg look like in this case?

pfr

rvp I'm not booting with any load options. Just entered the command from a terminal once logged in.

rvp

pfr Can't be. As I said before, if you do modload amdgpu with a GENERIC kernel w/o any modules load lines, at least 2 modules will get loaded (amdgpu and drmkms_sched).

Post the dmesg output, we'll see if amdgpu "took".

pfr

I made a mistake last time and instead of loading drmkms_sched I just loaded drmkms.
After doing it correctly I was hopeful as my screen held it's native 1440p resolution for much longer while booting, but then reverted to "shithouse" reslolution after .. something failed.

rvp Post the dmesg output, we'll see if amdgpu "took".

dmesg

I'm assuming this is the line that indicated that amdgpu doees not "take"?

[    11.706040] wsdisplay0 at amdgpufb0 kbdmux 1: console (default, vt100 emulation), using wskbd0

rvp

pfr but then reverted to "shithouse" reslolution

Not quite--that's just the larger font being used.

I would've said, "Party time!", except:

[    51.995337] panic: unlocking unlocked wait/wound mutex: 0xffffa82fa4fe0d20
[    51.995337] cpu1: Begin traceback...
[    51.995337] vpanic() at netbsd:vpanic+0x183
[    51.995337] panic() at netbsd:panic+0x3c
[    51.995337] linux_ww_mutex_unlock() at netbsd:linux_ww_mutex_unlock+0x9e
[    51.995337] ttm_bo_release() at netbsd:ttm_bo_release+0xf3
[    51.995337] amdgpu_bo_unref() at amdgpu:amdgpu_bo_unref+0x1d
[    51.995337] amdgpu_vm_free_table() at amdgpu:amdgpu_vm_free_table+0x53
[    51.995337] amdgpu_vm_free_pts() at amdgpu:amdgpu_vm_free_pts+0x6a
[    51.995337] amdgpu_vm_fini() at amdgpu:amdgpu_vm_fini+0x28c
[    51.995337] amdgpu_driver_postclose_kms() at amdgpu:amdgpu_driver_postclose_kms+0x133
[    51.995337] drm_file_free() at netbsd:drm_file_free+0x1fb
[    51.995337] drm_close() at netbsd:drm_close+0x60
[    51.995337] closef() at netbsd:closef+0x58
[    52.005335] fd_close() at netbsd:fd_close+0x140
[    52.005335] sys_close() at netbsd:sys_close+0x22
[    52.005335] syscall() at netbsd:syscall+0x1fc
[    52.005335] --- syscall (number 6) ---
[    52.005335] netbsd:syscall+0x1fc:

That's a kernel bug. File a PR (looks like the same issue as @r0ller) after you try the modesetting driver.

pfr I'm assuming this is the line that indicated that amdgpu doees not "take"?

No, just the opposite: it took.

BTW, the modesetting Xorg driver is recommended with DRMKMS. Do you have that config. fragment in place (so that the radeon driver is not tried)?

pfr

rvp BTW, the modesetting Xorg driver is recommended with DRMKMS. Do you have that config. fragment in place (so that the radeon driver is not tried)?

dmesg using modesetting in my xorg.conf
Running startx completely fails and the system automatically reboots.

rvp File a PR

Happy to. But, I'm out of my depth with this stuff..

What exactly am I requesting in the PR?
Where exactly do I submit the PR?
What should I include in the PR?

rvp

pfr dmesg using modesetting in my xorg.conf

Can't see any errors at all there.

pfr Running startx completely fails and the system automatically reboots.

Can you show the /var/log/Xorg.0.log resulting from this instance (ie. save the file before you do startx after the reboot).

pfr

rvp yeeehhhhhh, nope. It's there... But it's empty

pfr

Ok... I had some time away from my computer... 3 months just about. I've re-read over this entire thread again to refresh my memory. My brain hurts, but I still want to fix this!

Seeing as you've identified a kernel bug above, will recompiling the kernel (as suggested earlier in the peace) even solve this issue?

I'm prepared to submit a Problem Report, but having never done that before I may not do it 'properly'..

I've read over the PR Hint's page, but for things like Severity, Priority, Class fields I'm unsure what to enter. I'm guessing for this I'll assign it the sw-bug Class?

Anyway, I'll have a try and see what happens. I greatly appreciate all your support here @rvp 👍️
If I've missed anything in the last few months please do let me know, otherwise wish me luck.

rvp

pfr will recompiling the kernel (as suggested earlier in the peace) even solve this issue?

That's the first thing to do. Then enable sshd; boot using boot -vx (bootloader prompt); save the dmesg output; startx.

If startx crashes, try sshing into the machine to collect any kernel errors. If you can't ssh in, see if the keyboard works by pressing numlock. If it does, try rebooting the system blindly. Type: <space><enter>reboot (or sudo reboot--depending).

If you can reboot the system (instead of having to powering it down to recover), then the previous kernel messages should still be around in memory and a dmesg should be able to retrieve it after a reboot.

r0ller

pfr
There may be already a PR for this: 58032
At least, it's about "machine with amdgpu panics on starting X" and when searching through it I could find a crash dump with the "panic: unlocking unlocked wait/wound mutex" message where our problems also start.

rvp

r0ller As riastradh@ says in the PR, compile the kernel with all these uncommented:

# Diagnostic/debugging support options
options        DIAGNOSTIC       # inexpensive kernel consistency checks
                                # XXX to be commented out on release branch
options        DEBUG            # expensive debugging checks/support
options        LOCKDEBUG        # expensive locking checks/support

« Previous Page Next Page »