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