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

Dr. David Alan Gilbert
2015-03-11T19:59:28Z

* Andrey Korolyov (andrey@xdel.ru) wrote:
> On Wed, Mar 11, 2015 at 10:33 PM, Dr. David Alan Gilbert
> <dgilbert@redhat.com> wrote:
> > * Kevin O'Connor (kevin@koconnor.net) wrote:
> >> On Wed, Mar 11, 2015 at 02:45:31PM -0400, Kevin O'Connor wrote:
> >> > On Wed, Mar 11, 2015 at 02:40:39PM -0400, Kevin O'Connor wrote:
> >> > > For what it's worth, I can't seem to trigger the problem if I move the
> >> > > cmos read above the SIPI/LAPIC code (see patch below).
> >> >
> >> > Ugh!
> >> >
> >> > That's a seabios bug. Main processor modifies the rtc index
> >> > (rtc_read()) while APs try to clear the NMI bit by modifying the rtc
> >> > index (romlayout.S:transition32).
> >> >
> >> > I'll put together a fix.
> >>
> >> The seabios patch below resolves the issue for me.
> >
> > Thanks! Looks good here.
> >
> > Andrey, Paolo, Bandan: Does it fix it for you as well?
> >
>
> Thanks Kevin, Dave,
>
> I`m afraid that I`m hitting something different not only because
> different suberror code but also because of mine version of seabios -
> I am using 1.7.5 and corresponding code in the proposed patch looks
> different - there is no smp-related code patch is about of. Those
> mentioned devices went to production successfully and I`m afraid I
> cannot afford playing on them anymore, even if I re-trigger the issue
> with patched 1.8.1-rc, there is no way to switch to a different kernel
> and retest due to specific conditions of this production suite. I`ve
> ordered a pair of new shoes^W 2620v2-s which should arrive to me next

Well I was testing on a pair of 'E5-2620 v2'; but as you saw my test case
was pretty simple. If you can suggest any flags I should add etc to the
test I'd be happy to give it a go.

Dave

> Monday, so I`ll be able to test a) against 1.8.0-release, b) against
> patched bios code, c) reproduce initial error on master/3.19 (may be
> I`ll take them before weekend by going into this computer shop in
> person). Until then, I have a very deep feeling that mine issue is not
> there :) Also I became very curious on how a lack of IDT feature may
> completely eliminate the issue appearance for me, the only possible
> explanation is a clock-related race which is kinda stupid suggestion
> and unlikely to exist in nature.
>
> Thanks again for everyone for throughout testing and ideas!
>
> >
> >> -Kevin
> >>
> >>
> >> --- a/src/romlayout.S
> >> +++ b/src/romlayout.S
> >> @@ -22,7 +22,8 @@
> >> // %edx = return location (in 32bit mode)
> >> // Clobbers: ecx, flags, segment registers, cr0, idt/gdt
> >> DECLFUNC transition32
> >> -transition32_for_smi:
> >> +transition32_nmi_off:
> >> + // transition32 when NMI and A20 are already initialized
> >> movl %eax, %ecx
> >> jmp 1f
> >> transition32:
> >> @@ -205,7 +206,7 @@ __farcall16:
> >> entry_smi:
> >> // Transition to 32bit mode.
> >> movl $1f + BUILD_BIOS_ADDR, %edx
> >> - jmp transition32_for_smi
> >> + jmp transition32_nmi_off
> >> .code32
> >> 1: movl $BUILD_SMM_ADDR + 0x8000, %esp
> >> calll _cfunc32flat_handle_smi - BUILD_BIOS_ADDR
> >> @@ -216,8 +217,10 @@ entry_smi:
> >> DECLFUNC entry_smp
> >> entry_smp:
> >> // Transition to 32bit mode.
> >> + cli
> >> + cld
> >> movl $2f + BUILD_BIOS_ADDR, %edx
> >> - jmp transition32
> >> + jmp transition32_nmi_off
> >> .code32
> >> // Acquire lock and take ownership of shared stack
> >> 1: rep ; nop
> > --
> > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK