>> John Baldwin wrote:
> On Thursday, September 16, 2010 9:02:23 am Marcin Cieslak wrote:
>> Dnia 15.09.2010 John Baldwin napisał/a:
>> > On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote:
>> >> Output queue of tun(4) gets full after some time when sending lots of
>> >> data.
>> >> I
>> John Baldwin wrote:
> Oh, yes. I've updated the patch to remove D_NEEDGIANT.
So far (last 24 hours) my tun(4) with your patch was very stable.
I am updating it to remove D_NEEDGIANT. Thank you!
//Marcin
___
freebsd-current@freebsd.org mailing list
On Thursday, September 16, 2010 9:02:23 am Marcin Cieslak wrote:
> Dnia 15.09.2010 John Baldwin napisał/a:
> > On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote:
> >> Output queue of tun(4) gets full after some time when sending lots of data.
> >> I have been observing this on -CURRENT
Dnia 15.09.2010 John Baldwin napisał/a:
> On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote:
>> Output queue of tun(4) gets full after some time when sending lots of data.
>> I have been observing this on -CURRENT at least since March this year.
>>
>> Looks like it's a race condition
On Wednesday, September 15, 2010 5:57:34 pm Marcin Cieslak wrote:
> Dnia 15.09.2010 John Baldwin napisał/a:
> > On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote:
> >> Output queue of tun(4) gets full after some time when sending lots of data.
> >> I have been observing this on -CURREN
Dnia 15.09.2010 John Baldwin napisał/a:
> On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote:
>> Output queue of tun(4) gets full after some time when sending lots of data.
>> I have been observing this on -CURRENT at least since March this year.
>>
>> Looks like it's a race condition
On Monday, September 13, 2010 9:10:01 pm Marcin Cieslak wrote:
> Output queue of tun(4) gets full after some time when sending lots of data.
> I have been observing this on -CURRENT at least since March this year.
>
> Looks like it's a race condition (same in tun(4) and tap(4)),
> the following p
Output queue of tun(4) gets full after some time when sending lots of data.
I have been observing this on -CURRENT at least since March this year.
Looks like it's a race condition (same in tun(4) and tap(4)),
the following patch seems to address the issue:
Index: if_tap.c
===