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: Bandan Das
Subject: Re: [Qemu-devel] E5-2620v2 - emulation stop error
Date: Wed, 11 Mar 2015 14:24:16 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

"Dr. David Alan Gilbert" <address@hidden> writes:

> * Kevin O'Connor (address@hidden) wrote:
>> On Wed, Mar 11, 2015 at 04:52:03PM +0000, Dr. David Alan Gilbert wrote:
>> > * Kevin O'Connor (address@hidden) 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
>



reply via email to

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