Ross Patterson <[EMAIL PROTECTED]> writes:

> Ross Patterson <[EMAIL PROTECTED]> writes:
>
>> "Paulo J. S. Silva" <[EMAIL PROTECTED]> writes:
>>
>>> I am not a kernel hacker, but I have tried to add some printk as
>>> suggested by Pavel (I haven't used udelay, I was not sure what it did
>>> (Is there a good explanation anywhere?). I added one printk to
>>> state_store function in main.c file (in kernel/power/ directory of
>>> course) to make sure that the process was starting, and many in
>>> enter_state function.
>>>
>>> What I could see, at first, is that something was taking long while the
>>> kernel was trying to disable the non-boot CPU. Here is the important log
>>> snippet (mine printk start with ****):
>>>
>>>
>>>> May  6 12:44:44 trinity kernel: [  704.412000] ****Receiving request to 
>>>> power sa
>>>> ve: mem
>>>> May  6 12:44:44 trinity kernel: [  704.412000] .
>>>> May  6 12:44:44 trinity kernel: [  704.412000] **** starting enter_state.
>>>> May  6 12:44:44 trinity kernel: [  704.412000] **** Preparing system for 
>>>> mem sle
>>>> ep
>>>> May  6 12:44:44 trinity kernel: [  704.416000] Disabling non-boot CPUs ...
>>>> May  6 12:44:44 trinity kernel: [  704.552000] CPU 1 is now offline
>>>> May  6 12:44:44 trinity kernel: [  704.552000] SMP alternatives: switching 
>>>> to UP
>>>>  code
>>>> May  6 12:55:00 trinity kernel: [  704.552000] CPU1 is down
>>>
>>> You see? Something took 10 minutes between the last two lines.
>>>
>>> I then thought that SMP was the problem. I have then disabled the second
>>> CPU during boot using "noapic nosmp" options. But I still get the same
>>> long wait before suspending. Moreover, something weird happens. There is
>>> no more delay in the sequence of messages related to suspend. But the
>>> whole sequence of messages, even the first sentence that says that the
>>> system is calling the function state_store, is only written to the disk
>>> when the system is waked up and not before the suspend take place. The
>>> same thing happen if I disable the second CPU in the bios, instead of
>>> using "noapic nosmp". What should I try now?

I was wondering if anyone has any thoughts on what we might try from
here?  I think there are at least two willing, if not knowledgable :),
testers here.

Ross


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Suspend-devel mailing list
Suspend-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/suspend-devel

Reply via email to