Messages in this thread | | | Date | Sat, 19 Sep 1998 16:07:28 -0400 (EDT) | From | David Mansfield <> | Subject | driver irq handler latency |
| |
Hello,
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/
| |