kdg@nirvo.uucp (Kurt Gollhardt) (12/11/89)
In article <78@calcite.UUCP> vjs@calcite.UUCP (Vernon Schryver) writes: >In article <1708@mtunb.ATT.COM>, jcm@mtunb.ATT.COM (John McMillan) writes: >> On an ATT-6386 running SVR3.2, the 387 problem is 'fixed' by adding >> the following to '/etc/conf/cf.d/stune' and re-building the kernel: >> >> DO387CR3 1 > >Can someone say precisely what the kernel work-around is? I've heard >of something like leaving the 387 marked absent or in other words continueing >to "emulate" 387 instructions, and in the "emulator" doing strange and >slow stuff before actually doing the ESC+etc. That would be one way to work around the bug (80386 B1-stepping Errata 21), but it would be painfully slow. The DO387CR3 workaround takes advantage of a subtle point mentioned by the Errata, that the problem does not occur if the physical address of the Page Directory is at least 0x80001000. DO387CR3 will only work if your hardware supports "A31-aliasing", that is, memory accesses ignore the high address bit. The CPU's Page Directory Register (CR3) is loaded with the address of the page directory (usually 0x2000) *plus* 0x80000000. Due to the aliasing, this refers to the same memory location, but it satisfies the >= 0x80001000 constraint, and the bug doesn't occur. This workaround adds *no* extra cycles to the running system. On machines without A31-aliasing, setting DO387CR3 will prevent the system from booting. No software workaround is provided (at least in AT&T's product), for such machines. You'll have to use a hardware workaround, or replace your 386. Note: In SVR4, the system will automatically detect if DO387CR3 is necessary and A31-aliasing is present, so you won't have to worry about whether to set it or not. -- Kurt Gollhardt \ Nirvonics, Inc. -- Plainfield, NJ Kurt.Gollhardt@nirvo.uucp /\ Software Design and Consulting ...!rutgers!nirvo!Kurt.Gollhardt / \ "It's all about people; not you and me or him and her, but *us*."