NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

port-xen/42482: dom0 panics when copying large file



>Number:         42482
>Category:       port-xen
>Synopsis:       dom0 panics when copying large file
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    port-xen-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Dec 20 13:50:00 +0000 2009
>Originator:     Julio Merino
>Release:        NetBSD 5.99.22 (current as of 2009/12/20)
>Organization:
Julio Merino <jmmv%NetBSD.org@localhost>
>Environment:
System: NetBSD portal.virtual.network 5.99.22 NetBSD 5.99.22 (XEN3_DOM0) #6: 
Sun Dec 20 11:24:20 GMT 2009  
jmmv%portal.virtual.network@localhost:/home/jmmv/os/netbsd/obj.amd64/home/jmmv/os/netbsd/src/sys/arch/amd64/compile/XEN3_DOM0
 amd64
Architecture: x86_64
Machine: amd64
>Description:
        I have NetBSD 5.99.22 amd64 running on a Dell Precision T3400 (4-core,
        8gb machine).  I can reproducibly panic the machine by scp'ing an ISO
        image into it, and it seems to always crash at about 80% of the copy
        (2.8GB, but never in the exact same place).

        This happens with a XEN3_DOM0 kernel (xen 3.3), but not with a GENERIC
        one.  There are no domUs yet: the file is being copied from a remote
        machine into the dom0, which has 8gb of swap.

        The backtrace below corresponds to a dom0 with 6GB of ram.  I have
        tried other settings such as 3900M, 4GB, 6GB and all crashed.  However,
        setting the memory to 1GB or 2GB allowed the machine survive during the
        copy.

        WAPBL is not involved.

        The trace goes like this:

        kernel: page fault trap, code=0
        Stopped in pid 41.1 (scp) at netbsd:pmap_kenter_pa+0x169: movq 
0(%rax),%rsi
        pmap_kenter_pa() at netbsd:pmap_kenter_pa+0x169
        ubc_alloc() at netbsd:ubc_alloc+0x289
        ubc_iomove() at netbsd:ubc_uiomove+0xc0
        ffs_write() at netbsd:ffs_write+0x2a4
        VOP_WRITE() at netbsd:VOP_WRITE+0x2d
        vn_write() at netbsd:vn_write+0xc0
        dofilewrite() at netbsd:dofilewrite+0x74
        sys_write() at netbsd:sys_write+0x6e
        syscall() at netbsd:syscal+0xa8

        db> show register
        ds 0
        es 0x9910
        fs 0x6000
        gs 0x4ae0
        rdi 0xffffa00053ff70000
        rsi 0xc5428000
        rbp 0xffffa000548798f0
        rbx 0cx5428
        rdx 0x7f8000000000
        rcx 0
        rax 0xffffffff81400140
        r8 0xffffffff80b83f40 cpu_info_primary
        r9 0xffffa00054879918
        r10 0xffffa00005bf78c0
        r11 0
        r12 0x3
        r13 0x7fd00029ffb8
        r14 0
        r15 0xffffa00053ff7000
        rip 0xffffffff80521160 pmap_kernel_pa+0x169
        cs 0xe030
        rflags 0x10282
        rsp 0xffffa000548798c0
        ss 0xe02b
        netbsd:pmap_kenter_pa+0x169: movq 0(%rax), %rsi

        (gdb) list *(pmap_kenter_pa+0x169)
        0xffffffff80521160 is in pmap_kenter_pa (./xen/xenpmap.h:93).
        88      }
        89
        90      static __inline paddr_t
        91      xpmap_ptom_masked(paddr_t ppa)
        92      {
        93              return (((paddr_t)xpmap_phys_to_machine_mapping[(ppa -
        94                  XPMAP_OFFSET) >> PAGE_SHIFT]) << PAGE_SHIFT);
        95      }
        96
        97      static inline void
        (gdb)
>How-To-Repeat:
        Get a dom0 running with more than 4GB of ram assigned to it.  scp a big
        file (a 4GB DVD image into it) and watch it crash.
>Fix:
        Unknown, but the workaround is to set the dom0 memory to a low value
        such as 1GB.



Home | Main Index | Thread Index | Old Index