FreeBSD 8, i386 PV panic at idle

[K. Macy]

It is possible to grab a coredump through xen. That would simplify
diagnosis. I also wrote a patch to gdbserver that allowed one to treat
a running VM or a core as a process.

Cheers

On Wed, Jul 27, 2011 at 6:52 PM, Sean Bruno <seanbru at yahoo-inc.com> wrote:
> Simple left my xen domu running over night.  The console looks like
> this:
> rtc0: [XEN] xen_rtc_settime
> [XEN] hypervisor wallclock nudged; nudging TOD.
> [XEN] hypervisor wallclock nudged; nudging TOD.
> [XEN] hypervisor wallclock nudged; nudging TOD.
> [XEN] hypervisor wallclock nudged; nudging TOD.
> [XEN] hypervisor wallclock nudged; nudging TOD.
> [XEN] hypervisor wallclock nudged; nudging TOD.
> [XEN] hypervisor wallclock nudged; nudging TOD.
> [XEN] hypervisor wallclock nudged; nudging TOD.
> [XEN] hypervisor wallclock nudged; nudging TOD.
> [XEN] hypervisor wallclock nudged; nudging TOD.
> [XEN] hypervisor wallclock nudged; nudging TOD.
> [XEN] hypervisor wallclock nudged; nudging TOD.
> [XEN] hypervisor wallclock nudged; nudging TOD.
> panic: HYPERVISOR_update_va_mapping(((unsigned long)(sysmaps->CADDR2)),
> (0x001 | 0x002 | xpmap_ptom(((m)->phys_addr)) | 0x020 | 0x040),
> UVMF_INVLPG| UVMF_ALL) <
> 0: /dumpster/scratch/sbruno-scratch/8/sys/i386/xen/pmap.c:3400
> cpuid = 0
> KDB: enter: panic
> [thread pid 61868 tid 100085 ]
> Stopped at      kdb_enter+0x3a: movl    $0,kdb_why
> db> bt
> Tracing pid 61868 tid 100085 td 0xc3e0d2e0
> kdb_enter(c0369837,c0369837,c03915fd,e1ae0acc,0,...) at kdb_enter+0x3a
> panic(c03915fd,c0398e3e,c039848a,d48,c05bc140,...) at panic+0x134
> pmap_zero_page(c15d9038,e,0,40,e1ae0c14,...) at pmap_zero_page+0x112
> vm_fault(c350e0ec,bf7ee000,2,8,bf7eed78,...) at vm_fault+0x1201
> dblfault_handler() at dblfault_handler+0x4d7
> --- trap 0x17, eip = 0, esp = 0, ebp = 0 ---
>
>
> The Dom0 has the following on its console:
> entOS release 5.6 (Final)
> Kernel 2.6.18-238.12.1.el5xen on an x86_64
>
> xen1.freebsd.org login: (XEN) mm.c:2315:d146 Bad type (saw
> 4800000000000002 != exp e000000000000000) for mfn 1269f1 (pfn 25d7a)
> (XEN) mm.c:807:d146 Error getting mfn 1269f1 (pfn 25d7a) from L1 entry
> 00000001269f1063 for l1e_owner=146, pg_owner=146
>
>
>
> DomU config:
> #============================================================================
> # Python configuration setup for 'xm create'.
> # This script sets the parameters used when a domain is created using
> 'xm create'.
> # You use a separate script for each domain you want to create, or
> # you can set the parameters for the domain on the xm command line.
> #============================================================================
>
> #----------------------------------------------------------------------------
> # Kernel image file.
> #kernel = "/usr/lib/xen/boot/hvmloader"
> kernel = "/var/virt/freebsd-8-stable-i386-domu-kernel"
>
> #----------------------------------------------------------------------------
> # device model to use: only qemu-dm available for now
> #device_model = '/usr/lib64/xen/bin/qemu-dm'
>
> #builder='hvm'
>
> # Initial memory allocation (in megabytes) for the new domain.
> memory = 855
>
> # number of CPUS
> vcpus = 1
>
> # A name for your domain. All domains must have different names.
> name = "ref8-xen32"
> arch = "i386"
>
> #Network interface. By default emules a realtek 8139. For a NetBSD guest
> you
> # have to disable re(4) and let rtk attach to use it.
> # ne2k_pci emulates a pci ne2000 clone; this his cpu-hungry in dom0
> # pcnet emulates a AMD PCnet-PCI controller; but it corrupts packets
> with
> # pcn(4) under NetBSD.
> #vif = [ 'mac=00:16:3e:00:00:01, bridge=xenbr0, type=ioemu' ]
> vif = [ 'mac=00:16:3e:00:00:01, bridge=xenbr0, type=vbd' ]
>
> # Define the disk devices you want the domain to have access to, and
> # what you want them accessible as.
> # Each disk entry is of the form phy:UNAME,DEV,MODE
> # where UNAME is the device, DEV is the device name the domain will see,
> # and MODE is r for read-only, w for read-write.
> # For hvm domains you can only use hda to hdd. You can set extra types
> # (e.g. cdrom)
>
> disk = [
>        'file:/var/virt/FreeBSD-8.2-RELEASE-i386-disc1.iso,hdc:cdrom,r',
>        'file:/var/virt/ref8-xen32.bin,hda,w'
>        ]
>
> extra = "vfs.root.mountfrom=ufs:/dev/ad0s1a"
> # floppy images; this doesn't seem to work currently. Use a iso image
> instead.
> #fda = '/home/domains/boot1.fs'
>
> # boot device: a = floppy, c= hard drive, d= cdrom (with the disk entry
> # before)
> #
> # boot CDROM image
> #boot='d'
> # boot from DISK file
> boot='c'
>
> # By default, 'xm create' will try to open an X window on the current
> display
> # for the virtal framebuffer. You can have the virtal framebuffer in vnc
> # instead, and connect using a vnc client (using localhost:$vncdisplay)
> # If vncunused is set to 1 (this is the default value), vncdisplay
> # will be set to the first unused port; so it's recommended to
> #vfb = [ "type = vnc, vncdisplay = 1, vncunused = 0, display = TEST"  ]
>
> #Xen emulates a PS/2 mouse, but the pointer in the guest has
> difficulties
> # tracking the absolute position. Xen can emulate a USB tablet in
> addition
> # to the mouse which will report the absolute position of the pointer,
> # and make the mouse much easier to use.
> #
> usb=1
> usbdevice='tablet'
> #usbdevice='mouse'
>
> serial='pty'
> on_reboot='restart'
> #============================================================================
>
>
>
> _______________________________________________
> freebsd-xen at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-xen
> To unsubscribe, send any mail to "freebsd-xen-unsubscribe at freebsd.org"
>