Date: Fri, 6 Apr 2007 12:31:28 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Vladimir Ivanov <wawa@yandex-team.ru> Cc: freebsd-net@freebsd.org Subject: Re: Serious bug in most (?) ethernet drivers (bge, bce, ixgb etc.). Message-ID: <20070406121505.T43678@delplex.bde.org> In-Reply-To: <461549BD.1020800@yandex-team.ru> References: <461549BD.1020800@yandex-team.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 5 Apr 2007, Vladimir Ivanov wrote: > We have reported serious bug with em driver > (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/87418) one year and half > ago. > It's very funny but most freebsd ethernet drivers cloned this bug I seem. > You can see same bug in bce, bge, ixgb and so on. I can only see it in bce and ixgb. bge is much simpler and better -- bge_rxeof() doesn't depend on any state after the unlock/re-lock except the rx indexes, and these are both reset to 0 by reinitialization. However, reinitialization often panics bge_rxeof() anyway. The only reasons for the panics that I can think of is that nothing is declared volatile but the producer index is extremely volatile, so the following races are possible: - compiler caching the indexes. bce implements this as foot-shooting. I think aliasing problems prevent the compiler doing it, so declaring things as volatile would make no difference. - a race with the hardware in initialzation might result in the producer index being nonzero and for old data despite it having been reset to 0 and no new data arriving. Stopping the hardware for initialization should prevent such races. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070406121505.T43678>