Date: Fri, 05 May 2000 14:07:33 -0600 From: Drew Eckhardt <drew@Poohsticks.Org> To: freebsd-smp@freebsd.org Subject: T_RESERVED prevention kludge Message-ID: <200005052007.OAA28764@chopper.Poohsticks.ORG>
next in thread | raw e-mail | index | archive | help
The following is against 4.0 stable, and includes Tor.Egge@fast.no's
mask unused APIC pins patch.
Before, half the time I couldn't build a kernel before I paniced. Now,
I can survive five make buildworld -j 5s.
Index: mpapic.c
===================================================================
RCS file: /usr/local/cvs/src/sys/i386/i386/mpapic.c,v
retrieving revision 1.37
diff -u -r1.37 mpapic.c
--- mpapic.c 1999/12/15 19:17:08 1.37
+++ mpapic.c 2000/05/05 19:08:45
@@ -168,6 +168,27 @@
for (pin = 0; pin < maxpin; ++pin) {
int bus, bustype, irq;
+ select = pin * 2 + IOAPIC_REDTBL0; /* register */
+ /*
+ * Always disable interrupts, and by default map
+ * pin X to IRQX because the disable doesn't stick
+ * and the uninitialize vector will get translated
+ * into a panic.
+ *
+ * This is correct for IRQs 1 and 3-15. In the other cases,
+ * any robust driver will handle the spurious interrupt, and
+ * the effective NOP beats a panic.
+ *
+ * A dedicated "bogus interrupt" entry in the IDT would
+ * be a nicer hack, although some one should find out
+ * why some systems are generating interrupts when they
+ * shouldn't and stop the carnage.
+ */
+ vector = NRSVIDT + pin; /* IDT vec */
+ io_apic_write(apic, select,
+ (io_apic_read(apic, select) & ~IOART_INTMASK
+ & ~0xff)|IOART_INTMSET|vector);
+
/* we only deal with vectored INTs here */
if (apic_int_type(apic, pin) != 0)
continue;
@@ -209,7 +230,6 @@
if (apic != 0 || pin != irq)
printf("IOAPIC #%d intpin %d -> irq %d\n",
apic, pin, irq);
- select = pin * 2 + IOAPIC_REDTBL0; /* register */
vector = NRSVIDT + irq; /* IDT vec */
io_apic_write(apic, select, flags | vector);
io_apic_write(apic, select + 1, target);
--
<a href="http://www.poohsticks.org/drew/">Home Page</a>
For those who do, no explanation is necessary.
For those who don't, no explanation is possible.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200005052007.OAA28764>