Re: HEADSUP: Something has gone south with -current
On Fri, Dec 07, 2018 at 05:02:03PM -0800, Steve Kargl wrote: > On Sat, Dec 08, 2018 at 02:43:17AM +0200, Konstantin Belousov wrote: > > On Fri, Dec 07, 2018 at 04:25:39PM -0800, Steve Kargl wrote: > > > On Sat, Dec 08, 2018 at 02:08:20AM +0200, Konstantin Belousov wrote: > > > > > > > > Most likely this is an issue fixed by r339350. > > > > > > My tree is at r341703. The last paragraph of the commit > > > message for r339350 is > > Which tree ? The strip that is used by install should be past this > > revision. > > > This is the /usr/src that has led to the broken static binaries. > > Looking at timestamps, I have > > % ls -l /usr/bin/strip > -r-xr-xr-x 2 root wheel - 131144 Oct 10 17:10 /usr/bin/strip* > > which is the strip from my Oct 10 build. This strip did not get > updated because 'make installworld' died. Does install during > an installworld use the old strip instead of freshly built strip? > Looks like /usr/src/UPDATING could use an entry about r339350. I was updating an r339290 world to r341703. This jumps across r339350. /usr/bin/strip from r339290 apparently is used during installworld, which renders a system rather broken. 20181013: At r339350, /usr/bin/strip was updated to deal with the introduction of ifuncs into FreeBSD. In particular, a /usr/bin/strip from an earlier revision can lead to a broken system. To avoid mayhem, it is suggested that one does cd /usr/src/usr.bin/objcopy make install prior to 'make installworld' -- Steve ___ 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: HEADSUP: Something has gone south with -current
On Fri, Dec 07, 2018 at 05:02:03PM -0800, Steve Kargl wrote: > On Sat, Dec 08, 2018 at 02:43:17AM +0200, Konstantin Belousov wrote: > > On Fri, Dec 07, 2018 at 04:25:39PM -0800, Steve Kargl wrote: > > > On Sat, Dec 08, 2018 at 02:08:20AM +0200, Konstantin Belousov wrote: > > > > > > > > Most likely this is an issue fixed by r339350. > > > > > > My tree is at r341703. The last paragraph of the commit > > > message for r339350 is > > Which tree ? The strip that is used by install should be past this > > revision. > > > > % cd /usr/src > % svn info > Path: . > Working Copy Root Path: /usr/src > URL: svn://svn.freebsd.org/base/head > Relative URL: ^/head > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 341703 > Node Kind: directory > Schedule: normal > Last Changed Author: emaste > Last Changed Rev: 341703 > Last Changed Date: 2018-12-07 08:52:52 -0800 (Fri, 07 Dec 2018) > > This is the /usr/src that has led to the broken static binaries. > > Looking at timestamps, I have > > % ls -l /usr/bin/strip > -r-xr-xr-x 2 root wheel - 131144 Oct 10 17:10 /usr/bin/strip* > > which is the strip from my Oct 10 build. This strip did not get > updated because 'make installworld' died. Does install during > an installworld use the old strip instead of freshly built strip? It is installed (host) strip that is used, AFAIK. You can build static lib/libelftc and usr.bin/strip from the later date and install it to get past the issue. ___ 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: HEADSUP: Something has gone south with -current
On Sat, Dec 08, 2018 at 02:43:17AM +0200, Konstantin Belousov wrote: > On Fri, Dec 07, 2018 at 04:25:39PM -0800, Steve Kargl wrote: > > On Sat, Dec 08, 2018 at 02:08:20AM +0200, Konstantin Belousov wrote: > > > > > > Most likely this is an issue fixed by r339350. > > > > My tree is at r341703. The last paragraph of the commit > > message for r339350 is > Which tree ? The strip that is used by install should be past this > revision. > % cd /usr/src % svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 341703 Node Kind: directory Schedule: normal Last Changed Author: emaste Last Changed Rev: 341703 Last Changed Date: 2018-12-07 08:52:52 -0800 (Fri, 07 Dec 2018) This is the /usr/src that has led to the broken static binaries. Looking at timestamps, I have % ls -l /usr/bin/strip -r-xr-xr-x 2 root wheel - 131144 Oct 10 17:10 /usr/bin/strip* which is the strip from my Oct 10 build. This strip did not get updated because 'make installworld' died. Does install during an installworld use the old strip instead of freshly built strip? -- Steve ___ 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: HEADSUP: Something has gone south with -current
On Fri, Dec 07, 2018 at 04:25:39PM -0800, Steve Kargl wrote: > On Sat, Dec 08, 2018 at 02:08:20AM +0200, Konstantin Belousov wrote: > > On Fri, Dec 07, 2018 at 03:52:33PM -0800, Steve Kargl wrote: > > > On Fri, Dec 07, 2018 at 03:30:19PM -0800, Steve Kargl wrote: > > > > On Fri, Dec 07, 2018 at 03:06:22PM -0800, Steve Kargl wrote: > > > > > > > > > > make core dumps. > > > > > devd core dumps. > > > > > init core dumps. > > > > > cc core dumps. > > > > > c++ core dumps. > > > > > > > > > > Something seems to be broken. > > > > > > > > > > > > > Further investigation, > > > > as core dumps. > > > > cpp core dumps. > > > > /rescue/vi core dumps. > > > > > > > > All of these programs are statically linked. Note, ar and ranlib > > > > have static linkage, and appear to still work but these were not > > > > replaced by the failing 'make installworld'. > > > > > > > > Ah, so if I go into /usr/obj/usr/src/amd64.amd64/ar, this ar > > > > is static and not stripped and works! But, if I do > > > > > > > > cp ar ar.new > > > > strip ar > > > > ./ar > > > > > > > > This ar core dumps. So, stripping static binaries seems to > > > > break the binary. > > > > > > > > > > Yep, definitely, a problem with stripping static binaries. > > > > > > I copied both init and devd from /usr/obj to /sbin without > > > stripping the binaries. System rebooted as expected. > > > > Most likely this is an issue fixed by r339350. > > My tree is at r341703. The last paragraph of the commit > message for r339350 is Which tree ? The strip that is used by install should be past this revision. > > Just remove filter_reloc. This fixes certain cases including statically > linked binaries containing ifuncs. Stripping binaries with relocations > referencing removed symbols was already broken, and after this change > may still be broken in a different way. > > So, I guess I'm hitting the "broken in a different way". > > The gdb82 backtrace ends up in jemalloc. I do build world with > MALLOC_PRODUCTION="YES". Perhaps, ifuncs+jemalloc aren't at > production level. I have few more broken static binaries that > I need to replace before I can rebuild without MALLOC_PRODUCTION. > > -- > Steve ___ 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: HEADSUP: Something has gone south with -current
On Sat, Dec 08, 2018 at 02:08:20AM +0200, Konstantin Belousov wrote: > On Fri, Dec 07, 2018 at 03:52:33PM -0800, Steve Kargl wrote: > > On Fri, Dec 07, 2018 at 03:30:19PM -0800, Steve Kargl wrote: > > > On Fri, Dec 07, 2018 at 03:06:22PM -0800, Steve Kargl wrote: > > > > > > > > make core dumps. > > > > devd core dumps. > > > > init core dumps. > > > > cc core dumps. > > > > c++ core dumps. > > > > > > > > Something seems to be broken. > > > > > > > > > > Further investigation, > > > as core dumps. > > > cpp core dumps. > > > /rescue/vi core dumps. > > > > > > All of these programs are statically linked. Note, ar and ranlib > > > have static linkage, and appear to still work but these were not > > > replaced by the failing 'make installworld'. > > > > > > Ah, so if I go into /usr/obj/usr/src/amd64.amd64/ar, this ar > > > is static and not stripped and works! But, if I do > > > > > > cp ar ar.new > > > strip ar > > > ./ar > > > > > > This ar core dumps. So, stripping static binaries seems to > > > break the binary. > > > > > > > Yep, definitely, a problem with stripping static binaries. > > > > I copied both init and devd from /usr/obj to /sbin without > > stripping the binaries. System rebooted as expected. > > Most likely this is an issue fixed by r339350. My tree is at r341703. The last paragraph of the commit message for r339350 is Just remove filter_reloc. This fixes certain cases including statically linked binaries containing ifuncs. Stripping binaries with relocations referencing removed symbols was already broken, and after this change may still be broken in a different way. So, I guess I'm hitting the "broken in a different way". The gdb82 backtrace ends up in jemalloc. I do build world with MALLOC_PRODUCTION="YES". Perhaps, ifuncs+jemalloc aren't at production level. I have few more broken static binaries that I need to replace before I can rebuild without MALLOC_PRODUCTION. -- Steve ___ 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: HEADSUP: Something has gone south with -current
On Fri, Dec 07, 2018 at 03:52:33PM -0800, Steve Kargl wrote: > On Fri, Dec 07, 2018 at 03:30:19PM -0800, Steve Kargl wrote: > > On Fri, Dec 07, 2018 at 03:06:22PM -0800, Steve Kargl wrote: > > > > > > make core dumps. > > > devd core dumps. > > > init core dumps. > > > cc core dumps. > > > c++ core dumps. > > > > > > Something seems to be broken. > > > > > > > Further investigation, > > as core dumps. > > cpp core dumps. > > /rescue/vi core dumps. > > > > All of these programs are statically linked. Note, ar and ranlib > > have static linkage, and appear to still work but these were not > > replaced by the failing 'make installworld'. > > > > Ah, so if I go into /usr/obj/usr/src/amd64.amd64/ar, this ar > > is static and not stripped and works! But, if I do > > > > cp ar ar.new > > strip ar > > ./ar > > > > This ar core dumps. So, stripping static binaries seems to > > break the binary. > > > > Yep, definitely, a problem with stripping static binaries. > > I copied both init and devd from /usr/obj to /sbin without > stripping the binaries. System rebooted as expected. Most likely this is an issue fixed by r339350. ___ 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: HEADSUP: Something has gone south with -current
On Fri, Dec 07, 2018 at 03:52:33PM -0800, Steve Kargl wrote: > On Fri, Dec 07, 2018 at 03:30:19PM -0800, Steve Kargl wrote: > > On Fri, Dec 07, 2018 at 03:06:22PM -0800, Steve Kargl wrote: > > > > > > make core dumps. > > > devd core dumps. > > > init core dumps. > > > cc core dumps. > > > c++ core dumps. > > > > > > Something seems to be broken. > > > > > > > Further investigation, > > as core dumps. > > cpp core dumps. > > /rescue/vi core dumps. > > > > All of these programs are statically linked. Note, ar and ranlib > > have static linkage, and appear to still work but these were not > > replaced by the failing 'make installworld'. > > > > Ah, so if I go into /usr/obj/usr/src/amd64.amd64/ar, this ar > > is static and not stripped and works! But, if I do > > > > cp ar ar.new > > strip ar > > ./ar > > > > This ar core dumps. So, stripping static binaries seems to > > break the binary. > > > > Yep, definitely, a problem with stripping static binaries. > > I copied both init and devd from /usr/obj to /sbin without > stripping the binaries. System rebooted as expected. > Don't know if it's valid, but % ./ar % gdb82 ar.new ar.core Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0029386c in __je_malloc_tsd_boot0 () (gdb) bt #0 0x0029386c in __je_malloc_tsd_boot0 () #1 0x002b6d08 in calloc () #2 0x0028275b in _thr_alloc () #3 0x0027ec98 in _libpthread_init () #4 0x0024d239 in handle_static_init () #5 0x0024d10e in _start () -- Steve ___ 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: HEADSUP: Something has gone south with -current
On Fri, Dec 07, 2018 at 03:30:19PM -0800, Steve Kargl wrote: > On Fri, Dec 07, 2018 at 03:06:22PM -0800, Steve Kargl wrote: > > > > make core dumps. > > devd core dumps. > > init core dumps. > > cc core dumps. > > c++ core dumps. > > > > Something seems to be broken. > > > > Further investigation, > as core dumps. > cpp core dumps. > /rescue/vi core dumps. > > All of these programs are statically linked. Note, ar and ranlib > have static linkage, and appear to still work but these were not > replaced by the failing 'make installworld'. > > Ah, so if I go into /usr/obj/usr/src/amd64.amd64/ar, this ar > is static and not stripped and works! But, if I do > > cp ar ar.new > strip ar > ./ar > > This ar core dumps. So, stripping static binaries seems to > break the binary. > Yep, definitely, a problem with stripping static binaries. I copied both init and devd from /usr/obj to /sbin without stripping the binaries. System rebooted as expected. -- Steve ___ 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: HEADSUP: Something has gone south with -current
On Fri, Dec 07, 2018 at 06:23:57PM -0500, Shawn Webb wrote: > On Fri, Dec 07, 2018 at 03:06:22PM -0800, Steve Kargl wrote: > > Dell 7510 laptop was happily running FreeBSD12-alpha9 > > from Oct. 10th. I decided to update to top-of-tree > > today, which would be FreeBSD13 at r341703. > > analysis > > > > make core dumps. > > devd core dumps. > > init core dumps. > > cc core dumps. > > c++ core dumps. > > > > Something seems to be broken. > > There have been (and still are) issues with the introduction of ifunc > in libc (r339898). The symptoms you're describing sound a lot like the > symptoms I experienced early on. > > Do you have any non-standard settings in make.conf/src.conf? > Both are fairly benign. make.conf contains MALLOC_PRODUCTION="YES" and src.conf contains a few WITHOUT_* options (eg, CTM, PPP, NDIS). It seems to be associated with stripping static binaries. See my follow-up post. -- Steve ___ 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: HEADSUP: Something has gone south with -current
On Fri, Dec 07, 2018 at 03:06:22PM -0800, Steve Kargl wrote: > > make core dumps. > devd core dumps. > init core dumps. > cc core dumps. > c++ core dumps. > > Something seems to be broken. > Further investigation, as core dumps. cpp core dumps. /rescue/vi core dumps. All of these programs are statically linked. Note, ar and ranlib have static linkage, and appear to still work but these were not replaced by the failing 'make installworld'. Ah, so if I go into /usr/obj/usr/src/amd64.amd64/ar, this ar is static and not stripped and works! But, if I do cp ar ar.new strip ar ./ar This ar core dumps. So, stripping static binaries seems to break the binary. -- Steve ___ 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: HEADSUP: Something has gone south with -current
On Fri, Dec 07, 2018 at 03:06:22PM -0800, Steve Kargl wrote: > Dell 7510 laptop was happily running FreeBSD12-alpha9 > from Oct. 10th. I decided to update to top-of-tree > today, which would be FreeBSD13 at r341703. > > % cd /usr/obj > % rm -rf usr > % cd ../src > % svn update > % make -j6 buildwould (OK) > % make -j6 buildkernel (OK) > % make installkernel(OK) > % mergemaster -p > % > % mount -a > % cd /usr/src > % make installworld > > Dies with a segfault in make(1) half way through the update. > /sbin has been update. > > Rebooted with new kernel. Laptop locks up. > Rebooted with kernel.old/kernel (known good kernel). Laptop locks up. > Rebooted with verbose info. Lockup occurs right after > > Starting /sbin/init > > is printed to console. > > Reboot to Dell laptop BIOS and run system diagnostics. > > Reboot with old FreeBSD installation cdrom. Mounted the > laptop's root filesystem on /mnt. > > % chflags nochgs /mnt/sbin/init > % cp /mnt/sbin/init.bak /mnt/sbin/init > > Reboot laptop and finally get back to multi-user mode. Post trauma > analysis > > make core dumps. > devd core dumps. > init core dumps. > cc core dumps. > c++ core dumps. > > Something seems to be broken. There have been (and still are) issues with the introduction of ifunc in libc (r339898). The symptoms you're describing sound a lot like the symptoms I experienced early on. Do you have any non-standard settings in make.conf/src.conf? Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
HEADSUP: Something has gone south with -current
Dell 7510 laptop was happily running FreeBSD12-alpha9 from Oct. 10th. I decided to update to top-of-tree today, which would be FreeBSD13 at r341703. % cd /usr/obj % rm -rf usr % cd ../src % svn update % make -j6 buildwould (OK) % make -j6 buildkernel (OK) % make installkernel(OK) % mergemaster -p % % mount -a % cd /usr/src % make installworld Dies with a segfault in make(1) half way through the update. /sbin has been update. Rebooted with new kernel. Laptop locks up. Rebooted with kernel.old/kernel (known good kernel). Laptop locks up. Rebooted with verbose info. Lockup occurs right after Starting /sbin/init is printed to console. Reboot to Dell laptop BIOS and run system diagnostics. Reboot with old FreeBSD installation cdrom. Mounted the laptop's root filesystem on /mnt. % chflags nochgs /mnt/sbin/init % cp /mnt/sbin/init.bak /mnt/sbin/init Reboot laptop and finally get back to multi-user mode. Post trauma analysis make core dumps. devd core dumps. init core dumps. cc core dumps. c++ core dumps. Something seems to be broken. -- Steve ___ 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: Boot loader stuck after first stage upgrading 11.2 to 12.0-RC2
On 05/12/2018 00:48, Toomas Soome wrote:
Yes, that must be true but it does not hurt to get checked.
And of course, lsdev -v from 11.x loader would be good too.
Anyhow, I am afraid we have reached to point where more specific debug info is
needed (printed out), with lack of output about disks at all, it must be
related to floppy device checks.
Just another point in time.
Ended up more or less in the same situation this afternoon with
freebsd-upgrade to RC3
Boot stops after listing all DOS disks, in a spinner.
So that is no fix.
I booted from USB 11.2 and replaced the /boot/zfs{boot,loader} by the
11.2 ones.
That makes my server again happy.
--WjW
Rgds,
Toomas
Sent from my iPhone
On 4 Dec 2018, at 22:19, Ian Lepore wrote:
On Tue, 2018-12-04 at 21:51 +0200, Toomas Soome via freebsd-stable
wrote:
On 4 Dec 2018, at 19:59, Mark Martinec wrote:
2018-11-29 18:43, Toomas Soome wrote:
I just did push biosdisk updates to stable/12, I wonder if
you could
test those bits…
Myself wrote:
Thank you! I haven't tried it yet, but I wonder whether this
fix was
already incorporated into 12.0-RC3, which would make my rescue
easier.
Otherwise I can build a stable/12 on another host and
transplant
the problematic file(s) to the affected host - if I knew which
files
to copy.
2018-12-02 18:59, Toomas wrote:
The files are /boot/loader* binaries - to be exact, check which
one is
linked to /boot/loader. I can provide binaries if needed.
[...]
rgds,
toomas
I got a maintenance window today so I tried with the new loader,
and it did not help.
More specifically:
As it comes with 12-RC2, the /boot/loader was hard linked with
loader_lua.
Its size is 421888 bytes. So I concentrated on this loader.
I build a fresh stable/12 on another host, and copied the newly
built loader_lua (425984 bytes) to the /boot directory of the
affected
host, deleted the file 'loader', and hard-linked loader_lua to
loader.
The situation has not changed: the BTX loader lists all BIOS drives
C..J (disk0..disk7), then a spinner starts and gets stuck forever.
It never reaches the 'BIOS 635kB/3537856kB available memory' line.
While trying to restore the old /boot from 11.2, I tried booting
a live image from a 12.0-RC3 memory stick - and the loader got
stuck again, same as when booting from a disk.
So I had to boot from an 11.2 memstick to be able to regain
control.
Mark
ok, if you could perform 2 tests:
1. from loader prompt enter 0x413 0xa000 - @w . cr
2. on first spinner, press space and type on boot: prompt:
/boot/loader_4th and see if that will do better
thanks,
toomas
I don't think that will be an option. If it hasn't gotten to the point
of saying how much BIOS available memory there is, it's only halfway
through loader main() and has hung before getting to interact().
In fact, if that line hasn't printed, but some disk drives have been
listed, it pretty much has to be hung in the "March through the device
switch probing for things" loop. If all the disks are listed, then it
got through that entry in the devsw, and is likely hanging in the
dv_init calls for either the pxedisk or zfsdev devices.
-- Ian
On 29 Nov 2018, at 17:01, Mark Martinec wrote:
After successfully upgraded three hosts from 11.2-p4 to
12.0-RC2 (amd64,
zfs, bios), I tried my luck with one of our production
hosts, and ended up
with a stuck loader after rebooting with a new kernel
(after the first
stage of upgrade).
These were the steps, and all went smoothly and normally
until a reboot:
freebsd-update upgrade -r 12.0-RC2
freebsd-update install
shutdown -r now
While booting, the 'BTX loader' comes up, lists the BIOS
drives,
then the spinner below the list comes up and begins
turning,
stuttering, and after a couple of seconds it grinds to a
standstill
and nothing happens afterwards.
At this point the ZFS and the bootstrap loader is supposed
to
come up, but it doesn't.
This host has too zfs pools, the system pool consists of
two SSDs
in a zfs mirror (also holding a freebsd-boot partition
each), the
other pool is a raidz2 with six JBOD disks on an LSI
controller.
The gptzfsboot in both freebsd-boot partitions is fresh
from 11.2,
both zpool versions are up-to-date with 11.2. The 'zpool
status -v'
is happy with both pools.
After rebooting from an USB drive and reverting the /boot
directory
to a previous version, the machine comes up normally again
with the 11.2-RELEASE-p4.
I found a file init.core in the / directory, slightly
predating the
last reboot with a salvaged system - although it was
probably not
a cause of the problem, but a consequence of the rescue
operation.
It is unfortunate that this is a production host, so I
can't play
much with it. One or two more quick experiments I can
probably
afford, but not much more. Should I just first wait for the
official 12.0 release? Should I try booting with a 12.0 on
USB
and try to import pools? Suggestions welcome.
Now that the /boot has been manually restored to the 11.2
state,
A SECOND QUESTION is
Re: iflib.tx_abdicate: very strange behavior on incoming IPsec traffic (regression?)
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 >> IPsec policy, with aes-128-gcm encryption. And with IPsec tx_abdicate >> makes thing much worse and much more unstable. > I could say, that it doesn't matter, if I using IPsec with "tunnel" > policy to encrypt and tunnel transit traffic or if I add "gif" into mix > and encrypt GIF traffic in "transport" mode. In both cases tx_abdicate > makes PPS much lower. And one more datapoint: if I'm using "null" cipher (so, IPsec is in play, but no real encryption is performed) losses in packet rate are about 50% from turning on tx_abdicate. It is worst-case scenario. And if I have outbound traffic (traffic is received without IPsec processing and sent with IPsec processing on other interface) I have noticeable gains, up to 15% in packets per second and bandwidth. So, lookslike tx_abdicate works well when it is applied to non-IPsec-processed traffic. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
Re: iflib.tx_abdicate: very strange behavior on incoming IPsec traffic (regression?)
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 encryption. And with IPsec tx_abdicate > makes thing much worse and much more unstable. I could say, that it doesn't matter, if I using IPsec with "tunnel" policy to encrypt and tunnel transit traffic or if I add "gif" into mix and encrypt GIF traffic in "transport" mode. In both cases tx_abdicate makes PPS much lower. -- // Lev Serebryakov signature.asc Description: OpenPGP digital signature
iflib.tx_abdicate: very strange behavior on incoming IPsec traffic (regression?)
(I'm not sure, that it is exactly "bug" or "defect" and want to I've found very strange behavior of 13-CURRENT system I210 (igb) interfaces and enabled "dev.igb.X.iflib.tx_abdicate". I'm measuring "router" performance with BSDRP's "equilibrium" script (thank you, Oliver, for this great tool!). It generates traffic to route with pkt-gen and try to find packet rate / bandwidth with binary search. I'm testing simple UDP traffic via physical connection, without any GIF/GRE and other pseudo-interfaces. Router pass UDP traffic from igb1 to igb0, and this traffic is for ONLY ONE IP:PORT pair, as I'm imitating edge router for small network where only one host will receive huge amounts of traffic (i.e. torrent-box). When I enable "dev.igb.X.iflib.tx_abdicate" on both igb1 (inbound) and igb0 (outbound) interface, packet per second become a little better. So far so good. Now I'm throwing IPsec into mix. All incoming traffic is tunneled with IPsec policy, with aes-128-gcm encryption. And with IPsec tx_abdicate makes thing much worse and much more unstable. There is results without tx_abdicate: 480Mbit/s, 182Kpps And it is results with tx_abdicate: 352MBit/s, 85Kpps. And what is worse, "equilibrium" script starts to see unstable packet rate. Without tx_abdicate or without IPsec process of searching for "maximum" packet rate is very stable: each next measurement in binary search looks like previous, there is no big jumps and found "equilibrium" rate is very close to "maximum seen", and overloaded router shows rate smaller than equilibrium one). But with both "tx_abdicate" and IPsec it looks like (please, note, that overloaded router shows much better rate than not-overloaded): Benchmark tool using equilibrium throughput method - Benchmark mode: Throughput (pps) for Router - UDP load = 18B, IPv4 packet size=46B, Ethernet frame size=60B - Link rate = 1488 Kpps - Tolerance = 0.01 Iteration 1 - Offering load = 744 Kpps - Step = 372 Kpps - Measured forwarding rate = 120 Kpps - Forwared rate too low, forcing OLOAD=FWRATE and STEP=FWRATE/2 Iteration 2 - Offering load = 120 Kpps - Step = 60 Kpps - Trend = decreasing - Measured forwarding rate = 81 Kpps Iteration 3 - Offering load = 60 Kpps - Step = 60 Kpps - Trend = decreasing - Measured forwarding rate = 60 Kpps Iteration 4 - Offering load = 90 Kpps - Step = 30 Kpps - Trend = increasing - Measured forwarding rate = 84 Kpps Iteration 5 - Offering load = 75 Kpps - Step = 15 Kpps - Trend = decreasing - Measured forwarding rate = 75 Kpps Iteration 6 - Offering load = 82 Kpps - Step = 7 Kpps - Trend = increasing - Measured forwarding rate = 81 Kpps Iteration 7 - Offering load = 85 Kpps - Step = 3 Kpps - Trend = increasing - Measured forwarding rate = 85 Kpps Iteration 8 - Offering load = 86 Kpps - 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
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 Andriy Gapon changed: What|Removed |Added Assignee|a...@freebsd.org|a...@freebsd.org Status|Open|In Progress -- You are receiving this mail because: You are on the CC list for the bug. ___ 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: rm cannot recursively delete directory on tmpfs on RPi2
On 07.12.2018 10:59, Mateusz Guzik wrote: > On 12/7/18, Michal Meloun wrote: >> >> >> On 07.12.2018 7:25, Mateusz Guzik wrote: >>> On 12/7/18, Jia-Shiun Li wrote: On Fri, Dec 7, 2018 at 12:36 AM Alan Somers wrote: > On Wed, Dec 5, 2018 at 10:18 PM Jia-Shiun Li > wrote: >> >> amd64 and RPi3 do not have this issue. >> >> jsli@rpi2:/home/jsli 13:04 # uname -a >> FreeBSD rpi2 13.0-CURRENT FreeBSD 13.0-CURRENT r341419 GENERIC-NODEBUG > arm >> jsli@rpi2:/home/jsli 13:05 # mount -t tmpfs tmpfs /mnt >> jsli@rpi2:/home/jsli 13:05 # cd /mnt >> jsli@rpi2:/mnt 13:05 # tar xf >> /usr/ports/distfiles/sqlite-autoconf-326.tar.gz >> jsli@rpi2:/mnt 13:05 # rm -rf sqlite-autoconf-326/ >> rm: sqlite-autoconf-326/tea: Operation not permitted >> rm: sqlite-autoconf-326/: Directory not empty >> jsli@rpi2:/mnt 13:05 # >> >> -Jia-Shiun > > Did you check for file flags? Do "ls -lod > sqlite-autoconf-326/tea". > > Unlikely caused by flags I think. jsli@rpi2:/home/jsli # mount -t tmpfs tmpfs /mnt jsli@rpi2:/home/jsli # cd /mnt jsli@rpi2:/mnt # ls -R jsli@rpi2:/mnt # mkdir dir jsli@rpi2:/mnt # ls -R dir/ ls: dir: directory causes a cycle jsli@rpi2:/mnt # looks inode no for directories are wrong jsli@rpi2:/mnt # ll -ia total 4 2 drwxr-xr-x 3 root wheel 36 Dec 7 09:55 ./ 2 drwxr-xr-x 23 root wheel 512 Dec 3 17:04 ../ 2 drwxr-xr-x 2 root wheel0 Dec 7 09:55 dir/ jsli@rpi2:/mnt # ll -ia dir total 0 2 drwxr-xr-x 2 root wheel 0 Dec 7 09:55 ./ 2 drwxr-xr-x 3 root wheel 36 Dec 7 09:55 ../ jsli@rpi2:/mnt # >>> >>> Ouch. >>> >>> Looks like 64-bit atomic on 32-bit arm don't work as advertised. >>> >>> While they should be fixed, I have been meaning to commit the following >>> which will have a side effect of taking care of the bug you ran into: >>> >> >> Mateusz, >> where you see problem with 64-bit atomic on arm? I'm not aware of any >> problem in this area. > > inode allocation for tmpfs (and other places) was recently changed to use > 64-bit atomics (excluding mips and powerpc). So far atomic_fetchadd_64 > failing to bump the number on 32-bit arm (at least for the variant used > by whatever is put on rpi2) looks like a decent explanation. The code > definitely works on amd64. > Fixed in r341679. Thanks for report. ___ 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: rm cannot recursively delete directory on tmpfs on RPi2
On 07.12.2018 10:59, Mateusz Guzik wrote: > On 12/7/18, Michal Meloun wrote: >> >> >> On 07.12.2018 7:25, Mateusz Guzik wrote: >>> On 12/7/18, Jia-Shiun Li wrote: On Fri, Dec 7, 2018 at 12:36 AM Alan Somers wrote: > On Wed, Dec 5, 2018 at 10:18 PM Jia-Shiun Li > wrote: >> >> amd64 and RPi3 do not have this issue. >> >> jsli@rpi2:/home/jsli 13:04 # uname -a >> FreeBSD rpi2 13.0-CURRENT FreeBSD 13.0-CURRENT r341419 GENERIC-NODEBUG > arm >> jsli@rpi2:/home/jsli 13:05 # mount -t tmpfs tmpfs /mnt >> jsli@rpi2:/home/jsli 13:05 # cd /mnt >> jsli@rpi2:/mnt 13:05 # tar xf >> /usr/ports/distfiles/sqlite-autoconf-326.tar.gz >> jsli@rpi2:/mnt 13:05 # rm -rf sqlite-autoconf-326/ >> rm: sqlite-autoconf-326/tea: Operation not permitted >> rm: sqlite-autoconf-326/: Directory not empty >> jsli@rpi2:/mnt 13:05 # >> >> -Jia-Shiun > > Did you check for file flags? Do "ls -lod > sqlite-autoconf-326/tea". > > Unlikely caused by flags I think. jsli@rpi2:/home/jsli # mount -t tmpfs tmpfs /mnt jsli@rpi2:/home/jsli # cd /mnt jsli@rpi2:/mnt # ls -R jsli@rpi2:/mnt # mkdir dir jsli@rpi2:/mnt # ls -R dir/ ls: dir: directory causes a cycle jsli@rpi2:/mnt # looks inode no for directories are wrong jsli@rpi2:/mnt # ll -ia total 4 2 drwxr-xr-x 3 root wheel 36 Dec 7 09:55 ./ 2 drwxr-xr-x 23 root wheel 512 Dec 3 17:04 ../ 2 drwxr-xr-x 2 root wheel0 Dec 7 09:55 dir/ jsli@rpi2:/mnt # ll -ia dir total 0 2 drwxr-xr-x 2 root wheel 0 Dec 7 09:55 ./ 2 drwxr-xr-x 3 root wheel 36 Dec 7 09:55 ../ jsli@rpi2:/mnt # >>> >>> Ouch. >>> >>> Looks like 64-bit atomic on 32-bit arm don't work as advertised. >>> >>> While they should be fixed, I have been meaning to commit the following >>> which will have a side effect of taking care of the bug you ran into: >>> >> >> Mateusz, >> where you see problem with 64-bit atomic on arm? I'm not aware of any >> problem in this area. > > inode allocation for tmpfs (and other places) was recently changed to use > 64-bit atomics (excluding mips and powerpc). So far atomic_fetchadd_64 > failing to bump the number on 32-bit arm (at least for the variant used > by whatever is put on rpi2) looks like a decent explanation. The code > definitely works on amd64. > Ahh, right. atomic_fetchadd_64() is clearly broken. Give me a few minutes for fix and test. -- diff --git a/sys/arm/include/atomic-v6.h b/sys/arm/include/atomic-v6.h index 8f63554c701..40d2b94f4cf 100644 --- a/sys/arm/include/atomic-v6.h +++ b/sys/arm/include/atomic-v6.h @@ -435,7 +435,7 @@ atomic_fetchadd_64(volatile uint64_t *p, uint64_t val) __asm __volatile( "1: \n" - " ldrexd %Q[tmp], %R[tmp], [%[ptr]] \n" + " ldrexd %Q[ret], %R[ret], [%[ptr]] \n" " adds%Q[tmp], %Q[ret], %Q[val] \n" " adc %R[tmp], %R[ret], %R[val] \n" " strexd %[exf], %Q[tmp], %R[tmp], [%[ptr]] \n" ___ 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: rm cannot recursively delete directory on tmpfs on RPi2
On 12/7/18, Michal Meloun wrote: > > > On 07.12.2018 7:25, Mateusz Guzik wrote: >> On 12/7/18, Jia-Shiun Li wrote: >>> On Fri, Dec 7, 2018 at 12:36 AM Alan Somers wrote: >>> On Wed, Dec 5, 2018 at 10:18 PM Jia-Shiun Li wrote: > > amd64 and RPi3 do not have this issue. > > jsli@rpi2:/home/jsli 13:04 # uname -a > FreeBSD rpi2 13.0-CURRENT FreeBSD 13.0-CURRENT r341419 GENERIC-NODEBUG arm > jsli@rpi2:/home/jsli 13:05 # mount -t tmpfs tmpfs /mnt > jsli@rpi2:/home/jsli 13:05 # cd /mnt > jsli@rpi2:/mnt 13:05 # tar xf > /usr/ports/distfiles/sqlite-autoconf-326.tar.gz > jsli@rpi2:/mnt 13:05 # rm -rf sqlite-autoconf-326/ > rm: sqlite-autoconf-326/tea: Operation not permitted > rm: sqlite-autoconf-326/: Directory not empty > jsli@rpi2:/mnt 13:05 # > > -Jia-Shiun Did you check for file flags? Do "ls -lod sqlite-autoconf-326/tea". >>> Unlikely caused by flags I think. >>> >>> jsli@rpi2:/home/jsli # mount -t tmpfs tmpfs /mnt >>> jsli@rpi2:/home/jsli # cd /mnt >>> jsli@rpi2:/mnt # ls -R >>> jsli@rpi2:/mnt # mkdir dir >>> jsli@rpi2:/mnt # ls -R >>> dir/ >>> ls: dir: directory causes a cycle >>> jsli@rpi2:/mnt # >>> >>> >>> looks inode no for directories are wrong >>> >>> jsli@rpi2:/mnt # ll -ia >>> total 4 >>> 2 drwxr-xr-x 3 root wheel 36 Dec 7 09:55 ./ >>> 2 drwxr-xr-x 23 root wheel 512 Dec 3 17:04 ../ >>> 2 drwxr-xr-x 2 root wheel0 Dec 7 09:55 dir/ >>> jsli@rpi2:/mnt # ll -ia dir >>> total 0 >>> 2 drwxr-xr-x 2 root wheel 0 Dec 7 09:55 ./ >>> 2 drwxr-xr-x 3 root wheel 36 Dec 7 09:55 ../ >>> jsli@rpi2:/mnt # >>> >> >> Ouch. >> >> Looks like 64-bit atomic on 32-bit arm don't work as advertised. >> >> While they should be fixed, I have been meaning to commit the following >> which will have a side effect of taking care of the bug you ran into: >> > > Mateusz, > where you see problem with 64-bit atomic on arm? I'm not aware of any > problem in this area. inode allocation for tmpfs (and other places) was recently changed to use 64-bit atomics (excluding mips and powerpc). So far atomic_fetchadd_64 failing to bump the number on 32-bit arm (at least for the variant used by whatever is put on rpi2) looks like a decent explanation. The code definitely works on amd64. -- Mateusz Guzik ___ 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: rm cannot recursively delete directory on tmpfs on RPi2
On 07.12.2018 7:25, Mateusz Guzik wrote: > On 12/7/18, Jia-Shiun Li wrote: >> On Fri, Dec 7, 2018 at 12:36 AM Alan Somers wrote: >> >>> On Wed, Dec 5, 2018 at 10:18 PM Jia-Shiun Li wrote: amd64 and RPi3 do not have this issue. jsli@rpi2:/home/jsli 13:04 # uname -a FreeBSD rpi2 13.0-CURRENT FreeBSD 13.0-CURRENT r341419 GENERIC-NODEBUG >>> arm jsli@rpi2:/home/jsli 13:05 # mount -t tmpfs tmpfs /mnt jsli@rpi2:/home/jsli 13:05 # cd /mnt jsli@rpi2:/mnt 13:05 # tar xf /usr/ports/distfiles/sqlite-autoconf-326.tar.gz jsli@rpi2:/mnt 13:05 # rm -rf sqlite-autoconf-326/ rm: sqlite-autoconf-326/tea: Operation not permitted rm: sqlite-autoconf-326/: Directory not empty jsli@rpi2:/mnt 13:05 # -Jia-Shiun >>> >>> Did you check for file flags? Do "ls -lod sqlite-autoconf-326/tea". >>> >>> >> Unlikely caused by flags I think. >> >> jsli@rpi2:/home/jsli # mount -t tmpfs tmpfs /mnt >> jsli@rpi2:/home/jsli # cd /mnt >> jsli@rpi2:/mnt # ls -R >> jsli@rpi2:/mnt # mkdir dir >> jsli@rpi2:/mnt # ls -R >> dir/ >> ls: dir: directory causes a cycle >> jsli@rpi2:/mnt # >> >> >> looks inode no for directories are wrong >> >> jsli@rpi2:/mnt # ll -ia >> total 4 >> 2 drwxr-xr-x 3 root wheel 36 Dec 7 09:55 ./ >> 2 drwxr-xr-x 23 root wheel 512 Dec 3 17:04 ../ >> 2 drwxr-xr-x 2 root wheel0 Dec 7 09:55 dir/ >> jsli@rpi2:/mnt # ll -ia dir >> total 0 >> 2 drwxr-xr-x 2 root wheel 0 Dec 7 09:55 ./ >> 2 drwxr-xr-x 3 root wheel 36 Dec 7 09:55 ../ >> jsli@rpi2:/mnt # >> > > Ouch. > > Looks like 64-bit atomic on 32-bit arm don't work as advertised. > > While they should be fixed, I have been meaning to commit the following > which will have a side effect of taking care of the bug you ran into: > Mateusz, where you see problem with 64-bit atomic on arm? I'm not aware of any problem in this area. ___ 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"
