May 18, 20215 yr 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 Edited May 18, 20215 yr by cheezdog Updated device which seems to be causing the logs
May 25, 20215 yr Author 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.
June 17, 20215 yr pcieport 0000:001c.5: spurious naticw interrupt My system (p10s-c / V4，E3 1235L V5) also has this error, replacing the motherboard should be able to solve it.
June 17, 20215 yr On 5/18/2021 at 12:46 PM, cheezdog said: 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 82.83 kB · 1 download Is the error resolved? Edited June 17, 20215 yr by chouniu
June 17, 20215 yr Author 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.
June 17, 20215 yr 2 hours ago, cheezdog said: 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. E3 Pro gaming V5 motherboard was used, it was no error. When the motherboard p10s-c / V4 , it appeared: pcieport 0000:001c.5: spurious naticw interrupt The day after tomorrow, I'm going to test with another motherboard: supermicro x11sh-ln4 Edited June 17, 20215 yr by chouniu
June 17, 20215 yr Motherboard p10s-c / V4 E3 1235l V5 uses Windows 10 system, CPU uses 50%, so I think it's a hardware problem
June 17, 20215 yr Reference article https://github.com/torvalds/linux/commit/00ebf1348cb332941dab52948f29480592bfbe6a https://my.oschina.net/u/4392555/blog/4222769
June 17, 20215 yr Author 5 hours ago, chouniu said: Reference article https://github.com/torvalds/linux/commit/00ebf1348cb332941dab52948f29480592bfbe6a https://my.oschina.net/u/4392555/blog/4222769 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.
June 19, 20215 yr On 6/17/2021 at 8:15 PM, cheezdog said: 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. supermicro x11sh-ln4 E3 1235l V5 ECC 18G The test results is perfect! In addition, there is another possibility: gen8, to turn off rmrr verification, you need to add Intel IOMMU = relax rmrr in the U disk startup
June 19, 20215 yr Author 9 hours ago, chouniu said: supermicro x11sh-ln4 E3 1235l V5 ECC 18G The test results is perfect! In addition, there is another possibility: gen8, to turn off rmrr verification, you need to add Intel IOMMU = relax rmrr in the U disk startup 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!
November 1, 20214 yr Author 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. Edited November 2, 20214 yr by cheezdog
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.