[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [BUG] After upgrade to Xen 4.12.0 iommu=no-igfx
On Wed, Jul 31, 2019 at 2:46 AM Jan Beulich <JBeulich@xxxxxxxx> wrote: > > On 31.07.2019 10:58, Andrew Cooper wrote: > > On 31/07/2019 09:34, Jan Beulich wrote: > >> On 30.07.2019 19:56, Roman Shaposhnik wrote: > >>> On Fri, Jul 26, 2019 at 1:06 AM Jan Beulich <JBeulich@xxxxxxxx> wrote: > >>>> On 23.07.2019 20:25, Roman Shaposhnik wrote: > >>>>> Interestingly enough, adding iommu_inclusive_mapping=1 AND iommu=debug > >>>>> booted the system just fine. > >>>> Btw (I've noticed this only now) - are you saying without "iommu=debug" > >>>> the box does _not_ boot fine, despite the other option? > >>> Yes. But it made sense to me since iommu=debug (as per your > >>> explanation) overwhelms the CPU and I guess adding > >>> iommu_inclusive_mapping=1 avoids the code path that does it? > >> I'm afraid I don't follow: My question was whether > >> "iommu_inclusive_mapping=1" alone would not allow the box to boot. > >> Without "iommu=debug" there's no excessive logging afaict, no > >> matter what other IOMMU options you use. > > > > Without inclusive mappings, the system boots but the screen is junk and > > there are DMA faults all over the place. With inclusive mappings, it > > all "works" fine. > > > > With debug enabled, the DMA faults are spat out to the console for a > > short while, until an APIC error occurs and the system wedges completely. > > Right - the verbosity _with_ "iommu=debug" may be a problem. Hence me > wondering whether the system indeed wouldn't boot _without_ that option. Without iommu=debug (and any other option) the screen is garbled. Thanks, Roman. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |