From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 8 15:02:04 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3041F2B2; Tue, 8 Jan 2013 15:02:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9B48076B; Tue, 8 Jan 2013 15:02:03 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id r08F1tvV097278; Tue, 8 Jan 2013 17:01:55 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r08F1tvV097278 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id r08F1tS0097277; Tue, 8 Jan 2013 17:01:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 8 Jan 2013 17:01:55 +0200 From: Konstantin Belousov To: Jia-Shiun Li Subject: Re: cpufreq not working as module on i386/amd64 Message-ID: <20130108150155.GF82219@kib.kiev.ua> References: <20110129084125.GA54969@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k6SrlR5F+BMzH45x" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-hackers@freebsd.org, avg@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2013 15:02:04 -0000 --k6SrlR5F+BMzH45x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 08, 2013 at 01:15:59PM +0800, Jia-Shiun Li wrote: > Hi all, >=20 > move to -hackers as it seems a better place to discuss. >=20 > Turns out, at acpi_cpu_attach(), the bus probe will query > ACPI_GET_FEATURES() to get cpu_features flags from each cpufreq > drivers. Since it is only executed once at booting, subsequent module > loading after booting will not be called get_features() and will not > be able to express interests in terms of ACPI_CAP_* flags. And if > these flags were not set first, acpi_perf won't get attached. Later > when loading cpufreq.ko, est_attach(), etc. will not be able to find > acpi_perf and thus failed to attach. >=20 > After referred to Intel doc. #302223 mentioned in > dev/acpica/acpivar.h, I got confused by the meaning of these bits. > According to the document, capability bits probably should be set as > long as OSPM is *capable* of using them, no matter when they will be > used. I am not familiar with ACPI, but I suppose it will expose > states/methods to OSPM according to these bits? >=20 > To confirm this, I add a line to simply OR'd (ACPI_CAP_PERF_MSRS | > ACPI_CAP_C1_IO_HALT) to sc->cpu_features after the loop calling > ACPI_GET_FEATURES(). And then I am able to load cpufreq.ko after boot. > powerd also works fine with it. >=20 > If this is true, then probably we don't need get_features() for acpi > interface/drivers. It is sufficient to just turn on proper bits > directly for acpi_cpu when related code is added to repository. >=20 > Any comments? >=20 > ----->8----->8----->8----- > # svn diff > Index: sys/dev/acpica/acpi_cpu.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 > --- sys/dev/acpica/acpi_cpu.c (revision 245148) > +++ sys/dev/acpica/acpi_cpu.c (working copy) > @@ -350,6 +350,7 @@ > sc->cpu_features |=3D features; > } > free(drivers, M_TEMP); > + sc->cpu_features |=3D ACPI_CAP_PERF_MSRS | ACPI_CAP_C1_IO_HALT; > } I had almost word-to-word identical conversation with Andrey Gapon, might be a year ago. I Cc:ed him. >=20 > /* >=20 > ----->8----->8----->8----- >=20 >=20 > Jia-Shiun >=20 > On Wed, Dec 26, 2012 at 2:10 AM, Jia-Shiun Li wrote: > > I was cleaning up hard drive and found these old logs. Anyway I added > > some printf() > > and saw the process failed at device_find_child(..., "acpi_perf", ...) > > of est_acpi_info() i.e. it cannot find acpi_perf device. > > > > devinfo did confirmed the absence of acpi_perf. Comparing the dmesgs > > revealed the main difference: IST (i-state?) OEM tables in SSDT seems > > not loaded if cpufreq was not compiled into kernel, as it shows below. > > > > Before I diving into the ACPI part, can anyone familiar with how ACPI > > works shed me some light? > > > > ----->8----->8----->8----- > > % diff -bu cpufreq-nb.log cpufreq-no.log > > ... > > @@ -158,17 +158,11 @@ > > acpi0: Power Button (fixed) > > cpu0: Processor \\_PR_.CPU0 (ACPI ID 1) -> APIC ID 0 > > cpu0: on acpi0 > > -ACPI: SSDT 0xbfd8dc98 00223 (v01 PmRef Cpu0Ist 00003000 INTL 2005111= 7) > > -ACPI: Dynamic OEM Table Load: > > -ACPI: SSDT 0 00223 (v01 PmRef Cpu0Ist 00003000 INTL 20051117) > > ACPI: SSDT 0xbfd8b598 00537 (v01 PmRef Cpu0Cst 00003001 INTL 2005111= 7) > > ACPI: Dynamic OEM Table Load: > > ACPI: SSDT 0 00537 (v01 PmRef Cpu0Cst 00003001 INTL 20051117) > > cpu1: Processor \\_PR_.CPU1 (ACPI ID 2) -> APIC ID 1 > > cpu1: on acpi0 > > -ACPI: SSDT 0xbfd8ce18 001CF (v01 PmRef ApIst 00003000 INTL 2005111= 7) > > -ACPI: Dynamic OEM Table Load: > > -ACPI: SSDT 0 001CF (v01 PmRef ApIst 00003000 INTL 20051117) > > ACPI: SSDT 0xbfd8df18 0008D (v01 PmRef ApCst 00003000 INTL 2005111= 7) > > ACPI: Dynamic OEM Table Load: > > ACPI: SSDT 0 0008D (v01 PmRef ApCst 00003000 INTL 20051117 > > > > On Sat, Jan 29, 2011 at 4:41 PM, Alexander Best w= rote: > >> On Sat Jan 29 11, Jia-Shiun Li wrote: > >>> Hi all, > >>> > >>> I found that cpufreq driver failed to attach when compiled as module > >>> and loaded, but it works fine when compiled into kernel. I am > >>> wondering if this is due to some kind of limitation, or can be fixed? > >> > >> that's rather odd. for me neither the module nor the kernel code works= , since > >> my cpu isn't supported by sys/x86/cpufreq/est.c. actually only pentium= mobile > >> cpus seem to be supported. > >> > >> maybe you can add some printf's to est.c:est_get_info() to identify at= which > >> point error gets set. also you might want to make > >> > >> "est: cpu_vendor %s, msr %0jx\n", cpu_vendor, msr); > >> > >> non-conditional. maybe the output differy in kernel/module mode. > >> > >> cheers. > >> alex > >> > >>> > >>> Tested on a Pentium E5200 desktop (i386) and a Pentium T4200 laptop > >>> (amd64). Both got the same result. dmesg of T4200 attached. > >>> > >>> kldload module: > >>> ----->8----->8----->8----- > >>> est0: on cpu0 > >>> est: CPU supports Enhanced Speedstep, but is not recognized. > >>> est: cpu_vendor GenuineIntel, msr 6194c1a06004c1a > >>> device_attach: est0 attach returned 6 > >>> est1: on cpu1 > >>> est: CPU supports Enhanced Speedstep, but is not recognized. > >>> est: cpu_vendor GenuineIntel, msr 6194c1a06004c1a > >>> -----8<-----8<-----8<----- > >>> (repeated 6 times, kldload retries?) > >>> > >>> compiled into kernel: > >>> ----->8----->8----->8----- > >>> ... > >>> fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 > >>> uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 > >>> isa_probe_children: probing PnP devices > >>> coretemp0: on cpu0 > >>> coretemp0: Setting TjMax=3D104 > >>> p4tcc0: on cpu0 > >>> est0: on cpu0 > >>> coretemp1: on cpu1 > >>> coretemp1: Setting TjMax=3D104 > >>> p4tcc1: on cpu1 > >>> est1: on cpu1 > >>> Device configuration finished. > >>> procfs registered > >>> ... > >>> -----8<-----8<-----8<----- > >>> > >>> Jia-Shiun. > >> > >> > >> -- > >> a13x > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" --k6SrlR5F+BMzH45x Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ7DTiAAoJEJDCuSvBvK1B56EP/jSAbgGzLSd9tub1WE/Tsg/t 73D0wtgHH2UXeerxtdpQQiFR2Z9v6PWzYsQjSZsjXKNpXfCESkdqar48e+Nvi9Tt b8ApP6jMaW8pEnm6TJa23IPSYr2zvTK/1+8KJIuGk20ifn94wLrZBYPif/YtXRAw DiOHinU8umZgpV3KBPVG4eDVEOR0cx25Z1jPVIxuVDVwzm5gYjkhxw+JlH0nMoAb 42pdKJpv0IVEhqD95MyVKVPCwDQEFYnOMDzItcHblAA4LEO6MYWVr8JB0kSQPyje PD8hwEZmNAkak+W40KVT1N4jCOvtn7jYfU5BqNnDfwzAduGFdlZhsJ1k2VFIRH2t hqxiVdemsshrJ9rcvQMKpvRDWY9mwOyHSPoIoqUEjOexGZwz+qrocQhdwIXXCOAh HQ3LAhK2XogsQtXJDB0Y4hrcbjz5uxUS2Mxrb028sN6DZONIQakqF1YSE2Cu5Nkj 9OyHcABQPLcL6uo6X0urBDSb8b79rvLmEy0Eh1JDtDmZGH5xyA+W7gy2FYfGqDpB t85wKnSdhtB2yH6A657slbO2K1cW0SO0w5pz7ccmcqC4QANFhJGFYmCzGr1i/SbA zqCCj+bMMvXrOXT8zYu4RV4lHOU5MLhd7C29uqV7BiUDRnFmOlpwloagEBx85wiQ cyKf2LmRunwgHyyhjw0v =XhFv -----END PGP SIGNATURE----- --k6SrlR5F+BMzH45x--