Re: Fwd: newb question : list of elligible computers to debian-68k
On Thu, Oct 16, 2008 at 03:09:06PM +1100, Finn Thain wrote:
> '040 FPU emulation works, but some 68LC040 chips have a bug that screws it
> up (but rumour has it that you have to use swap to encounter the problem).
Well, swap probably makes it more likely. My understanding is that the
bug requires two things: a software trap (FPU emulation or otherwise)
caused by an instruction in the last word of a page and the next page
not being present in RAM causing a page fault. I believe this causes
the CPU to lose one of the exceptions (there should be an emulation
trap followed by a page fault). It's my impression that the prefetch
causes the page fault to happen too early and corrupt the chip state.
The demand-paged nature of executables should be able to trigger this
bug on the first time through even without swap.
Motorola definitely fixed the bug at some point, but my understanding
is that Apple didn't use the newer chip revisions in very many boxes.
I will note that this bug is known to affect the line-A trap that the
classic Mac system uses for system calls. Apple had a workaround for
this bug for line-A but not for FPU emulation.
> The problem is, we don't have a conclusive test for the presence or
> absence of the CPU bug.
It should be possible to artifically create the correct situation. I'm
just not sure I have any hardware subject to the bug. The PB190 is the
only 68LC040 system I have, and that's a very late 68k system and most
likely has a fixed chip due to that. Supposedly the bug affected full
68040 chips as well, although obviously any FPU instructions available
in hardware can't trip it. Most likely it could be done with one of
the opcodes they didn't implement in the 68040 FPU that are always
done with software on the built-in FPU. An A-line opcode could be
used for this purpose as well, and might be simpler due to the fact
that we don't actually use those or do anything with them other than
flag it as an illegal instruction.
The idea would be to create a pair of consecutive executable pages full
of some valid but useless code (probably NOPs), then put an instruction
at the end of the first page that will cause one of the traps. The
second page must be setup in a way that it is not present and will
cause a page fault. Then if you start running the code in the first
page, it should cause both the emulation trap and the page fault on
a good CPU. If you miss one, it's a broken CPU. It would most likely
need to be done in an isolated thread to be safe.
Brad Boyer
flar@allandria.com
Reply to: