Fix irq-set-prio not working in a PLC shell

What priority 55 has to attach to

Real-time priorities run from 0 to 99, and the higher number runs first. That scale is the entire meaning of the 55 in the command. A stock kernel starts a threaded interrupt handler at 50, half of the 99-point scale, so 55 asks for one step above the default.

An interrupt gets a schedulable thread in one of two ways. The driver registered a threaded handler, supplying both a hard-interrupt handler and a thread function, which is the pattern the kernel's own generic IRQ documentation lays out. Or the controller image is built for full preemption, in which case every interrupt is threaded whether its driver asked or not. Where eth0's interrupt is serviced in hard-interrupt context, there is no scheduling entity behind it, and a priority command against it cannot apply whatever the shell prints back. That image difference is why the same command works on one controller and does nothing on another.

Symptoms and what each points to

• The shell answers garbage arguments exactly as it answered 55. Points to a stub: the command lives in the parser and goes nowhere.
• Jitter is unchanged, and no thread in the thread list carries the interface's IRQ number. Points to a missing threaded handler.
• A handler thread exists, reads priority 50 before the command and 50 after. Points to the privilege ceiling.
• The command sticks, the thread reads 55, and jitter is unchanged. Points to the wrong interface: you raised the priority of a port that carries no process data.
• The value reads 55 in this session and 50 after a runtime restart or a power cycle. Points to a volatile setting applied at the wrong point in startup.

The checks in order

Work top to bottom. Each check is one or two commands, about 30 seconds each, and each closes a branch.

1. Test the command with an impossible argument: irq-set-prio eth0 999. The scale stops at 99, so a real parser rejects 999. A stub answers 999 exactly as it answered 55, and that is your answer.
2. Resolve the interface to its interrupt lines: cat /proc/interrupts, and read the lines whose device column names the interface. Record every number in column 1. A multi-queue network controller lists one line per queue, and each queue has its own interrupt and its own thread. Fixing one queue and leaving the rest is the classic partial improvement.
3. Confirm the thread exists: ps -eo pid,class,rtprio,comm, and match the recorded IRQ number inside a thread name, which starts with irq/. No matching thread, stop. This image cannot honor the command, and the fix is an image decision.
4. Read the priority before and after. Issue the command, rerun the ps line, compare the rtprio column. 50 before and 55 after means the command worked and the problem lives elsewhere. 50 and 50 means the request was refused, so go to step 5.
5. Read the ceiling as the user the runtime runs as: ulimit -r, plus the rtprio lines in /etc/security/limits.conf. A ceiling of 50 against a target of 55 is refused at the operating system layer.
6. Restart the runtime, then power cycle, rereading the priority each time. The value dying at the runtime restart points at startup ordering. Dying at the power cycle points at a command that only ever ran interactively.

Example: eth0 targeted at 55 under a ceiling of 50

Inputs:

• Target priority 55, from the shell command irq-set-prio eth0 55.
• Stock handler priority 50, the kernel default for a threaded interrupt.
• Real-time scale 0 to 99, set by the Linux scheduler.
• Ceiling 50, read with ulimit -r for the user the runtime runs as.
• A fieldbus cycle of 1 ms, so a priority fix has to show up as jitter moving within a few seconds of measurement.

Rule: the request takes effect only when the target priority is at or below the ceiling.

Arithmetic: the interrupt table resolves the interface to its line, and the thread list shows the handler thread at rtprio 50. The command is issued, and the thread still reads 50. Compare: 55 > 50, so the operating system refused the request. The ceiling and the target cannot both hold.

Fix and result: the runtime user's rtprio limit goes to 99 in /etc/security/limits.conf, the runtime restarts so the new limit loads, and the command is reissued. Now 55 is at or below 99, and the ps line reads rtprio 55. Decision: a true 55 reading with jitter unchanged moves you to the interface check in step 2. A reading still stuck at 50 under a ceiling of 99 moves you to the stub check in step 1.

The fix for each cause

Work in a planned stop, and treat any kernel or image change on a certified controller as a vendor case decided in writing, never a self-served swap.

A runtime configured against one device while the process data rides another is the same class of fault as a PLC runtime device mismatch, and you check it the same way: follow the traffic, not the name. Persisting a per-machine value like the priority is the same job as setting machine-specific NetVar IP and port values the supported way: the setting belongs in the machine's startup configuration, written once and applied in the right order.

Where 55 should sit

Before locking the value, list every real-time thread on the controller with the same ps line, then place the frame-handling thread deliberately:

• Above the cyclic task when the task cannot start its work until frames arrive. Late frame delivery then shows up as an outranked interrupt thread.
• Below the cyclic task when the task is compute-bound and frame handling tolerates deferral of a few microseconds.
• Never tied with another critical thread, and never pinned at the top of the scale to be safe. The gaps between your real-time priorities are the design; fill them on purpose. The cyclic task's own position comes from tracing PLC execution order across task layers.

Keep the fieldbus stack's threads within a few numbers of each other so the stack finishes what it starts.

Recommendation: Run the thread check first, always. A thread reading 50 before and after the command is a ceiling problem: set the runtime user's rtprio limit to 99, restart the runtime, reissue, reread. No thread at all is an image decision that belongs to the vendor. Whatever branch you land on, the command ends up in a startup hook that runs after the network driver and logs the priority it reads back.

Questions