Subject: Re: DANGER WILL ROBINSON
To: Ross Harvey <firstname.lastname@example.org>
From: Chris G. Demetriou <email@example.com>
Date: 05/21/1998 11:56:33
> Having said all that, no one knows why we get that warning (complaining
> that FEN is set in the new process) when a blue moon occurs on a
> tuesday. I've read through all the related code and it certainly
> seems to DTRT at each point.
So, the only thing that i've ever been able to think of is that the
Green Book says that reading the bit in this way is a no-no.
In particular, page II-B 4-2 (god, I love these page numbers... NOT!
>The swapctx instruction returns ownership of the current PCI to the
>operating system software and passes ownership of the new PCB from the
>poerating system to the processor. Any attempt to write a PCB while
>ownership resides with the processor has UNDEFINED results. If the
>PCB is read while ownership resides with the processor, it is
>UNPREDICTABLE whether the original or an updated value of a field is
>read. The processir is free to update a PCB field at any time. The
>decision as to whether or not a field is updated is made invididually
>for each field.
In other words, the green book says "don't expect that check to have a
predictable result." However, I think Ross has indicated privately in
the past that the PALcode seems to the 'expected' thing regarding the
setting of the FEN flag in the PCB. (Ross, can you confirm that?)
What i'd like to know is, why does the warning happen _so_
unpredictably, and can anything be done to make it more predictable?