| View previous topic :: View next topic |
| Author |
Message |
Randy Andy
Veteran
Joined: 19 Jun 2007
Posts: 1152
Location: /dev/koelsch
|
 Posted: Sun Nov 17, 2024 7:30 pm Post subject: Wayland-login → Mice & keyboard not responsive until... |
 |
|
Hello fellow campaigners,
I could probably use a little help or inspiration from you, because I've been fiddling for a week now, including upgrading Profle, switching to bin-packages, updating to the latest version of Kde/Plasma and using Wayland for the first time, with the following remaining problems that I just can't get under control.
I attribute the problems to my NVIDIA graphics card (Quadro FX 4800) codenamed NVA0 (GT200) GL, NV50 family (Tesla).
Since the nvidia-drivers-340.108 driver support is pretty scary, I'm trying the Nouveau driver again and it's almost working fine.
Until about a year ago, however, it ran much better under X11 than now, with the latest Xorg versions, so I really don't want to use it anymore. The delay when clicking on a desktop icon or a hot corner sometimes takes several seconds or several clicks until something happens.
Although X11 and Wayland give me the same FPS rate, the response time under wayland is much better so I would want to work with it if I could fix the following last problems:
When I log into Plasma under Wayland, my mouse and keyboard work with a delay of about 5 seconds! I don't have these problems under X11! This is absolutely reproducible here.
During the delay, Glxgears now gives me the following reduced frame rates under Wayland:
| Code: |
$ glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
12 frames in 5.1 seconds = 2.364 FPS
7 frames in 5.0 seconds = 1.396 FPS
5 frames in 5.0 seconds = 0.996 FPS
7 frames in 8.0 seconds = 0.873 FPS
5 frames in 6.1 seconds = 0.826 FPS
7 frames in 5.0 seconds = 1.392 FPS
X connection to :1 broken (explicit kill or server shutdown). |
As long as the delay lasts I see in dmesg:
| Code: | | nouveau 0000:02:00.0: DRM: base-0: timeout |
Only when I press Ctrl. + Alt + F1 to switch to a TTY console and then back to the X terminal, the delays stop and everything becomes responsive as it should be.
After that glxgears gives:
| Code: |
$ glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
143 frames in 5.0 seconds = 28.510 FPS
140 frames in 5.0 seconds = 27.830 FPS
140 frames in 5.0 seconds = 27.831 FPS
140 frames in 5.0 seconds = 27.836 FPS
X connection to :1 broken (explicit kill or server shutdown). |
In dmesg I see then:
| Code: |
235.921635] ------------[ cut here ]------------
[ 235.921639] WARNING: CPU: 3 PID: 2439 at drivers/gpu/drm/nouveau/dispnv50/disp.c:213 nv50_dmac_wait+0x181/0x230 [nouveau]
[ 235.921732] Modules linked in: bnep bluetooth ecdh_generic ecc nouveau vboxnetflt(OE) vboxnetadp(OE) drm_ttm_helper ttm drm_kms_helper syscopyarea sysfillrect sysimgblt vboxdrv(OE) fb_sys_
fops drm drm_panel_orientation_quirks cfbfillrect cfbimgblt cfbcopyarea i2c_algo_bit fb fbdev
[ 235.921749] CPU: 3 PID: 2439 Comm: kworker/u64:13 Tainted: G IOE 5.15.169-gentoo-x86_64 #1
[ 235.921751] Hardware name: Dell Inc. Precision WorkStation T3500 /09KPNV, BIOS A17 05/28/2013
[ 235.921753] Workqueue: events_unbound nv50_disp_atomic_commit_work [nouveau]
[ 235.921836] RIP: 0010:nv50_dmac_wait+0x181/0x230 [nouveau]
[ 235.921919] Code: 8d 48 04 48 89 4a 68 c7 00 00 00 00 20 49 8b 45 38 41 c7 85 20 01 00 00 00 00 00 00 49 89 45 68 e8 34 fd ff ff e9 d0 fe ff ff <0f> 0b b8 92 ff ff ff e9 4e ff ff ff 41 8b
85 24 01 00 00 85 c0 74
[ 235.921921] RSP: 0018:ffffab620075fd68 EFLAGS: 00010282
[ 235.921923] RAX: ffffffffffffff92 RBX: 000000000000000d RCX: 0000000000000000
[ 235.921925] RDX: 0000000000000001 RSI: ffffab620075fca8 RDI: ffffab620075fd48
[ 235.921926] RBP: ffffab620075fd68 R08: 0000000000000000 R09: ffffab62000e57f8
[ 235.921927] R10: 00000000000007ff R11: 0000000000000006 R12: 00000000fffffffb
[ 235.921928] R13: ffff9890bbf85bb0 R14: ffff9890ec2e7000 R15: ffff9890ec2e7800
[ 235.921930] FS: 0000000000000000(0000) GS:ffff9893cd6c0000(0000) knlGS:0000000000000000
[ 235.921932] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 235.921933] CR2: 000055ce3bffa150 CR3: 0000000101810004 CR4: 00000000000206e0
[ 235.921935] Call Trace:
[ 235.921938] <TASK>
[ 235.921940] ? __warn+0x81/0x100
[ 235.921946] ? nv50_dmac_wait+0x181/0x230 [nouveau]
[ 235.922028] ? report_bug+0x99/0xc0
[ 235.922033] ? handle_bug+0x34/0x80
[ 235.922037] ? exc_invalid_op+0x13/0x60
[ 235.922039] ? asm_exc_invalid_op+0x16/0x20
[ 235.922043] ? nv50_dmac_wait+0x181/0x230 [nouveau]
[ 235.922125] ? nv50_dmac_wait+0x7f/0x230 [nouveau]
[ 235.922208] base827c_image_set+0x2f/0x1d0 [nouveau]
[ 235.922289] nv50_wndw_flush_set+0x88/0x1c0 [nouveau]
[ 235.922371] nv50_disp_atomic_commit_tail+0x50d/0x7c0 [nouveau]
[ 235.922455] process_one_work+0x1d5/0x380
[ 235.922459] worker_thread+0x4d/0x3b0
[ 235.922462] ? process_one_work+0x380/0x380
[ 235.922464] kthread+0x118/0x140
[ 235.922467] ? set_kthread_struct+0x50/0x50
[ 235.922470] ret_from_fork+0x22/0x30
[ 235.922474] </TASK>
[ 235.922475] ---[ end trace f0f29a9fae92ddf0 ]---
[ 237.922554] ------------[ cut here ]------------
|
and that of course for all CPUs of my machine.
If I decode the above message, I got:
| Code: |
# sh /usr/src/linux/tools/debugging/kernel-chktaint
Kernel is "tainted" for the following reasons:
* kernel issued warning (#9)
* workaround for bug in platform firmware applied (#11)
* externally-built ('out-of-tree') module was loaded (#12)
* unsigned module was loaded (#13)
For a more detailed explanation of the various taint flags see
Documentation/admin-guide/tainted-kernels.rst in the Linux kernel sources
or https://kernel.org/doc/html/latest/admin-guide/tainted-kernels.html
Raw taint value as int/string: 14848/'G W IOE '
|
The only out of tree module I’m using, is (acc. to lsmod):
| Code: | | vboxdrv 540672 2 vboxnetadp,vboxnetflt |
of the package: app-emulation/virtualbox-modules
I tried to leave it out completely, and in version-7.0.20, and now in vesion 6.1.50-r3, because I’ve got the subjective impression, that its a bit more unproblematic while switching to tty and back to X-term, regarding freezing, because that seems to be the most critical operation to get my wayland session running.
The dist-kernel or a genkernel of 6.6.58 freezes here more often while switching than different types of my self configured kernels, without initramfs, thats why I’m using this more likely.
I tried lots of different combinations regarding nouveau only or in combinations with fbdev, VGA.
Prop. NVIDIA leaving completetely out of tree for this trials here.
Starting wayland from console with the help of:
$ dbus-run-session startplasma-wayland or
$ dbus-launch –exit-with-session startplasma-wayland
makes no difference in this misbebaviour.
Some more information from mine to your hands:
Using: OpenRC, sddm, kwin, kde-plasma/plasma-meta-6.1.5, (whole world on latest stable.)
selected profile: [49] default/linux/amd64/23.0/split-usr/no-multilib (stable) *
emerge --info https://bpa.st/VDUQ
Xorg.0.log https://bpa.st/CUIQ
glxinfo https://bpa.st/4F4A
What could be the root cause of this delays or whta could be a fix or at least a good workaround for this?
_________________
If you want to see a Distro done right, compile it yourself! |
|
| Back to top |
|
 |
Randy Andy
Veteran
Joined: 19 Jun 2007
Posts: 1152
Location: /dev/koelsch
|
|
| Back to top |
|
|
rab0171610
Guru
Joined: 24 Dec 2022
Posts: 478
|
| Posted: Sat Nov 23, 2024 4:33 pm Post subject: |
|
|
| Is there a reason that investing in a newer - even if slightly used - graphics card that is not using legacy drivers or reached the EOL/End of Life status not an option? There are a lot of factors at play in your posts, but it is also possible that the video card itself is not performing well after so many years. Some problems are just not worth all the time and headache involved when trying to extend the lifespan of antiquated hardware. I understand the need to milk every last ounce of value out of computer components but there is also a time to know when to let it go. This might be the time. The legacy Nvidia driver is eventually going to disappear. |
|
| Back to top |
|
|
Randy Andy
Veteran
Joined: 19 Jun 2007
Posts: 1152
Location: /dev/koelsch
|
| Posted: Sun Nov 24, 2024 10:55 am Post subject: |
|
|
Hi rab0171610,
what's more, the graphics card still works perfectly.
I can say that with certainty because I still have older Btrfs snapshots of my previous versions here, where the card is still performant and stable with the prop. Nvidia parts.
It also still offers enough performance reserves for me. After all, this is not some cheap consumer card, of which I have had to throw away quite a few in the last few years, be it because of burst cheap capacitors or defective fan bearings - keyword planned obsolescence! Take a look at the specs and the original price of the cards:
https://www.techpowerup.com/gpu-specs/quadro-fx-4800.c1320
The supported resolution and their interfaces are also still absolutely up to date:
| Code: |
xrandr -q
Screen 0: minimum 16 x 16, current 3440 x 1440, maximum 32767 x 32767
DP-2 connected primary 3440x1440+0+0 (normal left inverted right x axis y axis) 797mm x 334mm
3440x1440 59.94*+
1920x1440 59.97
1600x1200 59.87
1440x1080 59.99
1400x1050 59.98
1280x1024 59.89
1280x960 59.94
1152x864 59.96
1024x768 59.92
800x600 59.86
640x480 59.38
320x240 59.52
1920x1200 59.88
1680x1050 59.95
1440x900 59.89
1280x800 59.81
1152x720 59.97
960x600 59.63
928x580 59.88
800x500 59.50
768x480 59.90
720x480 59.71
640x400 59.95
320x200 58.96
2560x1440 59.96
2048x1152 59.90
1920x1080 59.96
1600x900 59.95
1368x768 59.88
1280x720 59.86
1024x576 59.90
864x486 59.92
720x400 59.55
640x350 59.77 |
But even with the older Nouveau and X11 versions, it still ran significantly better performance than since my last big upgrade. In this respect, the problems for me are home-made and because the older ebulds have been removed far too quickly for my taste in the tree for some time, it is not so easy to downgrade to find out which package could be responsible for this.
This also seems a bit like planned obsolescence, only on a software basis. 
That's why it now runs fast enough under Wayland and is now usable in contrast to X11. But it is damn annoying and tricky to get it running without mouse and keyboard lock. However, if it works, it remains stable for days until the next reboot, then the fiddling starts all over again.
But actually I'm more interested in technical solutions (buf fixing) than in a discussion of principles. Besides, there seem to be enough others with newer hardware who have similar problems, especially under Wayland.
Maybe it's also due to Plasma under Qt6 or the Java VM, I don't know...
Maybe it's time to change the desktop again, let's see what the performance says then...
I also tried it with Lightdm or completely without greeter and display manager - but it doesn't seem to help here either.
However, I have noticed that depending on the sddm.conf used, e.g. from the wiki, the problems increase, e.g. black screen instead of the log in screen.
_________________
If you want to see a Distro done right, compile it yourself! |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
