cheezdog

To follow up on this... I tried upgrading to 6.10.0-rc1 recently, thinking the newer kernel would eliminate the troublesome log messages. It did not. I realized I had a 2 port NIC installed in my server that I was no longer using. I thought I had pulled it during my initial upgrade attempts and troubleshooting. After removing it, I tried the upgrade to 6.9.2 again. The spurious native interrupt logs are no longer present. It appears there may have been an issue with the NIC.

Thank you for the testing results with your X11SSH-LN4F. I'm happy to learn it is working properly. This could indicate a hardware issue on my end or I might still be facing a kernel bug. I'll keep researching. I did try the iommu=relax_rmrr but I am still seeing the spurious native interrupt log messages several times a second. I've booted back into 6.8.3 for now while I think about what my next steps might be. Thank you again for all of your help!

Thank you for the link! It looks like one of the changes was to log level for the spurious interrupt messages. Am I reading that correctly? Would that mean the messages could be present in older kernels but wouldn't be seen due to log level? (debug vs info)? I would be very interested in your test results on the supermicro motherboard. While not the same chipset as mine, it would provide good information on whether or not this is a hardware problem.

Unfortunately, the BIOS update did not solve the issue. Did you actually replace your motherboard and solve the issue? If yes, did you replace your motherboard with the same model you had before? I'm asking because my searching has me thinking this might be a kernel bug rather than a true hardware problem. While I am not 100% sure it is a kernel issue, I do not have a spare motherboard which fits my CPU and ECC ram so I can't easily test the idea that my hardware is faulty. It does look like this is not a common problem which is making it more difficult to find information or to troubleshoot the issue.

As an update, I have moved forward with installing the latest bios for my motherboard. I'm still seeing the logs flooded with the spurious native interrupt messages upon upgrade to 6.9.2.

After upgrading my Unraid server from 6.8.3 to 6.9.2, I'm seeing the logs filled with: kernel: pcieport 0000:00:1b.4: PME: Spurious native interrupt! I do not see them when running 6.8.3. I haven't tested much on 6.9.2 due to the logs getting flooded. (I rolled back to 6.8.3 for now) I've done a little research and haven't come up with much information. Motherboard is Supermicro X11SCA-F. The device called out in the logs is 00:1b.4 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #21 (rev f0). There is a newer bios available for my motherboard but as this seems like something that might have occurred due to the newer kernel in 6.9.2, I thought I'd post here before working through a bios upgrade. I'm looking for a little help/advice on how to troubleshoot this. Thank you! hippo-diagnostics-20210517-2112.zip

Did you ever find the root cause on this? I attempted an upgrade to 6.9.1 recently and encountered the same issue. My device throwing the error is: 00:1b.0 PCI bridge: Intel Corporation Cannon Lake PCH PCI Express Root Port #17 (rev f0) I've done a bit of searching and haven't come up with any solid hits.

To close the loop on this, I was missing something. I noticed there was a version showing for IGFX VBOIS in the BIOS but not GOP. I changed the video option ROM from Legacy to UEFI. Additionally, I changed the primary PCIE device from 'Auto' to 'On Board'. the i915 driver now loads and I can maintain video via ipmi. (Just in case someone else runs into the same issue)

I'm curious to know if anyone has tested this on 6.7.0-rc6. I'm setting up a new server now with an x11sca-f and an e-2146g. I've got the BIOS set as shown in this thread and the kernel option for i915.disable_display=1 in my syslinux.cfg. I'm getting disconnected from my ipmi session as soon as I load the i915 driver. I feel like I'm missing something...

I think this would be a useful addition for people who want to tie the case fans to HDD temps and the CPU fan to CPU temps. If the CPU is being worked and gets hot but the HDDs aren't, the case fans could spin faster based on CPU temp to evacuate the heat based.