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 don't believe unraid will mount NTFS formatted drives for array use. I think you are going to have to format them to XFS in order to use the drives in the array.

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.

I think that would work. I'd did some quick reading on pcie and you should be able to use the pcie x16 slots for your network card and SATA card. On the x11sca-f board, using both pcie x16 slots limits them to x8/x8, so be aware of that.

In looking at the block diagram and reading the manual, I think one of the m.2 nvme slots is shared with the pcie x 4 slot, meaning you could use one of the m.2 slots but not both if you wanted to also use the pcie x4 slot.

Interesting. I didn't notice the lack of video support for the x11scm-f until I compared the specs with the ATX sized x11sca-f. I assumed there were only minor differences between the two. If you look at the specs for the x11sca-f: https://www.supermicro.com/products/motherboard/X11/X11SCA-F.cfm , you can see it states support for intel UDH P630 graphics. (Item 5 and under the 'Video Output' specs) I would take the lack of these statements on the page for the x11scm-f to indicate it doesn't support on-chip video. Certainly not stated very clearly, for sure. If you have the space for an ATX board, you might look into the x11sca-f as several others seem to have it working. I'm still piecing mine together but I purchased the MB and e-2146g based on their success.

Try reading the second page of this thread. There's a bit of talk about BIOS settings and kernel options that people have had success with. I just picked up an X11SCA-F (ATX version instead of M-ATX) but I haven't had a chance to test this out.