On 21.10.2020 15:36, Jason Andryuk wrote: > On Wed, Oct 21, 2020 at 8:53 AM Jan Beulich <jbeulich@xxxxxxxx> wrote: >> >> On 21.10.2020 14:45, Jason Andryuk wrote: >>> On Wed, Oct 21, 2020 at 5:58 AM Roger Pau Monné <roger.pau@xxxxxxxxxx> wrote: >>>> Hm, it's hard to tell what's going on. My limited experience with >>>> IOMMU faults on broken systems there's a small range that initially >>>> triggers those, and then the device goes wonky and starts accessing a >>>> whole load of invalid addresses. >>>> >>>> You could try adding those manually using the rmrr Xen command line >>>> option [0], maybe you can figure out which range(s) are missing? >>> >>> They seem to change, so it's hard to know. Would there be harm in >>> adding one to cover the end of RAM ( 0x04,7c80,0000 ) to ( >>> 0xff,ffff,ffff )? Maybe that would just quiet the pointless faults >>> while leaving the IOMMU enabled? >> >> While they may quieten the faults, I don't think those faults are >> pointless. They indicate some problem with the software (less >> likely the hardware, possibly the firmware) that you're using. >> Also there's the question of what the overall behavior is going >> to be when devices are permitted to access unpopulated address >> ranges. I assume you did check already that no devices have their >> BARs placed in that range? > > Isn't no-igfx already letting them try to read those unpopulated addresses? Yes, and it is for the reason that the documentation for the option says "If specifying `no-igfx` fixes anything, please report the problem." I imply from in in particular that one better wouldn't use it for non-development purposes of whatever kind. Jan _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
