From owner-freebsd-stable@FreeBSD.ORG Fri Nov 19 15:26:03 2010 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 F30A41065670 for ; Fri, 19 Nov 2010 15:26:02 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B3B828FC1B for ; Fri, 19 Nov 2010 15:26:02 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5A64D46B51; Fri, 19 Nov 2010 10:26:02 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 413CE8A009; Fri, 19 Nov 2010 10:26:01 -0500 (EST) From: John Baldwin To: Ian Smith Date: Fri, 19 Nov 2010 09:39:49 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <20101115045549.GB96011@johnny.reilly.home> <201011181711.05440.jhb@freebsd.org> <20101119135414.A39988@sola.nimnet.asn.au> In-Reply-To: <20101119135414.A39988@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201011190939.49254.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Fri, 19 Nov 2010 10:26:01 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: "Alexandre \"Sunny\" Kovalenko" , freebsd-stable@freebsd.org Subject: Re: Console options for legacy-free mini-itx server? 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: Fri, 19 Nov 2010 15:26:03 -0000 On Thursday, November 18, 2010 10:14:44 pm Ian Smith wrote: > On Thu, 18 Nov 2010, John Baldwin wrote: > > On Thursday, November 18, 2010 4:07:27 pm Andrew Reilly wrote: > > > Hi John, > > > > > > On 18/11/2010, at 23:59 , John Baldwin wrote: > > > > > > > You used devinfo -v, so it shows the devices that exist even if they failed > > > > to attach. Try just using 'devinfo' and seeing if est1 still shows up. > > > > > > OK, you're right: running without -v shows only est0: > > > > > > nexus0 > > > apic0 > > > ram0 > > > acpi0 > > > cpu0 > > > acpi_perf0 > ^^^^^^^^^^ > > > est0 > > > p4tcc0 > > > cpufreq0 > > > cpu1 > > > p4tcc1 > > > cpufreq1 > > > acpi_button0 > > > pcib0 > > > <...> > > > > > > Is est. involved in the reboot question? > > > > Probably not. > > I'm not so sure, having just noticed something that I missed last time: Not being able to alter the speed of CPU 1 shouldn't impact the ability to reboot the system. > device_attach: acpi_perf1 attach returned 6 > est0: on cpu0 > p4tcc0: on cpu0 > device_attach: acpi_perf1 attach returned 6 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 16 > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 > > I'd mis-read or assumed that first line as being for acpi_perf0, rather > than an earlier? attempt to attach acpi_perf1 at that time. > > From cpufreq(4): > > The following device drivers offer absolute frequency control via the > cpufreq interface. Usually, only one of these can be active at a time. > > acpi_perf ACPI CPU performance states > est Intel Enhanced SpeedStep > ichss Intel SpeedStep for ICH > powernow AMD PowerNow! for K7 and K8 > smist Intel SMI-based SpeedStep for PIIX4 > > Apart from never having seen est0 attach but est1 not, my understanding > from both the manual and from having read some of the code over the time > is that acpi_perf0 should only attach if eg est0 didn't - is that wrong? > > Note also that there's no mention of acpi_perf0 attaching in the dmesg, > where I'm used to seeing that listed (eg as with my P3-Mobile CPU) acpi_perf(4) operates in two modes. One is that it actively manages the CPU, the second is that it provides the data table that other drives like est(4) use. In the second mode it marks itself as quiet so it does not show up in dmesg. -- John Baldwin