I’ve HP EliteBook 840 14 inch G11 Notebook with 32GB of RAM and Intel Core Ultra 7 155H CPU. The GPU is embedded in this CPU. The BIOS is latest: BIOS W70 Ver. 01.07.02 09/24/2025. I use Fedora 42 with Cinnamon DE and with all latest updates. This is the only OS on this machine.
Sporadically this system hangs forever. Today, with recently installed kernel 6.17.4 (previously used 6.16.x) this happened again but this time, after a few more seconds, two screens became black with a message at the center of the compound two screens (internal and external) telling that there is a kernel panic and I have to reboot. Looks like an improved panic message of the same panic I had with 6.16.x too.
Is it a known issue? Is there any known workaround?
On the following URL you can find the output of the sudo journalctl -b -1 -k command that I ran right after the next boot after the panic:
The main cause of this crash seems to be i915 (your onboard graphics chip).
You say it’s sporadic, but can you replicate it with this kernel reliably - it’s triggered by suspend/resume and is likely to be some interaction with the kernel and firmware, so forcing a suspend/resume would be a good way to test its repeatability.
Replicate it.
Update the firmware with fwupdmgr refresh --force && fwupdmgr update
Replicate it again.
Add the kernel parameter i915.enable_guc=0 to this kernel, boot it and replicate the issue again. This will force the i915 chip to not use its driver and encourage the CPU to schedule tasks on it. Obviously we’d prefer to not have to do this permanently, so it’s a one-time attempt to see if you can still replicate the issue.
Post back the results of that testing - it’ll help show if the issue is firmware, the kernel, an interaction between the two and so on.
Unfortunately I don’t know how to replicate it, i.e. this panic is completely sporadic. It could happen once in a few weeks or a few times in a day.
All the firmware is the latest. I used both the fwupdmgr and the internal ability of the BIOS to update itself from the hp.com site. The fwupdmgr brought the previous 01.07.01 version of the BIOS and such panics happened with that version and with the previous version too. Later the internal BIOS updater brought the latest 01.07.02 version, so now there is no any newer BIOS/firmware that I can install or update.
Can the kernel panic mechanism itself or logging of panics be configure to be more verbosely and informative? So next time such a panic happens I would have more information to share.
You can - you can add the kernel parameter ignore_loglevel to the curently booted kernel - it’ll log everything all of the time though, so unless you can find a way to trigger this issue fairly reliably, you’re going to have lots of output in the journal.
That’s why I wanted to you try to replicate the issue - if you can’t replicate it, you never know if it’s fixed.
I just want to find more information that will help the kernel maintainers to fix this bug and probably to find a way of replicating it programmatically.
If I add that ignore_loglevel kernel parameter, could it slow my computer down or could it allocate too much disk space? For example during 2 - 3 months.
Will I have to add that ignore_loglevel kernel parameter again and again after each kernel update?
Yes, it will have an impact on the overall performance of the kernel, as it’ll be logging more data, more frequently and subsequently consuming more disk space. It’ll be using more CPU and more battery as it’s doing more work.
As for how much disk space it’ll use - no idea - depends on how much it logs which will vary from machine to machine.
If you add it to the kernel at boot time, by hitting e on the grub screen and placing it on the end of the existing kernel parameters, it’ll only be in effect for that boot. Subsequent boots will revert to normal.
If you want it logging more all the time, you can add it to the list of standard parameters which are applied to all kernels using grubby. I suspect you do not want to do this.
In other words setting verbose logging for a long time is not practical. Since I can’t reproduce this bug reliable maybe there is something else that I can do? Maybe enabling crash dumps of the kernel will be useful? Will it help to find a reliable way of reproducing this issue later programmatically? How to do that? Should I also install the kernel-debug package?
I suppose it only has to be triggered once with verbose logging on (and to be honest, I’m not even sure if you’ll get any additional information that’s useful - I’ve never needed to apply full-blast logging myself so I don’t know how much extra it spits out.
You oculd always try it and perform a few suspend/resume cycles which often is the trigger for i915 causes - there’s evidently something in the hardware or the standard driver which doesn’t deal perfectly with suspend and resume, I suspect.
I’ll have a crack at it now with my own system - rebooting with an ignore_loglevel parameter.
Doesn’t seem particularly different to me - I’d say give it a shot; I’m not sure if you’ll actively notice any difference. It’s not a fire-hose of output spewing out, until something does crash when I assume you’ll get a lot more debug output.