At 12:28 AM -0400 4/11/05, Nathan J. Williams wrote:
>I don't belive this is correct. As I mentioned, I added a simple
>printf() to vzeropage() that printed out both the pa it's trying to
>zero and the address of the pa variable - essentially, the location of
>the stack at that point. Here's some output:

Did you run any tests with Altivec not defined? We did, and found an additio=
nal
exception.

>Your analysis is flawed because the set of registers you see in DDB
>after a panic() reflects their state when panic() is called, not when
>the fatal trap happens. Stick a printf of frame->fixreg[9] before
>the panic("trap") in trap.c to see what I mean.

Calls into panic mucks registers, such that ddb can't restore them? That's
real useful for debugging. This needs to be filed as a PR. Gees, even
MacsBug from eight years ago wasn't this poor.

Beyond the few registers that are used for panic's output strings, why
would r9 get mucked before it could be recorded? That's really poor.

>instruction; it's a best-effort kind of thing. It may be a couple of
>instructions late, and I think that's happening here.

Quoting Programming Environment Manual, 32 bit, page 6-8:

=46or machine check exceptions, SRR0 holds either an instruction that would =
have
completed or some instruction following it that would have completed if the
exception had not occurred.

In my original analysis, I had already identified the instruction and
variable that you said was the problem, so it would appear that it is
giving the correct instruction. My analysis is apparently flawed, but I
identified what you did.

However, as you didn't reply to the original post, I get your point that I
am wasting my time and that I should wait until the cathedral builders
think there is a problem.

tim