Hi Slawa,
On 10/11/16 2:11 PM, Slawa Olhovchenkov wrote:
> On Tue, Oct 11, 2016 at 09:20:17AM +0200, Julien Charbon wrote:
>> Then threads are competing for the INP_WLOCK lock. For the example,
>> let's say the thread A wants to run tcp_input()/in_pcblookup_mbuf() and
>> racing for this INP_WL
On Wed, Oct 12, 2016 at 10:18:18AM +0200, Julien Charbon wrote:
>
> Hi Slawa,
>
> On 10/11/16 2:11 PM, Slawa Olhovchenkov wrote:
> > On Tue, Oct 11, 2016 at 09:20:17AM +0200, Julien Charbon wrote:
> >> Then threads are competing for the INP_WLOCK lock. For the example,
> >> let's say the thre
On Wed, Oct 12, 2016 at 11:19:48AM +0200, Julien Charbon wrote:
> > if INP_WLOCK is like spinlock -- this is dead lock.
> > if INP_WLOCK is like mutex -- thread1 resheduled.
>
> Thanks, I understand you question now. No an interrupt cannot bypass a
> lock: Here INP_WLOCK is like mutex -- threa
On 10/12/16 11:29 AM, Slawa Olhovchenkov wrote:
> On Wed, Oct 12, 2016 at 11:19:48AM +0200, Julien Charbon wrote:
>
>>> if INP_WLOCK is like spinlock -- this is dead lock.
>>> if INP_WLOCK is like mutex -- thread1 resheduled.
>>
>> Thanks, I understand you question now. No an interrupt cannot by
Hi Slawa,
On 10/12/16 10:40 AM, Slawa Olhovchenkov wrote:
> On Wed, Oct 12, 2016 at 10:18:18AM +0200, Julien Charbon wrote:
>> On 10/11/16 2:11 PM, Slawa Olhovchenkov wrote:
>>> On Tue, Oct 11, 2016 at 09:20:17AM +0200, Julien Charbon wrote:
Then threads are competing for the INP_WLOCK loc
On Wed, Oct 12, 2016 at 11:42:38AM +0200, Julien Charbon wrote:
> On 10/12/16 11:29 AM, Slawa Olhovchenkov wrote:
> > On Wed, Oct 12, 2016 at 11:19:48AM +0200, Julien Charbon wrote:
> >
> >>> if INP_WLOCK is like spinlock -- this is dead lock.
> >>> if INP_WLOCK is like mutex -- thread1 reshedule
Hi Slawa,
On 10/12/16 11:52 AM, Slawa Olhovchenkov wrote:
> On Wed, Oct 12, 2016 at 11:42:38AM +0200, Julien Charbon wrote:
>> On 10/12/16 11:29 AM, Slawa Olhovchenkov wrote:
>>> On Wed, Oct 12, 2016 at 11:19:48AM +0200, Julien Charbon wrote:
>>>
> if INP_WLOCK is like spinlock -- this is de
On Wed, Oct 12, 2016 at 02:06:59PM +0200, Julien Charbon wrote:
> > sofree() call tcp_usr_detach() and in tcp_usr_detach() we have
> > unexpected INP_TIMEWAIT.
>
> I see, thus just for the context: The TCP stack in sys/dev/cxgb* is a
> TOE (TCP Offload Engine?) TCP stack f
Hi Slawa,
On 10/12/16 2:13 PM, Slawa Olhovchenkov wrote:
> On Wed, Oct 12, 2016 at 02:06:59PM +0200, Julien Charbon wrote:
>>> sofree() call tcp_usr_detach() and in tcp_usr_detach() we have
>>> unexpected INP_TIMEWAIT.
>>
>> I see, thus just for the context: The TCP stack in sy
On Wed, Oct 12, 2016 at 02:35:11PM +0200, Julien Charbon wrote:
>
> Hi Slawa,
>
> On 10/12/16 2:13 PM, Slawa Olhovchenkov wrote:
> > On Wed, Oct 12, 2016 at 02:06:59PM +0200, Julien Charbon wrote:
> >>> sofree() call tcp_usr_detach() and in tcp_usr_detach() we have
> >>> unexpected INP_
Trying to upgrade a couple of hosts (11.0-RC2, 11.0-RC3,
10.3-RELEASE-p10)
to 11.0 (using: freebsd-update upgrade -r 11.0-RELEASE), and it seems
the fetch(1) always fails with a timeout. Even a simple (freebsd-update
fetch)
in an attempt to bump a 10.3-RELEASE-p9 to 10.3-RELEASE-p10 now fails
w
Hi Slawa,
On 10/12/16 3:01 PM, Slawa Olhovchenkov wrote:
> On Wed, Oct 12, 2016 at 02:35:11PM +0200, Julien Charbon wrote:
>> On 10/12/16 2:13 PM, Slawa Olhovchenkov wrote:
>>> On Wed, Oct 12, 2016 at 02:06:59PM +0200, Julien Charbon wrote:
> sofree() call tcp_usr_detach() and in tcp_usr
Whatever you did, it started to work now normally. Thank you!
(no changes at our side)
Mark
2016-10-12 16:29, Mark Martinec wrote:
Trying to upgrade a couple of hosts (11.0-RC2, 11.0-RC3,
10.3-RELEASE-p10)
to 11.0 (using: freebsd-update upgrade -r 11.0-RELEASE), and it seems
the fetch(1) a
On Wed, Oct 12, 2016 at 05:17:35PM +0200, Julien Charbon wrote:
> I see, thus just for the context: The TCP stack in sys/dev/cxgb*
> is a
> TOE (TCP Offload Engine?) TCP stack for Chelsio NICs, it is a
> separate/side TCP stack that is used only with TCP_OFFL
> I see, thus just for the context: The TCP stack in sys/dev/cxgb* is a
> TOE (TCP Offload Engine?) TCP stack for Chelsio NICs, it is a
> separate/side TCP stack that is used only with TCP_OFFLOAD option.
>
> This TOE TCP stack actually has its own set of detach()/input()
> functions and seems
details to follow
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Details:
After upgrading 2 machines from 9.3 to 10.3-STABLE, on one of them the
l2arc stays empty (capacity alloc = 0), although it is online and gets
accessed. It did work well on 9.3.
I did the following tests:
* Create a zpool on a stick, with two volumes: one filesystem and one
cache. The
sendbug seems not to work anymore, I end up on websites with marketing-
babble and finally get asked to provide some login and passwd. :(
But the former mail looks like having come back to me, so it seems I'm
still allowed to post here...
*** sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
Perhaps it's time to replace Apache httpd/2.2.16 (released 6+ years ago)
running on update.FreeBSD.org with something lighter and more agile
like nginx (or at least with a fresher version of Apache httpd).
The accf_http(9) (with: accept_filter=httpready) may help too.
Mark
2016-10-12 17:23,
FreeBSD thin.lan.fnwe.net 11.0-RELEASE-p1 FreeBSD 11.0-RELEASE-p1 #0
r306420: Thu Sep 29 01:43:23 UTC 2016
r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC
amd64
root@thin:~ # df -k
Filesystem 1024-blocksUsed Avail Capacity Mounted on
zroot/ROOT/default 927326328 8035732
20 matches
Mail list logo