Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Mar 2011 10:19:07 -0400
From:      Arnaud Lacombe <lacombar@gmail.com>
To:        Doug Barton <dougb@freebsd.org>
Cc:        freebsd-net@freebsd.org
Subject:   Re: igb(4) won't start with "igb0: Could not setup receive structures"
Message-ID:  <AANLkTi=z3J2ddUJ%2BcwCD3YWuy8L973k9foC0SQLgTGRC@mail.gmail.com>
In-Reply-To: <4D92BB71.5000900@FreeBSD.org>
References:  <4D923931.2070606@zonov.org> <AANLkTimnnDbtVVaK=yhozEmqxTAp3hudNbEVA6F6pbnq@mail.gmail.com> <4D92BB71.5000900@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

On Wed, Mar 30, 2011 at 1:11 AM, Doug Barton <dougb@freebsd.org> wrote:
> On 03/29/2011 22:07, Arnaud Lacombe wrote:
>>
>> ... or maintain internal changes to the driver to make it not that memor=
y
>> hungry/behave well under memory pressure, especially on system where
>> memory_is_ =A0a constraint.
>
> If you come up with patches, I'm sure everyone would like to see them.
>
No, I came with a patch, Jack sent it explicitly to /dev/null, telling
me that what I was checking was not available in the mode the driver
was in. Then I took the chip documentation, quoted all the chapters
which lead me to believe that what I was checking _was_ available in
the mode the driver was. I never got an answer. Unfortunately, all
these discussion are not publicly available because Jack like doing
things off the list.

The only things I've been able to get from Jack is "We, at Intel, test
em(4) at 256k nmbclusters. We do not have problem. If you have
problem, raise nmbcluster.". 256k nmbcluster in my environment is not
acceptable.

> Meanwhile, there are times where memory IS a constraint, and there are so=
me
> things you can't do without more of it.
>
yes, but the driver should not need a manual reset between the time
resource are (heavily) scarce and the time it became available again.

 - Arnaud



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=z3J2ddUJ%2BcwCD3YWuy8L973k9foC0SQLgTGRC>