Re: [Xen-devel] Re: [PATCH] SMP dom0 boot fix

[Ryan Harper <ryanh@xxxxxxxxxx>]

* Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> [2005-10-28 09:20]:
> 
> On 28 Oct 2005, at 02:05, Kamble, Nitin A wrote:
> 
> >    This patch reverts part of the 7402 patch. The reverted part is
> >conversion from unsigned long to uint32_t for evtchn_pending,
> >evtchn_mask.
> 
> That was the original *point* of the patch, so yours is basically the 
> anti-patch.
> 
> I can take a look... what is the bad SMP dom0 behaviour you are seeing 
> (is there a bugzilla reference)?

I'll file a bug if Nitin doesn't beat me to it.  I was seeing
smp_call_function() blocking while it waited for a function to return
from being invoked on the second processor in early boot.  

It would block forever installing the deadline io scheduler, digging
deeper, it was after the second processor was up, and the io schedulers
call kmem_cache_create() in mm/slab.c, which would eventually result in
a call to smp_call_function() and passed in wait=1 which forces the
function to block until it has run on all online processors.

WARK: CPU0 in enable_cpucache()
WARK: CPU0 do_tune_cpucache() in
WARK: CPU0 calling all cpus with do_ccupdate_local()
WARK: CPU0 smp_call_function_all_cpus()
WARK: CPU0 running do_ccupdate_local()
WARK: CPU0 invoking smp_call_function()

At this point send_IPI_allbutself() has been invoked and the system
just sits and waits on CPU1 to run the function.  But, CPU1's
evtchn_upcall_mask was set (1), so I'm guessing the pending interrupt
is never acknowledged.  

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh@xxxxxxxxxx

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