From owner-freebsd-current@FreeBSD.ORG Tue Dec 25 18:11:24 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2093DBF3; Tue, 25 Dec 2012 18:11:24 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by mx1.freebsd.org (Postfix) with ESMTP id C903F8FC0C; Tue, 25 Dec 2012 18:11:23 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id 17so9878903iea.2 for ; Tue, 25 Dec 2012 10:11:17 -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=I5SMsth/yzsMhxJyW/MAT0wt4bqnyJUcItyNufMMuwQ=; b=USj6UwmMb4aL9BK8ywv7DuB1y+nPANrfv9424i40E0vloe6/Tk5fRv3RW8DK1pCjxC 4QvECfNuiDmSKJ2Xs42IyQ9fKYNX2URvuSWaqRfYv/jvWSFUIgD3ALYR+D4kVEhZCXDb yIGFOIOYVj7Dzk4wyOkR2K9eVph+5qD9t2c4wLHc5JFea1589VjPecotmJcudVHpM+Yy bXWUDdLywkogmbr8nMfp7DYdIg/XUDcpo7tFqBus9U5BDJdS+B/Q//49WGH1cgwxGNA6 vBaQtNJ/qKEr0xHsDFFospYVahmaeXRFXwoFQWmoyDnvxAGHH1h7OSEL41aBuanln7fs wbnA== Received: by 10.50.237.6 with SMTP id uy6mr22477840igc.31.1356459077438; Tue, 25 Dec 2012 10:11:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.88.103 with HTTP; Tue, 25 Dec 2012 10:10:47 -0800 (PST) In-Reply-To: <20110129084125.GA54969@freebsd.org> References: <20110129084125.GA54969@freebsd.org> From: Jia-Shiun Li Date: Wed, 26 Dec 2012 02:10:47 +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-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 18:11:24 -0000 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