[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Fwd: newb question : list of elligible computers to debian-68k



Hi,

That would indeed vastly complicate matters. Are you sure the unreliable
bug isn't due to the page in question having been mapped in nonetheless?

No. Would the kernel map 16 or 17 pages following a mmap? Maybe glibc is
causing them to be paged in too early?

16 or 17 pages - maybe not. OTOH, if we get the F-line trap before the page fault, all is well.

But this is a secondary problem anyway.

No idea what to do about (1). Since I don't understand the
implications of "overlapped execution", I can't hazard a guess as to
whether this kind of fix is even theoretically feasible.

What this means is that one instruction is in the process of being
executed while another one is being loaded and decoded at the same time.

That's what I thought.

Loading it would trigger the page fault while executing of the previous
one had triggered the unimplemented instruction exception just
previously. Only guessing here...

Thing is, we have to know exactly what the saved PC will be when either,

a. ATC fault at unimplemented fpu op and bug may or may not take effect

Bug takes effect - the PC is what we need.

Bug does not take effect - the PC is that of the instruction causing the page fault, i.e. identical to the fault address (ISTR instruction execution always completes before trap or page fault in the normal case, and the trap must've completed otherwise we'd see the PC point to the FPU opcode)

b. ATC fault with no unimplemented fpu op

PC is equal to fault address.

The point I was trying to make is that only for (a) is the saved PC
determined (that's what the docs I quoted tell me, anyway). Which means,
the fault handler can't tell (a) and (b) apart.

It all hinges on the behavior in the case where the bug isn't properly triggered. If the PC points to the same page as the fault address in that case, we're fine, i.e.

if (page_of(PC) < page_of(fault_addr) && is_fpu_op(PC)
	need_fixup;

would be possible.

Your test kernel would be the ideal candidate to test whether there ever is a case where the F-line trap was taken correctly, yet the PC still reported on the wrong page afterwards.

	Michael


Reply to: