Re: kern/57790: Kernel panic on install

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

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

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: dean.anderson71%yahoo.com@localhost
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Subject: Re: kern/57790: Kernel panic on install
Date: Wed, 20 Dec 2023 22:12:42 +0000

 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.