Re: Speed problems with both system openssl and security/openssl-devel
Hello John, Friday, September 14, 2018, 1:44:13 AM, you wrote: >> % grep aesni ~/nanobsd/gatevay.v3/J3160 >> device aesni > From my understanding of the OpenSSL code, it doesn't use the kernel driver > at all (the kernel driver is only needed for in-kernel crypto such as IPSec > or GELI). It is my understanding too. > AESNI are just instructions that can be used in userland, and > OpenSSL's AESNI acceleration is purely different routines in userland. > I would verify if AESNI shows up in the CPU features in dmesg first (if it > doesn't I'd check for a BIOS option disabling it). It is enabled. It is used for sure by openssl 1.1.0 on Linux and bu openssl 1.1.1 on FreeBSD, but not by openssl 1.0.2 and 1.1.0 on FreeBSD. Problem is, openssl 1.1.1 is not used by anything on FreeBSD (yet) and almost everything uses system (1.0.2) and only some other ports could use 1.1.0 from ports. -- Best regards, Levmailto:l...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Speed problems with both system openssl and security/openssl-devel
On 9/13/18 1:27 AM, Lev Serebryakov wrote: > Hello Kevin, > > Thursday, September 13, 2018, 6:32:30 AM, you wrote: > > >> This is probably not the issue, but aesni is not in the GENERIC kernel. Are >> you sure aesni.ko is loaded? >> % kldstat | grep aesni > I'm not using modules, as it is NanoBSD image build for minimal size ant > maximal efficiency. But I have aesni in my kernel config for sure: > > % grep aesni ~/nanobsd/gatevay.v3/J3160 > device aesni From my understanding of the OpenSSL code, it doesn't use the kernel driver at all (the kernel driver is only needed for in-kernel crypto such as IPSec or GELI). AESNI are just instructions that can be used in userland, and OpenSSL's AESNI acceleration is purely different routines in userland. I would verify if AESNI shows up in the CPU features in dmesg first (if it doesn't I'd check for a BIOS option disabling it). -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Creating a memory/networking hungry mode in FreeBSD
Is it possible? Maybe by threading and caching Idealistically I feel desktop FreeBSD should have a mode that uses the resources as much as possible instead of keeping it idle ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ntpd user and group missing when upgrading from sources from 11-stable to 12-current
On Thu, Sep 13, 2018 at 04:16:26PM -0500, Eric van Gyzen wrote: > On 9/13/18 4:07 PM, Marek Zarychta wrote: > > Dear subscribers, > > > > stable/12 hasn't been branched yet, so it could be not a bug. Since > > r336525 make installworld fails on 11-stable when installing world for > > 12-current without ntpd user/group added. Of course, as a workaround > > user and group could be added manually. Mergemeaster also fails when it > > is run before installworld, what is IMHO predictable and expected > > behaviour. So mergemaster will not help with this issue. > > > > So the question arises, is it a feature or should a PR be submitted? > > Did you run mergemaster with the -p flag before installworld? > > Eric Thank you for the clue, TBH I didn't use -p flag which was my fault. I am sorry for the needless noise I have made on the list. -- Marek Zarychta signature.asc Description: PGP signature
Re: ntpd user and group missing when upgrading from sources from 11-stable to 12-current
On 9/13/18 2:07 PM, Marek Zarychta wrote: Dear subscribers, stable/12 hasn't been branched yet, so it could be not a bug. Since r336525 make installworld fails on 11-stable when installing world for 12-current without ntpd user/group added. Of course, as a workaround user and group could be added manually. Mergemeaster also fails when it is run before installworld, what is IMHO predictable and expected behaviour. So mergemaster will not help with this issue. So the question arises, is it a feature or should a PR be submitted? can you share how you are running mergemaster? i recently upgraded a system from 11.2-RELEASE to 12-CURRENT without issues. my steps are: make buildkernel make buildworld make installkernel mergemaster -m /path/to/current/checkout -p make installworld mergemaster -m /path/to/current/checkout -a it is critical to run the mergemaster -p before installing the world. this will prompt you to update your /etc/password and /etc/group tables to add the new ntp user/group. the same goes for using the mergemaster -a switch after installing the world, as that will ensure that critical configs for rc are updated correctly. cheers, -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ntpd user and group missing when upgrading from sources from 11-stable to 12-current
On 9/13/18 4:07 PM, Marek Zarychta wrote: Dear subscribers, stable/12 hasn't been branched yet, so it could be not a bug. Since r336525 make installworld fails on 11-stable when installing world for 12-current without ntpd user/group added. Of course, as a workaround user and group could be added manually. Mergemeaster also fails when it is run before installworld, what is IMHO predictable and expected behaviour. So mergemaster will not help with this issue. So the question arises, is it a feature or should a PR be submitted? Did you run mergemaster with the -p flag before installworld? Eric ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
ntpd user and group missing when upgrading from sources from 11-stable to 12-current
Dear subscribers, stable/12 hasn't been branched yet, so it could be not a bug. Since r336525 make installworld fails on 11-stable when installing world for 12-current without ntpd user/group added. Of course, as a workaround user and group could be added manually. Mergemeaster also fails when it is run before installworld, what is IMHO predictable and expected behaviour. So mergemaster will not help with this issue. So the question arises, is it a feature or should a PR be submitted? -- Marek Zarychta signature.asc Description: PGP signature
Implementing my Quantum data parallization library as a FreeBSD module
Sorry if this message sounds a little off, I'm on meds But I have a C library that could be of use for bleeding edge BSD distrobutions: The code is hosted at github at https://github.com/unidef/quantum Basically, it implements huge multidimension arrays using pointers and structures, and features a way to move data in and out of the "neuron". Each neuron consists of a data structure that has a pointer to char description and features a broken multidimensional binary tree It's memory intensive for now since there is no code to write data to disk (I'm a little rusty on my C), and broken since I cant figure out #ifdef But it could be of use for the FreeBSD kernel, it follows the BSD license For convenience: git clone https://github.com/unidef/quantum . Sorry again for the crappy and incomplete code, been dealing with medical issues. If this is considered spam, please tell me and I will desist in future posts such as this. Thank you Bill "unidef" Profane ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SD card reader only works after a suspend/resume
On 9/13/18 12:13 AM, Marius Strobl wrote: On Fri, Sep 07, 2018 at 04:52:12PM +0200, Jakob Alvermark wrote: On 9/7/18 12:41 AM, Marius Strobl wrote: On Thu, Sep 06, 2018 at 12:33:39PM +0200, Jakob Alvermark wrote: Hi, I discovered this by chance. The SD card reader in my laptop has never worked, but now I noticed it does after suspending and resuming. The controller is probed and attached on boot: sdhci_acpi1: iomem 0x90a0-0x90a00fff irq 47 on acpi0 But nothing happens if I put a card in. Unless I suspend and resume: mmc1: on sdhci_acpi1 mmcsd0: 32GB at mmc1 50.0MHz/4bit/65535-block Then I can remove and replug cards and it seems to work just fine. I believe that making SD card insertion/removal with the integrated SDHCI controlers of newer Intel SoCs work out-of-the-box requires support for ACPI GPE interrupts and ACPI GPIO events respectively to be added to FreeBSD. Otherwise insertion/removal interrutps/events aren't reported and polling the card present state doesn't generally work as a workaround with these controllers either, unfortunately. I'm not aware of anyone working on the former, though. Polling the card present state happens to work one time after SDHCI initialization with these controllers which is why a card will be attached when inserted as part of a suspend/resume cycle (resume of mmc(4) had some bugs until some months ago, which probably explains why that procedure hasn't worked as a workaround for you in the past). Inserting the card before boot, unloading/loading sdhci_acpi.ko or triggering detach/attach of sdhci_acpi(4) via devctl(8) should allow to attach a card, too. If a card is inserted before booting it is not detected. Removing and inserting card after boot is not detected unless I suspend and resume. After I have suspended and resumed once, cards are detected. Removals and insertions are detected as they happen. Okay, then you are seeing somewhat different behavior than I do. What SoC model is this? CPU: Intel(R) Pentium(R) CPU N3540 @ 2.16GHz (2166.73-MHz K8-class CPU) Are you loading a GPIO controller driver such as bytgpio(4) or chvgpio(4)? Doing so might be sufficient to kick ACPI GPIO events into working but would be missing dependency information between drivers (which might explain what you are experiencing if sdhci_acpi1 attaches first) and some other bits to do it properly. I have bytgpio_load="YES" in /boot/loader.conf But I tried removing it, doesn't change the behavior. With or without the bytgpio driver, inserting or removing cards is only detected after a suspend/resume cycle of the computer. Also, could you please try whether doing a suspend/resume cycle of sdhci_acpi1 via devctl(8) only kicks the card detection into working? That test should indicate whether the firmware plays a role in making the latter work. Tried that. devctl suspend sdhci_acpi1 devctl resume sdhci_acpi1 Doesn't make any difference. Also tried devctl disable/enable. No change. Jakob ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Error when compiling lang/qt5-qml on today's CURRENT
On 13 Sep 2018, at 08:52, Piotr Kubaj wrote: > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > Preprocessed source(s) and associated run script(s) are located at: > c++: note: diagnostic msg: /tmp/qv4jit-c801df.cpp > c++: note: diagnostic msg: /tmp/qv4jit-c801df.sh > c++: note: diagnostic msg: > > > --- .obj/OSAllocatorPosix.o --- > --- .obj/qv4jit.o --- > *** [.obj/qv4jit.o] Error code 254 > > make[3]: stopped in > /tmp/usr/ports/lang/qt5-qml/work/qtdeclarative-everywhere-src-5.11.1/src/qml > > When I run /tmp/qv4jit-c801df.sh, I get: > Assertion failed: (TRI && "LivePhysRegs is not initialized."), function > addReg, file /usr/src/contrib/llvm/include/llvm/CodeGen/LivePhysRegs.h, line > 80. > Abort trap (core dumped) Can you please create a PR, and attach a compressed tarball with qv4jit-c801df.cpp and qv4jit-c801df.sh in it? You can assign the PR to me. -Dimitry signature.asc Description: Message signed with OpenPGP
Re: arc_reclaim_thread running hot
On 9/13/18 8:18 AM, Eric van Gyzen wrote:
This morning, I found the arc_reclaim_thread running hot on my laptop
running 12.0-ALPHA5 r338572.
vfs.zfs.arc_max="4294967296" <-- 4 GiB
last pid: 13288; load averages: 1.32, 1.26, 1.16
Mem: 456M Active, 3837M Inact, 743M Laundry, 2563M Wired, 167M Free
ARC: 1131M Total, 304M MFU, 145M MRU, 1344K Anon, 9116K Header, 671M Other
89M Compressed, 361M Uncompressed, 4.03:1 Ratio
22 root -8 - 0 256K CPU2 2 309:20 99.75%
zfskern{arc_reclaim_thread}
zfs_arc_meta_strategy is still the default of 1.
I sampled the thread's stacks with
for N in `jot 1000`; do procstat -kk 100101; done | grep 100101
and put the results here:
https://people.freebsd.org/~vangyzen/arc_reclaim_thread_stacks.txt
I'm happy to help debug this. Just let me know what you need.
The thread eventually returned to normal, and I've rebooted the system
since then, so I no longer have any state. The thread started running
hot at 03:00, so maybe the daily periodic run triggered it. I have to
work now, but I'll try running the periodic stuff manually when I have time.
Eric
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: arc_reclaim_thread running hot
On Thu, 13 Sep 2018 at 15:19, Eric van Gyzen wrote:
>
> This morning, I found the arc_reclaim_thread running hot on my laptop
> running 12.0-ALPHA5 r338572.
>
> vfs.zfs.arc_max="4294967296" <-- 4 GiB
>
> last pid: 13288; load averages: 1.32, 1.26, 1.16
>
> Mem: 456M Active, 3837M Inact, 743M Laundry, 2563M Wired, 167M Free
> ARC: 1131M Total, 304M MFU, 145M MRU, 1344K Anon, 9116K Header, 671M Other
> 89M Compressed, 361M Uncompressed, 4.03:1 Ratio
>
> 22 root -8- 0 256K CPU2 2 309:20 99.75%
> zfskern{arc_reclaim_thread}
>
> zfs_arc_meta_strategy is still the default of 1.
>
> I sampled the thread's stacks with
>
> for N in `jot 1000`; do procstat -kk 100101; done | grep 100101
>
> and put the results here:
>
> https://people.freebsd.org/~vangyzen/arc_reclaim_thread_stacks.txt
>
> I'm happy to help debug this. Just let me know what you need.
>
> Eric
Just to summarize, these are the top 15 active
(guessing that the leftmost function is "current"):
22 arc_space_return
22 uma_dbg_free
26 uma_dbg_alloc
30 mi_switch
31 uma_zalloc_arg
33 multilist_sublist_lock
34 __mtx_unlock_flags
39
46 _sx_xlock
48 hdr_full_cons
50 uma_zfree_arg
58 aggsum_add
91 arc_adjust
156 _sx_xunlock
185 arc_evict_state
And the top 15 in total
(that is, no matter where in the call stack):
44 multilist_sublist_lock
44 uma_dbg_free
46 _sx_xlock
47 uma_dbg_alloc
61 arc_space_return
127 aggsum_add
139 hdr_full_cons
156 _sx_xunlock
211 uma_zfree_arg
219 uma_zalloc_arg
833 arc_evict_state
926 arc_adjust
961 arc_reclaim_thread
961 fork_exit
961 fork_trampoline
(I have nothing sensible to add about the actual problem.)
--
Daniel Nebdal
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
arc_reclaim_thread running hot
This morning, I found the arc_reclaim_thread running hot on my laptop
running 12.0-ALPHA5 r338572.
vfs.zfs.arc_max="4294967296" <-- 4 GiB
last pid: 13288; load averages: 1.32, 1.26, 1.16
Mem: 456M Active, 3837M Inact, 743M Laundry, 2563M Wired, 167M Free
ARC: 1131M Total, 304M MFU, 145M MRU, 1344K Anon, 9116K Header, 671M Other
89M Compressed, 361M Uncompressed, 4.03:1 Ratio
22 root -8- 0 256K CPU2 2 309:20 99.75%
zfskern{arc_reclaim_thread}
zfs_arc_meta_strategy is still the default of 1.
I sampled the thread's stacks with
for N in `jot 1000`; do procstat -kk 100101; done | grep 100101
and put the results here:
https://people.freebsd.org/~vangyzen/arc_reclaim_thread_stacks.txt
I'm happy to help debug this. Just let me know what you need.
Eric
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: make packages fails recent -current
On 11.09.2018 16:20, Andreas Nilsson wrote: On Mon, Sep 10, 2018 at 5:55 PM Mikaël Urankar wrote: 2018-09-10 17:45 GMT+02:00 Andreas Nilsson : Hello, I have for about a week been trying to get new (base)packages built. make buildworld/buildkernel works as expected, however make packages has been failing: ===> Creating FreeBSD-runtime-12.0.s20180910124534 pkg: duplicate directory listing: /boot, ignoring pkg: duplicate directory listing: /etc, ignoring ... pkg: duplicate directory listing: /etc/syslog.d, ignoring pkg: duplicate directory listing: /root, ignoring pkg: duplicate directory listing: /root, ignoring pkg: duplicate directory listing: /root, ignoring pkg: Plist error, @config /root/.cshrc: not a regular file pkg: Plist error, @config /root/.profile: not a regular file pkg: duplicate file listing: /usr/bin/zstdegrep, ignoring pkg: duplicate directory listing: /usr/lib, ignoring pkg: duplicate directory listing: /usr/lib/dtrace, ignoring pkg: duplicate directory listing: /usr/lib/dtrace, ignoring pkg: duplicate directory listing: /usr/lib32, ignoring ... Is anyone else seeing this? This is on git 4e22ee37542 . I use metamode for building. I'm currently building from scratch just to rule out metamode. See https://lists.freebsd.org/pipermail/freebsd-pkgbase/2018-September/000383.html Thanks, that would explain it. Although even after installing pkg-devel-1.10.99.8 it still fails. Guess I'll have to wait for it to trickle into the packages. The rev. 479255 was an update to version 1.10.99.9. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serv ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Error when compiling lang/qt5-qml on today's CURRENT
--- .obj/qv4jit.o --- c++: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: c++: note: diagnostic msg: /tmp/qv4jit-c801df.cpp c++: note: diagnostic msg: /tmp/qv4jit-c801df.sh c++: note: diagnostic msg: --- .obj/OSAllocatorPosix.o --- --- .obj/qv4jit.o --- *** [.obj/qv4jit.o] Error code 254 make[3]: stopped in /tmp/usr/ports/lang/qt5-qml/work/qtdeclarative-everywhere-src-5.11.1/src/qml When I run /tmp/qv4jit-c801df.sh, I get: Assertion failed: (TRI && "LivePhysRegs is not initialized."), function addReg, file /usr/src/contrib/llvm/include/llvm/CodeGen/LivePhysRegs.h, line 80. Abort trap (core dumped) make.conf: BOOT_COMCONSOLE_SPEED=115200 BOOT_COMCONSOLE_PORT="0x2f8" CPUTYPE?=native DEVELOPER=yes DISTDIR=/tmp DEFAULT_VERSIONS= mysql=102m php=72 linux=c7_64 pgsql=10 ruby=2.5 python=3.6 ssl=libressl-devel DWM_CONF=/usr/ports/x11-wm/dwm/files/config.h ST_CONF=/usr/ports/x11/sterm/files/config.h WRKDIRPREFIX=/tmp When I remove CPUTYPE, it happens as well. -- __ / There is nothing wrong with Southern \ | California that a rise in the ocean | | level wouldn't cure. | | | \ -- Ross MacDonald/ -- \ ^__^ \ (oo)\___ (__)\ )\/\ ||w | || || signature.asc Description: PGP signature
Re: Speed problems with both system openssl and security/openssl-devel
Hello Dimitry, Thursday, September 13, 2018, 11:52:08 AM, you wrote: > I can't reproduce your findings, at least not on a Core i7-4790K: > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > FreeBSD 93454 89077 117328 281016 285456 > Ubuntu 93405 88892 114192 122346 120266 > FreeBSD-evp633283688010 700775 701168 700669 > Ubuntu-evp 623889681075 697211 700505 698460 > That was with base openssl 1.0.2p on FreeBSD 12-ALPHA5, and 1.1.0g on > Ubuntu 18.04. Here are additional numbers on J3160, with security/openssl111 port added: Lin 1.1.0f 18942 20637 21300 57967 58769 58769 Free 1.0.2p 18938 20627 21243 57940 58785 Free 1.1.0i 18929 20593 21285 58287 58766 58751 Free 1.1.1 18936 20588 21266 57923 58690 58731 Lin-evp 1.1.0f 97049 151466 183905 194385 197514 197727 Free-evp 1.0.2p 2828 10665 35364 81836 130502 Free-evp 1.1.0i 2869 10813 34932 81292 131308 137376 Free-evp 1.1.1 96959 151359 183390 194431 197076 197686 I've checked poudriere logs, all ports are built with -DAES_ASM. -- Best regards, Levmailto:l...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Speed problems with both system openssl and security/openssl-devel
Hello Dimitry, Thursday, September 13, 2018, 11:52:08 AM, you wrote: > I can't reproduce your findings, at least not on a Core i7-4790K: I can not reproduce it on E3-1220v3 + 11-STABLE either. But security/openssl111 works as expected on J3160 and it bothers me. Something is wrong not with hardware, but with software here. -- Best regards, Levmailto:l...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Speed problems with both system openssl and security/openssl-devel
On 13 Sep 2018, at 01:46, Lev Serebryakov wrote: > > I'm benchmarking new hardware (rather limited one, but still) which > supports AES-NI (Celeron J3160). > > I'm comparing simple "openssl speed aes-256-cbc" and "openssl speed -evp > aes-256-cbc" on FreeBSD 12-ALPHA4 (built by myself with all debug options > turned off) and Debian Linux 9.5.0 booted from install DVD (without > installation). > > Simple "openssl speed aes-256-cbc" shows same numbers both in > single-threaded and multi-threaded mode (for all 4 cores). Linux is > marginally faster, > but it is in the margin of measurement error. > > But "openssl speed -evp aes-256-cbc" gives me very disappointing results. > FreeBSD's openssl is WAY slower than Linux one. It is even slower than > non-evp mode for small blocks. > > Here are results (As reported by openssl, with fractions dropped): > > Lin 1894220637 21300 57967 58769 58769 > Free 1893120591 21282 58342 58731 58779 > Lin-evp 97049 151466 183905 194385 197514 197727 > Free-evp 283810845 35362 81892 131264 137579 > > Linux have openssl 1.1.0f, and I've tried both system /usr/bin/openssl > (1.0.2p) > and /usr/local/bin/openssl from security/openssl-devel port (1.1.0i), results > are > virtually the same. I have "ASM" and "SSE2" options enabled in port. > > What happens here? Why does FreeBSD's build of openssl use AES-NI so > inefficient? I can't reproduce your findings, at least not on a Core i7-4790K: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes FreeBSD 93454 89077 117328 281016 285456 Ubuntu 93405 88892 114192 122346 120266 FreeBSD-evp633283688010 700775 701168 700669 Ubuntu-evp 623889681075 697211 700505 698460 That was with base openssl 1.0.2p on FreeBSD 12-ALPHA5, and 1.1.0g on Ubuntu 18.04. -Dimitry signature.asc Description: Message signed with OpenPGP
Re: Speed problems with both system openssl and security/openssl-devel
Hello Kevin, Thursday, September 13, 2018, 6:32:30 AM, you wrote: > This is probably not the issue, but aesni is not in the GENERIC kernel. Are > you sure aesni.ko is loaded? > % kldstat | grep aesni I'm not using modules, as it is NanoBSD image build for minimal size ant maximal efficiency. But I have aesni in my kernel config for sure: % grep aesni ~/nanobsd/gatevay.v3/J3160 device aesni % -- Best regards, Levmailto:l...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
