Date: Tue, 20 May 1997 12:09:40 +0800 From: Peter Wemm <peter@spinner.DIALix.COM> To: Jason Thorpe <thorpej@nas.nasa.gov> Cc: dg@root.com, Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>, freebsd-hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: trap type 29 on P6 Message-ID: <199705200409.MAA28246@spinner.DIALix.COM> In-Reply-To: Your message of "Mon, 19 May 1997 20:11:37 MST." <199705200311.UAA19076@lestat.nas.nasa.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
Jason Thorpe wrote: > On Mon, 19 May 1997 19:43:58 -0700 > David Greenman <dg@root.com> wrote: > > > Is the instruction right before this one an inb or outb? I've seen this > > before on P6 machines... > > Saw something similar to this on similar hardware under NetBSD, although > it was the serial port initialization that tickled it. IIRC, that's a > "reserved trap" in Intel lingo... (I think... pardon if I'm wrong, since I'm > neither an export on nor a fan of the x86 "architecture" :-) > > As I understand it, what basically happens is some buggy bit of hardware > (say, an I/O combo ASIC) signals an interrupt but drops it again before > the PIC can latch it... per the interrupt protocol, the PIC has to post > an interrupt to the CPU, and for hysterical raisins, picks "default IR7". > Apparently, this happens to map to a reserved trap vector :-) Under FreeBSD, the IDT vector number for irq7 is 39, not 29.. The PIC's are programmed to use 32 through 47 (under non-SMP). > There's not much you can do about it, really... you can't really stop the > condition from occurring, short of publicly flogging purveyors of broken > hardware (and it's not clear that'll help anyhow). It was fixed in > NetBSD-current some time ago by catching and ignoring this particular > reserved trap vector. We do to, we log it as a 'stray irq' - and have done this for quite some time - right back to FreeBSD 2.0.5 as far as I can tell, possibly further. Apparently, it's possible to detect the difference between a real irq7 and a stray irq7 by checking the in-service bit before the EOI is sent (AUTO_EOI has to be turned off), but nobody has been bothered enough to implement it. I think this is different to the problem that you describe. Here we're getting trap 29 which: [..] #define T_STKFLT 27 /* stack fault */ #define T_MCHK 28 /* machine check trap */ #define T_RESERVED 29 /* reserved (unknown) */ I wonder if the inb confused the P6 instruction sequencing or something? > Gotta love PCs. Amen to that though. :-) > Jason R. Thorpe thorpej@nas.nasa.gov > NASA Ames Research Center Home: 408.866.1912 > NAS: M/S 258-6 Work: 415.604.0935 > Moffett Field, CA 94035 Pager: 415.428.6939 Cheers, -Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705200409.MAA28246>