Re: aibs(4) / atk0110 support for newer systems

2016-10-14 Thread Torfinn Ingolfsen 
On Thu, 6 Oct 2016 00:37:16 +0300
Andriy Gapon  wrote:

> On 05/10/2016 23:28, Torfinn Ingolfsen wrote:
> > #6  0x80cd0081 in calltrap ()
> > at /usr/src/sys/amd64/amd64/exception.S:238
> > #7  0x81bcb078 in aibs_add_sensor () from /boot/kernel/aibs.ko
> > #8  0x81bcb4b4 in aibs_attach_sif () from /boot/kernel/aibs.ko
> 
> Argh, I've just spotted a very silly typo.
> Could you please replace '0' with 'o' in
>   err = aibs_add_sensor(sc, 0, [i], );
> ?

Yes, that fixes it - aibs.ko no longer panics my machine when I load it.
Output from /var/log/messages:
Oct 14 20:32:18 kg-core1 kernel: aibs0:  on acpi0
Oct 14 20:32:18 kg-core1 kernel: aibs0: v0: 0x0602Vcore Voltage   
850 /  1600
Oct 14 20:32:18 kg-core1 kernel: aibs0: v1: 0x06020001 +3.3 Voltage  
2970 /  3630
Oct 14 20:32:18 kg-core1 kernel: aibs0: v2: 0x06020002   +5 Voltage  
4500 /  5500
Oct 14 20:32:18 kg-core1 kernel: aibs0: v3: 0x06020003  +12 Voltage 
10200 / 13800
Oct 14 20:32:18 kg-core1 kernel: aibs0: t0: 0x0603  CPU Temperature   
600 /   950
Oct 14 20:32:18 kg-core1 kernel: aibs0: t1: 0x06030001   MB Temperature   
450 /   750
Oct 14 20:32:18 kg-core1 kernel: aibs0: f0: 0x0604CPU FAN Speed   
600 /  7200
Oct 14 20:32:18 kg-core1 kernel: aibs0: f1: 0x06040001CHASSIS FAN Speed   
600 /  7200

it looks almost the same as it did previously:
tingo@kg-core1$ grep aibs /tmp/c1-dmesg-9.3-stable-20160826.txt
aibs0:  on acpi0
aibs0: V0: 0x0602Vcore Voltage   850 /  1600  0x1
aibs0: V1: 0x06020001 +3.3 Voltage  2970 /  3630  0x1
aibs0: V2: 0x06020002   +5 Voltage  4500 /  5500  0x1
aibs0: V3: 0x06020003  +12 Voltage 10200 / 13800  0x1
aibs0: T0: 0x0603  CPU Temperature   600 /   950  0x10001
aibs0: T1: 0x06030001   MB Temperature   450 /   750  0x10001
aibs0: F0: 0x0604CPU FAN Speed   600 /  7200  0x10001
aibs0: F1: 0x06040001CHASSIS FAN Speed   600 /  7200  0x10001


and from sysctl dev.aibs
root@kg-core1# sysctl dev.aibs
dev.aibs.0.volt.0: 1404 850 1600
dev.aibs.0.volt.1: 3265 2970 3630
dev.aibs.0.volt.2: 5070 4500 5500
dev.aibs.0.volt.3: 12028 10200 13800
dev.aibs.0.temp.0: 51.9C 59.9C 94.9C
dev.aibs.0.temp.1: 30.9C 44.9C 74.9C
dev.aibs.0.fan.0: 2678 600 7200
dev.aibs.0.fan.1: 2678 600 7200
dev.aibs.0.%parent: acpi0
dev.aibs.0.%pnpinfo: _HID=ATK0110 _UID=16843024
dev.aibs.0.%location: handle=\_SB_.PCI0.SBRG.ASOC
dev.aibs.0.%driver: aibs
dev.aibs.0.%desc: ASUSTeK AI Booster (ACPI ASOC ATK0110)


-- 
Torfinn Ingolfsen 
___
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: aibs(4) / atk0110 support for newer systems

2016-10-14 Thread Torfinn Ingolfsen 
On Tue, 11 Oct 2016 14:29:34 +0300
Andriy Gapon  wrote:

