Hi!
> I have also tried the LFDk CD and my machine also suspended right away.
>
> I have been trying to hunt this bug down, adding many printk to my
> kernel to see where the time is being spend.
>
> Up to now I can see that the system I get the following:
>
> enter_state in kernel/power/main.c is called that calls
> suspend_enter in kernel/power/main.c is called that calls
> device_power_up in drivers/base/power/resume that calls
> sysdev_resume in drivers/base/sys.c that start calling
>
> __sysdev_resume in the same file to resume type 'cpu' and it works OK,
> but when it is called to resume type 'timer' (actually the timer0) it
> seems to take too long.
>
> See the related portion of my messages.log below
>
> Is this the expected behavior? Should I try to debug deeper in the
> calling sequence?
Yes, I think so. Look for timer sysdev... add printks there.
> May 10 16:25:00 trinity kernel: [ 85.124000] **** timer0
> May 10 16:25:00 trinity kernel: [ 85.124000] **** In __sysdev_resume,
> calling class specific resume.
> May 10 16:25:00 trinity kernel: [ 9002.124000] **** Done
Also notice that these timestamps may not be relevant. Unless you see
the prinks with your eyes, and can confirm timing, I'd not trust it.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-------------------------------------------------------------------------
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
