Testing Env: Host: Ubuntu 10.04 LTS Kernel: 2.6.32-21-generic-pae qemuppc images from weekly build 20101218, http://autobuilder.pokylinux.org/milestone/20101218-1/qemu/qemuppc/ Pls. check comments in bug 143 also. qemuppc first time booting needs more than 4 minutes on my machine. The issue exists before also.
This also happend on nightly build 20101225-1: kernel:http://autobuilder.pokylinux.org/nightly/20101225-1/qemu/qemuppc/zImage-2.6.37+git0+5955ebea1f0d2fbd67a66ed138ce2b3363adf72a_0+c01bc9165ab3192368dc2030a98fb75a7f8dc008-r14-qemuppc-20101226053323.bin rootfs: http://autobuilder.pokylinux.org/nightly/20101225-1/qemu/qemuppc/poky-image-sato-qemuppc-20101226053323.rootfs.ext3 Testing Env: Host: Ubuntu 10.10 Kernel: 2.6.35-22-generic
This is also happened on beagleboard Image from nightly build 20101225 http://autobuilder.pokylinux.org/nightly/20101225-1/qemu/qemubeagleboard/ When first time booting, it will wait for a long time after printing following message and give me a login prompt. ###################### TCP cubic registered NET: Registered protocol family 17 Power Management for TI OMAP3. VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 1 regulator_init_complete: incomplete constraints, leaving VDVI on regulator_init_complete: incomplete constraints, leaving VDAC on twl_rtc twl_rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800) Waiting for root device /dev/mmcblk0p2... mmc0: new high speed SD card at address 1234 mmcblk0: mmc0:1234 SA02G 1.83 GiB mmcblk0: p1 p2 kjournald starting. Commit interval 5 seconds EXT3-fs (mmcblk0p2): using internal journal EXT3-fs (mmcblk0p2): recovery complete EXT3-fs (mmcblk0p2): mounted filesystem with writeback data mode VFS: Mounted root (ext3 filesystem) on device 179:2. Freeing init memory: 172K ######################
I have test some targets and The test result shows below: a. On qemuppc, the first time: real 6m3.032s The second time: real 1m30.924s b. On qemuarm, the first time: real 2m17.204s The second time: real 0m52.896s c. On omap3530 platform, the first time: 1m30s The second time: 0m20s I think it's not a real problem. 1. Booting sdk rootfs on any target needs more time on the first time. Because the graphics enviroment will initialize some components before the first using. 2. qemuppc is a qemu target, and its simulation speed is a bit lower than qemuarm. 3. qemuppc has no framebuffer, so when it starts Xserver, it will wait matchbox to timeout, which will waste more than 40s. The Xserver startup log is following: Starting Xserver fbset: can't open '/dev/fb0': No such file or directory fbset: can't open '/dev/fb0': No such file or directory fbset: can't open '/dev/fb0': No such file or directory _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/qemuppc:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 Error opening framebuffer /dev/fb0: No such file or directory Fatal server error: no screens found giving up. xinit: Connection refused (errno 111): unable to connect to X server xinit: No such process (errno 3): Server error. Timeout waiting for org.matchbox_project.desktop.Loaded I think we can do nothing for this bug.
Liming: thanks for the update, this matches what I've seen as well. What are your timings for a minimal image boot ? Mine are taking less than a minute for all emulated targets. We can also strip down the qemuppc run to not have graphics, since adding a framebuffer driver to qemuppc still eludes us. Comments ? I concur with Liming that there is very little we can do here.
For minimal image, I just tested qemuppc and qemuarm, all only waste less than 30s.
Changing the state of this to accepted, but reducing the importance of this one. Since as the discussion states, it is fine with a minimal image, and the slow startup is due to missing graphics h/w for qemuppc.
This won't be fixed for M4 (see the last comment), it is somehow related to the X component of anything but the minimal image. That is out of the kernel/BSP hands, so there's nothing we can do here.
bumping to 1.1 when we'll have a chance to address qemuppc graphics.
Is this any better with the 3.0 kernel and associated fixes?
much to my displeasure, this is still an issue, the interrupt storm or accessed caused by any graphical startup on the non existent framebuffer slows initial boot down to a crawl. This looks like it will have to be addressed with the qemuppc replacement.
I re-tested some sato images with 20110806 build. commit info: abdec68876ac7ce1a6d5c223d1757b7e8a14b85f kernel version: 2.6.37 The results are as below: 1. On qemuppc The first time: 3m37s The second time: 1m30s 2. On qemuarm The first time: 1m6s The second time: 25s 3. On qemumips The first time: 1m The second time: 27s Although the booting time of qemuppc is less than 4 minutes now, it is still much slower than qemuarm and qemumips.
Is the timeout in the X startup scripts still an issue? Could we assist things by checking if /dev/fb0 exists somewhere and exiting early if not?
(In reply to comment #12) > Is the timeout in the X startup scripts still an issue? Could we assist things > by checking if /dev/fb0 exists somewhere and exiting early if not? Yes, the timeout is still an issue. ############# Starting Xserver fbset: can't open '/dev/fb0': No such file or directory fbset: can't open '/dev/fb0': No such file or directory fbset: can't open '/dev/fb0': No such file or directory Error opening framebuffer /dev/fb0: No such file or directory Fatal server error: no screens found xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error Timeout waiting for org.matchbox_project.desktop.Loaded ############### I tried to remove the X startup scripts 'S09xserver-nodm' from /etc/rc5.d, then the booting time of qemuppc is 20s ! (not the first time)
following patch changes qemuppc to run into 3 runlevel and doesn't use tty0 as console. It speeds up the boot time to 20s for the second time. diff --git a/scripts/runqemu-internal b/scripts/runqemu-internal index c15632d..883fa5b 100755 --- a/scripts/runqemu-internal +++ b/scripts/runqemu-internal @@ -384,7 +384,7 @@ if [ "$MACHINE" = "qemuppc" ]; then BIOS=powerpc_rom.bin QEMU_UI_OPTIONS="$QEMU_UI_OPTIONS -nographic" if [ "$FSTYPE" = "ext3" -o "$FSTYPE" = "btrfs" ]; then - KERNCMDLINE="root=/dev/hda rw console=ttyS0 console=tty0 $KERNEL_NETWORK_CMD mem=$QEMU_MEMORY" + KERNCMDLINE="root=/dev/hda rw console=ttyS0 3 $KERNEL_NETWORK_CMD mem=$QEMU_MEMORY" QEMUOPTIONS="$QEMU_NETWORK_CMD -cpu $CPU_SUBTYPE -M $MACHINE_SUBTYPE -bios $BIOS -hda $ROOTFS -no-reboot $QEM fi if [ "$FSTYPE" = "nfs" ]; then @@ -393,7 +393,7 @@ if [ "$MACHINE" = "qemuppc" ]; then cleanup return fi - KERNCMDLINE="root=/dev/nfs console=ttyS0 console=tty0 nfsroot=$NFS_SERVER:$NFS_DIR,$UNFS_OPTS rw $KERNEL_NETW + KERNCMDLINE="root=/dev/nfs console=ttyS0 3 nfsroot=$NFS_SERVER:$NFS_DIR,$UNFS_OPTS rw $KERNEL_NETWORK_CMD mem QEMUOPTIONS="$QEMU_NETWORK_CMD -cpu $CPU_SUBTYPE -M $MACHINE_SUBTYPE -bios $BIOS -no-reboot $QEMU_UI_OPTIONS" fi fi
Liming, is this bug fixed with the patches you mentioned? Are the patches in review? Thanks!
The patch has been passed review. I think this patch will merged into poky later. But I should ask Bruce how to merge the patch.
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=84ef84dbb8627fa5292cf10d1c9146c1236802d0
tried on qemuppc sato image: first boot time: 2m and 21 seconds. second boot time: 23 seconds and runlevel now is 3: root@qemuppc:~# runlevel N 3 git commit : 705ec50edda7f7fb8c132238fe3f1477384a470e git branch : poky/master test env : host : ubuntu 10.10 x86_64 kernel :2.6.35-30-generic #56-Ubuntu SMP test steps : 1.create toolchain using "bitbake meta-toolchain" command,get toolchain tarball from "tmp/deploy/sdk" subdir of build dir ,extract to /opt dir of the host machine. 2.run "runqemu" command to boot the sato image. next weekly test will check again and change the bug status to verified.
(In reply to comment #18) > tried on qemuppc sato image: > first boot time: 2m and 21 seconds. > second boot time: 23 seconds > > and runlevel now is 3: > root@qemuppc:~# runlevel > N 3 > > git commit : 705ec50edda7f7fb8c132238fe3f1477384a470e > git branch : poky/master > > test env : > host : ubuntu 10.10 x86_64 > kernel :2.6.35-30-generic #56-Ubuntu SMP > > test steps : > 1.create toolchain using "bitbake meta-toolchain" command,get toolchain tarball > from "tmp/deploy/sdk" subdir of build dir ,extract to /opt dir of the host > machine. > 2.run "runqemu" command to boot the sato image. > > next weekly test will check again and change the bug status to verified. verified using M4 RC1 images(nightly build 20110908-5) from: http://autobuilder.pokylinux.org/nightly/20110908-5/machines/qemuppc/ first boot time : 1 minutes and 45 seconds. second boot time :22 seconds.