From owner-freebsd-current Fri Apr 5 00:08:17 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id AAA02445 for current-outgoing; Fri, 5 Apr 1996 00:08:17 -0800 (PST) Received: from GndRsh.aac.dev.com (GndRsh.aac.dev.com [198.145.92.241]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id AAA02439 for ; Fri, 5 Apr 1996 00:08:11 -0800 (PST) Received: (from rgrimes@localhost) by GndRsh.aac.dev.com (8.6.12/8.6.12) id AAA08441; Fri, 5 Apr 1996 00:08:02 -0800 From: "Rodney W. Grimes" Message-Id: <199604050808.AAA08441@GndRsh.aac.dev.com> Subject: Re: tty-level buffer overflows - what to do? To: root@deadline.snafu.de (Andreas S. Wetzel) Date: Fri, 5 Apr 1996 00:08:01 -0800 (PST) Cc: current@FreeBSD.org In-Reply-To: from "Andreas S. Wetzel" at "Apr 5, 96 06:37:31 am" X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk [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