On Mon, May 3, 2010 at 1:02 PM, Chris Packham <[email protected]> wrote: > On Mon, May 3, 2010 at 12:48 PM, Kees Jongenburger > <[email protected]> wrote: >> Hello Chris, >> >> On Mon, May 3, 2010 at 6:57 PM, Chris Packham <[email protected]> >> wrote: >>> Hi, >>> >>> We've been using upstart in our embedded products for some time now >>> (we're using upstart 0.5.1). I'm in the process of porting our >>> software to a new hardware platform and I'm running into a problem >>> thats got me stumped. >>> >>> Our first init script mounts the file systems and then uses "initctl >>> reload" to reload the upstart config from the on-flash upstart config. >>> The problem is that "initctl reload" just hangs waiting forever. As >>> far as I've been able to debug so far it seems to be in the dbus >>> message dispatch which should have sent the message to init. I think >>> its waiting for a response it never sees, I also think init never got >>> the message. >> >> Are you using a initramfs? who mounts the required file system for >> upstart to work? > > It is an initramfs (squashfs) mounted by the kernel/bootloader. > >> try replacing upstart by a shell script and once you have a shell >> exec /sbin/init with extra debugging. > > I'm already running with #define DEBUG in init/main.c and init=/bin/sh > so I can start init after getting a shell. I might just add -DDEBUG to > configure and see what else I get.
The same problem seems to affect the debug event that gets sent when we build with -DDEBUG. After that event gets sent nothing happens, I think its the same problem just happening earlier. >> Double check your kernel configuration to have networking and sockets >> enabled. >> > > grep -e 'CONFIG_\(NET\|INET\|UNIX\)=' .config > CONFIG_NET=y > CONFIG_UNIX=y > CONFIG_INET=y > >>> I've run the same code on one of our existing platforms and that >>> starts up normally so I'm thinking its a toolchain/kenrel setup issue >>> but the only differences I can see in that area are the things that >>> _are_ different. >> >> Your hardware might also be different causing a different events to happen >> in a different order (for example a tmpfs to be mounted over the place >> where upstart has it's unix socket waiting). >> > > Hmm hadn't thought of that. One of the first things the script does is > mount tmpfs, procfs and sysfs. I might take that out and do it > manually as an experiment. > Mounting manually first (and disabling re-mounting) doesn't seem to have any effect on this problem. One hardware difference I haven't worked through yet is that there is no driver for the real time clock on the board I have (or at least I haven't found and configured the right one). I've been putting off that work as an easy task I can do later. Are there any system calls used that require a working rtc? I didn't think there were any such calls. -- upstart-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/upstart-devel
