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>