Date: Thu, 12 Sep 1996 05:15:00 +1000 From: Bruce Evans <bde@zeta.org.au> To: dg@Root.COM, kato@eclogite.eps.nagoya-u.ac.jp Cc: current@FreeBSD.org Subject: Re: patch for Cyrix/Ti 486SLC/DLC CPU bug Message-ID: <199609111915.FAA08571@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>CR2 might be modified by hardware interruption before it is read. The
>contributor of the trap.c modification observed:
>
> 1: CR2 register equals to 0 when it is read in trap_pfault().
> 2: The core dump shows CR2 should not be 0.
> 3: He change trap gate into interrupt gate, CR2 shows correct
> address.
>
>These observation imply the interruption breaks CR2. This is the
>reason for the modification in machdep.c.
It would be better to read %cr2 early in _Xpage and disable interrupts
there:
_Xpage:
pushl $T_PAGEFLT
pushal
movl %cr2,%eax
sti
/*
* Continue as before, except the copy of %cr2 must somehow be
* passed through trap() to the pagefault handler.
*/
I've never liked filtering all exceptions through trap(). It would be
just as easy and a little faster to call trap_pfault() directly here
(easier except you have to repeat a few lines of book-keeping from
trap()).
Several other exceptions should use interrupt gates because interrupts
may be harmful:
Breakpoints and Debug Exceptions: it should be a debugger option (defaulting
to off) to allow interrupts.
NMI's: further NMI's are masked until the next `iret'. Interrupts should
be masked so that the next `iret' is for the NMI handler and not for
an interrupt.
>> > 3) The functions pmap_update_{1,2}pg don't use LMSW instruction
>> > but call pmap_update in cpufunc.h (pmap.c).
>>
>> Is this because the Cyrix chip doesn't support selective TLB updates?
>
>Sorry, I lost Cyrix's data book and I couldn't check official
>information. I think Cyrix chip supports selective TLB update, but it
>may have bug and LMSW instruction fails in some cases. I think this
>depends on the version of CPU because some Cyrix machines works without
>pmap.c change.
pmap_update() actually stores to %cr3. Thus has nothing to do with LMSW,
which loads from %cr0. I guess the problem is in the non-386 case of
pmap_update_{1,2}pg(). The magic .byte's are a bad way of writing
`invlpg' (even gas understands this).
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609111915.FAA08571>