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

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

 



On Thu, Mar 26, 2015 at 08:08:52PM +0300, Andrey Korolyov wrote:
> On Thu, Mar 26, 2015 at 8:06 PM, Kevin O'Connor <kevin@xxxxxxxxxxxx> wrote:
> > On Thu, Mar 26, 2015 at 07:48:09PM +0300, Andrey Korolyov wrote:
> >> On Thu, Mar 26, 2015 at 7:36 PM, Kevin O'Connor <kevin@xxxxxxxxxxxx> wrote:
> >> > 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"?
> >>
> >> 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
> >
> > Thanks.  The d334 looks very similar to the d331 report (code=<cd>
> > 1c).  That path could happen during post (big real mode) or
> > immiediately after post (real mode).
> >
> > The d3f9 report does not look like the others - interrupts are
> > disabled there.  If you still have the error logs, can you post the
> > full kvm crash report for d3f9?
> >
> 
> Here you go:

Thanks.  While we're at, can you verify if all your reports are
showing the cpu in "real mode".  That is, do they all have "0000ffff"
in the third column of the segment registers - as in:

> ES =0000 00000000 0000ffff 00009300

[...]
> Code=48 18 67 8c 00 8c d1 8e d9 66 5a 66 58 66 5d 66 c3 cd 02 cb <cd>
> 10 cb cd 13 cb cd 15 cb cd 16 cb cd 18 cb cd 19 cb cd 1c cb fa fc 66
> b8 00 e0 00 00 8e

KVM reports the code as "int $0x10" here.  Was it possible this report
was from a different build of seabios (that had a different code
layout)?

Interestingly, this "int $0x10" is also in real-mode and not "big real
mode", so I think it would have occurred after post completed.

-Kevin
--
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




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux