From owner-freebsd-current@FreeBSD.ORG Thu Dec 24 21:45:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1267910656A4; Thu, 24 Dec 2009 21:45:30 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 7E53A8FC12; Thu, 24 Dec 2009 21:45:29 +0000 (UTC) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id nBOLj4oJ028196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Dec 2009 22:45:05 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id nBOLj0XA078232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Dec 2009 22:45:02 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id nBOLj00X042764; Thu, 24 Dec 2009 22:45:00 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id nBOLivaN042763; Thu, 24 Dec 2009 22:44:57 +0100 (CET) (envelope-from ticso) Date: Thu, 24 Dec 2009 22:44:57 +0100 From: Bernd Walter To: Kevin Oberman Message-ID: <20091224214457.GA2260@cicely7.cicely.de> References: <20091224174809.GZ2260@cicely7.cicely.de> <20091224202223.732631CC0C@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091224202223.732631CC0C@ptavv.es.net> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.015, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: Gleb Kurtsou , Doug Barton , ticso@cicely.de, freebsd-current@freebsd.org, "b. f." Subject: Re: powerd and nvidia drivers not playing nicely together (Was: Re: Systems running hot?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2009 21:45:30 -0000 On Thu, Dec 24, 2009 at 12:22:23PM -0800, Kevin Oberman wrote: > > Date: Thu, 24 Dec 2009 18:48:10 +0100 > > From: Bernd Walter > > > > On Thu, Dec 24, 2009 at 08:24:12AM -0800, Kevin Oberman wrote: > > > > Date: Thu, 24 Dec 2009 11:46:26 +0100 > > > > From: Bernd Walter > > > > Sender: owner-freebsd-current@freebsd.org > > > > > > > > On Wed, Dec 23, 2009 at 04:44:35PM +0200, Gleb Kurtsou wrote: > > > > > On (21/12/2009 19:18), Doug Barton wrote: > > > > > > b. f. wrote: > > > > > > > On 12/21/09, Doug Barton wrote: > > > > > > >> b. f. wrote: > > > > > > >>>> no X! So I think to myself, what else did I change last night.... oh > > > > > > > > > > > > > >>> acpi_perf? acpi_throttle? acpi_thermal? acpi_video? > > > > > > >> I haven't done anything special with the acpi stuff. The only thing > > > > > > >> that looks relevant from dmesg is: acpi_tz0: on acpi0 > > > > > > >> > > > > > > > > > > > > > > Yes, but which components show up in 'sysctl -a | grep -ie acpi' ? > > > > > > > > > > > > It's a long list, but here you go: > > > > > > http://people.freebsd.org/~dougb/acpi-grep.txt > > > > > > > > > > > > >>> Which nvidia driver? > > > > > > >> The latest. > > > > > > > > > > > > > > Which video card? > > > > > > > > > > > > nvidia0: > > > > > I had similar problems with GeForce 8400M. GPU temperature could get up > > > > > to 100C in X, which increased CPU temperature in its turn. I use > > > > > powerd, and had lockups with *_cx_lowest settings. I run amd64, i386 was > > > > > just fine on the same notebook. > > > > > > > > It is not just nvidia. > > > > I'm using two plain old PCI Matrox G400 and whenever I start X with > > > > powerd enabled I have a full freeze within 24 hours. > > > > It doesn't seem to be a problem to start powerd once X is runnning. > > > > Maybe it is something like tuning some delay loop with reduced clock > > > > rate, which then isn't long enough with increased speed. > > > > > > Quick question...are you using throttling/TCC? If so, either turn it off > > > or limit how low it can run the CPU. When I was running throttling on > > > systems with old Matrox and Radeon cards, they would freeze if the > > > throttling went too low. > > > > I asume yes - not sure about all those modern fancy names. > > In other words dev.cpu.?.freq changes. > > > > > As mav pointed out at http://wiki.freebsd.org/TuningPowerConsumption, > > > TCC does little to conserve power and was not designed for that. TCC is > > > Thermal Control Circuit and is designed to keep the CPU form > > > over-temping. It works for this, but not power management. I'd love to > > > see it off (for power management) by default. > > > hint.p4tcc.0.disabled=1 > > > hint.acpi_throttle.0.disabled=1 > > > > What is the difference between the hints and disabling powerd? > > The hints simply disable throttling and TCC for power management. > > These are ALMOST identical techniques for controlling high CPU > temperature. They were never intended to be used for power > management. Both work by skipping N of 8 CPU cycles. When a system using > ACPI exceeds the value of hw.acpi.thermal.tz0._PSV, it will engage > TCC. Older systems used throttling under software control for the same > purpose, but FreeBSD did not implement it, as far as I know. > > SpeedStep and its relatives on both Intel and AMD chips is designed for > power management and those are all I use on my systems. These are the > relevant sysctls: > dev.cpu.0.freq_levels: 2000/27000 1600/22600 1333/19666 1066/16733 800/13800 > dev.cpu.0.cx_supported: C1/1 C2/1 C3/85 C4/185 > > I only have 5 "frequency" settings, but all work by actually slowing the > clock and reducing voltage, so they really save power. I also have 4 'C' > states which also can be a huge win as they allow the system to use far > less power when idle. Different systems have more or fewer available > states. C2 saves fairly little power. C3 (if available) is a big winner > and C4 and above are even better, but read mav's article for a better > description. > > Now the bad news. As you note, you have only C1. At this time the > available frequencies are all from TCC, not SpeedStep. I thought all C2 > chips supported EST. It should be listed in the CPU features2 at the > start of /var/run/dmesg.boot. > > You should also have: > est0: on cpu0 > est1: on cpu1 > est2: on cpu2 > est3: on cpu3 > in the dmesg, but I suspect that, for some reason, you don't, and I > don't know why. Well I do have them: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (2419.30-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100000 AMD Features2=0x1 Cores per package: 4 real memory = 9126805504 (8704 MB) avail memory = 8125517824 (7749 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 cpu2: on acpi0 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 cpu3: on acpi0 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 How would you know that the frequencies are from TCC and not SpeedStep? Maybe I should mention, that the system is running 7.0-stable, so it is not running recent code. But my server is running an almost identic board with 8.0-RC1 amd64 and has similar sysctl output: [139]cicely14# sysctl dev.cpu 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.temperature: 34.0C dev.cpu.0.freq: 2394 dev.cpu.0.freq_levels: 2394/89000 2094/77875 1795/66750 1496/55625 1197/44500 897/33375 598/22250 299/11125 dev.cpu.0.cx_supported: C1/1 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% last 500us 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.temperature: 32.0C dev.cpu.1.cx_supported: C1/1 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% last 500us dev.cpu.2.%desc: ACPI CPU dev.cpu.2.%driver: cpu dev.cpu.2.%location: handle=\_PR_.CPU2 dev.cpu.2.%pnpinfo: _HID=none _UID=0 dev.cpu.2.%parent: acpi0 dev.cpu.2.temperature: 30.0C dev.cpu.2.cx_supported: C1/1 dev.cpu.2.cx_lowest: C1 dev.cpu.2.cx_usage: 100.00% last 500us dev.cpu.3.%desc: ACPI CPU dev.cpu.3.%driver: cpu dev.cpu.3.%location: handle=\_PR_.CPU3 dev.cpu.3.%pnpinfo: _HID=none _UID=0 dev.cpu.3.%parent: acpi0 dev.cpu.3.temperature: 30.0C dev.cpu.3.cx_supported: C1/1 dev.cpu.3.cx_lowest: C1 dev.cpu.3.cx_usage: 100.00% last 500us > Unfortunately, most servers and desktops are pretty poor at power > management compared to laptops, though they are getting batter. My C2 > Quad system does have C2, though no C3, but EST does work there. Yes - it is a desktop board and not the most modern - and not the very best BIOS from my expirience. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.