Date: Sat, 16 Mar 1996 14:45:36 -0500 (EST) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: altitude@petrified.cic.net (Alex Tang) Cc: freebsd-bugs@freebsd.org Subject: Re: npx0/Cyrix DLC486/Cyrix 80387 Message-ID: <199603161945.OAA12929@skynet.ctr.columbia.edu> In-Reply-To: <199603160334.WAA20882@petrified.cic.net> from "Alex Tang" at Mar 15, 96 10:34:43 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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.
=============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603161945.OAA12929>