intrinsics) can pessimize code.
Sometimes it is valuable to know exactly where AVX is used. I don't have
examples on hands, but I've seen situations, when autovectorized code was much
slower than scalar code.
--
// Lev Serebryakov
inserted/removed
May 14 16:01:27 supernovo kernel: rtsx0: Card absent
May 14 16:01:27 supernovo kernel: mmc0: detached
You insert card, driver thinks you remove it :)
--
// Lev Serebryakov
___
freebsd-current@freebsd.org mailing list
https
On 14.05.2021 11:22, Henri Hennebert wrote:
Please test the 2.0h version from GitHub.
Cold Boot with card: OK
Card removal after boot: OK
Cold Boot without card:OK
Card insertion after boot: OK
It is with 14-CURRENT n246524-95a74ab4fb0
--
// Lev Serebryakov
gable", as keyboard is working in ddb and crash dump
could be created. And I'm not sure, that GIANT in 2021 is good thing.
--
// Lev Serebryakov
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-cu
0: Interrupt card inserted/removed
rtsx0: Card present
rtsx0: A card is detected
mmc0: on rtsx0
pcib3: at device 28.1 on pci0
...
mmcsd0: 16GB at mmc0
50.0MHz/4bit/2048-block
...
No visible delays in both cases.
Both boots are "cold", with AC c
minal size.
This font is also passed to kernel and used as default font.
Gotcha! It is what I needed, thank you. "8x14" looks right!
--
// Lev Serebryakov
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinf
rtsx0: Interrupt card inserted/removed
rtsx0: Card absent
rtsx0: Card absent
pcib3: at device 28.1 on pci0
pci3: on pcib3
(no visible pause between two "Card absent" lines).
--
// Lev Serebryakov
___
freebsd-current@freebsd.org mailing list
h
On 13.05.2021 16:40, Henri Hennebert wrote:
try to rebuild your kernel with the attached patch.
Nope, same panic after cold (power-cycle) boot.
Can you try with "DELAY(50);"
to see if this is a path to dig further.
It helps with panic!
--
// Lev S
smooth),
"text resolution" is 80x25 still!
Adding "screen.font="16x32"" into "/boot/loader.conf" doesn't change anything.
Is it possible to have EFIFB resolution 1920x1080, but small font and lot of "text
resolution" from early boot o
efore it is detected as `atkbd` (keyboard in loader works!)
try to rebuild your kernel with the attached patch.
Nope, same panic after cold (power-cycle) boot.
--
// Lev Serebryakov
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.
is detected as `atkbd` (keyboard in loader works!)
--
// Lev Serebryakov
___
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"
It could explain, why in my case it crashes in different threads. And
sometimes in strlen() in stacktrace which contains rtsx functions!
--
// Lev Serebryakov
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freeb
th a "cold" boot and without a card inserted did you see something like:
rtsx0: <2.0c Realtek ...
rtsx0: Card present
mmc0: on rtsx0
rtsx0: Interrupt card inserted/removed
rtsx0: Card absent
When it panics, it panics before rtsx0 prints something in my case.
On 12.05.2021 21:01, Marc Veldman wrote:
I’m not sure if this is an interesting data point or not,
but a warm boot without the card inserted succeeds after
a cold boot with the card inserted.
It could explain, why my tests with "same code path" gave different results!
--
// Lev S
2363 28
cpu5:timer 3004 36
cpu6:timer 2990 36
cpu7:timer 2894 34
irq32: hdac0 6 0
irq33: xhci0 109175 1299
irq
ThinkPad T540p. I could provide remote
access to it, but it will not help for such low-level and early panic :-(
--
// Lev Serebryakov
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubsc
hen rtsx doesn't cause panic on boot, it still mangle
other devices detection & initialization.
I could provide any additional information. Unfortunately, memory dump of
panic-on-boot is impossible :-(
--
// Lev Serebryakov
___
freebsd-cur
lem on USB card readers, too.
My slot is empty, no card, no adapters, no plastic pseudo-card, nothing.
--
// Lev Serebryakov
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any m
On 07.05.2021 19:09, Jesper Schmitz Mouridsen wrote:
On 07.05.2021 13.33, Lev Serebryakov wrote:
Several versions of 14-CURRENT (including
FreeBSD-14.0-CURRENT-amd64-20210506-49c894ddced-246502-memstick.img) can not
boot on Lenovo T540p 19 times out of 20.
It crashes on device detection
e rtsx in them and are very generic. Looks like rtsx
mangle kernel memory and it crashes in other places/kernel threads.
--
// Lev Serebryakov
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To uns
and/or dump core.
13.0-RELEASE installation media crashes in same way if SD reader is enabled
in BIOS.
Is this with or without media in the SD reader?
It is without media in reader. I'll try with media later, as now I'm
rebuilding kernel to latest CURRENT.
--
// Lev S
On 07.05.2021 14:36, Lev Serebryakov wrote:
Looks like there is problem with rtsx driver!
Oh, I forgot to add: disabling SD Card Reader in BIOS solves problem!
And console on these crashes is totally dead, and disks are not detected yet,
so I can not look at structures in memory and
On 07.05.2021 14:33, Lev Serebryakov wrote:
Looks like there is problem with rtsx driver!
Oh, I forgot to add: disabling SD Card Reader in BIOS solves problem!
And console on these crashes is totally dead, and disks are not detected yet,
so I can not look at structures in memory and/or
oline()
Looks like there is problem with rtsx driver!
I've checked memory with memtest86+ for 24 hours (4.5 passes) without any
problems.
--
// Lev Serebryakov
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freeb
On 15.04.2021 22:19, Lev Serebryakov wrote:
calltrap()
--- trap 0x9
run_interrupt_driven_config_hooks()
boot_run_interrupt_driven_config_hooks()
mi_startup()
It is 100% reproducible, and I cannot issue commands to kernel debugger,
keyboard is dead.
Enabling verbose boot helps, with
rinting verbose information is not enough!
--
// Lev Serebryakov
___
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"
it is some race condition.
--
// Lev Serebryakov
___
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"
()
--- trap 0x9
run_interrupt_driven_config_hooks()
boot_run_interrupt_driven_config_hooks()
mi_startup()
It is 100% reproducible, and I cannot issue commands to kernel debugger,
keyboard is dead.
Enabling verbose boot helps, with verbose boot it boots to installer.
Looks like some race condition.
Is it known prob
ing status
information with source file ?
https://www.freebsd.org/releng/ ?
But I'm disappointed, that new page doesn't conttain dates of all old releases
in one neat table. I've used this table a lot :)
--
// Lev Serebryakov
___
fr
On 23.12.2020 18:04, Lev Serebryakov wrote:
On 23.12.2020 17:32, Michael Grimm wrote:
git-branch(1):
With a -m or -M option, will be renamed to .
If
==
had a corresponding reflog, it is renamed to match
stable/13 in the near future?
You should not use any options if you want to switch your working copy to new
branch. `-m` and `-M` *renames* branch!
--
// Lev Serebryakov
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailm
from pre-iflib driver? It did right things without
unneeded resets, including some `em` chips.
BTW, I'm surprised, that pre-iflib drivers still available on Intel site and
in ports. And sometimes works better :-(
--
// Lev Serebryakov
___
freeb
nfigure filters in clones automatically :-(
--
// Lev Serebryakov
___
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"
14.00.00.00, Driver: 23.00.00.00-fbsd
mpr0: IOCCapabilities:
7a85c
"man mpr" mentions LSI-3108 too, and "man mfi" doesn't mention LSI-3xxx chips.
Why does "mfi" attaches to LSI-3xxx? What is proper driver for these chips?
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
Hello Ian,
Thursday, May 28, 2020, 2:45:48 AM, you wrote:
> I noticed that my VLAN interfaces stopped working after a recent build.
> tcpdump showed traffic leaving leaving and entering the interface but no
> host on the network actually received any packets from this host. A
> binary search
had some unstable hardware which
could turn off due to overheating, and when I had UFS+SU, it could panic
in such way after reboot (typically after 5 or 10 minutes of normal
work)... I didn't report these panics, as was not enable to collect any
meningful information like crashdump or stack, as this system was
headless and consoleless.
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
Hello Yuri,
Sunday, April 5, 2020, 12:33:44 AM, you wrote:
>> CURRENT (and64, r359632) crashes very early on boot if
>> `/boot/loader.conf` contains this line:
>>
>> net.isr.dispatch="direct"
>>
>> Stacktrace (manually transcribed from photo of screen, as it is very early
>> stage of boot
Hello FreeBSD-Current,
CURRENT (and64, r359632) crashes very early on boot if
`/boot/loader.conf` contains this line:
net.isr.dispatch="direct"
Stacktrace (manually transcribed from photo of screen, as it is very early
stage of boot, so no crashdump possible):
calltrap()
--- trap 0xc
m
Hello freebsd-current,
Any kernel built from r356096 and later (till r357508 at least) panics
early (sometimes too early to print proper panic diagnostics!) with page
fault on this system when I have these options enabled in kernel config:
options RANDOM_LOADABLE
options RANDOM_ENABLE_UMA
It i
Hello Yasuhiro,
Saturday, February 15, 2020, 10:24:25 PM, you wrote:
> From: Lev Serebryakov
> Subject: Re: CURRENT panciks right after kernel load (r357966)
> Date: Sat, 15 Feb 2020 21:12:27 +0300
>> I didn't update this "firmware" for almost a year, and don&
Hello Yasuhiro,
Saturday, February 15, 2020, 9:54:25 PM, you wrote:
>> CURRENT r357966 on amd64, on host with 4G of memory (and Atom CPU) panics
>> with page fault right after kernel load (before any kernel output).
> I tried kernel update from r357653 to r357969 and boot completes
> successfu
Hello!
>> My last CURRENT build was at r357959 (and which booted without issue --
>> though the systems in question don't use ZFS); only commits I see to
>> head after r357959 are r357962 & r357967.
> r357508 works on "big iron" (Xeon E3-1220 with 32G of RAM) but pagefaults
> somewhat later:
>
Hello David,
Saturday, February 15, 2020, 9:02:53 PM, you wrote:
> My last CURRENT build was at r357959 (and which booted without issue --
> though the systems in question don't use ZFS); only commits I see to
> head after r357959 are r357962 & r357967.
r357508 works on "big iron" (Xeon E3-1220
Hello David,
Saturday, February 15, 2020, 9:02:53 PM, you wrote:
>> CURRENT r357966 on amd64, on host with 4G of memory (and Atom CPU) panics
>> with page fault right after kernel load (before any kernel output).
>>
>> Stacktrace (typed from photo of screen, all trap-related functions are
>>
Hello Current,
CURRENT r357966 on amd64, on host with 4G of memory (and Atom CPU) panics
with page fault right after kernel load (before any kernel output).
Stacktrace (typed from photo of screen, all trap-related functions are
omitted):
uma_zalloc_arg()
malloc()
sysctl_handle_string()
d:139
.if ${MK_ACPI} != "no" || ${MK_APM} != "no"
CONFS+= powerd
.endif
Why is it so? powerd(8) IS installed and WORKS well with these
WITHOUT_XXX options well, but could not be started at boot with these
options!
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
t; g_run_events
>> fork_exit
>> ...
>>
>> Has anybody touched this area recently? I'll try to narrow down the commit
>> range.
>
> Start with disassembling the faulting instruction. I suspect that somehow
> vital compiler switches like -mno-sse go
ou please look at, which helps NanoBSD to work better with
strange/broken hardware?
https://reviews.freebsd.org/D17102
https://reviews.freebsd.org/D17103
(I don't know do we need this for UEFI loader, though).
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
est/All/userland-base-20190420203550_7.txz
dist/FreeBSD:13:amd64/latest/All/userland-docs-20190420203550.txz
dist/FreeBSD:13:amd64/latest/All/userland-lib32-20190420203550.txz
#
I was under impression, that there is only 3 userland packages, not
100+ :-)
--
// Lev Serebryakov
signature.asc
Descrip
nf options to have ability to skip unneeded "optional" base
components (including, for example, man pages!).
And one more, not covered with src.conf WITHOUT_XXX: static libraries
and header files, of course!
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
On 15.02.2019 21:59, Ian Lepore wrote:
> My question would be: why? If some drivers have a new dependency on
> iflib, why isn't that expressed in sys/conf/files and handled
> automatically?
My question exactly.
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
only start the kernel.
Ok, I need to wait for it.
> But then again, if you are using stock (generic) OS on embedded system, you
> are already doing it wrong and will get into the trouble sooner or later:)
I can not say, is NanoBSD "stock" or not :-)
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
s the backup is created.
Does it live on code (root) FS or ESP? I understand, that when you
upgrade ESP partition, you could ruin it, but typically root FS is
upgraded much more often than ESP/boot0/boot1 parts.
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
On 20.01.2019 20:05, Warner Losh wrote:
> Is too complicated? Boot1.efi doesn't allow that, but loader.efi does.
loader.efi lives on ESP partition, do I understand it right? So, it
could not be damaged with "bad" upgrade?
--
// Lev Serebryakov
signature.asc
Descriptio
Hello Rebecca,
Sunday, January 20, 2019, 7:27:56 AM, you wrote:
> Ultimately, UEFI doesn't care about disks and partitions: it only really knows
> about ESPs -- FAT12/16/32 formatted partitions that contain the EFI directory
> structure. For now, that means /EFI/BOOT/BOOT{x64,i386,aa64,arm}.efi,
Hello Rebecca,
Saturday, January 19, 2019, 6:06:52 PM, you wrote:
> Ok, I've checked my desktop Asus Z170-A, but it is graphical and I could
> not find or understand anything in this home-rown UI with crazy-fast mouse.
> On ASUS systems you normally press F8 during POST to bring up the boot men
Hello Tomoaki,
Saturday, January 19, 2019, 4:42:21 AM, you wrote:
> I should note that 512-bytes boot0 doesn't have that feature.
> What had it WAS larger boot0ext, which has already gone on stable/11
> and later. IIRC, sysinstall let me select which to install on MBR.
It has, look at
src/stan
Hello Emmanuel,
Saturday, January 19, 2019, 12:10:13 AM, you wrote:
> With UEFI Boot* variable you could do :
> - Update previous partition and set BootNext to it
> - If it fail next boot will be on current partition due to BootOrder
> - If it succeed, change the BootOrder to have the new pa
Hello Warner,
Saturday, January 19, 2019, 12:17:29 AM, you wrote:
> Also most UEFI BIOSes I've used (which isn't a lot) allow one to choose
> which Boot variable to use to boot. Some will even create new Boot
> variables that they use when you choose a raw device to boot from.
I have nev
table
atteibute is set to it, "active" in case of MBR and "bootme" in case of
GPT).
If this new partition has problems and could not be booted, it is hard
to boot from "old" (previous) one. MBR + boot0 could (interactively)
change active partition before syste
It is why I write, that GPT/Legacy and GPT/UEFI miss
important feature which is present for MBR boot for ages. Which is sad &
funny at same time, as GPT/UEFI has much more code than 512 bytes of boot0.
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
partition itself.
> GPT does not have the concept of active partition.
It has "bootme" / "bootonce" attributes. And [zfs]gptboot doesn't have
any tools to set these attributes, AFAIK. Same for UEFI boot code.
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
gt; efibootmgr doesn't currently support it (it likely should).
All my UEFI-enabled systems have only one UEFI knob: "Boot:
[LEGACY|UEFI]", it's all :-(
It is not-so-new SuperMicro MoBos (X9, X10 generations), some Chinese
MiniPC, Intel D2500CC MoBo and such.
--
// Lev Serebry
very
beginning. This task is trivially solved by "boot0" in pure-MBR case.
What about GPT/Legacy and GPT/UEFI?
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
ve seen. Would this be usable on your appliances?
How could I set UEFI variable? Via BIOS/UEFI Setup? I don't see this at
my systems.
Also, there are same problems with GPT/BIOS setup (which uses GPT but
legacy boot) :-(
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
ot partition by MBR/boot0 and configuring
> early message redirection (with boot.config) is very useful.
> Not being able to do the same with GPT/EFI is the feature preventing me
> to upgrade my nanobsd image scheme.
My case exactly.
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
orted (as opposide to very-simple-516-bytes boot0!), and so on :-(
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
EAD) || !defined(ENOTRECOVERABLE) ||
!defined(EINTEGRITY)
^
/data/src/contrib/libc++/include/errno.h:34:2: error: unterminated
conditional directive
#ifdef __cplusplus
^
/data/src/contrib/libc++/include/errno.h:11:2: error: unterminated
conditional directive
#ifndef _LIBCPP_ERRNO_H
^
--
//
is error. I've had /usr/obj
from previous version (but I didn't use -DNO_CLEAN!).
> It almost looks as if your libclang.a is not rebuilt properly, or not
> built at all. Can you show the time stamps of:
I can not, as I cleaned up /usr/obj/src and now I have clean build.
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
Hello Lev,
Wednesday, December 12, 2018, 2:11:10 AM, you wrote:
Sorry for messed up subject, I mean r341836 of course.
--
Best regards,
Levmailto:l...@freebsd.org
___
freebsd-current@freebsd.org mailing list
https://list
Hello Freebsd-current,
I'm building very last r341836 (with new llvm/clang 7) on r341726 and get this
build
error (with MALLOC_PRODUCTION=yes):
===> usr.bin/clang/clang (all)
c++ -target x86_64-unknown-freebsd13.0
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/u
Hello Lev,
Saturday, December 8, 2018, 7:58:37 PM, you wrote:
>> Can you please narrow the problem down to a specific kernel revision?
> I'm still not sure it is software or hardware problem.
Looks like Samsung 850 EVO doesn't like TRIMs sent by ZFS (and I've thought
it is good SSD, consumer-gr
Hello Mateusz,
Saturday, December 8, 2018, 5:27:42 PM, you wrote:
>> Looks like each next compiler invocation is slower and more stressful than
>> previous one.
> Is this a fresh install?
Almost fresh. It was installed from some rather fresh 13 snapshot and then
upgraded to r341157 and custom
Hello Eugene,
Saturday, December 8, 2018, 4:27:13 PM, you wrote:
>> I'm completely lost. Is it problem of software? Hardware? If it is
>> hardware problem what should I blame?
> Try using different kern.timecounter.hardware and/or kern.eventtimer.timer
> but first try kern.eventtimer.periodic=1
Hello Lev,
Saturday, December 8, 2018, 2:13:03 PM, you wrote:
> Even when build is single-job, system becomes unresponsive. With
> 4-job build running it could takes up to minute to switch screen's windows!
And even with 1-job kernel build upsmon's connection to remote upsd
flickers! Unbelieva
Hello Lev,
Saturday, December 8, 2018, 2:13:03 PM, you wrote:
> Another strange thing I noticed: when system is in such state, "top -SH"
> shows that sometimes very low-profile processes, like clock software
> interrupt (!) could consume large amount of CPU for short periods time. When
> system
Hello Lev,
Saturday, December 8, 2018, 2:13:03 PM, you wrote:
> I've checked all "standard" places — CPU is not throttling, SSD looks
> perfectly Ok according to SMART and there is no complains from AHCI driver
> about timeouts and such, system doesn't start to use swap.
ZFS ARC was checked too
Hello Freebsd-hackers,
I'm experiencing very strange situation on my lab system which is
E3-1220v2, 8GiB of RAM and 850 EVO SATA SSD (with single ZFS pool).
It runs CURRENT r341157. Kernel is built *without* INVARIANTS and other
heavy debug aids.
Everything works great — but compilation. "mak
On 07.12.2018 18:02, Lev Serebryakov wrote:
>> (I'm not sure, that it is exactly "bug" or "defect" and want to
> ... discuss it here before filing PR.
>
>> Now I'm throwing IPsec into mix. All incoming traffic is tunneled with
>> IPs
On 07.12.2018 16:40, Lev Serebryakov wrote:
> (I'm not sure, that it is exactly "bug" or "defect" and want to
... discuss it here before filing PR.
> Now I'm throwing IPsec into mix. All incoming traffic is tunneled with
> IPsec policy, with aes-128-gcm
- Step = 1 Kpps
- Trend = increasing
- Measured forwarding rate = 86 Kpps
Estimated Equilibrium Ethernet throughput= 86 Kpps (maximum value seen:
120 Kpps)
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
Hello Ronald,
Saturday, December 1, 2018, 6:47:45 PM, you wrote:
> I got this response after gpart bootcode.
> Should I be worried?
> [AFTER make installkernel && make installworld]
> --
Installing everything completed on Sat Dec
ut it doesn't help.
Do I have any chances to get netmap supported (maybe, not very
efficient) on this NIC?
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
On 23.10.2018 17:25, Lev Serebryakov wrote:
>> Here are NO any errors or message on console, but system drops ssh
>> connection after several seconds (soemtimes before logon, sometimes
>> right after showing shell), timeouts connections to it, etc.
>>
>> Whe
On 23.10.2018 17:21, Lev Serebryakov wrote:
> Here are NO any errors or message on console, but system drops ssh
> connection after several seconds (soemtimes before logon, sometimes
> right after showing shell), timeouts connections to it, etc.
>
> When I able to run "t
n after several seconds (soemtimes before logon, sometimes
right after showing shell), timeouts connections to it, etc.
When I able to run "top -SH" (for several seconds!) it shows 98% idle!
--
// Lev Serebryakov
signature.asc
Description: OpenPGP digital signature
On 22.10.2018 12:27, Toomas Soome wrote:
> It would help to get output from loader lsdev -v command.
current loader crashes on "lsdev" for me:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232483 (it is not
threadripper-related, my hardware is Intel Atom).
--
// Le
I have reproducible crash of ALPHA7 when I try to benchmark IPsec.
Could somebody look at it? I could provide additional info, if needed.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231659
--
// Lev Serebryakov
___
freebsd-current
Hello Lev,
Thursday, September 13, 2018, 2:46:46 AM, you wrote:
> 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 enab
ork_exit() at fork_exit+0x84/frame 0xfe44aab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe44aab0
--
// Lev Serebryakov
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsu
it refuses to use
AES. No much luck, though, openssl sources are very convoluted :-(
> This seems like the sort of code that plausibly could bring out some
> compiler corner cases. (It's weird that 1.1.1 is fine, though.)
--
// Lev Serebryakov
___
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).
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 934
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 har
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.
Hello Brnrd,
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
)
cpu2: MSR_IA32_TEMPERATURE_TARGET: 0x005a (90 C)
--
// Lev Serebryakov
___
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"
ble, as
it is higher than official Turbo frequency (!). I don't know how to
explain this. Maybe, turbostat fails?
--
// Lev Serebryakov
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscrib
Hello Benjamin,
Thursday, September 6, 2018, 1:32:46 AM, you wrote:
>> > I don't think you need something accurate.
>> Ok, here is results. I'm working in single-user mode.
>>
>> TL;DR "Turbo" mode make "openssl" much slower (x3.5)!
>>
>> I can not properly interpret this result.
> You need
4 bytes256 bytes 1024 bytes 8192 bytes
aes-256 cbc 16277.18k20620.71k21272.10k57998.35k58687.83k
--
// Lev Serebryakov
___
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"
1 - 100 of 411 matches
Mail list logo
