openmoko at mazikeen.demon.co.uk
Fri Jul 18 00:13:14 CEST 2008
On Thursday 17 July 2008, Andy Green wrote:
> Somebody in the thread at some point said:
> | Subject to wakeups caused by cell reregistration this is true. This
> isn't a
> | complaint - keep reading ;-) It does a wake to full backlight too,
> which is
> | distracting and wastes power
> Backlight should be fixed for a couple of days now:
That's good to hear, thanks. Will this be in the latest daily build along with
the SD fix?
> |> Yes, suspend is unstable, it does not always wake, but nothing a reboot
> |> does not solve.
> Suspend per se is actually really quite stable (I sat here a few weeks
> ago doing 100 in a row with no trouble) except for one issue, something
> to do with certain GSM wakes getting in there first and deadlocking it
> somehow in resume time. Unfortunately not for want of trying I can't
> reproduce it here using my normal setup... which is why I know suspend
> is otherwise really pretty stable on current kernels. I'll be looking
> at it again very soon.
If you need this testing then point me at the images and let me know what you
need doing. My cell reregistrations seem to do a fair job of provoking resume
problems within a few hours on all the images I've tried so far.
> | That's currently the crux of the problem, and why I don't yet use
> suspend. It
> | resumes on cell registration messages, and each resume is another
> chance to
> | fail. It also has to resume to accept a call, and not being able to
> | resume makes it an unreliable phone.
> Yes, it's an issue. But it seems pretty certain this is "just
> software". Once we fix whatever the remaining issue is with
> GSM-provoked (and that much is known, if you turn off GSM before suspend
> you don't die in resume any more) resume deadlock and there is the wake
> daemon this should eventually be OK.
That was the impression I had got from looking at the list archives, but it's
nice to hear it confirmed.
More information about the community