From owner-acpi-jp@jp.FreeBSD.org Fri Apr 16 21:03:12 2004
Received: (from daemon@localhost)
	by castle.jp.FreeBSD.org (8.11.6p2+3.4W/8.11.3) id i3GC3Co51845;
	Fri, 16 Apr 2004 21:03:12 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from ms1.cc.affrc.go.jp (ms1.cc.affrc.go.jp [150.26.254.59])
	by castle.jp.FreeBSD.org (8.11.6p2+3.4W/8.11.3) with ESMTP/inet id i3GC3B951839
	for <acpi-jp@jp.FreeBSD.org>; Fri, 16 Apr 2004 21:03:11 +0900 (JST)
	(envelope-from suetsugu@affrc.go.jp)
Received: from mailer1.affrc.go.jp (mailer1.cc.affrc.go.jp [150.26.3.164])
	by ms1.cc.affrc.go.jp (8.12.10/8.12.10) with ESMTP id i3GC2vqu021139;
	Fri, 16 Apr 2004 21:02:58 +0900 (JST)
Received: from localhost (localhost [127.0.0.1])
 by mailer1.affrc.go.jp (MAFFIN-NSS-V1.0(9))
 with ESMTP id <0HW900CH7ISQ7C@mailer1.affrc.go.jp>; Fri,
 16 Apr 2004 21:02:50 +0900 (JST)
From: Yoshitaka Suetsugu <suetsugu@affrc.go.jp>
In-reply-to: <20040319105328.GD28592@poupinou.org>
To: acpi-jp@jp.FreeBSD.org, ducrot@poupinou.org
Cc: nate@root.org, imp@bsdimp.com
Message-id: <20040415.090118.74746160.suetsugu@affrc.go.jp>
MIME-version: 1.0
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Content-type: Text/Plain; charset=iso-2022-jp
Content-transfer-encoding: 7bit
References: <20040316144529.U97064@root.org>
 <20040318161700.GA2551@portege.clkao.org> <20040319105328.GD28592@poupinou.org>
Reply-To: acpi-jp@jp.FreeBSD.org
Precedence: list
Date: Thu, 15 Apr 2004 09:01:18 +0900
X-Sequence: acpi-jp 3189
Subject: [acpi-jp 3189] Re: acpi FADT and throttle problems
Sender: owner-acpi-jp@jp.FreeBSD.org
X-Originator: suetsugu@affrc.go.jp
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+040413

  Bruno Ducrot <ducrot@poupinou.org>
$B!?!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1!1(B
> On Fri, Mar 19, 2004 at 12:17:00AM +0800, Chia-liang Kao wrote:
> > On Tue, Mar 16, 2004 at 02:48:39PM -0800, Nate Lawson wrote:
> > > Merely loading the driver won't help unless he uses the sysctls.
> > > 
> > > One thing that might help ACPI Px states when I have the driver finished
> > > and committed.  I had the driver written and then had to back off to get
> > > infrastructure working to allow it to work (acpi rman, cpu newbus
> > > attachments -- and now I have to rework those#!#@$!#@$)  It's likely SMM
> > > code sets the Px state to the lowest before suspend and doesn't reset it
> > > on resume, leaving that to the OS.  It's also possible our _PSx code in
> > > the power branch will help.
> 
> I doubt ACPI Px states will help.  It is a PIII at 500MHz and even if
> that one support SpeedStep, there is no support at all for
> P-states from ACPI point-of-view.
> 
> > Ok, I just discovered hw.acpi.toshiba.cpu_speed being contrary to
> > acpi_toshiba(4) - the higher number of the sysctl makes the cpu
> > slower.
> > 
> > However after resuming the cpu_speed is set to 0 but it's really slow
> > as if i set it to 7 before, and setting it to any value later wouldn't
> > change the speed at all.
> 
> Are you sure that after resuming it is a problem with throttling?  This
> may be an interrupt storm, for example.
> 
> -- 
> Bruno Ducrot
> 
> --  Which is worse:  ignorance or apathy?
> --  Don't know.  Don't care.
