Is it possible to run X as root but the wm as normal user?

r0ller

kc9udx
Hm, mine looks ok:
-rws--x--x 1 root wheel 2902344 Mar 28 09:33 /usr/X11R7/bin/Xorg

rvp

r0ller ls -l /dev/dri output is:

crw-r-----  1 root  wheel  180,   0 Jun  6 12:25 card0

Well, that explains some things at least: a) wheel should have rw permissions for all the devices in /dev/dri, and b) the other card devices are missing (only matters if you have multiple graphics cards):

$ ls -l /dev/dri/
total 0
crw-rw----  1 root  wheel  180,   0 Feb 15 03:18 card0
crw-rw----  1 root  wheel  180,   1 Feb 15 03:18 card1
crw-rw----  1 root  wheel  180,   2 Feb 15 03:18 card2
crw-rw----  1 root  wheel  180,   3 Feb 15 03:18 card3
crw-rw----  1 root  wheel  180, 128 Jan 31 04:22 renderD128
crw-rw----  1 root  wheel  180, 129 Jan 31 04:22 renderD129
crw-rw----  1 root  wheel  180, 130 Jan 31 04:22 renderD130
crw-rw----  1 root  wheel  180, 131 Jan 31 04:22 renderD131
$

This should fix it:

# cd /dev/ && rm -fv dri/*
# sh ./MAKEDEV drm0 drm1 drm2 drm3

r0ller Concerning xhost, adding it to .xinitrc made the process hang so I added it to the root's .bash_profile like:
if xhost >& /dev/null ; then xhost + ; su -l r0ller; fi;

Hmm. Do you use startx or xdm? Adding it to .bash_profile is useless if run startx because there's no X server running at that time. Once the server is running, you can do xhost any time (and xhost + is bad--it allows everybody access to the X server; esp bad. if it accepts TCP/IP connections).

r0ller 1) if I boot normally, amdgpu cannot kick in and hangs the boot process. But when booting into single user first, reboot and then boot as normal user only then it gets to the login (not xdm).

DRMKMS bug? Missing firmware blobs? Bad RAM? Buggy BIOS? No idea.

Bad RAM is easiest to check: Memtest86+ or MemTest86

r0ller 2) The other strange thing I noticed is that ACPI seems to work correctly when I boot into single user. At least, the poweroff command works only in that case. When booting normally, even if logged in as root, poweroff does not turn off the box only halts and prints something like press any key to reboot.

Again, no clue. Is it the same if you userconf disable amdgpu* or run GENERIC? (Many kinds of ACPI issues can be fixed with the latest firmware. Can you check yours?)

My advice is to file a PR for the DRMKMS bugs, and just use wsfb until it gets fixed.

Can you post the dmesg output and your Xorg.0.log?
Are you running the modesetting Xorg driver with DRMKMS or the default radeon?

pfr

r0ller X seems to work with amdgpu only when logged in as root

I tried this just to see if it'd also work for me but it does not.

rvp My advice is to file a PR for the DRMKMS bugs, and just use wsfb until it gets fixed.

I think this is what I'll need to do. Far byond me to file a PR for something like this. I'me here to help test thigs if needed, just throw commands at me.

Cheers

r0ller

rvp
Sorry, this will be long as I tried to upload /var/log/messages (as it reveals more than dmesg) and Xorg.0.log but I always just get an error so I'll try to copy them at the end of my write-up. (Edit: created gdrive links for them: messages, Xorg.0.log)

The messages file contains 4 boot processes:
1st: single user mode boot with amdgpu, then reboot
2nd: normal user mode boot with amdgpu, login as root, X crashes
3rd: single user mode boot with amdgpu, then reboot
4th: normal user mode boot with amdgpu, login as root, X running

