Latency problem after upgrading to Trixie

Hi
After many happy years on Bookworm LinuxCNC I have upgraded to Trixie. I ended up installing Debian OS and then installing LCNC ( I could not get the download from LCNC website to work).  Anyway, I have the machine running again, but as soon as I start the program, I get the dreaded latency error message.  I have turned off everything that is not needed in the bios, but still get the message. I understand there are ways to manipulate how the cores work in the computer.  Can someone point me to some step-by-step instructions?
Thanks

I assume you have installed the RT kernel...
As for the error message that appears immediately after starting LinuxCNC, I have been blocking it for a long time (I always compile LinuxCNC myself).
I suspect that the cause of this error is the procedure for checking it.
I reported it once, but no one was interested.
Anyway, the message was almost always displayed, but latency-test or latency-plot didn't show anything alarming...

Its nothing to do with building LinuxCNC. As time goes on, the hardware manufactuters add more power saving features which induce latency so it takes more work to get it under control. Trixie is no worse than Bookworm. The biggest issue is not using the dkms drivers with realtek NIC's. Try to always use Intel NIC's. I've covered this and other steps in a few videos over the last 12 months or so on my YouTube channel.

Once again.
Many times I had the problem with the "Unexpected realtime delay on task" message, which meant nothing and only annoyed the user because neither latency-test nor latency-plot showed anything wrong.
This has nothing to do with compiling LinuxCNC yourself, except that compiling it yourself allows you to disable this message.
As for the message itself, I suspect that either the procedure displaying it is bad, or it is called at the wrong moment (LinuxCNC starts and maybe something jams, but only then and only once).

"Unexpected realtime delay on task" means that linuxcnc did not get everything done in the allotted 1ms time of the servo thread. This is nothing to do with the LinuxCNC application.

In kernel traces I did a long time ago on an i5 machine with Bookworm, Linuxcnc typically took 200 us to execute the servo thread and sleeps for the remaining 800 us. That 800 us is the safety buffer for real time tasks. Sometimes there is a Linux task that consumes a lot of the  CPU time which impacts on the servo thread and LinuxCNC does not have enough time to get everything done in time. Then the system reports the realtime delay and generally disables linuxcnc (so long since I have experienced this myself I can't remember). There are many possible tasks that can cause this.

One new source I found this week is that if the wifi has poor signal strength, a NetworkManager task fires looking for any stronger wifi signals every 30 seconds or so and causes a latency spike every 34-36 seconds. Because CNC machines are not generally wandering the aisles of a corpporate workspace, its a no brainer (and safe)  to disable this service. Linux obligingly provides an obscure process to do that.... Don't ask me what it is, I've forgotten already.

The code above displays message only once.
This may mean either a serious problem or a one-off event with no impact on further work.
This, in turn, means that this message says nothing, warns against nothing and is unnecessary.
The right thing to do is to run latency-test or latency-plot for a few hours immediately after installation, which will clearly answer the question whether the hardware and software can be used safely.

Where is it called from and what does the code around it do? send a URL into github
I don't think it can simply be  ignored.