http://bugzilla.kernel.org/show_bug.cgi?id=5989
------- Additional Comments From [EMAIL PROTECTED] 2006-03-28 05:28 -------
> I mean there are NO kernel hack exists to prevent THM 2,6,7?
Right, no hacks. That kernel hack was gone long ago: Once I took
THM2,6,7 out of the DSDT, I removed the hack in thermal.c. So the
kernel with 10 cycles used the BIOS-supplied DSDT. Below is the full
diff of every file (except my own compiling scripts) relative to
vanilla kernel/BIOS DSDT (i.e. config with CUSTOM_DSDT unset).
> If yes, then, it's time to do some clean up, and make a clean-patch. :-)
Except I'm worried about the unexplained kernel panic (when I didn't
use all the printk's). Maybe we have not got to the bottom of the
problem, and have merely pushed it elsewhere?
Another worrisome point is that the changes made the system hang on
the first sleep, unless I use acpi_serialize. But acpi_serialize is
not ideal on this box, because it slows down 'acpi -t' by a factor of
4, from 0.12 sec real time to 0.5 sec (but maybe nothing can be done
about that).
But here's the diff:
The current revision:
$ hg tip
changeset: 53:ec4441b5c420
tag: tip
user: Sanjoy Mahajan <[EMAIL PROTECTED]>
date: Mon Mar 27 22:04:23 2006 -0500
summary: Use vanilla DSDT.
The base revision (revision 0 is untarring 2.6.16-rc5.tar.gz):
$ hg log -r 1
changeset: 1:ac486e270597
tag: vanilla
user: Sanjoy Mahajan <[EMAIL PROTECTED]>
date: Sat Mar 18 08:35:34 2006 -0500
summary: Added my usual .config (uses vanilla DSDT).
The diff of the current revision relative to the base revision:
$ hg diff -r 1
diff -r ac486e270597 drivers/acpi/ec.c
--- a/drivers/acpi/ec.c Sat Mar 18 08:35:34 2006 -0500
+++ b/drivers/acpi/ec.c Tue Mar 28 08:20:44 2006 -0500
@@ -456,6 +456,7 @@ static int acpi_ec_intr_read(union acpi_
acpi_hw_low_level_read(8, data, &ec->common.data_addr);
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Read [%02x] from address [%02x]\n",
*data, address));
+ acpi_os_sleep (1);
end:
up(&ec->intr.sem);
@@ -506,6 +507,7 @@ static int acpi_ec_intr_write(union acpi
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Wrote [%02x] to address [%02x]\n",
data, address));
+ acpi_os_sleep (1);
up(&ec->intr.sem);
diff -r ac486e270597 drivers/acpi/osl.c
--- a/drivers/acpi/osl.c Sat Mar 18 08:35:34 2006 -0500
+++ b/drivers/acpi/osl.c Tue Mar 28 08:20:44 2006 -0500
@@ -634,6 +634,8 @@ static void acpi_os_execute_deferred(voi
return_VOID;
}
+extern int acpi_in_suspend;
+
acpi_status
acpi_os_queue_for_execution(u32 priority,
acpi_osd_exec_callback
function, void *context)
@@ -643,6 +645,12 @@ acpi_os_queue_for_execution(u32 priority
struct work_struct *task;
ACPI_FUNCTION_TRACE("os_queue_for_execution");
+ if (acpi_in_suspend) /* in case kacpid is causing the queue */
+ {
+ printk(KERN_INFO PREFIX "acpi_os_queue_for_execution:
acpi_in_suspend=%d, so returning\n", acpi_in_suspend);
+ /* should use a better error code, but oh well */
+ return_ACPI_STATUS(AE_OK);
+ }
ACPI_DEBUG_PRINT((ACPI_DB_EXEC,
"Scheduling function [%p(%p)] for deferred
execution.\n",
diff -r ac486e270597 drivers/acpi/sleep/main.c
--- a/drivers/acpi/sleep/main.c Sat Mar 18 08:35:34 2006 -0500
+++ b/drivers/acpi/sleep/main.c Tue Mar 28 08:20:44 2006 -0500
@@ -19,6 +19,12 @@
#include <acpi/acpi_drivers.h>
#include "sleep.h"
+/* for functions putting machine to sleep to know that we're
+ suspending, so that they can careful about what AML methods they
+ invoke (to avoid trying untested BIOS code paths) */
+int acpi_in_suspend;
+EXPORT_SYMBOL(acpi_in_suspend);
+
u8 sleep_states[ACPI_S_STATE_COUNT];
static struct pm_ops acpi_pm_ops;
@@ -55,6 +61,9 @@ static int acpi_pm_prepare(suspend_state
printk("acpi_pm_prepare does not support %d \n", pm_state);
return -EPERM;
}
+ acpi_os_wait_events_complete(NULL);
+ printk(KERN_INFO PREFIX "acpi_pm_prepare:
Setting acpi_in_suspend.\n");
+ acpi_in_suspend = TRUE;
return acpi_sleep_prepare(acpi_state);
}
@@ -132,6 +141,8 @@ static int acpi_pm_finish(suspend_state_
u32 acpi_state = acpi_suspend_states[pm_state];
acpi_leave_sleep_state(acpi_state);
+ printk(KERN_INFO PREFIX "acpi_pm_finish: Unsetting acpi_in_suspend.\n");
+ acpi_in_suspend = FALSE;
acpi_disable_wakeup_device(acpi_state);
/* reset firmware waking vector */
diff -r ac486e270597 drivers/acpi/thermal.c
--- a/drivers/acpi/thermal.c Sat Mar 18 08:35:34 2006 -0500
+++ b/drivers/acpi/thermal.c Tue Mar 28 08:20:44 2006 -0500
@@ -79,6 +79,8 @@ static int tzp;
static int tzp;
module_param(tzp, int, 0);
MODULE_PARM_DESC(tzp, "Thermal zone polling frequency, in 1/10 seconds.\n");
+
+extern int acpi_in_suspend;
static int acpi_thermal_add(struct acpi_device *device);
static int acpi_thermal_remove(struct acpi_device *device, int type);
@@ -683,6 +685,11 @@ static void acpi_thermal_run(unsigned lo
static void acpi_thermal_run(unsigned long data)
{
struct acpi_thermal *tz = (struct acpi_thermal *)data;
+ if (acpi_in_suspend) /* thermal methods might cause a hang */
+ {
+ printk(KERN_INFO PREFIX "acpi_thermal_run: acpi_in_suspend=%d, so
returning\n", acpi_in_suspend);
+ return_VOID; /* so don't do them */
+ }
if (!tz->zombie)
acpi_os_queue_for_execution(OSD_PRIORITY_GPE,
acpi_thermal_check, (void *)data);
@@ -705,6 +712,11 @@ static void acpi_thermal_check(void *dat
state = tz->state;
+ if (acpi_in_suspend) /* thermal methods might cause a hang */
+ {
+ printk(KERN_INFO PREFIX "acpi_thermal_check: acpi_in_suspend=%d,
so returning\n", acpi_in_suspend);
+ return_VOID;
+ }
result = acpi_thermal_get_temperature(tz);
if (result)
return_VOID;
@@ -1224,6 +1236,12 @@ static void acpi_thermal_notify(acpi_han
struct acpi_device *device = NULL;
ACPI_FUNCTION_TRACE("acpi_thermal_notify");
+
+ if (acpi_in_suspend) /* thermal methods might cause a hang */
+ {
+ printk(KERN_INFO PREFIX "acpi_thermal_notify: acpi_in_suspend=%d,
so returning\n", acpi_in_suspend);
+ return_VOID; /* so don't do them
*/
+ }
if (!tz)
return_VOID;
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
