From owner-freebsd-stable@FreeBSD.ORG Thu Nov 18 13:14:44 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 1035A1065672; Thu, 18 Nov 2010 13:14:44 +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 C2D908FC17; Thu, 18 Nov 2010 13:14:43 +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 5E0B346B06; Thu, 18 Nov 2010 08:14:43 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 414728A027; Thu, 18 Nov 2010 08:14:42 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Thu, 18 Nov 2010 07:59:38 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <20101115045549.GB96011@johnny.reilly.home> <20101118001349.GA40554@johnny.reilly.home> <1290041198.1899.19.camel@RabbitsDen.RabbitsLawn.verizon.net> In-Reply-To: <1290041198.1899.19.camel@RabbitsDen.RabbitsLawn.verizon.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201011180759.39129.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 18 Nov 2010 08:14:42 -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: stable@freebsd.org, "Alexandre \"Sunny\" Kovalenko" , Ian Smith 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: Thu, 18 Nov 2010 13:14:44 -0000 On Wednesday, November 17, 2010 7:46:38 pm Alexandre "Sunny" Kovalenko wrote: > On Thu, 2010-11-18 at 11:13 +1100, Andrew Reilly wrote: > > Hi Alexandre, > > > > On Wed, Nov 17, 2010 at 06:56:53PM -0500, Alexandre Sunny Kovalenko wrote: > > > On Thu, 2010-11-18 at 10:40 +1100, Andrew Reilly wrote: > > > > dev.cpu.0.%desc: ACPI CPU > > > > dev.cpu.0.%driver: cpu > > > > dev.cpu.0.%location: handle=\_PR_.CPU0 > > > > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > > > > dev.cpu.0.%parent: acpi0 > > > > dev.cpu.0.freq: 2933 > > > > dev.cpu.0.freq_levels: 2933/90000 2799/83000 2666/77000 2533/71000 2399/65000 2266/59000 2133/53000 1999/46000 1866/40000 1733/34000 1599/28000 1466/22000 1333/16000 1199/10000 1049/8750 899/7500 749/6250 599/5000 449/3750 299/2500 149/1250 > > > > dev.cpu.0.cx_supported: C1/3 C2/205 C3/245 > > > > dev.cpu.0.cx_lowest: C1 > > > > dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 311us > > > > dev.cpu.1.%desc: ACPI CPU > > > > dev.cpu.1.%driver: cpu > > > > dev.cpu.1.%location: handle=\_PR_.CPU1 > > > > dev.cpu.1.%pnpinfo: _HID=none _UID=0 > > > > dev.cpu.1.%parent: acpi0 > > > > dev.cpu.1.cx_supported: C1/3 C2/205 C3/245 > > > > dev.cpu.1.cx_lowest: C1 > > > > dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 191us > > > > > > > > Since the cpufreq man page lists the inability to set the > > > > frequency of different CPUs differently, perhaps this isn't a > > > > bug at all? > > > > > > > > Cheers, > > > > > > > > > > Does portion of 'devinfo -rv' similar to the snippet below show 'est' > > > attached to both CPUs? > > > <...> > > > cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU0 > > > ACPI I/O ports: > > > 0x1014 > > > 0x1015 > > > acpi_perf0 > > > acpi_throttle0 > > > coretemp0 > > > ==> est0 > > > p4tcc0 > > > cpufreq0 > > > cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1 > > > ACPI I/O ports: > > > 0x1014 > > > 0x1015 > > > acpi_perf1 > > > acpi_throttle1 > > > coretemp1 > > > ==> est1 > > > p4tcc1 > > > cpufreq1 > > > <...> > > > > Yes, but as you can see they are not nested under coretemp. devices: > > > > cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU0 > > ACPI I/O ports: > > 0x414 > > 0x415 > > acpi_perf0 > > est0 > > p4tcc0 > > cpufreq0 > > cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1 > > ACPI I/O ports: > > 0x414 > > 0x415 > > acpi_perf1 > > est1 > > p4tcc1 > > cpufreq1 > > > > This seems to be at odds with the dmesg and sysctl view of things? > > > > Cheers, > > > > I am sorry -- in the attempt to point them out, I have messed up the > alignment -- they *should not* be nested under coretemp. It is strange > that 'est' reported error on attach, yet seems to be attached to the > device. This said, I am way out of my depth here -- hopefully someone > smarter than I will chime in. 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. -- John Baldwin