From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: netfront: rx->offset: 12, size: 4294967295 Date: Mon, 04 Jun 2007 13:52:30 +0100 Message-ID: References: <20070604124040.GC2158@jajo.eggsoft.pl> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20070604124040.GC2158@jajo.eggsoft.pl> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jacek Konieczny , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 4/6/07 13:40, "Jacek Konieczny" wrote: > 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; My suspicion is that, strictly speaking, the assignment of 1 to copying_receiver is invalid because a single-bit bitfield can only hold the values -1 and 0. Older gcc perhaps mapped 1 to -1, but 4.2.0 is mapping 1 to 0 (or choosing to do that as an optimisation, since it has the choice, and hence can simplify the code to always write zero in this case). That sucks. Can you try changing the definition of copying_receiver in netback/common.h to be 'unsigned copying_receiver:1' instead of int:1? -- Keir