Re: kern/55667 (regression: XEN3_DOM0 fails to boot on)

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

The following reply was made to PR kern/55667; it has been noted by GNATS.

From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
To: Frank Kardel <kardel%netbsd.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost, jdolecek%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/55667 (regression: XEN3_DOM0 fails to boot on)
Date: Thu, 26 May 2022 13:41:09 +0200

 On Thu, May 26, 2022 at 07:36:01AM +0200, Frank Kardel wrote:
 > On 05/25/22 21:05, Manuel Bouyer wrote:
 > > The following reply was made to PR kern/55667; it has been noted by GNATS.
 > > 
 > > From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
 > > To: Frank Kardel <kardel%netbsd.org@localhost>
 > > Cc: gnats-bugs%netbsd.org@localhost, jdolecek%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
 > >          netbsd-bugs%netbsd.org@localhost
 > > Subject: Re: kern/55667 (regression: XEN3_DOM0 fails to boot on)
 > > Date: Wed, 25 May 2022 21:02:46 +0200
 > > 
 > >   --hjWYvqh1VhkoqIsN
 > >   Content-Type: text/plain; charset=us-ascii
 > >   Content-Disposition: inline
 > >   On Wed, May 25, 2022 at 07:51:12PM +0200, Frank Kardel wrote:
 > >   > See uuencodes files:
 > >   thanks, I see nothing obvious here.
 > >   Please rebuild the netbsd-XEN3_DOM0 kernel with the attached patch,
 > >   and use the attached xen-debug.gz (it has extra printk which I used to debug
 > >   the msi/msi-x setup). Hopefully this will tell us why Xen refuses to map
 > >   the msi-x, and then the msi interrupts.
 > >   --
 > >   Manuel Bouyer <bouyer%antioche.eu.org@localhost>
 > >        NetBSD: 26 ans d'experience feront toujours la difference
 > >   --
 > >   --hjWYvqh1VhkoqIsN
 > >   Content-Type: text/plain; charset=us-ascii
 > >   Content-Disposition: attachment; filename=diff
 > Here is the output (I had to wait for backup to complete):
 
 thanks.
 So Xen is failing eiter because it has no useable APIC or, more likely,
 it doens't find the PCI device. One possible cause is that this machine is
 using non-0 PCI segments, but we don't support PCI segments (and always
 set it to 0 when talking to Xen). Fixing it requires touching the MI pci
 infrastructure, which may not be a good idea so close to netbsd-10.
 
 Anyway the fallback to legacy interrupts should work. I think there's a
 problem specific to ixg(4) with legacy interrupts, I've opened kern/56857
 about it.
 
 -- 
 Manuel Bouyer <bouyer%antioche.eu.org@localhost>
      NetBSD: 26 ans d'experience feront toujours la difference
 --