From owner-freebsd-acpi@FreeBSD.ORG Thu Apr 6 19:27:21 2006 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FB4D16A527 for ; Thu, 6 Apr 2006 19:27:21 +0000 (UTC) (envelope-from tamaru@myn.rcast.u-tokyo.ac.jp) Received: from mail0.ecc.u-tokyo.ac.jp (mail0.ecc.u-tokyo.ac.jp [133.11.50.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED08B4455F for ; Thu, 6 Apr 2006 16:11:58 +0000 (GMT) (envelope-from tamaru@myn.rcast.u-tokyo.ac.jp) Received: from spam001.ecc.u-tokyo.ac.jp (spam001.ecc.u-tokyo.ac.jp [133.11.50.194]) by mail0.ecc.u-tokyo.ac.jp (Postfix) with ESMTP id C536A57C11D for ; Fri, 7 Apr 2006 01:11:57 +0900 (JST) Received: from 157.82.72.158 (157.82.72.158 [157.82.72.158]) by spam001.ecc.u-tokyo.ac.jp (SpamBlock.pst 3.4.90.0) with ESMTP id for ; Fri, 7 Apr 2006 01:11:40 +0900 Date: Fri, 07 Apr 2006 01:11:40 +0900 Message-ID: From: Hiroharu Tamaru To: freebsd-acpi@FreeBSD.org In-Reply-To: References: User-Agent: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-IP: 157.82.72.158 X-FROM-DOMAIN: myn.rcast.u-tokyo.ac.jp X-FROM-EMAIL: tamaru@myn.rcast.u-tokyo.ac.jp Cc: Nate Lawson Subject: Re: Is hw.pci.do_powerstate expected to be casually tuned? 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, 06 Apr 2006 19:27:25 -0000 I think I spoke too early... OK. I retried RELENG_6 kernel and learned that $FreeBSD: src/sys/dev/pci/pci.c,v 1.298 2005/09/21 19:47:00 imp Exp $ and a subsequent MFC $FreeBSD: src/sys/dev/pci/pci.c,v 1.292.2.3 2005/09/27 05:57:47 imp Exp $ has split hw.pci.do_powerstate=1 into hw.pci.do_power_resume=1 hw.pci.do_power_nodriver=0 FIVA 206VL needs hw.pci.do_power_resume=0, while do_power_nodriver can be > 0. So I'm now seeing that these are in fact expected to be tuned by an user depending on their hardware. ;-) Maybe, a better question would then be... Would it make sense to force do_power_resume = 0 when doing a S4BIOS? Is the current behavior tested on any other S4BIOS capable machine? Thanks, always. -- Hiroharu Tamaru