Re: E5-2620v2 - emulation stop error

[Kevin O'Connor <kevin@koconnor.net>]

On Thu, Mar 26, 2015 at 04:58:07PM +0100, Radim Krčmář wrote:
> 2015-03-25 20:05-0400, Kevin O'Connor:
> > On Thu, Mar 26, 2015 at 02:35:58AM +0300, Andrey Korolyov wrote:
> > > Thanks, strangely the reboot is always failing now and always reaching
> > > seabios greeting. May be prints straightened up a race (e.g. it is not
> > > int19 problem really).
> > > 
> > > object file part:
> > > 
> > > 0000d331 <irq_trampoline_0x19>:
> > > irq_trampoline_0x19():
> > > /root/seabios-1.8.1/src/romlayout.S:195
> > >     d331:       cd 19                   int    $0x19
> > >     d333:       cb                      lretw
> > 
> > [...]
> > > Jump to int19 (vector=f000e6f2)
> > 
> > Thanks.  So, it dies on the "int $0x19" instruction itself.  The
> > vector looks correct and I don't see anything in the cpu register
> > state that looks wrong.  Maybe one of the kvm developers will have an
> > idea what could cause a fault there.
> 
> The place agrees with the "<cd> 19 cb" part of KVM error output.
> Suberror 2 means that we were interrupted while delivering a vector,
> here it is disected: (delivering 'vect_info')
> 
>   vect_info (extra data[0]: 800000ef)
>   - vector 0xef
>   - INTR_TYPE_EXT_INTR (0x000)
>   - no error code (0x000)
>   - valid (0x80000000)
> 
>   intr_info (extra data[1]: 80000b0d)
>   - #GP (0x0d)
>   - INTR_TYPE_HARD_EXCEPTION (0x300)
>   - error code on stack (0x800)  [Hunk at the bottom exposes it.]
>   - valid (0x80000000)

Thanks for the background info.

> Notice the 0xef.  My best hypothesis so far is that we fail at resetting
> devices, and 0xef is LOCAL_TIMER_VECTOR from Linux before we rebooted.
> (The bug happens at the first place that enables interrupts.)

FYI, the "int $0x19" isn't the first place SeaBIOS will enable
interrupts.  Each screen print (every character in the seabios banner
and uuid string) will call the vga bios (int $0x10) with irqs enabled
(see output.c:screenc).

Also, SeaBIOS loads a default vector (f000:ff53) at 0xef which does a
simple "iretw".

Things that are unusual about the "int $0x19" call:
  - it is likely the first place that the cpu is transitioned into
    16bit real mode as opposed to "big real" mode.  (That is, the
    first place interrupts are enabled with the segment limits set to
    0xffff.)
  - it's right after the fw/shadow.c:make_bios_readonly() call, which
    attempts to configures the memory at 0xf0000-0x100000 as
    read-only.  That code also issues a wbinvd() call.

I'm not sure if the crash always happens at the "int $0x19" location
though.  Andrey, does the crash always happen with "EIP=d331" and/or
with "Code=... <cd> 19"?

-Kevin