blank screen on startx for kde at kernel 5.10.4

LuckyCyborg · 01-03-2021, 09:58 AM

Quote:

Originally Posted by Z038

When I try sddm from my unprivileged user account, I don't get a login screen.

The SDDM is supposed to be run as root, NOT as unprivileged user.

In fact it is supposed to be run by the runlevel 4 scripts.

Z038 · 01-03-2021, 11:39 AM

That's interesting about sddm. It hardly seems useful if you don't use runlevel 4. I'd never heard of sddm before this thread in fact, possibly because I have only ever used runlevel 3. I'll experiment with runlevel 4 on my laptop when I upgrade it to 15.0. Hopefully that won't be too much longer.

LuckyCyborg · 01-03-2021, 11:52 AM

Quote:

Originally Posted by Z038

That's interesting about sddm. It hardly seems useful if you don't use runlevel 4. I'd never heard of sddm before this thread in fact, possibly because I have only ever used runlevel 3. I'll experiment with runlevel 4 on my laptop when I upgrade it to 15.0. Hopefully that won't be too much longer.

BUT, it is exceptionally useful WHEN you use the runlevel 4.

And many people just uses their boxes for a graphical desktop environment, then having also a graphical login manager makes all the sense on the World.

BGB · 01-04-2021, 10:57 AM

This all works very well EXCEPT:
When screensaver kicks in, all screens & VTs freeze, can still ssh in, X is gone.
This happens whether I leave it on plasma or on VTs

install from --current
3357841408 Dec 29 19:59 slackware64-current-29_Dec_2020-DVD.iso

5.10.3 #1 SMP

messages gives many of these

segfault at c ip 00007ffab2a079b1 sp 00007ffd6413a630 error
4 in libQt5XcbQpa.so.5.15.2[7ffab29d7000+8f000]

ACPI: \_SB_.PCI0.P0P2.GFX0: failed to evaluate _DSM

1) some posts say QT is the problem: Is there any way to tell whether the QT patch noted at
https://forums.gentoo.org/viewtopic-t-1030398-start-0.html
is on the qt5-5.15.2-x86_64-2 in --current?

2) some posts talk about a problem in xproto

3) some posts say that the problem is in kernel 5.10.3

Code:

info: 

x86_64 Intel(R) Core(TM) i5-3470S

        Manufacturer: Apple Inc.
        Product Name: Mac-FC02E91DDD3FA6A4
        Version: iMac13,2

 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GTX 660M Mac Edition] (rev a1)

X.Org X Server 1.20.10
Kernel command line: 
BOOT_IMAGE=dev000:\EFI\Slackware\vmlinuz  root=/dev/sda3 vga=normal ro  nouveau.noaccel=1  irqpoll and intremap=off ro
NOUVEAU(0): Chipset: "NVIDIA NVE7"
[drm] nouveau interface version: 1.3.1


Monitors:  
DP-1 Manufacturer: APP  Model: b005    Builtin 27"
DP-2 Manufacturer: BNQ  Model: 7f44   miniDP - HDMI
DP-3 Manufacturer: GSM  Model: 770d   miniDP - HDMI

bassmadrigal · 01-05-2021, 05:40 PM

Quote:

Originally Posted by Z038

That's interesting about sddm. It hardly seems useful if you don't use runlevel 4. I'd never heard of sddm before this thread in fact, possibly because I have only ever used runlevel 3. I'll experiment with runlevel 4 on my laptop when I upgrade it to 15.0. Hopefully that won't be too much longer.

