Created attachment 1075316 [details] dmesg output captured to a USB device from the emergency shell (sdf) Description of problem: While trying to investigate a problem with the F22 kernel, I wanted to try to see if it also happened with the latest. So I installed the kernel and dracut packages from F23. That kernel fails to find my SATA disks. In the emergency shell, there are no device nodes for the SATA disks in /dev. In the dmesg output, there are messages about "qc timeout" followed by a message that it filed to identify the disk, getting an I/O error. Version-Release number of selected component (if applicable): kernel-headers-4.2.0-300.fc23.x86_64 kernel-devel-4.2.0-300.fc23.x86_64 kernel-core-4.2.0-300.fc23.x86_64 kernel-modules-4.2.0-300.fc23.x86_64 kernel-4.2.0-300.fc23.x86_64 kernel-tools-libs-4.2.0-300.fc23.x86_64 kernel-tools-4.2.0-300.fc23.x86_64 dracut-tools-043-60.git20150811.fc23.x86_64 dracut-043-60.git20150811.fc23.x86_64 How reproducible: Every boot. Steps to Reproduce: 1. Install the 4.2.0-300.fc23 kernel. 2. Boot it. Actual results: After some a timeout, I'm dropped into an emergency shell from the initrd. Looking around I can not see any traces of the hard disks in the machine. Expected results: Ordinary boot to multi-user mode using the installation on the hard disks. Additional info: As I said, I started investigating other issues with the F22 kernel, and much of the userspace is F22. From what I can understand, it can hardly cause this problem. Userspace isn't much involved this early in the boot, is it?
Created attachment 1075317 [details] dmesg output from a boot with the previous 4.1 kernel For comparison, I also provide dmesg messages from a boot using the previous kernel, which is 4.1.4-200.fc22.x86_64.
I now tried the 4.2.3-300.fc23 kernel, but it didn't do any better.
Inspired by the thread at https://lkml.org/lkml/2015/7/27/693 I tried to boot with "intremap=off" added. That DID help! Now it does find the disks. (To actually get my system up and running, I also had to add "rd.auto". It didn't start my RAIDs or LVs otherwise. I assume that is unrelated, and somehow caused by my mixed F22/F23 environment. I'll investigate that separately. But just in case I'm wrong, and in order to not hide anything that COULD be of importance, I thought I'd mention it.)
Created attachment 1091075 [details] rdsosreport under kernel 4.2.5 rdsosreport from failure to boot. Dracut initially finds the SATA disks, but subsequently suffers fromI_O page fault on device 00:11:00 (SATA Controller) and loses the disks. Adding intremap=off to boot parameters resolves issue.
Created attachment 1091076 [details] journalctl -xb output with Kernel 4.2.5 Export of journalctl -xb from failure to boot. Dracut initially finds the SATA disks, but subsequently suffers fromI_O page fault on device 00:11:00 (SATA Controller) and loses the disks. Adding intremap=off to boot parameters resolves issue.
The problem remains in kernel-4.5.4-300.fc24.x86_64.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 23 kernel bugs. Fedora 23 has now been rebased to 4.7.4-100.fc23. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 24 or 25, and are still experiencing this issue, please change the version to Fedora 24 or 25. If you experience different issues, please open a new bug report for those.
I tried with the F25 kernel, kernel-4.8.0-0.rc7.git0.1.fc25.x86_64, and I was able to boot successfully. (Without the intremap=off boot parameter.) The problem is at least fixed in F25. I can't easily check if the problem remains in F23, but I guess we close the bug anyway?