Skip to contentSkip to conversation

ACPI Lock after resume from S3 [2.5.59+latest ACPI]

DISCUSSION Alvaro Lopes 2 participants 2 messages Feb 6, 2003 1 message not in the archive ACPI

lore
Share & tools
lore

Alvaro Lopes

author
#0 lore raw

Hi list

here's the problem:

My toshiba enters S3 via acpi_enter_sleep_state(). It goes to sleep right after writing PM1A_CONTROL with SLP_ENABLE. It resumes then to the caller [acpi_suspend()] and then calls acpi_restore_system_state() and finally acpi_leave_sleep_state().

The problem is that it enters a deadlock because:

1- When setting PM1A_CONTROL with flag ACPI_MTX_LOCK, the hardware
mutex is locked, the system enters sleep right after writing the register and never unlocks the mutex, because it resumes to a different point;

2- in acpi_leave_sleep_state() we disable BM artbitration, and here
it locks forever, waiting a hardware mutex release.

Disabling APCI_MTX_LOCK on the 1st point seems to go around the problem, and the system resumes almost OK, only HDD DMA is disabled:

Feb  6 18:19:26 supernova kernel: hda: status timeout: status=0x80 { Busy }
Feb  6 18:19:26 supernova kernel: hda: DMA disabled
Feb  6 18:19:26 supernova kernel: hda: drive not ready for command
Feb  6 18:19:27 supernova kernel: ide0: reset: master: error (0x00?)

Álvaro

Signature · 10 lines
Álvaro Lopes ---------------------
A .sig is just a .sig




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld =Something 2 See!
http://www.vasoftware.com

A message that is not in the archive (sent off-list or not yet received): [email protected]

#2 lore raw
Quoted 9 lines · Alvaro Lopes

Hi list

here's the problem:

My toshiba enters S3 via acpi_enter_sleep_state(). It goes to sleep right after writing PM1A_CONTROL with SLP_ENABLE. It resumes then to the caller [acpi_suspend()] and then calls acpi_restore_system_state() and finally acpi_leave_sleep_state().

Quoted 6 lines

The problem is that it enters a deadlock because:

1- When setting PM1A_CONTROL with flag ACPI_MTX_LOCK, the hardware
mutex is locked, the system enters sleep right after writing the register and never unlocks the mutex, because it resumes to a different point;

Good point.
In fact, I am wondering why we have to acquire the hardware lock at all here. (We should be the only thread allowed to be scheduled, here.)

Quoted 3 lines

2- in acpi_leave_sleep_state() we disable BM artbitration, and here
it locks forever, waiting a hardware mutex release.

The comment is wrong. In fact we ensure that BM arbitration is on.

Quoted 7 lines

Disabling APCI_MTX_LOCK on the 1st point seems to go around the problem, and the system resumes almost OK, only HDD DMA is disabled:

Feb  6 18:19:26 supernova kernel: hda: status timeout: status=0x80 { Busy }
Feb  6 18:19:26 supernova kernel: hda: DMA disabled
Feb  6 18:19:26 supernova kernel: hda: drive not ready for command
Feb  6 18:19:27 supernova kernel: ide0: reset: master: error (0x00?)

Problem with the ide bridge resume path perhaps ?

Signature · 10 lines
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com