Red Hat Bugzilla – Bug 1275201
Neither 4.2.3-200 or 4.2.5-201 kernel will not boot on Lenovo w530 Thinkpad
Last modified: 2016-07-19 15:21:06 EDT
Created attachment 1086425 [details]
tar file holding lscpi, dmidecode, cpuinfo output and grub.cfg
Description of problem:
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install 4.2.3-200 kernel
Machine hangs after printing "[ 1.1728022] pci 0000:00:01.0: ASPM: Could not configure common clock"
Keyboard input is echoed to the screen but has no effect
Machine boots normally
I'm running the nouveau video drivers
Description of problem:
Machine will not boot 4.2.3-200.fc22.x86_64 kernel, boots fine with 4.1.10-200.fc22.x86_64
I'm getting similar reports from colleges using a Lenovo T440p and a W520. I'll ask them to upload similar hardware info
info2.tgz has the hardware info for the w520 seeing the issue
Created attachment 1087628 [details]
Hardware info for W520 seeing the same problem
Still seeing the same problem with the new kernel-4.2.5-201.fc22.x86_64
Created attachment 1092144 [details]
Photo of stacktrace
I've managed to grab a photo of the stacktrace I managed to induce by pressing ctl-alt-delete while the machine was hung.
I've been trying to grab some more info and was looking at kdump but I think this may be happening too early on in the boot to have the storage or network subsystems up.
I'm having the same issue running Lenovo W520. Kernels above 4.1.8-200 (FC22) won't boot. It seems to hang somewhere before disk is initialized as LUKS passphare dialog is not shown.
Created attachment 1095310 [details]
Screenshot - Timed out & Dependency failed messages
After a long wait I managed capture something:
Timed out waiting for device dev-disk-by...
Dependency failed for Cryptography Setup for luks...
Dependency failed for Encrypted volumes.
Same applies to the latest 4.2.6-200 kernel :(.
No changes on kernel-4.2.6-201.fc22.x86_64
Created attachment 1101470 [details]
ata1.00: qc timeout (cmd 0xec)
With kernel-4.2.6-201.fc22.x86_64. No disks detected.
Workaround: Append nointremap to kernel parameters.
Found discussion about this issue on linux kerner list (VGER.KERNEL.ORG): http://filibusta.crema.unimi.it/~cavok/kbts/kr784.html
Created attachment 1101675 [details]
dmesg and /proc/interrupts from both kernels
dmesg and /proc/interrupts from kernels 4.1.8-200 (working) and 4.2.6-201 (with nointremap)
Could this be related to IRQ mapping as nointremap fixed?
Problem persist on kernel-4.2.7-200. However with 'nointremap' able to boot.
Confirmed with 4.2.8-200.fc22.x86_64 - not working.
This commit may help to resolve the regression, could you please help to have a try?
Author: Thomas Gleixner <email@example.com>
Date: Mon May 4 10:47:40 2015 +0800
irq_remapping/vt-d: Init all MSI entries not just the first one
Commit b106ee63abcc ("irq_remapping/vt-d: Enhance Intel IR driver to
support hierarchical irqdomains") caused a regression, which forgot
to initialize remapping data structures other than the first entry
when setting up remapping entries for multiple MSIs.
[ Jiang: Commit message ]
Fixes: b106ee63abcc ("irq_remapping/vt-d: Enhance Intel IR driver to support
Signed-off-by: Thomas Gleixner <firstname.lastname@example.org>
Signed-off-by: Jiang Liu <email@example.com>
Cc: Konrad Rzeszutek Wilk <firstname.lastname@example.org>
Cc: David Cohen <email@example.com>
Cc: Sander Eikelenboom <firstname.lastname@example.org>
Cc: David Vrabel <email@example.com>
Cc: Tony Luck <firstname.lastname@example.org>
Cc: Greg Kroah-Hartman <email@example.com>
(In reply to jiang.liu from comment #17)
> This commit may help to resolve the regression, could you please help to
> have a try?
> commit 9d4c0313f24a05e5252e7106636bf3c5b6318f5d
> Author: Thomas Gleixner <firstname.lastname@example.org>
> Date: Mon May 4 10:47:40 2015 +0800
> irq_remapping/vt-d: Init all MSI entries not just the first one
This commit is already in the 4.2 kernel releases, isn't it?
[jwboyer@vader linux]$ git describe --contains 9d4c0313f24a05e5252e7106636bf3c5b6318f5d
I'm not sure how it would help given people are reporting issues against 4.2.y kernels and it should already be present.
Upgraded to 4.3.4-200.fc22.x86_64 today. No changes.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.