Created attachment 1098640 [details]
Image of iLO capture

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 1098745 [details]
sosreport

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.

(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.

Thanks prarit++

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

*** Bug 1295056 has been marked as a duplicate of this bug. ***

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.