Re: problems with em(4) since update to driver 7.2.2

On Thu, May 5, 2011 at 7:21 AM, Arnaud Lacombe <lacombar_at_gmail.com> wrote:

> Hi,
>
> On Thu, May 5, 2011 at 2:59 AM, Jack Vogel <jfvogel_at_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