11-RELEASE PL1 doesn't load kernel modules with ZFS-on-Root

2016-10-12 Thread Aryeh Friedman
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

Re: update.FreeBSD.org unresponsive?

2016-10-12 Thread Mark Martinec
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,

[fixed] ZFS l2arc broken in 10.3

2016-10-12 Thread Peter
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

Re: ZFS l2arc broken in 10.3

2016-10-12 Thread Peter
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

ZFS l2arc broken in 10.3

2016-10-12 Thread Peter
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"

Re: 11.0 stuck on high network load

2016-10-12 Thread Navdeep Parhar
> 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

Re: 11.0 stuck on high network load

2016-10-12 Thread Slawa Olhovchenkov
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

Re: update.FreeBSD.org unresponsive?

2016-10-12 Thread Mark Martinec
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

Re: 11.0 stuck on high network load

2016-10-12 Thread Julien Charbon
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

update.FreeBSD.org unresponsive?

2016-10-12 Thread Mark Martinec
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

Re: 11.0 stuck on high network load

2016-10-12 Thread Slawa Olhovchenkov
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_

Re: 11.0 stuck on high network load

2016-10-12 Thread Julien Charbon
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

Re: 11.0 stuck on high network load

2016-10-12 Thread Slawa Olhovchenkov
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

Re: 11.0 stuck on high network load

2016-10-12 Thread Julien Charbon
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

Re: 11.0 stuck on high network load

2016-10-12 Thread Slawa Olhovchenkov
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

Re: 11.0 stuck on high network load

2016-10-12 Thread Julien Charbon
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

Re: 11.0 stuck on high network load

2016-10-12 Thread Julien Charbon
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

Re: 11.0 stuck on high network load

2016-10-12 Thread Slawa Olhovchenkov
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

Re: 11.0 stuck on high network load

2016-10-12 Thread Slawa Olhovchenkov
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

Re: 11.0 stuck on high network load

2016-10-12 Thread Julien Charbon
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