From owner-freebsd-stable@FreeBSD.ORG Wed Jul 23 11:09:31 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81BD11065674; Wed, 23 Jul 2008 11:09:31 +0000 (UTC) (envelope-from oleg@opentransfer.com) Received: from smh01.opentransfer.com (smh01.opentransfer.com [71.18.216.112]) by mx1.freebsd.org (Postfix) with ESMTP id 4F1A38FC0C; Wed, 23 Jul 2008 11:09:31 +0000 (UTC) (envelope-from oleg@opentransfer.com) Received: by smh01.opentransfer.com (Postfix, from userid 8) id 485AB1024CA5; Wed, 23 Jul 2008 07:09:12 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on smh01.opentransfer.com X-Spam-Level: ** X-Spam-Status: No, score=2.6 required=5.0 tests=MIME_QP_LONG_LINE,RDNS_NONE autolearn=disabled version=3.2.4 Received: from webmail6.opentransfer.com (unknown [69.49.230.6]) by smh01.opentransfer.com (Postfix) with ESMTP id F0D361024CAB; Wed, 23 Jul 2008 07:09:11 -0400 (EDT) Received: from webmail6.opentransfer.com (webmail6.opentransfer.com [127.0.0.1]) by webmail6.opentransfer.com (8.13.8/8.13.8) with ESMTP id m6NB9T41031461; Wed, 23 Jul 2008 06:09:29 -0500 Received: (from nobody@localhost) by webmail6.opentransfer.com (8.13.8/8.13.8/Submit) id m6NB9RUL031460; Wed, 23 Jul 2008 14:09:27 +0300 X-Authentication-Warning: webmail6.opentransfer.com: nobody set sender to oleg@opentransfer.com using -f Received: from oleg.ecommerce-dev.com (oleg.ecommerce-dev.com [193.142.124.7]) by webmail.opentransfer.com (Horde MIME library) with HTTP; for ; Wed, 23 Jul 2008 14:09:27 +0300 Message-ID: <20080723140927.duc11agcg44ockw4@webmail.opentransfer.com> Date: Wed, 23 Jul 2008 14:09:27 +0300 From: "Oleg V. Nauman" To: John Baldwin References: <20080719100315.2td4dl2q5ck88wkw@webmail.opentransfer.com> <200807211800.12415.jhb@freebsd.org> <20080722113751.qp8znc0duswkgs8g@webmail.opentransfer.com> <200807221514.55055.jhb@freebsd.org> In-Reply-To: <200807221514.55055.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=KOI8-R; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) X-Originating-IP: 193.142.124.7 Cc: Jeremy Chadwick , freebsd-stable@freebsd.org Subject: Re: ACPI regression on recent 7.0-STABLE: HPET stops working X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2008 11:09:31 -0000 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-STAB= LE > 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 acp= i0 >> >> >>> 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 acp= i0 >> >> >>> [..] >> >> >>> 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 ac= pi0 >> >> >> 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 thro= ugh >> >> > 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 o= n >> > 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 =20 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 an= d > just gives CPUs a really high probe order so that they should be after oth= er > devices. It was the patch against the CURRENT as far I understand while my =20 laptop running 7.0-STABLE. Well it was applied manually (not a so big =20 issue finally) against 1.243.2.3 revision of =20 /usr/src/sys/dev/acpica/acpi.c and reporting success for the HPET =20 functionality at least (part of relevant verbose dmesg output): ACPI: HPET @ 0x0x77fd6800/0x0038 (v 1 A M I OEMHPET 0x10000626 MSFT =20 0x00000097) acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi= 0 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) =20 dummy(-1000000) kern.timecounter.hardware: HPET I/O mem conflict with ichsmb still in place though Thank you > > Index: acpi.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /usr/cvs/src/sys/dev/acpica/acpi.c,v > retrieving revision 1.248 > diff -u -r1.248 acpi.c > --- acpi.c=097 Apr 2008 18:35:11 -0000=091.248 > +++ acpi.c=0922 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, =20 > "PNP0C02")) > @@ -1541,10 +1540,8 @@ > =09*order =3D 2; > else if (acpi_MatchHid(handle, "PNP0C0F")) > =09*order =3D 3; > - else if (acpi_MatchHid(handle, "PNP0A03")) > -=09*order =3D ACPI_DEV_BASE_ORDER; > else if (type =3D=3D ACPI_TYPE_PROCESSOR) > -=09*order =3D ACPI_DEV_BASE_ORDER + 10; > +=09*order =3D 100000; > } > > /* > @@ -1594,10 +1591,8 @@ > =09 * placeholder so that the probe/attach passes will run > =09 * breadth-first. Orders less than ACPI_DEV_BASE_ORDER > =09 * are reserved for special objects (i.e., system > -=09 * resources). Orders between ACPI_DEV_BASE_ORDER and 100 > -=09 * are used for Host-PCI bridges (and effectively all > -=09 * their children) and CPUs. Larger values are used for > -=09 * all other devices. > +=09 * resources). CPU devices have a very high order to > +=09 * ensure they are probed after other devices. > =09 */ > =09 ACPI_DEBUG_PRINT((ACPI_DB_OBJECTS, "scanning '%s'\n", handle_str))= ; > =09 order =3D level * 10 + 100; > > -- > John Baldwin >