Re: [debian/fso] phonefsod: unpredictable pin dialog and questions abot config options
arne anka wrote: > within normal operation (runlevel) phonefsod does not work predicatble. > small changes in the phonefsod.conf made it stop entirely (w/o any useful > info in the log despite DEBUG) and small changes in eg fsodeviced seemed > to fix that ... > > what looks far more confusing to me is, that phonefsod always gets a lower > pid than fsodeviced, fsousage or frameworkd -- despite being started later > according to the number assigned in /etc/rc3.d: > S01dbus > ... > S02fso-deviced > S02fso-frameworkd > ... > S03phonefsod I don't know if it applies here, but unusual PIDs can happen as some daemons fork in order to run in the background, while others don't fork. Instead, they rely on "start-stop-daemon" or the startup script to put the process in the background. The FR is kind of slow, so apps that fork might take some time getting to the first fork. > since accessing (activating?) the gsm means, one of the otheres has to be > activae already. > Not necessarily that active. init runs the fso-deviced script, which launch the daemon and quits. Then init launch the fso-frameworkd script, and so on. Generally, one script quits before the next starts. But that doesn't mean the launched daemon is actually ready for a connection. It may still be running early initialization code, such as resolving dynamic linking or parsing the config file. The next daemon to start may get through its initialization much faster, and try to contact an earlier daemon before it is ready. Which is why it is so necessary to have good retry logic. For example: 1. try to access resource 2. if "not ready yet" then sleep 1s, then try (1) again. It may still be necessary to abort/give up on other kinds of errors, but "not ready" is best handled by sleeping a little so the others can catch up before the next retry. The sleeping is necessary to avoid busy waiting. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian/fso] phonefsod: unpredictable pin dialog and questions abot config options
> note, that nothing else is printed when shutting down by doing init 2 -- > looks, like phonefsod freezes somehow? it doesn't freeze -- it dies. most recent log of phonefsod (last lines): 2010.01.23 14:07:40.886422 [phonefsod] DEBUG: _request_resource_callback() 2010.01.23 14:07:42.854920 [phonefsod] DEBUG: call ogsmd_device_set_antenna_power() 2010.01.23 14:07:44.918310 [phonefsod] DEBUG: fso_sim_ready_status_handler() 2010.01.23 14:07:44.974339 [phonefsod] DEBUG: fso_sim_auth_status_handler(status=2) 2010.01.23 14:07:45.019485 [phonefsod] DEBUG: _dimit: reference = 100; percent = 100; b = 100 2010.01.23 14:07:47.504410 [phonefsod] DEBUG: _set_antenna_power_callback() 2010.01.23 14:07:47.504957 [phonefsod] DEBUG: getting SIM auth status... most recent log of phoneuid: 2010.01.23 14:07:40.883915 [libphone-ui]DEBUG: _resource_changed_handler: GSM is now enabled 2010.01.23 14:07:45.033648 [libphone-ui]DEBUG: _idle_notifier_handler: idle state now 0 2010.01.23 14:07:48.957456 [libphone-ui]DEBUG: _resource_changed_handler: GSM is now disabled note, that the last sign of life of phonefsod dates from 14:07:47.504957 -- a few seconds before, phoneuid reports GSM to be enabled ... and shortly after that date, GSM is reported to be disabled. checking with ps shows no sign of phonefsod whatsoever. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian/fso] phonefsod: unpredictable pin dialog and questions abot config options
> frameworkd and phonefsod are updated. So your next report would be > based on git head ;) ah, thanks! however, it does not change the problem, below the output of a normal startup (init 3). note, that nothing else is printed when shutting down by doing init 2 -- looks, like phonefsod freezes somehow? 2010.01.23 13:24:56.642900 [libframeworkd-glib] DEBUG: Trying to get the system bus 2010.01.23 13:24:56.653780 [libframeworkd-glib] DEBUG: Adding signals. 2010.01.23 13:24:56.667839 [libframeworkd-glib] DEBUG: registered to GSM.Network.Status 2010.01.23 13:24:56.703153 [libframeworkd-glib] DEBUG: registered to GSM.SIM.AuthStatus 2010.01.23 13:24:56.713064 [libframeworkd-glib] DEBUG: registered to GSM.SIM.ReadyStatus 2010.01.23 13:24:56.725956 [libframeworkd-glib] DEBUG: registered to GSM.Call.CallStatus 2010.01.23 13:24:56.743368 [libframeworkd-glib] DEBUG: registered to Device.IdleNotifier.State 2010.01.23 13:24:56.773191 [libframeworkd-glib] DEBUG: registered to Device.Input.Event 2010.01.23 13:24:56.783067 [libframeworkd-glib] DEBUG: registered to GSM.Network.IncomingUssd 2010.01.23 13:24:56.796001 [libframeworkd-glib] DEBUG: registered to Usage.ResourceAvailable 2010.01.23 13:24:56.803080 [libframeworkd-glib] DEBUG: registered to Usage.ResourceChanged 2010.01.23 13:24:56.815982 [libframeworkd-glib] DEBUG: registered to PIM.Messages.IncomingMessage 2010.01.23 13:24:56.832810 [phonefsod] DEBUG: connected to FSO 2010.01.23 13:24:56.834832 [phonefsod] DEBUG: entering glib main loop 2010.01.23 13:24:56.883832 [phonefsod] DEBUG: fso_list_resources() 2010.01.23 13:24:57.834365 [phonefsod] DEBUG: list_resources_callback() 2010.01.23 13:25:05.329396 [phonefsod] DEBUG: resource Accelerometer is now available 2010.01.23 13:25:05.371474 [phonefsod] DEBUG: _dimit: reference = 100; percent = 100; b = 100 2010.01.23 13:25:05.954160 [phonefsod] DEBUG: resource CPU is now available 2010.01.23 13:25:05.955658 [phonefsod] DEBUG: resource Display is now available 2010.01.23 13:25:05.957095 [phonefsod] DEBUG: resource Bluetooth is now available 2010.01.23 13:25:05.961129 [phonefsod] DEBUG: resource UsbHost is now available 2010.01.23 13:25:05.964828 [phonefsod] DEBUG: resource WiFi is now available 2010.01.23 13:25:05.969449 [phonefsod] DEBUG: resource Accelerometer is now disabled 2010.01.23 13:25:05.971607 [phonefsod] DEBUG:policy: 0 2010.01.23 13:25:05.974476 [phonefsod] DEBUG:refcount: 0 2010.01.23 13:25:05.996226 [phonefsod] DEBUG: resource CPU is now disabled 2010.01.23 13:25:05.998651 [phonefsod] DEBUG:policy: 0 2010.01.23 13:25:06.001016 [phonefsod] DEBUG:refcount: 0 2010.01.23 13:25:06.061422 [phonefsod] DEBUG: resource Display is now disabled 2010.01.23 13:25:06.061929 [phonefsod] DEBUG:policy: 0 2010.01.23 13:25:06.062264 [phonefsod] DEBUG:refcount: 0 2010.01.23 13:25:06.064934 [phonefsod] DEBUG: Display state state changed: disabled 2010.01.23 13:25:06.083795 [phonefsod] DEBUG: resource Bluetooth is now disabled 2010.01.23 13:25:06.085878 [phonefsod] DEBUG:policy: 0 2010.01.23 13:25:06.105005 [phonefsod] DEBUG:refcount: 0 2010.01.23 13:25:06.109706 [phonefsod] DEBUG: resource UsbHost is now disabled 2010.01.23 13:25:06.147875 [phonefsod] DEBUG:policy: 0 2010.01.23 13:25:06.149893 [phonefsod] DEBUG:refcount: 0 2010.01.23 13:25:06.456496 [phonefsod] DEBUG: resource WiFi is now disabled 2010.01.23 13:25:06.456996 [phonefsod] DEBUG:policy: 0 2010.01.23 13:25:06.457329 [phonefsod] DEBUG:refcount: 0 2010.01.23 13:25:27.065730 [phonefsod] DEBUG: not suspending due to charging or battery full 2010.01.23 13:25:30.918245 [phonefsod] DEBUG: _dimit: reference = 100; percent = 100; b = 100 2010.01.23 13:25:36.172698 [phonefsod] DEBUG: resource CPU is now enabled 2010.01.23 13:25:36.173294 [phonefsod] DEBUG:policy: 0 2010.01.23 13:25:36.173646 [phonefsod] DEBUG:refcount: 1 2010.01.23 13:25:36.258362 [phonefsod] DEBUG: resource GPS is now available 2010.01.23 13:25:36.328862 [phonefsod] DEBUG: resource TEST is now available 2010.01.23 13:25:36.392200 [phonefsod] DEBUG: resource GSM is now available 2010.01.23 13:25:36.392772 [phonefsod] DEBUG: handling offline mode (ONLINE) 2010.01.23 13:25:36.408114 [phonefsod] DEBUG: going online 2010.01.23 13:25:36.410149 [phonefsod] DEBUG: Request GSM resource 2010.01.23 13:25:37.289339 [phonefsod] DEBUG: resource GPS is now disabled 2010.01.23 13:25:37.289851 [phonefsod] DEBUG:policy: 0 2010.01.23 13:25:37.290380 [phonefsod] DEBUG:refcount: 0 2010.01.23 13:25:42.349525 [phonefsod] DEBUG: resource TEST is now disabled 2010.01.23 13:25:42.350046 [phonefsod] DEBUG:policy: 0 2010.01.23 13:25:42.350385 [phonefsod] DEBUG:refcount: 0 2010.01.23 13:25:42.393745 [phonefsod] DEBUG: resource GSM is now disabled 2010.01.23 13:25:42.394246 [phonefsod] DEBUG:policy: 0 2010.01.23 13:25:42.3945
Re: [debian/fso] phonefsod: unpredictable pin dialog and questions abot config options
Hi, frameworkd and phonefsod are updated. So your next report would be based on git head ;) -- Sebastian signature.asc Description: Digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian/fso] phonefsod: unpredictable pin dialog and questions abot config options
On Fri, Jan 22, 2010 at 10:55:38PM +0100, arne anka wrote: > > only changed in opimd and a small fix for ogpsd since then. > a link to the changelog? http://git.freesmartphone.org/?p=framework.git;a=shortlog -- Sebastian signature.asc Description: Digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian/fso] phonefsod: unpredictable pin dialog and questions abot config options
> only changed in opimd and a small fix for ogpsd since then. a link to the changelog? > This will most probably not fix your problem! that's quite possible, i added the remark only i case the issue was related to differences in frameworkd between the one debian uses and the shr one (since shr is the development platform for fso, iirc). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian/fso] phonefsod: unpredictable pin dialog and questions abot config options
On Fri, Jan 22, 2010 at 10:03:07PM +0100, arne anka wrote: > > hmm, strange thing. This is exactly what we intend to do... retry to > > access FSO until it appears on the scene... and then list the resources > > and register GSM if it is there... if not, wait for the signal that the > > GSM resource > > appeared. > > well, that's what i thought. > i've seen two different scenarios, when no pin dialog appears: > one was a message like "could not set environment" or something to that > effect. > the other one, that phonefsod apparently waits forever (although fsousaged > lists it as gsm user in its log and fso-abyss is started). > > please bear in mind, that debian's frameworkd is not quite up to date, if > i recall mickey's comments a while back correctly. fso-frameworkd in pkg-fso is currently a git checkout from 20090920. There will be a git head version in the next hour, but there were only changed in opimd and a small fix for ogpsd since then. This will most probably not fix your problem! I guess mickey meant the framework from Debian main repository, which is VERY old (~ one year). -- Sebastian signature.asc Description: Digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian/fso] phonefsod: unpredictable pin dialog and questions abot config options
> hmm, strange thing. This is exactly what we intend to do... retry to > access FSO until it appears on the scene... and then list the resources > and register GSM if it is there... if not, wait for the signal that the > GSM resource > appeared. well, that's what i thought. i've seen two different scenarios, when no pin dialog appears: one was a message like "could not set environment" or something to that effect. the other one, that phonefsod apparently waits forever (although fsousaged lists it as gsm user in its log and fso-abyss is started). please bear in mind, that debian's frameworkd is not quite up to date, if i recall mickey's comments a while back correctly. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian/fso] phonefsod: unpredictable pin dialog and questions abot config options
Am Freitag 22 Januar 2010 18:52:58 schrieb arne anka: > within normal operation (runlevel) phonefsod does not work predicatble. > small changes in the phonefsod.conf made it stop entirely (w/o any useful > info in the log despite DEBUG) and small changes in eg fsodeviced seemed > to fix that ... > > what looks far more confusing to me is, that phonefsod always gets a lower > pid than fsodeviced, fsousage or frameworkd -- despite being started later > according to the number assigned in /etc/rc3.d: > S01dbus > ... > S02fso-deviced > S02fso-frameworkd > ... > S03phonefsod > > since accessing (activating?) the gsm means, one of the otheres has to be > activae already. > > but after a few repeated tests, a reliable way to make phonefsod to pop > the pin dialog seems to be: > - stop everything (fso and maybe dbus), i do that by swithcing to runlevel > two which does not start anything > - manually start dbus, fso-deviced and fso-frameworkd > /etc/init.d/dbus start ; /etc/init.d/fso-frameworkd start > - let cook slowly > - after a few minutes tart everything else, i do that with > init 3 > which starts X and phonefsod > - pin dialog will pop up every time > > but that certainly is no way to go in case of an emergency reboot or > similar ... > to me it looks either like one of the timeout issues again -- in zhone, > neil worked around that by retrying until eventually the registration > would be possible. > or phonefsod starts far too fast and fails to access the not yet available > gsm, never recovering from that disappointment. hmm, strange thing. This is exactly what we intend to do... retry to access FSO until it appears on the scene... and then list the resources and register GSM if it is there... if not, wait for the signal that the GSM resource appeared. > > in the course of actions, i was wondering about the phonefsod.conf (yes, i > read the comments): > - "should ophonekitd try to activate GSM on startup" -- what does > ophonekitd has to do with phonefsod.conf? ouch - nothing :P don't remember if that part of the conf came from ophonekitd and I forgot to adjust the comment or if I was still used to the old name when writing that comment. Should read phonefsod. > - gsm_reregister_timeout = 60 -- what does "reregister" mean here? when is > the first registering attempted? reregister kicks in when you are without network coverage. Either on start or afterwards. It determines the seconds how often to schedule a try to register to the network. This is needed, because we don't get notified if some usable network (re-)appears. > - "when to show idle screen" -- disabling the associated option does not > disable the idle screen at all and there's no parameter to disable Disabling it lets the default kick in, which is aux,lock. Try if setting it to an empty string works. Should. > - auto_suspend = [never|normal|always] -- what part does "auto suspend" > refer to? the freerunner as such? a resource? what is the difference > between "normal" and "always"? suspend to mem the complete device. Not refering to a specific resource. It is using FSO for that (org.freesmartphone.Usage.Suspend). Normal does _not_ suspend the device while the battery is getting charged. Always does suspend it even then. -- Klaus 'mrmoku' Kurzmann ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[debian/fso] phonefsod: unpredictable pin dialog and questions abot config options
within normal operation (runlevel) phonefsod does not work predicatble. small changes in the phonefsod.conf made it stop entirely (w/o any useful info in the log despite DEBUG) and small changes in eg fsodeviced seemed to fix that ... what looks far more confusing to me is, that phonefsod always gets a lower pid than fsodeviced, fsousage or frameworkd -- despite being started later according to the number assigned in /etc/rc3.d: S01dbus ... S02fso-deviced S02fso-frameworkd ... S03phonefsod since accessing (activating?) the gsm means, one of the otheres has to be activae already. but after a few repeated tests, a reliable way to make phonefsod to pop the pin dialog seems to be: - stop everything (fso and maybe dbus), i do that by swithcing to runlevel two which does not start anything - manually start dbus, fso-deviced and fso-frameworkd /etc/init.d/dbus start ; /etc/init.d/fso-frameworkd start - let cook slowly - after a few minutes tart everything else, i do that with init 3 which starts X and phonefsod - pin dialog will pop up every time but that certainly is no way to go in case of an emergency reboot or similar ... to me it looks either like one of the timeout issues again -- in zhone, neil worked around that by retrying until eventually the registration would be possible. or phonefsod starts far too fast and fails to access the not yet available gsm, never recovering from that disappointment. in the course of actions, i was wondering about the phonefsod.conf (yes, i read the comments): - "should ophonekitd try to activate GSM on startup" -- what does ophonekitd has to do with phonefsod.conf? - gsm_reregister_timeout = 60 -- what does "reregister" mean here? when is the first registering attempted? - "when to show idle screen" -- disabling the associated option does not disable the idle screen at all and there's no parameter to disable - auto_suspend = [never|normal|always] -- what part does "auto suspend" refer to? the freerunner as such? a resource? what is the difference between "normal" and "always"? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community