From mboxrd@z Thu Jan 1 00:00:00 1970 From: Igor Mammedov Subject: Re: Xen randomly stuck in mdelay() during MP initialization Date: Wed, 11 Jan 2012 15:53:09 +0100 Message-ID: <4F0DA255.2030703@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 01/11/2012 02:06 PM, Julian Pidancet 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. > Essentially the same issue, check out http://article.gmane.org/gmane.comp.emulators.xen.devel/114776/match=ivy+bridge Problem is that udelay uses 32 bit value from tsc for measuring elapsed time and at early boot stage something steals (most likely SMI) boot cpu with a following wrapping of tsc value in udelay. And in case of mdelay this happens multiple times. Replacing mdelay with udelay or removing it helps but it may break boot on other hardware. I suspect it's a BIOS issue. -- Thanks, Igor