From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bandan Das Subject: Re: [Qemu-devel] E5-2620v2 - emulation stop error Date: Wed, 11 Mar 2015 14:24:16 -0400 Message-ID: References: <54FF4541.9080608@redhat.com> <20150310202958.GR2338@work-vm> <20150311134556.GH2334@work-vm> <20150311154220.GA26463@morn.localdomain> <20150311155306.GK2334@work-vm> <20150311163739.GA29522@morn.localdomain> <20150311165203.GL2334@work-vm> <20150311173738.GD29522@morn.localdomain> <20150311175904.GN2334@work-vm> Mime-Version: 1.0 Content-Type: text/plain Cc: "Kevin O'Connor" , Andrey Korolyov , "kvm\@vger.kernel.org" , "qemu-devel\@nongnu.org" , kraxel@redhat.com, Paolo Bonzini To: "Dr. David Alan Gilbert" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:56060 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750770AbbCKSYW (ORCPT ); Wed, 11 Mar 2015 14:24:22 -0400 In-Reply-To: <20150311175904.GN2334@work-vm> (David Alan Gilbert's message of "Wed, 11 Mar 2015 17:59:04 +0000") Sender: kvm-owner@vger.kernel.org List-ID: "Dr. David Alan Gilbert" writes: > * Kevin O'Connor (kevin@koconnor.net) wrote: >> On Wed, Mar 11, 2015 at 04:52:03PM +0000, Dr. David Alan Gilbert wrote: >> > * Kevin O'Connor (kevin@koconnor.net) wrote: >> > > So, I couldn't get this to fail on my older AMD machine at all with >> > > the default SeaBIOS code. But, when I change the code with the patch >> > > below, it failed right away. >> [...] >> > > And the failed debug output looks like: >> > > >> > > SeaBIOS (version rel-1.8.0-7-gd23eba6-dirty-20150311_121819-morn.localdomain) >> > > [...] >> > > cmos_smp_count0=20 >> > > [...] >> > > cmos_smp_count=1 >> > > cmos_smp_count2=1/20 >> > > Found 1 cpu(s) max supported 20 cpu(s) >> > > >> > > I'm going to check the assembly for a compiler error, but is it >> > > possible QEMU is returning incorrect data in cmos index 0x5f? >> >> I checked the SeaBIOS assembler and it looks sane. So, I think the >> question is, why is QEMU sometimes returning a 0 instead of 127 from >> cmos 0x5f. > > My reading of the logs I've just created is that qemu doesn't think > it's ever being asked to read 5f in the failed case: > > good: > > pc_cmos_init 5f setting smp_cpus=20 > cmos: read index=0x0f val=0x00 > cmos: read index=0x34 val=0x00 > cmos: read index=0x35 val=0x3f > cmos: read index=0x38 val=0x30 > cmos: read index=0x3d val=0x12 > cmos: read index=0x38 val=0x30 > cmos: read index=0x0b val=0x02 > cmos: read index=0x0d val=0x80 > cmos: read index=0x5f val=0x13 Yeh! > cmos: read index=0x0f val=0x00 > cmos: read index=0x0f val=0x00 > cmos: read index=0x0f val=0x00 > > bad: > pc_cmos_init 5f setting smp_cpus=20 > cmos: read index=0x0f val=0x00 > cmos: read index=0x34 val=0x00 > cmos: read index=0x35 val=0x3f > cmos: read index=0x38 val=0x30 > cmos: read index=0x3d val=0x12 > cmos: read index=0x38 val=0x30 > cmos: read index=0x0b val=0x02 > cmos: read index=0x0d val=0x80 Oh! > cmos: read index=0x0f val=0x00 > cmos: read index=0x0f val=0x00 > cmos: read index=0x0f val=0x00 rtc_read in hw/rt.c is: u8 rtc_read(u8 index) { index |= NMI_DISABLE_BIT; outb(index, PORT_CMOS_INDEX); return inb(PORT_CMOS_DATA); } Is it possible that the read would happen before the index has been committed ? > Dave >