qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [Bochs-developers] BIOS, ACPI, CMOS and Windows EvenID:


From: Gleb Natapov
Subject: [Qemu-devel] Re: [Bochs-developers] BIOS, ACPI, CMOS and Windows EvenID: 4
Date: Thu, 21 Aug 2008 08:34:06 +0300

On Thu, Aug 21, 2008 at 01:23:17AM +0200, Sebastian Herbszt wrote:
>> We ignored this error for a long time since there was no any stability
>> issues caused by it, but recently we encountered Windows 2008 reboot
>> problem (one of 10 reboots hangs with ACPI error) that, according to
>> Microsoft, is caused by CMOS access from AML code. Eliminating the
>> access indeed fixed reboot problem. ACPI spec defines a way to read
>> CMOS without accessing IO ports directly, but unfortunately neither
>> Windows XP nor Linux implements this part of the spec (it works in
>> Windows 2008 though).
>
> Do you mean OperationRegion type CMOS?
>
Yes. Tried that and it works only on Windows 2008 / Vista. XP doesn't
boot and Linux complains that it doesn't have a handler for this region
type. Linux can be fixed by XP is hopeless :)

>> As far as I can see AML accesses CMOS in order
>> to see how much memory is present and configure PCI hole to be maximum
>> size. Is this really needed or we can just hard code a reasonably large
>> PCI hole like in patch below and eliminate CMOS access
>
> The AML of my real hardware does calculate the maximal hole. VMware seems
> to do the same.
My real HW reads it from a chipset.

>
> Is there a minimal hole size specified somewhere? I looked at some specs but 
> didn't
> find any.
Qemu has a minimal hole size hardcoded to start at 0xe0000000.

>
>> Any other ideas how to solve the problem?
>
> The Microsoft document suggests to copy the CMOS data to somewhere in memory
> and access it there. I guess rombios space from 0xe000 to 0xffff could be a 
> good
> candidate.
No need to copy the whole CMOS. Copying only memory size should be
enough. Also putting it somewhere in first 4K should be better. You
can't write into 0xe000-0xffff unless chipset shadows it in a memory.

> The 440fx specs says "The top of memory is determined by the value written 
> into DRB7."
> We might get the proper value from there. But it also says "Note that the PMC 
> supports
> a maximum of 1 Gbytes of DRAM."
>
Yeah, I saw that my real HW takes top of the memory somewhere from the
chipset and looked in 440fx specs if it has this info, but it turned
out that we abuse 440fx and sometimes use much more memory that it
supports. We can re-use DRB registers for our needs and store memory
size there on POST (we can store 8 bytes there, so it should be enough)
and read them from AML. Are all users of bochs BIOS uses the same
chipset?

--
                        Gleb.




reply via email to

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