Certainly... the test os maps itself in V==R, and it seems to have a call
to check for each entry before mapping it. Seems kinda silly... but the
code has a ton of ifdefs for processors with software loaded TLB.... very
yucky, and I have a feeling that the code was cut and pasted a couple of
times.
Debugging was a pain, since printfs where not flushed... so 10 minute cycle
time for rebooting to do a binary search with a while(1). Tried two things
to help me debug, might be of value to discuss. First, I tried yielding
the processor a few hundred times after each printf. This didn't help at
all. I have a feeling that the problem here is that I am only writting to
event channel, not consuming events, so the yeild doesn't actually yield
the processor. Is this worth exploring?
This morning I decided to explore blocking the VCPU instead of yielding.
It resulted in a BUG_ON in Xen in external.c line 63
/* XXX OS error: EE was set but RI was not. We could trigger a machine
* check, or kill the domain... for now just crash Xen so we notice. */
BUG_ON(!(regs->msr & MSR_RI));
Jimi Xenidis
<[EMAIL PROTECTED]
.com> To
Orran Y Krieger/Watson/[EMAIL PROTECTED]
08/25/2006 07:08 cc
AM xen-ppc-devel@lists.xensource.com,
Jimi Xenidis/Watson/[EMAIL PROTECTED]
Subject
Re: [XenPPC] current crash
On Aug 25, 2006, at 12:17 AM, Orran Y Krieger wrote:
>
> Been doing a binary search to find at least one of the things
> causing a crash. What I have now is that the following call from
> libOS reliably crashes xen.
>
> the call is:
> rc = hcall_read(ret, flags, idx + i);
> In the library OS , with parameters:
> flags - 0, idx = 0 ret = 240948
Thanks Orran.
A little cscope'ing reveals, arch/powerpc/papr/xlate.c:
__init_papr_hcall(H_READ, not_yet);
static void not_yet(struct cpu_user_regs *regs)
{
printk("not implemented yet: 0x%lx\n", regs->gprs[3]);
for (;;);
}
Obviously not_yet() was written before we had a proper panic() and
before we "de-synchronized" console.
Linux does not use H_READ anymore, but we should still supported,
I'll get on that now, tho I'll need your help to test.
Any idea why libOS is using it?
-JX
_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@lists.xensource.com
http://lists.xensource.com/xen-ppc-devel
