From owner-freebsd-current@FreeBSD.ORG Thu May 5 17:20:04 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B9C8106564A for ; Thu, 5 May 2011 17:20:04 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id DBCA58FC13 for ; Thu, 5 May 2011 17:20:03 +0000 (UTC) Received: by qwc9 with SMTP id 9so2063129qwc.13 for ; Thu, 05 May 2011 10:20:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RL5dmUS4lXRGxBzsTuwLyKFsZQeoD8lmUsaR2woquAI=; b=cYz7w10++sU+PDZkULBThO0SSMpyxKSkKeO8jbgCu6Bd1qOw78Mg4YorEK4YIIy38Z VQccHfCCq690M9zod+Z991t4OIe4PjND1/eN9drIZFU8Xr/+gmlpKylYdteHSD3fRbB7 +3SP6TbgqmQ17lJg57CzulYInXKC6oqim61Mg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CgpA6wCJiLarGj90uIfrTMFhtBhob1G4SBoCMv1JCJFFrZMBHeQwIlJgUFDY6kMF9q MOs8LnRXci6SXbMMmgKH7VCn+4gwhsAwdYRFEgiK3YzcYaltMCmriRsl5xGJVlgvqvFp TDQJJEl8sIgHNs5Y73xlqwMByvAMFTMCaMZOE= MIME-Version: 1.0 Received: by 10.52.76.102 with SMTP id j6mr593068vdw.44.1304616003178; Thu, 05 May 2011 10:20:03 -0700 (PDT) Received: by 10.52.184.169 with HTTP; Thu, 5 May 2011 10:20:03 -0700 (PDT) In-Reply-To: References: <4D94A354.9080903@sentex.net> <4DC07013.9070707@gmx.net> <4DC078BD.9080908@gmx.net> Date: Thu, 5 May 2011 10:20:03 -0700 Message-ID: From: Jack Vogel To: Arnaud Lacombe Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Olivier Smedts , FreeBSD current mailing list Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2011 17:20:04 -0000 On Thu, May 5, 2011 at 7:21 AM, Arnaud Lacombe wrote: > Hi, > > On Thu, May 5, 2011 at 2:59 AM, Jack Vogel wrote: > > OK, but what this does not explain is why I do not see this if > > its so easily reproduced, what causes the failure case, any idea? > > > It is completely random as it depends on the content of the stack. I > spent 3 or 4 hours trying to reproduce it using different approach on > different platform, with different version of the code and failed. And > once `error' was explicitly colored, it popped up. That's the beauty > of error related with uninitialized variable. > > - Arnaud > > > As I said, given the code was not feasible for igb anyway I would not > > be unhappy about returning to the old way of doing things. > > > I am not sure what you mean by "old way of doing thing", but I'd guess > that the ring only need to be setup on a few occasion, like > initialization and MTU transition. I'm not sure either how other > driver manage their ring. > > The old way was as the code is in igb now, on each entry to this setup it would completely wipe the descriptor memory, then release all mbufs, and initialize from scratch. Its only because of this "lazy" reinit, meaning only the range from next_to_refresh to next_to_check is reset, that this problem can happen. For igb the reason this will not work, is it requires you to set E1000_RDH(i) to next_to_check, and in fact, the hardware prohibits the write, its ALWAYS 0 after a reset. The reason for this is that the hardware wishes to manage the head index and not software. Anyway, I see the problematic code path, its only when you skip the while loop altogether. I'm surprised the compiler did not complain about this, its usually so anal. Jack