Re: [XenPPC] current crash

[Orran Y Krieger <okrieg@xxxxxxxxxx>]

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