Leap 15.3: Kernel Panic on Boot after apparently successful update from 15.2


I’ve updated a relatively old machine from Leap 15.2 to 15.3. Everything seemed to complete OK but the machine now stops with a kernel panic early in the boot process. The output reports a “Fatal exception in interrupt” after a line tagged RIP which point to an address in the pm80xx module.

The motherboard is an ASUS P8H61-M with a Pentium G850 and the machine has an Adaptec 6805H controller board set up in non-RAID mode for a software RAID 6 array. The OS is installed on an SSD.

That’s about all the information I have at the moment. The machine is running headless with an Aten IP8000 providing console access but any suggestions for further debugging options would be gratefully received.

I’m thinking about pulling the SSD to read the Smart data and then maybe trying a repair install to see if there was any unreported corruption of a file during the update


The problem was something to do with the interrupt handling of the pm80xx module in the default kernel, kernel-default-5.3.18-57.3.
Booting the system with pci=nomsi resulted in a successful boot but with no access to the disks on the SAS HBA controller (and also an error message related to setting up the interrupt)

The system boots successfully with the alternate kernel, 5.3.18-lp152.75-default.

Should this be reported as a bug? If so, how do I go about it?


Hi and welcome to the Forum :slight_smile:
See here for reporting a bug: openSUSE:Submitting bug reports - openSUSE

Many Thanks, Looks like I’ve got a few more things to work through before submitting a bug report


Yes, that is a good idea, boot with “pci=nomsi” and try to insert the module after but by hand.

When I booted with pci=nomsi, the module still loaded during boot but there was an error reported when trying to set up interrupts. After boot, there were no disks visible to the system and the module wouldn’t unload as it was in use.

I also tried pci=nacpi, pci=noirq, pci=noacpi,routeirq and acpi=off and all of these also all resulted in a kernel panic

I’m considering trying blacklisting the pm800x module at boot and then trying a manual load of the module from the command line. If nothing else, this should enable me to get a kernel dump of the panic