Re: netfront: rx->offset: 12, size: 4294967295

[Jacek Konieczny <jajcus@jajcus.net>]

On Sun, Jun 03, 2007 at 09:33:59AM +0100, Keir Fraser wrote:
> If you're happy modifying C code a bit, a good place to add some printk()
> tracing would be connect_rings() in drivers/xen/netback/xenbus.c. It's that
> function which should read the request-rx-copy node and decide whether it is
> going to use copying or flipping mode.

Ok, got it. It seems like a bug (feature?) of my compiler (gcc 4.2.0 and
several earlier snapshots of gcc 4.2) or maybe some race condition (is
it possible? anything else writes the netif structure?)

The problem occurs in line 377 of drivers/xen/netback/xenbus.c:

       be->netif->copying_receiver = !!rx_copy;

rx_copy is 1, but copying_receiver is set/left 0 after this instruction.
Using "= rx_copy?1:0" didn't work either. I changed it like this:

diff -dur -x '*~' linux-2.6.18.orig/drivers/xen/netback/xenbus.c linux-2.6.18/drivers/xen/netback/xenbus.c
--- linux-2.6.18.orig/drivers/xen/netback/xenbus.c      2007-06-04 07:48:40.000000000 +0000
+++ linux-2.6.18/drivers/xen/netback/xenbus.c   2007-06-04 11:40:22.000000000 +0000
@@ -374,8 +377,16 @@
                                 dev->otherend);
                return err;
        }
-       be->netif->copying_receiver = !!rx_copy;
-
+       if (rx_copy) {
+               DPRINTK("rx_copy=%u, setting copying_receiver to -1", rx_copy);
+               be->netif->copying_receiver = -1;
+       }
+       else {
+               DPRINTK("rx_copy=%u, setting copying_receiver to 0", rx_copy);
+               be->netif->copying_receiver = 0;
+       }
+       DPRINTK("be->netif->copying_receiver = %i", (int)be->netif->copying_receiver);
+
        if (be->netif->dev->tx_queue_len != 0) {
                if (xenbus_scanf(XBT_NIL, dev->otherend,
                                 "feature-rx-notify", "%d", &val) < 0)



... and the problem is gone. Strange, but good enough for me.

Thank you for your hints.

Greets,
        Jacek