ME PC hangs #2600

Open
opened 2026-02-28 01:15:37 -05:00 by deekerman · 6 comments
Owner

Originally created by @macdroid53 on GitHub (Dec 18, 2024).

I'm trouble shooting an issue where the machine just hangs.

The hang appears random, but always after hour of up time. (Typically, 12 or more, sometimes a couple days.)

The system log shows this:

Dec 17 07:03:00 Motioneye3 kernel: microcode: microcode updated early to revision 0x24000026, date = 2023-09-26
Dec 17 07:03:00 Motioneye3 kernel: Linux version 6.1.0-28-amd64 (xxx) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.119-1 (2024-11-22)
Dec 17 07:03:00 Motioneye3 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-28-amd64 root=UUID=fa28c875-7a8c-4122-aec5-369e16487c2d ro resume=UUID=975f9104-e799-4b4c-be06-680c969eba3c
Dec 17 07:03:00 Motioneye3 kernel: x86/split lock detection: #AC: crashing the kernel on kernel split_locks and warning on user-space split_locks

System info:
X86_64
motionEye 0.43.1b2
Motion 4.7.0
OS 6.1.0-28-amd64

Originally created by @macdroid53 on GitHub (Dec 18, 2024). I'm trouble shooting an issue where the machine just hangs. The hang appears random, but always after hour of up time. (Typically, 12 or more, sometimes a couple days.) The system log shows this: Dec 17 07:03:00 Motioneye3 kernel: microcode: microcode updated early to revision 0x24000026, date = 2023-09-26 Dec 17 07:03:00 Motioneye3 kernel: Linux version 6.1.0-28-amd64 (xxx) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.119-1 (2024-11-22) Dec 17 07:03:00 Motioneye3 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-28-amd64 root=UUID=fa28c875-7a8c-4122-aec5-369e16487c2d ro resume=UUID=975f9104-e799-4b4c-be06-680c969eba3c Dec 17 07:03:00 Motioneye3 kernel: x86/split lock detection: #AC: crashing the kernel on kernel split_locks and warning on user-space split_locks System info: X86_64 motionEye 0.43.1b2 Motion 4.7.0 OS 6.1.0-28-amd64
Author
Owner

@zagrim commented on GitHub (Jan 23, 2025):

That log is from when the system starts, what would be interesting is the log before that. If your system uses journald, try journalctl -b-1 |tail -30 to get last 30 lines before the most previous reboot.

@zagrim commented on GitHub (Jan 23, 2025): That log is from when the system starts, what would be interesting is the log before that. If your system uses journald, try `journalctl -b-1 |tail -30` to get last 30 lines before the most previous reboot.
Author
Owner

@macdroid53 commented on GitHub (Jan 23, 2025):

I think it ended up being a Debian Display manager problem.

I will provide this log info if it occurs again.

@macdroid53 commented on GitHub (Jan 23, 2025): I think it ended up being a Debian Display manager problem. I will provide this log info if it occurs again.
Author
Owner

@macdroid53 commented on GitHub (Feb 4, 2025):

Ok it crashed after running for many days. Of course I was out of town when it happened and am just now getting to look into it. Here the journalctl output:

lasthang.txt

@macdroid53 commented on GitHub (Feb 4, 2025): Ok it crashed after running for many days. Of course I was out of town when it happened and am just now getting to look into it. Here the journalctl output: [lasthang.txt](https://github.com/user-attachments/files/18657041/lasthang.txt)
Author
Owner

@zagrim commented on GitHub (Feb 9, 2025):

So the hang happened right after Feb 02 12:40:21 ? That log, unfortunately, doesn't seem to show anything that would hint about such. Could it be that the system is otherwise fine, but the video driver or display manager or Xorg/Wayland fails so that it appears to be frozen? Have you tried to SSH into the box when it appears hung? If that works, looking at X/Wayland logs might be helpful. In my Debian/Xorg box the file is /var/log/Xorg.0.log.

However, it looks a lot that your issue is not about Motion or MotionEye. The only way they should be able to cause a system to hang is Motion taking all the CPU time there is and causing the CPU to overheat, since neither should be able to hog memory on desktop-sized hardware in such amounts that it would cause serious issues. Then again, in such cases there possibly wouldn't be any evidence in system logs so it's hard to rule anything out without hooking the system up with some external monitoring to record CPU and mem usage.

@zagrim commented on GitHub (Feb 9, 2025): So the hang happened right after Feb 02 12:40:21 ? That log, unfortunately, doesn't seem to show anything that would hint about such. Could it be that the system is otherwise fine, but the video driver or display manager or Xorg/Wayland fails so that it appears to be frozen? Have you tried to SSH into the box when it appears hung? If that works, looking at X/Wayland logs might be helpful. In my Debian/Xorg box the file is `/var/log/Xorg.0.log`. However, it looks a lot that your issue is not about Motion or MotionEye. The only way they should be able to cause a system to hang is Motion taking all the CPU time there is and causing the CPU to overheat, since neither should be able to hog memory on desktop-sized hardware in such amounts that it would cause serious issues. Then again, in such cases there possibly wouldn't be any evidence in system logs so it's hard to rule anything out without hooking the system up with some external monitoring to record CPU and mem usage.
Author
Owner

@macdroid53 commented on GitHub (Feb 10, 2025):

Yes, ME is low on my list of suspects at this point.
But, I had said I'd get a log if it failed again.

As for ssh into the box, no, no ssh, no ping response, on response to keyboard or mouse...the box is completely unresponsive. Yet, the logs never show anything catastrophic before the hang, no memory usage increase.
There definitely wifi driver issues with the driver/chipset combination, but, I don't have wifi enabled. This is difficult to mess with since the chipset apparently does bot hardwired and wifi.

Since the machine runs fine otherwise, I may move ME to another PC and, hopefully be done with it.

@macdroid53 commented on GitHub (Feb 10, 2025): Yes, ME is low on my list of suspects at this point. But, I had said I'd get a log if it failed again. As for ssh into the box, no, no ssh, no ping response, on response to keyboard or mouse...the box is completely unresponsive. Yet, the logs never show anything catastrophic before the hang, no memory usage increase. There definitely wifi driver issues with the driver/chipset combination, but, I don't have wifi enabled. This is difficult to mess with since the chipset apparently does bot hardwired and wifi. Since the machine runs fine otherwise, I may move ME to another PC and, hopefully be done with it.
Author
Owner

@zagrim commented on GitHub (Feb 10, 2025):

Ok, sounds like kernel-level issue if the network interface also dies. Is the kernel you're running a Debian packaged one? If there are options to try another version of the kernel, that might help in case your issue is something that has been fixed in a newer kernel release (but what hasn't been backported by Debian) or that was introduced only rather recently (thus an older kernel might work better). But it's hard to diagnose this further.
If you always left the box running so that it is displaying the text console instead of your desktop manager GUI, you might be able to see something on the console after the hang occurs in case of kernel panic, but that would be more about getting confirmation to a hypothesis than getting any closer to resolving the issue.

@zagrim commented on GitHub (Feb 10, 2025): Ok, sounds like kernel-level issue if the network interface also dies. Is the kernel you're running a Debian packaged one? If there are options to try another version of the kernel, that might help in case your issue is something that has been fixed in a newer kernel release (but what hasn't been backported by Debian) or that was introduced only rather recently (thus an older kernel might work better). But it's hard to diagnose this further. If you always left the box running so that it is displaying the text console instead of your desktop manager GUI, you might be able to see something on the console after the hang occurs in case of kernel panic, but that would be more about getting confirmation to a hypothesis than getting any closer to resolving the issue.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/motioneye#2600
No description provided.