Error on restore domU (x86_64)

[Robert Valentan <R.Valentan@solid-soft.at>]

My system: Tyan-Dual-Opterion with 2 Opteron 246 with 2GB RAM
    for each processor.

version: xen-unstable 9499  with liunx 2.6.16

I have defined a domU with 4 vcpus, starting with create is
working. I get in domU in /proc/cpuinfo 4 cpu's.
Using only 1 or 2 vcpus, i havn't got an error.

"xm store # file "  seems to be ok (no error, filesize 2GB)
"xm restore file"   the command (xm) gives no error, but on
  the xen-console (com1) I get

---------------------begin------------------------------------
(XEN) domain_crash_sync called from entry.S
(XEN) Domain 2 (vcpu#0) crashed on cpu#1:
(XEN) ----[ Xen-3.0-unstable    Not tainted ]----
(XEN) CPU:    1
(XEN) RIP:    e033:[<000000000000e033>]
(XEN) RFLAGS: 0000000000190e12   CONTEXT: guest
(XEN) rax: ffffffffffffffda   rbx: 0000000000000001   rcx: 000000000000e033
(XEN) rdx: 0000000000000000   rsi: 00007fffffd82de0   rdi: 0000000000000008
(XEN) rbp: 0000000000000000   rsp: 000000000000e02b   r8:  0000000000000000
(XEN) r9:  0000000000000000   r10: 0000000000000000   r11: 00007fff7fd80e18
(XEN) r12: 00007fffffd82f5c   r13: 0000000000000007   r14: 000000000040b505
(XEN) r15: 0000000000000002   cr0: 000000008005003b   cr3: 0000000062f14000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
(XEN) Guest stack trace from rsp=000000000000e02b:
(XEN)    Fault while accessing guest memory.
---------------------end------------------------------------

a "xm list" is not showing the new domain.

One time (while "playing" with the bug) i got a running domU,
but "xm list" was showing only 1 vcpus. As i connect to the
dom with "xm console" a got the following in the domU-console:

---------------------begin------------------------------------
Unable to handle kernel NULL pointer dereference at 00000000000001d8 RIP:
<ffffffff8023b284>{blk_start_queue+4}
PGD 7dcbe067 PUD 7dcbf067 PMD 0
Oops: 0002 [1] SMP
CPU 0
Pid: 2777, comm: suspend Not tainted 2.6.16-xenU #13
RIP: e030:[<ffffffff8023b284>] <ffffffff8023b284>{blk_start_queue+4}
RSP: e02b:ffff88007fecdde8  EFLAGS: 00010083
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffffffffff5fd000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffff880000add848 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 00000000fffffffc R12: 0000000000000000
R13: ffff88007ffaba00 R14: ffff88007faba000 R15: ffff88007ffaba00
FS:  00002ab8e17f26d0(0000) GS:ffffffff804e6000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000
Process suspend (pid: 2777, threadinfo ffff88007fecc000, task 
ffff88007faf5520)
Stack: ffff88007faba000 ffffffff80283bc8 00000000ffffffff ffffffff80283f6e
        0000000080282aa0 ffff88007ffaa000 ffff88007faba0d8 ffff880000add800
        ffff880000add848 0000000000000000
Call Trace: <ffffffff80283bc8>{kick_pending_request_queues+24}
        <ffffffff80283f6e>{blkfront_resume+910} 
<ffffffff80144a90>{keventd_create_kthread+0}
        <ffffffff802820d6>{resume_dev+150} <ffffffff80282040>{resume_dev+0}
        <ffffffff802717e9>{bus_for_each_dev+73} 
<ffffffff80281f85>{xenbus_resume+37}
        <ffffffff8027b35d>{__do_suspend+909} 
<ffffffff8027afd0>{__do_suspend+0}
        <ffffffff80144bd9>{kthread+217} <ffffffff8010bd06>{child_rip+8}
        <ffffffff80144a90>{keventd_create_kthread+0} 
<ffffffff80144b00>{kthread+0}
        <ffffffff8010bcfe>{child_rip+0}

Code: f0 0f ba b7 d8 01 00 00 02 f0 0f ba af d8 01 00 00 06 19 c0
RIP <ffffffff8023b284>{blk_start_queue+4} RSP <ffff88007fecdde8>
CR2: 00000000000001d8
---------------------end------------------------------------



-- 
wbr
Robert Valentan