Hide Forgot
Created attachment 570858 [details] Section of git patchset causing kernel hang Description of problem: When choosing the the 3.3.0-rc7 kernels starting with git1 to now, the boot process hangs after grub has processed. Cannot access machine or dracut or anything. Have to forcibly reset system and choose an earlier kernel. Version-Release number of selected component (if applicable): Tested these: kernel-3.3.0-0.rc7.git1.2.fc17 kernel-3.3.0-0.rc7.git2.3.fc17 How reproducible: Always. Steps to Reproduce: 1. Turn on pc. 2. Choose kernel from grub 3. Kernel and Init echo lines process.. then nothing. Actual results: Plymouth splash or bootup text should appear, but system hangs immediately upon handoff from grub. Expected results: Graphics or text should kick in and kernel should boot. Additional info: I am booting through EFI. Do not have bios configured to test but I am uncertain that matters in this case. Did some comparisons and further testing by removing bits from the git patches and testing reboots with kernels and I narrowed the cause of my problem to one specific change, attached. After seeing this, I did a test by setting the kernel option "pcie_aspm=force" and I was then able to boot. This was not needed previously. Doing a grep of 'dmesg' output for aspm from hanging kernel and non-hanging, they are the same except for the 'force' acknowledgment. Snippet is attached. In case it matters: My mobo is an ASUS P8Z68-M PRO. Video is attached to a Nvidia GeForce 520 in the PCIe x16 slot. I did not test with the integrated graphics.
Created attachment 570859 [details] Output of dmesg | grep aspm
I'm having the same issue, however pcie_aspm=force doesn't not allow newer kernels to boot. I even tried a vanilla 3.3rc7, git pull as of today with no luck. My MB happens to also be a P8Z68-M PRO, Intel graphics. System is F17 with all updates as of today.
Created attachment 570961 [details] dmesg dump
Clarification: Newer Fedora kernels do not boot with pcie_aspm=force, however Linus GIT kernels with pcie_aspm=force do.
There's been an upstream report that commit 4949be16822e92a18ea0cc1616319926628092ee is causing similar boot issues: http://article.gmane.org/gmane.linux.kernel/1269495 Matthew?
Just to be thorough, I tested with the kernel-3.3.0-1.fc17 rpm from koji and can confirm the problem still exists, as Josh indicates in comment #5. I am still able to workaround using pcie_aspm=force.
I too am experiencing this issue with kernel 3.3.0 in Fedora 16 (and Xubuntu and Arch). Hardware is an Asus P8Z68-M Pro motherboard, 8gb Kingston 1600 ram, i5 2500 and a Crucial m4 SSD. If it's of any assistance, here is the output taken with my camera. http://img600.imageshack.us/img600/4395/p1000229w.jpg
I just realised two of you have the same Asus motherboard as me. That can't be a coincidence. Now I'm thinking I should've chosen an Intel board instead of Asus. ;)
There is definitely something off with the board, but it seems to work fine for the most part so far. If you want to be able to poll your sensors, you'll need to pass the "acpi-enforce-resources=lax" as well I've discovered, or you are limited to cpu temps. FWIW, I'm running with the latest 3702 firmware and it makes no difference. Maybe Fedora/RedHat can whitelist this mobo from the recent aspm change or hopefully include an errata/known issues bullet point somewhere.
I have the same board (Asus P8Z68-M Pro) and it worked with latest F16 kernel (3.3.0-4.fc16.x86_64) without problems until I upgraded the mobo bios (from 0402 to 3702). Now I get system panic as soon as kernel starts to boot. (And bios is not allowing me to downgrade!). I'm writing this messages while booted from the F17 Aplha USB Live image (3.3.0-0.rc3.git7.2.fc17.x86_64) though. All F16 kernels and F17 aplha kernel don't boot cleanly on this motherboard though. I have to change the mode of storage controler (from AHCI to IDE) and have to blacklist the pata_acpi driver. But that's another story.
I can confirm that pcie_aspm=force workaround works on latest F16 kernel (3.3.0-4.fc16.x86_64).
And even later F16 kernel (updated today: 3.3.0-8.fc16.x86_64) does not need this pcie_aspm=force workaround any more. It seems that this is fixed now.
I haven't tested, but it appears that the issue was fixed in kernel-3.3.0-8.fc16. * Wed Mar 28 2012 Josh Boyer <jwboyer> - Fix disabled ASPM regression Do we know if the patch will be included upstream in 3.3.1?