Re: NetBSD domU fails on Xen 3.4.0 dom0

[Anup Patil <anupp%gmx.net@localhost>]

On Thu, 2009-06-04 at 13:45 +0300, Martti Kuparinen wrote:
> Hi,
> 
> My domU is running without any problems on Debian 5.0.1 dom0 with Xen 3.3.1. 
> I 
> upgraded our secondary dom0 to 3.4.0 and started my domU but it panics early 
> in 
> the boot. Any ideas what's wrong?
> 
> ROOT xen2:~> xm create -c /xen/conf/mydomain.org
> Using config file "/xen/conf/mydomain.org".
> Started domain mydomain.org (id=1)
> Loaded initial symtab at 0xc04dfdb8, strtab at 0xc05159ec, # entries 12823
> Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
>      2006, 2007, 2008
>      The NetBSD Foundation, Inc.  All rights reserved.
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>      The Regents of the University of California.  All rights reserved.
> 
> NetBSD 5.0.0_PATCH (XEN3PAE_DOMU) #0: Mon May 18 08:50:17 EEST 2009
>  
> root%backup.mydomain.com@localhost:/autobuild/netbsd-5-0/obj/i386/sys/arch/i386/compile/XEN3PAE_DOMU
> total memory = 512 MB
> avail memory = 496 MB
> mainbus0 (root)
> hypervisor0 at mainbus0: Xen version 3.4
> vcpu0 at hypervisor0: Intel 686-class, 2992MHz, id 0x10676
> xenbus0 at hypervisor0: Xen Virtual Bus Interface
> xencons0 at hypervisor0: Xen Virtual Console Driver
> xencons0: using event channel 2
> npx0 at hypervisor0: using exception 16
> xbd0 at xenbus0 id 2048: Xen Virtual Block Device Interface
> xpq_flush_queue: 1 entries
> 0x00000002f8509e70: 0x00000000335cc003
> panic: HYPERVISOR_mmu_update failed
> 
> fatal breakpoint trap in supervisor mode
> trap type 1 code 0 eip c0395dbc cs 9 eflags 246 cr2 0 ilevel 6
> Stopped in pid 0.12 (system) at netbsd:breakpoint+0x4:  popl    %ebp
> db> bt
> breakpoint(c044677b,ca7f2a48,c045bf80,c0300975,0,5,0,0,ca7f2a58,ca7f2a5c) at 
> net
> bsd:breakpoint+0x4
> panic(c04481a2,f8509e70,3,1634e003,0,c1010de0,ca7f2a6c,c02d2827,c04b7622,0) 
> at n
> etbsd:panic+0x1a6
> xpq_flush_queue(f8509e70,3,1634e003,0,0,4,1634e000,0,ca7ce000,bfe53e70) at 
> netbs
> d:xpq_flush_queue+0xb2
> pmap_kenter_ma(ca7ce000,1634e000,0,2,ca7f2b60,c04dc3c0,ca7f2b1c,c0397ff0,1,bfe50
> 000) at netbsd:pmap_kenter_ma+0xc9
> xengnt_more_entries(6,cb130000,ca7f2b7c,c02863c4,314ac000,4,ca7f2b4c,c03adc84,c0
> 4dc3c0,c04dc3c0) at netbsd:xengnt_more_entries+0xee
> xengnt_get_entry(c04dc3c0,c04dc3c0,0,ca8f5208,c104d680,cb12f040,ca7f2b7c,c03b01d
> 6,0,314ac000) at netbsd:xengnt_get_entry+0x24
> xengnt_grant_access(0,314ac000,4,0,ca8f52a8,bf800000,cb12f000,ca8f5208,ca8f5208,
> 1) at netbsd:xengnt_grant_access+0x24
> xenbus_grant_ring(c104d680,314ac000,4,ca8f52a8,ca7cacf0,ca7f2bd8,c04392a6,ca7cad
> 0c,ca7ca3ac,ca7f2bb8) at netbsd:xenbus_grant_ring+0x36
> xbd_xenbus_attach(ca7ca390,ca7cacf0,ca7f2c54,0,ca7f2c54,0,ca7cacf0,c104d6b0,c104
> d680,c04153b7) at netbsd:xbd_xenbus_attach+0x1af
> config_attach_loc(ca7ca390,c0452e10,0,ca7f2c54,c03b07b0,0,ca7f2c7c,c03b0daf,ca7c
> a390,c04153b7) at netbsd:config_attach_loc+0x166
> config_found_ia(ca7ca390,c04153b7,ca7f2c54,c03b07b0,a,c1072edc,0,c1072ecc,ca7f2c
> ba,0) at netbsd:config_found_ia+0x32
> xenbus_probe_device_type(ca7f2cba,1e,c0448d24,c1072ecc,ca7f2cdc,0,0,c1072ec0,0,0
> ) at netbsd:xenbus_probe_device_type+0x28f
> xenbus_probe_frontends(0,0,c04153b7,ca2ea2a0,ca2ea2a0,c03b11f0,ca7f2d2c,c03b1260
> ,0,ca7f2da0) at netbsd:xenbus_probe_frontends+0xbf
> xenbus_probe(0,ca7f2da0,ca2ea2a0,ca2ea2a0,c03b11f0,ca2ea2a0,0,c01000a1,ca2ea2a0,
> 0) at netbsd:xenbus_probe+0x18
> xenbus_probe_init(ca2ea2a0,0,c010006b,c0100063,c010006b,0,0,0,0,0) at 
> netbsd:xen
> bus_probe_init+0x70

I see identical behaviour.



Anup Patil