Raspberry Pi 4 | System is freezing up

the way you added it to local startup means it is doing nothing, since you added the commands AFTER the exit 0

Believe it or not, I did wonder about that!

Can you explain the command in a bit more detail.

This post uses echo 2 for both commands.

What is the significance of the echo 2 vs echo 8 and irq/31 vs irq/32?

Thanks,

I'd be interested in how those irq's are relevant to "Raspberry Pi 4" .. .since 31 doesn't exist on the pi4 and 32 is the "VCHIQ doorbell"

Can you suggest some more appropriate commands for the Raspberry Pi 4?

No ... the commands are fine - the irq's are invalid or not relevant - but that's OK, since you aren't actually running them - but somehow, adding two lines of incorrect code that doesn't even run ... "seems to be working"

If it's working, then don't fix it

What are the valid irqs for a Raspberry Pi? Don't be a tease...

cat /proc/interrupts

31 and 32 appear to be the correct values.

Now, what is the significance of echo 2 vs echo 8?...

Just to give some context on what's possible, I can easily get 800+ Mbps through my squid proxy on my RPi4 while running my custom HFSC shaper. Just regular routing and SQM should be no problem once you spread the load over the CPUs.

I believe these are bitmaps, 2 means it goes to cpu 1, 8 means it goes to CPU 3

It also looks like 39 is the USB interrupt which you could move to CPU 2 via echo 4

I'll admit that I'm a bit confused by this.

In the table above, both 31 and 32 refer to eth0. My WAN connection is eth1?

The Raspberry Pi 4 is a quad core CPU. Should I be trying to spread the load across all four cores?

Yes. See above I edited my comment to include info on moving the USB interrupt. Most likely the eth0 interrupt is split between send and receive which is why 2 of them

OK, so the commands should be:

echo 2 > /proc/irq/31/smp_affinity
echo 4 > /proc/irq/39/smp_affinity
echo 8 > /proc/irq/32/smp_affinity

Is that correct?

1 Like

Start with that yes

That seems to be a step backwards.

Yup. That looks bad. I honestly think irqbalance is what you want.

1 Like

It might be due to the way I entered the commands - the Wi-Fi timer was above the irq commands.

# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
wifi up && sleep $((15*60)) && wifi down
echo 2 > /proc/irq/31/smp_affinity
echo 4 > /proc/irq/39/smp_affinity
echo 8 > /proc/irq/32/smp_affinity
exit 0

I've changed it to this.

# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
echo 2 > /proc/irq/31/smp_affinity
echo 4 > /proc/irq/39/smp_affinity
echo 8 > /proc/irq/32/smp_affinity
wifi up && sleep $((15*60)) && wifi down
exit 0

I'm now waiting for my router to reboot again. It seems to be very slow to reboot at the moment. It it waiting for the wifi timer to expire before executing the command?

Yes, I'm not sure the point of the wifi timer, but I'd do that in the background by adding an & at the end of the command

wifi up && sleep $((15*60)) && wifi down&
exit 0

Like that?

how odd - in OpenWRT, mine are 39 and 40

 39:        208   16616653          0          0     GICv2 189 Level     eth0
 40:         43          0          0   14803336     GICv2 190 Level     eth0

and in raspberry pi os - 54 and 55

 54:    7018974          0          0          0     GICv2 189 Level     eth0
 55:    2354904          0          0          0     GICv2 190 Level     eth0

the lesson is ... don't rely on other people ... check for yourself