On Tue, 2 Dec 2003, Nate Lawson wrote:
> Build with options ACPI_DEBUG and boot with this in loader.conf:
> debug.acpi.layer=ACPI_POWER
> debug.acpi.level=ACPI_LV_OBJECTS
>
> It will print any power resources you have.
Unfortunately, there's no power resource listed.
regards,
le
--
Lukas Ertl
On Tue, 2 Dec 2003, Lukas Ertl wrote:
> On Tue, 2 Dec 2003, Nate Lawson wrote:
> > Um, you have no _ACx values so the fan will be controlled by the BIOS. We
> > should probably provide a way for users to supply their own _ACx values if
> > they're not happy with the BIOS's but I'm not sure your AS
On Tue, 2 Dec 2003, Nate Lawson wrote:
> Um, you have no _ACx values so the fan will be controlled by the BIOS. We
> should probably provide a way for users to supply their own _ACx values if
> they're not happy with the BIOS's but I'm not sure your ASL exports a
> power resource for the fan obje
On Wed, 26 Nov 2003, Lukas Ertl wrote:
> On Wed, 26 Nov 2003, Nate Lawson wrote:
> > I need the output of sysctl hw.acpi.thermal to see your _ACx values.
>
> hw.acpi.thermal.tz0.temperature: 3072
> hw.acpi.thermal.tz0.active: -1
> hw.acpi.thermal.tz0.thermal_flags: 0
> hw.acpi.thermal.tz0._PSV: 362
On Wed, 26 Nov 2003, Nate Lawson wrote:
> On Wed, 26 Nov 2003, Lukas Ertl wrote:
> > On Wed, 26 Nov 2003, Nate Lawson wrote:
> > > It's possible the fan is under BIOS control so make sure you have an
> > > up-to-date bios. If not, you should get a console printout when acpi
> > > switches the fan
On Wed, 26 Nov 2003, Lukas Ertl wrote:
> On Wed, 26 Nov 2003, Nate Lawson wrote:
> > It's possible the fan is under BIOS control so make sure you have an
> > up-to-date bios. If not, you should get a console printout when acpi
> > switches the fan on. sysctl hw.acpi.thermal
>
> Nope, no ACPI mess
On Wed, 26 Nov 2003, Nate Lawson wrote:
> It's possible the fan is under BIOS control so make sure you have an
> up-to-date bios. If not, you should get a console printout when acpi
> switches the fan on. sysctl hw.acpi.thermal
Nope, no ACPI messages, and I can't find a FAN device in my ASL. (A
On Fri, 21 Nov 2003, Lukas Ertl wrote:
> On Fri, 21 Nov 2003, Nate Lawson wrote:
> > > > On Tue, 18 Nov 2003, Lukas Ertl wrote:
> > > > > I'm gonna try some "buildkernelstones" with the different settings. If
> > > > > you have some special benchmarks in mind I'd be happy to run them.
> > > >
> >
I believe this completes the changes to acpi_cpu for 5.2. Please test on
SMP boxes and laptops and if you were disabling it before, please
re-enable it to test. (To do that, remove debug.acpi.disable from
loader.conf).
Thanks,
Nate
-- Forwarded message --
Date: Wed, 26 Nov 2003
On Sat, 22 Nov 2003, Lukas Ertl wrote:
> Ah, this would explain why I can see the C3 states change after a
> suspend/resume - USB is dead then :-)
>
> I'm gonna try without USB and send you the output again.
Yes, looks better now:
hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 C3/185
hw.acpi.cpu.cx_l
On Fri, 21 Nov 2003, Nate Lawson wrote:
> On Sat, 22 Nov 2003, Lukas Ertl wrote:
> > On Fri, 21 Nov 2003, Nate Lawson wrote:
> >
> > > Those are what is more interesting. Also, can you send me your sysctl
> > > hw.acpi.cpu.cx_history after you've used it for a while with the maximum
> > > cx_lowe
On Sat, 22 Nov 2003, Lukas Ertl wrote:
> On Fri, 21 Nov 2003, Nate Lawson wrote:
>
> > Those are what is more interesting. Also, can you send me your sysctl
> > hw.acpi.cpu.cx_history after you've used it for a while with the maximum
> > cx_lowest setting?
>
> hw.acpi.cpu.cx_supported: C1/1 C2/1 C
On Fri, 21 Nov 2003, Nate Lawson wrote:
> > > On Tue, 18 Nov 2003, Lukas Ertl wrote:
> > > > I'm gonna try some "buildkernelstones" with the different settings. If
> > > > you have some special benchmarks in mind I'd be happy to run them.
> > >
> > > That's probably ok. It has a lot of IO.
> >
>
> > On Tue, 18 Nov 2003, Lukas Ertl wrote:
> > > I'm gonna try some "buildkernelstones" with the different settings. If
> > > you have some special benchmarks in mind I'd be happy to run them.
> >
> > That's probably ok. It has a lot of IO.
>
> Now I've tried running make buildkernel and tarring
On Wed, 19 Nov 2003, Eric Anderson wrote:
> Nate Lawson wrote:
> >You should run a benchmark with different values for
> >hw.acpi.cpu.current_speed to be sure the throttling control still works
> >ok. I left it mostly intact so you shouldn't see any problems but it's
> >still good to test. As you
On Tue, 18 Nov 2003, Nate Lawson wrote:
> On Tue, 18 Nov 2003, Lukas Ertl wrote:
> >
> > I'm gonna try some "buildkernelstones" with the different settings. If
> > you have some special benchmarks in mind I'd be happy to run them.
>
> That's probably ok. It has a lot of IO.
Now I've tried runni
On Wed, 19 Nov 2003, Harald Schmalzbauer wrote:
> On Wednesday 19 November 2003 16:31, Nate Lawson wrote:
> > Ok, here's the final patch. I believe it fixes both problems.
> >
> *SCHNIP*
>
> Yep, seems really final. I downloaded the acpi_cpi.c from cvs-web to be sure
> to have the correct one and
On Wednesday 19 November 2003 16:31, Nate Lawson wrote:
> Ok, here's the final patch. I believe it fixes both problems.
>
*SCHNIP*
Yep, seems really final. I downloaded the acpi_cpi.c from cvs-web to be sure
to have the correct one and applied your patch.
hw.acpi.cpu.cx_supported: C1/0
hw.acpi.
On Wed, 19 Nov 2003, Robert Watson wrote:
> On Wed, 19 Nov 2003, Nate Lawson wrote:
> > On Wed, 19 Nov 2003, Robert Watson wrote:
> > > Success! The system rebooted without panicking. It even came back up
> > > cleanly. :-)
> >
> > Good to hear. I think Don has the same problem as Harald so perh
On Wed, 19 Nov 2003, Nate Lawson wrote:
> On Wed, 19 Nov 2003, Robert Watson wrote:
> > On Wed, 19 Nov 2003, Nate Lawson wrote:
> >
> > > Ok, here's the final patch. I believe it fixes both problems.
> >
> > Success! The system rebooted without panicking. It even came back up
> > cleanly. :-)
On Wed, 19 Nov 2003, Robert Watson wrote:
> On Wed, 19 Nov 2003, Nate Lawson wrote:
>
> > Ok, here's the final patch. I believe it fixes both problems.
>
> Success! The system rebooted without panicking. It even came back up
> cleanly. :-)
Good to hear. I think Don has the same problem as Hara
ou still want it.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
>
> * Add a DEVMETHOD for acpi so that child detach methods get called. Add
> an acpi_cpu method for both detach and shutdown that disables en
Ok, here's the final patch. I believe it fixes both problems.
* Add a DEVMETHOD for acpi so that child detach methods get called. Add
an acpi_cpu method for both detach and shutdown that disables entry to
acpi_cpu_idle and then IPIs/waits for threads to exit. This fixes a panic
late in r
On Tue, 18 Nov 2003, Nate Lawson wrote:
> On Tue, 18 Nov 2003, Don Lewis wrote:
> >
> > Yup, a Thinkpad R40, which refuses to actually power down in ACPI mode
> > when I run "shutdown -p".
>
> That's an old problem that Linux is also trying to work around. It
> appears to be buggy hw.
Just for t
On Tue, 18 Nov 2003, Don Lewis wrote:
> On 18 Nov, Lukas Ertl wrote:
> > On Tue, 18 Nov 2003, Nate Lawson wrote:
>
> >> This excerpt from truckman@'s asl shows that 4 Cx states are only
> >> available when the AC adapter is not attached. (The C*NA memory addresses
> >> appear to be managed by the
On 18 Nov, Lukas Ertl wrote:
> On Tue, 18 Nov 2003, Nate Lawson wrote:
>> This excerpt from truckman@'s asl shows that 4 Cx states are only
>> available when the AC adapter is not attached. (The C*NA memory addresses
>> appear to be managed by the BIOS and not the AML but the PSR access is
>> cle
On Tue, 18 Nov 2003, Robert Watson wrote:
> On Tue, 18 Nov 2003, Nate Lawson wrote:
> > Could you add a printf to the start of acpi_cpu_detach()? I want to see
> > if we're being called before or after ACPI is stopped ("Shutting down
>
> So indeed, it doesn't look like the ACPI detach call has gon
On Tue, 18 Nov 2003, Nate Lawson wrote:
> On Tue, 18 Nov 2003, Robert Watson wrote:
> > On Tue, 18 Nov 2003, Nate Lawson wrote:
> >
> > > Below you'll find the update patch for acpi_cpu. Please test this,
> > > especially for SMP and laptops with _CST obj
On Tue, 18 Nov 2003, Lukas Ertl wrote:
> On Tue, 18 Nov 2003, Nate Lawson wrote:
> > Try settings of cx_lowest of 1 and 2 (and 3 when the last C3 state is
> > available). I'm interested in any benchmark results, especially IO. I'm
> > hoping the scheduling of sleeps is good enough that you don't
On Tue, 18 Nov 2003, Nate Lawson wrote:
> On Tue, 18 Nov 2003, Lukas Ertl wrote:
>
> > hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85
> > hw.acpi.cpu.cx_lowest: 0
> > hw.acpi.cpu.cx_history: 86231/0 0/0 0/0
>
> Try settings of cx_lowest of 1 and 2 (and 3 when the last C3 state is
> available). I'm int
On Tue, 18 Nov 2003, Robert Watson wrote:
> On Tue, 18 Nov 2003, Nate Lawson wrote:
>
> > Below you'll find the update patch for acpi_cpu. Please test this,
> > especially for SMP and laptops with _CST objects in their ASL.
> ...
> > Notes:
> > * Add
On Tue, 18 Nov 2003, Lukas Ertl wrote:
> On Tue, 18 Nov 2003, Nate Lawson wrote:
> > Below you'll find the update patch for acpi_cpu. Please test this,
> > especially for SMP and laptops with _CST objects in their ASL.
>
> Looks good here on a Centrino based laptop,
On Tue, 18 Nov 2003, Nate Lawson wrote:
> Below you'll find the update patch for acpi_cpu. Please test this,
> especially for SMP and laptops with _CST objects in their ASL.
...
> Notes:
> * Add a detach method that disables entry to acpi_cpu_idle and in the SMP
> case, IP
On Tue, 18 Nov 2003, Lukas Ertl wrote:
> hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85
> hw.acpi.cpu.cx_lowest: 0
> hw.acpi.cpu.cx_history: 86231/0 0/0 0/0
>
> Although it seems I have lost a C3 state (before, I had an additional
> C3/185).
Correction: every other boot I get the additional C3/185 - s
On Tue, 18 Nov 2003, Nate Lawson wrote:
> Below you'll find the update patch for acpi_cpu. Please test this,
> especially for SMP and laptops with _CST objects in their ASL.
Looks good here on a Centrino based laptop, which has a _CST method in
its ASL:
acpi_cpu0: on acpi0
acpi_cpu
Below you'll find the update patch for acpi_cpu. Please test this,
especially for SMP and laptops with _CST objects in their ASL.
Thanks,
Nate
Notes:
* Add a detach method that disables entry to acpi_cpu_idle and in the SMP
case, IPIs all processors to exit sleeping. This fixes a pan
On 21-Jan-2003 Nate Lawson wrote:
> How is this?
>
> --- acpi_cpu.c 16 Oct 2002 17:28:52 - 1.14
> +++ acpi_cpu.c 21 Jan 2003 06:07:43 -
> @@ -295,8 +295,10 @@
> /* set initial speed */
> acpi_cpu_power_profile(NULL);
>
> -print
In the last episode (Jan 21), Terry Lambert said:
> I think that changing the order from "100% to 10%" to "10% to 100%"
> will, if people ignore the second printed line, imply that there was
> a transition from 10% to 100%, rather than the reverse (that was my
> response to the patch).
Or better y
Daniel Holmes wrote:
> > +printf("acpi_cpu: throttling enabled, %d steps from 100%% to %d.%d%%, "
> > + "currently %d.%d%%\n"
>
> Personally, rather than 'enabled', how about 'available'? Using the
> word enabled might gi
On Tue, 21 Jan 2003, Daniel Holmes wrote:
> > +printf("acpi_cpu: throttling enabled, %d steps from 100%% to %d.%d%%, "
> > + "currently %d.%d%%\n"
>
> Personally, rather than 'enabled', how about 'available'? Using the
&g
> +printf("acpi_cpu: throttling enabled, %d steps from 100%% to %d.%d%%, "
> + "currently %d.%d%%\n"
Personally, rather than 'enabled', how about 'available'? Using the
word enabled might give some newbies fits when they try to f
Nate Lawson wrote:
> How is this?
[ ... less alarming throttling message ... ]
I like it. I don't know if it's redundant with the "currently ..."
thing, but I'd like to see it:
+printf("acpi_cpu: throttling enabled, %d steps from %d.%d%% to 100%%, "
How is this?
--- acpi_cpu.c 16 Oct 2002 17:28:52 - 1.14
+++ acpi_cpu.c 21 Jan 2003 06:07:43 -
@@ -295,8 +295,10 @@
/* set initial speed */
acpi_cpu_power_profile(NULL);
-printf("acpi_cpu: CPU throttling enabled, %d steps from 100%% to %d.%
43 matches
Mail list logo
