ACPI regression on recent 7.0-STABLE: HPET stops working
Oleg V. Nauman
oleg at opentransfer.com
Wed Jul 23 11:09:31 UTC 2008
Quoting John Baldwin <jhb at freebsd.org>:
> 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
It never was working for me. Well nothing more than
ichsmb0: <SMBus controller> port 0xb00-0xb0f mem 0xfed00000-0xfed003ff
at device 20.0 on pci0
ichsmb0: can't map I/O
device_attach: ichsmb0 attach returned 6
> 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.
It was the patch against the CURRENT as far I understand while my
laptop running 7.0-STABLE. Well it was applied manually (not a so big
issue finally) against 1.243.2.3 revision of
/usr/src/sys/dev/acpica/acpi.c and reporting success for the HPET
functionality at least (part of relevant verbose dmesg output):
ACPI: HPET @ 0x0x77fd6800/0x0038 (v 1 A M I OEMHPET 0x10000626 MSFT
0x00000097)
acpi_hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
acpi_hpet0: vend: 0x4353 rev: 0x10 num: 3 hz: 14318180 opts: legacy_route
Timecounter "HPET" frequency 14318180 Hz quality 900
And part of sysctl variables related:
kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0)
dummy(-1000000)
kern.timecounter.hardware: HPET
I/O mem conflict with ichsmb still in place though
Thank you
>
> 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