Hello, Keir,
Please, do You have any inforamtion what is the state of this error.
This is still reported in the version 3.2.1 by some people, the bug in
bugzilla is still open - for very very long time...
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1038
I have seen in the last time You are the only person who adds some
new commits to the Xen repository, so I want to ask You, if You have any
information what can be done to avoid this problem...
IF I yesterday compiled the Xen 3.2.1 source tarball downloaded at
5.5.2008 will this bug be still there? If I would take the current Xen
unstable, will this issue be still there?
From unknown reasons it became a critical problem for us in the last
days, the domains are crashing now some minutes after the start (Oracle
Instance, which starts the reconstrukction of the data from previous crash
and the load starts to be big from the start - this is my guess why it
happens)...
Any helps or informations about some solution or work-around would
be highly appreciated...
Thany You in advance for help,
Artur
-----Original Message-----
From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Keir Fraser
Sent: Tuesday, August 07, 2007 2:09 PM
To: Matthias Ableitner; xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] domU crash by large disk operations on dom0
Almost certainly this is a jump at bm->dma_cb() == NULL. Possibly a DMA
control block has been queued up twice or something like that.
This whole area of code is rewritten in qemu 0.90, as used in xen-unstable.
You may have success using xen-unstable's qemu-0.90 on xen 3.1.
-- Keir
On 7/8/07 12:57, "Matthias Ableitner" <spam@xxxxxxx> wrote:
> Hi,
>
> i've installed xen 3.1 as dom0 and windows 2003 as domU. While dom0 does
> big file operations, qemu-dm crashes with a segfault:
>
> qemu-dm[18802]: segfault at 0000000000000000 rip 0000000000000000 rsp
> 0000000041000c08 error 14
>
> This happened while dom0 was cloning a snapshot from the partion, where
> domU lives. I can reproduce the bug, so i made a backtrace:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1090525504 (LWP 7085)]
> 0x0000000000000000 in ?? ()
> (gdb) bt
> #0 0x0000000000000000 in ?? ()
> #1 0x000000000042b2e3 in dma_thread_func (opaque=<value optimized out>)
> at
>
/var/tmp/portage/app-emulation/xen-tools-3.1.0/work/xen-3.1.0-src/tools/ioem
u/
> hw/ide.c:2402
> #2 0x00002b044f6e1135 in start_thread () from /lib/libpthread.so.0
> #3 0x00002b044fd1562d in clone () from /lib/libc.so.6
> #4 0x0000000000000000 in ?? ()
>
> I've added this to bug #542 but i don't know, if it's the same bug.
> Others seems to have the problem too, but i couldn't find a solution. My
> solution is to avoid big file operations, or stop the domU...
>
> Others seems to have this problem too.
>
>
> Best regards,
>
> Matthias
>
>
>
> Ps.: more details are also on xen-users:
> http://lists.xensource.com/archives/html/xen-users/2007-08/msg00074.html
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
__________ Informace od NOD32 2441 (20070807) __________
Tato zprava byla proverena antivirovym systemem NOD32.
http://www.nod32.cz
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home