Re: kern/57790: Kernel panic on install

[Dean Anderson <dean.anderson71%yahoo.com@localhost>]

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

From: Dean Anderson <dean.anderson71%yahoo.com@localhost>
To: Taylor R Campbell <riastradh%netbsd.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/57790: Kernel panic on install
Date: Tue, 9 Jan 2024 15:19:32 -0600

 Sure.
 
 FYI, subsequent testing revealed that a 30 second delay between VM starts ap=
 pears to have made the problem go away.
 
 I suspect it=E2=80=99s memory related, and that the Dom0 allocates and then f=
 rees a ton of memory during VM construction.
 
 So I=E2=80=99m thinking it=E2=80=99s really a xen bug but a better error mes=
 sage in the netbsd kernel wouldn=E2=80=99t hurt=E2=80=A6
 
 
 
 
 
 Sent from my iPhone
 
 > On Dec 20, 2023, at 4:12=E2=80=AFPM, Taylor R Campbell <riastradh@netbsd.o=
 rg> wrote:
 >=20
 > =EF=BB=BFDean: Can you run with serial console rather than graphical conso=
 le
 > and record the entire output?  That may help to gather more
 > information about the environment that NetBSD is booting in.
 >=20
 >=20
 > Relevant fragment of stack trace:
 >=20
 > panic
 > xengnt_finish_init() at netbsd:xengnt_finish_init+0x22f
 > xengnt_init
 > hypervisor_attach
 > config_attach_internal
 > config_found
 > xen_mainbus_attach
 > mainbus_attach
 > config_attach_internal
 > config_rootfound
 > cpu_configure
 > main
 >=20
 > There's only one panic in xengnt_finish_init:
 >=20
 >    while (gnt_nr_grant_frames < previous_nr_grant_frames) {
 >        if (xengnt_more_entries() !=3D 0)
 >            panic("xengnt_resume: can't restore grant frames");
 >    }
 >=20
 > So although it's not printed on screen, I think that must be what
 > crashed.
 >=20
 > There are three ways xengnt_more_entries can fail:
 >=20
 > 1. gnt_nr_grant_frames =3D=3D gnt_max_grant_frames
 > 2. kmem_alloc(KM_NOSLEEP) fails
 > 3. HYPERVISOR_grant_table_op(GNTTABOP_setup_table, ...) returns a
 >   status other than GNTST_okay
 >=20
 > (In all three cases, it returns ENOMEM, so printing the error code in
 > the panic message wouldn't help even if we could see the panic
 > message.)
 >=20
 > Can we get someone who knows the Xen grant table logic to look at
 > this and figure out what's happening here?
 >=20
 > If it's case (2), it may just be that the VM doesn't have enough RAM
 > reserved to boot NetBSD.  Not sure we should be using KM_NOSLEEP in
 > this path.