Re: non reliable nmi
On Thu, 28 Aug 2003, Don Bowman wrote: I have machdep.ddb_on_nmi=1. I can drop into the debugger with the magic key sequence. However, when i hit the NMI jumper, i don't always go there. Sometimes I do. The system is 4-way SMP [2xHTT xeon processors] with 4.7. Any suggestion on where my NMI might be going? Is your NMI about 106K in size, and does it have the subjects Thank you, Wicked screensaver and others? If so, I think I know where it's going... Mike Silby Silbersack ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: non reliable nmi
From: Mike Silbersack [mailto:[EMAIL PROTECTED] On Thu, 28 Aug 2003, Don Bowman wrote: I have machdep.ddb_on_nmi=1. I can drop into the debugger with the magic key sequence. However, when i hit the NMI jumper, i don't always go there. Sometimes I do. The system is 4-way SMP [2xHTT xeon processors] with 4.7. Any suggestion on where my NMI might be going? Is your NMI about 106K in size, and does it have the subjects Thank you, Wicked screensaver and others? If so, I think I know where it's going... ? it was actually a serious question. The nmi header on my board goes into the ICH-3 of my chipset, but shorting the jumper out doesn't always enter the debugger. It does sometimes. If I set the NMI_NOW bit in the ICH-3 I always enter the debugger. I was curious if anyone else had seen this behaviour. --don ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: non reliable nmi
On Thu, Sep 04, 2003 at 09:16:23AM -0400, Don Bowman wrote: From: Mike Silbersack [mailto:[EMAIL PROTECTED] On Thu, 28 Aug 2003, Don Bowman wrote: I have machdep.ddb_on_nmi=1. I can drop into the debugger with the magic key sequence. However, when i hit the NMI jumper, i don't always go there. Sometimes I do. The system is 4-way SMP [2xHTT xeon processors] with 4.7. Any suggestion on where my NMI might be going? Is your NMI about 106K in size, and does it have the subjects Thank you, Wicked screensaver and others? If so, I think I know where it's going... ? it was actually a serious question. The nmi header on my board goes into the ICH-3 of my chipset, but shorting the jumper out doesn't always enter the debugger. It does sometimes. If I set the NMI_NOW bit in the ICH-3 I always enter the debugger. I was curious if anyone else had seen this behaviour. I haven't kept quite up to date on my x86 hardware lately (read: in the past five to ten years), but I distinctly remember a time when everyone referred to x86's NMI as a joke: a non-maskable interrupt that anyone could mask using a simple CLI instruction. Not sure if this is still the case, others would have to say if today's processors still may get so wedged that a NMI request would simply be ignored. The other possibility is some kind of kernel mess-up, bad enough that an NMI does indeed reach the processor, the processor does invoke the NMI handler, yet the handler (DDB) is quite unable to actually do any useful work - messed up data structures and such. G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence no verb. pgp0.pgp Description: PGP signature
Re: non reliable nmi
In [EMAIL PROTECTED], on 09/04/03 at 09:12 AM, Peter Pentchev [EMAIL PROTECTED] said: I haven't kept quite up to date on my x86 hardware lately (read: in the past five to ten years), but I distinctly remember a time when everyone referred to x86's NMI as a joke: a non-maskable interrupt that anyone could mask using a simple CLI instruction. Not sure if this is still the case, others would have to say if today's processors still may get so wedged that a NMI request would simply be ignored. CLI doesn't stop an NMI, but you can mask off NMI in the CMOS RAM. On standard PC-AT platforms anyway. -- Clark ** This email, and any files transmitted with it, are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please advise [EMAIL PROTECTED] ** ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: non reliable nmi
On 04-Sep-2003 [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], on 09/04/03 at 09:12 AM, Peter Pentchev [EMAIL PROTECTED] said: I haven't kept quite up to date on my x86 hardware lately (read: in the past five to ten years), but I distinctly remember a time when everyone referred to x86's NMI as a joke: a non-maskable interrupt that anyone could mask using a simple CLI instruction. Not sure if this is still the case, others would have to say if today's processors still may get so wedged that a NMI request would simply be ignored. CLI doesn't stop an NMI, but you can mask off NMI in the CMOS RAM. On standard PC-AT platforms anyway. The bug is probably in FreeBSD in that we mask the NMI LVT entry in the local APIC on all the APs and only leave it enabled in the BSP. Thus, if your NMI gets sent to one of the APs, it is effectively ignored. You can try fixing this in mpapic.c like so: Index: mpapic.c === RCS file: /usr/cvs/src/sys/i386/i386/mpapic.c,v retrieving revision 1.64 diff -u -r1.64 mpapic.c --- mpapic.c25 Aug 2003 09:48:47 - 1.64 +++ mpapic.c4 Sep 2003 18:40:47 - @@ -74,7 +74,9 @@ /* setup LVT2 as NMI, masked till later... */ temp = lapic.lvt_lint1; temp = ~(APIC_LVT_M | APIC_LVT_TM | APIC_LVT_IIPP | APIC_LVT_DM); - temp |= 0x00010400; /* masked, edge trigger, active hi */ + temp |= 0x0400; /* edge trigger, active hi */ + if (PCPU_GET(cpuid) == 0) + temp |= APIC_LVT_MSET; /* masked till later */ lapic.lvt_lint1 = temp; -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
non reliable nmi
I have machdep.ddb_on_nmi=1. I can drop into the debugger with the magic key sequence. However, when i hit the NMI jumper, i don't always go there. Sometimes I do. The system is 4-way SMP [2xHTT xeon processors] with 4.7. Any suggestion on where my NMI might be going? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
