From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 8 05:16:30 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 86E9459E; Tue, 8 Jan 2013 05:16:30 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by mx1.freebsd.org (Postfix) with ESMTP id 35D1CAB4; Tue, 8 Jan 2013 05:16:29 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id k1so9970oag.2 for ; Mon, 07 Jan 2013 21:16:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qTstP9I/xsP9nCHU11tAQD7350t0w0megMw+4g6/nho=; b=pdRovyD/J918ekPrKme7Mr1eSEy0O7tN20td/zy3PQRhQHyZNTLLdYAruIQb0DeKkO d8xB9ZOf10pQS3v9VeN31MAlK+wW7UlhMY9jhXC8CrLfwzuJVmz4088JyRNLBVKqXzmf So+HIf6QD7m9xH/xEqZ0tT6ioqurKAnDam5jOUKKxa67NhV0NCZSjQDvXUszsIWwHBpp t7VhshOcI5+v4u0cZVq0x72LfwlckziJspnrXLUcVaQdBYWIjtIvW6SppEpZRb850odO 6PUhDAz7e6v09blorDKloo/Y5Hof7R4htAScBNyzTqqQaaHLhZKYSbNGJjAYSRRa+OO0 Qykw== Received: by 10.182.18.133 with SMTP id w5mr45726836obd.64.1357622189287; Mon, 07 Jan 2013 21:16:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.93.105 with HTTP; Mon, 7 Jan 2013 21:15:59 -0800 (PST) In-Reply-To: References: <20110129084125.GA54969@freebsd.org> From: Jia-Shiun Li Date: Tue, 8 Jan 2013 13:15:59 +0800 Message-ID: Subject: Re: cpufreq not working as module on i386/amd64 To: Alexander Best Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@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 05:16:30 -0000 Hi all, move to -hackers as it seems a better place to discuss. 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. 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? 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. 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. Any comments? ----->8----->8----->8----- # svn diff Index: sys/dev/acpica/acpi_cpu.c =================================================================== --- sys/dev/acpica/acpi_cpu.c (revision 245148) +++ sys/dev/acpica/acpi_cpu.c (working copy) @@ -350,6 +350,7 @@ sc->cpu_features |= features; } free(drivers, M_TEMP); + sc->cpu_features |= ACPI_CAP_PERF_MSRS | ACPI_CAP_C1_IO_HALT; } /* ----->8----->8----->8----- Jia-Shiun 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 20051117) > -ACPI: Dynamic OEM Table Load: > -ACPI: SSDT 0 00223 (v01 PmRef Cpu0Ist 00003000 INTL 20051117) > ACPI: SSDT 0xbfd8b598 00537 (v01 PmRef Cpu0Cst 00003001 INTL 20051117) > 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 20051117) > -ACPI: Dynamic OEM Table Load: > -ACPI: SSDT 0 001CF (v01 PmRef ApIst 00003000 INTL 20051117) > ACPI: SSDT 0xbfd8df18 0008D (v01 PmRef ApCst 00003000 INTL 20051117) > 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 wrote: >> 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=104 >>> p4tcc0: on cpu0 >>> est0: on cpu0 >>> coretemp1: on cpu1 >>> coretemp1: Setting TjMax=104 >>> p4tcc1: on cpu1 >>> est1: on cpu1 >>> Device configuration finished. >>> procfs registered >>> ... >>> -----8<-----8<-----8<----- >>> >>> Jia-Shiun. >> >> >> -- >> a13x