"Paulo J. S. Silva" <[EMAIL PROTECTED]> writes: > This is somewhat a follow up to Ross Petter email.
Thanks for confirming my findings. It's good to know I didn't mess something up. > I have the same laptop as him, a U205-S5067. I also get basically the > same behavior: is I try to suspend, the screen power off very fast but > the fan start moving like there is some processing going on. > > But, if I wait long enough (between 5 and 10 minutes) the system > suspends to ram and I can wake it up successfully. However this long > time seems unreasonable and it drains battery. Suspend to disk is much > faster. > > I amusing an Ubuntu Feisty Fawn (7.04) system. > > 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 just confirmed this behavior with a 2.6.21.1 kernel, still happening. What I'm curious of is if there are any other core 2 duo laptops having this problem. If not, why does this laptop have the problem? 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
