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 14:09:19 +0100
Cc: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 22 Jul 2004 14:13:04 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Thu, 22 Jul 2004 22:53:49 +1000." <045A665C-DCE2-43E2-BDD3-15B6614BA09C@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
> I am trying this now. Within a few seconds of starting the flood ping,
> dom1 rebooted. no messages in the logs to give any hint as to why
> though. Trying again and I didn't get anything useful either once I
> started getting noticable corruption.

Hmmm.... I guess maybe there's a race somewhere, rather than the
problem being a broken error-handling path. Which is a shame, as it's
bound to be harder to track down. :-(

> just on the subject of page reassignment, I'm trying to figure out
> what the code is doing.
> in netif_be_start_xmit, there is a check to make sure that the packet
> is entirely on 1 page. What happens if the packet is too big for one
> page, or if there is other data on the same page? (it's all black
> magic to me at the moment!)

Unless you're using jumbo Ethernet frames (which you're almost
certainly not) then the packet will certainly fit in a page. We also
check that the packet buffer is at least half a page in size --- since
the slab allocator allocates in powers-of-two, that means the packet
buffer must actually be a full aligned page in size.

If our checks are insufficient and a few packets that are sharing
their data page are getting thru, for example, then we would be pretty
screwed! This might be another area to explore -- whether there are a
few skbuffs coming thru now and then that are of a layout that we 

 -- Keir

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