Created attachment 716965 [details] Photo of the display after I get the backtrace Description of problem: A recent rc4 kernel in Rawhide initially boots but prints some kind of a backtrace and seems to get stuck before the system is fully booted. Version-Release number of selected component (if applicable): kernel-3.9.0-0.rc4.git0.1.fc20.x86_64 How reproducible: On every boot, on the this hardware I have. Steps to Reproduce: 1. Install kernel-3.9.0-0.rc4.git0.1.fc20.x86_64 2. Boot that kernel. Actual results: System boots for a while but before having booted completely, it prints a backtrace and seems to get stuck. After this, the system does not seem to respond to any keyboard input. Also nothing seems to end up into the systemd journal or some other place where I could get the kernel log of that boot. Expected results: Works at least as well as an earlier rawhide kernel, like the kernel-3.9.0-0.rc3.git1.3.fc20.x86_64 from fedora-rawhide-kernel-nodebug that has worked just fine on my system. Additional info: Attached to the report is a photo of the display that has the backtrace visible.
Are you still seeing this with 3.9 final, or the 3.10-rc1 kernels? Does it only happen if you have a USB serial adaptor plugged in?
It did look like this was somehow related to whether or not an USB-serial adapter I have was connected, but can not say for sure. I did run into some btrfs corruption in the system where this happened, which kind of encouraged me to keep the adapter disconnected. With kernel-3.10.0-0.rc1.git6.2.fc20.x86_64 from the fedora-rawhide-kernel-nodebug repository, this problem does not seem to occur anymore, regardless of me having connected the adapter again.
The nodebug builds don't have the checks enabled to see this trace.
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle. Changing version to '20'. More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
Are you still seeing this with the rawhide kernels, or with kernel-debug installed?
The host where I encountered this bug currently runs the F20 branch of Fedora. I did not see this bug happen in the last months that the computer ran Rawhide, but I did keep running the nodebuginfo kernels. When I originally encountered the bug, booting failed also with new nodebug kernels. Since this did not happen for a long time after that, I'd guess the bug has been fixed (or hidden) at some point. If you still think it would be useful if I installed the kernel from Rawhide with the debug options turned on and tried to reproduce the backtrace, I guess I could do that.
(In reply to Joonas Sarajärvi from comment #6) > If you still think it would be useful if I installed the kernel from Rawhide > with the debug options turned on and tried to reproduce the backtrace, I > guess I could do that. Let's close this out for now if you haven't seen it since. If you do happen to install a rawhide or debug kernel at some point and hit this, please reopen.