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

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

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.

Xen-ppc-devel mailing list

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