On Fri, Oct 09, 2020 at 05:17:53PM +0200, Jason A. Donenfeld wrote: > Interestingly, some of the time that I run that lspci command, the > dmesg line is provoked. That sort of makes sense, since lspci is > communicating over the bus to gather all that info. I ran the command > a few times and stored the output, if you want to look at their diffs. > See attached. The dmesg logs from your initial report: pcieport 0000:04:00.0: 31.504 Gb/s available PCIe bandwidth, limited by 8.0 GT/s PCIe x4 link at 0000:00:1b.4 (capable of 1984.941 Gb/s with 32.0 GT/s PCIe x63 link) are almost certainly seeing ~0 responses to config reads of 04:00.0. That would happen if 04:00.0 were powered off or if the bridge leading to it (00:1b.4) were in Downstream Port Containment mode. 00:1b.4 does support DPC, but none of the lspci logs you attached show DPC being triggered. If it were, you should see some indication in dmesg as well, e.g., the "containment event, status:%#06x source:%#06x\n" message from dpc_process_error(). If you can collect the complete dmesg log, especially after you get the bandwidth notification spam, it might have a clue. Just to re-confirm: this happens with v5.8 but not with v5.9? (v5.9 had not been released at your initial report, so I assume you meant v5.9-rc8 or something?) If you can bisect, that would be the easiest way to identify the problem. Bjorn
