|Summary:||kernel panic not syncing attempted to kill init|
|Product:||[Fedora] Fedora||Reporter:||Don Swaner <dswaner>|
|Component:||kernel||Assignee:||Kernel Maintainer List <kernel-maint>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||22||CC:||gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, mchehab|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-11-12 16:21:57 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Don Swaner 2015-11-05 12:27:54 UTC
Description of problem: New kernel (vmlinuz-4.2.5-201.fc22.x86_64) fails to boot - terminates with error message "Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 Version-Release number of selected component (if applicable): kernel-core-4.2.5-201.fc22.x86_64 How reproducible: Always Steps to Reproduce: 1. Boot system 2. 3. Actual results: boot hangs with error message Expected results: successful boot Additional info:
Comment 1 Don Swaner 2015-11-06 00:46:48 UTC
removing this kernel and reinstalling had no effect - same error.
Comment 2 Josh Boyer 2015-11-06 14:08:16 UTC
Please attach the output of dmesg from a successfully booting kernel, as well as a digitial picture of as much of the backtrace as you can see on the failed boot.
Comment 3 Don Swaner 2015-11-06 15:03 UTC
Created attachment 1090694 [details] dmesg output from good boot
Comment 4 Don Swaner 2015-11-06 15:06 UTC
Created attachment 1090695 [details] failed boot backtrace This attachment was manually created, so it may contain typographical errors.
Comment 5 Don Swaner 2015-11-06 15:11:28 UTC
I do not have a camera or cell phone to take a digital picture of the screen, which I believe is what was requested.
Comment 6 Josh Boyer 2015-11-06 15:18:40 UTC
(In reply to Don Swaner from comment #4) > Created attachment 1090695 [details] > failed boot backtrace > > This attachment was manually created, so it may contain typographical errors. Thanks, that was helpful. Looking at the versions you have, it seems like a patch added in 4.2.4 is causing your issue. Upstream is already aware of it, and the fix is queued for 4.2.6. Specifically it is: commit ababae44108b0e94b58eef6cb5bd830bd040a47f Author: Werner Pawlitschko <email@example.com> Date: Tue Oct 27 09:08:04 2015 +0900 x86/ioapic: Prevent NULL pointer dereference in setup_ioapic_dest() Commit 4857c91f0d19 changed the way how irq affinity is setup in setup_ioapic_dest() from using the core helper function to unconditionally calling the irq_set_affinity() callback of the underlying irq chip. That results in a NULL pointer dereference for the rare case where the underlying irq chip is lapic_chip which has no irq_set_affinity() callback. lapic_chip is occasionally used for the timer interrupt (irq 0). The fix is simple: Check the availability of the callback instead of calling it unconditionally. Fixes: 4857c91f0d19 "x86/ioapic: Force affinity setting in setup_ioapic_dest()" Signed-off-by: Thomas Gleixner <firstname.lastname@example.org> Cc: email@example.com
Comment 7 Josh Boyer 2015-11-10 16:46:17 UTC
4.2.6 is building right now.
Comment 8 Don Swaner 2015-11-12 16:17:23 UTC
kernel 4.2.6-200.fc22.x86_64 fixes bug
Comment 9 Josh Boyer 2015-11-12 16:21:57 UTC
Thank you for testing.