gsmd power management device

Andy Green andy at
Fri Jan 18 15:02:18 CET 2008

Hash: SHA1

Somebody in the thread at some point said:
> "Andy Green" <andy at> writes:
> [snip]
>> In addition, there are some sleep()s in the /etc/init.d/gsmd script that
>> are really a bit of an unreliable blunt instrument.  The sleeps add 5
>> whole seconds to the boot time.
> Yes, my testing (rather quite some time ago) showed that in all test
> cases the sleeps in that script were completely unnecessary.


> [Since there's been discussion on startup time recently, I should note
> that there's another 1 second delay built into the startup of the actual
> gsmd code itself that is not necessary, provided the powerup and
> initialization of the serial port on the GTA01 is done in the correct
> order, and a bit earlier in startup.  Every second counts...]

Yes usermode startup is of great interest now, I think we need to take
the same attitude we took with the mount delay -- that we don't accept
to leave it like it is any more and will take one kind of action or
another against it in the short term.  Mickey had some ideas on what to
do and not to do he said I am looking forward to.

Apparently we can expect bootchart to appear as an
available package shortly, this will give us some insight into what
exactly goes on during initscripts.

To discover that gsmd is the culprit for resume I moved out /etc/rcS.d
and /etc/rc5.d symlinks and ran them by hand, there's no shortage of
things to attack like a mandatory ldconfig every boot.  But the
bootchart will show us the worst offenders and by giving us a number on
each for the maximum time we could trim show us what we should look
hardest at.

Also the linear blocking initscript behaviour is the absolute worst
case, with X starting up at the end there.  We need to think about if we
can move X to the beginning and make the applets smarter so they block
on their dependent daemons / block devices / etc.

- -Andy
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list