Got error -1 in tcflush: (25)Inappropriate ioctl for device

[gaolst]

Basic Information:

Printer Model: Custom Rostock Delta
MCU / Printerboard: Beaglebone black + CRAMPS
Host / SBC: Beaglebone Black
klippy.log

klippy (23).zip (175.1 KB)

Error in klippy.log

Got error -1 in tcflush: (25)Inappropriate ioctl for device

Most probably this is a bug report.

I did experienced this error constantly when I did try to setup vanilla klipper for beaglebone in latest Debian images for BeagleBone. Eventually it become apparent that PRU firmware is not compatible with Kernel 5.10
That issue I did resolved by refactoring and upgrading PRU firmware for Kernel 5.10 in this topic, and this error did disappear.

Very rarely (once or twice in last 3 months) I did spot same error in my logs but it seems like it was not impacting anything.

Last week I start working on integration of ADXL345 sensor in my configuration and I start seeing this error very often and almost immediately ‘Lost communication with MCU’ or ‘Timer too close’ error was appearing.
When I was playing with Command dispatch benchmark this error start constantly appearing when I was trying flood and overload system.

So I traced it to following conditions: When Klipper is communicating with PRU cores via /dev/rpmsg_pru30 - sometimes message can become corrupted by some reason (for example when CPU is very heavily loaded, or rarely some other reasons), but each instance of message re-transmit is producing this error - which seems like incorrect behavior.

I traced it back to “klippy/chelper/serialqueue.c” method retransmit_event there is a check that if connection type is UART then we will call tcflush to reset buffers, but seems it’s incorrect because in this case we use “pipe connection”.
As a temporary solution I disabled that block and did overload tests again - error disappeared and re-transmits are working fine.

I did include klippy.log file where that issue is present, you can see that my sources have many changes - almost all of them are related to PRU Firmware upgrade for Kernel 5.10, so please don’t ask to reproduce this issue in vanilla setup - because most probably it’s impossible, but most probably this issue can be reproduced on any serial “pipe connection” with re-transmit events.

Thanks.

[koconnor]

The Klipper host code calls tcflush() on a retransmit to clear out any serial buffers that Linux may have pending. It’s a way to speed up retransmit recovery on slow serial ports, as it allows the retransmit data to start immediately.

As you’ve indicated, the pru connection isn’t a serial port, and it is not possible to flush that connection. However, the call to tcflush() should be harmless on the PRU - Linux reports an error and Klipper reports the warning in its log - and then everything should proceed as normal. There should be no harm in the call or the logged warning.

It’s odd that you’re getting these warnings at all, as the PRU should acknowledge commands very quickly. A retransmit should only be triggered if a command is not ack’ed in 25ms, and the PRU should ack commands in well under 1ms.

It’s possible the error you reported is just a symptom of some other problem - if the connection dies for some reason you’ll see these warnings as part of retransmit attempts (thus the warnings are a symptom of a dead connection not the cause).

I guess it’s also possible that Linux has a bug causing the tcflush() to destabilize the PRU, but that seems unlikely.

I suppose it’s possible that the tcflush() warning messages could increase host load to the point that it causes more retransmits, which ultimately destabilizes the system. Seems unlikely though.

It’s also possible that there could be a subtle defect in some of your recent code changes to the PRU (or in the original PRU code) which causes a high command message rate to destabilize the PRU.

Anyway, I hope that explanation may help.
-Kevin