Bug 618

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.