This is probably a duplicate of:
https://bugs.launchpad.net/ubuntu/+source/xen-3.3/+bug/154271
I always disable tx checksumming on xen domu's to avoid this problem. I
would be curious to hear from chris lea as to what exactly breaks when
doing this. I have never noticed any problems with incorre
Man, it's been a while since I was actually messing with this, but a LOT
of things stopped working with the checksumming off IIRC. For starters,
while I could scp or ftp a file in and out, the md5 and sha1 sums would
frequently not match when comparing the source and destination files.
MySQL replic
I have a similar/same error with a lenovo s10e and ubuntu 8.10: it uses the tg3
driver for the fast ethernet device:
connecting with ssh to the netbook and starting firefox or other big
application in this shell, produces an
error "Disconnecting: Corrupted MAC on input." and I'm disconnected fro
Jürgen -
Yes, but as noted, doing the
ethtool -K eth0 tx off rx off
trick turns off tcp checksumming, which then causes all manner of other
things to break horribly.
I find it pretty sad that this bug is still here with 8.10 out. This
makes Xen basically unusable for a lot of situations. :(
--
Hi all and Chris,
I don't use Xen, the tg3 driver or something else produces this error, too.
Yesterday I have found out that disabling AND reenabling checksum validation
with
'sudo ethtool -K eth0 tx off rx off; sudo ethtool -K eth0 tx on rx on' fixes
the error, too!
Another notebook (HP 530)
http://bderzhavets.wordpress.com/2008/11/13/backport-intrepid-xen-33
-hypervisor-at-ubuntu-hardy-dom0-2624-21-xen/
--
networking stalls between domU using vif
https://bugs.launchpad.net/bugs/246789
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
This is still a severe problem for me as well. I'm surprised this has
not yet been resolved anywhere. When deploying code to a Ubuntu VM
running on a CentOS 5.3 Xen server, this is the error I get
consistently:
** [blah.com :: out] remote: Compressing objects: 94% (756/804)
** [blah.com :: o
Kernel 2.6.24-21-xen seems to improve things a little bit. I can get a
higher throughput than before without the network stalling, but
definitely when I reach traffic around 6Mbps the network still dies.
Has anything changed in that revision that might have improved things?
--
networking stalls
I was able to do a workaround now. Please do the following on domU and
dom0:
$ aptitude install ethtool
$ ethtool -K eth0 tx off
I found the hint on
http://lists.us.dell.com/pipermail/linux-
poweredge/2008-January/034372.html
Let me now, if that works for you.
--
networking stalls between dom
Yes, I noted originally that this does allow you to move big files
around. However, it causes all sorts of other things to break since TCP
checksumming is needed to make sure all the packets are correct. So it
doesn't effectively leave you with a usable system to do the ethtool
trick.
--
networki
I can hereby confirm this as I am able to reproduce with a current
Ubuntu Hardy. Scp from domU1 to domU2 goes down to a speed of round
abound 10KB/s.
** Changed in: xen-3.2 (Ubuntu)
Status: New => Confirmed
--
networking stalls between domU using vif
https://bugs.launchpad.net/bugs/246789
I have corresponded with one of the Xen devs and he suspects the problem
is in the netfront module. He reviewed the netback module code and it
seemed right to him.
I would hope that Ubuntu devotes a little bit of resources to this issue
since it is biting hard to some people that have deployed Ubu
Hi elventear,
could be more specific please? What exactly did the Xen developer say?
Which code exactly did he review and did he say "yes, the code is the
failure" or "yes, the code is right"? Sorry for the questions but
getting as much information as possible into this ticket will make it
much mo
I am having the same problem with Xen. Have you been able to find any
workarounds?
--
networking stalls between domU using vif
https://bugs.launchpad.net/bugs/246789
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing
I haven't been able to solve this problem but at least mitigate it.
Use the 'rate' directive in the configuration files for all the domUs,
to limit the network rate. I also used Shorewall's QoS to limit the
download traffic to a value lower than our maximum for the public
interface for one of our
I am having the same problem with Xen. Have you been able to find any
workarounds?
--
networking stalls between domU using vif
https://bugs.launchpad.net/bugs/246789
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing
I haven't been able to solve this problem but at least mitigate it.
Use the 'rate' directive in the configuration files for all the domUs,
to limit the network rate. I also used Shorewall's QoS to limit the
download traffic to a value lower than our maximum for the public
interface for one of our
I can hereby confirm this as I am able to reproduce with a current
Ubuntu Hardy. Scp from domU1 to domU2 goes down to a speed of round
abound 10KB/s.
** Changed in: xen-3.2 (Ubuntu)
Status: New => Confirmed
--
networking stalls between domU using vif
https://bugs.launchpad.net/bugs/246789
I have corresponded with one of the Xen devs and he suspects the problem
is in the netfront module. He reviewed the netback module code and it
seemed right to him.
I would hope that Ubuntu devotes a little bit of resources to this issue
since it is biting hard to some people that have deployed Ubu
Hi elventear,
could be more specific please? What exactly did the Xen developer say?
Which code exactly did he review and did he say "yes, the code is the
failure" or "yes, the code is right"? Sorry for the questions but
getting as much information as possible into this ticket will make it
much mo
I was able to do a workaround now. Please do the following on domU and
dom0:
$ aptitude install ethtool
$ ethtool -K eth0 tx off
I found the hint on
http://lists.us.dell.com/pipermail/linux-
poweredge/2008-January/034372.html
Let me now, if that works for you.
--
networking stalls between dom
Yes, I noted originally that this does allow you to move big files
around. However, it causes all sorts of other things to break since TCP
checksumming is needed to make sure all the packets are correct. So it
doesn't effectively leave you with a usable system to do the ethtool
trick.
--
networki
Kernel 2.6.24-21-xen seems to improve things a little bit. I can get a
higher throughput than before without the network stalling, but
definitely when I reach traffic around 6Mbps the network still dies.
Has anything changed in that revision that might have improved things?
--
networking stalls
I have a similar/same error with a lenovo s10e and ubuntu 8.10: it uses the tg3
driver for the fast ethernet device:
connecting with ssh to the netbook and starting firefox or other big
application in this shell, produces an
error "Disconnecting: Corrupted MAC on input." and I'm disconnected fro
Jürgen -
Yes, but as noted, doing the
ethtool -K eth0 tx off rx off
trick turns off tcp checksumming, which then causes all manner of other
things to break horribly.
I find it pretty sad that this bug is still here with 8.10 out. This
makes Xen basically unusable for a lot of situations. :(
--
Hi all and Chris,
I don't use Xen, the tg3 driver or something else produces this error, too.
Yesterday I have found out that disabling AND reenabling checksum validation
with
'sudo ethtool -K eth0 tx off rx off; sudo ethtool -K eth0 tx on rx on' fixes
the error, too!
Another notebook (HP 530)
http://bderzhavets.wordpress.com/2008/11/13/backport-intrepid-xen-33
-hypervisor-at-ubuntu-hardy-dom0-2624-21-xen/
--
networking stalls between domU using vif
https://bugs.launchpad.net/bugs/246789
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
This is probably a duplicate of:
https://bugs.launchpad.net/ubuntu/+source/xen-3.3/+bug/154271
I always disable tx checksumming on xen domu's to avoid this problem. I
would be curious to hear from chris lea as to what exactly breaks when
doing this. I have never noticed any problems with incorre
Man, it's been a while since I was actually messing with this, but a LOT
of things stopped working with the checksumming off IIRC. For starters,
while I could scp or ftp a file in and out, the md5 and sha1 sums would
frequently not match when comparing the source and destination files.
MySQL replic
I have a similar/same error with a lenovo s10e and ubuntu 8.10: it uses the tg3
driver for the fast ethernet device:
connecting with ssh to the netbook and starting firefox or other big
application in this shell, produces an
error "Disconnecting: Corrupted MAC on input." and I'm disconnected fro
Jürgen -
Yes, but as noted, doing the
ethtool -K eth0 tx off rx off
trick turns off tcp checksumming, which then causes all manner of other
things to break horribly.
I find it pretty sad that this bug is still here with 8.10 out. This
makes Xen basically unusable for a lot of situations. :(
--
Hi all and Chris,
I don't use Xen, the tg3 driver or something else produces this error, too.
Yesterday I have found out that disabling AND reenabling checksum validation
with
'sudo ethtool -K eth0 tx off rx off; sudo ethtool -K eth0 tx on rx on' fixes
the error, too!
Another notebook (HP 530)
http://bderzhavets.wordpress.com/2008/11/13/backport-intrepid-xen-33
-hypervisor-at-ubuntu-hardy-dom0-2624-21-xen/
--
networking stalls between domU using vif
https://bugs.launchpad.net/bugs/246789
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
This is probably a duplicate of:
https://bugs.launchpad.net/ubuntu/+source/xen-3.3/+bug/154271
I always disable tx checksumming on xen domu's to avoid this problem. I
would be curious to hear from chris lea as to what exactly breaks when
doing this. I have never noticed any problems with incorre
Man, it's been a while since I was actually messing with this, but a LOT
of things stopped working with the checksumming off IIRC. For starters,
while I could scp or ftp a file in and out, the md5 and sha1 sums would
frequently not match when comparing the source and destination files.
MySQL replic
This is still a severe problem for me as well. I'm surprised this has
not yet been resolved anywhere. When deploying code to a Ubuntu VM
running on a CentOS 5.3 Xen server, this is the error I get
consistently:
** [blah.com :: out] remote: Compressing objects: 94% (756/804)
** [blah.com :: o
I am having the same problem with Xen. Have you been able to find any
workarounds?
--
networking stalls between domU using vif
https://bugs.launchpad.net/bugs/246789
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing
I haven't been able to solve this problem but at least mitigate it.
Use the 'rate' directive in the configuration files for all the domUs,
to limit the network rate. I also used Shorewall's QoS to limit the
download traffic to a value lower than our maximum for the public
interface for one of our
I was able to do a workaround now. Please do the following on domU and
dom0:
$ aptitude install ethtool
$ ethtool -K eth0 tx off
I found the hint on
http://lists.us.dell.com/pipermail/linux-
poweredge/2008-January/034372.html
Let me now, if that works for you.
--
networking stalls between dom
Yes, I noted originally that this does allow you to move big files
around. However, it causes all sorts of other things to break since TCP
checksumming is needed to make sure all the packets are correct. So it
doesn't effectively leave you with a usable system to do the ethtool
trick.
--
networki
I can hereby confirm this as I am able to reproduce with a current
Ubuntu Hardy. Scp from domU1 to domU2 goes down to a speed of round
abound 10KB/s.
** Changed in: xen-3.2 (Ubuntu)
Status: New => Confirmed
--
networking stalls between domU using vif
https://bugs.launchpad.net/bugs/246789
I have corresponded with one of the Xen devs and he suspects the problem
is in the netfront module. He reviewed the netback module code and it
seemed right to him.
I would hope that Ubuntu devotes a little bit of resources to this issue
since it is biting hard to some people that have deployed Ubu
Hi elventear,
could be more specific please? What exactly did the Xen developer say?
Which code exactly did he review and did he say "yes, the code is the
failure" or "yes, the code is right"? Sorry for the questions but
getting as much information as possible into this ticket will make it
much mo
Kernel 2.6.24-21-xen seems to improve things a little bit. I can get a
higher throughput than before without the network stalling, but
definitely when I reach traffic around 6Mbps the network still dies.
Has anything changed in that revision that might have improved things?
--
networking stalls
I was able to do a workaround now. Please do the following on domU and
dom0:
$ aptitude install ethtool
$ ethtool -K eth0 tx off
I found the hint on
http://lists.us.dell.com/pipermail/linux-
poweredge/2008-January/034372.html
Let me now, if that works for you.
--
networking stalls between dom
Yes, I noted originally that this does allow you to move big files
around. However, it causes all sorts of other things to break since TCP
checksumming is needed to make sure all the packets are correct. So it
doesn't effectively leave you with a usable system to do the ethtool
trick.
--
networki
I can hereby confirm this as I am able to reproduce with a current
Ubuntu Hardy. Scp from domU1 to domU2 goes down to a speed of round
abound 10KB/s.
** Changed in: xen-3.2 (Ubuntu)
Status: New => Confirmed
--
networking stalls between domU using vif
https://bugs.launchpad.net/bugs/246789
I have corresponded with one of the Xen devs and he suspects the problem
is in the netfront module. He reviewed the netback module code and it
seemed right to him.
I would hope that Ubuntu devotes a little bit of resources to this issue
since it is biting hard to some people that have deployed Ubu
Hi elventear,
could be more specific please? What exactly did the Xen developer say?
Which code exactly did he review and did he say "yes, the code is the
failure" or "yes, the code is right"? Sorry for the questions but
getting as much information as possible into this ticket will make it
much mo
This is probably a duplicate of:
https://bugs.launchpad.net/ubuntu/+source/xen-3.3/+bug/154271
I always disable tx checksumming on xen domu's to avoid this problem. I
would be curious to hear from chris lea as to what exactly breaks when
doing this. I have never noticed any problems with incorre
Man, it's been a while since I was actually messing with this, but a LOT
of things stopped working with the checksumming off IIRC. For starters,
while I could scp or ftp a file in and out, the md5 and sha1 sums would
frequently not match when comparing the source and destination files.
MySQL replic
I was able to do a workaround now. Please do the following on domU and
dom0:
$ aptitude install ethtool
$ ethtool -K eth0 tx off
I found the hint on
http://lists.us.dell.com/pipermail/linux-
poweredge/2008-January/034372.html
Let me now, if that works for you.
--
networking stalls between dom
Yes, I noted originally that this does allow you to move big files
around. However, it causes all sorts of other things to break since TCP
checksumming is needed to make sure all the packets are correct. So it
doesn't effectively leave you with a usable system to do the ethtool
trick.
--
networki
I can hereby confirm this as I am able to reproduce with a current
Ubuntu Hardy. Scp from domU1 to domU2 goes down to a speed of round
abound 10KB/s.
** Changed in: xen-3.2 (Ubuntu)
Status: New => Confirmed
--
networking stalls between domU using vif
https://bugs.launchpad.net/bugs/246789
I have corresponded with one of the Xen devs and he suspects the problem
is in the netfront module. He reviewed the netback module code and it
seemed right to him.
I would hope that Ubuntu devotes a little bit of resources to this issue
since it is biting hard to some people that have deployed Ubu
Hi elventear,
could be more specific please? What exactly did the Xen developer say?
Which code exactly did he review and did he say "yes, the code is the
failure" or "yes, the code is right"? Sorry for the questions but
getting as much information as possible into this ticket will make it
much mo
I am having the same problem with Xen. Have you been able to find any
workarounds?
--
networking stalls between domU using vif
https://bugs.launchpad.net/bugs/246789
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing
I haven't been able to solve this problem but at least mitigate it.
Use the 'rate' directive in the configuration files for all the domUs,
to limit the network rate. I also used Shorewall's QoS to limit the
download traffic to a value lower than our maximum for the public
interface for one of our
I have a similar/same error with a lenovo s10e and ubuntu 8.10: it uses the tg3
driver for the fast ethernet device:
connecting with ssh to the netbook and starting firefox or other big
application in this shell, produces an
error "Disconnecting: Corrupted MAC on input." and I'm disconnected fro
Jürgen -
Yes, but as noted, doing the
ethtool -K eth0 tx off rx off
trick turns off tcp checksumming, which then causes all manner of other
things to break horribly.
I find it pretty sad that this bug is still here with 8.10 out. This
makes Xen basically unusable for a lot of situations. :(
--
Hi all and Chris,
I don't use Xen, the tg3 driver or something else produces this error, too.
Yesterday I have found out that disabling AND reenabling checksum validation
with
'sudo ethtool -K eth0 tx off rx off; sudo ethtool -K eth0 tx on rx on' fixes
the error, too!
Another notebook (HP 530)
Kernel 2.6.24-21-xen seems to improve things a little bit. I can get a
higher throughput than before without the network stalling, but
definitely when I reach traffic around 6Mbps the network still dies.
Has anything changed in that revision that might have improved things?
--
networking stalls
This is still a severe problem for me as well. I'm surprised this has
not yet been resolved anywhere. When deploying code to a Ubuntu VM
running on a CentOS 5.3 Xen server, this is the error I get
consistently:
** [blah.com :: out] remote: Compressing objects: 94% (756/804)
** [blah.com :: o
http://bderzhavets.wordpress.com/2008/11/13/backport-intrepid-xen-33
-hypervisor-at-ubuntu-hardy-dom0-2624-21-xen/
--
networking stalls between domU using vif
https://bugs.launchpad.net/bugs/246789
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
I am having the same problem with Xen. Have you been able to find any
workarounds?
--
networking stalls between domU using vif
https://bugs.launchpad.net/bugs/246789
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing
I haven't been able to solve this problem but at least mitigate it.
Use the 'rate' directive in the configuration files for all the domUs,
to limit the network rate. I also used Shorewall's QoS to limit the
download traffic to a value lower than our maximum for the public
interface for one of our
I have a similar/same error with a lenovo s10e and ubuntu 8.10: it uses the tg3
driver for the fast ethernet device:
connecting with ssh to the netbook and starting firefox or other big
application in this shell, produces an
error "Disconnecting: Corrupted MAC on input." and I'm disconnected fro
Jürgen -
Yes, but as noted, doing the
ethtool -K eth0 tx off rx off
trick turns off tcp checksumming, which then causes all manner of other
things to break horribly.
I find it pretty sad that this bug is still here with 8.10 out. This
makes Xen basically unusable for a lot of situations. :(
--
Hi all and Chris,
I don't use Xen, the tg3 driver or something else produces this error, too.
Yesterday I have found out that disabling AND reenabling checksum validation
with
'sudo ethtool -K eth0 tx off rx off; sudo ethtool -K eth0 tx on rx on' fixes
the error, too!
Another notebook (HP 530)
http://bderzhavets.wordpress.com/2008/11/13/backport-intrepid-xen-33
-hypervisor-at-ubuntu-hardy-dom0-2624-21-xen/
--
networking stalls between domU using vif
https://bugs.launchpad.net/bugs/246789
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
This is probably a duplicate of:
https://bugs.launchpad.net/ubuntu/+source/xen-3.3/+bug/154271
I always disable tx checksumming on xen domu's to avoid this problem. I
would be curious to hear from chris lea as to what exactly breaks when
doing this. I have never noticed any problems with incorre
Man, it's been a while since I was actually messing with this, but a LOT
of things stopped working with the checksumming off IIRC. For starters,
while I could scp or ftp a file in and out, the md5 and sha1 sums would
frequently not match when comparing the source and destination files.
MySQL replic
This is still a severe problem for me as well. I'm surprised this has
not yet been resolved anywhere. When deploying code to a Ubuntu VM
running on a CentOS 5.3 Xen server, this is the error I get
consistently:
** [blah.com :: out] remote: Compressing objects: 94% (756/804)
** [blah.com :: o
This is still a severe problem for me as well. I'm surprised this has
not yet been resolved anywhere. When deploying code to a Ubuntu VM
running on a CentOS 5.3 Xen server, this is the error I get
consistently:
** [blah.com :: out] remote: Compressing objects: 94% (756/804)
** [blah.com :: o
I was able to do a workaround now. Please do the following on domU and
dom0:
$ aptitude install ethtool
$ ethtool -K eth0 tx off
I found the hint on
http://lists.us.dell.com/pipermail/linux-
poweredge/2008-January/034372.html
Let me now, if that works for you.
--
networking stalls between dom
Yes, I noted originally that this does allow you to move big files
around. However, it causes all sorts of other things to break since TCP
checksumming is needed to make sure all the packets are correct. So it
doesn't effectively leave you with a usable system to do the ethtool
trick.
--
networki
I can hereby confirm this as I am able to reproduce with a current
Ubuntu Hardy. Scp from domU1 to domU2 goes down to a speed of round
abound 10KB/s.
** Changed in: xen-3.2 (Ubuntu)
Status: New => Confirmed
--
networking stalls between domU using vif
https://bugs.launchpad.net/bugs/246789
I have corresponded with one of the Xen devs and he suspects the problem
is in the netfront module. He reviewed the netback module code and it
seemed right to him.
I would hope that Ubuntu devotes a little bit of resources to this issue
since it is biting hard to some people that have deployed Ubu
Hi elventear,
could be more specific please? What exactly did the Xen developer say?
Which code exactly did he review and did he say "yes, the code is the
failure" or "yes, the code is right"? Sorry for the questions but
getting as much information as possible into this ticket will make it
much mo
Kernel 2.6.24-21-xen seems to improve things a little bit. I can get a
higher throughput than before without the network stalling, but
definitely when I reach traffic around 6Mbps the network still dies.
Has anything changed in that revision that might have improved things?
--
networking stalls
I am having the same problem with Xen. Have you been able to find any
workarounds?
--
networking stalls between domU using vif
https://bugs.launchpad.net/bugs/246789
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing
I haven't been able to solve this problem but at least mitigate it.
Use the 'rate' directive in the configuration files for all the domUs,
to limit the network rate. I also used Shorewall's QoS to limit the
download traffic to a value lower than our maximum for the public
interface for one of our
I have a similar/same error with a lenovo s10e and ubuntu 8.10: it uses the tg3
driver for the fast ethernet device:
connecting with ssh to the netbook and starting firefox or other big
application in this shell, produces an
error "Disconnecting: Corrupted MAC on input." and I'm disconnected fro
Jürgen -
Yes, but as noted, doing the
ethtool -K eth0 tx off rx off
trick turns off tcp checksumming, which then causes all manner of other
things to break horribly.
I find it pretty sad that this bug is still here with 8.10 out. This
makes Xen basically unusable for a lot of situations. :(
--
Hi all and Chris,
I don't use Xen, the tg3 driver or something else produces this error, too.
Yesterday I have found out that disabling AND reenabling checksum validation
with
'sudo ethtool -K eth0 tx off rx off; sudo ethtool -K eth0 tx on rx on' fixes
the error, too!
Another notebook (HP 530)
http://bderzhavets.wordpress.com/2008/11/13/backport-intrepid-xen-33
-hypervisor-at-ubuntu-hardy-dom0-2624-21-xen/
--
networking stalls between domU using vif
https://bugs.launchpad.net/bugs/246789
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Kernel 2.6.24-21-xen seems to improve things a little bit. I can get a
higher throughput than before without the network stalling, but
definitely when I reach traffic around 6Mbps the network still dies.
Has anything changed in that revision that might have improved things?
--
networking stalls
This is still a severe problem for me as well. I'm surprised this has
not yet been resolved anywhere. When deploying code to a Ubuntu VM
running on a CentOS 5.3 Xen server, this is the error I get
consistently:
** [blah.com :: out] remote: Compressing objects: 94% (756/804)
** [blah.com :: o
This is probably a duplicate of:
https://bugs.launchpad.net/ubuntu/+source/xen-3.3/+bug/154271
I always disable tx checksumming on xen domu's to avoid this problem. I
would be curious to hear from chris lea as to what exactly breaks when
doing this. I have never noticed any problems with incorre
Man, it's been a while since I was actually messing with this, but a LOT
of things stopped working with the checksumming off IIRC. For starters,
while I could scp or ftp a file in and out, the md5 and sha1 sums would
frequently not match when comparing the source and destination files.
MySQL replic
On Jan 27, 2009, at 7:18 PM, chris lea wrote:
> I find it pretty sad that this bug is still here with 8.10 out. This
> makes Xen basically unusable for a lot of situations. :(
It is such a shame that Ubuntu has decided to not support Xen at all,
specially since currently is the best OSS VM out
On Jan 29, 2009, at 9:29 AM, Todd Deshane wrote:
> http://bderzhavets.wordpress.com/2008/11/13/backport-intrepid-xen-33
> -hypervisor-at-ubuntu-hardy-dom0-2624-21-xen/
I've seen that already. The upgrade was almost painless. xen-utils-3.2
need to be removed before doing an upgrade, or there wil
On Oct 8, 2008, at 3:59 AM, Caspar Clemens Mierau wrote:
> $ aptitude install ethtool
> $ ethtool -K eth0 tx off
That doesn't work for me.
--
networking stalls between domU using vif
https://bugs.launchpad.net/bugs/246789
You received this bug notification because you are a member of Ubuntu
Bug
He reviewed the netback.c code in the latest stable Ubuntu 8.04 kernel
that I pulled for him. This is what he said:
This is what he said:
> Hmmm... It has the patches in that I suspected might be missing. I'm
> at a
> bit of a loss then. I guess I'll diff against our current netback.c
> and
Man, I wish. But thus far no luck.
On Fri, Aug 22, 2008 at 11:54 PM, elventear <[EMAIL PROTECTED]> wrote:
> I am having the same problem with Xen. Have you been able to find any
> workarounds?
>
> --
> networking stalls between domU using vif
> https://bugs.launchpad.net/bugs/246789
> You received
Man, I wish. But thus far no luck.
On Fri, Aug 22, 2008 at 11:54 PM, elventear <[EMAIL PROTECTED]> wrote:
> I am having the same problem with Xen. Have you been able to find any
> workarounds?
>
> --
> networking stalls between domU using vif
> https://bugs.launchpad.net/bugs/246789
> You received
He reviewed the netback.c code in the latest stable Ubuntu 8.04 kernel
that I pulled for him. This is what he said:
This is what he said:
> Hmmm... It has the patches in that I suspected might be missing. I'm
> at a
> bit of a loss then. I guess I'll diff against our current netback.c
> and
On Oct 8, 2008, at 3:59 AM, Caspar Clemens Mierau wrote:
> $ aptitude install ethtool
> $ ethtool -K eth0 tx off
That doesn't work for me.
--
networking stalls between domU using vif
https://bugs.launchpad.net/bugs/246789
You received this bug notification because you are a member of Ubuntu
Bug
On Jan 27, 2009, at 7:18 PM, chris lea wrote:
> I find it pretty sad that this bug is still here with 8.10 out. This
> makes Xen basically unusable for a lot of situations. :(
It is such a shame that Ubuntu has decided to not support Xen at all,
specially since currently is the best OSS VM out
On Jan 29, 2009, at 9:29 AM, Todd Deshane wrote:
> http://bderzhavets.wordpress.com/2008/11/13/backport-intrepid-xen-33
> -hypervisor-at-ubuntu-hardy-dom0-2624-21-xen/
I've seen that already. The upgrade was almost painless. xen-utils-3.2
need to be removed before doing an upgrade, or there wil
1 - 100 of 120 matches
Mail list logo
