> Was this in the state where things crashed or the "working" state (but > with the second issue you mentioned occurring)?
This is the diff between -18 and -19 when nothing crash in both case. This shows there is a visible change for efibootmgr. > I think there is a pretty good chance that this is therefore a firmware > issue. I'd recommend the first thing to try would be to see if an > updated firmware is available for your system and if so then install it. You mean the motherboard firmware right? There seem to be only minor changes according to the changelog of Gigabyte on their website. I'm always worried about upgrading firmwares, I could give a try though as a last resort. > Your kernel stack trace shows that the CPU has tried to execute code > from a region of RAM which has been marked non-executable when calling > into the firmware. I'm not familiar enough with EFI to know if > responsibility for this lies with the firmware or the kernel and have a > feeling it might be the two in concert. > > You might find that adding "noexec=off" to your kernel command line > worksaround this issue. I can give it a try. Question: isn't it dangerous to enable this flag in normal use? I guess so. > Sounds like a firmware issue to me, if an upgrade doesn't help I'd > recommend to start by reporting against efibootmgr. I thought the issue may be related so I hope I didn't confuse you more with this information. > Once you've updated the firmware I think I'd suggest starting by > reassigning this crash issue to the Linux package (I can help with the > mechanics of that if you need). The thing about the delete boot entries > probably ought to start with efibootmgr (I could clone this report, but > I think a fresh one dedicated to that issue would be better). Thanks for the help. Let's report it to efibootmgr after I tried the two things you mentionned above. Thanks!
signature.asc
Description: Digital signature