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: Wed, 11 Mar 2015 22:47:35 +0300

On Wed, Mar 11, 2015 at 10:33 PM, Dr. David Alan Gilbert
<address@hidden> wrote:
> * Kevin O'Connor (address@hidden) 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
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 / address@hidden / Manchester, UK



reply via email to

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