ASUS Z35Fm DSDT (for asus_acpi module)

2007-05-21 Thread Francois Marier
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.

Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]

2007-05-21 Thread Thomas Renninger
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

Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]

2007-05-21 Thread Pavel Machek
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

Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]

2007-05-21 Thread Pavel Machek
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

Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]

2007-05-21 Thread Matthew Garrett
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

Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]

2007-05-21 Thread Pavel Machek
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

Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]

2007-05-21 Thread Matthew Garrett
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

Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]

2007-05-21 Thread Pavel Machek
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

Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]

2007-05-21 Thread Matthew Garrett
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

Re: [patch 2.6.21-git] pci_choose_state() works, does ACPI magic

2007-05-21 Thread Bjorn Helgaas
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

Re: [patch 2.6.21-git] pci_choose_state() works, does ACPI magic

2007-05-21 Thread David Brownell
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:

Re: [patch 2.6.21-git] pci_choose_state() works, does ACPI magic

2007-05-21 Thread Bjorn Helgaas
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

Re: [patch 2.6.21-git] pci_choose_state() works, does ACPI magic

2007-05-21 Thread David Brownell
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

[patch 04/69] ACPI: Fix 2.6.21 boot regression on P4/HT

2007-05-21 Thread Chris Wright
-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

Re: [lm-sensors] [RFC] ACPI based hwmon driver for ASUS

2007-05-21 Thread Luca
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

Re: 2.6.21-mm2: ACPI exception on resume

2007-05-21 Thread Matt Mackall
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

Re: 2.6.21-mm2: ACPI exception on resume

2007-05-21 Thread Henrique de Moraes Holschuh
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

Re: [RFC][PATCH 4/4] swsusp: Fix hibernation code ordering (updated)

2007-05-21 Thread Pavel Machek
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

Re: [RFC][PATCH 3/4] swsusp: Introduce restore platform operations

2007-05-21 Thread Pavel Machek
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

Re: [RFC][PATCH 2/4] swsusp: Remove code duplication between disk.c and user.c

2007-05-21 Thread Pavel Machek
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

Re: [RFC][PATCH 1/4] swsusp: Remove incorrect code from user.c

2007-05-21 Thread Pavel Machek
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

Re: 2.6.22-rc1-mm1 [cannot change thermal trip points]

2007-05-21 Thread Matthew Garrett
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