[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen randomly stuck in mdelay() during MP initialization

>>> On 11.01.12 at 15:51, Julian Pidancet <julian.pidancet@xxxxxxxxx> wrote:
> On Wed, Jan 11, 2012 at 1:28 PM, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
>> On 11/01/2012 13:06, "Julian Pidancet" <julian.pidancet@xxxxxxxxx> 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.

Running in x2apic mode, perhaps? (Despite having been asked
already, you still didn't really provide technical details about your
systems. Nor did you care to attach a log of the successful
attempt with -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 ?

Quite obviously the former delays by a number of milliseconds,
while the value passed to the latter is in microseconds.

> Does mdelay() relies on some form of timer to execute ?

No. mdelay() is simply a loop around udelay() - see


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.