Let’s see – I’m running Tumbleweed on an older (32-bit) dual cpu (2 x Intel Pentium 4, 2.40 GHz) processor. OpenSuse Tumbleweed 20171218, KDE Plasma 5.11.4, KDE Frameworks 5.40.0, Qt 5.9.3, Kernel 4.14.6-1-default. This problem arose about two or three days ago (shortly after the latest automatic update). Oh, yeah – my mouse is a standard PS/2 2-button dealie, connected to the 6-pin PS/2 port. The keyboard uses a similar connection.
Anyway, every once in a while my pointer device / mouse gets “stuck” – the cursor stops at a particular point on the screen, and no amount of moving the mouse around will get it free. Sometimes I’m able to use keyboard navigation to shut down a few application programs (like Alt-f, then Quit). Sometimes that also fails. The only way I can get around this is to reboot. Most of the time I can use Alt-Ctrl-F1 to get to the terminal interface, log in as root, and do an orderly shutdown. Other times I have to use the reset button (this is messy, and often means I have to boot up three times before everything works right: once to get past an error message about “Invalid PTCI data”, once to get the system up with the mouse still frozen but with the keyboard operational, and the third time I can do a clean boot after a clean shutdown).
This problem arises in any one of several applications, so I suspect a bug in the OS (it’s as if an interrupt service routine stops working). I’m not certain this is the appropriate forum, but couldn’t find a better one.
Any advice will be appreciated. It’s annoying to be forced to reboot the system four or five times per day.
This reads like a possible kernel regression IMO. Not many using PS/2 connected devices these days. Examine the journal log from a previous boot where lock up occurred (eg -1 pertains to last boot before current)
sudo journalctl -b -1
and look for any obvious errors relating to the PS/2 devices at a given time. (Some filtering with grep may be needed to help here.)
You could also try substituting/adding a USB pointing device as a backup and using that instead. Does it stay working when the PS2 device is locked up?
sounds like a graphic card issue to me
what kind of a graphic card and driver do you have
sudo lspci | grep VGA
are you sure that’s a 32bit cpu afaik intel only had 32bit single core cpu’s they did include hyper threading in some of them so they had a cpu with 2 virtual cores but those weren’t dual core afaik all dualcore are x64
sudo lscpu
or
cat /proc/cpuinfo
anyways if you have an old graphic card without hardware acceleration plasma 5 is too intensive for you, you’re better off with a lighter desktop like lxqt or lxde or mate
plasma 5 is also known to have issues with some on-board intel graphic cards (the fix for some of them is to use uxa acceleration) and does not work well with the noveau driver you’d need the propitiatory nvidia driver which afaik only officially supports GeForce 4xx or never you might be able to get the older G03 driver working (GeForce 8xx and above) but that needs to be installed the hard way
This doesn’t work well for me. It did work without the operands.
david@localhost:~> sudo journalctl -b -1
[sudo] password for root:
Specifying boot ID or boot offset has no effect, no persistent journal was found.
david@localhost:~>
david@localhost:~> sudo journalctl
[sudo] password for root:
... a lot of stuff
Dec 22 14:50:13 localhost kernel: psmouse serio1: hgpk: ID: 10 00 64
... a lot more stuff
Dec 22 15:03:09 localhost kernel: psmouse serio1: bad data from KBC - timeout
Dec 22 15:03:11 localhost kernel: psmouse serio1: hgpk: ID: 10 00 64
Dec 22 15:03:23 localhost kernel: psmouse serio1: hgpk: ID: 10 00 64
Dec 22 15:04:41 localhost kernel: psmouse serio1: bad data from KBC - timeout
Dec 22 15:04:41 localhost kernel: psmouse serio1: Mouse at isa0060/serio1/input0 lost synchronization, throwing 2 bytes away.
Dec 22 15:04:46 localhost kernel: psmouse serio1: hgpk: ID: 10 02 64
Dec 22 15:05:49 localhost systemd[1]: Starting Cleanup of Temporary Directories...
Dec 22 15:05:49 localhost systemd-tmpfiles[2430]: [/usr/lib/tmpfiles.d/tmp.conf:13] Duplicate line for path "/var/tmp", ignoring.
Dec 22 15:05:49 localhost systemd-tmpfiles[2430]: [/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring.
Dec 22 15:05:49 localhost systemd-tmpfiles[2430]: [/usr/lib/tmpfiles.d/var.conf:19] Duplicate line for path "/var/cache", ignoring.
Dec 22 15:05:49 localhost systemd-tmpfiles[2430]: [/usr/lib/tmpfiles.d/var.conf:21] Duplicate line for path "/var/lib", ignoring.
Dec 22 15:05:49 localhost systemd-tmpfiles[2430]: [/usr/lib/tmpfiles.d/var.conf:23] Duplicate line for path "/var/spool", ignoring.
Dec 22 15:05:50 localhost systemd[1]: Started Cleanup of Temporary Directories.
Dec 22 15:06:07 localhost kernel: psmouse serio1: hgpk: ID: 10 00 64
Dec 22 15:07:16 localhost kernel: psmouse serio1: hgpk: ID: 10 00 64
No more messages about “psmouse” that I can find. Thanks! dcb
On systems where /var/log/journal/ does not exist yet but where persistent logging is desired (and the default journald.conf is used), it is sufficient to create the directory, and ensure it has the correct access modes and ownership:
mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
seeing how it’s a known issue I still think it’s your graphic card as Mesa-dri-nouveau taints the kernel and there is a serious bug in intel’s driver stack (old ati cards have been abandoned by amd)
telling us your graphic card and cpu would have been of more help, seeing it’s an old PC most likely has an nvidia graphic card running TW you are using noveau if you installed Mesa-dri-nouveau your system is broken and will have the symptoms you described, if it’s a supported card install the propitiatory driver if it’s not remove Mesa-dri-nouveau and use openbox instead of kwin5 as a window manager by installing openbox-kde and selecting plasma5-openbox at the login screen
seriosly how dificult is it to post
I’ve an old AMD 64 X2 5600+ based PC (currently using it to reply here incidentally), with a GeForce 8600GTS using the OSS nouveau driver and Mesa-dri-nouveau. Machine also has a PS/2 keyboard and PS/2 mouse… No problems at all running TW 20171220 with KDE Plasma 5 (albeit a little sluggish, but perfectly usable).
OK, so the system stayed up for a long time (almost a whole day) before it crashed. Then I had to reboot three times before everything was working. Nothing of interest in the intermediate re-boots … here’s the “journalctl” output from when it locked up.
Dec 22 19:11:19 localhost kernel: psmouse serio1: hgpk: ID: 10 00 64
Dec 22 20:36:51 localhost kernel: psmouse serio1: hgpk: ID: 10 00 64
Dec 22 22:04:02 localhost kernel: psmouse serio1: hgpk: ID: 10 00 64
Dec 23 02:29:55 localhost kernel: psmouse serio1: hgpk: ID: 10 00 64
Dec 23 03:13:33 localhost kernel: psmouse serio1: hgpk: ID: 10 00 64
Dec 23 03:36:53 localhost kernel: psmouse serio1: hgpk: ID: 10 00 64
Dec 23 03:36:53 localhost kernel: psmouse serio1: hgpk: ID: 10 00 64
Dec 23 03:52:06 localhost kernel: psmouse serio1: hgpk: ID: 10 00 64
Dec 23 07:11:18 localhost kernel: psmouse serio1: hgpk: ID: 10 00 64
Dec 23 07:29:03 localhost kernel: psmouse serio1: hgpk: ID: 10 00 64
Dec 23 09:09:50 localhost kernel: psmouse serio1: hgpk: ID: 10 00 64
Dec 23 09:16:37 localhost kernel: psmouse serio1: hgpk: ID: 10 00 64
Dec 23 09:22:41 localhost kernel: psmouse serio1: hgpk: ID: 10 00 64
Dec 23 09:23:06 localhost kernel: psmouse serio1: bad data from KBC - timeout
Dec 23 09:23:06 localhost kernel: psmouse serio1: bad data from KBC - timeout
Dec 23 09:23:06 localhost kernel: psmouse serio1: bad data from KBC - timeout
(This message repeated 857 more times in ten seconds, then the system died).
Any ideas from that? Clearly it’s bad data from somewhere, but what can I do about it? Thanks!
Any ideas from that? Clearly it’s bad data from somewhere, but what can I do about it? Thanks!
The problem is originating with the interaction between the kernel and the PS/2 (8042) controller. Since you report that this only started occurring after a recent update, I think a bug bug report will be needed to help progress this.
What is reported by the following?
cat /sys/bus/serio/devices/serio1/protocol
The following kernel boot parameters may be worth a shot, although this is designed as a workaround for hardware the doesn’t support multiplexing and I can’t promise that it will help here…
localhost:~ # cat /sys/bus/serio/devices/seriol/protocol
cat: /sys/bus/serio/devices/seriol/protocol: No such file or directory
I’ll try adding those boot parameters and see what happens the next time the system locks up. Thanks for the suggestions. (Oh – I did find some bug reports relating to this error message by searching with Google. But they were all pretty old.) And Merry Christmas! Stay cool down there.
That’s because you mis-typed the path. It should be ‘serio1’ (numeric one), rather than ‘seriol’. Copy/paste it as I gave it in the last post.
I’ll try adding those boot parameters and see what happens the next time the system locks up. Thanks for the suggestions. (Oh – I did find some bug reports relating to this error message by searching with Google. But they were all pretty old.) And Merry Christmas! Stay cool down there.
Sorry – I’m so used to using “Ctrl + V” for a paste command I didn’t even notice I can paste stuff into Konsole via the “Edit” menu. Anyway, here’s the requested output.
Just a general inquiry: What’s with the “Random Question” deal? I had to answer three questions before this site would accept my post. And I’m certain my answers were all correct; your Turing machine is short on English apprehension skills, apparently.
a lot of people have reported issues with plasma 5 and intel gfx, before doing anything else try using uxa acceleration https://mail.kde.org/pipermail/kde-distro-packagers/2015-August/000088.html
this was supposed to be fixed upstream in newer kernels but there have been a lot of reports that the fix is hardware dependent
you’d create /etc/X11/xorg.conf.d/20-intel.conf
I don’t have much experience with old intel integrated chips I doubt that one even has uxa let alone sna acceleration I’d recommend disabling all compositing and using xrender
while it is possible that there is a bug in the kernel (or your install) regarding ps2 devices if it is the mouse it’s more likely it’s hardware related can you try a different mouse?
imo the issue is the fact that plasma 5 is too much for your system to handle a workaround would be to use openbox as a window manager instead of kwin5
That didn’t help a bit. After I booted the system with those parameters, it ran OK for a while. But once it logged me out (I was in the kitchen for a bit) and I tried to log back in, the whole thing went haywire. I tried getting to the graphic interface (Alt + Ctrl + F1) to do an orderly shutdown, but as soon as I entered a couple of characters it kicked me back to the X11 session. When I moved the mouse around I got black squares all over the screen … sort of like the bouncing ball effect that was in older versions of KDE. And sometimes there were two mice pointers on the screen. Anyway, thanks for the suggestion. Something is working a little bit better … I booted up about noon on Saturday, and the system didn’t crash for about 36 hours. I can live with rebooting once a day.
Merry Christmas to all the kind Linux users out there!
