I'm pretty sure there's another bug on this, but I can't seem to find it. The plasma panel starts out responding fine, but at some point in the session it will become unresponsive. It seems that all window events are being ignored, because the digital clock stops updating as well as the panel being unresponsive to the mouse. This has been happening for months, but up until about a week ago you could unfreeze the panel by switching to a tty and back again. No more. You now have to logout and login to get the panel back, which requires that all your running apps get aborted. This seems to affect only the panel; the desktop and the apps continue to respond, and CTRL-ALT-DEL allows logout.
Additional info: icons on the desktop are similarly unresponsive (won't launch, don't respond to right-click).
Also, the desktop itself doesn't respond to right-click.
CC: (none) => marja11Assignee: bugsquad => kde
Hello, Confirmed in Cauldron : $ rpm -qa | grep plasma plasma-integration-5.8.5-2.mga6 lib64kf5plasma5-5.29.0-1.mga6 lib64plasma3-4.14.27-2.mga6 plasma-framework-5.29.0-1.mga6 plasma-workspace-5.8.5-3.mga6 lib64plasmaweather1-5.8.5-1.mga6 lib64plasma-geolocation-interface5-5.8.5-3.mga6 plasma-pa-5.8.5-1.mga6 plasma-desktop-5.8.5-2.mga6 mageia-plasma5-config-6-28.mga6 lib64kf5plasmaquick5-5.29.0-1.mga6 lib64plasmacomicprovidercore1-5.8.5-1.mga6 task-plasma5-minimal-5.8.5-1.mga6 kdeplasma-addons-5.8.5-1.mga6 I filled a bug upstream as Neoclus suggested : https://bugs.kde.org/show_bug.cgi?id=374857 Regards, Maât
CC: (none) => maat-ml
Isn't it a duplicate of bug 19869 which is prominently visible on the release blockers page http://madb.mageia.org/tools/blockers ?
(In reply to Samuel Verschelde from comment #4) > Isn't it a duplicate of bug 19869 which is prominently visible on the > release blockers page http://madb.mageia.org/tools/blockers ? Ok, bug 19869 is not assigned to KDE team since it's not plasma's fault actually, so that explains why it was missed. Maat, there's already a bug report upstream too, linked from bug 19869, so you might want to close it as duplicate also. *** This bug has been marked as a duplicate of bug 19869 ***
Resolution: (none) => DUPLICATEStatus: NEW => RESOLVED
Still happening for Frank, probably not a duplicate of bug 19869 then.
Resolution: DUPLICATE => (none)Status: RESOLVED => REOPENED
Frank, can you confirm that switching to a tty and back again still doesn't fix it for you? Do you have anything in the system and XOrg logs when it happens?
Status: REOPENED => NEW
I'm pretty sure the tty switch doesn't fix it, but I'll retry the next time it happens, and check the logs as well.
From Xorg.0.log: [ 80401.892] (II) Axis 0x1 value 988 is outside expected range [1233, 5076] See https://wayland.freedesktop.org/libinput/doc/1.5.3//absolute_coordinate_ranges.html for details [ 80701.119] (EE) libinput bug: invalid tap event when fingers are up [ 80701.132] (EE) libinput bug: invalid tap event when fingers are up [ 80701.168] (EE) libinput bug: invalid tap event when fingers are up [ 80701.180] (EE) libinput bug: invalid tap event when fingers are up [ 81696.829] (EE) libinput bug: invalid tap event when fingers are up [ 86505.145] (EE) libinput bug: invalid tap event when fingers are up [ 86832.836] (II) Axis 0x1 value 971 is outside expected range [1233, 5076] See https://wayland.freedesktop.org/libinput/doc/1.5.3//absolute_coordinate_ranges.html for details From journalctl: Jan 14 19:15:01 ftglap crond[32674]: (/usr/bin/python) ERROR (getpwnam() failed) Jan 14 19:15:04 ftglap plasmashell[5761]: QXcbConnection: XCB error: 17 (BadImplementation), sequence: 16150, resource id: 50331678, major code: 147 (Unknown), minor code: 2 Jan 14 19:15:04 ftglap plasmashell[5761]: QXcbConnection: XCB error: 9 (BadDrawable), sequence: 16151, resource id: 50331992, major code: 147 (Unknown), minor code: 4 Jan 14 19:15:04 ftglap plasmashell[5761]: QXcbConnection: XCB error: 4 (BadPixmap), sequence: 16152, resource id: 50331992, major code: 146 (Unknown), minor code: 1 Jan 14 19:15:04 ftglap plasmashell[5761]: QXcbConnection: XCB error: 17 (BadImplementation), sequence: 16153, resource id: 50331678, major code: 147 (Unknown), minor code: 2 Jan 14 19:15:04 ftglap plasmashell[5761]: QXcbConnection: XCB error: 9 (BadDrawable), sequence: 16154, resource id: 50331994, major code: 147 (Unknown), minor code: 4 Jan 14 19:15:04 ftglap plasmashell[5761]: QXcbConnection: XCB error: 4 (BadPixmap), sequence: 16155, resource id: 50331994, major code: 146 (Unknown), minor code: 1 Jan 14 19:15:24 ftglap nscd[30782]: 30782 checking for monitored file `/etc/netgroup': No such file or directory The digital clock on the panel froze at 19:15. The tty switch has no effect.
The link in the previous comment indicates that the udev rule for the touchpad is faulty in describing the geometry of the touchpad. It gives a manual procedure for correcting it, which I do not intend to try as I want to preserve the error case for testing our fix. I don't know enough about how we generate our udev rules to say whether the suggested fix can or should be incorporated into our rule generation. However, the implication is that systemd is lacking accurate geometry info about the touchpad involved. This touchpad didn't used to exhibit this behavior, so I'm assuming that whatever procedure or database systemd used to use has been borked. What I don't know is whether I need to use the manual procedure to generate correct information to post here or whether it should be corrected by a fix to a fix. Always assuming that the Xorg messages are related to the problem.
Source RPM: plasma => libinput
Still happening even with refreshed libinput 1.6.
Severity: normal => major
Switching this back to plasma since it only seems to occur with the plasma panel and desktop widgets. Some other interesting stuff: This also happens on a desktop system with Radeon. I noticed it lock up, but I was burning a DVD at the time and didn't want to interrupt that to logout/login. I came back about 12 hours later and saw that the panel was now acting normally and the digital clock was now correct (as part of the panel, it had frozen at the time of the panel freeze). In the past, when the panel froze, you could still switch virtual desktops with CTRL-Fx and you could eventually, when it suited you, use CTRL-ALT-DEL to initiate logoff. No more. One or two uses of CTRL-Fx locks any keyboard interaction with X; CTRL-Fx no longer works, nor does CTRL-ALT-DEL, but CTRL-ALT-BKSP works to kill X and allow re-login. I also think that Suspend (initiated via keyboard Fn key) restores the panel when resumed, but I'll verify this again. IMO this is a release blocker.
Source RPM: libinput => plasma
Correction: suspend/resume does not release the panel. The desktop in question is set to turn off the monitor after 5 minutes of inactivity, and that may have been what released the panel. I'm not sure what "turn off the monitor" actually entails besides turning off the monitor.
I've just acquired a new laptop with only an Intel graphics chip: Vendor ID: â0x8086 Device ID: â0x5916 Sub vendor ID: â0x1043 Sub device ID: â0x14c0 Keeping my fingers crossed, but a fresh install on this machine has not had the panel freeze yet (over 24 hours). Both of the other affected systems are up-to-date cauldron that have been maintained via --auto-update for a looong time. We'll see....
The new system went for quite a while (48 hours) with no panel freeze *until* I plugged in a USB DVD drive with a disk in it. The removable device notification popup came up and obscured the window behind it, but did not paint (remained transparent) and the panel locked. Switching to a tty didn't free it, and the transparent notification panel was present on all virtual desktops. However, after about 5 minutes, the popup disappeared and the panel unfroze. I tried this again with identical results.
This time I timed it. 12 minutes from original freeze to unfreeze. Unplugging the USB drive at about 4 minutes in had no effect, and there didn't seem to be any trigger event for the unfreeze. I'll try letting the original system sit after freezing, and I'll also see if plugging the drive causes the problem there.
Plugging the USB DVD drive into the original system works perfectly and does not freeze.
is this bug still valid for you ?
CC: (none) => mageia
I haven't noticed the random panel freeze on the new system for a while (since I last reported it). I'll try the USB test again today. I haven't been using the original system for a while, but I'll update it to current cauldron and see if it still freezes.
The USB stick now works correctly on the new system.
I'm going to call this good. I've been using the fully-updated original system for most of the day with no lockup.
Status: NEW => RESOLVEDResolution: (none) => FIXED