Date: Thu, 5 May 2011 01:20:30 -0400 From: Arnaud Lacombe <lacombar@gmail.com> To: Jack Vogel <jfvogel@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: <BANLkTinmKH40yx5Mgu9zgQ2qEF2O-n6HMQ@mail.gmail.com> In-Reply-To: <BANLkTin2j3QzO0pwVHe9Nm-L8otEf9pcbg@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>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Wed, May 4, 2011 at 5:38 PM, Jack Vogel <jfvogel@gmail.com> wrote: > I have had my validation engineer busy all day, we have tried both > a 9 kernel as well as 8.2, =A0using the code from HEAD, and we > cannot reproduce this problem. > Actually, it can be trivially reproduced by tainting `error'. As it is uninitialized in HEAD, it's value can be _anything_, so let's mark it as explicitly invalid. diff -u ./if_em.c /data/src/freebsd/em-7.2.2/src/if_em.c --- ./if_em.c 2011-02-18 01:18:23.000000000 -0500 +++ /data/src/freebsd/em-7.2.2/src/if_em.c 2011-05-05 01:12:01.000000000 -0400 @@ -3912,7 +3912,7 @@ struct adapter *adapter =3D rxr->adapter; struct em_buffer *rxbuf; bus_dma_segment_t seg[1]; - int i, j, nsegs, error; + int i, j, nsegs, error =3D -1; The error pointed out in this thread pops up in the next boot. - Arnaud > The data your netstat -m shows suggests to me that what's happening > is somehow setup of the receive ring is running more than once maybe?? > > You asked at one point how this could go into STABLE, well, because > not only here at Intel, but at lots of external customers this code has b= een > used and tested thoroughly. > > I am not calling into question your problem, but until I understand what = it > is I cannot "fix" it :) > > The thing I am guessing right now is the culprit is the setup code, the > reason > is that when I ported to the igb driver I found that it did not work on o= ur > newer > hardware, and so I went back to the older version of setup for igb. Now, > even > though I have not seen hardware fail with em, maybe there is some. > > To help me give me a complete pciconf -lv, and if its a namebrand system > tell me that, including all hardware in it. > > If you like Olivier I can make a version of em for you that also reverts = the > setup code the way I did for igb, see if that fixes it for you? > > Thanks for your patience, > > Jack > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTinmKH40yx5Mgu9zgQ2qEF2O-n6HMQ>