WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Problem with BIOS timer interrupts

To: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Problem with BIOS timer interrupts
From: Gary Grebus <ggrebus@xxxxxxxxxxxxxxx>
Date: Tue, 18 Nov 2008 15:28:35 -0500
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 18 Nov 2008 12:28:57 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C548CFCA.1F55A%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C548CFCA.1F55A%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2008-11-18 at 20:02 +0000, Keir Fraser wrote:
> On 18/11/08 18:50, "Gary Grebus" <ggrebus@xxxxxxxxxxxxxxx> wrote:
> 
> > It uses this to timeout waiting for a key press.  The expected interrupt
> > is from the BIOS timer implemented in rombios.  But in fact, the loop
> > hangs.  However, if I insert a nop instruction between the sti and hlt,
> > then things work as expected.
> > 
> > Is there something wrong with this sequence?  This happens on AMD, so
> > it's not a quirk of the real mode emulations on Intel.

Interestingly, the same problem and "fix" apply on Intel under
vmxassist.  But likely nobody cares about that anymore (and gPXE has
other problems with vmxassist).

> > 
> > I notice that in the gPXE code currently in xen-unstable, the path that
> > uses this code is patched out.
> 
> As a data point, I commented it out because the delay's annoying rather than
> because it caused a boot hang for me. I was testing on Intel though.
> 
> Inserting the nop is obviously bogus (I expect you're aware of that :-),
> since it raises the opportunity of a wakeup-waiting race. That it fixes this
> issue is very weird. I expect we have some issue to do with leaving an
> interrupt shadow during HLT emulation -- why this would only trigger in real
> mode I cannot guess.
> 
> Wei's erratum is not applicable, for three reasons:
>  1. We disable C1 clock ramping
>  2. We always intercept HLT
>  3. STI; HLT is a standard x86 idiom used in all OSes, and this is the only
> place we're seeing a problem. Also the erratum would lead to rare
> non-deterministic hangs, not a hang every time (which is what you're
> seeing?).

OK.  It does appear to be family 0xf processor.  dom0 says:
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 65
model name      : Dual-Core AMD Opteron(tm) Processor 2216
stepping        : 2
cpu MHz         : 2394.000
cache size      : 1024 KB

> 
> I would say it's a good idea to see if you can repro this on xen-unstable.

OK... My usual xen-unstable setup is out of commission at the moment,
but I will try to reproduce it.

        /gary


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