|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] segfault in VM
At this stage, it looks like disabling the receive path for the guest os eg netif_be_start_xmit 'goto drop' means that I can ping from the guest OS all i like with no crashes. I hope that's the right way around to do it...
I'm just looking at that procedure, how is the ring actually managed - what do all the _prod and _cons variables actually represent? And how is synchronisation handled between the domains? i notice there is no spinlock in there, is this done by the calling function?
james
From: Keir Fraser Sent: Thu 22/07/2004 12:17 AM To: James Harper Cc: Keir Fraser; xen-devel@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [Xen-devel] segfault in VM That would be extremely helpful! If it turns out to be the net backend (probably most likely, although I guess it may not be a backend problem at all, which would be harder to debug), then we can isolate it to the receive or transmit path as follows: To disable the receive path for guest OSes: Edit netif_be_start_xmit in arch/xen/drivers/netif/backend/main.c to always 'goto drop;'. 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; With one half of the network path disabled, to load up the remaining direction you'll need to flood ping from an external machine to the guest OS (when you disable the guest's transmit path) or flood ping out from the guest (when you disable it's rx path). I guess in both cases you'll need a broadcast ping (yuk!) since ARP won't work (needs both tx and rx). -- Keir > i'll try this out tomorrow morning (too late tonight - need sleep!) > > > > From: Keir Fraser > Sent: Wed 21/07/2004 11:30 PM > To: James Harper > Cc: Keir Fraser; xen-devel@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: [Xen-devel] segfault in VM > > > Could someone try to isolate this to either the network backend driver > or the blkdev backend driver? > > The best way to do this is to disable the frontend drivers so that > they never try to coinnect to the backend driver... > > To disable networking: > Edit arch/xen/drivers/netif/frontend/main.c. Change netif_init() to > always 'return 0;'. > > To disable block devices: > Edit arch/xen/drivers/blkif/frontend/main.c. Change xlblk_init() to > always 'return 0;'. > > Oh yes -- the 2.4 sparse tree no longer contains the net frontend > driver - you'll find the build tree symlinks to > linux-2.6.7-xen-sparse/drivers/xen/net/network.c. So you might want to > edit that instead... > > Obviously, if you disable blkdevs you'll need to boot off a ramdisk > or via a networked mount. :-) > > Cheers, > Keir > > > > I downloaded these (from a tgz that Keir had given me a link to as bk was down - I assume it's identical to his latest fixes) and started my tests running and went to bed, but it looks like I got errors within a very short time. > > The tests I was running were my 'compare' script and pinging the two domains I had running with > > ping -q -i 0.01 -s 1400 <ip address> > > > > Lots of oopses in the logs, most are probably as a result of the corruption and not indicative of the cause. They look similar to Jody's dump so I won't bother sending them unless someone thinks they might be useful. > > > > btw, can the install be modified to give us a System.map-2.4.26-xen[0U] in /boot? ksymoops would be much happier. > > > > James -=- MIME -=- --_AD96A7AB-04BB-40C1-819D-80A6B56655A4_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable i'll try this out tomorrow morning (too late tonight - need sleep!) From: Keir Fraser Sent: Wed 21/07/2004 11:30 PM To: James Harper Cc: Keir Fraser; xen-devel@xxxxxxxxxxxxxxxxxxxxx Subject: Re: [Xen-devel] segfault in VM Could someone try to isolate this to either the network backend driver or the blkdev backend driver? The best way to do this is to disable the frontend drivers so that they never try to coinnect to the backend driver... To disable networking: Edit arch/xen/drivers/netif/frontend/main.c. Change netif_init() to always 'return 0;'. To disable block devices: Edit arch/xen/drivers/blkif/frontend/main.c. Change xlblk_init() to always 'return 0;'. Oh yes -- the 2.4 sparse tree no longer contains the net frontend driver - you'll find the build tree symlinks to linux-2.6.7-xen-sparse/drivers/xen/net/network.c. So you might want to edit that instead... Obviously, if you disable blkdevs you'll need to boot off a ramdisk or via a networked mount. :-) Cheers, Keir > I downloaded these (from a tgz that Keir had given me a link to as bk was= down - I assume it's identical to his latest fixes) and started my tests r= unning and went to bed, but it looks like I got errors within a very short = time. > The tests I was running were my 'compare' script and pinging the two doma= ins I had running with > ping -q -i 0.01 -s 1400 <ip address> >=20 > Lots of oopses in the logs, most are probably as a result of the corrupti= on and not indicative of the cause. They look similar to Jody's dump so I w= on't bother sending them unless someone thinks they might be useful. >=20 > btw, can the install be modified to give us a System.map-2.4.26-xen[0U] i= n /boot? ksymoops would be much happier. >=20 > James --_AD96A7AB-04BB-40C1-819D-80A6B56655A4_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML><HEAD></HEAD> <BODY> <DIV id=3DidOWAReplyText57341 dir=3Dltr> <DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>i'll try this ou= t tomorrow morning (too late tonight - need sleep!)</FONT></DIV></DIV> <DIV dir=3Dltr><BR> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Keir Fraser<BR><B>Sent:</B> Wed 2= 1/07/2004 11:30 PM<BR><B>To:</B> James Harper<BR><B>Cc:</B> Keir Fraser; xe= n-devel@xxxxxxxxxxxxxxxxxxxxx<BR><B>Subject:</B> Re: [Xen-devel] segfault i= n VM<BR></FONT><BR></DIV> <DIV><PRE style=3D"WORD-WRAP: break-word">Could someone try to isolate this= to either the network backend driver or the blkdev backend driver? The best way to do this is to disable the frontend drivers so that they never try to coinnect to the backend driver... To disable networking: Edit arch/xen/drivers/netif/frontend/main.c. Change netif_init() to always 'return 0;'. To disable block devices: Edit arch/xen/drivers/blkif/frontend/main.c. Change xlblk_init() to always 'return 0;'. Oh yes -- the 2.4 sparse tree no longer contains the net frontend driver - you'll find the build tree symlinks to linux-2.6.7-xen-sparse/drivers/xen/net/network.c. So you might want to edit that instead... Obviously, if you disable blkdevs you'll need to boot off a ramdisk or via a networked mount. :-) Cheers, Keir > I downloaded these (from a tgz that Keir had given me a link to as bk = was down - I assume it's identical to his latest fixes) and started my test= s running and went to bed, but it looks like I got errors within a very sho= rt time. > The tests I was running were my 'compare' script and pinging the two d= omains I had running with > ping -q -i 0.01 -s 1400 <ip address> >=20 > Lots of oopses in the logs, most are probably as a result of the corru= ption and not indicative of the cause. They look similar to Jody's dump so = I won't bother sending them unless someone thinks they might be useful. >=20 > btw, can the install be modified to give us a System.map-2.4.26-xen[0U= ] in /boot? ksymoops would be much happier. >=20 > James </PRE></DIV></BODY></HTML> --_AD96A7AB-04BB-40C1-819D-80A6B56655A4_--
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |