Date: Fri, 5 Apr 1996 00:08:01 -0800 (PST) From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> To: root@deadline.snafu.de (Andreas S. Wetzel) Cc: current@FreeBSD.org Subject: Re: tty-level buffer overflows - what to do? Message-ID: <199604050808.AAA08441@GndRsh.aac.dev.com> In-Reply-To: <m0u53H9-0009QNC@deadline.snafu.de> from "Andreas S. Wetzel" at "Apr 5, 96 06:37:31 am"
next in thread | previous in thread | raw e-mail | index | archive | help
[CC: trimmed.. it was getting a bit long...]
> Hi!
> ---
>
> Bruce Evans writes:
>
> ] The cause has to be a signal on one of the IRQ lines enabled by FreeBSD
> ] (because masked lines are completely ignored). The signal can then interfere
> ] with the signal from the enabled board.
>
> But what card could generate such IRQ? The problem seems to occur _only_
> during boot at about the time when fsck gets run and a second time a bit
> later when some of the daemons get started.
See my other mail, IRQ7 is the default interrupt generrated if _any_ of
your enabled (clause added to keep Bruce happy) interrupt signals are
asserted then deasserted before the INTA cycle from the CPU.
>
> A vmstat -i says:
[Thanks! This is what I needed to nail your problem with an 87% certainty
of being correct]
>
> interrupt total rate
> clk0 irq0 2039463 100
> rtc0 irq8 2610423 127
> wdc0 irq14 17877 0
> fdc0 irq6 1 0
> sc0 irq1 1 0
> sio0 irq4 1657 0
> sio1 irq3 283893 13
> sio2 irq9 1539814 75
^^^ are you REALLY doing that much I/O on sio2?
> sio3 irq5 25268 1
> ed0 irq12 171733 8
> stray irq7 5032 0
> Total 6695162 328
I highly suspect you have a video card also sitting on IRQ9 (aka IRQ2) and
it is asserting a 60 to 72Hz video refresh interrupt, and do to conflicts
with SIO2 is infact on occasion glitching IRQ9 causing a stray interrupt 7.
> The rate for irq7 is 0, so I think it hasn't recently occured anymore since
> bootup.
Do this immediately after a reboot (preverably add this to /etc/rc.local):
vmstat -i >/var/tmp/vmstat.atboot
Then after being up for 2 or 3 hours do another vmstat -i >/var/tmp/vmstat,
take a look to see if your got any more while the system was up.
Also if you can stop using sio2 for a day and see if the problem goes away.
Also check your video card for a trace going to bin B4, if it is connected
to something check your card for an IRQ2/9 jumper. Try another video card
that either has the jumper or has no connection to pin B4.
> The problem happened with all kernels I used on the machine til now. That
> included the original 2.2-SNAPSHOT installation kernel, the 2.1.0 RELEASE
> installation kernel as well as several kernels I built specifically for
> this machine from actual -current sources.
>
> What _really_ made me wonder was that when I used another IDE/FD controller
> the problem was gone. But the controller card I use on this machine
> a) has no physical connection to the irq 7 line and
Does not matter, any glitch on IRQ{0,1,3,4,5,6,8,9,12,14} will do the
deed. Probably IRQ14 for the IDE channel, many small inexpensive IDE
controllers do not buffer the signals between the ISA backplane and the
ribbon cable and this is a major source of noise on IRQ14.
> b) has been in use
> for a long time on another machine running -current and did never cause
> any problem like that.
The other machine probably has better schmitt trigger thresholds on the
IRQ inputs to the chipset.
> And apart from that the only irq's that this card
> should ever generate should be irq 14 and irq 6 (It's a pure controller
> card, no I/O interfaces are on that board).
See above...
>
> Well... any ideas how to get rid of that stray irq?
Having fixed about 20 or so machines with this problem and given the data
up to this point I am 99% confident it is one of two things, a cheap
unbuffered IDE I/O controller or a conflict between your video card
and SIO2 on interrupt 9.
--
Rod Grimes rgrimes@gndrsh.aac.dev.com
Accurate Automation Company Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604050808.AAA08441>