> On 06/10/2016 00:37, Andriy Gapon wrote:
> > On 05/10/2016 23:28, Torfinn Ingolfsen wrote:
> >> #6  0x80cd0081 in calltrap ()
> >> at /usr/src/sys/amd64/amd64/exception.S:238
> >> #7  0x81bcb078 in aibs_add_sensor () from /boot/kernel/aibs.ko
> >> #8  0x81bcb4b4 in aibs_attach_sif () from /boot/kernel/aibs.ko
> > 
> > Argh, I've just spotted a very silly typo.
> > Could you please replace '0' with 'o' in
> > err = aibs_add_sensor(sc, 0, [i], );
> > ?
> 
> Ping.

Done - see other messages in this thread. Sorry about the delay.

-- 
Torfinn Ingolfsen 
___
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: make buildwotrld can not find zlib,h

2016-10-14 Thread 河北隆生 
On Fri, Oct 14, 2016 at 6:10 AM, Dmitry Luhtionov  wrote:

> c++  -O2 -pipe
> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include
> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/
> include
> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I.
> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/
> include
> -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS
> -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing
> -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\"
> -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\"
> -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\" -MD -MF.depend.Compression.o
> -MTCompression.o -Qunused-arguments
> -I/usr/obj/usr/src/tmp/legacy/usr/include  -std=c++11 -fno-exceptions
> -fno-rtti -stdlib=libc++ -Wno-c++11-extensions  -c
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/
> Compression.cpp
> -o Compression.o
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/
> Compression.cpp:21:10:
> fatal error: 'zlib.h' file not found
> #include 
>  ^
> 1 error generated.
>

Very odd. /usr/include/zlib.h is and long has been a standard component of
FreeBSD and should be present on your system. Can you confirm its absence?
Anything that could be in /etc/src.conf that might trigger this? (I can't
see anything obvious, but src.conf(5) is very long.)

I'm also not sure whether, at this point in the build, you should be using
the system's include files or those in /usr/obj/usr/src/tmp/usr/include/ or
/usr/src/lib/libz/zlib.h, which is what should be copied to
/usr/obj/usr/src/tmp/usr/include. Normally the system's files are not used
during the build.

