Re: DragonFly won't boot on qemu-kvm-1.0

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:It works fine with -no-kvm, which is how I was able to update /usr/src
:and build a new world and kernel (although it took >24h)
:
:HAMMER(ROOT) recovery nexto 3000000003848338 endseqno=00442468
:HAMMER(ROOT) mounted clean, no recovery needed
:DMA space used: 144k, remaining available: 16384k
:
:
:Fatal trap 9: general protection fault while in kernel mode
:cpuid = 0; lapic->id = 00000000
:instruction pointer = 0x8:0xffffffff80898a02
:stack pointer        = 0x10:0xffffffe00e457c00
:frame pointer        = 0x10:0xffffffe003218bb0
:code segment = base 0x0, limit 0xfffff, type 0x1b
:= DPL 0, pres 1, long 0, def32 0, gran 1
:processor eflags = interrupt enabled, IOPL = 0
:current process = 1
:current thread          = pri 10 (CRIT)
:kernel: type 9 trap, code=0
:
:CPU0 stopping CPUs: 0x00000000
: stopped
:Stopped at      cpu_heavy_restore+0x72: movl    %ecx,%cr3
:db> trace
:cpu_heavy_restore() at cpu_heavy_restore+0x72 0xffffffff80898a02
:tsleep() at tsleep+0x5ab 0xffffffff80509071
:dfly_helper_thread() at dfly_helper_thread+0x324 0xffffffff804f7de5
:db> show registers
:cs                 0x8  gd_curthread
:ss                0x10  gd_curthread+0x8
:rax         0xffffffe00e465870
:rcx         0x3dfdc007
:rdx         0xffffffe00e457ce0
:rbx         0xffffffff82248ae8  dfly_pcpu+0x8
:rsp         0xffffffe00e457c10
:rbp         0xffffffe003218bb0
:rsi          0x349c000
:rdi         0xffffffe00e465870
:rip         0xffffffff80898a02  cpu_heavy_restore+0x72
:rfl              0x202  gd_cnt+0x18e
:r8          0xffffffff82249610  dfly_pcpu+0xb30
:r9          0xfffffdff
:r10                  0
:r11         0xffffffff822490a0  dfly_pcpu+0x5c0
:r12         0xffffffe00e465870
:r13         0xffffffff82248ae8  dfly_pcpu+0x8
:r14         0xffffffe00e465870
:r15                  0
:dr0                  0
:dr1                  0
:dr2                  0
:dr3                  0
:dr4         0xffff0ff0
:dr5              0x400  gd_cnt+0x38c
:dr6         0xffff0ff0
:dr7              0x400  gd_cnt+0x38c
:cpu_heavy_restore+0x72: movl    %ecx,%cr3
:db>
:
:What can I do to help diagnose this?

    It's basically dying on an instruction that it shouldn't be
    dying on.  All I can think of is that the linux hw kvm stuff
    isn't implementing the instruction properly, or that it is
    not reporting physical memory properly.

    This would need a kvm expert to figure out.  The register
    state looks correct, but we could try to match up %rcx's 
    physical memory address against the list of memory regions.

    If you boot the kernel verbose and record the entire dmesg output
    we can match those up to see if they are reasonable.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>