WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] segfault in VM


On Jul 21, 2004, at 9:30 AM, Keir Fraser wrote:

To disable networking:
Edit arch/xen/drivers/netif/frontend/main.c. Change netif_init() to
always 'return 0;'.

changing netif_init() so that all the returns are "return 0;" doesn't seem to do much, the VMs still get network access, and everything looks and acts normal and there's still corruption after a few minutes of stress testing and network traffic. (Although it does seem to be network related. It ran for a while with no network traffic and no corruption, and within a minute or two of starting the pings, it started to flake out.)

changing netif_init() so that it immediately does "return 0" runs for a good long time with no corruption, unless you try to send data to one of the vifs, which makes dom0 blow up real good. Running it for a while with just block I/o and ping traffic to dom0 didn't result in any obvious corruption while running, but I did get these messages when I rebooted:

(XEN) (file=/opt/src/xeno/xeno-unstable.bk/xen/include/asm/mm.h, line=215) Unexpected type (saw c0000000 != exp e0000000) for pfn 000032db (XEN) DOM0: (file=memory.c, line=249) Bad page type for pfn 000032db (d0000005)
(XEN) (file=traps.c, line=466) GPF (0004): fc5277c8 -> fc52a094
Kernel panic: Failed to execute MMU updates
 (XEN) Domain 0 shutdown: rebooting machine!

which I've only seen on a reboot when there has been corruption.

disabling the receive path seems to still let packets through and shows signs of corruption, even with very little network traffic. I'm not sure if that's because I have everything doing NAT instead of bridging, although that doesn't really make sense since it's still the same interface and the code looks like it should simply drop the packets...

It's getting late so I'll have to work on disabling the transmit path and working out how to go about testing the blockdev backend tomorrow.

I'll let it run for a while without even up'ing the vifs on the dom0 side, which should preclude any network traffic at all getting to the VMs and see if there's any corruption going on running overnight or longer.

Can anyone else corrupt their systems with no network traffic?

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
"I think that's what they mean by   |
"nickels a day can feed a child."   |       http://www.eff.org/
I thought, "How can food be so      | http://www.anti-dmca.org/
cheap over there?"  It's not, they  |--------------------------
just eat the nickels." -- Peter Nguyen



-------------------------------------------------------
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.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel