On Thu, Jul 03, 2008 at 09:27:31PM +0900, Isaku Yamahata wrote:
> On Thu, Jul 03, 2008 at 08:50:56PM +1000, Simon Horman wrote:
> > Hi,
> >
> > I have been looking over the SAL manual and looking into where
> > exactly the lockup that I am seeing occurs.
> >
> > What seems to happen is this.
> >
> > If ia64_mca_cpe_int_caller() is called from vmx context (is that the
> > right word?) then when it calls ia64_log_queue() which in turn calls
> > ia64_sal_get_state_info() then as the SAL_GET_STATE_INFO call is being
> > made (I'm pretty sure that it is inside the firmware)
> > ia64_mca_ucmc_handler() is invoked. I presume that this is because an
> > unrecoverable machine check occurs during the SAL_GET_STATE_INFO call.
> >
> > The call to ia64_mca_ucmc_handler() seems to complete successfully
> > (including a call to ia64_sal_get_state_info() via ia64_log_queue()).
> > Just after that the hypervisor locks up, presumably because execution
> > goes back to the original SAL_GET_STATE_INFO call that caused the
> > unrecoverable machine check.
> >
> > With regards to rr7. It is not set to EFI RR when entering
> > ia64_mca_cpe_int_caller(), but it is when entering
> > ia64_mca_ucmc_handler(), which makes sense, as it should be set when
> > going into the first SAL_GET_STATE_INFO call.
>
> That's great.
> Table 9-2 SAL spec says that SAL_GET_STATE_INFO is NOT reentrant,
> the above explains why the hypervisor locks up.
I see, good point.
> > My latest micro-hack involves having ia64_sal_get_state_info() return 0,
> > without going into SAL, if VMX_DOMAIN(current) is true, which seems to
> > work.
> >
> > I will ponder the SAL manual some more to try and work out why
> > EFI RR + VMX (+ IRQ?) + SAL_GET_STATE_INFO -> bad
>
> Yes, now the next question is why the mca occurs and
> whether it can/should be avoided.
Yes, I agree. That is the question I need to investigate.
> Is it possible to determine what mca occurs?
> The mca record might be in nvram, if so there should be a way
> to retrieve them.
Good idea, I will check tomorrow.
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home