Re: Waiting for bufdaemon
Alexander Leidinger Alexander at leidinger.net wrote on Sat Mar 6 10:47:29 UTC 2021 : > Quoting Konstantin Belousov (from Fri, 5 Mar > 2021 22:43:58 +0200): > . . . > > For you, a simple but manual workaround, setting the timecounter to > > ACPI (?) or might be HPET, with a loader tunable, should do it. > > > Do you propose this to him as a test if this solves the issue with the > intend to change the code to use a more suitable TC if VirtualBox is > detected? Turns out to not matter: Yasuhiro reported that all the kern.timecounter.choice alternatives [ACPI-fast(900) i8254(0) TSC-low(-100) dummy(-100)] failed to make a usable environment. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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: geli broken in 13.0-BETA4 and later on armv8
On 2021-Mar-06 10:39:02 -0800, Oleksandr Tymoshenko wrote: >Peter Jeremy via freebsd-current (freebsd-current@freebsd.org) wrote: >> [Adding arm@ and making it clearer that this is armv8-only] >> >> On 2021-Mar-06 20:26:19 +1100, Peter Jeremy >> wrote: >> >On 2021-Mar-06 19:18:37 +1100, Peter Jeremy via freebsd-stable >> > wrote: >> >>Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4 >> >>(releng/13.0-n244592-e32bc253629), geli (at least on my RockPro64 - >> >>RK3399, arm64) has changed so that a geli-encrypted partition (using >> >>AES-XTS 128) that was readable on 13.0-ALPHA2 becomes garbage on >> >>13.0-BETA4. >> > >> >I've confirmed that the problem is f76393a6305b - reverting that >> >commit fixes the problem in releng/13.0. >> > >> >I've further verified that the bug is still present in main (14.x) >> >at 028616d0dd69. > >Could you test this patch and let me know if it fixes the issue? > >https://people.freebsd.org/~gonzo/patches/armv8crypto-xts-fix.diff Yes, it does. Thank you very much. --- Peter Jeremy signature.asc Description: PGP signature
Re: FreeBSD 13-RC1 PVSCSI install error with VMware
On 06/03/2021 14:38, Fabien via freebsd-current wrote: > Hello, > > A quick feedback related to VMware install of FreeBSD 13-RC1 with PVSCSI > drive. > At the end of the install it fails with the following error: > https://e.pcloud.link/publink/show?code=XZBzIkZS2Sx31RK3k0L91Hz4I8p70F82iHV > > Is it planned to be fixed before release ? Please see if this helps: https://lists.freebsd.org/pipermail/freebsd-current/2020-December/077859.html Note that you don't have to recompile, kern.maxphys in loader.conf or at the loader prompt should work as well. But it would be ideal to fix the issue in the driver. -- Andriy Gapon ___ 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: FreeBSD 13-RC1 PVSCSI install error with VMware
On 3/6/21 12:38 PM, Fabien via freebsd-current wrote: > Hello, > > A quick feedback related to VMware install of FreeBSD 13-RC1 with PVSCSI > drive. > At the end of the install it fails with the following error: > https://e.pcloud.link/publink/show?code=XZBzIkZS2Sx31RK3k0L91Hz4I8p70F82iHV > > Is it planned to be fixed before release ? Sorry but it all works great here : sedna_esxi# cat /vmfs/volumes/5b6fad86-242d5412-299e-00144f811e40/deathstar/deathstar.vmx .encoding = "UTF-8" config.version = "8" virtualHW.version = "10" nvram = "deathstar.nvram" pciBridge0.present = "TRUE" svga.present = "TRUE" pciBridge4.present = "TRUE" pciBridge4.virtualDev = "pcieRootPort" pciBridge4.functions = "8" pciBridge5.present = "TRUE" pciBridge5.virtualDev = "pcieRootPort" pciBridge5.functions = "8" pciBridge6.present = "TRUE" pciBridge6.virtualDev = "pcieRootPort" pciBridge6.functions = "8" pciBridge7.present = "TRUE" pciBridge7.virtualDev = "pcieRootPort" pciBridge7.functions = "8" vmci0.present = "TRUE" hpet0.present = "TRUE" displayName = "deathstar" extendedConfigFile = "deathstar.vmxf" virtualHW.productCompatibility = "hosted" floppy0.present = "FALSE" numvcpus = "2" memSize = "8192" powerType.powerOff = "hard" powerType.reset = "hard" tools.upgrade.policy = "manual" scsi0.virtualDev = "pvscsi" scsi0.present = "TRUE" scsi0:0.deviceType = "scsi-hardDisk" scsi0:0.fileName = "d_0.vmdk" scsi0:0.present = "TRUE" ide1:0.deviceType = "cdrom-image" ide1:0.fileName = "/vmfs/volumes/5b6fad86-242d5412-299e-00144f811e40/iso_images/FreeBSD-13.0-RC1-amd64-disc1.iso" ide1:0.present = "TRUE" ethernet0.virtualDev = "e1000" ethernet0.networkName = "vm_net_01" ethernet0.addressType = "generated" ethernet0.present = "TRUE" svga.autodetect = "TRUE" guestOS = "other-64" vcpu.hotadd = "TRUE" mem.hotadd = "TRUE" tools.syncTime = "FALSE" uuid.bios = "56 4d d6 67 c5 ca b8 fb-79 d3 d1 8b bc 26 1b ea" vc.uuid = "52 c3 0a e2 b1 48 4f 38-8f 18 69 01 ec 77 bf 07" scsi0:1.deviceType = "scsi-hardDisk" scsi0:1.fileName = "d_1.vmdk" scsi0:1.present = "TRUE" bios.forceSetupOnce = "FALSE" sched.swap.derivedName = "/vmfs/volumes/5b6fad86-242d5412-299e-00144f811e40/deathstar/deathstar-f1184228.vswp" uuid.location = "56 4d d6 67 c5 ca b8 fb-79 d3 d1 8b bc 26 1b ea" replay.supported = "FALSE" replay.filename = "" scsi0:0.redo = "" scsi0:1.redo = "" pciBridge0.pciSlotNumber = "17" pciBridge4.pciSlotNumber = "21" pciBridge5.pciSlotNumber = "22" pciBridge6.pciSlotNumber = "23" pciBridge7.pciSlotNumber = "24" scsi0.pciSlotNumber = "160" ethernet0.pciSlotNumber = "32" vmci0.pciSlotNumber = "33" scsi0.sasWWID = "50 05 05 67 c5 ca b8 f0" ethernet0.generatedAddress = "00:0c:29:26:1b:ea" ethernet0.generatedAddressOffset = "0" vmci0.id = "-1138353174" monitor.phys_bits_used = "40" vmotion.checkpointFBSize = "16777216" cleanShutdown = "FALSE" softPowerOff = "FALSE" sedna_esxi# I hate being that guy that says "works for me"(tm) however ... it does. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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"
FreeBSD 13.0-RC1 Now Available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 The first RC build of the 13.0-RELEASE release cycle is now available. Installation images are available for: o 13.0-RC1 amd64 GENERIC o 13.0-RC1 i386 GENERIC o 13.0-RC1 powerpc GENERIC o 13.0-RC1 powerpc64 GENERIC64 o 13.0-RC1 powerpc64le GENERIC64LE o 13.0-RC1 powerpcspe MPC85XXSPE o 13.0-RC1 armv6 RPI-B o 13.0-RC1 armv7 GENERICSD o 13.0-RC1 aarch64 GENERIC o 13.0-RC1 aarch64 RPI o 13.0-RC1 aarch64 PINE64 o 13.0-RC1 aarch64 PINE64-LTS o 13.0-RC1 aarch64 PINEBOOK o 13.0-RC1 aarch64 ROCK64 o 13.0-RC1 aarch64 ROCKPRO64 o 13.0-RC1 riscv64 GENERIC o 13.0-RC1 riscv64 GENERICSD Note regarding arm SD card images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root. It is strongly recommended to change the password for both users after gaining access to the system. Installer images and memory stick images are available here: https://download.freebsd.org/ftp/releases/ISO-IMAGES/13.0/ The image checksums follow at the end of this e-mail. If you notice problems you can report them through the Bugzilla PR system or on the -stable mailing list. If you would like to use SVN to do a source based update of an existing system, use the "releng/13.0" branch. A summary of changes since 13.0-BETA4 includes: o An update to handle partial data resending on ktls/sendfile has been added. o A bug fix in iflib. o A fix to pf(4) for incorrect fragment handling. o A TCP performance improvement when using TCP_NOOPT has been added. o Several SCTP fixes and improvements. o Several other miscellaneous fixes and improvements. A list of changes since 12.2-RELEASE is available in the releng/13.0 release notes: https://www.freebsd.org/releases/13.0R/relnotes.html Please note, the release notes page is not yet complete, and will be updated on an ongoing basis as the 13.0-RELEASE cycle progresses. === Virtual Machine Disk Images === VM disk images are available for the amd64, i386, and aarch64 architectures. Disk images may be downloaded from the following URL (or any of the FreeBSD download mirrors): https://download.freebsd.org/ftp/releases/VM-IMAGES/13.0-RC1/ The partition layout is: ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label) ~ 1 GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label) The disk images are available in QCOW2, VHD, VMDK, and raw disk image formats. The image download size is approximately 135 MB and 165 MB respectively (amd64/i386), decompressing to a 21 GB sparse image. Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI loader file is needed for qemu-system-aarch64 to be able to boot the virtual machine images. See this page for more information: https://wiki.freebsd.org/arm64/QEMU To boot the VM image, run: % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ -bios QEMU_EFI.fd -serial telnet::,server -nographic \ -drive if=none,file=VMDISK,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -device virtio-net-device,netdev=net0 \ -netdev user,id=net0 Be sure to replace "VMDISK" with the path to the virtual machine image. BASIC-CI images can be found at: https://download.freebsd.org/ftp/releases/CI-IMAGES/13.0-RC1/ === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: af-south-1 region: ami-024a37d8ee55504a9 eu-north-1 region: ami-0f7e6ef964131a5c5 ap-south-1 region: ami-0da383cf93cddac9d eu-west-3 region: ami-0c2e5eecf725c8480 eu-west-2 region: ami-07e739abd39787f83 eu-south-1 region: ami-042c036041ab5c683 eu-west-1 region: ami-02b72374c39f164f4 ap-northeast-3 region: ami-06b158bab2dc009b8 ap-northeast-2 region: ami-0fbcb7db014004a7f me-south-1 region: ami-0a5040da848631036 ap-northeast-1 region: ami-0ea2e5573427aa49c sa-east-1 region: ami-0e8ca0e56ecd00395 ca-central-1 region: ami-08503cd732e74743f ap-east-1 region: ami-0fa7c7d12cd5c992f ap-southeast-1 region: ami-0adc820ff9c36b582 ap-southeast-2 region: ami-0f031e3027fe5ed45 eu-central-1 region: ami-0685d9bbc37652517 us-east-1 region: ami-0dc102bfa2a63a6c0 us-east-2 region: ami-0d65407784cf103ac us-west-1 region: ami-0d676e4b02aeac56e us-west-2 region: ami-0f2f2e90ae8956750 FreeBSD/aarch64 EC2 AMIs are available in the following regions: af-south-1 region: ami-00bc7809c32164ef7 eu-north-1 region: ami-079c3b3939e1422f5 ap-south-1 region: ami-09f83dd115907186c eu-west-3 region: ami-0b466ac2ccb1d9a17 eu-west-2 region: ami-03127626a3b795617 eu-south-1 region: ami-04b543c7eca712cb2 eu-west-1 region: ami-04bec8381d23b2d33 ap-northeast-3 region: ami-08ec822521c26b950 ap-northeast-2 region: ami-08b8dd381dcc36d65 me-south-1 region: ami-07253323150004fb7
Re: geli broken in 13.0-BETA4 and later on armv8
Peter Jeremy via freebsd-current (freebsd-current@freebsd.org) wrote: > [Adding arm@ and making it clearer that this is armv8-only] > > On 2021-Mar-06 20:26:19 +1100, Peter Jeremy wrote: > >On 2021-Mar-06 19:18:37 +1100, Peter Jeremy via freebsd-stable > > wrote: > >>Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4 > >>(releng/13.0-n244592-e32bc253629), geli (at least on my RockPro64 - > >>RK3399, arm64) has changed so that a geli-encrypted partition (using > >>AES-XTS 128) that was readable on 13.0-ALPHA2 becomes garbage on > >>13.0-BETA4. > > > >I've confirmed that the problem is f76393a6305b - reverting that > >commit fixes the problem in releng/13.0. > > > >I've further verified that the bug is still present in main (14.x) > >at 028616d0dd69. Could you test this patch and let me know if it fixes the issue? https://people.freebsd.org/~gonzo/patches/armv8crypto-xts-fix.diff Thanks -- gonzo ___ 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: FreeBSD 13-RC1 PVSCSI install error with VMware
On 3/6/21 12:38 PM, Fabien via freebsd-current wrote: > Hello, > > A quick feedback related to VMware install of FreeBSD 13-RC1 with PVSCSI > drive. > At the end of the install it fails with the following error: > https://e.pcloud.link/publink/show?code=XZBzIkZS2Sx31RK3k0L91Hz4I8p70F82iHV > > Is it planned to be fixed before release ? I just took a look at : Configuring disks to use VMware Paravirtual SCSI (PVSCSI) controllers (1010398) https://kb.vmware.com/s/article/1010398 Where it seems you are definately using ESXi and I also have ESXi here to test with. However it is unclear how you configured your disk(s) and controllers. Can you provide some details on the config and how you arrived at this bug? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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: FreeBSD 13-RC1 PVSCSI install error with VMware
On 3/6/21 12:38 PM, Fabien via freebsd-current wrote: > Hello, > > A quick feedback related to VMware install of FreeBSD 13-RC1 with PVSCSI > drive. > At the end of the install it fails with the following error: > https://e.pcloud.link/publink/show?code=XZBzIkZS2Sx31RK3k0L91Hz4I8p70F82iHV > > Is it planned to be fixed before release ? Interesting error. Was this : 1) VMware Workstation of some flavour ? 2) ESXi or VMware vSphere server based ? What are the specs of the virtual machine ? Just some basics here. A little data please. In the meanwhile I will fire up RC1 on both Xeon based hardware and on VMware vSphere and VMware workstation just to see what happens. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ 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"
FreeBSD 13-RC1 PVSCSI install error with VMware
Hello, A quick feedback related to VMware install of FreeBSD 13-RC1 with PVSCSI drive. At the end of the install it fails with the following error: https://e.pcloud.link/publink/show?code=XZBzIkZS2Sx31RK3k0L91Hz4I8p70F82iHV Is it planned to be fixed before release ? Regards, Fabien ___ 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: geli broken in 13.0-BETA4 and later on armv8
[Adding arm@ and making it clearer that this is armv8-only] On 2021-Mar-06 20:26:19 +1100, Peter Jeremy wrote: >On 2021-Mar-06 19:18:37 +1100, Peter Jeremy via freebsd-stable > wrote: >>Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4 >>(releng/13.0-n244592-e32bc253629), geli (at least on my RockPro64 - >>RK3399, arm64) has changed so that a geli-encrypted partition (using >>AES-XTS 128) that was readable on 13.0-ALPHA2 becomes garbage on >>13.0-BETA4. > >I've confirmed that the problem is f76393a6305b - reverting that >commit fixes the problem in releng/13.0. > >I've further verified that the bug is still present in main (14.x) >at 028616d0dd69. -- Peter Jeremy signature.asc Description: PGP signature
Re: Problem compiling gcc10
On 6 Mar 2021, at 11:19, Filippo Moretti wrote:
>
> This is the output from MAKE_JOBS_UNSAFE=yes
>
> checking whether the C compiler works... yes
> checking for C compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... configure: error: in
> `/usr/ports/lang/gcc10/work/.build/x86_64-portbld-freebsd14.0/32/libgcc':
> configure: error: cannot run C compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details
> gmake[4]: *** [Makefile:17191: configure-stage1-target-libgcc] Error 1
> gmake[4]: Leaving directory '/usr/ports/lang/gcc10/work/.build'
Ok, for some reason it fails to run its autoconf test case. Since it
specifically dies on x86_64-portbld-freebsd14.0/32/libgcc, I would guess
that you haven't got any 32 bit compat libraries installed?
But if you want to know for sure, find the config.log file which
contains the details. It should be in
$workdir/.build/x86_64-portbld-freebsd14.0/32/libgcc. This should show
exactly which commands it ran, and what error it got.
Btw, if you attempt to compile and run a small 32 bit executable, like
this:
echo "int main(void) { return 0; }" > minimal.c && cc -m32 minimal.c -o minimal
&& ./minimal
does it work?
-Dimitry
signature.asc
Description: Message signed with OpenPGP
Re: Waiting for bufdaemon
Quoting Konstantin Belousov (from Fri, 5 Mar 2021 22:43:58 +0200): On Fri, Mar 05, 2021 at 04:03:11PM +0900, Yasuhiro Kimura wrote: Dear src committers, From: Yasuhiro Kimura Subject: Re: Waiting for bufdaemon Date: Thu, 28 Jan 2021 05:02:42 +0900 (JST) >>> I have been experiencing same problem with my 13-CURRENT amd64 >>> VirtualBox VM for about a month. The conditions that the problem >>> happens are unclear and all what I can say is >>> >>> * It happens only after I login in the VM and do something for a >>> while. If I boot the VM and shut it down immediately, it never >>> happens. >>> * When the problem happens, one or more unkillable processes seem to >>> be left. >> >> CPU of my host is not AMD but Intel. According to the >> /var/run/dmesg.boot of VM, information of CPU is as following. >> >> CPU: Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz (3000.09-MHz K8-class CPU) >> Origin="GenuineIntel" Id=0x906ed Family=0x6 Model=0x9e Stepping=13 >> Features=0x1783fbff >> Features2=0x5eda2203 >> AMD Features=0x28100800 >> AMD Features2=0x121 >> Structured Extended Features=0x842421 >> Structured Extended Features3=0x3400 >> IA32_ARCH_CAPS=0x29 >> TSC: P-state invariant >> >> Just FYI. > > It took for a while to investigate, but according to the result of > bisect following commit is the source of problem in my case. > > -- > commit 84eaf2ccc6a > Author: Konstantin Belousov > Date: Mon Dec 21 19:02:31 2020 +0200 > > x86: stop punishing VMs with low priority for TSC timecounter > > I suspect that virtualization techniques improved from the time when we > have to effectively disable TSC use in VM. For instance, it was reported > (complained) in https://github.com/JuliaLang/julia/issues/38877 that > FreeBSD is groundlessly slow on AWS with some loads. > > Remove the check and start watching for complaints. > > Reviewed by:emaste, grehan > Discussed with: cperciva > Sponsored by: The FreeBSD Foundation > Differential Revision: https://reviews.freebsd.org/D27629 > -- > > I confirmed the problem still happens with 5c325977b11 but reverting > above commit fixes it. Would someone please revert above commit from main, stable/13 and releng/13.0? As I wrote previous mail I submitted this problem to Bugzilla as bug 253087 and added the committer to Cc. But there is no response for 34 days. I confirmed the problem still happens with 37cd6c20dbc of main and 13.0-RC1. My belief is that this commit helps more users than it hurts. Namely, the VMWare and KVM users, which are majority, use fast timecounter, comparing to the more niche hypervisors like VirtualBox. For you, a simple but manual workaround, setting the timecounter to ACPI (?) or might be HPET, with a loader tunable, should do it. Do you propose this to him as a test if this solves the issue with the intend to change the code to use a more suitable TC if VirtualBox is detected? Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF pgpZtn2nb4T4U.pgp Description: Digitale PGP-Signatur
Re: Problem compiling gcc10
This is the output from MAKE_JOBS_UNSAFE=yes checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... configure: error: in `/usr/ports/lang/gcc10/work/.build/x86_64-portbld-freebsd14.0/32/libgcc': configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. See `config.log' for more details gmake[4]: *** [Makefile:17191: configure-stage1-target-libgcc] Error 1 gmake[4]: Leaving directory '/usr/ports/lang/gcc10/work/.build' gmake[3]: *** [Makefile:22903: stage1-bubble] Error 2 gmake[3]: Leaving directory '/usr/ports/lang/gcc10/work/.build' gmake[2]: *** [Makefile:23235: bootstrap-lean] Error 2 gmake[2]: Leaving directory '/usr/ports/lang/gcc10/work/.build' *** Error code 1 Stop. On Friday, March 5, 2021, 9:28:52 PM GMT+1, Dimitry Andric wrote: On 5 Mar 2021, at 18:19, Filippo Moretti via freebsd-current wrote: > > The following is the error while compiling on: > [root@sting /usr/ports]# uname -aFreeBSD sting 14.0-CURRENT FreeBSD > 14.0-CURRENT #32 main-n245104-dfff1de729b: Fri Feb 26 12:08:40 CET 2021 > root@sting:/usr/obj/usr/src/amd64.amd64/sys/STING amd64 > > gmake[6]: *** [Makefile:1212: multi-do] Error 1gmake[6]: Leaving directory > '/usr/ports/lang/gcc10/work/.build/x86_64-portbld-fr > eebsd14.0/libgcc'gmake[5]: *** [Makefile:127: all-multi] Error 2gmake[5]: *** > Waiting for unfinished jobsgmake[5]: Leaving directory > '/usr/ports/lang/gcc10/work/.build/x86_64-portbld-fr > eebsd14.0/libgcc'gmake[4]: *** [Makefile:17599: all-stage1-target-libgcc] > Error 2gmake[4]: Leaving directory > '/usr/ports/lang/gcc10/work/.build'gmake[3]: *** [Makefile:22903: > stage1-bubble] Error 2gmake[3]: Leaving directory > '/usr/ports/lang/gcc10/work/.build'gmake[2]: *** [Makefile:23235: > bootstrap-lean] Error 2gmake[2]: Leaving directory > '/usr/ports/lang/gcc10/work/.build'===> Compilation failed unexpectedly.Try > to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure tothe > maintainer.*** Error code 1Stop.make[1]: stopped in /usr/ports/lang/gcc10*** > Error code 1 Hi Filippo, Unfortunately the actual error is earlier in the build, so it is not shown, and your log is wrapped very strangely. Can you run the build under script(1) and upload a full build log somewhere? Alternatively, you can set MAKE_JOBS_UNSAFE=yes so it would use a single job make, and it should then show the error more clearly at the end. But this is likely to take a bit longer to build. -Dimitry signature.asc Description: PGP signature ___ 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: Waiting for bufdaemon
From: Yasuhiro Kimura Subject: Re: Waiting for bufdaemon Date: Sat, 06 Mar 2021 08:33:23 +0900 (JST) >> My belief is that this commit helps more users than it hurts. Namely, >> the VMWare and KVM users, which are majority, use fast timecounter, >> comparing to the more niche hypervisors like VirtualBox. >> >> For you, a simple but manual workaround, setting the timecounter to >> ACPI (?) or might be HPET, with a loader tunable, should do it. > > Then please let me know the name of it. From: Michael Gmelin Subject: Re: Waiting for bufdaemon Date: Sat, 6 Mar 2021 00:56:43 +0100 > see `man 4 timecounters': > > https://www.freebsd.org/cgi/man.cgi?query=timecounters From: Mark Millard via freebsd-current Subject: Re: Waiting for bufdaemon Date: Fri, 5 Mar 2021 17:35:14 -0800 > Its somewhat messy but there is a technique of using > the "timecounter" in kib's wording to explore: ... From: Chris Subject: Re: Waiting for bufdaemon Date: Fri, 05 Mar 2021 18:54:05 -0800 > Not exactly what you're asking for. But sysctl sysctl(3) and loader(8) > will provide some good clues. Thank you for reply. On the system in question 'kern.timecounter.choice' and 'kern.timecounter.hardware' tunables have following values. -- yasu@rolling-vm-freebsd1[1002]% sysctl kern.timecounter.choice kern.timecounter.choice: ACPI-fast(900) i8254(0) TSC-low(-100) dummy(-100) yasu@rolling-vm-freebsd1[1003]% sysctl kern.timecounter.hardware kern.timecounter.hardware: ACPI-fast yasu@rolling-vm-freebsd1[1004]% -- So I tried setting the latter to 'i8254', 'TSC-low' and 'dummy', and checked if the problem disappear. But unfortunately it still happened. On the contrary changing the value from default made thing worse. If it is set to either 'i8254' or 'TSC-low', timeout of bufdaemon also happens when I shutdown the system just after bootstrap is completed. And if it is set to 'dummy', the sytem hung up in the middle of bootstrap. So setting 'kern.timecounter.hardware' tunable doesn't work in my case. Then is there any way to try? --- Yasuhiro Kimura ___ 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: geli broken in 13.0-BETA4 and later
On 2021-Mar-06 19:18:37 +1100, Peter Jeremy via freebsd-stable wrote: >Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4 >(releng/13.0-n244592-e32bc253629), geli (at least on my RockPro64 - >RK3399, arm64) has changed so that a geli-encrypted partition (using >AES-XTS 128) that was readable on 13.0-ALPHA2 becomes garbage on >13.0-BETA4. I've confirmed that the problem is f76393a6305b - reverting that commit fixes the problem in releng/13.0. I've further verified that the bug is still present in main (14.x) at 028616d0dd69. -- Peter Jeremy signature.asc Description: PGP signature
Re: ifa leak on VNET teardown
On 13 Feb 2021, at 21:58, Alexander V. Chernikov wrote: It turns out we're leaking some ifas for loopback interfaces on VNET teardown: There’s a recent bug about this as well: 253998. The problem’s been around for a long time though. The pf tests trigger it from time to time, although it doesn’t appear to be 100% consistent, so my current feeling is that it may be racy. I see ‘in6_purgeaddr: err=65, destination address delete failed’ when we do leak, and I’ve also been able to confirm this is about the ::1 IPv6 loopback address. Best regards, Kristof ___ 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"
