Messages in this thread | | | Subject | 2.6.0-test9: ACPI suspend problems with acpi_ps_parse_loop() and ascending callbacks | From | Felipe Alfaro Solana <> | Date | Fri, 07 Nov 2003 15:05:55 +0100 |
| |
Hi!
I've been playing with ACPI suspend (S3) on my Packard Bell Chrom@ laptop for a few weeks.
To make the system enter S3, I do:
# echo -n mem > /sys/power/state
Most of the time, it works flawlessly, but from time to time, while trying to suspend to S3, the system is suspended incorrectly. By incorrectly I mean:
1. The system seems to enter S3 before completing proper kernel suspension, that is, freezing processes, sending power events to buses/drivers, etc. To be more concrete, upon resume, the only message shown on the screen is:
Stopping tasks: ===================================|
No additional PM events are written to the screen, like those that are dumped when the system enters S3 appropiately.
2. The harddisk is not properly spun down, but instead, it seems that power is cut out. I'm sure about this since I can clearly hear the disk heads making the typical "click" sound when they are being parked. This "click" sound should only be heard when the system shuts down (init 0) or when I remove the power plug.
3. The system seems to be able to resume. The screen lits up, but the only message that appears is the one I described above. Then, the system sits idle (hung up) or simply reboots after a few seconds.
So far, I've been trying to nail down where the problem lies. When the system enters S3 correctly, I can see that _PTS, _ADR and _GST namespaces are evaluated by the ACPI subsystem. However, from time to time, the system doesn't follow the predefined steps and prematurely and inconsistently enters S3 sleep (before it should).
Given the following code fragment from drivers/acpi/parsers/nsparse.c from the acpi_ps_parse_loop() function (starting at line ~830):
/* This op complete, notify the dispatcher */
if (walk_state->ascending_callback != NULL) { walk_state->op = op; walk_state->opcode = op->common.aml_opcode;
printk("acpi_ps_parse_loop(): calling walk_state->ascending_callback...\n"); status = walk_state->ascending_callback (walk_state); printk("acpi_ps_parse_loop(): calling acpi_ps_next_parse_state...\n"); status = acpi_ps_next_parse_state (walk_state, op, status); if (status == AE_CTRL_PENDING) { status = AE_OK; goto close_this_op; } }
I have extracted the following conclusions:
1. The problem is related to an ascending callback being invoked from the acpi_ps_parse_loop() function. The call is made in the code snippet from above.
2. When acpi_pm_prepare() is called, it seems the ACPI subsystem starts evaluating the _PTS namespace. At some point, the _ADR namespace is evaluated from within _PTS. Then, a control method must be executed and thus, acpi_psx_execute() is invoked. acpi_psx_execute() calls acpi_ps_parse_aml() which in turn calls acpi_ps_parse_loop(). Well, it's inside the code fragment shown above where the system stops executing code and then enters S3 before it should.
In fact, the first printk() displays its output, then wait_state->ascending_callback() is called and then, control does never return to the following line (the second printk). In fact, after invoking walk_state->ascending_callback() the system enters S3 without properly finalizing the suspend sequence.
I'm no ACPI expert, so I've been unable to track down what function is being pointed to by walk_state->ascending_callback(). Also, I don't understand why control is never returned after invoking the ascending callback function.
I hope someone from this list could throuw some light on this issue. I have attached a copy of /proc/acpi/dsdt and /proc/acpi/fadt to see if someone can help me in figuring out what's going on.
Thank you very much!
Felipe Alfaro
[unhandled content-type:application/octet-stream] | |