What I noticed is that amdgpu failing due to mutex handling and my hack to solve it (see https://www.unitedbsd.com/d/1052-netbsd-9-10-amdgpu/25) may have to do something with the ACPI error I mentioned. Some parts of the dmesg differ when booting in single user mode or normal user mode.

BOOT IN SINGLE USER MODE WITH AMDGPU (at the very begining of boot):

Jun 7 09:13:12 r0ller /netbsd: [ 1.0000040] ACPI: RSDP 0x00000000000F05A0 000024 (v02 ALASKA)
Jun 7 09:13:12 r0ller /netbsd: [ 1.0000040] ACPI: XSDT 0x00000000DBDAC098 0000B4 (v01 ALASKA A M I Jun 7 09:13:12 r0ller /netbsd: [ 1.0000040] ACPI: FACP 0x00000000DBDB3C70 000114 (v06 ALASKA A M I Jun 7 09:13:12 r0ller /netbsd: [ 1.0000040] ACPI: DSDT 0x00000000DBDAC1E8 007A83 (v02 ALASKA A M I Jun 7 09:13:12 r0ller /netbsd: [ 1.0000040] ACPI: FACS 0x00000000DBE18E00 000040
Jun 7 09:13:12 r0ller /netbsd: [ 1.0000040] ACPI: APIC 0x00000000DBDB3D88 00015E (v03 ALASKA A M I Jun 7 09:13:12 r0ller /netbsd: [ 1.0000040] ACPI: FPDT 0x00000000DBDB3EE8 000044 (v01 ALASKA A M I Jun 7 09:13:12 r0ller /netbsd: [ 1.0000040] ACPI: FIDT 0x00000000DBDB3F30 00009C (v01 ALASKA A M I Jun 7 09:13:12 r0ller /netbsd: [ 1.0000040] ACPI: SSDT 0x00000000DBDB3FD0 0000C8 (v02 ALASKA CPUSSDT Jun 7 09:13:12 r0ller /netbsd: [ 1.0000040] ACPI: SSDT 0x00000000DBDB4098 008C98 (v02 AMD Jun 7 09:13:12 r0ller /netbsd: [ 1.0000040] ACPI: SSDT 0x00000000DBDBCD30 003676 (v01 AMD Jun 7 09:13:12 r0ller /netbsd: [ 1.0000040] ACPI: MCFG 0x00000000DBDC03A8 00003C (v01 ALASKA A M I Jun 7 09:13:12 r0ller /netbsd: [ 1.0000040] ACPI: HPET 0x00000000DBDC03E8 000038 (v01 ALASKA A M I Jun 7 09:13:12 r0ller /netbsd: [ 1.0000040] ACPI: UEFI 0x00000000DBDC0420 000042 (v01 ALASKA A M I Jun 7 09:13:12 r0ller /netbsd: [ 1.0000040] ACPI: IVRS 0x00000000DBDC0468 0000D0 (v02 AMD Jun 7 09:13:12 r0ller /netbsd: [ 1.0000040] ACPI: PCCT 0x00000000DBDC0538 00006E (v01 AMD Jun 7 09:13:12 r0ller /netbsd: [ 1.0000040] ACPI: SSDT 0x00000000DBDC05A8 002F29 (v01 AMD Jun 7 09:13:12 r0ller /netbsd: [ 1.0000040] ACPI: CRAT 0x00000000DBDC34D8 000B58 (v01 AMD Jun 7 09:13:12 r0ller /netbsd: [ 1.0000040] ACPI: CDIT 0x00000000DBDC4030 000029 (v01 AMD Jun 7 09:13:12 r0ller /netbsd: [ 1.0000040] ACPI: SSDT 0x00000000DBDC4060 001D4A (v01 AMD Jun 7 09:13:12 r0ller /netbsd: [ 1.0000040] ACPI: SSDT 0x00000000DBDC5DB0 0000BF (v01 AMD Jun 7 09:13:12 r0ller /netbsd: [ 1.0000040] ACPI: WSMT 0x00000000DBDC5E70 000028 (v01 ALASKA A M I Jun 7 09:13:12 r0ller /netbsd: [ 1.0000040] ACPI: 7 ACPI AML tables successfully acquired 01072009 AMI 00010013)
01072009 AMI 00010013)
01072009 INTL 20120913)
01072009 AMI 00010013)
01072009 AMI 00010013)
01072009 AMI 00010013)
01072009 AMI 01072009)
AMD ALIB 00000002 MSFT 04000000)
AMD AOD 00000001 INTL 20120913)
01072009 MSFT 00010013)
01072009 AMI 00000005)
00000002 01000013)
AMD IVRS 00000001 AMD 00000000)
AMD PCCT 00000001 AMD 00000000)
AMD CPU 00000001 AMD 00000001)
AMD CRAT 00000001 AMD 00000001)
AMD CDIT 00000001 AMD 00000001)
AmdTable 00000001 INTL 20120913)
AMD PT 00001000 INTL 20120913)
01072009 AMI 00010013)
and loaded

BOOT IN NORMAL USER MODE WITH AMDGPU (at the very begining of boot):

Jun 7 09:13:12 r0ller /netbsd: [ 1.0000040] ACPI Error: AE_BAD_PARAMETER, Thread 2175328192 could not acquire Mutex [ACPI_MTX_Tables] (0x2) (20221020/utmutex-326)

That ACPI error complains about mutexes and the error that I "fixed" earlier by hacking mutex handling to be able to boot in normal user mode with amdgpu was:
panic: unlocking unlocked wait/wound mutex: 0xffff858023c90920

Now that panic does not appear on boot, but probably my hack leads to this mysterious behaviour of X sometimes working and sometimes not (regardless of being root or not) with amdgpu. The interesting question is: why does the ACPI error show up only when booting in normal user mode and never when booting in single user mode?

I'll now give a try to your suggestion about changing the permissions of /dev/dri but until now I was just busy with booting the system and describing in this post what happened 🙂

rvp

r0ller Concerning /dev/dri, is it just enough to change the permission of card0

That should be enough.

r0ller it's enough to issue just MAKEDEV drm0 if I have one card.

Yes.

r0ller By the way, will it recreate renderD* files as well?

Yes.

r0ller The messages file contains 4 boot processes:
1st: single user mode boot with amdgpu, then reboot
2nd: normal user mode boot with amdgpu, login as root, X crashes
3rd: single user mode boot with amdgpu, then reboot
4th: normal user mode boot with amdgpu, login as root, X running
[...]
The interesting question is: why does the ACPI error show up only when booting in normal user mode and never when booting in single user mode?

I don't get this either. From your messages I see that in single-user mode, the amdgpu drivers are not active. I don't see how that can happen if the drivers are built-in. Are you loading these as modules for the normal boot and not for the single-user ones?

BTW, syslogd is never run in single-user mode, so nothing will ever be written to /var/log/messages in that case. If you happen to reboot from single-user to multi-user, then the previous kernel logs in memory may get preserved and get added to the logs on the subsequent boots.

Better to explicitly collect logs while in single-user mode:

mount -u -w /
dmesg > /root/dmesg.0.txt
mount -u -r /
poweroff                  # ensure memory is cleared.

Can you tell me if the ACPI errors show up without your patch? (Ie. GENERIC with just the amdgpu drivers compiled in.)

EDIT: Here's root's ~/.xinitrc, which I used while testing this stuff. With this, if I do startx as root, I get rvp's X session (as if the user typed startx on the command-line).

#!/bin/sh

xhost +local:
exec su -l rvp -c '
    export DISPLAY=:0
    export PATH=$HOME/bin:/usr/X11R7/bin:$PATH
    . ~/.xinitrc
'

r0ller

Concerning /dev/dri, is it just enough to change the permission of card0 or shall I really delete everything (including renderD* files) in /dev/dri and use makedev? If the latter, I guess it's enough to issue just MAKEDEV drm0 if I have one card. By the way, will it recreate renderD* files as well?

r0ller

rvp

Recompiled the kernel without my hack but with amdgpu still enabled and my findings are as follows:

1) The ACPI error is also reported without my hack when booting in normal user mode but not in single user mode.
2) Starting X in single user mode as root (after mount -a) crashes with unlocking unlocked mutex (remember, my hack is removed). So the ACPI mutex error reported when booting in normal user mode does not seem to have anything to do with that since in single user mode there are no ACPI errors reported.

Concerning xorg.conf, I haven't generated any, I just let the system use the builtin configuration. Shall I generate one as described in https://www.netbsd.org/docs/guide/en/chap-x.html#chap-x-configuration and modify it to use the modesetting driver or amdgpu or anything else?

rvp

r0ller 1) The ACPI error is also reported without my hack when booting in normal user mode but not in single user mode.

Don't see why this should happen. The only difference between single-user and multi-user mode is that in single-user mode, the kernel run init with the -s flag. Might be a warm-boot/cold-boot difference instead. Is it still the same after a physical power-off between SU/MU?

r0ller 2) Starting X in single user mode as root (after mount -a) crashes with unlocking unlocked mutex

I would try, in order:

Updating BIOS (even if there's no newer BIOS, just reflash the current one--that sometimes clears out EFI cruft).
Do a memtest.
File a PR. If this unlocking unlocked mutex error happens only when you exit Xorg (as seems to be the case with @pfr), then the cause should pretty easily be found and fixed by people who know this code.

r0ller nd modify it to use the modesetting driver

Yes. Please try this too.

r0ller

rvp
Didn't have much time so I only tried modesetting in xorg.conf as normal user but it crashed the system. I also added a dri section which I don't know if it's necessary or not:

Section "DRI"
    Group "wheel"
    Mode 0660
EndSection

I'll play around a bit more with xorg.conf. By the way, generating xorg.conf ended up with an error message something like "number of created screens does not match number of detected devices" but it seemed complete in the end so I edited and used that. The strange thing is that even though I have one card (R9 nano) but two were detected (card0 and card1).

pfr

rvp File a PR. If this unlocking unlocked mutex error happens only when you exit Xorg (as seems to be the case with @pfr),

I'm still happy to move forward with this. But as I replied on my other post, I don't really know where to start.

rvp

r0ller Didn't have much time so I only tried modesetting in xorg.conf as normal user but it crashed the system.

This is, by definition, a bug in the kernel: no userspace program should cause a kernel to crash.

r0ller I also added a dri section which I don't know if it's necessary or not

Not needed, I think, but does no harm.

r0ller By the way, generating xorg.conf [...]

Don't need to generate a full xorg.conf these days.