Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionPablo Iranzo Gómez
2015-11-25 09:30:53 UTC
Description of problem:
After updating system to 7.2 with kernel 3.10.0-327.el7 system crashes on boot.
Version-Release number of selected component (if applicable):
Kernel 3.10.0-327.el7
How reproducible:
Upgrade kernel to 3.10.0-327.el7, reboot system, crash appears
Actual results:
System crashes on boot
Expected results:
System boots properly
Additional info:
Booting with previous kernel makes the system boot again
Comment 1Pablo Iranzo Gómez
2015-11-25 09:31:42 UTC
Comment 2Pablo Iranzo Gómez
2015-11-25 10:19:49 UTC
I'm unable to get sysrq working either via console or via ipmitool sol access
A colleague has same problem.
From the OS I can trigger crash and it works.
Any hint?
Same happening in my AMD Turion(tm) II Neo N54L Dual-Core Processor, I have no ILO so no screenshots of the panic, but I want to mention that is happening so early in the boot process that kdump nor sysrq works. I'm attaching a sosreport just in case.
Created attachment 1098825[details]
Capture during 7.2 install from USB
I tried to install 7.2 via USB stick on my N54L and got the attached backtrace as soon as it booted, which is different from comment#1
Can you try booting with the kernel parameter
initcall_blacklist=clocksource_done_booting
?
P.
Comment 10Julio Entrena Perez
2015-12-02 13:57:09 UTC
(In reply to Prarit Bhargava from comment #8)
> Can you try booting with the kernel parameter
>
> initcall_blacklist=clocksource_done_booting
Yep, that option allows it to boot up successfully.
(In reply to Julio Entrena Perez from comment #10)
> (In reply to Prarit Bhargava from comment #8)
> > Can you try booting with the kernel parameter
> >
> > initcall_blacklist=clocksource_done_booting
>
> Yep, that option allows it to boot up successfully.
\o/ :)
Okay, a fix for this was put into the z-stream release for RHEL7.2. Unfortunately you'll have to install with this option and then immediately upgrade the kernel to the RHEL7.2.z release.
I'm closing this bug as a DUPLICATE of BZ 1265283.
P.
*** This bug has been marked as a duplicate of bug 1265283 ***
(In reply to Javier Ramirez from comment #4)
> Same happening in my AMD Turion(tm) II Neo N54L Dual-Core Processor, I have
> no ILO so no screenshots of the panic, but I want to mention that is
> happening so early in the boot process that kdump nor sysrq works. I'm
> attaching a sosreport just in case.
FWIW ... for some odd reason the AMD Turion processors seem to hit this more often than any other processor. I'm not sure why that is, but it has been resolved in BZ 1265283.
P.
Comment 13Julio Entrena Perez
2015-12-02 14:02:59 UTC
Just to add to the bug report that initcall_blacklist=clocksource_done_booting kernel parameter also solves the same issue on the following lenovo thinkpad :
Manufacturer: LENOVO
Product Name: 25453PG
Version: ThinkPad Edge
Processor model name: AMD Athlon(tm) II Neo K345 Dual-Core Processor
from the CentOS bugs entry: https://bugs.centos.org/view.php?id=9860#c25506
<quote>On my HP N40L, that workaround does let it boot, but I don't really trust this. For instance, I found that reading sysfs current_clocksource crashed the system, even as an unprivileged user!
$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
The crash is easy to understand -- clocksource_done_booting() is supposed to set pointer curr_clocksource, and sysfs_show_current_clocksources() dereferences it.
</quote>
(In reply to Tru Huynh from comment #16)
> from the CentOS bugs entry: https://bugs.centos.org/view.php?id=9860#c25506
>
> <quote>On my HP N40L, that workaround does let it boot, but I don't really
> trust this. For instance, I found that reading sysfs current_clocksource
> crashed the system, even as an unprivileged user!
>
> $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>
> The crash is easy to understand -- clocksource_done_booting() is supposed to
> set pointer curr_clocksource, and sysfs_show_current_clocksources()
> dereferences it.
> </quote>
The workaround is only meant to get you through the initial install. After the installation, upgrade to the latest functioning kernel, and then reboot. A permanent fix for this issue will be available at some point in z-stream. Please contact your support person for further details.
P.