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 ###############
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 ?
I tried both the pre and post systemtap kernel update and both fail, so it maybe qemu or userspace
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.
This is out for review, when the SRCREVs merge to master .. this problem goes away.
Confirmed to boot, we had lost EABI configuration values hence userspace was having issues.
Verified with build 20110212-1, the bug is fixed.