Greetings,
Ive been following your discussion and documentation efforts concerning pm in the kernel. This has in the past been a gray area which was hard to find information about so kudos.
I maintain 2 handheld platforms that would benefit greatly from implementing proper pm (mainly suspend) but Im having problems bugtracking it. Currently the system tries to suspend but fails somewhere and then tries to resume (which fails). The end result however is that Im unable to see anything (bugmessages...) since the video driver gets deactivated by pm.
My question is this: Is bisecting (turning off device support in kernel until it works) the best approach when bugtracking pm suspend? Or is there any other logging system that I can use?
--
Kristoffer Ericson <[email protected]>
Kristoffer Ericson wrote:
> Greetings,
>
> Ive been following your discussion and documentation efforts concerning pm
> in the kernel. This has in the past been a gray area which was hard to
> find information about so kudos.
>
> I maintain 2 handheld platforms that would benefit greatly from
> implementing proper pm (mainly suspend) but Im having problems bugtracking
> it. Currently the system tries to suspend but fails somewhere and then
> tries to resume (which fails). The end result however is that Im unable to
> see anything (bugmessages...) since the video driver gets deactivated by
> pm.
>
> My question is this: Is bisecting (turning off device support in kernel
> until it works) the best approach when bugtracking pm suspend? Or is there
> any other logging system that I can use?
>
Good question. I could use advice too :)
Bisecting is good only if you have known good and known bad versions. From
your description it sounds like it has never worked - so bisecting won't
help. Also sometimes bisecting hits way too large commit (this happened to
me when ACPI replaced mutex with spinlock).
On Friday, 16 of November 2007, Andrey Borzenkov wrote:
> Kristoffer Ericson wrote:
>
> > Greetings,
> >
> > Ive been following your discussion and documentation efforts concerning pm
> > in the kernel. This has in the past been a gray area which was hard to
> > find information about so kudos.
> >
> > I maintain 2 handheld platforms that would benefit greatly from
> > implementing proper pm (mainly suspend) but Im having problems bugtracking
> > it. Currently the system tries to suspend but fails somewhere and then
> > tries to resume (which fails). The end result however is that Im unable to
> > see anything (bugmessages...) since the video driver gets deactivated by
> > pm.
> >
> > My question is this: Is bisecting (turning off device support in kernel
> > until it works) the best approach when bugtracking pm suspend? Or is there
> > any other logging system that I can use?
> >
>
> Good question. I could use advice too :)
>
> Bisecting is good only if you have known good and known bad versions. From
> your description it sounds like it has never worked - so bisecting won't
> help. Also sometimes bisecting hits way too large commit (this happened to
> me when ACPI replaced mutex with spinlock).
If I understand the original post correctly, Kristoffer didn't mean searching
for a bad patch using bisection. :-)
On Saturday, 17 of November 2007, Kristoffer Ericson wrote:
> Greetings,
>
> Ive been following your discussion and documentation efforts concerning pm
> in the kernel. This has in the past been a gray area which was hard to find
> information about so kudos.
Thanks!
> I maintain 2 handheld platforms that would benefit greatly from implementing
> proper pm (mainly suspend) but Im having problems bugtracking it. Currently
> the system tries to suspend but fails somewhere and then tries to resume
> (which fails). The end result however is that Im unable to see anything
> (bugmessages...) since the video driver gets deactivated by pm.
That's bad.
> My question is this: Is bisecting (turning off device support in kernel until
> it works) the best approach when bugtracking pm suspend? Or is there any
> other logging system that I can use?
Well, various approaches are possible.
First, you can build as many drivers as possible as modules and boot with
init=/bin/bash . Then, try to suspend and resume and if that fails, the
problem is somewhere deeper. If that goes well, one of the drivers is failing
and you'll need to find it (eg. by bisection).
Second, on x86 we have PM_TRACE which uses the RTC to store some debugging
information that can be used later to identify the point of failure. This
might be portable to your platforms.
Next, you can use my recent patches (available at
http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.24-rc2/patches/) to
check how deep the problem is located.
Greetings,
Rafael
On Fri 2007-11-16 16:14:20, Kristoffer Ericson wrote:
> Greetings,
>
> Ive been following your discussion and documentation efforts concerning pm in the kernel. This has in the past been a gray area which was hard to find information about so kudos.
>
> I maintain 2 handheld platforms that would benefit greatly from implementing proper pm (mainly suspend) but Im having problems bugtracking it. Currently the system tries to suspend but fails somewhere and then tries to resume (which fails). The end result however is that Im unable to see anything (bugmessages...) since the video driver gets deactivated by pm.
>
> My question is this: Is bisecting (turning off device support in kernel until it works) the best approach when bugtracking pm suspend? Or is there any other logging system that I can use?
Bisecting is not bad. Or you can port store-progress-into-rtc hacks
from pc...
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html