Both hpet and rtc have irq 8 in their ressources, making windows unhappy because of the conflict. Fix this by making rtc check whenever the hpet is present, and claim irq 8 only in case it isn't. So rtc gets irq 8 only in case you start qemu with the -no-hpet switch.
Verified working in both linux (check pnp boot messages) and windows (check rtc ressources in device manager) guests.
Signed-off-by: Gerd Hoffmann kraxel@redhat.com --- src/acpi-dsdt-isa.dsl | 16 ++++++++++++++-- 1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/src/acpi-dsdt-isa.dsl b/src/acpi-dsdt-isa.dsl index 23761db..15dc181 100644 --- a/src/acpi-dsdt-isa.dsl +++ b/src/acpi-dsdt-isa.dsl @@ -3,11 +3,23 @@ Scope(_SB.PCI0.ISA) {
Device(RTC) { Name(_HID, EisaId("PNP0B00")) - Name(_CRS, ResourceTemplate() { + Name(RESP, ResourceTemplate() { IO(Decode16, 0x0070, 0x0070, 0x10, 0x02) - IRQNoFlags() { 8 } IO(Decode16, 0x0072, 0x0072, 0x02, 0x06) }) + Name(RESI, ResourceTemplate() { + IRQNoFlags() { 8 } + }) + Method(_CRS, 0) { + Store(_SB.HPET._STA(), Local0) + If (LEqual(Local0, 0)) { + /* hpet not present -> give irq 8 to rtc */ + ConcatenateResTemplate(RESP, RESI, Local1) + Return (Local1) + } else { + Return (RESP) + } + } }
Device(KBD) {
On Wed, Dec 05, 2012 at 10:13:57AM +0100, Gerd Hoffmann wrote:
Both hpet and rtc have irq 8 in their ressources, making windows unhappy because of the conflict. Fix this by making rtc check whenever the hpet is present, and claim irq 8 only in case it isn't. So rtc gets irq 8 only in case you start qemu with the -no-hpet switch.
Verified working in both linux (check pnp boot messages) and windows (check rtc ressources in device manager) guests.
I also successfully tested it on SnowLeopard.
--Gabriel
On Wed, Dec 05, 2012 at 10:13:57AM +0100, Gerd Hoffmann wrote:
Both hpet and rtc have irq 8 in their ressources, making windows unhappy because of the conflict. Fix this by making rtc check whenever the hpet is present, and claim irq 8 only in case it isn't. So rtc gets irq 8 only in case you start qemu with the -no-hpet switch.
Verified working in both linux (check pnp boot messages) and windows (check rtc ressources in device manager) guests.
Resolves the Windows 7 RTC resource conflict on Q35 as well.
However, Windows XP continues to blue screen on boot as I reported, and Brad also posted (for both piix and q35).
Thanks,
-Jason
On Wed, Dec 05, 2012 at 01:18:48PM -0500, Jason Baron wrote:
On Wed, Dec 05, 2012 at 10:13:57AM +0100, Gerd Hoffmann wrote:
Both hpet and rtc have irq 8 in their ressources, making windows unhappy because of the conflict. Fix this by making rtc check whenever the hpet is present, and claim irq 8 only in case it isn't. So rtc gets irq 8 only in case you start qemu with the -no-hpet switch.
Verified working in both linux (check pnp boot messages) and windows (check rtc ressources in device manager) guests.
Resolves the Windows 7 RTC resource conflict on Q35 as well.
However, Windows XP continues to blue screen on boot as I reported, and Brad also posted (for both piix and q35).
Looks like a regression caused by d9f5cdbdf55d61aef9a1a534d9123ef734427478 - I'll revert that patch if no fix is found.
-Kevin
On Wed, Dec 05, 2012 at 05:28:31PM -0500, Kevin O'Connor wrote:
CCing Alex.
On Wed, Dec 05, 2012 at 01:18:48PM -0500, Jason Baron wrote:
On Wed, Dec 05, 2012 at 10:13:57AM +0100, Gerd Hoffmann wrote:
Both hpet and rtc have irq 8 in their ressources, making windows unhappy because of the conflict. Fix this by making rtc check whenever the hpet is present, and claim irq 8 only in case it isn't. So rtc gets irq 8 only in case you start qemu with the -no-hpet switch.
Verified working in both linux (check pnp boot messages) and windows (check rtc ressources in device manager) guests.
Resolves the Windows 7 RTC resource conflict on Q35 as well.
However, Windows XP continues to blue screen on boot as I reported, and Brad also posted (for both piix and q35).
Looks like a regression caused by d9f5cdbdf55d61aef9a1a534d9123ef734427478 - I'll revert that patch if no fix is found.
If it was copied from real HW can we check that XP runs on this HW?
-- Gleb.
On Thu, Dec 06, 2012 at 09:33:50AM +0200, Gleb Natapov wrote:
On Wed, Dec 05, 2012 at 05:28:31PM -0500, Kevin O'Connor wrote:
Looks like a regression caused by d9f5cdbdf55d61aef9a1a534d9123ef734427478 - I'll revert that patch if no fix is found.
If it was copied from real HW can we check that XP runs on this HW?
HPET with both
Memory32Fixed (ReadOnly, 0xFED00000, // Address Base 0x00000400, // Address Length )
and
IRQNoFlags () {0} IRQNoFlags () {8}
is from Apple hardware. I remember running XP on my MBP2,1 a few years ago.
On a Dell Latitude D630, I have just
Memory32Fixed (ReadOnly, 0xFED00000, // Address Base 0x00000400, // Address Length )
without the IRQNoFlags for the HPET's _CRS.
On the Macs, the RTC looks like this:
Device (RTC) { Name (_HID, EisaId ("PNP0B00")) Name (_CRS, ResourceTemplate () { IO (Decode16, 0x0070, // Range Minimum 0x0070, // Range Maximum 0x01, // Alignment 0x08, // Length ) }) }
On the Dell D630, it looks like this (more or less similar to SeaBIOS):
Device (RTC) { Name (_HID, EisaId ("PNP0B00")) Name (RT, ResourceTemplate () { IO (Decode16, 0x0070, // Range Minimum 0x0070, // Range Maximum 0x10, // Alignment 0x02, // Length ) IRQNoFlags () {8} IO (Decode16, 0x0072, // Range Minimum 0x0072, // Range Maximum 0x02, // Alignment 0x06, // Length ) }) Method (_CRS, 0, NotSerialized) { Return (RT) } }
Kevin, Jason: if dropping only the IRQNoFlags line from HPET _CRS gets XP working in your setup, can we just do that instead of fully reverting d9f5cdbdf55d61aef9a1a534d9123ef734427478 ? At least that way OS X will still work in single-core mode ?
Thanks, --Gabriel
On Wed, Dec 05, 2012 at 10:13:57AM +0100, Gerd Hoffmann wrote:
Both hpet and rtc have irq 8 in their ressources, making windows unhappy because of the conflict. Fix this by making rtc check whenever the hpet is present, and claim irq 8 only in case it isn't. So rtc gets irq 8 only in case you start qemu with the -no-hpet switch.
Verified working in both linux (check pnp boot messages) and windows (check rtc ressources in device manager) guests.
Thanks. It looks like ConcatenateResTemplate wasn't in the ACPI 1.0 spec, so I think we should try to avoid using it. (I know it's used by the 64bit PCI code, but any machine supporting 64bit PCI is likely to have a more recent OS.)
I put together a slightly modified patch - see separate email.
-Kevin
-
Gabriel L. Somlo -
Gerd Hoffmann -
Gleb Natapov -
Jason Baron -
Kevin O'Connor