This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] segfault in VM

To: James Harper <JamesH@xxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] segfault in VM
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Thu, 22 Jul 2004 12:54:59 +0100
Cc: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 22 Jul 2004 13:03:42 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Thu, 22 Jul 2004 13:49:53 +1000." <3F8C5F70-01D1-4528-ADD6-37287173E487@mimectl>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> Okay, I have made the following change in dom0:
> To disable the transmit path for guest OSes:
> Edit net_tx_action in arch/xen/drivers/netif/backend/main.c. After the
> call to netif_schedule_work(), add:
>   make_tx_response(netif, txreq.id, NETIF_RSP_OKAY);
>   netif_put(netif);
>   continue;
> compiled and rebooted with the new kernel. booted dom1, removed vif1.0 from 
> the bridge, gave it it's own ip address, added a static arp entry and pinged 
> away. I could see the packet counters for dom0 and dom1 climbing rapiding 
> indicating that dom0 was sending packets, dom1 was receiving packets, but 
> that a packet sent by dom1 was unable to reach dom0 again. I got the same 
> sort of crashes after about 10 minutes.

If you do a test with DPRINTK enabled in
and with debugging enabled in Xen 'debug=y make'
then you may get some useful debugging out of the machine when it all
goes horribly wrong. e.g., perhaps something is failing apparently
spuriously... one example would be that a page reassignment (from dom0
to the other guest) is failing for some weird reason.

If we can get somne debugging out when things first go wrong, that
would be very useful indeed.


This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
Xen-devel mailing list