This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [XenPPC] current crash

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

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                                                  
             .com>                                                      To 
                                       Orran Y Krieger/Watson/IBM@IBMUS    
             08/25/2006 07:08                                           cc 
             AM                        xen-ppc-devel@xxxxxxxxxxxxxxxxxxx,  
                                       Jimi Xenidis/Watson/IBM@IBMUS       
                                       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?


Xen-ppc-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>