In many use cases, there is no reason to run a login manager from the console you're already logged in on. You're already logged in as a user on the console and xwmconfig has been used to set the WM/DE you want to start. Simply running startx will do the same thing as what sddm does (with the extra work of typing your username/password and ensuring the proper WM/DE is selected.

sddm and other login managers are designed for use with starting the system to runlevel 4, and would be the first instance where a user is able to log into the system.

Z038 · 01-06-2021, 07:38 AM

Quote:

Originally Posted by BGB

This all works very well EXCEPT:
When screensaver kicks in, all screens & VTs freeze, can still ssh in, X is gone.
This happens whether I leave it on plasma or on VTs

install from --current
3357841408 Dec 29 19:59 slackware64-current-29_Dec_2020-DVD.iso

5.10.3 #1 SMP

messages gives many of these

segfault at c ip 00007ffab2a079b1 sp 00007ffd6413a630 error
4 in libQt5XcbQpa.so.5.15.2[7ffab29d7000+8f000]

ACPI: \_SB_.PCI0.P0P2.GFX0: failed to evaluate _DSM

1) some posts say QT is the problem: Is there any way to tell whether the QT patch noted at
https://forums.gentoo.org/viewtopic-t-1030398-start-0.html
is on the qt5-5.15.2-x86_64-2 in --current?

2) some posts talk about a problem in xproto

3) some posts say that the problem is in kernel 5.10.3

Code:

info: 

x86_64 Intel(R) Core(TM) i5-3470S

        Manufacturer: Apple Inc.
        Product Name: Mac-FC02E91DDD3FA6A4
        Version: iMac13,2

 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GTX 660M Mac Edition] (rev a1)

X.Org X Server 1.20.10
Kernel command line: 
BOOT_IMAGE=dev000:\EFI\Slackware\vmlinuz  root=/dev/sda3 vga=normal ro  nouveau.noaccel=1  irqpoll and intremap=off ro
NOUVEAU(0): Chipset: "NVIDIA NVE7"
[drm] nouveau interface version: 1.3.1


Monitors:  
DP-1 Manufacturer: APP  Model: b005    Builtin 27"
DP-2 Manufacturer: BNQ  Model: 7f44   miniDP - HDMI
DP-3 Manufacturer: GSM  Model: 770d   miniDP - HDMI

That seems a lot different than my circumstances. I did not have segfaults, nor was I using 5.10.3 kernel, nor any indication of QT problems. Also, you have nvidia graphics card, whereas I am using Intel onboard graphics with i915 driver, no separate video card.

You should open a separate thread for your problem because I think it is different from mine.

That said, if X goes away when the screen blanks, don't allow it to blank. Ever. Because if it does, you won't get X back.

Disable screen blanking when at the command line using the commented out line at the bottom of /etc/rc.d/rc.setterm. Just comment out the normal setterm command above it. You want this one to be in effect:

Code:

/bin/setterm -blank 0 -powersave off -powerdown 0

I left my screen locker enabled in plasma, set to display an image, not a blank screeen, when it locks. In plasma settings, disable the Screen Energy Saving option in the Energy Savings tab of the Power Management settings.

Now, you will spend energy rather than save it, and your screen will never go dark, but at least X won't go away. Hope for a fix in a future kernel.

But again, I think the issues you raise deserve their own thread, as they don't seem related to mine, except for the one symptom of X going away.

BGB · 01-06-2021, 09:33 AM

I noticed that there are several different threads going on this, each focusing on GPU. This leads me to suspect that at least some of the common problems ( X freezes or crashes & inability to get back to VTs, related to screen saver/blanker) are either in the X.Org X Server ( not sure if pure Wayland installs are immune to the freezes), ACPI, or kernel based.

I updated
x/mesa-20.3.2-x86_64-1.txz:
kernel-huge-5.10.4-x86_64-1.txz

as well as the setterm change, turning off everything but screen dimming in X and added acpi=off to elilo.conf

So far it is stable. To be nice to my screens, I run

Code:

for i in  DP-1 DP-2 DP-3 ; do
    xrandr --output $i  --brightness .09
done

before I leave... (and then return the brightness to 0.90 for working) not sure if this saves energy though.
---
An observation for other people having this problem:

One interesting thing occasionally happened during my experimentation. Starting sddm or xdm first spews the regular lines of text output, then the X screen flashes on, then I am returned to VT looking like X died. If I try other CTL_ALT_Fn up to 7, I could find X on F2 sometimes, F4 sometimes, and F7 sometimes. I am suggesting that people try 1 to 7 before rebooting. Could it be that there is an off-by-1 or other numeric error and setterm or screensaver are locking the wrong thing? I am not familiar enough with the various levels of the server and VTs etc to know where the state is for these, so I could be pushing on a rope here. I mention this because the more 'signs and symptoms' we have, the better the diagnosis.

