Date: Fri, 30 Mar 2018 12:21:50 +0530 From: Reshad Patuck <reshadpatuck1@gmail.com> To: Kristof Provost <kristof@sigsegv.be> Cc: freebsd-net@freebsd.org, "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, Reshad Patuck <reshad@patuck.net> Subject: Re: [vnet] [epair] epair interface stops working after some time Message-ID: <6FF884DA-1AA9-4488-9798-7B16AAFED243@gmail.com> In-Reply-To: <10647168-66DF-48CD-9121-9CC2B00848D4@sigsegv.be> References: <CADaJeD2LZy=RU0vtqD7%2BdkZkUs0GKW%2B7duGDQkZ19GR-_cS=MQ@mail.gmail.com> <71B1A1BD-6FCF-47BB-9523-CCAAC03799A5@sigsegv.be> <1563563.7DUcjoHYMp@reshadlaptop.patuck.net> <C162AFB2-FF80-4640-BDC8-23B30CC22873@sigsegv.be> <1D6101CD-BCB4-4206-838B-1A75152ACCC4@sigsegv.be> <AB52ED81-F97F-471B-A1BA-F3221152A586@patuck.net> <F382A5B4-6941-43C0-9686-4B108034EBF1@patuck.net> <FDCE9FAA-1289-4E15-9239-1B6FD98B589C@sigsegv.be> <38C78C2B-87D2-4225-8F4B-A5EA48BA5D17@patuck.net> <5803CAA2-DC4A-4E49-B715-6DE472088DDD@sigsegv.be> <9CAB4522-0B0A-42BF-B9A4-BF36AFC60286@patuck.net> <7202AFF2-A314-41FE-BD13-C4C77A95E106@sigsegv.be> <2D15ABDE-0C25-4C97-AEA6-0098459A2795@lists.zabbadoz.net> <CEB5C82A-33AA-4F8A-9A80-EC9CBE0300C3@gmail.com> <277350C5-3B1F-4105-AF0A-886B6133218E@sigsegv.be> <97945712-B53E-4CF6-B20E-6001CF40CDFC@gmail.com> <10647168-66DF-48CD-9121-9CC2B00848D4@sigsegv.be>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, I have filed a bug for this issue and cc'd both of you in it=2E https://bugs=2Efreebsd=2Eorg/bugzilla/show_bug=2Ecgi?id=3D227100 Best, Reshad On 29 March 2018 6:39:13 PM IST, Kristof Provost <kristof@sigsegv=2Ebe> wr= ote: >On 29 Mar 2018, at 14:48, Reshad Patuck wrote: >> pulling the 'net=2Elink=2Eepair=2Enetisr_maxqlen' down does seem to mak= e=20 >> this occur faster=2E >> =E2=80=8B >Good, I think my hypothesis about where the issue lies is correct then=2E >You should be able to avoid (or at least reduce the frequency of) the=20 >issue by increasing the value on your system(s)=2E > >> When I dropped it to 2 like Kristof did and I have the same symptoms=20 >> on a box which was not exhibiting the problems manually began to have > >> the same symptoms=2E >> Bumping it back up to 2100 did not restore the functionality (I don't > >> know if it should)=2E >> =E2=80=8B >It=E2=80=99s good to know this=2E It doesn=E2=80=99t surprise me that it = doesn=E2=80=99t fix=20 >things=2E >Something=E2=80=99s wrong in the code which handle an overflow of the net= isr=20 >queue in the epair driver=2E Once that happens the IFF_DRV_OACTIVE flag= =20 >gets set, and we keep enqueuing outside the netisr queue=2E >Somehow we never end up back in epair_nh_drainedcpu(), so the flag >never=20 >gets cleared and the driver never recovers=2E > >> I will create a PR for this later today with all the information I=20 >> have gathered so that we can have it all in one place=2E >> >Thanks=2E Please cc me on it=2E I=E2=80=99ll see if I can figure out what= the=20 >problem is, but we might need someone smarter, so cc Bjoern too=2E > >Regards, >Kristof
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6FF884DA-1AA9-4488-9798-7B16AAFED243>