Hi, I have a host running Debian Squeeze with Xen 4.0.1 installed from the Debian repository. My host is working fine running 10 domUs, except that after some number of days one or more domUs lose their network interface. In dom0 and domU I''m running kernel 2.6.32-5-xen-amd64 (PV kernel in Debian repo), and interfaces are in a bridged config. When the network dies eth0 in domU is up as well as vif in dom0, but it seems like no unicast packets make it to/from the domU and dom0. I can run wireshark on the dom0 on vif and see packets attempt to be sent to the domU, but I don''t have wireshark installed in the domU to verify what is actually received. The only thing that I can see coming from domU in wireshark is ARP broadcasts and replies are attempted to be sent, but domU never receives them (arp command shows ''incomplete''). The only other odd thing I see is that the load average is 17 or 18 in each affected domU, while normal domUs are 0 load average. Nothing helpful in dmesg. At first I had one domU do this after maybe 30 days uptime. Then another did it about 2 weeks later. Now three of them are doing the same thing 8 days later and all three started at the same time (plus or minus a few minutes?). The only fix seems to be to restart the domU. ifdown/up doesn''t seem to help. Is there any way to figure out why domU never receives unicast packets? Is there any other useful info that I can collect to help track down the cause? Thanks, Nathan _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Mon, Nov 15, 2010 at 8:00 AM, Nathan Friess <nathan@lyryx.com> wrote:> Hi, > > I have a host running Debian Squeeze with Xen 4.0.1 installed from the > Debian repository. My host is working fine running 10 domUs, except that > after some number of days one or more domUs lose their network interface. > In dom0 and domU I''m running kernel 2.6.32-5-xen-amd64 (PV kernel in Debian > repo), and interfaces are in a bridged config. > > When the network dies eth0 in domU is up as well as vif in dom0, but it > seems like no unicast packets make it to/from the domU and dom0. I can run > wireshark on the dom0 on vif and see packets attempt to be sent to the domU, > but I don''t have wireshark installed in the domU to verify what is actually > received. > > The only thing that I can see coming from domU in wireshark is ARP > broadcasts and replies are attempted to be sent, but domU never receives > them (arp command shows ''incomplete''). The only other odd thing I see is > that the load average is 17 or 18 in each affected domU, while normal domUs > are 0 load average. Nothing helpful in dmesg. > > At first I had one domU do this after maybe 30 days uptime. Then another > did it about 2 weeks later. Now three of them are doing the same thing 8 > days later and all three started at the same time (plus or minus a few > minutes?). The only fix seems to be to restart the domU. ifdown/up doesn''t > seem to help. > > Is there any way to figure out why domU never receives unicast packets? Is > there any other useful info that I can collect to help track down the cause? > > Thanks, > > Nathan > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >You need to try and figure out why the load is so often. I have seen many times that when the load goes high, network activity drops. Maybe the server is overloaded? If you have too high IO use, it will start consuming RAM & CPU above what is needed and cause high load. -- Kind Regards Rudi Ahlers SoftDux Website: http://www.SoftDux.com Technical Blog: http://Blog.SoftDux.com Office: 087 805 9573 Cell: 082 554 7532 _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Sun, 2010-11-14 at 23:00 -0700, Nathan Friess wrote:> Hi, > > I have a host running Debian Squeeze with Xen 4.0.1 installed from the > Debian repository. My host is working fine running 10 domUs, except > that after some number of days one or more domUs lose their network > interface. In dom0 and domU I''m running kernel 2.6.32-5-xen-amd64 (PV > kernel in Debian repo), and interfaces are in a bridged config.Just out of curiosity, are you running the kernel from testing or from backports? I recently had some issues with networking in DomU''s running 2.6.36-5.bpo-xen-amd64 over a Debian testing Dom0. Regards, -- Sebastián Cruz default50@gmail.com GPG FP: 5D35 54C4 ABA7 DED9 133F 5272 04F7 13E3 B03D 64C4 _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hello, I''ve got same issues here. My versions are Xen version : ii xen-hypervisor-4.0-amd64 4.0.1-1 The Xen Hypervisor on AMD64 Kernel for dom0 : ii linux-image-2.6.32-bpo.5-xen-amd64 2.6.32-26~bpo50+1 Linux 2.6.32 for 64-bit PCs, Xen dom0 suppor Kernel for domU ii linux-image-2.6.32-bpo.5-amd64 2.6.32-26~bpo50+1 Linux 2.6.32 for 64-bit PCs Sebastian, have you tested with testing kernel for domU/dom0 instead of backports ? Regards Olivier 2010/11/15 Sebastián Cruz <default50@gmail.com>> On Sun, 2010-11-14 at 23:00 -0700, Nathan Friess wrote: > > Hi, > > > > I have a host running Debian Squeeze with Xen 4.0.1 installed from the > > Debian repository. My host is working fine running 10 domUs, except > > that after some number of days one or more domUs lose their network > > interface. In dom0 and domU I''m running kernel 2.6.32-5-xen-amd64 (PV > > kernel in Debian repo), and interfaces are in a bridged config. > > Just out of curiosity, are you running the kernel from testing or from > backports? I recently had some issues with networking in DomU''s running > 2.6.36-5.bpo-xen-amd64 over a Debian testing Dom0. > > Regards, > > -- > Sebastián Cruz > default50@gmail.com > GPG FP: 5D35 54C4 ABA7 DED9 133F 5272 04F7 13E3 B03D 64C4 > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Mon, 2010-11-15 at 14:58 +0100, Olivier Hanesse wrote:> Hello, > > I''ve got same issues here. > > My versions are > > Xen version : > ii xen-hypervisor-4.0-amd64 4.0.1-1 > The Xen Hypervisor on AMD64 > > Kernel for dom0 : > ii linux-image-2.6.32-bpo.5-xen-amd64 2.6.32-26~bpo50+1 > Linux 2.6.32 for 64-bit PCs, Xen dom0 suppor > > Kernel for domU > ii linux-image-2.6.32-bpo.5-amd64 2.6.32-26~bpo50+1 > Linux 2.6.32 for 64-bit PCs > > Sebastian, have you tested with testing kernel for domU/dom0 instead > of backports ?I have Dom0s running testing kernels and since I replaced the DomUs with testing kernels too (instead of backports'') the problem disappeared. Give it a try and tell us if it worked for you too :-)> 2010/11/15 Sebastián Cruz <default50@gmail.com> > On Sun, 2010-11-14 at 23:00 -0700, Nathan Friess wrote: > > Hi, > > > > I have a host running Debian Squeeze with Xen 4.0.1 > installed from the > > Debian repository. My host is working fine running 10 > domUs, except > > that after some number of days one or more domUs lose their > network > > interface. In dom0 and domU I''m running kernel > 2.6.32-5-xen-amd64 (PV > > kernel in Debian repo), and interfaces are in a bridged > config. > > > Just out of curiosity, are you running the kernel from testing > or from > backports? I recently had some issues with networking in > DomU''s running > 2.6.36-5.bpo-xen-amd64 over a Debian testing Dom0.-- Sebastián Cruz default50@gmail.com GPG FP: 5D35 54C4 ABA7 DED9 133F 5272 04F7 13E3 B03D 64C4 _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Sebastián Cruz wrote:> On Mon, 2010-11-15 at 14:58 +0100, Olivier Hanesse wrote: >> Sebastian, have you tested with testing kernel for domU/dom0 instead >> of backports ? > > I have Dom0s running testing kernels and since I replaced the DomUs with > testing kernels too (instead of backports'') the problem disappeared. > Give it a try and tell us if it worked for you too :-)My dom0 is running testing (pure amd64 install). My domUs are actually 32 bit Lenny installs that were copied from another setup, but use the same kernel as dom0. Some additional info: I did get tcpdump installed in one of the "dead" domUs. As I suspected, I don''t see any incoming packets on eth0 at all. So it seems that dom0 isn''t able to send anything to domU, but going outbound might be okay (as the ARP requests are getting out). Nathan _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Rudi Ahlers wrote:> You need to try and figure out why the load is so often. I have seen > many times that when the load goes high, network activity drops. Maybe > the server is overloaded? If you have too high IO use, it will start > consuming RAM & CPU above what is needed and cause high load.Thanks for the suggestion. I did figure out why there was high load. Because the network is down, cfengine in the domU was getting stuck and several cfagent processes were building up. I killed them all off and that brought the load down to 0 again. No change in the networking though, so my guess is that was not a cause, but a result of the network issue. Nathan _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Nathan Friess wrote:> Hi, > > I have a host running Debian Squeeze with Xen 4.0.1 installed from the > Debian repository. My host is working fine running 10 domUs, except > that after some number of days one or more domUs lose their network > interface. In dom0 and domU I''m running kernel 2.6.32-5-xen-amd64 (PV > kernel in Debian repo), and interfaces are in a bridged config. >In case anyone runs into something similar, I did figure out how to resolve my issue without having to reboot the domU... which is a slight improvement I suppose. Running xm network-detach domUName 0 Causes eth0 to disappear in the domain, and the following to show up in dmesg: net eth0: xennet_release_rx_bufs: fix me for copying receiver. Then running an xm network-attach will bring eth0 back and everything will be okay. I also tried rmmoding xen_netfront in domU before I figured out the network-detach, but this doesn''t help. When modprobing again, the domU says "eth0: link is not ready". This also causes any subsequent attempt to network-detach in dom0 to get stuck and eventually timeout with "Device 0 (vif) could not be disconnected." Also, when the vif is stuck, the TX dropped packets shown in dom0 is steadily increasing. It seems that dom0 is having trouble sending packets to domU because one of the two gets stuck in an unexpected state. At least doing a network-detach will reset the state and allow things to run properly again. Nathan _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Nathan
Friess wrote:
Hi,
I have a host running Debian Squeeze with Xen 4.0.1 installed
from the Debian repository. My host is working fine running 10
domUs, except that after some number of days one or more domUs
lose their network interface. In dom0 and domU I''m running
kernel 2.6.32-5-xen-amd64 (PV kernel in Debian repo), and
interfaces are in a bridged config.
In case anyone runs into something similar, I did figure out how
to resolve my issue without having to reboot the domU... which is
a slight improvement I suppose.
Running
xm network-detach domUName 0
Causes eth0 to disappear in the domain, and the following to show
up in dmesg:
net eth0: xennet_release_rx_bufs: fix me for copying receiver.
Then running an xm network-attach will bring eth0 back and
everything will be okay.
I also tried rmmoding xen_netfront in domU before I figured out
the network-detach, but this doesn''t help. When modprobing
again,
the domU says "eth0: link is not ready". This also causes any
subsequent attempt to network-detach in dom0 to get stuck and
eventually timeout with "Device 0 (vif) could not be
disconnected."
Also, when the vif is stuck, the TX dropped packets shown in dom0
is steadily increasing. It seems that dom0 is having trouble
sending packets to domU because one of the two gets stuck in an
unexpected state. At least doing a network-detach will reset the
state and allow things to run properly again.
Nathan
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
I have a similar issue, however my DomU''s seem to get their
connection back after a while automatically, most of the time it
happens when I physically login to the Dom0 :/
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
Le 18/11/2010 19:33, Stein van Oevelen a écrit :> >> Nathan Friess wrote: >>> Hi, >>> >>> I have a host running Debian Squeeze with Xen 4.0.1 installed from >>> the Debian repository. My host is working fine running 10 domUs, >>> except that after some number of days one or more domUs lose their >>> network interface. In dom0 and domU I''m running kernel >>> 2.6.32-5-xen-amd64 (PV kernel in Debian repo), and interfaces are in >>> a bridged config. >>> >> >> In case anyone runs into something similar, I did figure out how to >> resolve my issue without having to reboot the domU... which is a >> slight improvement I suppose. >> >> Running >> xm network-detach domUName 0 >> >> Causes eth0 to disappear in the domain, and the following to show up >> in dmesg: >> >> net eth0: xennet_release_rx_bufs: fix me for copying receiver. >> >> Then running an xm network-attach will bring eth0 back and everything >> will be okay. >> >> I also tried rmmoding xen_netfront in domU before I figured out the >> network-detach, but this doesn''t help. When modprobing again, the >> domU says "eth0: link is not ready". This also causes any subsequent >> attempt to network-detach in dom0 to get stuck and eventually timeout >> with "Device 0 (vif) could not be disconnected." >> >> Also, when the vif is stuck, the TX dropped packets shown in dom0 is >> steadily increasing. It seems that dom0 is having trouble sending >> packets to domU because one of the two gets stuck in an unexpected >> state. At least doing a network-detach will reset the state and >> allow things to run properly again. >> >> Nathan >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xensource.com >> http://lists.xensource.com/xen-users > > I have a similar issue, however my DomU''s seem to get their connection > back after a while automatically, most of the time it happens when I > physically login to the Dom0 :/ > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-usersSame for me, anyone knows if a bug report has been filled somewhere for this ? _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Thu, Nov 18, 2010 at 10:35:46PM +0100, Erwan RENIER wrote:> Le 18/11/2010 19:33, Stein van Oevelen a écrit : > > Nathan Friess wrote: > > Hi, > > I have a host running Debian Squeeze with Xen 4.0.1 installed from > the Debian repository. My host is working fine running 10 domUs, > except that after some number of days one or more domUs lose their > network interface. In dom0 and domU I''m running kernel > 2.6.32-5-xen-amd64 (PV kernel in Debian repo), and interfaces are in > a bridged config. > > In case anyone runs into something similar, I did figure out how to > resolve my issue without having to reboot the domU... which is a > slight improvement I suppose. > > Running > xm network-detach domUName 0 > > Causes eth0 to disappear in the domain, and the following to show up > in dmesg: > > net eth0: xennet_release_rx_bufs: fix me for copying receiver. > > Then running an xm network-attach will bring eth0 back and everything > will be okay. > > I also tried rmmoding xen_netfront in domU before I figured out the > network-detach, but this doesn''t help. When modprobing again, the > domU says "eth0: link is not ready". This also causes any subsequent > attempt to network-detach in dom0 to get stuck and eventually timeout > with "Device 0 (vif) could not be disconnected." > > Also, when the vif is stuck, the TX dropped packets shown in dom0 is > steadily increasing. It seems that dom0 is having trouble sending > packets to domU because one of the two gets stuck in an unexpected > state. At least doing a network-detach will reset the state and allow > things to run properly again. > > Nathan > > _______________________________________________ > Xen-users mailing list > [1]Xen-users@lists.xensource.com > [2]http://lists.xensource.com/xen-users > > I have a similar issue, however my DomU''s seem to get their connection > back after a while automatically, most of the time it happens when I > physically login to the Dom0 :/ > >Are you guys running the latest kernel? This sounds like a bug that was fixed two months ago (or so) in the upstream "xen/stable-2.6.32.x" git branch.. -- Pasi _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hello Pasi, Are you thinking about the smartpoll patch ? * [x86/xen] Disable netfront''s smartpoll mode by default. If so, yes the debian kernel we are using, is fine about this issue. Regards Olivier 2010/11/19 Pasi Kärkkäinen <pasik@iki.fi>> On Thu, Nov 18, 2010 at 10:35:46PM +0100, Erwan RENIER wrote: > > Le 18/11/2010 19:33, Stein van Oevelen a écrit : > > > > Nathan Friess wrote: > > > > Hi, > > > > I have a host running Debian Squeeze with Xen 4.0.1 installed > from > > the Debian repository. My host is working fine running 10 > domUs, > > except that after some number of days one or more domUs lose > their > > network interface. In dom0 and domU I''m running kernel > > 2.6.32-5-xen-amd64 (PV kernel in Debian repo), and interfaces > are in > > a bridged config. > > > > In case anyone runs into something similar, I did figure out how > to > > resolve my issue without having to reboot the domU... which is a > > slight improvement I suppose. > > > > Running > > xm network-detach domUName 0 > > > > Causes eth0 to disappear in the domain, and the following to show > up > > in dmesg: > > > > net eth0: xennet_release_rx_bufs: fix me for copying receiver. > > > > Then running an xm network-attach will bring eth0 back and > everything > > will be okay. > > > > I also tried rmmoding xen_netfront in domU before I figured out > the > > network-detach, but this doesn''t help. When modprobing again, the > > domU says "eth0: link is not ready". This also causes any > subsequent > > attempt to network-detach in dom0 to get stuck and eventually > timeout > > with "Device 0 (vif) could not be disconnected." > > > > Also, when the vif is stuck, the TX dropped packets shown in dom0 > is > > steadily increasing. It seems that dom0 is having trouble sending > > packets to domU because one of the two gets stuck in an unexpected > > state. At least doing a network-detach will reset the state and > allow > > things to run properly again. > > > > Nathan > > > > _______________________________________________ > > Xen-users mailing list > > [1]Xen-users@lists.xensource.com > > [2]http://lists.xensource.com/xen-users > > > > I have a similar issue, however my DomU''s seem to get their > connection > > back after a while automatically, most of the time it happens when I > > physically login to the Dom0 :/ > > > > > > > Are you guys running the latest kernel? > > This sounds like a bug that was fixed two months ago (or so) > in the upstream "xen/stable-2.6.32.x" git branch.. > > -- Pasi > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Fri, Nov 19, 2010 at 10:27:05AM +0100, Olivier Hanesse wrote:> Hello Pasi, > > Are you thinking about the smartpoll patch ? > > * [x86/xen] Disable netfront''s smartpoll mode by default. > > If so, yes the debian kernel we are using, is fine about this issue. >Yep, that. Also there was another bug in the dom0 kernel netback driver, but I think that should be fixed if the smartpoll bug is fixed.. unless only the other patch was pulled to Debian kernel.. -- Pasi> Regards > > Olivier > > 2010/11/19 Pasi Kärkkäinen <[1]pasik@iki.fi> > > On Thu, Nov 18, 2010 at 10:35:46PM +0100, Erwan RENIER wrote: > > Le 18/11/2010 19:33, Stein van Oevelen a écrit : > > > > Nathan Friess wrote: > > > > Hi, > > > > I have a host running Debian Squeeze with Xen 4.0.1 installed > from > > the Debian repository. My host is working fine running 10 > domUs, > > except that after some number of days one or more domUs lose > their > > network interface. In dom0 and domU I''m running kernel > > 2.6.32-5-xen-amd64 (PV kernel in Debian repo), and interfaces > are in > > a bridged config. > > > > In case anyone runs into something similar, I did figure out > how to > > resolve my issue without having to reboot the domU... which is > a > > slight improvement I suppose. > > > > Running > > xm network-detach domUName 0 > > > > Causes eth0 to disappear in the domain, and the following to > show up > > in dmesg: > > > > net eth0: xennet_release_rx_bufs: fix me for copying > receiver. > > > > Then running an xm network-attach will bring eth0 back and > everything > > will be okay. > > > > I also tried rmmoding xen_netfront in domU before I figured out > the > > network-detach, but this doesn''t help. When modprobing again, > the > > domU says "eth0: link is not ready". This also causes any > subsequent > > attempt to network-detach in dom0 to get stuck and eventually > timeout > > with "Device 0 (vif) could not be disconnected." > > > > Also, when the vif is stuck, the TX dropped packets shown in > dom0 is > > steadily increasing. It seems that dom0 is having trouble > sending > > packets to domU because one of the two gets stuck in an > unexpected > > state. At least doing a network-detach will reset the state > and allow > > things to run properly again. > > > > Nathan > > > > _______________________________________________ > > Xen-users mailing list > > [1][2]Xen-users@lists.xensource.com > > [2][3]http://lists.xensource.com/xen-users > > > > I have a similar issue, however my DomU''s seem to get their > connection > > back after a while automatically, most of the time it happens > when I > > physically login to the Dom0 :/ > > > > > > Are you guys running the latest kernel? > > This sounds like a bug that was fixed two months ago (or so) > in the upstream "xen/stable-2.6.32.x" git branch.. > > -- Pasi > > _______________________________________________ > Xen-users mailing list > [4]Xen-users@lists.xensource.com > [5]http://lists.xensource.com/xen-users > > References > > Visible links > 1. mailto:pasik@iki.fi > 2. mailto:Xen-users@lists.xensource.com > 3. http://lists.xensource.com/xen-users > 4. mailto:Xen-users@lists.xensource.com > 5. http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hello,
About the netback driver, in Debian Kernel, I can see those :
* xen: Fix crash in netback.
* Update Xen patch.
- Fix checksum offloading in netback.
Olivier
2010/11/19 Pasi Kärkkäinen <pasik@iki.fi>
> On Fri, Nov 19, 2010 at 10:27:05AM +0100, Olivier Hanesse wrote:
> > Hello Pasi,
> >
> > Are you thinking about the smartpoll patch ?
> >
> > * [x86/xen] Disable netfront''s smartpoll mode by default.
> >
> > If so, yes the debian kernel we are using, is fine about this
issue.
> >
>
> Yep, that.
>
> Also there was another bug in the dom0 kernel netback driver,
> but I think that should be fixed if the smartpoll bug is fixed..
>
> unless only the other patch was pulled to Debian kernel..
>
> -- Pasi
>
> > Regards
> >
> > Olivier
> >
> > 2010/11/19 Pasi Kärkkäinen <[1]pasik@iki.fi>
> >
> > On Thu, Nov 18, 2010 at 10:35:46PM +0100, Erwan RENIER wrote:
> > > Le 18/11/2010 19:33, Stein van Oevelen a écrit :
> > >
> > > Nathan Friess wrote:
> > >
> > > Hi,
> > >
> > > I have a host running Debian Squeeze with Xen 4.0.1
> installed
> > from
> > > the Debian repository. My host is working fine
running
> 10
> > domUs,
> > > except that after some number of days one or more
domUs
> lose
> > their
> > > network interface. In dom0 and domU I''m
running kernel
> > > 2.6.32-5-xen-amd64 (PV kernel in Debian repo), and
> interfaces
> > are in
> > > a bridged config.
> > >
> > > In case anyone runs into something similar, I did
figure
> out
> > how to
> > > resolve my issue without having to reboot the domU...
which
> is
> > a
> > > slight improvement I suppose.
> > >
> > > Running
> > > xm network-detach domUName 0
> > >
> > > Causes eth0 to disappear in the domain, and the
following
> to
> > show up
> > > in dmesg:
> > >
> > > net eth0: xennet_release_rx_bufs: fix me for
copying
> > receiver.
> > >
> > > Then running an xm network-attach will bring eth0
back and
> > everything
> > > will be okay.
> > >
> > > I also tried rmmoding xen_netfront in domU before I
figured
> out
> > the
> > > network-detach, but this doesn''t help. When
modprobing
> again,
> > the
> > > domU says "eth0: link is not ready". This
also causes any
> > subsequent
> > > attempt to network-detach in dom0 to get stuck and
> eventually
> > timeout
> > > with "Device 0 (vif) could not be
disconnected."
> > >
> > > Also, when the vif is stuck, the TX dropped packets
shown
> in
> > dom0 is
> > > steadily increasing. It seems that dom0 is having
trouble
> > sending
> > > packets to domU because one of the two gets stuck in
an
> > unexpected
> > > state. At least doing a network-detach will reset
the
> state
> > and allow
> > > things to run properly again.
> > >
> > > Nathan
> > >
> > > _______________________________________________
> > > Xen-users mailing list
> > > [1][2]Xen-users@lists.xensource.com
> > > [2][3]http://lists.xensource.com/xen-users
> > >
> > > I have a similar issue, however my DomU''s seem
to get their
> > connection
> > > back after a while automatically, most of the time it
happens
> > when I
> > > physically login to the Dom0 :/
> > >
> > >
> >
> > Are you guys running the latest kernel?
> >
> > This sounds like a bug that was fixed two months ago (or so)
> > in the upstream "xen/stable-2.6.32.x" git branch..
> >
> > -- Pasi
> >
> > _______________________________________________
> > Xen-users mailing list
> > [4]Xen-users@lists.xensource.com
> > [5]http://lists.xensource.com/xen-users
> >
> > References
> >
> > Visible links
> > 1. mailto:pasik@iki.fi
> > 2. mailto:Xen-users@lists.xensource.com
> > 3. http://lists.xensource.com/xen-users
> > 4. mailto:Xen-users@lists.xensource.com
> > 5. http://lists.xensource.com/xen-users
>
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users