Z038 · 01-14-2021, 07:03 AM

This problem went away after I upgraded from the 5.10.4 kernel to the 5.10.6 kernel packages. I no longer lose X when the screen blanks, so I've reverted all my power management settings to their original values.

marcdw · 01-15-2021, 05:47 AM

Interesting. Though I never had any interest in KDE/Plasma I did try it initially when it became available in the updates and I suffered from the same problems. I gave up quickly, finding no solutions.
Will give it another go now and see how I fare.

BGB · 01-15-2021, 02:38 PM

I updated to kernel 5.10.7 and just for safety, reinstalled libdrm libevdev xorg. Other than a bit of background corruption, I have xinerama working properly across 3 2560x1440 screens (one is a 43" 4K TV). Screen saver seems to be ok, and an earlier problem ( something was grabbing the keyboard/graphics so clicking in the display settings window or even Chromium were unusable) having something to do with miniDP or HDP connections, is gone. I still get that behaviour that is different from kdm: I used to run kdm as root from VT1 and it would automagically send me to VT7 which was X. Now I do sddm on VT1, some stdout messages come, X flashes up
and then back to VT1. In the beginning I thought X had failed, but sure enough, there it was on VT7. In the 25 years I have been doing linux, I had never seen that behaviour. Well something new.

enorbet · 01-15-2021, 02:53 PM

Quote:

Originally Posted by BGB

there it was on VT7. In the 25 years I have been doing linux, I had never seen that behaviour. Well something new.

The behaviour is due to sddm.conf which stipulates by default "MinimumVT=7". This is new. The auto-switching works fine with some combinations of hardware and software apparently but fails on some others. I mentioned this months ago and was told it is some odd hardware thing but that's not the whole issue nor is it uncommon. LiveSlak for example, auto-switches no problem but every install, even from a full iso, to storage, fails to auto-switch. I have to either hit "Alt-F7" or edit sddm.conf back to "MinimumVT=1". It really should be noted in docs since there seems to be a lot of posts about new installs and upgrades exhibiting this puzzling behaviour.

louigi600 · 01-16-2021, 02:20 AM

If you boot with your previous kernel does everything work as before ?
When I install new kernels I always configure the bootloader to give me an option for booting with old kernel just in case the new kernel has something so bad that it makes it difficult to go back without using another boot media. It just happened that once away in a trip (pre smartphone era) I decided to compile a new kernel, I did something wrong with the setup and kernel panicked before I could get a prompt: as a result I had no computer until I got back home some 2 weeks later.

In the following example I not only have the old kernel but even an option for booting a stock kernel from current:

Code:

root@nuc8i5:~# cat /boot/efi/EFI/Slackware/elilo.conf 
prompt
timeout=30
default=Slackware
#
image=4.19.167
        label=Slackware
        read-only
        append="root=/dev/sda4 vga=normal ro"
image=4.19.166
        label=Old
        read-only
        append="root=/dev/sda4 vga=normal ro"
image=5.10.6-huge
        label=5
        read-only
        append="root=/dev/sda4 vga=normal ro"
root@nuc8i5:~#

BGB · 01-17-2021, 11:00 AM

I just use the upgraded kernel to keep things simple. This is a 'production' machine so I like more deterministic settings than experimental. Whatever the causes or interactions that are making X and wayland unstable, they seem to be affecting a wide range of hardware, and also exposing weaknesses in some other 'drivers' ... glad I no longer have the dreaded i810 or i915. The latter seems to be especially vulnerable to whatever is going on.

As with most-things HDMI, people (me included) need to remember to check problems with different cables. The early days of USB were like this. Cheapo cables sometimes were no problem and other times caused intermittent grief. At the same time, there seem to be outrageously expensive cables that I am not sure are any benefit.

I also noticed (in trying to get a DisplayLink adapter going) that HDMI audio seems to be a problem: if the audio pins? or protocols? report errors, this sometimes takes the video link down with it. I would prefer a dialog or log in such a case that says: Video link OK, Audio link Failed, proceeding with Video only. After all, for Monitors, the HDMI audio is less critical than actually getting video in some cases.

At least I have a somewhat stable system at this point.

But:
1) Screensaver and Sleep are still broken
2) "NOUVEAU(0): Backing store disabled" which is very ugly.
3) (EE) NOUVEAU(0): failed to set mode: Permission denied [ has something to do with VTs I think ]
4) (WW) NOUVEAU(0): Option "DPI" is not used
(WW) NOUVEAU(0): Option "PreferredMode" is not used
which means using xrandr to kick the 4K tv to at 2160x1440
5) many USB devices are "tagged by udev as: Keyboard" which may be innocuous

