Re: Xen randomly stuck in mdelay() during MP initialization

[Keir Fraser <keir@xen.org>]

On 11/01/2012 14:51, "Julian Pidancet" <julian.pidancet@gmail.com> wrote:

> On Wed, Jan 11, 2012 at 1:28 PM, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 11/01/2012 13:06, "Julian Pidancet" <julian.pidancet@gmail.com> wrote:
>> 
>>> Hi,
>>> 
>>> When trying to boot xen 4.1 on new hardware, Xen become stuck in
>>> wakeup_secondary_cpu() in the mdelay function.
>>> 
>>>     Dprintk("Waiting for send to finish...\n");
>>>     timeout = 0;
>>>     do {
>>>         Dprintk("+");
>>>         udelay(100);
>>>         if ( !x2apic_enabled )
>>>             send_status = apic_read(APIC_ICR) & APIC_ICR_BUSY;
>>>     } while ( send_status && (timeout++ < 1000) );
>>> 
>>>     printk("before mdelay\n");
>>>     mdelay(10);
>>>     printk("after mdelay\n");
>>> 
>>>     Dprintk("Deasserting INIT.\n");
>>> 
>>> The hang can happen randomly with any of the CPUs to wake up and
>>> sometime doesn't happen at all.
>>> Replacing mdelay(10) with udelay(10) seems to fix the issue.
>> 
>> Do you see this in xen-unstable? Hopefully it is working there, and we can
>> simply backport the fix.
>> 
> 
> I checked yesterday and the code of this function is the same in
> xen-unstable, but I don't encounter the problem with xen-unstable.

Well that would be because the code of this function is not the same in
xen-4.1 and xen-unstable.

> What concerns me is that this is the only place in the function where
> mdelay() is used, the rest of the function seems to be using udelay().
> What's the difference between the two ?
> Does mdelay() relies on some form of timer to execute ?

mdelay(ms) just calls udelay(1000) ms times.

 -- Keir