Hello,
Whenever I load the asus_acpi module, I get the following message in my
logs:
kernel: Asus Laptop ACPI Extras version 0.
kernel: unsupported model Z35FM, trying default values
kernel: send /proc/acpi/dsdt to the developers
I have attached my /proc/acpi/dsdt to this email.
On Sun, 2007-05-20 at 23:50 -0400, Len Brown wrote:
On Saturday 19 May 2007 15:56, Thomas Renninger wrote:
On Thu, 2007-05-17 at 15:17 -0400, Len Brown wrote:
On Thursday 17 May 2007 05:23, Pavel Machek wrote:
ACPI: thermal trip points are read-only
What was the
Hi!
No, writing trip-points is neither a fix, nor it is reasonable.
It is a workaround at best, and it is a dangerous and mis-leading hack.
Yes it is a workaround for critical ACPI bugs like that or similar:
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.17/+bug/22336
On Thu 2007-05-17 18:42:43, Len Brown wrote:
Something similar happened to me on XE3, yes.
(Actual values were different; BIOS specified critical temperature at
cca 95C, but hw killed the power at cca 83C. Setting critical trip
point at 80C made the problem go away.)
Great, please
On Mon, May 21, 2007 at 02:10:48PM +0200, Pavel Machek wrote:
nope, the OS can't reliably override the processor passive trip point.
That is what _SCP and cooling_mode are for.
Yes, it is reliable if you turn on thermal polling.
As Len says, the system can force a reevaluation of the trip
Hi!
For folks with the reverse problem -- active cooling where the
fans kick in early than they'd like, they should just turn off
the fans via /proc/acpi/fan and not mess with the trip points at
all.
No. Manually turning off fans is even worse hack.
It's significantly more
On Mon, May 21, 2007 at 03:29:48PM +0200, Pavel Machek wrote:
No. Manually turning off fans is even worse hack.
It's significantly more correct.
Significantly more correct? It forces you to do all the thermal
management in userspace!
Why's that a problem? Overriding the hardware
On Mon 2007-05-21 14:36:08, Matthew Garrett wrote:
On Mon, May 21, 2007 at 03:29:48PM +0200, Pavel Machek wrote:
No. Manually turning off fans is even worse hack.
It's significantly more correct.
Significantly more correct? It forces you to do all the thermal
management in
On Mon, May 21, 2007 at 03:40:46PM +0200, Pavel Machek wrote:
On Mon 2007-05-21 14:36:08, Matthew Garrett wrote:
On Mon, May 21, 2007 at 03:29:48PM +0200, Pavel Machek wrote:
Significantly more correct? It forces you to do all the thermal
management in userspace!
Why's that a
On Wednesday 09 May 2007 01:22:29 pm David Brownell wrote:
static int acpi_pci_set_power_state(struct pci_dev *dev, pci_power_t state)
{
...
+ switch (state) {
+ case PCI_D0:
+ case PCI_D1:
+ case PCI_D2:
+ case PCI_D3hot:
+ case PCI_D3cold:
+ return
On Monday 21 May 2007, Bjorn Helgaas wrote:
On Wednesday 09 May 2007 01:22:29 pm David Brownell wrote:
static int acpi_pci_set_power_state(struct pci_dev *dev, pci_power_t state)
{
...
+ switch (state) {
+ case PCI_D0:
+ case PCI_D1:
+ case PCI_D2:
+ case PCI_D3hot:
On Monday 21 May 2007 11:55:54 am David Brownell wrote:
On Monday 21 May 2007, Bjorn Helgaas wrote:
We had a bug[1] a while back where e1000 would suspend a device and
call pci_power_state(), which used ACPI to turn off the slot. The
only problem was that this was a dual-port card and the
On Monday 21 May 2007, Bjorn Helgaas wrote:
On Monday 21 May 2007 11:55:54 am David Brownell wrote:
On Monday 21 May 2007, Bjorn Helgaas wrote:
We had a bug[1] a while back where e1000 would suspend a device and
call pci_power_state(), which used ACPI to turn off the slot. The
only
-stable review patch. If anyone has any objections, please let us know.
-
From: Len Brown [EMAIL PROTECTED]
Up through 2.6.20 we cleared the FADT.CSTATE_CONTROL field
for FADT versions before r3, because it made no sense
for that reserved field to be set for pre-ACPI 2.0
On 5/21/07, Rudolf Marek [EMAIL PROTECTED] wrote:
ATK0110 ATK0110:00: atk_enumerate_fan: invalid fan count 3 (should be 5)
ATK0110: probe of ATK0110:00 failed with error -22
Ok, the FAN package contains 5 items, but the enumerator only
advertises the first 3. I guess that the other 2 (chipset
On Sun, May 20, 2007 at 12:52:59AM -0300, Henrique de Moraes Holschuh wrote:
On Sat, 19 May 2007, Matt Mackall wrote:
usually does, then go black and the machine will become totally
unresponsive, even to holding down the power button for 30+ seconds.
Now, that means either the
On Mon, 21 May 2007, Matt Mackall wrote:
BIOS Information
Vendor: IBM
Version: 1RETDHWW (3.13 )
Release Date: 10/29/2004
No sign of any EC version in the output.
This is a buggy, ancient version of the BIOS, which probably means you have
an old and slightly buggy EC
Hi!
From: Rafael J. Wysocki [EMAIL PROTECTED]
Change the code ordering so that hibernation_ops-prepare() is called after
device_suspend(). This is needed so that we don't violate the ACPI
specification, which states that the _PTS and _GTS system-control methods,
executed from
Hi!
From: Rafael J. Wysocki [EMAIL PROTECTED]
At least on some machines it is necessary to prepare the ACPI firmware for the
restoration of the system memory state from the hibernation image if the
platform mode of hibernation has been used. Namely, in that cases we need
to
disable the
Hi!
From: Rafael J. Wysocki [EMAIL PROTECTED]
Currently, much of the code in kernel/power/disk.c is duplicated in
kernel/power/user.c , mainly for historical reasons. By eliminating this code
duplication we can reduce the size of user.c quite substantially and remove
the
maintenance
On Fri 2007-05-18 00:21:21, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki [EMAIL PROTECTED]
Make the code hibernation code in kernel/power/user.c be functionally
equivalent
to the corresponding code in kernel/power/disk.c , as it should be.
The calls to the platform functions removed
On Tue, May 22, 2007 at 12:42:00AM +0200, Pavel Machek wrote:
On Mon 2007-05-21 14:45:53, Matthew Garrett wrote:
So don't do it badly. The advantage of doing so is that you can make it
work properly, which you can't by putting it in the kernel.
You want stuff like critical shutdowns to
22 matches
Mail list logo