From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 23 18:46:19 2008 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB1B51065677; Wed, 23 Jul 2008 18:46:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 49E518FC0A; Wed, 23 Jul 2008 18:46:19 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m6NIk0nA049681; Wed, 23 Jul 2008 14:46:12 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Oleg V. Nauman" Date: Wed, 23 Jul 2008 11:16:02 -0400 User-Agent: KMail/1.9.7 References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> <200807221514.55055.jhb@freebsd.org> <20080723140927.duc11agcg44ockw4@webmail.opentransfer.com> In-Reply-To: <20080723140927.duc11agcg44ockw4@webmail.opentransfer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807231116.02389.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 23 Jul 2008 14:46:13 -0400 (EDT) X-Virus-Scanned: ClamAV 0.93.1/7798/Wed Jul 23 13:42:38 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.3 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: acpi@freebsd.org, Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: ACPI regression on recent 7.0-STABLE: HPET stops working X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 18:46:20 -0000 On Wednesday 23 July 2008 07:09:27 am Oleg V. Nauman wrote: > Quoting John Baldwin : > > > On Tuesday 22 July 2008 04:37:51 am Oleg V. Nauman wrote: > >> Quoting John Baldwin : > >> > >> > On Monday 21 July 2008 06:07:52 am Oleg V. Nauman wrote: > >> >> Quoting "Oleg V. Nauman" : > >> >> > >> >> > Quoting Jeremy Chadwick : > >> >> > > >> >> >> 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@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 > >> >> >>> [..] > >> >> >>> acpi0: 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: port 0x62,0x66 on acpi0 > >> >> >>> acpi_hpet0: 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@rainhaven.theweb.org.ua:/usr/src/sys/i386/compile/oleg2 > >> >> >>> [..] > >> >> >>> acpi0: 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: 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@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: 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: 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: 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: 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 I've committed the patch. However, I think this actually points out a slightly bigger issue in that the HPET timer is probably piggybacking on the ichsmb0 device's BAR, and they really should both be able to attach somehow. A way to fix that would be to make the HPET device actually borrow the PCI device's resource instead of allocating its own perhaps. I think the HPET ACPI device and the table tell us the PCI deviec the HPET lives in. -- John Baldwin