Re: [XenPPC] current crash

[Jimi Xenidis <jimix@xxxxxxxxxxxxxx>]

On Aug 25, 2006, at 8:29 AM, Orran Y Krieger wrote:

> Certainly...  the test os maps itself in V==R, and it seems to have  
> a call
> to check for each entry before mapping it.
Recall the lineage of this code was for chip validation, so it does  
not surprise me that some wasteful tho validating
> 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.
I doubt that, but some of that libOS code was poorly written, some  
took liberties in the rhype/test directory.
> 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).
I assume you are speaking of DomU console output?
I'm not sure if there is anyway to force a flush since the system  
assumes no one is listening :(
> 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?
Yield does not do much other then allow something else to be  
scheduled, but you come right back and not necessarily running any  
other domain before you come back.
> This morning I decided to explore blocking the VCPU instead of  
> yielding.
Very good idea, this will block until you have an asynchronous  
interrupt.
That interrupt is eether and timer alarm you have programed or an  
evtchn.
In order for either of these to be delivered to you (in order to wake  
you from your block) the clokcing hcall will assert EE on. this is  
done in:
  include/asm-powerpc/event.h local_event_delivery_enable 49 static  
inline void local_event_delivery_enable(void )
> 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));
I need to study this a bit more, but it is important that your OS  
assert RI in its MSR anytime it is not in an "exception handling  
critical section" (my words).  Not sure if libOS even mamnages this  
bit, if not then just leave it on for now.
-JX




_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel