From owner-freebsd-bugs Mon May 19 21:16:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA09528 for bugs-outgoing; Mon, 19 May 1997 21:16:22 -0700 (PDT) Received: from spinner.DIALix.COM (spinner.dialix.com [192.203.228.67]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA09516; Mon, 19 May 1997 21:16:07 -0700 (PDT) Received: from spinner.DIALix.COM (localhost.dialix.com.au [127.0.0.1]) by spinner.DIALix.COM with ESMTP id MAA28246; Tue, 20 May 1997 12:09:43 +0800 (WST) Message-Id: <199705200409.MAA28246@spinner.DIALix.COM> X-Mailer: exmh version 2.0gamma 1/27/96 To: Jason Thorpe cc: dg@root.com, Kazutaka YOKOTA , freebsd-hackers@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: trap type 29 on P6 In-reply-to: Your message of "Mon, 19 May 1997 20:11:37 MST." <199705200311.UAA19076@lestat.nas.nasa.gov> Date: Tue, 20 May 1997 12:09:40 +0800 From: Peter Wemm Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jason Thorpe wrote: > On Mon, 19 May 1997 19:43:58 -0700 > David Greenman 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