ACPI regression on recent 7.0-STABLE: HPET stops working
John Baldwin
jhb at freebsd.org
Tue Jul 22 21:00:43 UTC 2008
On Tuesday 22 July 2008 04:37:51 am Oleg V. Nauman wrote:
> Quoting John Baldwin <jhb at freebsd.org>:
>
> > On Monday 21 July 2008 06:07:52 am Oleg V. Nauman wrote:
> >> Quoting "Oleg V. Nauman" <oleg at opentransfer.com>:
> >>
> >> > Quoting Jeremy Chadwick <koitsu at FreeBSD.org>:
> >> >
> >> >> On Sat, Jul 19, 2008 at 10:03:15AM +0300, Oleg V. Nauman wrote:
> >> >>> It seems to be something was changed with ACPI support on 7.0-STABLE
so
> >> >>> my next system upgrade ended with ACPI HPET not working anymore on my
> >> >>> ASUS A9Rp laptop.
> >> >>>
> >> >>> Here is the part of /var/log/dmesg.today dated July 13:
> >> >>>
> >> >>> FreeBSD 7.0-STABLE #65: Tue Jul 8 22:05:07 EEST 2008
> >> >>> root at rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2
> >> >>> [..]
> >> >>> acpi0: <A M I OEMRSDT> on motherboard
> >> >>> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21
> >> >>> acpi0: [ITHREAD]
> >> >>> acpi0: Power Button (fixed)
> >> >>> acpi0: reservation of 0, a0000 (3) failed
> >> >>> acpi0: reservation of 100000, 77f00000 (3) failed
> >> >>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
> >> >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
> >> >>> acpi_ec0: <Embedded Controller: GPE 0x18> port 0x62,0x66 on acpi0
> >> >>> acpi_hpet0: <High Precision Event Timer> iomem
> >> >>> 0xfed00000-0xfed003ff on acpi0
> >> >>> Timecounter "HPET" frequency 14318180 Hz quality 900
> >> >>>
> >> >>> Here is the fresh dmesg output info:
> >> >>>
> >> >>> FreeBSD 7.0-STABLE #66: Tue Jul 15 22:11:27 EEST 2008
> >> >>> root at rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2
> >> >>> [..]
> >> >>> acpi0: <A M I OEMRSDT> on motherboard
> >> >>> acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21
> >> >>> acpi0: [ITHREAD]
> >> >>> acpi0: Power Button (fixed)
> >> >>> acpi0: reservation of 0, a0000 (3) failed
> >> >>> acpi0: reservation of 100000, 77f00000 (3) failed
> >> >>> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
> >> >>> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0
> >> >>> [..]
> >> >>> acpi_hpet0: <High Precision Event Timer> iomem
> >> >>> 0xfed00000-0xfed003ff on acpi0
> >> >>> device_attach: acpi_hpet0 attach returned 12
> >> >>>
> >> >>> And the part of actual sysctl kern.timecounter output:
> >> >>>
> >> >>> kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0)
> > dummy(-1000000)
> >> >>> kern.timecounter.hardware: ACPI-safe
> >> >>
> >> >> Seems okay here:
> >> >>
> >> >> FreeBSD icarus.home.lan 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat Jul
> >> >> 12 10:53:08 PDT 2008
> >> >> root at icarus.home.lan:/usr/obj/usr/src/sys/PDSMI_PLUS_amd64 amd64
> >> >>
> >> >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
> >> >> acpi_hpet0: <High Precision Event Timer> iomem
> >> >> 0xfed00000-0xfed003ff on acpi0
> >> >> Timecounter "i8254" frequency 1193182 Hz quality 0
> >> >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
> >> >> Timecounter "HPET" frequency 14318180 Hz quality 900
> >> >> Timecounters tick every 1.000 msec
> >> >>
> >> >> kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000)
> >> >> i8254(0) dummy(-1000000)
> >> >> kern.timecounter.hardware: ACPI-fast
> >> >>
> >> >> You sure you haven't upgraded your BIOS or something and forgot to
> >> >> re-enable HPET?
> >> >
> >> > No it was not upgraded.. Have no option to enable/disable HPET through
> >> > BIOS settings though
> >>
> >> I was unclear a bit or so. There are no ACPI related settings in my
> >> laptop's BIOS.
> >>
> >> Well.. Backout 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c
> >> (committed to RELENG_7 at July 10 by jhb) fixes this issue for me:
> >>
> >> acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on
> > acpi0
> >> Timecounter "HPET" frequency 14318180 Hz quality 900
> >>
> >> kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0)
> >> dummy(-1000000)
> >> kern.timecounter.hardware: HPET
> >>
> >> Hopefully it helps to understand what is went wrong there.
> >
> > Ok, so the attempt to allocate the resource is failing for some reason.
Can
> > you get output from 'devinfo -r' and 'devinfo -u'?
>
> ...
>
> Will not provide with full listings but just a diff comparing two
> states (this good one with HPET working and bad w/o it):
>
> rainhaven# diff devinfo.r.good devinfo.r.bad
> 177,179d176
> < acpi_hpet0
> < I/O memory addresses:
> < 0xfed00000-0xfed003ff
>
> rainhaven# diff devinfo.u.good devinfo.u.bad
> 128c128
> < 0xfed00000-0xfed003ff (acpi_hpet0)
> ---
> > 0xfed00000-0xfed003ff (ichsmb0)
>
> So kernel with 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c
> allocates the region required to ichsmb0 instead HPET (it not helps to
> ichsmb0 because it never was working on my laptop but it is another
> story I think).
>
> Thank you for looking into.
Hmm, so ichsmb0 doesn't show up at all in your earlier dmesg. Try this
change, it restores the probe orders to be more of what they used to be and
just gives CPUs a really high probe order so that they should be after other
devices.
Index: acpi.c
===================================================================
RCS file: /usr/cvs/src/sys/dev/acpica/acpi.c,v
retrieving revision 1.248
diff -u -r1.248 acpi.c
--- acpi.c 7 Apr 2008 18:35:11 -0000 1.248
+++ acpi.c 22 Jul 2008 19:12:56 -0000
@@ -1531,8 +1531,7 @@
* 1. I/O port and memory system resource holders
* 2. Embedded controllers (to handle early accesses)
* 3. PCI Link Devices
- * ACPI_DEV_BASE_ORDER. Host-PCI bridges
- * ACPI_DEV_BASE_ORDER + 10. CPUs
+ * 100000. CPUs
*/
AcpiGetType(handle, &type);
if (acpi_MatchHid(handle, "PNP0C01") || acpi_MatchHid(handle, "PNP0C02"))
@@ -1541,10 +1540,8 @@
*order = 2;
else if (acpi_MatchHid(handle, "PNP0C0F"))
*order = 3;
- else if (acpi_MatchHid(handle, "PNP0A03"))
- *order = ACPI_DEV_BASE_ORDER;
else if (type == ACPI_TYPE_PROCESSOR)
- *order = ACPI_DEV_BASE_ORDER + 10;
+ *order = 100000;
}
/*
@@ -1594,10 +1591,8 @@
* placeholder so that the probe/attach passes will run
* breadth-first. Orders less than ACPI_DEV_BASE_ORDER
* are reserved for special objects (i.e., system
- * resources). Orders between ACPI_DEV_BASE_ORDER and 100
- * are used for Host-PCI bridges (and effectively all
- * their children) and CPUs. Larger values are used for
- * all other devices.
+ * resources). CPU devices have a very high order to
+ * ensure they are probed after other devices.
*/
ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "scanning '%s'\n", handle_str));
order = level * 10 + 100;
--
John Baldwin
More information about the freebsd-stable
mailing list