From owner-freebsd-smp Wed Mar 26 03:24:35 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA03666 for smp-outgoing; Wed, 26 Mar 1997 03:24:35 -0800 (PST) Received: from corona.jcmax.com (corona.jcmax.com [204.69.248.2]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id DAA03661 for ; Wed, 26 Mar 1997 03:24:33 -0800 (PST) Received: by corona.jcmax.com (5.65/2.49G/4.1.3_U1) id AA22145; Wed, 26 Mar 97 06:24:31 -0500 Date: Wed, 26 Mar 97 06:24:31 -0500 From: cr@jcmax.com (Cyrus Rahman) Message-Id: <9703261124.AA22145@corona.jcmax.com> To: smp@freebsd.org Subject: APIC_IO and the fpu Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> >It looks to me that the problem with the fpu stuff might be more a >> >function of FPU error handling (irq13 vs. IDT trap #16) rather than just >> >plain floating point operations... >> >> I agree, and think that someone could find it by examining what goes on >> in i386/isa/npx.c:mpxintr(). > >A further thought, its possible that it could be APIC_IO related, could >someone run this program on both an APIC_IO and non APIC_IO kernel >to see if it locks both (I don't have an SMP machine anymore)? > >> ======================================================================== >> #include >> #include >> void blech() { exit(3); } >> main() >> { >> int i32; >> double f; >> int result = 0; >> signal(SIGFPE, blech); >> >> f = (double) 0x7fffffff; >> f = 10 * f; >> i32 = (int) f; >> >> if (i32 != (int) f) >> result |= 1; >> exit(result); >> } >> ======================================================================== > >-- >Steve Passe | powered by >smp@csn.net | FreeBSD >The code runs fine with APIC_IO off, but locks the machine up quite nicely >with it on. I'm not sure what causes the problem yet... Hmm, since this is exactly the opposite of what I actually found out, I should probably go home and get some sleep before continuing this note, but in the interest of not creating more confusion: In fact, the code locks up the machine with or without APIC_IO on, but only if the second processor is activated. The reason that I'm bringing it up is that the fpu lockup symptoms are very similar to the lock up I've been experiencing with high interrupt rates; this problem only occurs with APIC_IO on (and smp_active = 2). If anyone's found any clues about the fpu problem that might offer some insight into this other problem please let me know. Cyrus