Created attachment 292537 [details] otcpl-dell-9370-kbl_mem.html This issue has been showing up on several different platforms for the past few releases: DMAR: [DMA Read] Request device [03:00.0] PASID ffffffff fault addr fffd3000 [fault reason 06] PTE Read access is not set It doesn't seem to cause any functional, power, or performance issues as of yet, but it's worth tracking. I'm in the process of gathering a histogram of all the machines and kernel versions it happens on.
Created attachment 292539 [details] issue.def
This issue appears to have started in 5.8.0-rc1 on several machines, such as: otcpl-aml-y otcpl-cml-h otcpl-cml-u otcpl-dell-7390-cmlu otcpl-dell-9370-kbl otcpl-icl-u-pnp otcpl-kbl-rvp-7 otcpl-tgl-h otcpl-whl-u otcpl-yoga-920-kblr It usually occurs in about 6% of the tests in a batch run.
Created attachment 292585 [details] otcpl-aml-y_mem.html
Created attachment 292587 [details] otcpl-dell-7390-cmlu_mem.html
Created attachment 292589 [details] otcpl-kbl-rvp-7_mem.html
Created attachment 292591 [details] otcpl-whl-u_mem.html
Created attachment 292593 [details] otcpl-yoga-920-kblr_mem.html
Can you attach a complete dmesg log and "sudo lspci -vv" output for one of the affected systems? Also please describe a way to reproduce it (even if it's not 100% reliable). If it's practical to bisect it, that would be very helpful.
Todd, I can also take a look at reproducing. Is it a system that I can access? If so I can give a hand at triaging.
(In reply to Bjorn Helgaas from comment #8) > Can you attach a complete dmesg log and "sudo lspci -vv" output for one of > the affected systems? Also please describe a way to reproduce it (even if > it's not 100% reliable). If it's practical to bisect it, that would be very > helpful. Yes, please let us know what kind of device 03:00.0 is and which driver is attached to it. The output of lspci -vv contains that information. Thanks, Joerg
(In reply to Bjorn Helgaas from comment #8) > Can you attach a complete dmesg log and "sudo lspci -vv" output for one of > the affected systems? Also please describe a way to reproduce it (even if > it's not 100% reliable). If it's practical to bisect it, that would be very > helpful. The html timelines have dmesg and logs embedded. The buttons are on the upper right hand corner. click dmesg to see the dmesg log, click log to see the log. The log includes several basic system info calls like lspci -tv and lsusb -t. There's nothing special to reproducing it. You just call "echo mem > /sys/power/state" in a loop and it occurs in 6% of the timelines. All the systems are running ubuntu 19.04. Try: %> sleepgraph -m mem -rtcwake 15 -multi 6h 0 That'll run it over and over for 6 hours.
Created attachment 293739 [details] otcpl-dell-7390-cmlu-lspci-vv.txt lspci -vv on otcpl-dell-7390-cmlu