* Andrey Korolyov (andrey@xxxxxxx) wrote: > On Wed, Mar 11, 2015 at 10:33 PM, Dr. David Alan Gilbert > <dgilbert@xxxxxxxxxx> wrote: > > * Kevin O'Connor (kevin@xxxxxxxxxxxx) 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@xxxxxxxxxx / Manchester, UK -- Dr. David Alan Gilbert / dgilbert@xxxxxxxxxx / Manchester, UK -- 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
