Display goes black.
yutiao
Status: New User - Welcome
Joined: 21 Jan 2022
Posts: 1
Reply Quote
Hi all.
New Liqourix user. Running a system with a 6800xt and using amdgpu driver. After installing with no errors, I rebooted. After reboot, the monitor goes black once I'm passed the grub boot screen. Sometimes it goes black right away, other times it gives me enough time to decrypt LUKS. Never enough time to get log in or get even close. I experienced this problem a while back on a regular mainline kernel, but it was fixed when I went to version 5.14.x. Sorry I don't have many details, I'm new to debugging this, but I can provide any info requested.
Back to top
damentz
Status: Assistant
Joined: 09 Sep 2008
Posts: 1135
Reply Quote
Sounds like some strange kernel / distribution mismatch. I run a 6700xt and it works just fine.

Please provide the output of inxi -SCGMx on a working kernel.
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4127
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
One suspects that the use of LUKS is introducing an entire area of possible failures to the start of x.

If I were to speculate, I'd speculate that it might be a timing issue, that is, the moments when xorg tries to load, vs when the LUKS stuff tries to run to unlock the partition. The fact that it varies slightly suggest that might be what is going on.

In this case, inxi -Fxz is more useful since there are many areas that might be creating issues, graphics, cpu, system, the info item, with init system, or partitions.

Note that drive types are also relevant in this, which is why you want to show inxi -Fxz.

Using LUKS certainly absolutely maximizes both the places you can get failures, and the difficultly of diagnosing issues, since it grows increasingly difficult for kernel developers to reproduce the issue since it's so specific to the exact setup you have.
Back to top
yutiao2
Status: New User - Welcome
Joined: 24 Jan 2022
Posts: 1
Reply Quote
:: techAdmin wrote ::
One suspects that the use of LUKS is introducing an entire area of possible failures to the start of x.

Yes this very well could be a contributing factor, however I do not use a display manager, instead I boot right into tty1. On certain attempts, I haven't had enough time to even see the decryption prompt from LUKS before the signal dies. And when I say signal dies -- I mean the monitor stops receiving video input, not just a black screen.

That said, here is the output of inxi -Fxz on a fully working kernel. This is just a mainline kernel I compiled with a few tweaks (preempt-rt, 1000hz clock) a few months back. Relevant info, on bootup with this kernel after selecting it in grub there is a quick flash of a black screen with teal lines down the middle, looks like a graphics/driver error but it goes away within a second and everything functions normally. I tried the boot parameter `amdgpu.dpm=0` to liquorix and instead of the video signal dying, it just hung on the aforementioned black screen with teal lines indefinitely.

:: Code ::

System:    Kernel: 5.14.14+ x86_64 bits: 64 compiler: gcc v: 10.2.1 Desktop: bspwm 0.9.10
           Distro: Debian GNU/Linux 11 (bullseye)
Machine:   Type: Desktop System: Micro-Star product: MS-7D13 v: 1.0 serial: <filter>
           Mobo: Micro-Star model: MEG B550 UNIFY (MS-7D13) v: 1.0 serial: <filter> UEFI: American Megatrends LLC. v: 1.24
           date: 04/08/2021
Battery:   ID-1: hidpp_battery_0 charge: N/A condition: N/A model: Logitech G Pro Wireless Gaming Mouse status: Discharging
CPU:       Info: 12-Core model: AMD Ryzen 9 5900X bits: 64 type: MT MCP arch: Zen 3 rev: 0 L2 cache: 6 MiB
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 177610
           Speed: 3599 MHz min/max: 2200/3700 MHz boost: enabled Core speeds (MHz): 1: 3599 2: 3730 3: 3594 4: 3597 5: 3592
           6: 3592 7: 3595 8: 3593 9: 3582 10: 3630 11: 3716 12: 3598 13: 3599 14: 3598 15: 3597 16: 3601 17: 3592 18: 3597
           19: 3598 20: 3600 21: 3591 22: 3601 23: 3598 24: 3693
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] Navi 21 [Radeon RX 6800/6800 XT / 6900 XT] vendor: Micro-Star MSI
           driver: amdgpu v: kernel bus ID: 2d:00.0
           Display: server: X.Org 1.20.11 driver: loaded: amdgpu resolution: 2560x1600~60Hz
           OpenGL: renderer: AMD Radeon RX 6800 XT (SIENNA_CICHLID DRM 3.42.0 5.14.14+ LLVM 11.0.1) v: 4.6 Mesa 20.3.5
           direct render: Yes
Audio:     Device-1: Advanced Micro Devices [AMD/ATI] driver: N/A bus ID: 2d:00.1
           Device-2: Logitech HD Pro Webcam C920 type: USB driver: snd-usb-audio,uvcvideo bus ID: 3-4:3
           Device-3: Focusrite-Novation Scarlett 4i4 USB type: USB driver: snd-usb-audio bus ID: 3-3:6
           Sound Server: ALSA v: k5.14.14+
Network:   Device-1: Intel Wi-Fi 6 AX200 driver: iwlwifi v: kernel bus ID: 29:00.0
           IF: wlo1 state: down mac: <filter>
           Device-2: Realtek RTL8125 2.5GbE vendor: Micro-Star MSI driver: r8169 v: kernel port: f000 bus ID: 2a:00.0
           IF: enp42s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Bluetooth: Device-1: Intel AX200 Bluetooth type: USB driver: btusb v: 0.8 bus ID: 1-10:7
           Report: ID: hci0 state: down address: <filter>
RAID:      Device-1: tank type: zfs status: ONLINE level: mirror size: 7.27 TiB free: 4.11 TiB
           Components: Online: 1: sda 2: sdb
Drives:    Local Storage: total: raw: 15.46 TiB usable: 8.18 TiB used: 3.46 TiB (42.3%)
           ID-1: /dev/nvme0n1 vendor: Samsung model: SSD 970 EVO 1TB size: 931.51 GiB
           ID-2: /dev/sda vendor: Western Digital model: WD80EFAX-68KNBN0 size: 7.28 TiB temp: 31 C
           ID-3: /dev/sdb vendor: Western Digital model: WD80EFAX-68KNBN0 size: 7.28 TiB temp: 31 C
Partition: ID-1: / size: 41.2 GiB used: 26.48 GiB (64.3%) fs: ext4 dev: /dev/dm-2 mapped: navi-root
           ID-2: /boot size: 474 MiB used: 258.2 MiB (54.5%) fs: ext4 dev: /dev/nvme0n1p2
           ID-3: /boot/efi size: 511 MiB used: 3.4 MiB (0.7%) fs: vfat dev: /dev/nvme0n1p1
           ID-4: /home size: 847.96 GiB used: 272.87 GiB (32.2%) fs: ext4 dev: /dev/dm-5 mapped: navi-home
           ID-5: /tmp size: 3.86 GiB used: 96 KiB (0.0%) fs: ext4 dev: /dev/dm-4 mapped: navi-tmp
           ID-6: /var size: 13.78 GiB used: 7.96 GiB (57.8%) fs: ext4 dev: /dev/dm-3 mapped: navi-var
Swap:      ID-1: swap-1 type: partition size: 8 GiB used: 0 KiB (0.0%) dev: /dev/dm-1 mapped: navi-swap
Sensors:   System Temperatures: cpu: 34.6 C mobo: N/A gpu: amdgpu temp: 40.0 C
           Fan Speeds (RPM): N/A gpu: amdgpu fan: 245
Info:      Processes: 647 Uptime: 2d 2h 48m Memory: 31.28 GiB used: 4.38 GiB (14.0%) Init: systemd runlevel: 5 Compilers:
           gcc: 10.2.1 Packages: 4184 Shell: Zsh v: 5.8 inxi: 3.3.01

Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4127
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
sudo inxi -LRDpzay

Will break it down more, that will include logical disk data, which includes LUKS stuff, at least it should.

particularly with nvme, it would depend which parts are encrypted, looks like HOME is on a spinning disk, but if root is encrypted, it would be mounting massively faster than home I believe, and that makes me suspicious, I suspected there would be some very fast drives involved.

Damentz would have to confirm this, but I wonder if some of the liquorix performance optimizaitons might not clash with certain more obscure situations like something slightly hanging on mount, just long enough to make LUKS fail. That's just a guess, I've seen some I/O stuff have issues before, but he's not using that scheduler anymore, but there might be issues with the scheduler he's using now in relation to LUKS disk mounts, that's a very fragile setup I'd say.

Oddly, and probably totally not related, I've had a few failures to show anything on the monitor when resuming from suspend on liquorix, I never mentioned it since wake from suspend tends to glitch now and then, but I wonder if there's a relationship there since in a sense it's a similar failure, no data going to monitors at all, forcing reboot, which in my case fixes it since then it's not wake from ram, but a normal boot.

Oh, I had also missed you are using zfs raid 0, now you've really maxed your odds of failure, it's actually not a surprise to me that you are getting failures there. So raid has to load, luks has to load, xorg has to load, and my guess is, one of those just runs too fast, maybe due to nvme speeds, and the kernel just loses that instant detection requirement due maybe to some scheduler issues, that's my guess, but damentz can say better.

But the debugging odds there drop, 3rd party zfs fs kernel module with a very heavy ram intensive file system running software raid, luks encryption, and a performance oriented kernel that makes certain compromises to gain desktop performance, that's probably not the most optimal setup in the world.

My guess is that the system starts to load, but loads way too fast due to nvme, the spinning disks are lagging, zfs lags, and then the moment when luks had to be activated/de-encrypted comes, but it's too late, the kernel has lost track.
Back to top
damentz
Status: Assistant
Joined: 09 Sep 2008
Posts: 1135
Reply Quote
So, two major updates are coming up that might resolve your issue.

1) 5.15.17 is gearing to be a huge stable update with 19 AMD patches, the majority for AMD GPUs, the rest for AMD chipsets/CPUs.

2) This weekend I'll be upgrading Liquorix to 5.16, that may also have something in there that'll fix the weirdness on your system.

I don't really have any other advice for you. The other things about your system shouldn't cause the issue you're having. I use full disk encryption on one device of mine with Liquorix and I have no issues, but it is an Intel system (CPU + iGPU).

You can also try booting with loglevel=7, hopefully you get some type of screen output that tells you what's wrong.
Back to top
damentz
Status: Assistant
Joined: 09 Sep 2008
Posts: 1135
Reply Quote
Liquorix is on kernel 5.16 now, did anything improve for you?
Back to top
Display posts from previous:   

All times are GMT - 8 Hours