[maemo-developers] [maemo-developers] Maemo 2.0 device reboot
From: Malix malix0 at gmail.comDate: Thu Oct 19 16:40:38 EEST 2006
- Previous message: [maemo-developers] Maemo 2.0 device reboot
- Next message: [maemo-developers] Maemo 2.0 device reboot
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
2006/10/19, Eero Tamminen <eero.tamminen at movial.fi>: > > Hi, > > ext Marius Gedminas wrote: > >>>> Hi, after upgrade to maemo 2.0 I have a problem. Some times my 770 > >>>> reboot. This happen some times when I'm using the browser and every > >>>> time I try to use Gizmo. For now I never had problem with other > >>>> programs. You think this is a software problem or hardware? > >>> My 770 reboots once every two--three days. I think it's a software > >>> problem. I could be wrong. > >> As mentioned in the following link, please file bugs against the errant > >> applications. > >> http://maemo.org/maemowiki/ReportingRebootIssues?action=show > >> > >> I remember in your case it was FBReader - report it to them. > > > > /var/lib/dsme/lifeguard-resets claims it is maemo_af_desktop's fault. > > Were there several reboots accounted for the Desktop process? > > Btw. there are several reasons why Desktop might die: > - It's buggy :-) > - Something in the device is forcing it to run completely out of memory > (and if alloc fails, Glib will abort the co. process), e.g. because > that something is leaking memory or otherwise using a lot of memory > without integrating itself to the device memory management: > - If possible, app should implement support for the "background killing" > i.e. save UI state when backgrounded and then indicate[1] that it's > killable when the device runs out of memory: > > https://stage.maemo.org/svn/maemo/projects/haf/doc/api/hildon-libs/hildon-libs-HildonProgram.html#hildon-program-set-can-hibernate > > http://www.maemo.org/platform/docs/api/libosso/html/group__Statesave.html > > http://www.maemo.org/platform/docs/api/libosso/html/group__Autosave.html > When foregrounded, I think app should then remove the state and > when being re-started, it should check whether there was some > UI-state. If there was, restore the UI-state (instead of going > to the default application state). If you strace the device apps, > you see that UI state is stored under /tmp/osso-appl-states/ which > is on tmpfs i.e. goes away at reboot > - It could use the libosso osso_mem_saw_enable & osso_mem_saw_disable > http://maemo.org/lxr/source/libosso/src/osso-mem.h#110 > functions around operations that: > - could potentially take a lot of memory (loading large image etc) > - handle allocation failures gracefully (not abort/assert) > - If app caches things or otherwise has some "optional" memory > usage, it could also listen to the system low memory notifications > so that it can purge from RAM all of its caches when that happens: > > http://www.maemo.org/platform/docs/api/libosso/html/group__Devstate.html > > http://www.maemo.org/platform/docs/api/libosso/html/group__outside.html#g231284109a21410088850beed324ea57 > > If the device runs _completely_ out of memory, I don't think the kernel > out-of-memory killer knows which process user would prefer to be killed > to get more memory :-). > > Some more info on kernel OOM-killer: > http://linux-mm.org/OOM_Killer > http://lwn.net/Articles/104179/ > > [1] You can check whether app is "background-killable" by: > - using "xwininfo|grep Window id" and tapping to the application window, > - topping another window, and then > - doing "xprop -id <id> | grep KILL" > If you see the hibernate property set for the app, > it is "background killable". > > > > FBReader just happens to be the application I use most often. > > > > I haven't reported it in Bugzilla yet, because I do not have a way to > > reproduce the problem (other than "try to use the device for a few > > days"), and also because it is not that irritating -- the device boots > > pretty fast, and the progress bar is kinda nice. :) > > > - Eero > _______________________________________________ > maemo-developers mailing list > maemo-developers at maemo.org > https://maemo.org/mailman/listinfo/maemo-developers Thanks to everyone for suggestions. I will report any information I can collect , following those instructions http://maemo.org/maemowiki/ReportingRebootIssues?action=show, in the hope that those can help to fix bugs. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maemo.org/pipermail/maemo-developers/attachments/20061019/2b663281/attachment.htm
- Previous message: [maemo-developers] Maemo 2.0 device reboot
- Next message: [maemo-developers] Maemo 2.0 device reboot
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]