Bug 654

Summary: [qemuarm]kernel panic when booting qemuarm images of nightly build 20110114-1
Product: [Yocto Project Subprojects] Kernel Reporter: Yi Zhao <yi.zhao>
Component: kernel-toolingAssignee: Bruce Ashfield <bruce.ashfield>
Status: VERIFIED FIXED QA Contact:
Severity: critical    
Priority: High CC: edwin.zhai, jiajun.xu, ke.yu, kevin.tian, liang.li2, liangliang.wang, sgw, yi.zhao, yp.kernel.watcher, yp.watcher
Version: 1.0   
Target Milestone: 1.0 M3   
Hardware: x86   
OS: arm   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Program Management Documentation change: ---

Description Yi Zhao 2011-01-16 18:19:27 UTC 
Testing Env:    
Host: Ubuntu 10.10 x86_64
Kernel: 2.6.35-23-generic


When booting the qemuarm images(minimal & sato & sdk) from autobuilder,
http://autobuilder.pokylinux.org/nightly/20110114-1/qemu/qemuarm/, a kernel panic happened. 

The command used to start qemuarm:
###########
poky-qemu qemuarm zImage-2.6.37+git0+7102097a25c7658e0f4d4dc71844e0ff6c446b25_0+4f86b5a0cb23faa4134cc004730d673f6640614b-r15-qemuarm-20110115101905.bin poky-image-sato-qemuarm-20110115130348.rootfs.ext3 ext3
###########

kernel panic info:
###########
....

EXT3-fs (sda): warning: feature flags set on rev 0 fs, running e2fsck is recommended
EXT3-fs: barriers not enabled
EXT3-fs (sda): mounted filesystem with ordered data mode
VFS: Mounted root (ext3 filesystem) readonly on device 8:0.
Freeing init memory: 204K
kjournald starting.  Commit interval 5 seconds
Kernel panic - not syncing: Attempted to kill init!
Backtrace: 
[<c0045410>] (dump_backtrace+0x0/0x114) from [<c0405dd8>] (dump_stack+0x20/0x24)
 r6:c7858000 r5:c05311fc r4:c0550168
[<c0405db8>] (dump_stack+0x0/0x24) from [<c0405e4c>] (panic+0x70/0x1a0)
[<c0405ddc>] (panic+0x0/0x1a0) from [<c005e404>] (do_exit+0x73c/0x774)
 r3:c05311fc r2:c005e2c4 r1:c7858000 r0:c04b4340
 r7:c7850000
[<c005dcc8>] (do_exit+0x0/0x774) from [<c005e744>] (do_group_exit+0x50/0xec)
 r7:00078000
[<c005e6f4>] (do_group_exit+0x0/0xec) from [<c006e518>] (get_signal_to_deliver+0x204/0x4b4)
 r6:c785a000 r5:c7858000 r4:0830009f
[<c006e314>] (get_signal_to_deliver+0x0/0x4b4) from [<c0044118>] (do_signal+0x60/0x620)
[<c00440b8>] (do_signal+0x0/0x620) from [<c0044d84>] (do_notify_resume+0x70/0x7c)
[<c0044d14>] (do_notify_resume+0x0/0x7c) from [<c0041774>] (work_pending+0x24/0x28)
 r4:4d34d000

###############
Comment 1 Bruce Ashfield 2011-01-16 18:38:41 UTC 
We've made no changes to the kernel for ARM, so I'm betting that this
isn't a kernel issue, but instead is related to changes to qemu or userspace.

When's the last time this booted. If you change the most recent kernel for
an older one, do things boot ? What about the new kernel and an older qemu/userspace ?
Comment 2 Saul Wold 2011-01-16 23:21:39 UTC 
I tried both the pre and post systemtap kernel update and both fail, so it maybe qemu or userspace
Comment 3 Yi Zhao 2011-01-17 00:43:18 UTC 
I tested the recent build images from the autobuilder.

The build images from both 20110111-1 and 20110112-1 can not boot with this issue. 
With the build images from 20110110-1, it can boot. 

After changing the kernel, the 20110110-1 kernel can boot with the 20110114-1 filesystem image. 
However, the 20110114-1 kernel can not boot with the 20110110-1 filesystem image.

I also try to change qemu from toolchain 20110110-1. After that, it has same problem.
Comment 4 Bruce Ashfield 2011-01-19 18:56:12 UTC 
This is out for review, when the SRCREVs merge to master .. this problem goes away.
Comment 5 Bruce Ashfield 2011-02-15 06:12:35 UTC 
Confirmed to boot, we had lost EABI configuration values hence
userspace was having issues.
Comment 6 Yi Zhao 2011-02-17 18:34:37 UTC 
Verified with build 20110212-1, the bug is fixed.