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:

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

Reply via email to