From owner-freebsd-acpi@FreeBSD.ORG Thu Jun 30 22:52:38 2011 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BD3D106566B; Thu, 30 Jun 2011 22:52:38 +0000 (UTC) (envelope-from vmagerya@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id BB1698FC12; Thu, 30 Jun 2011 22:52:35 +0000 (UTC) Received: by vws18 with SMTP id 18so2764576vws.13 for ; Thu, 30 Jun 2011 15:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4ZJqLRb3N0ehF0ZgxJ3aK0gKTw+ZT9oerfHVuM9qoM8=; b=M6VlVSg70F5uZnstfSCmlwsleXZsHLfH80fw4Nrr+RCSdCpKwU1a4UOwQdD3yH5bTu zs2zQqxdhhf3hlDI7Ogu4GUkFRxA9DbttZtxm7yPzui9EkUxGfgLuTdtqkaep1yM27TA VT8OnuOMsKwBFMBJTDQqSWGhgX5qnLte1dyDo= MIME-Version: 1.0 Received: by 10.52.66.199 with SMTP id h7mr3607765vdt.119.1309474354284; Thu, 30 Jun 2011 15:52:34 -0700 (PDT) Received: by 10.52.108.226 with HTTP; Thu, 30 Jun 2011 15:52:34 -0700 (PDT) In-Reply-To: <4E0CE158.6030804@FreeBSD.org> References: <4E05EB91.9090509@FreeBSD.org> <4E0862A0.7060405@FreeBSD.org> <4E09BADF.7050702@FreeBSD.org> <4E0A41C8.3000904@FreeBSD.org> <4E0CE158.6030804@FreeBSD.org> Date: Fri, 1 Jul 2011 01:52:34 +0300 Message-ID: From: Vitaly Magerya To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-acpi@freebsd.org Subject: Re: (Missing) power states of an Atom N455-based netbook X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 22:52:38 -0000 Andriy Gapon wrote: > Here's what Intel docs say: > > The processor implements two software interfaces for requesting low power > states, MWAIT instruction extensions with sub-state hints and P_LVLx reads to > the ACPI P_BLK register block mapped in the processor's I/O address space. The > P_LVLx I/O reads are converted to equivalent MWAIT C-state requests inside the > processor and do not directly result in I/O reads on the processor FSB. > > My interpretation is that both mechanism should work equally. I see. >> Just tried this. Nothing seems fried; the visible effect is that >> now when I plug the power cord in backlight brightness turns all >> the way up, and then back down the I turn it off. No changes in >> SNVS or GNVS variables aside from the usual ones. > > At least some improvement (or just a difference)... Since VDRV is always 0, you can't really say if it's a coincidence or the intended behavior. > Not sure how to proceed here further. Apparently we do something differently > from Linux (and presumably Windows) here, but it's quite hard to tell what. The > problem is that SNVS/GNVS (in particular C1ON) seem to be controlled by some > firmware/hardware and that's a black box. > And I am still puzzled about which exactly event triggers change in C1ON value > on FreeBSD... I got the dumps for Linux (it appears that you can't just read /dev/mem on there, you need to mmap it). The summary of differences between FreeBSD and Linux right after the boot: DB00: 01 -> 00 P80D: 06:08:00:00 -> 06:08:4C:00 PCP0: 1D -> BF PCP1: 1D -> BF BRTL: 00 -> 1E VDRV: 00 -> 01 (Note that C1ON is 0 just as with FreeBSD, and yet powertop does report C2 and C4). Then, after about 4 minutes of uptime, C1ON changes to 1 (and powertop still reports the same states). > Do you have powerd enabled? Can you check if anything changes > with it disabled (just for the sake of testing). I do; nothing changes if I don't. > P.S. Just an idea, maybe the following script could be of some help if you > have dtrace support in your kernel: > $ dtrace -n 'fbt::AcpiEvaluateObject:entry { printf("%p->%s\n", args[0], > (string)args[1]); }' > I would like to get entries, if any, around the time that the C-states > become available. I'll try to compile the kernel with dtrace and post the results back.