From owner-freebsd-acpi@FreeBSD.ORG Mon Nov 11 20:26:59 2013 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E9C03265; Mon, 11 Nov 2013 20:26:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9B3B0247C; Mon, 11 Nov 2013 20:26:59 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id k4so2284290qaq.14 for ; Mon, 11 Nov 2013 12:26:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=k7gemk13PdTb39JsuAkT1a27y2gDUFVBvsd2nCd6CJw=; b=YaG8zdyc1IxgXPzKEUdzfW5UB/EmJDzvx3nljlzxsvEYiJop6An7YPYwLQhqXJwxG1 Jzfo1kzqmOwIA3mmZZ2FLwiDkXy1fHBnENHV6PwJQgruc2VWdOuI2lHzohcQvybRLyom +wUq2MjyxfEVlvgYJr7BuOWLoIDKY3DnQnLj4L5+8W6hy0w+oSd/PgSR+w/aK0sM/rBL yoPyg6IOpqHQJorDAiY9u/Wr2vsWoo/laqY6O/FkQywOVrSI6/2L35fDIksdodnBBZY4 kfprCTItp1RbunXF10gzDARBytyz4g9zIcdTEbdFAuSZrMOLYFDR65ryTKbCaUKRV9w5 oTCA== MIME-Version: 1.0 X-Received: by 10.224.28.130 with SMTP id m2mr51967496qac.98.1384201618790; Mon, 11 Nov 2013 12:26:58 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Mon, 11 Nov 2013 12:26:58 -0800 (PST) In-Reply-To: <5281374F.7080802@FreeBSD.org> References: <5281358D.1010406@FreeBSD.org> <5281374F.7080802@FreeBSD.org> Date: Mon, 11 Nov 2013 12:26:58 -0800 X-Google-Sender-Auth: YELKFqtWClRj8hBQm7vQZHq6me0 Message-ID: Subject: Re: Re: Problems with amd FX 8 core and freq scaling From: Adrian Chadd To: Jung-uk Kim Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-acpi X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 20:27:00 -0000 On 11 November 2013 12:00, Jung-uk Kim wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2013-11-11 13:16:47 -0500, Nicholas McKenzie wrote: >> But wouldn't this just disable frequency scaling and the whole >> point of powerd? > > No. acpi_throttle (and p4tcc) controls T-state. "Frequency scaling" > should be done by changing P-state. Right. IIRC, T-state is just for emergency temperature throttling. It shouldn't be used outside of that. >>> There have been a number of reports of throttling causing >>> crashes. This setting does not prevent powerd from adjusting >>> your CPU's clock, it just disables some arcane feature which >>> pre-dates the modern power management methods. .. did anyone ever figure out why crashes would be caused by T-state adjustment? > I rewrote acpi_throttle.c at some point to fix the problem but never > committed it because nobody was really interested in testing the > patch. Also, it is really an arcane and archaic feature: > > http://software.intel.com/en-us/blogs/2013/10/15/c-states-p-states-where-the-heck-are-those-t-states > > Now I think we should disable the feature by default because it is > causing too much hassle for us (attached). Any objection? No, I think we should correctly identify which particular features are required for which particular CPUs and enable/disable it based on that. So, if it's relevant for P4 era hardware, let's default to having it on for that class hardware. If it's not relevant for core and core 2 (and later) hardware, then let's default to leaving it off for that. So, how about we come up with a table of CPUs and what particular power save technologies we should be using, then start implementing that? I'm reading the SDM bits on the adaptive frequency stuff (turbo boost, etc) and I'll see about writing up some data gathering knobs for the kernel. People still spin up FreeBSD on P4 (and earlier) class hardware. I'd rather we get it right versus just flipping crap on and off based on what 'current' hardware expects. I watched people do this with the RTC code. It's ridiculous. -adrian