First off, I'm going to pardon myself in advance for speaking without
knowing anything. Secondly, I'm trying to track down the cause of
(apparently) missed serial IRQ's when using the aha152x and IDE drivers
simultaneosly (see previous post: "aha152x in 2.1.121 causes dropped ppp
packets"). The apparently missed serial IRQ's manifest in PPP framing
errors out the yin-yang.
I'm trying to determine if the time spent handling the aha152x interrupt
is causing the serial interrupt to be missed. If this is actually
impossible (i.e. the one has no effect on the other) stop reading now.
Otherwise, I have added to the aha152x_intr routine a bracketing set of
do_gettimeofday() and a small benchmarking routing that calcualates min,
mean and max usecs for this handler. Again, if do_gettimeofday is invalid
here, stop reading! A sampling of results are:
Sep 19 hamlet kernel: aha152x: intr_benchmark min 7 mean:613 max 8790
Sep 19 hamlet kernel: aha152x: intr_benchmark min 14 mean:676 max 9992
Sep 19 hamlet kernel: aha152x: intr_benchmark min 20 mean:356 max 9992
For 1000 interrupts, the logging happens every 1000, and the numbers are
basically the same for every 1000. The total benchmark stats are cleared
every 10000, and I get pretty consistent numbers across samplings. I added
the same benchmark to the ide_intr handler:
Sep 19 hamlet kernel: ide: intr_benchmark min 2 mean:86 max 147
Sep 19 hamlet kernel: ide: intr_benchmark min 2 mean:86 max 167
Sep 19 hamlet kernel: ide: intr_benchmark min 3 mean:119 max 154
and to ther serial rs_interrupt handler:
Sep 19 13:56:44 hamlet kernel: serial: intr_benchmark min 8 mean:11 max 63
Sep 19 14:43:13 hamlet kernel: serial: intr_benchmark min 3 mean:30 max 58
Sep 19 14:43:23 hamlet kernel: serial: intr_benchmark min 1 mean:30 max 57
All times measured using do_gettimeofday and displayed in total usecs. I
see that the max time for an aha152x handler is about 2 orders of
magnitude slower than the other two. Is it possible that this is the
source of my problems? Here's the only strange fact: if I do a:
tar -tvf /dev/nst0 >/dev/null 2>&1
in other words, this tape read doesn't result in data written to the IDE
disk, I don't miss serial interrupts (actually: I don't see corrupted PPP
frames, I don't know for sure if I am missing the interrupts). But:
tar -tvf /dev/nst0 >tar.log 2>&1
i.e. the tar *listing* being written, not the tar contents, causes severe
PPP frame corruption/lossage.
My system is a PPro 200 with onboard 16550a, intel Triton IDE, old WD PIO
mode harddrives, (hdparm -u 1 has no effect). aha152x is builtin to a
SoundBlaster card, and is at 0x140,11. SCSI devices are HP SureStore data
and Toshiba CDROM. 96MB System ram, no other processes to speak of
running. Software is RedHat 5.1 with needed package upgrades, and stock
2.1.121 plus my benchmarks compiled with gcc 2.7.2.3. The problem existed
in 2.0.32, RedHat 4.2 based system as well.
-- /==============================\ | David Mansfield | | david@cobite.com | | | | (212) 536-9115 | \==============================/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/