Re: 80211s HWMP problem
On Thu, Feb 10, 2011 at 12:17 PM, Monthadar Al Jaberi wrote: > On Thu, Feb 10, 2011 at 12:09 PM, Bernhard Schmidt > wrote: >> On Thursday, February 10, 2011 11:42:05 Monthadar Al Jaberi wrote: >>> Okej, I run all four scenarios: >>> >>> 0->2 OK, but the first "ping -c 1" got lost >>> 1->3 OK, >>> 2->0 OK, >>> 3->1 FAIL, works after "ping -c 1" 1->2 >>> >>> looks like path is built correct in one way only? :S >> >> I have no clue about the mesh code.. but, that smells like there are a >> few frames discard which are supposed to fill the ARP table. Can I talk >> you into dumping frames on the interfaces to figure out where those >> discards happen? > > please :) Sorry, but what was it you want me to dump? > >> >>> On Thu, Feb 10, 2011 at 11:19 AM, Bernhard Schmidt >> wrote: >>> > On Thursday, February 10, 2011 11:06:41 Monthadar Al Jaberi wrote: >>> >> Hej, wanna check if anyone encountered this problem: >>> >> I setup 4 mesh nodes in a link topology ( 0 <-> 1 <-> 2 <-> 3) >>> >> >>> >> But I cant ping from 3 to 0, or 0 to 3, without first ping between >>> >> the nodes to fill the hwmp route tables. >>> > >>> > Pinging 0 -> 2, 1 -> 3, 2 -> 0 and 3 -> 1 on freshly started nodes >>> > works though? >>> > >>> > -- >>> > Bernhard >> >> -- >> Bernhard >> > > > > -- > //Monthadar Al Jaberi > -- //Monthadar Al Jaberi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/154679: [em] Fatal trap 12: "em1 taskq" only at startup (8.1-RELEASE)
Old Synopsis: [Fatal trap 12] "em1 taskq" only at startup (8.1-RELEASE) New Synopsis: [em] Fatal trap 12: "em1 taskq" only at startup (8.1-RELEASE) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Feb 11 16:06:24 UTC 2011 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=154679 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/154557: [tcp] Freeze tcp-session of the clients, if in the gateway is used quagga
The following reply was made to PR kern/154557; it has been noted by GNATS. From: "Vladislav V. Prodan" To: bug-follo...@freebsd.org, univers...@ukr.net Cc: Subject: Re: kern/154557: [tcp] Freeze tcp-session of the clients, if in the gateway is used quagga Date: Fri, 11 Feb 2011 20:31:03 +0200 Put in mpd.conf option: set iface enable tcpmssfix and it worked. -- Vladislav V. Prodan VVP24-UANIC +38[067]4584408 +38[099]4060508 vla...@jabber.ru ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: igb driver RX (was TX) hangs when out of mbuf clusters
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:
>
> > 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?
> That was the test case I created: I set up a server accepting connections
> but not reading anything. So the driver passes the mbufs to the transport
> stack and they are not consumed. Then the problem occurs. Then I kill the
> server. Now there are mbufs available again, but the driver doesn't know.
>
> I had the impression that these were the circumstances in which the problem
> showed up (mbuf allocations failing).
> >
> > Since you can reproduce it, do me a favor, in rxeof, change the
> processed
> > value from 8 to 4 and then 1, effectively call refresh every descriptor,
> see if
> > that eliminates the issue.
> I will do. Need to see if I can do it remotely, since I'm not in my lab
> right now. Can do it tomorrow for sure.
>
> But I do not think that this solves the problem, since I did the things
> very slowly and you call it at least when you are leaving rxeof.
>
> Best regards
> Michael
> >
> > Thanks for your help,
> >
> > Jack
> >
> >
> > On Wed, Feb 9, 2011 at 2:36 AM, Michael Tuexen
> wrote:
> > 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.
> >
> > Now outside of the driver, at some point of time, clusters are freed.
> > I don't think that igb_refresh_mbufs() gets called, since it only gets
> > called from igb_rxeof(), which gets called when a packet has been
> received,
> > which can not happen since the receive ring is empty. So how can the
> driver
> > know? I have no idea. Maybe we can periodically check for such an event
> > and call igb_refresh_mbufs().
> >
> > Does this make sense to you?
> >
> > Best regards
> > Michael
> >
> >
> > On Feb 9, 2011, at 8:32 AM, Jack Vogel wrote:
> >
> > > 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 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 comfortable
> > > with the code changes, nor convinced that it was a real issue and not a
> misunderstanding.
> > > However I think now that this very report might be behind what we are
> seeing today. I have
> > > a slightly different approach to solving it, of course it remains to be
> seen if it handles it
> > > properly.
> > >
> > > Please try the patch I've attached, I'm open to further correction or
> polishing of the
> > > changes. And thanks to Beezar for his original report and changes, this
> is not for em,
> > > but if this eliminates the problem its clearly needed in all drivers.
> > >
> > > Jack
> > >
> > >
> > > Hi Jack,
> > >
> > > Thanks for your help. I tried your patch and it didn't work so I added
> a couple of printf to see if the added code was getting hit:
> > >
> > > --- a/freebsd/sys/dev/e1000/if_igb.c
> > > --More--(byte 1253)+++ b/freebsd/sys/dev/e1000/if_igb.c
> > > @@ -612,7 +612,7 @@ igb_attach(device_t dev)
> > > device_get_nameunit(dev));
> > >
> > > INIT_DEBUGOUT("igb_attach: end");
> > > -
> > > + printf("this driver has a patch from Jack Vogel\n");
> > > return (0);
> > >
> > > err_late:
> > > @@ -4131,6 +4131,7 @@ igb_rxeof(struct igb_queue *que, int count, int
> *done)
> > > struct mbuf *sendmp, *mh, *mp;
> > > struct igb_rx_buf *rxbuf;
> > > u16 hlen, plen, hdr, vtag;
> > > + int commit;
> > > booleop = FALSE;
> > >
> > > cur = &rxr->rx_base[i];
> > > @@ -4255,10 +4256,23 @@ next_desc:
> > > bus_dmamap_sync(rxr->rxdma.dma_tag, rxr->rxdma.dma_map,
> > > BUS_DMASYNC_PREREAD | BUS_DMASYNC_PREWRITE);
> > >
> > > + commit = i; /* capture the old index */
> > > +
> > > /* Advance our pointers to the next descriptor. *
Re: igb driver RX (was TX) hangs when out of mbuf clusters
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 (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:
>>
>> > 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?
>> That was the test case I created: I set up a server accepting connections
>> but not reading anything. So the driver passes the mbufs to the transport
>> stack and they are not consumed. Then the problem occurs. Then I kill the
>> server. Now there are mbufs available again, but the driver doesn't know.
>>
>> I had the impression that these were the circumstances in which the
>> problem
>> showed up (mbuf allocations failing).
>> >
>> > Since you can reproduce it, do me a favor, in rxeof, change the
>> processed
>> > value from 8 to 4 and then 1, effectively call refresh every descriptor,
>> see if
>> > that eliminates the issue.
>> I will do. Need to see if I can do it remotely, since I'm not in my lab
>> right now. Can do it tomorrow for sure.
>>
>> But I do not think that this solves the problem, since I did the things
>> very slowly and you call it at least when you are leaving rxeof.
>>
>> Best regards
>> Michael
>> >
>> > Thanks for your help,
>> >
>> > Jack
>> >
>> >
>> > On Wed, Feb 9, 2011 at 2:36 AM, Michael Tuexen
>> wrote:
>> > 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.
>> >
>> > Now outside of the driver, at some point of time, clusters are freed.
>> > I don't think that igb_refresh_mbufs() gets called, since it only gets
>> > called from igb_rxeof(), which gets called when a packet has been
>> received,
>> > which can not happen since the receive ring is empty. So how can the
>> driver
>> > know? I have no idea. Maybe we can periodically check for such an event
>> > and call igb_refresh_mbufs().
>> >
>> > Does this make sense to you?
>> >
>> > Best regards
>> > Michael
>> >
>> >
>> > On Feb 9, 2011, at 8:32 AM, Jack Vogel wrote:
>> >
>> > > 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 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 comfortable
>> > > with the code changes, nor convinced that it was a real issue and not
>> a misunderstanding.
>> > > However I think now that this very report might be behind what we are
>> seeing today. I have
>> > > a slightly different approach to solving it, of course it remains to
>> be seen if it handles it
>> > > properly.
>> > >
>> > > Please try the patch I've attached, I'm open to further correction or
>> polishing of the
>> > > changes. And thanks to Beezar for his original report and changes,
>> this is not for em,
>> > > but if this eliminates the problem its clearly needed in all drivers.
>> > >
>> > > Jack
>> > >
>> > >
>> > > Hi Jack,
>> > >
>> > > Thanks for your help. I tried your patch and it didn't work so I added
>> a couple of printf to see if the added code was getting hit:
>> > >
>> > > --- a/freebsd/sys/dev/e1000/if_igb.c
>> > > --More--(byte 1253)+++ b/freebsd/sys/dev/e1000/if_igb.c
>> > > @@ -612,7 +612,7 @@ igb_attach(device_t dev)
>> > > device_get_nameunit(dev));
>> > >
>> > > INIT_DEBUGOUT("igb_attach: end");
>> > > -
>> > > + printf("this driver has a patch from Jack Vogel\n");
>> > > return (0);
>> > >
>> > > err_late:
>> > > @@ -4131,6 +4131,7 @@ igb_rxeof(struct igb_queue *que, int count, int
>> *done)
>> > > struct mbuf *sendmp, *mh, *mp;
>> > > struct igb_rx_buf *rxbuf;
>> > > u16 hlen, plen, hdr, vtag;
>> > > + int commit;
>> > > boole
Re: igb driver RX (was TX) hangs when out of mbuf clusters
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.
>
> 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 (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:
>>>
>>> > 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?
>>> That was the test case I created: I set up a server accepting connections
>>> but not reading anything. So the driver passes the mbufs to the transport
>>> stack and they are not consumed. Then the problem occurs. Then I kill the
>>> server. Now there are mbufs available again, but the driver doesn't know.
>>>
>>> I had the impression that these were the circumstances in which the
>>> problem
>>> showed up (mbuf allocations failing).
>>> >
>>> > Since you can reproduce it, do me a favor, in rxeof, change the
>>> processed
>>> > value from 8 to 4 and then 1, effectively call refresh every
>>> descriptor, see if
>>> > that eliminates the issue.
>>> I will do. Need to see if I can do it remotely, since I'm not in my lab
>>> right now. Can do it tomorrow for sure.
>>>
>>> But I do not think that this solves the problem, since I did the things
>>> very slowly and you call it at least when you are leaving rxeof.
>>>
>>> Best regards
>>> Michael
>>> >
>>> > Thanks for your help,
>>> >
>>> > Jack
>>> >
>>> >
>>> > On Wed, Feb 9, 2011 at 2:36 AM, Michael Tuexen
>>> wrote:
>>> > 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.
>>> >
>>> > Now outside of the driver, at some point of time, clusters are freed.
>>> > I don't think that igb_refresh_mbufs() gets called, since it only gets
>>> > called from igb_rxeof(), which gets called when a packet has been
>>> received,
>>> > which can not happen since the receive ring is empty. So how can the
>>> driver
>>> > know? I have no idea. Maybe we can periodically check for such an event
>>> > and call igb_refresh_mbufs().
>>> >
>>> > Does this make sense to you?
>>> >
>>> > Best regards
>>> > Michael
>>> >
>>> >
>>> > On Feb 9, 2011, at 8:32 AM, Jack Vogel wrote:
>>> >
>>> > > 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 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 comfortable
>>> > > with the code changes, nor convinced that it was a real issue and not
>>> a misunderstanding.
>>> > > However I think now that this very report might be behind what we are
>>> seeing today. I have
>>> > > a slightly different approach to solving it, of course it remains to
>>> be seen if it handles it
>>> > > properly.
>>> > >
>>> > > Please try the patch I've attached, I'm open to further correction or
>>> polishing of the
>>> > > changes. And thanks to Beezar for his original report and changes,
>>> this is not for em,
>>> > > but if this eliminates the problem its clearly needed in all drivers.
>>> > >
>>> > > Jack
>>> > >
>>> > >
>>> > > Hi Jack,
>>> > >
>>> > > Thanks for your help. I tried your patch and it didn't work so I
>>> added a couple of printf to see if the added code was getting hit:
>>> > >
>>> > > --- a/freebsd/sys/dev/e1000/if_igb.c
>>> > > --More--(byte 1253)+++ b/freebsd/sys/dev/e1000/if_igb.c
>>> > > @@ -612,7 +612,7 @@ igb_attach(device_t dev)
>>> > > device_get_nameunit(dev));
>>> > >
>>> > > INIT_DEBUGOUT("igb_attach: end");
>>> > > -
>>> > > + printf("this driver has a patch from Jack Vogel\n");
>>> > > return (0);
>>> > >
>>> > > err_late:
>>> > > @@ -4131,6 +4131,7 @@ igb_rxeof(struct igb_queue *que, int count, int
>>> *done
Re: Re: igb driver RX (was TX) hangs when out of mbuf clusters
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> wrote: > >> 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. >> I think it's r218583 that is trying to fix the issue. :) Jack, did you try the fix in PR kern/150516, I think it's better to handle some corner cases, such as mbuf shortage, NIC re-initialization... Thanks! Beezar __ 赶快注册雅虎超大容量免费邮箱? http://cn.mail.yahoo.com ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
