Hi Jack,
It would seem I've just been encountering this issue on an `em'
interface as well (chip ID 0x10d38086). The system has been up for a
bit more than a day. netstat(1) list about 2500 clusters allocation
denial. The mentioned interface was unable to receive traffic,
however, it continued to
Hi,
On Wed, Feb 16, 2011 at 2:30 PM, Jack Vogel wrote:
> I've been in email conversation with Beezar, and he's clarified some
> things, I think
> I would like to try his approach to the issue, it will mean one more
> iteration of changes
> to test, would you be willing to do so?
Yes, sure.
- A
Yes.
2011/2/16 Jack Vogel
> I've been in email conversation with Beezar, and he's clarified some
> things, I think
> I would like to try his approach to the issue, it will mean one more
> iteration of changes
> to test, would you be willing to do so? It would be good to know for sure
> if his a
I've been in email conversation with Beezar, and he's clarified some
things, I think
I would like to try his approach to the issue, it will mean one more
iteration of changes
to test, would you be willing to do so? It would be good to know for sure if
his approach
also eliminates the problem.
Jac
Hi Jack,
On Fri, Feb 11, 2011 at 2:57 PM, Jack Vogel wrote:
> Yes, it was the fix for this, Mike has tested and confirmed it eliminates
> the problem, and yes
> I will MFC the relevant bits back to 8 and 7 for you asap.
>
I can confirm this works too. A machine showing the symptoms in a
couple of
On 2011-02-12 03:57:42, Jack Vogel wrote:
>Yes, it was the fix for this, Mike has tested and confirmed it eliminates
>the problem, and yes
>I will MFC the relevant bits back to 8 and 7 for you asap.
>
>Jack
>
>
>On Fri, Feb 11, 2011 at 11:53 AM, Karim Fodil-Lemelin <
>fodillemlinka...@gmail.com> wr
This is great news! Thanks!
Btw we've confirmed that your patch (from current) is indeed working for us
as well.
2011/2/11 Jack Vogel
> Yes, it was the fix for this, Mike has tested and confirmed it eliminates
> the problem, and yes
> I will MFC the relevant bits back to 8 and 7 for you asap.
>
Yes, it was the fix for this, Mike has tested and confirmed it eliminates
the problem, and yes
I will MFC the relevant bits back to 8 and 7 for you asap.
Jack
On Fri, Feb 11, 2011 at 11:53 AM, Karim Fodil-Lemelin <
fodillemlinka...@gmail.com> wrote:
> Hi,
>
> I see a commit was made in current
Hi,
I see a commit was made in current (r218530 | jfv | 2011-02-10 20:00:26
-0500 (Thu, 10 Feb 2011)). Is that commit done to address this issue?
And if so Is there any MFC planned for 7.4 for this?
Thanks,
Karim.
2011/2/9 Michael Tuexen
> On Feb 9, 2011, at 6:35 PM, Jack Vogel wrote:
>
> >
On Feb 9, 2011, at 6:35 PM, Jack Vogel wrote:
> OK, but the question is why does the ring get totally consumed this way, the
> ring has 1024 descriptors, it seems unintuitive that that whole quantity can
> be
> used without some being recharged. Do you see the system mbuf pool being
> depleted at
OK, but the question is why does the ring get totally consumed this way, the
ring has 1024 descriptors, it seems unintuitive that that whole quantity can
be
used without some being recharged. Do you see the system mbuf pool being
depleted at the same time?
Since you can reproduce it, do me a favor
Hi Jack,
I could recreate the problem. When the problem occurs, we see
rx_nxt_check = n
rx_nxt_refresh = n + 1
(This was also reported in a mail from Karim)
This means that the *whole* receive ring has no buffers anymore. This can
occur if, for some amount of time, no clusters are available.
N
Hmmm, well so much for that theory :)
Jack
On Tue, Feb 8, 2011 at 4:06 PM, Karim Fodil-Lemelin <
fodillemlinka...@gmail.com> wrote:
>
>
> 2011/2/8 Jack Vogel
>
>
>> I have been following this, and thinking about it. I still am working from
>> a theoretical
>> standpoint, but based on a patch I
2011/2/8 Jack Vogel
>
> I have been following this, and thinking about it. I still am working from
> a theoretical
> standpoint, but based on a patch I got quite a long time back and never
> quite groked,
> I believe now that I might have a solution.
>
> The original PR and patch was kern/150516
I have been following this, and thinking about it. I still am working from a
theoretical
standpoint, but based on a patch I got quite a long time back and never
quite groked,
I believe now that I might have a solution.
The original PR and patch was kern/150516 from Beezar Liu, I was never
quite c
> 2011/2/8 Michael Tüxen
>
>> On Feb 8, 2011, at 4:29 AM, Karim Fodil-Lemelin wrote:
>>
>> > 2011/2/7 Pyun YongHyeon
>> >
>> >> On Mon, Feb 07, 2011 at 09:21:45PM -0500, Karim Fodil-Lemelin wrote:
>> >>> 2011/2/7 Pyun YongHyeon
>> >>>
>> On Mon, Feb 07, 2011 at 05:33:47PM -0500, Karim Fodil
On Feb 8, 2011, at 4:29 AM, Karim Fodil-Lemelin wrote:
> 2011/2/7 Pyun YongHyeon
>
>> On Mon, Feb 07, 2011 at 09:21:45PM -0500, Karim Fodil-Lemelin wrote:
>>> 2011/2/7 Pyun YongHyeon
>>>
On Mon, Feb 07, 2011 at 05:33:47PM -0500, Karim Fodil-Lemelin wrote:
> Subject: Re: igb driver tx
On Feb 8, 2011, at 10:10 AM, Lev Serebryakov wrote:
> Hello, Karim.
> You wrote 8 февраля 2011 г., 6:29:53:
>
>> Precisely, the exact same behavior happens (RX hang) if options
>> DEVICE_POLLING is _not_ used in the kernel configuration file. I tried with
>> POLLING since someone mentioned that i
Hello, Karim.
You wrote 8 февраля 2011 г., 6:29:53:
> Precisely, the exact same behavior happens (RX hang) if options
> DEVICE_POLLING is _not_ used in the kernel configuration file. I tried with
> POLLING since someone mentioned that it helped in a case mentioned earlier
> today. Unfortunately fo
2011/2/7 Pyun YongHyeon
> On Mon, Feb 07, 2011 at 09:21:45PM -0500, Karim Fodil-Lemelin wrote:
> > 2011/2/7 Pyun YongHyeon
> >
> > > On Mon, Feb 07, 2011 at 05:33:47PM -0500, Karim Fodil-Lemelin wrote:
> > > > Subject: Re: igb driver tx hangs when out of mbuf clusters
> > > >
> > > > > To: Lev S
20 matches
Mail list logo
