>> Hmm, probably, you need to do :
>>
>> 4. in acpi_thermal_notify,
>> if (acpi_in_suspend == YES)
>> do nothing.
>
>I've just tested that. It suspended twice without problem, which made
>me think the problem was solved. But it hung on the third suspend!
I'm NOT surprised about that hung, because kernel thread kacpid
is a kernel worker thread that has flag PF_NOFREEZE, that means
kacpid won't be freezed. I tried to freeze kacpid, but end up with
this conclusion. From my understanding, for safety concern,
kernel worker thread should be freezed. Because, kacpid could
invoke AML methods that we are trying to avoid during suspend.
Please try additional ugly hack
5. in acpi_os_queue_for_execution:
if(acpi_in_suspend == YES)
do nothing.
Also, please add acpi_debug_layer=0x10 acpi_debug_leve=0x10
boot option, then you can observe what methods were executed
before suspend.
Thanks,
Luming
> Please try additional ugly hack
> 5. in acpi_os_queue_for_execution:
> if(acpi_in_suspend == YES)
> do nothing.
Am compiling it. If acpi_in_suspend, I've had it do
return_ACPI_STATUS(AE_BAD_PARAMETER). Is there a better error code to
use? I didn't want to use AE_OK, since the caller might think that
the function will be executed eventually, and might do something silly
like wait for it to be executed -- and produce another hang. I didn't
know, but to be safe I wanted to return an error code.
> Also, please add acpi_debug_layer=0x10 acpi_debug_leve=0x10 boot
> option, then you can observe what methods were executed before
> suspend.
That's in my lilo.conf so all kernels I test use those options. I can
send you the dmesgs from the suspends without the ugly hack (and will
send them from the upcoming suspends, with the ugly hack).
-Sanjoy
`Never underestimate the evil of which men of power are capable.'
--Bertrand Russell, _War Crimes in Vietnam_, chapter 1.