| Summary: | qemuppc bootup failure with oe-core toolchain (with systemd) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Yocto Project Subprojects] Cross-prelink | Reporter: | Yang Shi <yang.shi> | ||||
| Component: | cross-prelink | Assignee: | Bruce Ashfield <bruce.ashfield> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | Medium+ | CC: | bruce.ashfield, ke.zou, leimaohui, mark.hatle, meta.mr.watcher, meta.watcher, randy.macleod, richard.purdie, ross.burton, yp.cp.watcher, yp.watcher | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 2.0.3 | ||||||
| Hardware: | x86 | ||||||
| OS: | ppc | ||||||
| Whiteboard: | |||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |||||
| Attachments: |
|
||||||
BTW, forgot to mention WR 4.9.2 toolchain works well. Other than signal 4 error, it may cause systemd segment fault (not occur with signal 4 error at the same time):
init[1]: unhandled signal 11 at 00000000 nip 00000000 lr 2076abc0 code 30001
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
CPU: 0 PID: 1 Comm: init Not tainted 3.14.29ltsi-WR7.0.0.0_standard #1
Call Trace:
[c786dd10] [c0009b88] show_stack+0xfc/0x1b4 (unreliable)
[c786dd60] [c069f07c] panic+0xe0/0x200
[c786ddb0] [c0032aa4] complete_and_exit+0x0/0x34
[c786de00] [c0032b48] do_group_exit+0x50/0xe0
[c786de10] [c0043c80] get_signal_to_deliver+0x2c4/0x6dc
[c786de70] [c000a698] do_signal+0x48/0x248
[c786df30] [c000a9bc] do_notify_resume+0x8c/0xa4
[c786df40] [c0012d4c] do_user_signal+0x74/0xc4
--- Exception: 400 at (null)
LR = 0x2076abc0
Investigation started. Re-tested with master commit: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=46720f0e7a119aa8792a9615ecbc237cb0bea769 which basically gives us gcc 4.9.3 and qemu 2.4.0-rc0. Issue is still reproducible. Created attachment 2595 [details]
qemuppc crash
Hi Bruce, Are you looking into this one? If so, do you have any insights? Thanks, Cristian I'm not looking into this one directly, outside of the fact that we know it isn't the kernel .. it is the toolchain or systemd. If you boot with init=/bin/bash, you'll get to the prompt and can debug. The point of having this Bugzilla raised was to get a non-kernel person to look at it :) (In reply to comment #6) > Hi Bruce, > > Are you looking into this one? > If so, do you have any insights? > > Thanks, > Cristian Does this still replicate with current master? This is a prelink bug that started when gcc was upreved. Mark is actively working on it now. I think it is a bug of binutils. If disable the "gold" option in binutils. This bug will disappear. We should retest this with master (MACHINE=qemuppc with systemd) (In reply to comment #11) > We should retest this with master (MACHINE=qemuppc with systemd) I do all of my kernel testing with systemd enabled, so I know that with a default configuration qemuppc does boot with systemd .. but someone else should confirm. re-tested with yocto master branch(2.1 rc2) since gcc4.9.2 is not an option in this release(correct me if I'm mistaken), we set parameters in local.conf: MACHINE ??= "qemuppc" DISTRO_FEATURES_append = " systemd" DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit" VIRTUAL-RUNTIME_init_manager = "systemd" VIRTUAL-RUNTIME_initscripts = "systemd-compat-units" GCCVERSION = "4.9.3%" the qemuppc can bootup correctly without kernel panic |
Build qemuppc with oe-core toolchain (gcc 4.9.2), it is failed to boot up with the following error: init[1]: unhandled signal 4 at 203137a0 nip 203137a0 lr 20170f0c code 30001 Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004 CPU: 0 PID: 1 Comm: init Not tainted 3.14.29ltsi-WR7.0.0.0_standard #1 Call Trace: [c786dd10] [c0009b88] show_stack+0xfc/0x1b4 (unreliable) [c786dd60] [c069f07c] panic+0xe0/0x200 [c786ddb0] [c0032aa4] complete_and_exit+0x0/0x34 [c786de00] [c0032b48] do_group_exit+0x50/0xe0 [c786de10] [c0043c80] get_signal_to_deliver+0x2c4/0x6dc [c786de70] [c000a698] do_signal+0x48/0x248 [c786df30] [c000a9bc] do_notify_resume+0x8c/0xa4 [c786df40] [c0012d4c] do_user_signal+0x74/0xc4 --- Exception: 700 at 0x203137a0 LR = 0x20170f0c Rebooting in 180 seconds..QEMU: Terminated Bruce mentioned he ran into the same issue with the toolchain (gcc 5.1) used by master branch too. And, it sounds like a glibc issue.