qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] E5-2620v2 - emulation stop error


From: Andrey Korolyov
Subject: Re: [Qemu-devel] E5-2620v2 - emulation stop error
Date: Thu, 26 Mar 2015 19:48:09 +0300

On Thu, Mar 26, 2015 at 7:36 PM, Kevin O'Connor <address@hidden> wrote:
> 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

There are also rare occurences for d3f9 (in the middle of ep) and d334
ep (less than one tenth of events for both). I`ll post a sample event
capture with and without Radim`s proposed patch maybe today or
tomorrow.

/root/seabios-1.8.1/src/romlayout.S:289
    d3eb:       66 50                   pushl  %eax
    d3ed:       66 51                   pushl  %ecx
    d3ef:       66 52                   pushl  %edx
    d3f1:       66 53                   pushl  %ebx
    d3f3:       66 55                   pushl  %ebp
    d3f5:       66 56                   pushl  %esi
    d3f7:       66 57                   pushl  %edi
    d3f9:       06                      pushw  %es
    d3fa:       1e                      pushw  %ds

0000d334 <irq_trampoline_0x1c>:
irq_trampoline_0x1c():
/root/seabios-1.8.1/src/romlayout.S:196
    d334:       cd 1c                   int    $0x1c
    d336:       cb                      lretw



reply via email to

[Prev in Thread] Current Thread [Next in Thread]