Version 2.8.2 Debian Buster PREEMPT-RT ISO Freezes

I'm new to LinuxCNC and indeed to Linux in general so please forgive what may seem like silly questions.

I'm putting together a Taig CNC Mill and have installed LinuxCNC on a mini industrial PC that I obtained for the purpose.  I replaced WiCD with network manager but otherwise it was a straightforward install.

I have successfully configured everything and things work as they should - for a while.  Then the system simply freezes (becomes unresponsive to both the mouse and the keyboard).  To date the freezes have only occurred while running LInuxCNC.  I really haven't tried exercising the machine in other ways, but if I simply do nothing it seems more stable.

I'm using a Mesa 7i76e card and the PC has a NEX 604 motherboard with an Intel Atom D52550 processor.  Latency was terrible until I disabled multi threading, after which it became acceptable.

My problem seems very similar to that described in a recent topic (linux-mint-cnc-2-8-0-freezing).  In that case the solution evidently involved going back to an earlier kernel (with presumably, the RT patch applied).  Is this something I should consider trying and, if so, how might I go about doing it?

Is it really possible that the current kernel isn't compatible with what seems to be a pretty standard PC?  If so, are there known hardware configurations (e.g. processors)  that cause problems?  I'm also considering obtaining another PC and would like to know if there's anything I should avoid.

I've tried using each of the 2G memory cards independently, and this hasn't changed anything.  Adding new heat paste is also on the list of things to try (it is a fanless PC) but the CPU to heat sink contact appears to be pretty good.  Is there some kind of  "system exerciser" application that I can install and run to see whether the freezes only occur while LinuxCNC is running?

Any help or suggestions would be most appreciated.
 

As I've yet to get to running G-code, I can't say whether any code that was running might continue to execute. But other evidence indicates that I'm dealing with complete and utter machine failures, The last time around I had a monitor running in another window, and when the freeze occurred the monitor stopped as well.

Since posting, I have answered one of my own questions. I've found a computer stress tester (stress, s-tui), and have installed and used it. It ran for 25 hours with all test options enabled before I shut it down. So I don't think that I've a dodgy PC that is prone to crashing from time to time. Also CPU overheating can be ruled out as an issue. The temperature never exceed 68C.

When I invoke LInuxCNC and can be pretty sure that a freeze will occur within an hour. And this is with LinuxCNC just sitting there (I'm not actually doing anything). I make a few axes movements, go away, and come back to find everything frozen.

And I've no wireless dongles anywhere. The mouse and keyboard connect to the PS-2 ports via USB to PS-2 adapters.

The uname command returns:

4.19.0-17-rt-amd64 #1 SMP PREEMPT RT Debian 4.19.194-2 (2021-06-21) x86_64 GNU/Linux

I presume that the 4.19.0-17-rt-amd64 is the kernel and the Debian 4.19.194-2 is the Linux version?

In any case I definitely didn't do any fancy mixing and matching. I just downloaded the current standard LinuxCNC package.

The catch is that I'm using a Mesa Ethernet card, and my understanding is that the RTAI kernels are definitely not compatible with these cards.

I'll try the dmseg idea and will report back.

The BIOS definitely doesn't support TPM.

I'm not sure what you mean by virtualizations, but I have disabled multi-threading.

The PC uses a NEX 604 motherboard (Intel NM10 chipset + Intel Atom D2550 processor). It's a small fanless unit intended for industrial use. Nothing fancy, and nothing to do with Dell. Seemed perfect for the job....

I did a dmesg clear and ran LinuxCNC.Some time later LinuxCNC reported "Unexpected realtime delay on task 0 with period 1000000. Run the latency  test and resolve before continuing".  This was a bit distressing as I though that disabling multi threading had put paid to this issue.  Evidently not completely.....

After I while I checked (and recleared) dmesg.  There were five messages, all of the same form but with increasing values:
perf: interrupt took too long (3171 > 3170) lowering kernel.prf
....
perf: interrup took too long (7834 > 7832) lowering kernel.perf

More evidence of latency issues?

Ultimately I decided that the system was taking rather longer than usual to fail, and I wondered whether this might be because having the terminal application open was somehow stabilizing things.  So I closed the terminal application and, sure enough, the system froze shortly afterwards.

After rebooting I obtained the attached dmesg file.  Hopefully it will shed some light.