From owner-freebsd-bugs Sat Mar 16 11:45:54 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA26494 for bugs-outgoing; Sat, 16 Mar 1996 11:45:54 -0800 (PST) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA26487 for ; Sat, 16 Mar 1996 11:45:50 -0800 (PST) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id OAA12929; Sat, 16 Mar 1996 14:45:37 -0500 From: Bill Paul Message-Id: <199603161945.OAA12929@skynet.ctr.columbia.edu> Subject: Re: npx0/Cyrix DLC486/Cyrix 80387 To: altitude@petrified.cic.net (Alex Tang) Date: Sat, 16 Mar 1996 14:45:36 -0500 (EST) Cc: freebsd-bugs@freebsd.org In-Reply-To: <199603160334.WAA20882@petrified.cic.net> from "Alex Tang" at Mar 15, 96 10:34:43 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Of all the gin joints in all the world, Alex Tang had to walk into mine and say: > Hi folks. > > I've got an Intel i386/33 with a Cyrix 387 running FreeBSD-2.1.0-RELEASE. > (run's great, no problems). I was given a Cyrix DLC-486/33 Chip by a > friend. the problem is that when I put the 486 and the 387 in the box at > the same time, FreeBSD won't boot, it stops right after checking npx0. > The 486 chip works fine without the 387. Is this a FreeBSD problem, or am > I just an idiot who's forgotten something. I had this problem with my old 386sx/16 and 387 system. Both chips are made by Intel, but for some reason, executing an fnsave instruction would cause my system to wedge. (The npx.c code does an fnsave as during boot as part of the FPU initialization, and again in the interrupt handler. Debugging showed that it was hanging right at the first fnsave.) This was true of FreeBSD, NetBSD and even 386bsd 0.1. The only way I could get the system to boot was by removing the 387 chip. Annoyingly enough, I used to be able to run Linux on the same machine just fine. Anyway, after some tinkering, I came up with the following patch to /sys/i386/isa/npx.c: 71c71 < #define fnsave(addr) __asm("fnsave %0" : "=m" (*(addr))) --- > #define fnsave(addr) __asm("fnsave %0; fninit" : "=m" (*(addr))) All this does is cause an fninit instruction to be executed immediately after the fnsave instruction. This fixed most of my problems and allowed me to boot FreeBSD on the 386sx system without any trouble. (I've had to do this for every version of FreeBSD since 1.1.) The strange thing is that the fnsave instruction is also supposed to perform an fninit, so in theory this step shouldn't be needed. But without it, I'm toast. Note that this is not a real fix since it is still possible for a user-level program to wedge the system again by executing an fnsave instruction by itself. (Bruce Evans once sent me a sample program to excersize the 387 that can do it.) Also, I have yet to find another machine exhibiting the same behavior where this change made any difference. So far, it seems specific to my hardware, which is why I normally add it to my sources with an #ifdef SKYNET around it. Anyway, try this: put the 387 chip back in and boot with the -c flag. At the userconfig menu, disable npx0 and then try to continue booting. This is what I do to install new versions of FreeBSD on the 386 these days; disabling npx0 allows the kernel to boot and gives me a chance to patch npx.c. Try doing the same: add the fninit instruction and recompile the kernel. Then try booting the new kernel with npx0 enabled. If you're having the same hardware problem I am, it might just work this time. If it doesn't you might consider adding some debugging printf()s to the npx initialization code to see where it is hanging. This is how I originally traced down my problem. Hope this helps. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= License error: The license for this .sig file has expired. You must obtain a new license key before any more witty phrases will appear in this space. =============================================================================