KDE (Plasma) desktop freezes, but machine remains operable

More
20 Oct 2020 22:32 #186762 by JetForMe
I've posed this question on Stack Exchange, but figured I'd try here, too.

I've got a Debian 9.13 machine for running LinuxCNC, with KDE/Plasma desktop. Generally everything works well, but every now and again, the desktop will freeze. The mouse still moves the cursor, the screen still goes to sleep after the set time and can be woken up with keyboard input, I can ssh to it, and amazingly, LinuxCNC g-code interpretation continues and the CNC machine keeps working.

But I can't move or activate windows, or do anything else. Once the program is finished, I can't use the ShuttleXpress to jog the CNC machine. It forces me to restart the machine, which means losing positioning reference on the CNC machine.

Is there any way to recover this without having to re-launch LinuxCNC? Better, is there any way to diagnose and fix the issue?

Please Log in or Create an account to join the conversation.

More
21 Oct 2020 10:21 #186801 by rodw
I'm just wondering if its a USB thing. Does it do it if the Shuttle is disconnected?

Please Log in or Create an account to join the conversation.

More
23 Oct 2020 04:12 #186966 by seuchato

JetForMe wrote: I've posed this question on Stack Exchange, but figured I'd try here, too.

I've got a Debian 9.13 machine for running LinuxCNC, with KDE/Plasma desktop. Generally everything works well, but every now and again, the desktop will freeze. The mouse still moves the cursor, the screen still goes to sleep after the set time and can be woken up with keyboard input, I can ssh to it, and amazingly, LinuxCNC g-code interpretation continues and the CNC machine keeps working.

But I can't move or activate windows, or do anything else. Once the program is finished, I can't use the ShuttleXpress to jog the CNC machine. It forces me to restart the machine, which means losing positioning reference on the CNC machine.

Is there any way to recover this without having to re-launch LinuxCNC? Better, is there any way to diagnose and fix the issue?


I use Kde too, but on buster (Debian 10, stock 2.8.0 iso). Never observed such a thing. SO, my suggestion: upgrade to buster.

greez
chris
The following user(s) said Thank You: JetForMe

Please Log in or Create an account to join the conversation.

More
23 Oct 2020 21:56 #187033 by JetForMe
If I weren't in the middle of a job I'd do that. It's rare enough I can live with it for now, but perhaps I should upgrade soon. Thanks.

Please Log in or Create an account to join the conversation.

More
23 Oct 2020 21:57 #187034 by JetForMe

rodw wrote: I'm just wondering if its a USB thing. Does it do it if the Shuttle is disconnected?


Hmm, not sure. It's so rare it would be virtually impossible to test.

Please Log in or Create an account to join the conversation.

More
24 Oct 2020 08:33 #187082 by seuchato
Also: verify the BIOS Version. Sometimes an upgrade can do wonders.

Please Log in or Create an account to join the conversation.

More
24 Oct 2020 08:53 #187084 by BeagleBrainz
Make sure you have all the latest drivers & updates.

Well if we're going to play Windows.

In all seriousness I'd ssh into it and do some digging around. Start with dmesg and then go through some of the logs.

Tho I think Rod might be on the right track with a USB issue.
Keyboard & mouse are they USb or PS/2 ?
Or it could a piece of hardware that might need reseating, stranger things happen. If it's just a recent thing I wouldn't be so quick to upgrade.
Could even be a bit of electrical noise.
The following user(s) said Thank You: seuchato

Please Log in or Create an account to join the conversation.

More
24 Oct 2020 09:23 - 24 Oct 2020 09:24 #187087 by rodw

BeagleBrainz wrote: Tho I think Rod might be on the right track with a USB issue.


I have bad experiences with unreliable USB connections dating back 10-12 years on Windows XP when I built a car computer with a USB GPS dongle and some other USB devices. I know the technology has improved but:
I would never use a USB device on a CNC machine where I expect bulletproof reliability.

Moving up to a next level wireless pendant is the best decision I think I made. I am so glad I found a hardware solution before I was tempted to go the USB route.
Last edit: 24 Oct 2020 09:24 by rodw.
The following user(s) said Thank You: seuchato

Please Log in or Create an account to join the conversation.

More
24 Oct 2020 09:44 #187089 by BeagleBrainz
With the ITX M\B I was using I went for PS/2 mouse & keyboard over USB.

I'll stick with a wire pendant, I have a habit of putting things down and not finding them, I suspect a Garage Goblin moves them around, at least I can follow a cord. It even happens with my cordless tools.
The following user(s) said Thank You: seuchato, rodw

Please Log in or Create an account to join the conversation.

More
11 Nov 2020 23:43 - 11 Nov 2020 23:43 #189073 by JetForMe

BeagleBrainz wrote: Make sure you have all the latest drivers & updates.

Well if we're going to play Windows.

In all seriousness I'd ssh into it and do some digging around. Start with dmesg and then go through some of the logs.


It has gotten substantially worse with the update to Buster.

Dmesg does start to show a bunch of this when it happens:
[  605.370057] INFO: task kworker/u8:2:174 blocked for more than 120 seconds.
[  605.370060]       Not tainted 4.19.0-12-rt-amd64 #1 Debian 4.19.152-1
[  605.370061] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  605.370062] kworker/u8:2    D    0   174      2 0x80000000
[  605.370092] Workqueue: events_unbound nv50_disp_atomic_commit_work [nouveau]
[  605.370093] Call Trace:
[  605.370097]  __schedule+0x323/0x7b0
[  605.370100]  schedule+0x39/0xe0
[  605.370102]  schedule_timeout+0x33c/0x470
[  605.370105]  ? preempt_count_add+0x5a/0xb0
[  605.370106]  ? migrate_enable+0x118/0x390
[  605.370108]  dma_fence_default_wait+0x1cb/0x200
[  605.370110]  ? dma_fence_release+0xe0/0xe0
[  605.370111]  dma_fence_wait_timeout+0x42/0x180
[  605.370117]  drm_atomic_helper_wait_for_fences+0x63/0xc0 [drm_kms_helper]
[  605.370141]  nv50_disp_atomic_commit_tail+0x7c/0x880 [nouveau]
[  605.370143]  ? _raw_spin_unlock_irq+0x1d/0x50
[  605.370144]  ? __switch_to_asm+0x35/0x70
[  605.370146]  process_one_work+0x19e/0x420
[  605.370147]  worker_thread+0x30/0x370
[  605.370148]  ? process_one_work+0x420/0x420
[  605.370150]  kthread+0x159/0x170
[  605.370152]  ? kthread_create_worker_on_cpu+0x70/0x70
[  605.370153]  ret_from_fork+0x35/0x40
Last edit: 11 Nov 2020 23:43 by JetForMe.

Please Log in or Create an account to join the conversation.

Time to create page: 0.107 seconds
Powered by Kunena Forum