diff --git a/debian/changelog b/debian/changelog
index 33a64cc03..5d3ede56e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -24,6 +24,7 @@ linux-2.6 (2.6.32-12) UNRELEASED; urgency=low
   * megaraid_sas: Fix copying of sense data for 32-bit management tools on
     64-bit kernel (Closes: #578398)
   * Add ipheth driver for iPhone tethering
+  * virtio_net: Make delayed refill more reliable (Closes: #576838)
 
   [ maximilian attems]
   * [ia64] Built in fbcon.
diff --git a/debian/patches/bugfix/all/virtio_net-Make-delayed-refill-more-reliable.patch b/debian/patches/bugfix/all/virtio_net-Make-delayed-refill-more-reliable.patch
new file mode 100644
index 000000000..104509ca8
--- /dev/null
+++ b/debian/patches/bugfix/all/virtio_net-Make-delayed-refill-more-reliable.patch
@@ -0,0 +1,50 @@
+From 39d321577405e8e269fd238b278aaf2425fa788a Mon Sep 17 00:00:00 2001
+From: Herbert Xu <herbert@gondor.apana.org.au>
+Date: Mon, 25 Jan 2010 15:51:01 -0800
+Subject: [PATCH] virtio_net: Make delayed refill more reliable
+
+I have seen RX stalls on a machine that experienced a suspected
+OOM.  After the stall, the RX buffer is empty on the guest side
+and there are exactly 16 entries available on the host side.  As
+the number of entries is less than that required by a maximal
+skb, the host cannot proceed.
+
+The guest did not have a refill job scheduled.
+
+My diagnosis is that an OOM had occured, with the delayed refill
+job scheduled.  The job was able to allocate at least one skb, but
+not enough to overcome the minimum required by the host to proceed.
+
+As the refill job would only reschedule itself if it failed completely
+to allocate any skbs, this would lead to an RX stall.
+
+The following patch removes this stall possibility by always
+rescheduling the refill job until the ring is totally refilled.
+
+Testing has shown that the RX stall no longer occurs whereas
+previously it would occur within a day.
+
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Acked-by: Rusty Russell <rusty@rustcorp.com.au>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+---
+ drivers/net/virtio_net.c |    3 +--
+ 1 files changed, 1 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
+index c708ecc..9ead30b 100644
+--- a/drivers/net/virtio_net.c
++++ b/drivers/net/virtio_net.c
+@@ -395,8 +395,7 @@ static void refill_work(struct work_struct *work)
+ 
+ 	vi = container_of(work, struct virtnet_info, refill.work);
+ 	napi_disable(&vi->napi);
+-	try_fill_recv(vi, GFP_KERNEL);
+-	still_empty = (vi->num == 0);
++	still_empty = !try_fill_recv(vi, GFP_KERNEL);
+ 	napi_enable(&vi->napi);
+ 
+ 	/* In theory, this can happen: if we don't get any buffers in
+-- 
+1.7.0.3
+
diff --git a/debian/patches/series/12 b/debian/patches/series/12
index 63c1e5ef0..a832c8fab 100644
--- a/debian/patches/series/12
+++ b/debian/patches/series/12
@@ -58,3 +58,4 @@
 + bugfix/all/ext4-issue-discard-operation-before-releasing-blocks.patch
 + bugfix/all/libiscsi-regression-fix-header-digest-errors.patch
 + bugfix/all/revert-percpu-stable-changes.patch 
++ bugfix/all/virtio_net-Make-delayed-refill-more-reliable.patch