Re: kern/57790: Kernel panic on install

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

Sure.

FYI, subsequent testing revealed that a 30 second delay between VM starts appears to have made the problem go away.

I suspect it’s memory related, and that the Dom0 allocates and then frees a ton of memory during VM construction.

So I’m thinking it’s really a xen bug but a better error message in the netbsd kernel wouldn’t hurt…





Sent from my iPhone

> On Dec 20, 2023, at 4:12 PM, Taylor R Campbell <riastradh%netbsd.org@localhost> wrote:
> 
> Dean: Can you run with serial console rather than graphical console
> and record the entire output?  That may help to gather more
> information about the environment that NetBSD is booting in.
> 
> 
> Relevant fragment of stack trace:
> 
> 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
> 
> There's only one panic in xengnt_finish_init:
> 
>    while (gnt_nr_grant_frames < previous_nr_grant_frames) {
>        if (xengnt_more_entries() != 0)
>            panic("xengnt_resume: can't restore grant frames");
>    }
> 
> So although it's not printed on screen, I think that must be what
> crashed.
> 
> There are three ways xengnt_more_entries can fail:
> 
> 1. gnt_nr_grant_frames == 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
> 
> (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.)
> 
> Can we get someone who knows the Xen grant table logic to look at
> this and figure out what's happening here?
> 
> 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.