Ross Patterson <[EMAIL PROTECTED]> writes: > "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.
I further confirmed Paulo's findings. I also toggled a bunch of settings in the BIOS to see if they had any effect, including the multi-core/multi-processor setting. It always has the same symptom of heating up hugely with fan running at full for 5-10 minutes before it finally does enter sleep. It may also be worth noting that I upgraded my laptops BIOS to the latest from Toshiba, version 3.50. > 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
