On Wed, Dec 09, 2020 at 11:43:59PM +0200, Vladimir Oltean wrote: > On Wed, Dec 09, 2020 at 03:34:49PM -0600, Bjorn Helgaas wrote: > > On Wed, Dec 09, 2020 at 11:20:17PM +0200, Vladimir Oltean wrote: > > > On Wed, Dec 09, 2020 at 02:59:13PM -0600, Bjorn Helgaas wrote: > > > > Yep, that's the theory. Thanks for testing it! > > > > > > Testing what? I'm not following. > > > > You posted a patch that you said fixed the bug for you. The fix is > > exactly the theory we've been discussing, so you have already verified > > that the theory is correct. > > > > I'm sure Krzysztof will update his patch, and we'll get this tidied up > > in -next again. > > If you were discussing this already, I missed it. I was copied to this > thread out of the blue two emails ago. I also looked at the full thread > on patchwork, I don't see anything being said about the culprit being > the size of the config space mapping. Oh, sorry, this was an IRC discussion on #linux-pci (OFTC): 10:51 AM <bjorn_> so the fault is on the first read for 00:00.1. forget my noise about extracting the device/func from the *virtual* address. the *physical* address is supposed to be aligned so you can do that, but not the virtual address 10:55 AM <bjorn_> kwilczynski: oh, i think i see it: pci_ecam_create() does "bsz = 1 << ops->bus_shift", but we removed .bus_shift for this case 10:55 AM <bjorn_> needs to default to 20 if it's not specified 10:56 AM <bjorn_> result is that we only map one page of the ECAM space, so we fault when we access the second page (which is where 00:00.1 starts) Anyway, thanks very much again for fixing this and confirming the fix! Bjorn