I am slowing trying to solve each of these. As usual, WW and EE and other log messages are like body pain... something might be really bad, or just a mild reminder. The trick is to figure out which.

BGB · 01-20-2021, 05:54 PM

Well, something new ...

[ 4854.797059] ------------[ cut here ]------------
[ 4854.797094] WARNING: CPU: 1 PID: 6931 at drivers/gpu/drm/nouveau/nvif/vmm.c:68 nvif_vmm_put+0x6a/0x80 [nouveau]
[ 4854.797112] Modules linked in: fuse udp_diag ipv6 tcp_diag inet_diag tun 8021q garp mrp stp llc efivarfs btusb btrtl btbcm btintel bluetooth ecdh_generic ecc cdc_mbim cdc_wdm cdc_ncm cdc_ether usbnet mii uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev apple_mfi_fastcharge hid_generic snd_usb_audio snd_usbmidi_lib snd_rawmidi usbhid snd_seq_device uas mc hid usb_storage b43 cordic intel_rapl_msr intel_rapl_common mac80211 cfg80211 x86_pkg_temp_thermal ssb intel_powerclamp rfkill pcmcia pcmcia_core at24 nouveau regmap_i2c coretemp kvm_intel mxm_wmi wmi mei_hdcp evdev ttm snd_hda_codec_cirrus kvm snd_hda_codec_generic irqbypass ledtrig_audio applesmc drm_kms_helper crct10dif_pclmul crc32_pclmul snd_hda_codec_hdmi ghash_clmulni_intel drm snd_hda_intel snd_intel_dspcfg rapl soundwire_intel soundwire_generic_allocation intel_cstate agpgart i2c_algo_bit i2c_i801 snd_soc_core sdhci_pci snd_compress i2c_smbus snd_pcm_dmaengine fb_sys_fops soundwire_cadence cqhci
[ 4854.797152] syscopyarea lpc_ich sysfillrect sdhci snd_hda_codec sysimgblt tg3 mmc_core thunderbolt libphy snd_hda_core i2c_core bcma snd_hwdep xhci_pci snd_pcm xhci_pci_renesas snd_timer snd acpi_als kfifo_buf soundcore ac97_bus industrialio xhci_hcd mei_me video mei ehci_pci ehci_hcd apple_bl button loop
[ 4854.797169] CPU: 1 PID: 6931 Comm: kworker/1:0 Not tainted 5.10.8 #1
[ 4854.797170] Hardware name: Apple Inc. iMac13,2/Mac-FC02E91DDD3FA6A4, BIOS 281.0.0.0.0 09/17/2018
[ 4854.797205] Workqueue: events nouveau_cli_work [nouveau]
[ 4854.797226] RIP: 0010:nvif_vmm_put+0x6a/0x80 [nouveau]
[ 4854.797245] Code: 00 00 48 89 e2 be 02 00 00 00 48 c7 04 24 00 00 00 00 48 89 44 24 08 e8 04 e3 ff ff 85 c0 75 0a 48 c7 43 08 00 00 00 00 eb b7 <0f> 0b eb f2 e8 bd c1 80 cd 66 66 2e 0f 1f 84 00 00 00 00 00 66 90
[ 4854.797246] RSP: 0018:ffffb3d9852a7de8 EFLAGS: 00010282
[ 4854.797248] RAX: 00000000fffffffe RBX: ffffb3d9852a7e10 RCX: 0000000000000000
[ 4854.797248] RDX: 0000000000000010 RSI: ffffb3d9852a7d58 RDI: ffffb3d9852a7df8
[ 4854.797249] RBP: ffff8ef026f00200 R08: 00000000fffffffe R09: 0000000000000000
[ 4854.797250] R10: 0000000000000030 R11: 0000000000000018 R12: dead000000000122
[ 4854.797251] R13: dead000000000100 R14: ffff8eefe9752180 R15: ffff8eefe9752660
[ 4854.797252] FS: 0000000000000000(0000) GS:ffff8ef517280000(0000) knlGS:0000000000000000
[ 4854.797253] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 4854.797253] CR2: 0000000001b5f548 CR3: 0000000285aba001 CR4: 00000000001706e0
[ 4854.797254] Call Trace:
[ 4854.797290] nouveau_vma_del+0x78/0xb0 [nouveau]
[ 4854.797323] nouveau_gem_object_delete_work+0x36/0x60 [nouveau]
[ 4854.797367] nouveau_cli_work+0xbb/0x110 [nouveau]
[ 4854.797390] process_one_work+0x1d4/0x370
[ 4854.797392] worker_thread+0x4d/0x3d0
[ 4854.797394] ? rescuer_thread+0x3d0/0x3d0
[ 4854.797396] kthread+0x11b/0x140
[ 4854.797398] ? __kthread_bind_mask+0x60/0x60
[ 4854.797401] ret_from_fork+0x22/0x30
[ 4854.797403] ---[ end trace 7ac2e6a98b37c690 ]---
[ 6577.668830] snd_hda_codec_hdmi hdaudioC1D0: HDMI: pin nid 6 not registered
[52250.378919] snd_hda_codec_hdmi hdaudioC1D0: HDMI: pin nid 6 not registered
[52250.412123] nouveau 0000:01:00.0: DRM: Failure to read SCDC_TMDS_CONFIG: -6
[58250.295583] snd_hda_codec_hdmi hdaudioC1D0: HDMI: pin nid 6 not registered
[59387.075899] snd_hda_codec_hdmi hdaudioC1D0: HDMI: pin nid 6 not registered
[59387.108203] nouveau 0000:01:00.0: DRM: Failure to read SCDC_TMDS_CONFIG: -6
[69279.911669] snd_hda_codec_hdmi hdaudioC1D0: HDMI: pin nid 6 not registered
[69483.665470] snd_hda_codec_hdmi hdaudioC1D0: HDMI: pin nid 6 not registered
[69483.697941] nouveau 0000:01:00.0: DRM: Failure to read SCDC_TMDS_CONFIG: -6
[74102.535556] snd_hda_codec_hdmi hdaudioC1D0: HDMI: pin nid 6 not registered
[74691.871179] snd_hda_codec_hdmi hdaudioC1D0: HDMI: pin nid 6 not registered
[74691.903397] nouveau 0000:01:00.0: DRM: Failure to read SCDC_TMDS_CONFIG: -6
[79723.803683] snd_hda_codec_hdmi hdaudioC1D0: HDMI: pin nid 6 not registered
[80934.302116] snd_hda_codec_hdmi hdaudioC1D0: HDMI: pin nid 6 not registered
[80934.334491] nouveau 0000:01:00.0: DRM: Failure to read SCDC_TMDS_CONFIG: -6
[84655.384310] nouveau 0000:01:00.0: fifo: fault 00 [READ] at 000000001521d000 engine 1b [CE2] client 18 [HUB/GR_CE] reason 02 [PTE] on channel 2 [001f9f5000 Xorg[1356]]
[84655.384324] nouveau 0000:01:00.0: fifo: channel 2: killed
[84655.384326] nouveau 0000:01:00.0: fifo: runlist 0: scheduled for recovery
[84655.384335] nouveau 0000:01:00.0: fifo: engine 7: scheduled for recovery
[84655.384343] nouveau 0000:01:00.0: Xorg[1356]: channel 2 killed!

and poof, X restarts.

X.Org X Server 1.20.10
X Protocol Version 11, Revision 0
[ 84656.006] Build Operating System: Slackware 15.0 Slackware Linux Project
[ 84656.006] Current Operating System: Linux macabre.upstairs.net 5.10.8 #1 SMP Sun Jan 17 12:54:46 CS