Have you tried completely removing /usr/obj (rm -r /usr/obj/*) before
starting the build with -DNO_CLEAN?
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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"

---
河北隆生＠熊本県産業技術センター
___
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: make buildwotrld can not find zlib,h

2016-10-14 Thread Kevin Oberman 
On Fri, Oct 14, 2016 at 6:10 AM, Dmitry Luhtionov  wrote:

> c++  -O2 -pipe
> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include
> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/
> include
> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I.
> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/
> include
> -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS
> -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing
> -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\"
> -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\"
> -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\" -MD -MF.depend.Compression.o
> -MTCompression.o -Qunused-arguments
> -I/usr/obj/usr/src/tmp/legacy/usr/include  -std=c++11 -fno-exceptions
> -fno-rtti -stdlib=libc++ -Wno-c++11-extensions  -c
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/
> Compression.cpp
> -o Compression.o
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/
> Compression.cpp:21:10:
> fatal error: 'zlib.h' file not found
> #include 
>  ^
> 1 error generated.
>

Very odd. /usr/include/zlib.h is and long has been a standard component of
FreeBSD and should be present on your system. Can you confirm its absence?
Anything that could be in /etc/src.conf that might trigger this? (I can't
see anything obvious, but src.conf(5) is very long.)

I'm also not sure whether, at this point in the build, you should be using
the system's include files or those in /usr/obj/usr/src/tmp/usr/include/ or
/usr/src/lib/libz/zlib.h, which is what should be copied to
/usr/obj/usr/src/tmp/usr/include. Normally the system's files are not used
during the build.

Have you tried completely removing /usr/obj (rm -r /usr/obj/*) before
starting the build with -DNO_CLEAN?
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: make buildwotrld can not find zlib,h

2016-10-14 Thread Marek Zarychta 
On Fri, Oct 14, 2016 at 04:10:18PM +0300, Dmitry Luhtionov wrote:
> c++  -O2 -pipe
> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include
> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include
> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I.
> -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
> -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS
> -D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing
> -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\"
> -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\"
> -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\" -MD -MF.depend.Compression.o
> -MTCompression.o -Qunused-arguments
> -I/usr/obj/usr/src/tmp/legacy/usr/include  -std=c++11 -fno-exceptions
> -fno-rtti -stdlib=libc++ -Wno-c++11-extensions  -c
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Compression.cpp
> -o Compression.o
> /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Compression.cpp:21:10:
> fatal error: 'zlib.h' file not found
> #include 
>  ^
> 1 error generated.

Maybe some incorrect or stale statements in src.conf ?

-- 
Marek Zarychta


signature.asc
Description: PGP signature

Re: vale-ctl(-8), ifconfig(8), SIOCAIFADDR: Invalid argument [utilizing netmap(4) providing virtual switches+interfaces to BHyVe]

2016-10-14 Thread Harry Schmalzbauer 
Bezüglich Vincenzo Maffione's Nachricht vom 14.10.2016 15:08 (localtime):
> Hi,
> 
>   Thanks for your feedback.
> 
…
>> Accidentally I found out that 'vale-ctl -n testif0' creates a artificial
>> interface, which is reported by ifconfig(8):
>> testif0: flags=8801 metric 0 mtu 1500
>> options=8
>> ether 00:be:eb:8d:f8:00
>> nd6 options=21
>>
>> But I can't assign a IP address: 'ifconfig testif0 203.0.113.1/24'
>> ifconfig: ioctl (SIOCAIFADDR): Invalid argument
>>
>> I guess couldn't geti the picture of the netmap(4) world yet.
>> Probably, testif0 is available only in netmap(4) world, not in "host
>> world".
>> I'm assuming, because I found vale-ctl(-8)s "-h" switch.
>>
> 
> Yes, those are the "persistent" VALE ports. They are a recent feature, and
> probably you don't need to use them if you are going to play with Virtual
> Machines and jails (see below).

Hello Vincenzo,

thank you very much for your help!!!


…
>> Now my question:
>>
>> How can I plug a jail's or vmm's artificial interface to a VALE virtual
>> switch, bridging frames to real-world via physical interfaces?
>> (the latter part should work with vale-ctl -h vale0:em1, but what
>> interface to use for jail(8) vnet.interface and how to create/attach?)
>>
> 
> If you use bhyve/vmm, you can attach the VM TAP interface to the VALE
> switch, as you would do for "em1". Regarding jails, I don't know exactly
> how networking works there, but I guess epair(4) interface (or similar) are
> used. If this is the case, then you would have one end of the epair only
> visible in the jail, and the other end only visible in the "host"; then you

I'm familar with epair(4), but not with tap(4).
I don't understand the man page for tap, perhaps I should read pty(4)…
But I guess I don't have to know the details of tap(4), since you
confirmed that it can be connected to VALE.

So one could summarize:
VALE (as part of netmap(4)) can act as a if_bridge(4) replacement in
FreeBSD-10/11, keeping everything else involved untouched.
Please correct me if I'm wrong.


> could attach the host end to a VALE switch again with "vale-ctl -a".
> Unfortunately, the performance you would get in any case is not great,
> because TAP and epair interface do not have netmap "native support".
> Moreover, when using bhyve, you have to pay the cost of the emulation of
> the vtnet device, since each packet passes through this device (other than
> passing across netmap).

I understand, thanks.
In fact, I expected that at first hand, but have had some oddities with
if_bridge(4) some years ago, so I thought I'd better try something new ;-)
Can I expect any resource savings over if_bridge(4)? I guess if so, the
ammount isn't relevant considering the whole bhyve scenarium.


> However, consider the following: a consistent netmap update is going to
> happen in FreeBSD-CURRENT, in short. This is going to align the netmap code
> which is now in FreeBSD to the code on the official github repository (
> https://github.com/luigirizzo/netmap). Among the new features, there is a
> new solution for bhyve networking, which will let you attach your bhyve VMs
> directly to a VALE switch, without paying additional overheads related to
> TAPs, epairs, and vtnet emulation. You can find additional information,
> code and performance numbers here:
> https://wiki.freebsd.org/SummerOfCode2016/PtnetDriverAndDeviceModel.

Thanks for that hint!
I guess it's about ptnetmap(4)? I read papers but haven't considered it
could be production-ready for FreeBSD in the near future.
It's extremely interesting and I'd love to be eraly adopter, but my
(ESXi) setups are currently doing well and I don't have spare time or
any business project to try out… :-(

Is it likely that there will a MFC happen? Or will it be a exclusive
12.0 feature? If ptnetmap will be MFCd I'll definitely give it a try
next summer and stay with 11.0 for my replacement machines for now.
Otherwise I'm unsure…

best,

-Harry
___
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"

make buildwotrld can not find zlib,h

2016-10-14 Thread Dmitry Luhtionov 
c++  -O2 -pipe
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I.
-I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include
-DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS
-D__STDC_CONSTANT_MACROS -DNDEBUG -fno-strict-aliasing
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\"
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\"
-DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\" -MD -MF.depend.Compression.o
-MTCompression.o -Qunused-arguments
-I/usr/obj/usr/src/tmp/legacy/usr/include  -std=c++11 -fno-exceptions
-fno-rtti -stdlib=libc++ -Wno-c++11-extensions  -c
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Compression.cpp
-o Compression.o
/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/Compression.cpp:21:10:
fatal error: 'zlib.h' file not found
#include 
 ^
1 error generated.
___
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: vale-ctl(-8), ifconfig(8), SIOCAIFADDR: Invalid argument [utilizing netmap(4) providing virtual switches+interfaces to BHyVe]

2016-10-14 Thread Vincenzo Maffione 
Hi,

  Thanks for your feedback.

2016-10-14 11:00 GMT+02:00 Harry Schmalzbauer :

>  Dear all,
>
> I found great papers about netmap(4)s desigen and implementation
> details, and I'm sure it's one other masterpeace of rizzo-quality :-)
> Thanks to all participants for that great code!
>
> To be honest, I haven't read all of that, because I'm short in time and
> my first mission is to see if FreeBSD 11 will replace some of my ESXi
> machines.
>
> One key element seems netmap(4).
> It's quiet hard to find userland documentation.
>
> So far, I've discovered that there are three essential tools waiting in
> _usr/src/tools/tools/netmap_ to be compiled
> (resulting in *./vale-ctl*, *./bridge*, *./pkt-gen*)
>
> While the latter is often referenced in netmap(4) documentation, it's
> not of interest for me, because I'll be doing real-world performance
> tests and I'm convinced that all the impressive numbers presented in the
> netmap documentation are valid :-)
>
> So *vale-ctl(-8)* seems to be of interest (I'm using (-8) becaus
> currently there is no man8 part (I guess that's the reason for these
> tools not beeing integrated into base binaries))
>
> Accidentally I found out that 'vale-ctl -n testif0' creates a artificial
> interface, which is reported by ifconfig(8):
> testif0: flags=8801 metric 0 mtu 1500
> options=8
> ether 00:be:eb:8d:f8:00
> nd6 options=21
>
> But I can't assign a IP address: 'ifconfig testif0 203.0.113.1/24'
> ifconfig: ioctl (SIOCAIFADDR): Invalid argument
>
> I guess couldn't geti the picture of the netmap(4) world yet.
> Probably, testif0 is available only in netmap(4) world, not in "host
> world".
> I'm assuming, because I found vale-ctl(-8)s "-h" switch.
>

Yes, those are the "persistent" VALE ports. They are a recent feature, and
probably you don't need to use them if you are going to play with Virtual
Machines and jails (see below).


>
> So another very little peace I'm aware of the netmap(4) world, is how to
> attach physical interfaces to virtual switches:
> '/usr/src/tools/tools/netmap/vale-ctl -a vale0:em1'
> Now vale-ctl(-8) shows:
> bdg_ctl [149] bridge:0 port:0 vale0:em1
>
> /*
> To share my experience: One cannot use any other than vale[[:digit:]]
> for defining the on-demand to be created virtual switch instance, so
> e.g. "vale-ctl -a vale-test:em1" doesn't work, although found in
> netmap(4) man page in FreeBSD-11:
> »valeXXX:YYY (arbitrary XXX and YYY)
> the file descriptor is bound to port YYY of a VALE switch called
> XXX, both dynamically created if necessary. The string cannot
> exceed IFNAMSIZ characters, and YYY cannot be the name of any
> existing OS network interface«
>
> I was about to give up on netmap(4) investigations because I thought it
> isn't production ready yet (in FreeBSD), since even andding the first
> physical interface fails: '/usr/src/tools/tools/netmap/vale-ctl -a
> vale-test:em1'
> vale-test:em1: Invalid argument
>
> Probably accidentally I used vale[[:digit:]] instead and wondered whay
> it suddenly works…
>

Correct, this seems to be an inconsistency between the manual and the
implementation, we will fix the manual.


>
> To get back to vale-ctl(-8)s "-h" switch:
> */
>
> If I add a physical interface with -h instead of -a, the host's IP stack
> doesn't get disconnected from the interface, so it's still usable by
> host applications and vale-ctl(-8) lists one line more:
> bdg_ctl [149] bridge:0 port:0 vale0:em1
> bdg_ctl [149] bridge:0 port:1 vale0:em1^
> So my assumption that netmap(4) lives decapsuled from the well known
> FreeBSD IP world.
>
>
> Now my question:
>
> How can I plug a jail's or vmm's artificial interface to a VALE virtual
> switch, bridging frames to real-world via physical interfaces?
> (the latter part should work with vale-ctl -h vale0:em1, but what
> interface to use for jail(8) vnet.interface and how to create/attach?)
>

If you use bhyve/vmm, you can attach the VM TAP interface to the VALE
switch, as you would do for "em1". Regarding jails, I don't know exactly
how networking works there, but I guess epair(4) interface (or similar) are
used. If this is the case, then you would have one end of the epair only
visible in the jail, and the other end only visible in the "host"; then you
could attach the host end to a VALE switch again with "vale-ctl -a".
Unfortunately, the performance you would get in any case is not great,
because TAP and epair interface do not have netmap "native support".
Moreover, when using bhyve, you have to pay the cost of the emulation of
the vtnet device, since each packet passes through this device (other than
passing across netmap).

However, consider the following: a consistent netmap update is going to
happen in FreeBSD-CURRENT, in short. This is going to align the netmap code
which is now in FreeBSD to the code on the official github repository (
https://github.com/luigirizzo/netmap). Among the new features, there is a

Re: 11.0 stuck on high network load

2016-10-14 Thread Slawa Olhovchenkov 
On Fri, Oct 14, 2016 at 11:48:38AM +0200, Julien Charbon wrote:

> >>> Also, using dtrace too complex in production (need complex startup
> >>> under screen and capture output) and for many peoples.
> >>> kdb_backtrace() have too less administrative overhead.
> >>
> >>  I still think it is overkill.  The main goal of this change is to fix a
> >> quite tricky and old TCP stack locking issue.  Let's try to do that
> >> first, it is complex enough by itself.
> >>
> >>  Once the fix is validated and pushed, feel free to propose your own
> >> patch/review to add kdb_backtrace(), log(), etc.. to get other devs
> >> point of view.
> >>
> >>  I don't remember who said: "Never ever optimize error cases"...
> > 
> > This is not optimeze error cases, this is error recovery and
> > diagnostic of error cases in other subsystems.
> 
>  Sure, I guess this quote is more geared toward:  "Always spend 50x more
> time on improving the main path than the error path".
> 
> > Currently FreeBSD internals too complex for just always trust on
> > correct of other subsystem or do panic on any incosystency.
> > 
> > INVARIANTS too expensive now (20Gbit drops to 8Gbits).
> 
>  I do agree.  I am not expert enough to see all the side effects of
> calling kdb_backtrace() from the TCP stack, might be way too slow,
> tricky in interruption context, etc.  You can see that  kdb_backtrace()

I think about this. This is example take from netgraph and this
similar case (about interruption context and etc). Occurrence to rare
(one per day, may be one per two hour) for any overhead.
OK, I am see you point: you expirence don't allow to put this code and
need separete review and commit. Right, np.

> is rarely called in the kernel source.  That's why it is better if you
> propose a review on adding this line to get comments from other devs on
> just this question.
> 
> > PS: I am applay patch. Wait till monday.
> > 
> > Thanks very match for this hard work!
> 
>  No problem, thanks for your time.  But it is not over yet:  We have to
> wait for final test.

Currently system don't use Chelsio TOE, after monday I am update
system with Chelsio TOE. With chelsio I am see this occurrence very
rare, one in few month.
___
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-14 Thread Julien Charbon 

 Hi,

On 10/14/16 11:35 AM, Slawa Olhovchenkov wrote:
> On Thu, Oct 13, 2016 at 06:14:29PM +0200, Julien Charbon wrote:
>> On 10/13/16 5:17 PM, Slawa Olhovchenkov wrote:
>>> On Thu, Oct 13, 2016 at 05:06:00PM +0200, Julien Charbon wrote:
>>>
>> will give you that trace in the core, and without INVARIANT then it is
>> better to use dtrace:
>>
>> $ cat tcp-twstart-dropped.d
>> fbt::tcp_twstart:entry
>> /args[0]->t_inpcb->inp_flags & 0x0400/
>> {
>>   stack();
>>   printf("INP_DROPPED in tcp_twstart: %x", args[0]->t_inpcb->inp_flags);
>> }
>
> Same code may be insert there too, IMHO.

  Hmm, I don't think so:

  - If you have INVARIANT, the kernel will panic in tcp_twstart() or
 tcp_detach() and you will have everything you need to debug.
  - If you don't, dtrace is the right tool to use in all cases anyway.
>>>
>>> dtrace don't executed in may case w/ diagnostic "dtrace: processing
>>> aborted: Abort due to systemic unresponsiveness". This is for
>>> tcp_close. May be tcp_twstart will be more successuful, may be not.
>>
>>  It does and will.
>>
>>> Also, using dtrace too complex in production (need complex startup
>>> under screen and capture output) and for many peoples.
>>> kdb_backtrace() have too less administrative overhead.
>>
>>  I still think it is overkill.  The main goal of this change is to fix a
>> quite tricky and old TCP stack locking issue.  Let's try to do that
>> first, it is complex enough by itself.
>>
>>  Once the fix is validated and pushed, feel free to propose your own
>> patch/review to add kdb_backtrace(), log(), etc.. to get other devs
>> point of view.
>>
>>  I don't remember who said: "Never ever optimize error cases"...
> 
> This is not optimeze error cases, this is error recovery and
> diagnostic of error cases in other subsystems.

 Sure, I guess this quote is more geared toward:  "Always spend 50x more
time on improving the main path than the error path".

> Currently FreeBSD internals too complex for just always trust on
> correct of other subsystem or do panic on any incosystency.
> 
> INVARIANTS too expensive now (20Gbit drops to 8Gbits).

 I do agree.  I am not expert enough to see all the side effects of
calling kdb_backtrace() from the TCP stack, might be way too slow,
tricky in interruption context, etc.  You can see that  kdb_backtrace()
is rarely called in the kernel source.  That's why it is better if you
propose a review on adding this line to get comments from other devs on
just this question.

> PS: I am applay patch. Wait till monday.
> 
> Thanks very match for this hard work!

 No problem, thanks for your time.  But it is not over yet:  We have to
wait for final test.

--
Julien



signature.asc
Description: OpenPGP digital signature

Re: 11.0 stuck on high network load

2016-10-14 Thread Slawa Olhovchenkov 
On Thu, Oct 13, 2016 at 06:14:29PM +0200, Julien Charbon wrote:

> On 10/13/16 5:17 PM, Slawa Olhovchenkov wrote:
> > On Thu, Oct 13, 2016 at 05:06:00PM +0200, Julien Charbon wrote:
> > 
>  will give you that trace in the core, and without INVARIANT then it is
>  better to use dtrace:
> 
>  $ cat tcp-twstart-dropped.d
>  fbt::tcp_twstart:entry
>  /args[0]->t_inpcb->inp_flags & 0x0400/
>  {
>    stack();
>    printf("INP_DROPPED in tcp_twstart: %x", args[0]->t_inpcb->inp_flags);
>  }
> >>>
> >>> Same code may be insert there too, IMHO.
> >>
> >>  Hmm, I don't think so:
> >>
> >>  - If you have INVARIANT, the kernel will panic in tcp_twstart() or
> >> tcp_detach() and you will have everything you need to debug.
> >>  - If you don't, dtrace is the right tool to use in all cases anyway.
> > 
> > dtrace don't executed in may case w/ diagnostic "dtrace: processing
> > aborted: Abort due to systemic unresponsiveness". This is for
> > tcp_close. May be tcp_twstart will be more successuful, may be not.
> 
>  It does and will.
> 
> > Also, using dtrace too complex in production (need complex startup
> > under screen and capture output) and for many peoples.
> > kdb_backtrace() have too less administrative overhead.
> 
>  I still think it is overkill.  The main goal of this change is to fix a
> quite tricky and old TCP stack locking issue.  Let's try to do that
> first, it is complex enough by itself.
> 
>  Once the fix is validated and pushed, feel free to propose your own
> patch/review to add kdb_backtrace(), log(), etc.. to get other devs
> point of view.
> 
>  I don't remember who said: "Never ever optimize error cases"...

This is not optimeze error cases, this is error recovery and
diagnostic of error cases in other subsystems.

Currently FreeBSD internals too complex for just always trust on
correct of other subsystem or do panic on any incosystency.

INVARIANTS too expensive now (20Gbit drops to 8Gbits).

PS: I am applay patch. Wait till monday.

Thanks very match for this hard work!
___
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"

vale-ctl(-8), ifconfig(8), SIOCAIFADDR: Invalid argument [utilizing netmap(4) providing virtual switches+interfaces to BHyVe]

2016-10-14 Thread Harry Schmalzbauer 
 Dear all,

I found great papers about netmap(4)s desigen and implementation
details, and I'm sure it's one other masterpeace of rizzo-quality :-)
Thanks to all participants for that great code!

To be honest, I haven't read all of that, because I'm short in time and
my first mission is to see if FreeBSD 11 will replace some of my ESXi
machines.

One key element seems netmap(4).
It's quiet hard to find userland documentation.

So far, I've discovered that there are three essential tools waiting in
_usr/src/tools/tools/netmap_ to be compiled
(resulting in *./vale-ctl*, *./bridge*, *./pkt-gen*)

While the latter is often referenced in netmap(4) documentation, it's
not of interest for me, because I'll be doing real-world performance
tests and I'm convinced that all the impressive numbers presented in the
netmap documentation are valid :-)

