Date: Fri, 14 Jul 2000 10:00:23 -0600 From: Steve Passe <smp@timing.com> To: Warner Losh <imp@village.org> Cc: Paul Saab <ps@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/i386 trap.c Message-ID: <200007141600.KAA00892@Ilsa.StevesCafe.com> In-Reply-To: Your message of "Fri, 14 Jul 2000 09:28:08 MDT." <200007141528.JAA36004@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> In message <200007141149.EAA96783@freefall.freebsd.org> Paul Saab writes: > : This will solve the problem with having DDB enabled and getting an > : NMI due to some possibly bad error and being able to continue the > : operation of the kernel when you really want to panic and know > : what happened. > > Does this work on all motherboards? Steve Passe wrote similar code a > long time ago, which i dusted off and tried to submit. Both Steve and > bde were worried that it was too motherboard and/or chipset dependent. > > Warner > My quick look at trap.c doesn't show anything related to the issues you bring up. The issues addressed by my old code were related to catching the SECOND NMI. Specifically, motherboard hardware has to be recocked after an NMI to catch following NMIs. I saw nothing in intr_machdep.c:isa_nmi() that attempts to do this yet... The rub with doing it properly is that there are MANY variations in the way hardware is setup to do this, and none of it is very well documented (if at all). The BIOS initially handles NMI, and the typical "handling" is: NMI, F1 to disable and continue, RETURN to reboot. My old code does do it successfully on PIIX style chipsets, we have apps that reliably catch NMI every second (high precision pps synchronization). -- Steve Passe | powered by smp@timing.com | Symmetric MultiProcessor FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200007141600.KAA00892>