> Date: Fri, 7 Jun 2019 17:00:24 +1000
> From: David Gwynne <[hidden email]>
> Cc: [hidden email] > Content-Type: text/plain; charset="utf-8"
> Content-Disposition: inline
> currently mem bars and the rom address conflict lines in dmesg look
> the same, which is a bit confusing. this makes rom conflicts lines say
> "rom conflict" instead.
> that looks like this:
> dlg@r6415 pci$ dmesg | grep -A4 conflict
> 129:0:0: rom address conflict 0xfffc0000/0x40000
> 129:0:1: rom address conflict 0xfffc0000/0x40000
> bge0 at pci7 dev 0 function 0 "Broadcom BCM5720" rev 0x00, BCM5720 A0 (0x5720000), APE firmware NCSI 126.96.36.199: msi, address d0:94:66:34:52:57
> brgphy0 at bge0 phy 1: BCM5720C 10/100/1000baseT PHY, rev. 0
> bge1 at pci7 dev 0 function 1 "Broadcom BCM5720" rev 0x00, BCM5720 A0 (0x5720000), APE firmware NCSI 188.8.131.52: msi, address d0:94:66:34:52:58
> brgphy1 at bge1 phy 2: BCM5720C 10/100/1000baseT PHY, rev. 0
> 132:0:0: rom address conflict 0xfff80000/0x80000
> 132:0:1: rom address conflict 0xfff80000/0x80000
> bnxt0 at pci10 dev 0 function 0 "Broadcom BCM57416" rev 0x00: fw ver 20.6.151, apic 131 int 12, address d0:94:66:45:11:d0
> bnxt1 at pci10 dev 0 function 1 "Broadcom BCM57416" rev 0x01: fw ver 20.6.151, apic 131 int 13, address d0:94:66:45:11:d1
> pchb48 at pci6 dev 2 function 0 "AMD AMD64 17h PCIE" rev 0x00
> pchb49 at pci6 dev 3 function 0 "AMD AMD64 17h PCIE" rev 0x00
> 193:0:0: rom address conflict 0xfff00000/0x100000
> mfii0 at pci14 dev 0 function 0 "Symbios Logic MegaRAID SAS3508" rev 0x01: msi
> mfii0: "PERC H740P Mini ", firmware 50.5.0-1750, 8192MB cache
> scsibus2 at mfii0: 64 targets
> sd0 at scsibus2 targ 0 lun 0: <DELL, PERC H740P Mini, 5.05> SCSI3 0/direct fixed naa.6d09466036370500226b9c61889dfc88
That's fine. It is still a (potential) mmio address space conflict,
but it is useful to know it is the ROM BAR that's causing this.
Interesting to see those though. The conflicting address is always
the "all ones" address. So what's hapening here is that the BIOS
sized the ROM, but didn't assign an address and doesn't clear the
register. I've seen the same thing with edk2-based UEFI firmwares on
arm64, and I've been told that edk2 deliberately doesn't assign an
address. Not clearing the register after sizing seems sloppy though.
But if this disease is widespread it may make sense to detect this
case and skip the message. That's another diff though.