On Thu, Mar 26, 2015 at 7:36 PM, Kevin O'Connor <kevin@xxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
