At Fri, 7 May 2021 16:44:00 +0100, Patrick Welche <prlw1%cam.ac.uk@localhost> wrote: Subject: Re: booting xen [was Re: serial console puzzle] > > On Fri, May 07, 2021 at 08:52:02PM +0530, Mathew, Cherry G. wrote: > > On 2021, ???? 7 8:35:54 PM IST, Patrick Welche <prlw1%cam.ac.uk@localhost> wrote: > > > > > >[ 1.0000000] NetBSD 9.99.82 (XEN3_DOM0) #4: Wed Apr 28 10:53:21 BST > > >2021 > > >... > > >[ 1.0000030] pci14: i/o space, memory space enabled > > >[ 1.0000030] entropy: WARNING: extracting entropy too early > > >(XEN) mm.c:2980:d0v0 Bad type (saw e400000000000001 != exp > > >2000000000000000) fo) > > >(XEN) mm.c:1142:d0v0 Attempt to create linear p.t. with write perms > > > > uhuh. on a hunch: > > > > can you reduce the dom0 RAM to, say 1G, or play with the configuration (dom0_mem=1G) to see if has any effect ? > > I should have said, that output was from > > menu=Boot Xen:consdev com0,57600;load /netbsd-XEN3_DOM0 console=com0;multiboot /xen-debug.gz dom0_mem=1024M console=com1 com1=57600,8n1,0x3f8 > > so exactly like an older message, without the rndseed bit, which apparently > caused the "not an ELF binary" error. > > (XEN) PHYSICAL MEMORY ARRANGEMENT: > (XEN) Dom0 alloc.: 0000000618000000->000000061a000000 (253952 pages to be al) > (XEN) VIRTUAL MEMORY ARRANGEMENT: > (XEN) Loaded kernel: ffffffff80200000->ffffffff81150ef8 > (XEN) Init. ramdisk: ffffffff81151000->ffffffff81151000 > (XEN) Phys-Mach map: ffffffff81151000->ffffffff81351000 > (XEN) Start info: ffffffff81351000->ffffffff813514b8 > (XEN) Xenstore ring: 0000000000000000->0000000000000000 > (XEN) Console ring: 0000000000000000->0000000000000000 > (XEN) Page tables: ffffffff81352000->ffffffff8135f000 > (XEN) Boot stack: ffffffff8135f000->ffffffff81360000 > (XEN) TOTAL: ffffffff80000000->ffffffff81400000 > (XEN) ENTRY ADDRESS: ffffffff8023d000 > > [ 1.0000000] NetBSD 9.99.82 (XEN3_DOM0) #4: Wed Apr 28 10:53:21 BST 2021 > [ 1.0000000] prlw1@waxwing:/usr/src/sys/arch/amd64/compile/obj.amd64/XEN3_DO0 > [ 1.0000000] total memory = 1024 MB > [ 1.0000000] avail memory = 971 MB I take it that it (NetBSD now, not Xen) is still panic-ing though? And is Xen still printing the same "(Xen) mm.c:" messages too? One other difference with what I do is that I've never tried to boot a gzip'ed version of any kernel (xen or netbsd) -- I just don't see the point and I always unpack them. It shouldn't be the problem though as I believe others do exercise the decompression code in the boot loader regularly. Grasping at straws I don't know much about I'm also wondering if your system has some slightly weird memory layout too. There's usually some way to tell the EFI shell to print info about memory layout -- Google suggests "memmap". Beyond comparing the results to what Xen reports the real trick here though might be recognizing something wrong/different with what the firmware reports vs. the actual hardware. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpwa2pZ3Yc4A.pgp
Description: OpenPGP Digital Signature