On Tuesday, 8 May 2007 19:53, Ross Patterson wrote: > Ross Patterson <me@xxxxxxxxxxxxxx> writes: > > > Ross Patterson <me@xxxxxxxxxxxxxx> writes: > > > >> "Paulo J. S. Silva" <pjssilva@xxxxxxxxxx> 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. Well, I'm afraid no one has any idea. Otherwise, someone would have responded. ;-) I've added more appropriate lists for your problem report to the CC list. Also, it probably would be a good idea to file a bug report at http://bugzilla.kernel.org, in the ACPI->Power-Sleep-Wake category (please add my address to the bugzilla entry's CC list if you do that). Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
