networkimprov / arch-packages

1 stars 0 forks source link

interrupt checking #26

Open networkimprov opened 10 years ago

networkimprov commented 10 years ago

o.026 interrupt checking

While the system is idle, we should only have interrupts every few seconds. For now, a few interrupts per second are OK as that can be tuned later on.

We need to run a test script after building rootfs to make sure the timer interrupts are reasonable. You may want to add some calculations for totals to the script below. Note that loading cat, echo and diff from the eMMC will also cause interrupts when run for the first time.

You may want to play with it a bit by shutting down services initially until you start getting timer and device interrupts only few times per second, then enable services one at a time to figure out the problem ones. And you may want to have the USB cable disconnected while doing this because that will also cause interrupts.

#!/bin/sh
old="$(cat /proc/interrupts)"
sleep 10
new="$(cat /proc/interrupts)"
echo "$old" > /tmp/old
echo "$new" > /tmp/new
diff -u /tmp/old /tmp/new

Without subshells?

exec < /proc/interrupts
data=''
while read; do ; done # read to current eof
sleep 10
while read line; do data=$data$line\n; done # read latest
echo $data
networkimprov commented 10 years ago

Can we filter the USB interrupts?

Sure. Those are the musb interrupts and twl4030-usb interrupts.

For diagnosing unexpected WLAN interrupts, what's the best way to inspect incoming packets?

Those would be MMC3 interrupts for the SDIO.

Is there a way to link an mmc3 interrupt, or sequence, to a specific packet?

Not really, but tcpdump -i mlan0 shows the packets.

Try to limit the tcpdump output to the 10s period, perhaps by issuing a udp packet as a flag before and after reading /proc/interrupts...

I'd assume tcpdump will cause an insane number of various interrupts when run :) So it should only be run manually when debugging what is causing interrupts for network traffic.