Date: Thu, 5 May 2011 10:20:03 -0700 From: Jack Vogel <jfvogel@gmail.com> To: Arnaud Lacombe <lacombar@gmail.com> Cc: Olivier Smedts <olivier@gid0.org>, FreeBSD current mailing list <current@freebsd.org> Subject: Re: problems with em(4) since update to driver 7.2.2 Message-ID: <BANLkTimXU3eRTPtUDfxX2FwsJ=uHs3xS3A@mail.gmail.com> In-Reply-To: <BANLkTimVc2Chq9iKrRVCBfqg6WPmt_O=6w@mail.gmail.com> References: <BANLkTinrfZbO%2BMUDDuzsoaN1y-=_O8LgNA@mail.gmail.com> <4D94A354.9080903@sentex.net> <AANLkTik_XPsVWL-KqHkPic1KQ0SdCSk6u_9ykRefi3VE@mail.gmail.com> <BANLkTi=K5ASG9TWLAh5r%2Bzo9Wy1stMf9WA@mail.gmail.com> <BANLkTikPPzxZ6XRAaqrvdeXBp=Ydvz7hNg@mail.gmail.com> <BANLkTi=rhZ0dyO6Zq13jY6-NKVE8n24YyQ@mail.gmail.com> <4DC07013.9070707@gmx.net> <BANLkTi=DmQsVvJOaoxMr5GPOLkjs7sdTxQ@mail.gmail.com> <4DC078BD.9080908@gmx.net> <BANLkTin1ykoo80%2B9iWe%2Bg5ib1DXw%2B05BgQ@mail.gmail.com> <BANLkTi=STPT13-50dxMRgjLP_pyxL9Utyw@mail.gmail.com> <BANLkTikX8gs7Ln2KLZkA=MyieeCR%2BzKXzQ@mail.gmail.com> <BANLkTikj-wSOFWQX9Y_yN54Q_jk-=vD3LA@mail.gmail.com> <BANLkTin0ANtbWGv4CTr%2BO5xEL58hVRDefg@mail.gmail.com> <BANLkTikzpjxe%2BcMYiTRak0B0tnkhrW%2BBow@mail.gmail.com> <BANLkTikUJOD%2BtzYoiHCoWHrD36PxLQgN7A@mail.gmail.com> <BANLkTin2j3QzO0pwVHe9Nm-L8otEf9pcbg@mail.gmail.com> <BANLkTinmKH40yx5Mgu9zgQ2qEF2O-n6HMQ@mail.gmail.com> <BANLkTikehcbxm0MQtb0SQ0giSfhmkHw99A@mail.gmail.com> <BANLkTikkbpW6_jE5QznGjAt4Zcpee0RagQ@mail.gmail.com> <BANLkTimVc2Chq9iKrRVCBfqg6WPmt_O=6w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 5, 2011 at 7:21 AM, Arnaud Lacombe <lacombar@gmail.com> wrote: > Hi, > > On Thu, May 5, 2011 at 2:59 AM, Jack Vogel <jfvogel@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTimXU3eRTPtUDfxX2FwsJ=uHs3xS3A>