MCU 'mcu' shutdown: Timer too close with SKR Mini E3 1.2 and Debian VM

MCU 'mcu' shutdown: Timer too close
This often indicates the host computer is overloaded. Check
for other processes consuming excessive CPU time, high swap
usage, disk errors, overheating, unstable voltage, or
similar system problems on the host computer.
Once the underlying issue is corrected, use the
"FIRMWARE_RESTART" command to reset the firmware, reload the
config, and restart the host software.
Printer is shutdown

I am using a Debian VM on my PowerEdge R710, and it has 4 cores and 4 gigs of ram. I have had tons of successful prints, until this latest one. I am even a little bit slower than normal due to printing PETG and not PLA. I have had this issue several times with OctoPrint as well. I will have several successful prints, and then all of a sudden I will have a print that fails about 25% or 50% through. I cannot figure out any issues on the PC end, there aren’t errors in the DMESG, and there is very little CPU/RAM usage on the VM. Attached are my logs, this issue has been intermittent until this print. Usually I can clear the bed, restart the print and it will finish. Not this time! I have attached the GCODE also for that print.

After several restarts, and I changed orientation of one of the parts I successfully printed this piece. This is an intermittent issue, and I am not sure how to remedy this.

The Klipper host software (klippy) has some real-time requirements. In general, it may have to respond to an event within a couple of hundred milliseconds. Should it fail to respond in a timely manner then it can result in errors like you’ve reported.

It sounds like you’re running the host software in a VM. Be aware that if anything on the host machine (the r710) consumes notable CPU time (or memory, swap, etc.) then it can cause a scheduling delay in the VM running Klipper which can lead to errors like the above. This real-time nature of Klipper is one of the reasons we currently recommend running Klipper on a dedicated single board computer (SBC).



I have klipper in a VM in Proxmox, with 4 cores dedicated to it; as well as 4 gigs of ram. It should have plenty of resources, and I never see over 1 or 2% CPU usage inside of the Debian VM.

Is there a way to slightly de-sensitize the timer for this error in my case? Pi’s are quite difficult to come by at decent prices right now it seems.

Not sure where you’re located, but the Pi Zero 2 W is often available for $15 plus shipping in the US. Pishop has them in stock right now.

I am using Proxmox with klippy and Cheetah 1.1 without any issues. Did you do firmware update on MCU recently? I found this:

I did have issues with USB freezing the VM when Pi Pico was connected so perhaps success is dependent on MCU’s USB implementation.

PS.: running klippy in VM is such a huge improvement over rpi that it would take a lot of errors to get me go back :slight_smile:

Everywhere I have looked shows out of stock. They are selling for 50$ or more on ebay for a zero 2 w

I am not on the latest version but only one or two behind. I flashed recently, but guess I can place another update and verify I have it set right.

Hmm, I have the SKR Mini E3 1.2 in the Ender 5; but I also have a Ender 3 on SKR Mini E3 2.0. I think I left it at 8mhz for both of them, but I can only find a refence for the 2.0

This link says to set it to 8mhz for the 2.0; anyone got information for the SKR Mini E3 1.2 clock ref?

Below schematic shows 8MHz crystal:

Yep; good find. I am unsure then. I don’t get why sometimes it will work great, and then randomly after several prints this will happen. It always happens like 1/4 or mid print.

What does it take to start printing again? VM reboot or mcu?

I have had to hard reset the printer several times after this, and on a few occasions a simple “firmware reboot” will work.

I see some tape up 5V tab on the usb port - perhaps that’s worth trying…

I will give that a try this weekend. I feel like this VM should be way overpowered for the task.

Klipper is not about CPU power or RAM. You can throw as much as you want at it without any benefit. Essentially it will run on a Raspberry Pi Zero which has the performance of a mechanical watch.

Klipper is about precise timing down to milliseconds. Here the pitfalls begin:

  • VM systems are tuned to scheduling fairness → Klipper demands real-time
  • VMs do houskepping and stuff in the background → Klipper says “not while I’m printing”
  • VMs add hardware abstraction and complexity → Klipper wants direct and exclusive hardware access

It can work to run it in a VM or it can lead to subtle and hard to diagnose problems.

My experience is that klipper can run in a VM.

My VM server is running two firewalls, two linux VMs, pihole, netflow collector and klipper with fluidd. I have zero timing related issues. Browsing the internet, compiling and watching videos is not causing any issues - all running on a 4 core 8 years old desktop CPU. One problem, I mentioned earlier, was with USB passthrough freezes VM when pi pico mcu is connected.

PS: is there a way to tell what the jitter and/or latency is between klipper and mcu? I would be curious to know how various VM tasks affect the timing.

It’s great that it works for you, but it doesn’t for the OP. I’ve also seen several reports from other users with similar issues when attempting to use a VM. This is why it is not a recommended configuration. The failures are hard to diagnose and generally outside the control of Klipper.

I do remember how years ago some doubted that using rpi and python for printing was not real-time enough. And those people were proven wrong. I posted my experience here because normally forums are where people come with issues so it might give readers false idea that running klipper in a VM is impossible.

I appreciate your replies w00sh. I had run Octoprint and Marlin only with this same configuration for years without issue. I understand Klipper requires instant access to the bus, and doesn’t like to wait…

I’m just asking if there is a way we CAN desensitize the “timers” in a way that will not affect print quality or safety.

I have an Atomic Pi SBC, and maybe a Pi Zero W laying around I could try alternatively in the future. I have klipper on a Pi3b/Ender 3 also, but will be building my RatRig Vcore3 soon as well. I would prefer to be on a single firmware across the board.

I would prefer for the Ender 5 to work in a VM and I’d hate to go back to Marlin. Due to this printer being on top of my server rack it’s convenient.

I am going to look into the Linux logs and see if anything pops out at me. Maybe a driver or USB host issue.

…I forgot that I’m also running Home Assistant on the same server…

Anyway, Kevin mentioned that timing requirements are in 100s of miliseconds range so KVM should not have issues meeting that. See if you can tweak power management settings so the CPU does not throttle too much, use USB port passthrough, adjust CPU units for your VMs. First thing however, I would suggest to try setting up new barebone VM with klipper. Here’s what I’m using: Ubuntu 20.04.02 LTS