svn commit: r209371 - in head/sys: amd64/amd64 amd64/include conf dev/acpica i386/i386 i386/include isa kern pc98/cbus sys x86/isa x86/x86

[Alexander Motin]

Kostik Belousov wrote:
> On Tue, Jun 22, 2010 at 12:12:44AM +0300, Alexander Motin wrote:
>> Kostik Belousov wrote:
>>> Witness patch worked for me, and I can boot multiuser in the qemu-hosted
>>> system with hint.hpet.0.clock=0. Does the same hint should work for
>>> amd64 ?
>> Yes.
>>
>>> The issue is no longer critical for me due to hint, below is the dmesg
>>> you asked for. Thanks.
>> It is not verbose.
> 
> Fair enough.
> 
> hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
> hpet0: vendor 0x8086, rev 0x1, 100000000Hz 64bit, 3 timers, legacy route
> hpet0:  t0: irqs 0x00000004 (0), 64bit, periodic
> hpet0:  t1: irqs 0x00000004 (0), 64bit, periodic
> hpet0:  t2: irqs 0x00000004 (0), 64bit, periodic
> Timecounter "HPET" frequency 100000000 Hz quality 900

So there are three timers without FSB interrupts support. They can use
only IRQ2 (not sure if this is a good practice) and can steal IRQ0 and
IRQ8 from i8254 and RTC, when "legacy route" enabled. So the only way to
use all three timers without level-triggered interrupts is to completely
and silently brake i8254 and RTC timers. I prefer not to do it now.

Please try such a patch, it should fix QEMU panic without using hints,
while HPET timers there won't be used until they implement either FSB
interrupts or shareable level-triggred IRQ above 15:

--- acpi_hpet.c.prev    2010-06-21 23:23:45.000000000 +0300
+++ acpi_hpet.c 2010-06-22 10:52:43.000000000 +0300
@@ -526,6 +526,7 @@ hpet_attach(device_t dev)
                                t->irq = -2;
                } else
 #endif
+               if (sc->irq >= 0)
                        t->caps |= (sc->irq << 9) | HPET_TCNF_INT_TYPE;
                bus_write_4(sc->mem_res, HPET_TIMER_CAP_CNF(i), t->caps);
                /* Skip event timers without set up IRQ. */


-- 
Alexander Motin