From owner-freebsd-acpi@freebsd.org Mon Feb 27 19:15:59 2017 Return-Path: Delivered-To: freebsd-acpi@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A409CF002D for ; Mon, 27 Feb 2017 19:15:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4149B88F for ; Mon, 27 Feb 2017 19:15:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v1RJFwZh056068 for ; Mon, 27 Feb 2017 19:15:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-acpi@FreeBSD.org Subject: [Bug 217247] [acpi] r265474 makes 11.0R unusable with Atom 330 Date: Mon, 27 Feb 2017 19:15:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: stephane_freebsd@lesimple.fr X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-acpi@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 19:15:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D217247 --- Comment #4 from St=C3=A9phane Lesimple -= -- (In reply to Adrian Chadd from comment #2) Compiled HEAD this morning, namely base r314326 and booted it. It does behave differently: at boot I couldn't observe the slowdown. However after some digging, I found out that HEAD's /etc/default/rc.conf is different and now contains: > performance_cx_lowest=3D"NONE" Where 11.0R contained > performance_cx_lowest=3D"Cmax" (introduced by base r265474) On my system, NONE translates to C1, as shown by sysctl -a, so that's why it behaves properly: it never tries to use C2 or C3. I tried to manually set dev.cpu.X.cx_lowest to C2, and see if the slowdown = was still there, but it wasn't. However sysctl indicates that my setting is completely ignored and the system always uses C1, as seen by cx_usage: dev.cpu.0.cx_method: C1/hlt C2/io C3/io dev.cpu.0.cx_usage_counters: 4617 0 0 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 49467us dev.cpu.0.cx_lowest: C2 dev.cpu.0.cx_supported: C1/1/0 C2/2/1 C3/3/85 dev.cpu.0.%parent: acpi0 dev.cpu.0.%pnpinfo: _HID=3Dnone _UID=3D0 dev.cpu.0.%location: handle=3D\_PR_.P001 dev.cpu.0.%driver: cpu dev.cpu.0.%desc: ACPI CPU So this *is* indeed different from 11.0R. For some reason the kernel now chooses to keep C1 at all times, even if I tell it that C2 is okay. If you = want me to try anything, just ask, I'm keeping HEAD's memstick.img around just in case. --=20 You are receiving this mail because: You are the assignee for the bug.=