So *vale-ctl(-8)* seems to be of interest (I'm using (-8) becaus
currently there is no man8 part (I guess that's the reason for these
tools not beeing integrated into base binaries))

Accidentally I found out that 'vale-ctl -n testif0' creates a artificial
interface, which is reported by ifconfig(8):
testif0: flags=8801 metric 0 mtu 1500
options=8
ether 00:be:eb:8d:f8:00
nd6 options=21

But I can't assign a IP address: 'ifconfig testif0 203.0.113.1/24'
ifconfig: ioctl (SIOCAIFADDR): Invalid argument

I guess couldn't geti the picture of the netmap(4) world yet.
Probably, testif0 is available only in netmap(4) world, not in "host world".
I'm assuming, because I found vale-ctl(-8)s "-h" switch.

So another very little peace I'm aware of the netmap(4) world, is how to
attach physical interfaces to virtual switches:
'/usr/src/tools/tools/netmap/vale-ctl -a vale0:em1'
Now vale-ctl(-8) shows:
bdg_ctl [149] bridge:0 port:0 vale0:em1

/*
To share my experience: One cannot use any other than vale[[:digit:]]
for defining the on-demand to be created virtual switch instance, so
e.g. "vale-ctl -a vale-test:em1" doesn't work, although found in
netmap(4) man page in FreeBSD-11:
»valeXXX:YYY (arbitrary XXX and YYY)
the file descriptor is bound to port YYY of a VALE switch called
XXX, both dynamically created if necessary. The string cannot
exceed IFNAMSIZ characters, and YYY cannot be the name of any
existing OS network interface«

I was about to give up on netmap(4) investigations because I thought it
isn't production ready yet (in FreeBSD), since even andding the first
physical interface fails: '/usr/src/tools/tools/netmap/vale-ctl -a
vale-test:em1'
vale-test:em1: Invalid argument

Probably accidentally I used vale[[:digit:]] instead and wondered whay
it suddenly works…

To get back to vale-ctl(-8)s "-h" switch:
*/

If I add a physical interface with -h instead of -a, the host's IP stack
doesn't get disconnected from the interface, so it's still usable by
host applications and vale-ctl(-8) lists one line more:
bdg_ctl [149] bridge:0 port:0 vale0:em1
bdg_ctl [149] bridge:0 port:1 vale0:em1^
So my assumption that netmap(4) lives decapsuled from the well known
FreeBSD IP world.


Now my question:

How can I plug a jail's or vmm's artificial interface to a VALE virtual
switch, bridging frames to real-world via physical interfaces?
(the latter part should work with vale-ctl -h vale0:em1, but what
interface to use for jail(8) vnet.interface and how to create/attach?)

Thanks,

-harry

___
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"