Re: Fall back to fast_float when C++ stdlib doesn't provide from_chars for floats
On 8 Aug 2024, at 19:56, Daniel Tameling wrote: > > On Tue, Aug 06, 2024 at 11:26:26AM +0100, Nuno Teixeira wrote: >> >> As I don't have skills to understand why this fix works, I'd like to have >> some expert opinion on this fix since I don't know if this will be >> supported in the future. > > Not an expert, but here is my opinion: the workaround uses the strtod > function instead of the from_chars function. The latter got added in > c++17 and the former is still in the latest standard, and I don't > think it will be removed any time soon. So as long as it is supported > by upstream, it should be save to use the workaround. > > You might want to raise the issue with toolch...@freebsd.org to get a > reaction from the real experts. Maybe there is a better solution to > your problem. At the moment, from_chars is only implemented for integers, in libc++. I'm unsure what the reason is for not implementing it for floating point types. So for now, just use strtod() or the equivalent. -Dimitry
Re: Fall back to fast_float when C++ stdlib doesn't provide from_chars for floats
On Tue, Aug 06, 2024 at 11:26:26AM +0100, Nuno Teixeira wrote: > > As I don't have skills to understand why this fix works, I'd like to have > some expert opinion on this fix since I don't know if this will be > supported in the future. Not an expert, but here is my opinion: the workaround uses the strtod function instead of the from_chars function. The latter got added in c++17 and the former is still in the latest standard, and I don't think it will be removed any time soon. So as long as it is supported by upstream, it should be save to use the workaround. You might want to raise the issue with toolch...@freebsd.org to get a reaction from the real experts. Maybe there is a better solution to your problem. -- Best regards, Daniel
Fall back to fast_float when C++ stdlib doesn't provide from_chars for floats
Hello all,
On deskutils/treesheets port, upstream did some updated that broke build.
After investigating it upstream says we are building with an outdated C++
standard lib.
To fix it, I'm using a fall back to fast_float as we see in main PR:
https://github.com/aardappel/treesheets/issues/686
As I don't have skills to understand why this fix works, I'd like to have
some expert opinion on this fix since I don't know if this will be
supported in the furure.
Resuming we added __FreeBSD__ to fall back in code already present:
template T parse_float(string_view sv, const char **end =
nullptr) {
// FIXME: Upgrade compilers for these platforms on CI.
-#if defined(__APPLE__) || defined(__ANDROID__) ||
defined(__EMSCRIPTEN__)
+#if defined(__APPLE__) || defined(__ANDROID__) ||
defined(__EMSCRIPTEN__) || defined(__FreeBSD__)
auto = *(char *)(sv.data() + sv.size());
auto orig = term;
term = 0;
auto v = (T)strtod(sv.data(), (char **)end);
term = orig;
return v;
#else
T val = 0;
auto res = from_chars(sv.data(), sv.data() + sv.size(), val);
if (end) *end = res.ptr;
return val;
#endif
}
Commit is
https://cgit.freebsd.org/ports/commit/?id=4ffd449f0cfdbef7d1c78442ad3ea0be9ab12ea3
Thanks,
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
Re: RFC: rc(8) script for bhyve(8) on FreeBSD
I don't want a GUI for bhyve. I want to manage everything by creating a script in bash. On Mon, Aug 5, 2024 at 8:52 PM Dennis Clarke wrote: > On 8/5/24 14:22, Miroslav Lachman wrote: > > On 05/08/2024 18:50, Dennis Clarke wrote: > >> On 8/5/24 12:12, Harry Schmalzbauer wrote: > >>> Hello, > >>> > >>> two years elapsed since I last deployed a FreeBSD machine that > >>> utilizd bhyve(8), which already had bhyve_config(5) support back then. > >>> > >> > >> This may feel slightly off topic but I assure you that it is of great > >> benefit. Have a look at the brilliant creation of Steve Wills that I > >> know and love as "cirrina" : > >> > >> https://gitlab.com/swills/cirrina/-/releases > >> > >> It is very much in active development and does a neat job of handling a > >> pile of stuff related to bhyve. Not the least of which is the creation > >> and configuration and management of a whole slew of VMs. It is actively > >> being tested and developed and I have been using it while testing PCI > >> device passthru of NVidia Quadro GPUs for the purpose of CUDA dev work. > >> > >> I also am motivated to write up a pile of documentation related to > >> cirrina given that it really does feel like a Swiss Army Knife which > >> can do damn near everything I ever wanted with bhyve. > > > > I have seen cirrina some time ago. I was interested in GUI. > A GUI with bells and whistles like VMware Workstation is a long way off. > Feel free to drop a few million US dollars and I am sure a prototype > would be available in six months. It may even work. > > Sorry but cirrina(d) is just great from the command line for now. > > -- > Dennis Clarke > RISC-V/SPARC/PPC/ARM/CISC > UNIX and Linux spoken > > > -- Mario.
Re: RFC: rc(8) script for bhyve(8) on FreeBSD
On 8/5/24 14:22, Miroslav Lachman wrote: On 05/08/2024 18:50, Dennis Clarke wrote: On 8/5/24 12:12, Harry Schmalzbauer wrote: Hello, two years elapsed since I last deployed a FreeBSD machine that utilizd bhyve(8), which already had bhyve_config(5) support back then. This may feel slightly off topic but I assure you that it is of great benefit. Have a look at the brilliant creation of Steve Wills that I know and love as "cirrina" : https://gitlab.com/swills/cirrina/-/releases It is very much in active development and does a neat job of handling a pile of stuff related to bhyve. Not the least of which is the creation and configuration and management of a whole slew of VMs. It is actively being tested and developed and I have been using it while testing PCI device passthru of NVidia Quadro GPUs for the purpose of CUDA dev work. I also am motivated to write up a pile of documentation related to cirrina given that it really does feel like a Swiss Army Knife which can do damn near everything I ever wanted with bhyve. I have seen cirrina some time ago. I was interested in GUI. A GUI with bells and whistles like VMware Workstation is a long way off. Feel free to drop a few million US dollars and I am sure a prototype would be available in six months. It may even work. Sorry but cirrina(d) is just great from the command line for now. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
Re: RFC: rc(8) script for bhyve(8) on FreeBSD
On 05/08/2024 18:50, Dennis Clarke wrote: On 8/5/24 12:12, Harry Schmalzbauer wrote: Hello, two years elapsed since I last deployed a FreeBSD machine that utilizd bhyve(8), which already had bhyve_config(5) support back then. This may feel slightly off topic but I assure you that it is of great benefit. Have a look at the brilliant creation of Steve Wills that I know and love as "cirrina" : https://gitlab.com/swills/cirrina/-/releases It is very much in active development and does a neat job of handling a pile of stuff related to bhyve. Not the least of which is the creation and configuration and management of a whole slew of VMs. It is actively being tested and developed and I have been using it while testing PCI device passthru of NVidia Quadro GPUs for the purpose of CUDA dev work. I also am motivated to write up a pile of documentation related to cirrina given that it really does feel like a Swiss Army Knife which can do damn near everything I ever wanted with bhyve. I have seen cirrina some time ago. I was interested in GUI. Main page shows: Run Clients GUI Start weasel Create switch Create VM Add Disk Add NIC Upload ISO Select VM, click edit, add disk, iso and nic to VM Start VM But what is weasel / how can I start it? I see only cirrinad and cirrinactl. Kind regards Miroslav Lachman
Re: RFC: rc(8) script for bhyve(8) on FreeBSD
On 2024-08-05 19:04, Mario Marietto wrote: Hello. I'm also interested in writing a script to manage the bhyve vms. Even if I suspect that my approach will be different. My idea is to ask the user what he wants to do and then the script will configure the vm getting the information provided by the user. I will give a look at /etc/rc.d/bhyve,but I don't think I will study cirrina,it seems very complicated. To avoid misunderstandings: /etc/rc.d/bhyve is not meant to 'manage' bhyve(8) VMs in the sense of configuring bhyve(8) or the host which runs the guest operating system. It's just to start/stop already defined VMs at boot time. Managing VM's means utlizing $EDITOR /etc/bhyve.d/yourvm.cfg to me. bhyve_config(5) is what /etc/rc.d/bhyve relies on and where the VM config happens. cirrina seems to be a completely different tool. From the page: »Only UEFI boot is supported, no bhyveload.« Another showstopper for me: »./cirrinactl switch set-uplink -n bridge0 -u em0« (I never use if_bridge(4) for HyperVisor networking) All you can do with /etc/rc.d/bhyve is service bhyve start [vmname] [...] service bhyve stop [vmname] [...] and expect to have all VMs running after rebooting, which you wrote a config file for and placed it into /etc/bhyve.d/ Best, -harry
Re: RFC: rc(8) script for bhyve(8) on FreeBSD
Hello. I'm also interested in writing a script to manage the bhyve vms. Even if I suspect that my approach will be different. My idea is to ask the user what he wants to do and then the script will configure the vm getting the information provided by the user. I will give a look at /etc/rc.d/bhyve,but I don't think I will study cirrina,it seems very complicated. On Mon, Aug 5, 2024 at 6:13 PM Harry Schmalzbauer wrote: > Hello, > > two years elapsed since I last deployed a FreeBSD machine that utilizd > bhyve(8), which already had bhyve_config(5) support back then. > > I was astonished that I still couldn't find bhyve in /etc/rc.d in > 14.1-stable as of last week. > Since I utilize ng_bridge(8) and do some more things differently than > vm-bhyve / iocage and the like, I wanted to have something straight > forward, capable of making use of the wonderful bhyve_config(5) feature, > for use cases where /usr/share/examples/bhyve/vmrun.sh isn't suitable. > > Please find attached my first approch, which currently covers the > following features: > > - auto-preload FreeBSD guest using bhyveload(8) in case config file > doesn't define lpc.bootrom > - Allows referencing %(youname_somevar) in config file if defined as > bhyve_youname_somevar in rc.conf(5). >(For example: > bhyve_vmdisk_default_pool="myppol2" > bhyve_vmdisk_default_dataset="bhyveVOL/sys" > and > pci.0.3.0.path=/dev/zvol/%(vmdisk_default_pool)/%(vmdisk_default_dataset)/%(name) > > in bhyve_config(5) file >) > - Adaptive handling of start/stop requests depending on 'AUTO' 'ALL' or > specific list of VM names, depending on the non-bhyve_cfg(5) 'autostart' > option. > - Hopefully balanced amount of messages about what's going on, to be > user friendly but not spamming. > > There's a lot of room for improvements (selectable pre-jail/post-jail > order, bootdisk detection, priority handling, a useful 'status' > implementation, style) and for sure some bugs, but this version works > well for my current setup. > Happy to contribute if useful for others, feedback welcome. > > -harry > > > -- Mario.
Re: RFC: rc(8) script for bhyve(8) on FreeBSD
On 8/5/24 12:12, Harry Schmalzbauer wrote: Hello, two years elapsed since I last deployed a FreeBSD machine that utilizd bhyve(8), which already had bhyve_config(5) support back then. This may feel slightly off topic but I assure you that it is of great benefit. Have a look at the brilliant creation of Steve Wills that I know and love as "cirrina" : https://gitlab.com/swills/cirrina/-/releases It is very much in active development and does a neat job of handling a pile of stuff related to bhyve. Not the least of which is the creation and configuration and management of a whole slew of VMs. It is actively being tested and developed and I have been using it while testing PCI device passthru of NVidia Quadro GPUs for the purpose of CUDA dev work. I also am motivated to write up a pile of documentation related to cirrina given that it really does feel like a Swiss Army Knife which can do damn near everything I ever wanted with bhyve. Have a long hard stare at it. -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken
RFC: rc(8) script for bhyve(8) on FreeBSD
Hello, two years elapsed since I last deployed a FreeBSD machine that utilizd bhyve(8), which already had bhyve_config(5) support back then. I was astonished that I still couldn't find bhyve in /etc/rc.d in 14.1-stable as of last week. Since I utilize ng_bridge(8) and do some more things differently than vm-bhyve / iocage and the like, I wanted to have something straight forward, capable of making use of the wonderful bhyve_config(5) feature, for use cases where /usr/share/examples/bhyve/vmrun.sh isn't suitable. Please find attached my first approch, which currently covers the following features: - auto-preload FreeBSD guest using bhyveload(8) in case config file doesn't define lpc.bootrom - Allows referencing %(youname_somevar) in config file if defined as bhyve_youname_somevar in rc.conf(5). (For example: bhyve_vmdisk_default_pool="myppol2" bhyve_vmdisk_default_dataset="bhyveVOL/sys" and pci.0.3.0.path=/dev/zvol/%(vmdisk_default_pool)/%(vmdisk_default_dataset)/%(name) in bhyve_config(5) file ) - Adaptive handling of start/stop requests depending on 'AUTO' 'ALL' or specific list of VM names, depending on the non-bhyve_cfg(5) 'autostart' option. - Hopefully balanced amount of messages about what's going on, to be user friendly but not spamming. There's a lot of room for improvements (selectable pre-jail/post-jail order, bootdisk detection, priority handling, a useful 'status' implementation, style) and for sure some bugs, but this version works well for my current setup. Happy to contribute if useful for others, feedback welcome. -harry rc.d_bhyve.shar.xz Description: application/xz
Re: 13.3 14.x panic in qlogic isp vm_fault_lookup: fault on nofault entry, addr: 0xfffffe0127d22000
> Subject: 13.3 14.x panic in qlogic isp vm_fault_lookup: fault on nofault entry, addr: 0xfe0127d22000 > 13.2 works. 13.3 and 14.x panic. 13.3 iso will work if load ispfw first (escape to loader, unload kernel, load ispfw, load kernel, boot) also, adding ispfw_load="YES" to loader.conf to the working 13.2-system, and then freebsd-update to 13.3 will also work. the working 13.2 : grep ^isp 13.2-dmesg isp0: port 0x6c00-0x6cff mem 0xfc4fc000-0xfc4f irq 16 at device 0.0 on pci3 isp0: Mailbox Command (0x8) Timeout (500us) (isp_reset:439) isp0: Mailbox Command 'ABOUT FIRMWARE' failed (TIMEOUT) isp0: isp_reinit: cannot reset card isp0: See the ispfw(4) man page on how to load known good firmware at boot time isp0: port 0x9c00-0x9cff mem 0xfcbfc000-0xfcbf irq 18 at device 0.0 on pci9 isp0: Mailbox Command (0x8) Timeout (500us) (isp_reset:439) isp0: Mailbox Command 'ABOUT FIRMWARE' failed (TIMEOUT) isp0: isp_reinit: cannot reset card isp0: See the ispfw(4) man page on how to load known good firmware at boot time isp0: port 0x6c00-0x6cff mem 0xfc4fc000-0xfc4f irq 16 at device 0.0 on pci3 isp_2400: could not load firmware image, error 6 isp0: Mailbox Command (0x8) Timeout (500us) (isp_reset:439) isp0: Mailbox Command 'ABOUT FIRMWARE' failed (TIMEOUT) isp0: isp_reinit: cannot reset card isp0: See the ispfw(4) man page on how to load known good firmware at boot time isp0: port 0x9c00-0x9cff mem 0xfcbfc000-0xfcbf irq 18 at device 0.0 on pci9 isp_2400: could not load firmware image, error 6 isp0: Mailbox Command (0x8) Timeout (500us) (isp_reset:439) isp0: Mailbox Command 'ABOUT FIRMWARE' failed (TIMEOUT) isp0: isp_reinit: cannot reset card isp0: See the ispfw(4) man page on how to load known good firmware at boot time isp0: port 0x6c00-0x6cff mem 0xfc4fc000-0xfc4f irq 16 at device 0.0 on pci3 isp1: port 0x9c00-0x9cff mem 0xfcbfc000-0xfcbf irq 18 at device 0.0 on pci9 working 13.3 dmesg with ispfw loaded in loader.conf grep ^isp 13.3-dmesg isp0: port 0x6c00-0x6cff mem 0xfc4fc000-0xfc4f irq 16 at device 0.0 on pci3 isp0: FLT[DEF]: Invalid length=0x(65535) isp0: invalid NVRAM header (55 aa 56) isp0: invalid NVRAM header (55 aa 56) isp0: bad frame length (0) from NVRAM - using 1024 isp1: port 0x9c00-0x9cff mem 0xfcbfc000-0xfcbf irq 18 at device 0.0 on pci9 isp1: FLT[DEF]: Invalid length=0x(65535) isp1: invalid NVRAM header (55 aa 56) isp1: invalid NVRAM header (55 aa 56) isp1: bad frame length (0) from NVRAM - using 1024 Sent: Tuesday, July 16, 2024 at 6:27 PM From: "Roger Hammerstein" To: curr...@freebsd.org Subject: 13.3 14.x panic in qlogic isp vm_fault_lookup: fault on nofault entry, addr: 0xfe0127d22000 13.2 works. 13.3 and 14.x panic. an older system with two qlogic isp cards, isp0 and isp1, nothing attached to them, and it panics on boot with 13.3 and 14.x images. 13.2 works Autoloading module: ichsmb ichsmb0: port 0x300-0x31f irq 22 at device 31.3 on pci0 smbus0: on ichsmb0 isp1: port 0x9c00-0x9cff mem 0xfcbfc000-0xfcbf irq 18 at device 0.0 on pci9 isp1: FLT[DEF]: Invalid length=0x(65535) panic: vm_fault_lookup: fault on nofault entry, addr: 0xfe0127d22000 cpuid = 6 time = 1721060956 KDB: stack backtrace: Uptime: 17s Dumping 936 out of 24532 MB:..2%..11%..21%..31%..42%..52%..62%..71%..81%..91%
Re: July 2024 stabilization week
On Wed, 31 Jul 2024 at 21:52, Kyle Evans wrote: > On 7/31/24 14:31, Gleb Smirnoff wrote: > > On Tue, Jul 30, 2024 at 05:05:33PM -0500, Kyle Evans wrote: > > K> > > commit ce220b82ad546d3518a805750e5ee6add73f1fbf > > K> > > Author: Alfonso Siciliano > > K> > > Date: Sat May 25 02:42:46 2024 +0200 > > K> > > > > K> > > change: --form and --mixedgauge do not print field input to > output if > K> > > eldlen> <= 0 > > K> > > > > K> > > > > K> > > That means if you have any scripting using 'bsddialog --form' > with readonly > > K> > > values, you would need to adjust your scripts, otherwise your > variables would > > K> > > be messed up, leading to any possible kind of bugs. > > K> > > > K> > I can't find this revision. > > K> > > > K> > slippy$ git log ce220b82ad546d3518a805750e5ee6add73f1fbf > > K> > fatal: bad object ce220b82ad546d3518a805750e5ee6add73f1fbf > > K> > slippy$ > > K> > > > K> > To verify that my repo wasn't damaged in any way I cloned a fresh > new repo > > K> > from git.freebsd.org. I still can't list that revision. > > K> > > > K> > > K> It's a bsddialog commit, since the full history isn't preserved in > vendor > > K> imports for bsddialog > > K> > > K> > https://gitlab.com/alfix/bsddialog/-/commit/ce220b82ad546d3518a805750e5ee6add73f1fbf > > > > btw, I'd suggest to switch to subtree merges for future bsddialog > imports, so > > that full commit history is preserved. I can help with that, if needed. > > > > Sorry, to be a bit pedantic: the way it's managed now is still a subtree > merge, the difference is what's in the vendor branch that's merged in > (full history vs. release diffs). > > > Can you please ack that POLA breakage will be noted in the Release Notes > of > > 15.0 and won't be merged to 14.x? > > > I don't maintain bsddialog imports, just the one that fixed an immediate > issue for the work I was doing, but Alfonso noted in response to a > private e-mail thread you started that he'll do both. He hasn't yet > responded to current@ as stated in that e-mail, though, AFAICT. > > Thank you for the testing and the report, Of course I' ll add an entry to src/RELNOTES, new bsddialog shall not be merged to 14.0. Anyway, this change is not related to bsddialog 1.0.4 and to the recent kevans' import. I changed --form outputs in bsddialog 1.0.2 and 1.0.3, imported in CURRENT May 2024. I changed to restore the "old" (LGPL) dialog(1) behavior to avoid bsdinstall-networking-scripts faults (we have a discussion in current@ "bsdinstall wifi setup is broken on CURRENT" and some review). It is not a "full history" but I wrote rationale and FreeBSD notes in the commit messages: https://cgit.freebsd.org/src/tag/?h=vendor/bsddialog/1.0.3 https://cgit.freebsd.org/src/tag/?h=vendor/bsddialog/1.0.2 Also I maintain a CHANGELOG, src/contrib/bsddialog/CHANGELOG. Alfonso
Re: filemon
Dag-Erling Smørgrav wrote: > Loader I/O performance is much better these days so loading modules > pre-boot doesn't slow the boot down much any more, but it's still more That depends very much on the h/w, especially the storage attachment. None of which applies to any machine likely to be using filemon of course.
Re: July 2024 stabilization week
On 7/31/24 14:31, Gleb Smirnoff wrote: On Tue, Jul 30, 2024 at 05:05:33PM -0500, Kyle Evans wrote: K> > > commit ce220b82ad546d3518a805750e5ee6add73f1fbf K> > > Author: Alfonso Siciliano K> > > Date: Sat May 25 02:42:46 2024 +0200 K> > > K> > > change: --form and --mixedgauge do not print field input to output if > > eldlen> <= 0 K> > > K> > > K> > > That means if you have any scripting using 'bsddialog --form' with readonly K> > > values, you would need to adjust your scripts, otherwise your variables would K> > > be messed up, leading to any possible kind of bugs. K> > K> > I can't find this revision. K> > K> > slippy$ git log ce220b82ad546d3518a805750e5ee6add73f1fbf K> > fatal: bad object ce220b82ad546d3518a805750e5ee6add73f1fbf K> > slippy$ K> > K> > To verify that my repo wasn't damaged in any way I cloned a fresh new repo K> > from git.freebsd.org. I still can't list that revision. K> > K> K> It's a bsddialog commit, since the full history isn't preserved in vendor K> imports for bsddialog K> K> https://gitlab.com/alfix/bsddialog/-/commit/ce220b82ad546d3518a805750e5ee6add73f1fbf btw, I'd suggest to switch to subtree merges for future bsddialog imports, so that full commit history is preserved. I can help with that, if needed. Sorry, to be a bit pedantic: the way it's managed now is still a subtree merge, the difference is what's in the vendor branch that's merged in (full history vs. release diffs). Can you please ack that POLA breakage will be noted in the Release Notes of 15.0 and won't be merged to 14.x? I don't maintain bsddialog imports, just the one that fixed an immediate issue for the work I was doing, but Alfonso noted in response to a private e-mail thread you started that he'll do both. He hasn't yet responded to current@ as stated in that e-mail, though, AFAICT. Thanks, Kyle Evans
Re: July 2024 stabilization week
On Tue, Jul 30, 2024 at 05:05:33PM -0500, Kyle Evans wrote: K> > > commit ce220b82ad546d3518a805750e5ee6add73f1fbf K> > > Author: Alfonso Siciliano K> > > Date: Sat May 25 02:42:46 2024 +0200 K> > > K> > > change: --form and --mixedgauge do not print field input to output if > > eldlen> <= 0 K> > > K> > > K> > > That means if you have any scripting using 'bsddialog --form' with readonly K> > > values, you would need to adjust your scripts, otherwise your variables would K> > > be messed up, leading to any possible kind of bugs. K> > K> > I can't find this revision. K> > K> > slippy$ git log ce220b82ad546d3518a805750e5ee6add73f1fbf K> > fatal: bad object ce220b82ad546d3518a805750e5ee6add73f1fbf K> > slippy$ K> > K> > To verify that my repo wasn't damaged in any way I cloned a fresh new repo K> > from git.freebsd.org. I still can't list that revision. K> > K> K> It's a bsddialog commit, since the full history isn't preserved in vendor K> imports for bsddialog K> K> https://gitlab.com/alfix/bsddialog/-/commit/ce220b82ad546d3518a805750e5ee6add73f1fbf btw, I'd suggest to switch to subtree merges for future bsddialog imports, so that full commit history is preserved. I can help with that, if needed. Can you please ack that POLA breakage will be noted in the Release Notes of 15.0 and won't be merged to 14.x? -- Gleb Smirnoff
Re: Files not deleted via update procedure: rescue/gbde usr/include/machine/fiq.h usr/lib/include/machine/fiq.h usr/share/man/man4/CAM.4.gz
On 7/27/24 19:28, Mark Millard wrote: On Jul 27, 2024, at 16:07, Mark Millard wrote: The following old files were in the historically incrementally updated directory tree but not in the installation to an empty directory tree (checked via diff -rq): /usr/obj/DESTDIRs/main-CA7-poud/rescue/gbde /usr/obj/DESTDIRs/main-CA7-poud/usr/include/machine/fiq.h /usr/obj/DESTDIRs/main-CA7-poud/usr/lib/include/machine/fiq.h /usr/obj/DESTDIRs/main-CA7-poud/usr/share/man/man4/CAM.4.gz That was an armv7 context. For comparison/contrast, aarch64 had: /usr/obj/DESTDIRs/main-CA76-poud/rescue/gbde /usr/obj/DESTDIRs/main-CA76-poud/usr/lib/debug/usr/tests/cddl/usr.sbin/dtrace/amd64/kinst/ /usr/obj/DESTDIRs/main-CA76-poud/usr/lib/debug/usr/tests/lib/libc/ssp/h_raw.debug /usr/obj/DESTDIRs/main-CA76-poud/usr/share/examples/IPv6/USAGE /usr/obj/DESTDIRs/main-CA76-poud/usr/share/man/man2/recvmmsg.2.gz /usr/obj/DESTDIRs/main-CA76-poud/usr/share/man/man2/sendmmsg.2.gz /usr/obj/DESTDIRs/main-CA76-poud/usr/share/man/man4/CAM.4.gz /usr/obj/DESTDIRs/main-CA76-poud/usr/share/man/man4/geom_map.4.gz /usr/obj/DESTDIRs/main-CA76-poud/usr/tests/cddl/usr.sbin/dtrace/amd64/kinst/ /usr/obj/DESTDIRs/main-CA76-poud/usr/tests/lib/libc/ssp/h_raw Thanks, I've pushed fixes for most of these. The *mmsg.2.gz links are actually not supposed to be stale and D46200 should fix those. h_raw is a bit more of an odd duck that isn't easily solved. I'm not sure why it was installed in the past for you but isn't installed anymore. -- John Baldwin
a zfs thank you :)
Hi, I was pleasantly surprised when I installed a new [1] zfs-on-root -current to rpi4 that when adduser was invoked, I was given the option to encrypt the homedir. This is a great feature for my context [2]. It doesn't automount on boot but I think this is more of a feature rather than a bug. One can have a different password to the GELI one used to boot up the whole system. I have not tested yet whether one can have the user, once logged in, mount their homedir with doas(1). Right now, I mount the homedir like so: zfs load-key -a (prompts for password) zfs mount -a as root. I could I guess make a doas line for the user for zfs load-key -r zfsfile/system. Can anyone suggest any better ideas please? [1] n271321-9ae91f59c500 [2] machine and disk are not in a "secure" area. My concern is for data-at-rest. homedirs will have things like cached passwords user creds etc and it's to prevent someone just walking off with the disk and grabbing user creds for example. --
Re: aesni_load present in /boot/loader.conf on arm64
On Wed, Jul 31, 2024 at 10:48:15AM -0400, John Baldwin wrote:
> On 7/31/24 08:15, void wrote:
> > Hi,
> >
> > Looking at man 4 aesni it appears this pertains to intel and AMD only?
> > is its prescence on arm64 a bug?
> >
> > It seems to be added to /boot/loader.conf by default.
> >
> > The method I used to install is to boot to the latest snapshot at
> > the time, then plug in a usb3 disk, ran bsdinstall to that disk,
> > rebooted (this booted initially to the installer image), mounted the
> > msdos partition on /mnt. moved the /boot/efi/efi from the installed-to
> > disk out of the way, copied everything in /mnt to /boot/efi,
> > moved the /boot/efi/efi back to where it originally was, halted the machine
> > and
> > removed the installer image. This was to achieve zfs-on-root.
> >
> > Maybe something about the way I installed meant aesni was added?
>
> Looks like bsdinstall hardcodes aesni without doing an architecture
> check for both ZFS and geli.
>
> Probably the bits of the zfsboot script referencing aesni need to
> switch on the architecture. The trick is that depending on the
> architecture you may want to load more than one module. For 14
> I think you could get by with something like:
>
> crypto_kld()
> {
> case `uname -m` in
> amd64|i386)
> echo "aesni"
> ;;
> arm64)
> echo "armv8crypto"
> ;;
> *)
> echo ""
> }
>
> Then in the other parts of zfsboot call this function and treat it as
> a list of modules. On main I think you would want 32-bit arm and
> powerpc64 to list ossl, and you might want to include ossl for
> x86 and arm64 as well (eventually ossl should replace aesni and
> armv8crypto IMO).
Note that aesni has been compiled into amd64 kernels for a while, so
it's not really necessary to load aesni.ko explicitly unless one is
using a custom kernel. But yes, your proposal is better than loading
nothing at all.
> Side topic: the ossl(4) manpage in main is stale and needs to be updated
> to reflect armv7 and powerpc64 support. I'm not sure yet if it supports
> AES-GCM for armv8 as well.
No, I don't believe AES-GCM is supported on arm64. I'll work on getting
the man page updated this week.
Re: aesni_load present in /boot/loader.conf on arm64
On 7/31/24 08:15, void wrote:
Hi,
Looking at man 4 aesni it appears this pertains to intel and AMD only?
is its prescence on arm64 a bug?
It seems to be added to /boot/loader.conf by default.
The method I used to install is to boot to the latest snapshot at
the time, then plug in a usb3 disk, ran bsdinstall to that disk,
rebooted (this booted initially to the installer image), mounted the
msdos partition on /mnt. moved the /boot/efi/efi from the installed-to
disk out of the way, copied everything in /mnt to /boot/efi,
moved the /boot/efi/efi back to where it originally was, halted the machine and
removed the installer image. This was to achieve zfs-on-root.
Maybe something about the way I installed meant aesni was added?
Looks like bsdinstall hardcodes aesni without doing an architecture
check for both ZFS and geli.
Probably the bits of the zfsboot script referencing aesni need to
switch on the architecture. The trick is that depending on the
architecture you may want to load more than one module. For 14
I think you could get by with something like:
crypto_kld()
{
case `uname -m` in
amd64|i386)
echo "aesni"
;;
arm64)
echo "armv8crypto"
;;
*)
echo ""
}
Then in the other parts of zfsboot call this function and treat it as
a list of modules. On main I think you would want 32-bit arm and
powerpc64 to list ossl, and you might want to include ossl for
x86 and arm64 as well (eventually ossl should replace aesni and
armv8crypto IMO).
Side topic: the ossl(4) manpage in main is stale and needs to be updated
to reflect armv7 and powerpc64 support. I'm not sure yet if it supports
AES-GCM for armv8 as well.
--
John Baldwin
Re: setting the console to serial by defailt seems to not work
> On 31. Jul 2024, at 15:01, void wrote: > > On Tue, Jul 30, 2024 at 08:55:22PM +0200, Dag-Erling Smørgrav wrote: >> void writes: >>> The arm64 device is headless and i connect to it via serial. >>> I noticed the beastie menu come up with the option Video for >>> console. Cycled it to Serial, booted, all fine. [...] >> >> man boot.config > > Thank you for this. I did 'echo "-h" > /boot.config and then booted > and it showed console messages going to the console. This is a result I'm > happy with. > > What's a bit confusing is > 1. it did this with option 5: Cons set to Video in the beastie menu > 2. setting it to Serial in this menu doesn't 'stick' across reboots. > > -- > anything* you set in beastie menu is volatile and is not preserved. — * except if nvstore is used, but it needs a bit of love. rgds, toomas
aesni_load present in /boot/loader.conf on arm64
Hi, Looking at man 4 aesni it appears this pertains to intel and AMD only? is its prescence on arm64 a bug? It seems to be added to /boot/loader.conf by default. The method I used to install is to boot to the latest snapshot at the time, then plug in a usb3 disk, ran bsdinstall to that disk, rebooted (this booted initially to the installer image), mounted the msdos partition on /mnt. moved the /boot/efi/efi from the installed-to disk out of the way, copied everything in /mnt to /boot/efi, moved the /boot/efi/efi back to where it originally was, halted the machine and removed the installer image. This was to achieve zfs-on-root. Maybe something about the way I installed meant aesni was added? --
Re: setting the console to serial by defailt seems to not work
On Tue, Jul 30, 2024 at 08:55:22PM +0200, Dag-Erling Smørgrav wrote: void writes: The arm64 device is headless and i connect to it via serial. I noticed the beastie menu come up with the option Video for console. Cycled it to Serial, booted, all fine. [...] man boot.config Thank you for this. I did 'echo "-h" > /boot.config and then booted and it showed console messages going to the console. This is a result I'm happy with. What's a bit confusing is 1. it did this with option 5: Cons set to Video in the beastie menu 2. setting it to Serial in this menu doesn't 'stick' across reboots. --
Re: error: unknown type name 'sigset_t'
Hello,
I've pushed 9333e1cbd028 ("include: ssp: hide ppoll redirect behind
> __BSD_VISIBLE") and audited a bit for similar issues in the other ssp
> headers, but didn't see any off-hand. With that change:
>
> 100% tests passed, 0 tests failed out of 267
>
> Thanks,
>
> Kyle Evans
>
Upgraded today and tests builds and runs OK.
Thank you for ultra fast fix!
Cheers,
--
Nuno Teixeira
FreeBSD UNIX: Web: https://FreeBSD.org
Re: filemon
On Tue, Jul 30, 2024 at 10:02:37PM -0600, Warner Losh wrote: > On Tue, Jul 30, 2024, 12:54 PM Dag-Erling Smørgrav wrote: > > > Miroslav Lachman <000.f...@quip.cz> writes: > > > I'm a bit confused. If I understand it right, you say loader.conf > > > causes less memory fragmentation, but DES said "it still increases low > > > memory fragmentation". So what is true? And is this something to watch > > > out for, or is memory fragmentation not such a big deal? > > > > I used the wrong term. The loader loads the kernel and modules into a > > particular region of memory, while modules loaded after boot can go > > anywhere. Furthermore, modules loaded by the loader cannot be unloaded. > > So loading modules pre-boot does not increase fragmentation, but it uses > > up memory from a much more limited pool than loading them later. > > > > Yea. The lower memory addresses used to matter a lot. Now, we don't have > floppies or devices that care <256MB. Some can only do DMA to < 4GB. So > unless you have a huge RAM dusk compiled in, you're not going to > meaningfully depleate the under 4GB. And we don't treat that memory as > special for allocation so the modules loaded after boot could also wind up > there > > So it used to matter a lot. Now it's marginally relevant at best. There are still allocations that must happen below 4G. In particular, until we have CPUs that start directly in long mode, the AP startup code and all its data (initial stack, trampoline page tables etc) must happen below 4G. Same for the sleep/wake trampoline. Usually these special allocations are bound in quantity, so if we were lucky to have them succeed at early run time, they are no longer problem. But still it is enough critical allocations that must occur in low memory, where low is below 4G right now.
Re: filemon
On Tue, Jul 30, 2024, 12:54 PM Dag-Erling Smørgrav wrote: > Miroslav Lachman <000.f...@quip.cz> writes: > > I'm a bit confused. If I understand it right, you say loader.conf > > causes less memory fragmentation, but DES said "it still increases low > > memory fragmentation". So what is true? And is this something to watch > > out for, or is memory fragmentation not such a big deal? > > I used the wrong term. The loader loads the kernel and modules into a > particular region of memory, while modules loaded after boot can go > anywhere. Furthermore, modules loaded by the loader cannot be unloaded. > So loading modules pre-boot does not increase fragmentation, but it uses > up memory from a much more limited pool than loading them later. > Yea. The lower memory addresses used to matter a lot. Now, we don't have floppies or devices that care <256MB. Some can only do DMA to < 4GB. So unless you have a huge RAM dusk compiled in, you're not going to meaningfully depleate the under 4GB. And we don't treat that memory as special for allocation so the modules loaded after boot could also wind up there So it used to matter a lot. Now it's marginally relevant at best. Warner DES > -- > Dag-Erling Smørgrav - d...@freebsd.org >
Re: filemon
> On Jul 31, 2024, at 2:54 AM, Dag-Erling Smørgrav wrote: > > Miroslav Lachman <000.f...@quip.cz> writes: >> I'm a bit confused. If I understand it right, you say loader.conf >> causes less memory fragmentation, but DES said "it still increases low >> memory fragmentation". So what is true? And is this something to watch >> out for, or is memory fragmentation not such a big deal? > > I used the wrong term. The loader loads the kernel and modules into a > particular region of memory, while modules loaded after boot can go > anywhere. Furthermore, modules loaded by the loader cannot be unloaded. This is not accurate. Indeed the pre-loaded ( loaded by loader ) modules can be unloaded by kldunload(8). > So loading modules pre-boot does not increase fragmentation, but it uses > up memory from a much more limited pool than loading them later. > > DES > -- > Dag-Erling Smørgrav - d...@freebsd.org >
Re: build failure: clang.full
On 07/30/2024 9:25 am, Larry Rosenman wrote: On 07/30/2024 9:22 am, Ed Maste wrote: On Mon, 29 Jul 2024 at 19:54, Larry Rosenman wrote: I'm getting the following on an up2date checkout: Building /usr/obj/usr/src/amd64.amd64/usr.bin/clang/clang/clang.full ld: warning: /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a: archive member 'FaultMaps.o' is neither ET_REL nor LLVM bitcode This looks like you have a corrupt object in this archive. If you want to start on the path of determining the root cause you could try extracting FaultMaps.o (using ar or tar) and seeing what file(1) says about it. This happens even with a FRESH (I.E. empty) /usr/obj. It apparently got fixed, I just made it through a buildworld/buildkernel. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 13425 Ranch Road 620 N, Apt 718, Austin, TX 78717-1010
Re: July 2024 stabilization week
On 7/30/24 16:16, Cy Schubert wrote: In message , Gleb Smirnoff writes: On Tue, Jul 23, 2024 at 01:39:23PM -0700, Gleb Smirnoff wrote: T> On Mon, Jul 22, 2024 at 01:00:11AM -0700, Gleb Smirnoff wrote: T> T> This is an automated email to inform you that the July 2024 stabilizati on week T> T> started with FreeBSD/main at main-n271321-9ae91f59c500, which was tagge d as T> T> main-stabweek-2024-Jul. T> T> Testing at Netflix didn't discover any stability or performance regression s T> compared to June stabweek snapshot. My personal use in a desktop environm ent T> also didn't show any problems. Everybody are advised to update their Free BSD T> 15.0-CURRENT :) Belatedly we have found a kind of regression in main-stabweek-2024-Jul. Ther e is a POLA breaking behavior change in the new version of bsddialog(1). The change is clearly documented in the original commit message: commit ce220b82ad546d3518a805750e5ee6add73f1fbf Author: Alfonso Siciliano Date: Sat May 25 02:42:46 2024 +0200 change: --form and --mixedgauge do not print field input to output if <= 0 That means if you have any scripting using 'bsddialog --form' with readonly values, you would need to adjust your scripts, otherwise your variables would be messed up, leading to any possible kind of bugs. I can't find this revision. slippy$ git log ce220b82ad546d3518a805750e5ee6add73f1fbf fatal: bad object ce220b82ad546d3518a805750e5ee6add73f1fbf slippy$ To verify that my repo wasn't damaged in any way I cloned a fresh new repo from git.freebsd.org. I still can't list that revision. It's a bsddialog commit, since the full history isn't preserved in vendor imports for bsddialog https://gitlab.com/alfix/bsddialog/-/commit/ce220b82ad546d3518a805750e5ee6add73f1fbf
Re: July 2024 stabilization week
In message , Gleb Smirnoff writes: > On Tue, Jul 23, 2024 at 01:39:23PM -0700, Gleb Smirnoff wrote: > T> On Mon, Jul 22, 2024 at 01:00:11AM -0700, Gleb Smirnoff wrote: > T> T> This is an automated email to inform you that the July 2024 stabilizati > on week > T> T> started with FreeBSD/main at main-n271321-9ae91f59c500, which was tagge > d as > T> T> main-stabweek-2024-Jul. > T> > T> Testing at Netflix didn't discover any stability or performance regression > s > T> compared to June stabweek snapshot. My personal use in a desktop environm > ent > T> also didn't show any problems. Everybody are advised to update their Free > BSD > T> 15.0-CURRENT :) > > Belatedly we have found a kind of regression in main-stabweek-2024-Jul. Ther > e > is a POLA breaking behavior change in the new version of bsddialog(1). The > change is clearly documented in the original commit message: > > commit ce220b82ad546d3518a805750e5ee6add73f1fbf > Author: Alfonso Siciliano > Date: Sat May 25 02:42:46 2024 +0200 > > change: --form and --mixedgauge do not print field input to output if eldlen> <= 0 > > > That means if you have any scripting using 'bsddialog --form' with readonly > values, you would need to adjust your scripts, otherwise your variables would > be messed up, leading to any possible kind of bugs. I can't find this revision. slippy$ git log ce220b82ad546d3518a805750e5ee6add73f1fbf fatal: bad object ce220b82ad546d3518a805750e5ee6add73f1fbf slippy$ To verify that my repo wasn't damaged in any way I cloned a fresh new repo from git.freebsd.org. I still can't list that revision. > > -- > Gleb Smirnoff > -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0
Re: A few good ports on release iso images ?
Shawn Webb writes: > While probably less efficient than just running the tools outright, I > usually just set up a tmpfs that I chroot into and install those kinds > of packages. Yeah, I do something similar, with the footnote that I more often than not have no internet connection, so I have to remember to bring the packages. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: filemon
On 7/30/2024 4:44 AM, Dag-Erling Smørgrav wrote: "Poul-Henning Kamp" writes: Dag-Erling Smørgrav writes: There is very little difference between options and devices in kernel configuration files, but for what it's worth, filemon is a device, not an option. Apart from the internals of config(8) and it's input data, is there any actual difference left ? From the perspective of including files in the build, there is no difference: `foo/foo.c optional foo` does not care whether "foo" is an option or a device. However, options generate macros, while devices don't. So adding `option FILEMON` to your kernel config will cause filemon to be compiled into the kernel, but it will also generate an unneeded opt_filemon.h with `#define FILEMON 1`. Or it would, if it weren't for this: % git annotate sys/conf/options |& grep -i filemon 6c6f1f0185b84 (Peter Wemm 2013-07-03 20:22:12 + 109)FILEMON opt_dontuse.h which suggests Peter intended filemon to be an option rather than a device. DES Yes it probably should have been a device from the start. I do not recall why I picked one over the other. It was originally not config(8)able at all. -Peter
Re: July 2024 stabilization week
On Tue, Jul 23, 2024 at 01:39:23PM -0700, Gleb Smirnoff wrote: T> On Mon, Jul 22, 2024 at 01:00:11AM -0700, Gleb Smirnoff wrote: T> T> This is an automated email to inform you that the July 2024 stabilization week T> T> started with FreeBSD/main at main-n271321-9ae91f59c500, which was tagged as T> T> main-stabweek-2024-Jul. T> T> Testing at Netflix didn't discover any stability or performance regressions T> compared to June stabweek snapshot. My personal use in a desktop environment T> also didn't show any problems. Everybody are advised to update their FreeBSD T> 15.0-CURRENT :) Belatedly we have found a kind of regression in main-stabweek-2024-Jul. There is a POLA breaking behavior change in the new version of bsddialog(1). The change is clearly documented in the original commit message: commit ce220b82ad546d3518a805750e5ee6add73f1fbf Author: Alfonso Siciliano Date: Sat May 25 02:42:46 2024 +0200 change: --form and --mixedgauge do not print field input to output if <= 0 That means if you have any scripting using 'bsddialog --form' with readonly values, you would need to adjust your scripts, otherwise your variables would be messed up, leading to any possible kind of bugs. -- Gleb Smirnoff
Re: A few good ports on release iso images ?
On Tue, Jul 30, 2024 at 07:07:51PM +, Poul-Henning Kamp wrote: > I do not want want this to turn into a everything-and-Emacs bloat-party, > but I would find it really helpful if our install-ISO images had two > HW-spelunking ports installed: > > sysutils/smartmontools > > and > > sysutils/dmidecode > > Is that even possible ? > > Am I the only one who thinks so ? While probably less efficient than just running the tools outright, I usually just set up a tmpfs that I chroot into and install those kinds of packages. Just boot memstick.img, mount a tmpfs and a /dev under that, chroot and bring up networking, then pkg install. Simple process, but certainly more steps than having the tools pre-installed on the install media. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: A few good ports on release iso images ?
On 2024-07-30 19:07 +, Poul-Henning Kamp wrote: > sysutils/smartmontools > > and > > sysutils/dmidecode > > Is that even possible ? > > Am I the only one who thinks so ? I have missed having these tools numerous times over the years. Whether it's installing on a new machine or trying to figure out a failure on a current one both of these are indispensable. Would love to see them included. Amar.
A few good ports on release iso images ?
I do not want want this to turn into a everything-and-Emacs bloat-party, but I would find it really helpful if our install-ISO images had two HW-spelunking ports installed: sysutils/smartmontools and sysutils/dmidecode Is that even possible ? Am I the only one who thinks so ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: setting the console to serial by defailt seems to not work
void writes: > The arm64 device is headless and i connect to it via serial. > I noticed the beastie menu come up with the option Video for > console. Cycled it to Serial, booted, all fine. [...] man boot.config DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: filemon
Miroslav Lachman <000.f...@quip.cz> writes: > I'm a bit confused. If I understand it right, you say loader.conf > causes less memory fragmentation, but DES said "it still increases low > memory fragmentation". So what is true? And is this something to watch > out for, or is memory fragmentation not such a big deal? I used the wrong term. The loader loads the kernel and modules into a particular region of memory, while modules loaded after boot can go anywhere. Furthermore, modules loaded by the loader cannot be unloaded. So loading modules pre-boot does not increase fragmentation, but it uses up memory from a much more limited pool than loading them later. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: error: unknown type name 'sigset_t'
On 7/29/24 18:04, Nuno Teixeira wrote:
Hello all,
At main-n271434-b3cec803eaa4 security/s2n-tls fails to build tests with
`make test`.
I remember that tests were ok about 1 or 2 weeks ago.
I will update world soon and continue to monitor this tests failure.
Thanks,
Hi,
I've pushed 9333e1cbd028 ("include: ssp: hide ppoll redirect behind
__BSD_VISIBLE") and audited a bit for similar issues in the other ssp
headers, but didn't see any off-hand. With that change:
100% tests passed, 0 tests failed out of 267
Thanks,
Kyle Evans
Re: filemon
On Tue, Jul 30, 2024 at 11:57:07PM +0900, Tomoaki AOKI wrote: Another aspect is that loading multiple too large modules easily makes boots crash. Staging area (memory region which loader allocates to load kernel and modules, and maybe configured buffers) is limited. This is why I went looking for filemon as kernel device in the manpage initially. Generally, in the kernel config I'll comment out stuff thats not going to be used and add stuff i know is needed, instead of using loader.conf or other methods. --
Re: filemon
On 30/07/2024 16:30, Warner Losh wrote: [..] Does this also apply today? I recently read from someone on a mailing list that the kld_list in rc.conf is no longer needed, that any problems it used to solve are solved, and that the preferred way is to load everything from loader.conf. So I'm curious, what's the right thing to do then? (I load most of my modules from rc.conf) Either or for filemon. Either rc.conf's kld_list or loader.conf's filemon_load=YES. I've been recommending loader.conf since there's slightly less memory fragmentation, but even that effect is small. Only drm kmod has to be in kld_list. I'm a bit confused. If I understand it right, you say loader.conf causes less memory fragmentation, but DES said "it still increases low memory fragmentation". So what is true? And is this something to watch out for, or is memory fragmentation not such a big deal? Kind regards Miroslav Lachman
setting the console to serial by defailt seems to not work
Hi, I have an rpi4 arm64 device at n271321-9ae91f59c500 and an amd64 image running in screen(8) as zvol-backed vm at n271360-82283cad12a4 The arm64 device is headless and i connect to it via serial. I noticed the beastie menu come up with the option Video for console. Cycled it to Serial, booted, all fine. Rebooted and it's back at Video, which i don't want. At the time it was inconvenient to reboot that machine again, so made the amd64 test vm mentioned above. On installation, this was set to Serial in the beastie menu, rebooted and it remained at Serial. So rebooted again set it to Video. rebooted again and it had gone back to Serial! So looked at man 5 loader.conf and set console="vidconsole" and rebooted, expecting beastie to show Video. It remained as (or gone back to) Serial. Is this a bug? --
Re: filemon
On Tue, 30 Jul 2024 19:22:31 +0800
Alastair Hogge wrote:
>
>
> On 30 July 2024 5:38:57 pm AWST, Miroslav Lachman <000.f...@quip.cz> wrote:
> >On 30/07/2024 11:10, Dag-Erling Smørgrav wrote:
> >> Gary Jennejohn writes:
> >
> >[..]
> >
> >>> I also load it from /boot/loader.conf using filemon_load="YES"
> >>
> >> This does cause the module to be loaded at boot time, but it's slower
> >> than loading it later, and it increases memory fragmentation. A better
> >> option is to include "filemon" in the kld_list variable in /etc/rc.conf
> >> or /etc/rc.conf.d/kld. For instance,
> >>
> >> % cat /etc/rc.conf.d/kld/filemon
> >> kld_list="${kld_list} filemon"
> >
> >Does this also apply today? I recently read from someone on a mailing list
> >that the kld_list in rc.conf is no longer needed, that any problems it used
> >to solve are solved, and that the preferred way is to load everything from
> >loader.conf.
>
> Was it the following mail from Warner on a relates commit?
>
> https://lists.freebsd.org/archives/dev-commits-src-main/2024-May/024029.html
>
> --
> Sent from a device with a tiny bloody screen and no hard keyboard; please
> excuse my brevity.
Seems to be related to me, but only with single aspect, loading speed.
Another aspect is that loading multiple too large modules easily makes
boots crash. Staging area (memory region which loader allocates to load
kernel and modules, and maybe configured buffers) is limited.
Loading zfs.ko and GPU drivers (drm.ko, nvidia-drm.ko,
nvidia-modeset.ko, nvidia.ko and so on) via /boot/loader.conf[.loal]
alltogether easily makes boot to crash on module loads.
A few of examples related: Bug 277967 [1], Bug 277364 [2],
Bug 277827 [3]
You would find much, much more on forums.freebsd.org.
[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277967
[2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277364
[3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277827
--
Tomoaki AOKI
Re: filemon
On Tue, Jul 30, 2024, 4:50 AM Poul-Henning Kamp wrote: > > Dag-Erling Smørgrav writes: > > > There is very little difference between options and devices in kernel > > configuration files, but for what it's worth, filemon is a device, not > > an option. > > Apart from the internals of config(8) and it's input data, is there > any actual difference left ? > DEV_FOO is defined instead of FOO in the opt_*.h file is the only difference since otherwise both are added. I think that config's grammer only lets option foo=bar work, while device foo=bar does not. For options like filemon that conditionally include whole files without ifdefs elsewhere, there's no difference. Warner -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > p...@freebsd.org | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > >
Re: filemon
On Tue, Jul 30, 2024, 3:39 AM Miroslav Lachman <000.f...@quip.cz> wrote:
> On 30/07/2024 11:10, Dag-Erling Smørgrav wrote:
> > Gary Jennejohn writes:
>
> [..]
>
> >> I also load it from /boot/loader.conf using filemon_load="YES"
> >
> > This does cause the module to be loaded at boot time, but it's slower
> > than loading it later, and it increases memory fragmentation. A better
> > option is to include "filemon" in the kld_list variable in /etc/rc.conf
> > or /etc/rc.conf.d/kld. For instance,
> >
> > % cat /etc/rc.conf.d/kld/filemon
> > kld_list="${kld_list} filemon"
>
> Does this also apply today? I recently read from someone on a mailing
> list that the kld_list in rc.conf is no longer needed, that any problems
> it used to solve are solved, and that the preferred way is to load
> everything from loader.conf. So I'm curious, what's the right thing to
> do then? (I load most of my modules from rc.conf)
>
Either or for filemon. Either rc.conf's kld_list or loader.conf's
filemon_load=YES. I've been recommending loader.conf since there's slightly
less memory fragmentation, but even that effect is small. Only drm kmod has
to be in kld_list.
The performance advantage of the former is no longer there (for UEFI
systems) or is very hard to measure on all but super fringe machines (for
BIOS). Net booting would favor kld_list though.
Warner
Kind regards
> Miroslav Lachman
>
>
>
>
Re: build failure: clang.full
On 07/30/2024 9:22 am, Ed Maste wrote: On Mon, 29 Jul 2024 at 19:54, Larry Rosenman wrote: I'm getting the following on an up2date checkout: Building /usr/obj/usr/src/amd64.amd64/usr.bin/clang/clang/clang.full ld: warning: /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a: archive member 'FaultMaps.o' is neither ET_REL nor LLVM bitcode This looks like you have a corrupt object in this archive. If you want to start on the path of determining the root cause you could try extracting FaultMaps.o (using ar or tar) and seeing what file(1) says about it. This happens even with a FRESH (I.E. empty) /usr/obj. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 13425 Ranch Road 620 N, Apt 718, Austin, TX 78717-1010
Re: build failure: clang.full
On Mon, 29 Jul 2024 at 19:54, Larry Rosenman wrote: > > I'm getting the following on an up2date checkout: > Building /usr/obj/usr/src/amd64.amd64/usr.bin/clang/clang/clang.full > ld: warning: /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a: > archive member 'FaultMaps.o' is neither ET_REL nor LLVM bitcode This looks like you have a corrupt object in this archive. If you want to start on the path of determining the root cause you could try extracting FaultMaps.o (using ar or tar) and seeing what file(1) says about it.
Re: filemon
On 30/07/2024 12:31, Dag-Erling Smørgrav wrote: Miroslav Lachman <000.f...@quip.cz> writes: Dag-Erling Smørgrav writes: This does cause the module to be loaded at boot time, but it's slower than loading it later, and it increases memory fragmentation. Does this also apply today? I recently read from someone on a mailing list that the kld_list in rc.conf is no longer needed, that any problems it used to solve are solved, Loader I/O performance is much better these days so loading modules pre-boot doesn't slow the boot down much any more, but it's still more than zero, and it still increases low memory fragmentation, and you still can't unload a module that was loaded pre-boot. and that the preferred way is to load everything from loader.conf. I suspect you're extrapolating here. There is a very small number of cases where loading pre-boot is required (e.g. zfs.ko if your root is on zfs) or recommended (e.g. USB HID drivers due to probe ordering issues) but in the majority of cases, it is still better (even if only slightly) to wait until after boot. Thank you for the explanation. I will continue to use kld_list. Kind regards Miroslav Lachman
Re: filemon
On 30/07/2024 14:55, Michael Gmelin wrote: On Tue, 30 Jul 2024 11:38:57 +0200 Miroslav Lachman <000.f...@quip.cz> wrote: [..] Does this also apply today? I recently read from someone on a mailing list that the kld_list in rc.conf is no longer needed, that any problems it used to solve are solved, and that the preferred way is to load everything from loader.conf. So I'm curious, what's the right thing to do then? (I load most of my modules from rc.conf) I think this is what you're referring to, quoting Warner (emphasis is mine): https://lists.freebsd.org/archives/freebsd-current/2024-May/005953.html w> Also, in this case, kld_list is a terrible place to load the files. w> You're better off loading them with xxx_load=YES in loader.conf. The w> reason is that both uhid and ums will match your mouse. kld_list w> loads these in a random order (effectively) and the first one to w> load will claim the device, since there's no re-probe when the next w> one loads. **You should never use it, unless the module you're w> loading isn't supported by the boot loader (like drm-kmod)**. The old w> advice was to put everything in kld_list and it would speed up boot, w> but all the performance bugs in the boot loader have been fixed by a w> combination of moving to UEFI (which is generally faster), BIOSes w> with performance bugs disappearing 10 years ago and block caching w> being added to the boot loader. It should almost always be empty or w> just drm-mod these days (unless you somehow have special needs). w> w> By adding uhid last to this list in this way, you're guaranteeing w> you'll hit this bug because it's not after ums, and that things w> won't work. w> w> Warner Cheers Yes, this is it! I didn't remember the subject, so I couldn't find it. Thank you for the original message! Kind regards Miroslav Lachman
Re: filemon
On Tue, 30 Jul 2024 11:38:57 +0200
Miroslav Lachman <000.f...@quip.cz> wrote:
> On 30/07/2024 11:10, Dag-Erling Smørgrav wrote:
> > Gary Jennejohn writes:
>
> [..]
>
> >> I also load it from /boot/loader.conf using filemon_load="YES"
> >
> > This does cause the module to be loaded at boot time, but it's
> > slower than loading it later, and it increases memory
> > fragmentation. A better option is to include "filemon" in the
> > kld_list variable in /etc/rc.conf or /etc/rc.conf.d/kld. For
> > instance,
> >
> > % cat /etc/rc.conf.d/kld/filemon
> > kld_list="${kld_list} filemon"
>
> Does this also apply today? I recently read from someone on a mailing
> list that the kld_list in rc.conf is no longer needed, that any
> problems it used to solve are solved, and that the preferred way is
> to load everything from loader.conf. So I'm curious, what's the right
> thing to do then? (I load most of my modules from rc.conf)
>
I think this is what you're referring to, quoting Warner (emphasis is
mine):
https://lists.freebsd.org/archives/freebsd-current/2024-May/005953.html
w> Also, in this case, kld_list is a terrible place to load the files.
w> You're better off loading them with xxx_load=YES in loader.conf. The
w> reason is that both uhid and ums will match your mouse. kld_list
w> loads these in a random order (effectively) and the first one to
w> load will claim the device, since there's no re-probe when the next
w> one loads. **You should never use it, unless the module you're
w> loading isn't supported by the boot loader (like drm-kmod)**. The old
w> advice was to put everything in kld_list and it would speed up boot,
w> but all the performance bugs in the boot loader have been fixed by a
w> combination of moving to UEFI (which is generally faster), BIOSes
w> with performance bugs disappearing 10 years ago and block caching
w> being added to the boot loader. It should almost always be empty or
w> just drm-mod these days (unless you somehow have special needs).
w>
w> By adding uhid last to this list in this way, you're guaranteeing
w> you'll hit this bug because it's not after ums, and that things
w> won't work.
w>
w> Warner
Cheers
--
Michael Gmelin
Re: filemon
"Poul-Henning Kamp" writes: > Dag-Erling Smørgrav writes: > > There is very little difference between options and devices in kernel > > configuration files, but for what it's worth, filemon is a device, not > > an option. > Apart from the internals of config(8) and it's input data, is there > any actual difference left ? >From the perspective of including files in the build, there is no difference: `foo/foo.c optional foo` does not care whether "foo" is an option or a device. However, options generate macros, while devices don't. So adding `option FILEMON` to your kernel config will cause filemon to be compiled into the kernel, but it will also generate an unneeded opt_filemon.h with `#define FILEMON 1`. Or it would, if it weren't for this: % git annotate sys/conf/options |& grep -i filemon 6c6f1f0185b84 (Peter Wemm 2013-07-03 20:22:12 + 109)FILEMON opt_dontuse.h which suggests Peter intended filemon to be an option rather than a device. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: filemon
On 30 July 2024 5:38:57 pm AWST, Miroslav Lachman <000.f...@quip.cz> wrote:
>On 30/07/2024 11:10, Dag-Erling Smørgrav wrote:
>> Gary Jennejohn writes:
>
>[..]
>
>>> I also load it from /boot/loader.conf using filemon_load="YES"
>>
>> This does cause the module to be loaded at boot time, but it's slower
>> than loading it later, and it increases memory fragmentation. A better
>> option is to include "filemon" in the kld_list variable in /etc/rc.conf
>> or /etc/rc.conf.d/kld. For instance,
>>
>> % cat /etc/rc.conf.d/kld/filemon
>> kld_list="${kld_list} filemon"
>
>Does this also apply today? I recently read from someone on a mailing list
>that the kld_list in rc.conf is no longer needed, that any problems it used to
>solve are solved, and that the preferred way is to load everything from
>loader.conf.
Was it the following mail from Warner on a relates commit?
https://lists.freebsd.org/archives/dev-commits-src-main/2024-May/024029.html
--
Sent from a device with a tiny bloody screen and no hard keyboard; please
excuse my brevity.
Re: filemon
Dag-Erling Smørgrav writes: > There is very little difference between options and devices in kernel > configuration files, but for what it's worth, filemon is a device, not > an option. Apart from the internals of config(8) and it's input data, is there any actual difference left ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: filemon
On Tue, 30 Jul 2024 11:10:06 +0200
Dag-Erling Smørgrav wrote:
> Gary Jennejohn writes:
> > filemon is not a device, it's an option. So you can't have "device
> > filemon" in your kernel config file.
>
> There is very little difference between options and devices in kernel
> configuration files, but for what it's worth, filemon is a device, not
> an option.
>
Yes, I know. I now have device filemon in my kernel config file.
I mentioned that in a followup post, but apparently you didn't see it.
> > I compile it with makeoptions MODULES_OVERRIDE="filemon ..." in my
> > kernel config file.
>
> All that does is build the module as part of the buildkernel process.
> It does not include the module in the kernel, nor does it cause the
> module to be loaded at boot time.
>
> > I also load it from /boot/loader.conf using filemon_load="YES"
>
> This does cause the module to be loaded at boot time, but it's slower
> than loading it later, and it increases memory fragmentation. A better
> option is to include "filemon" in the kld_list variable in /etc/rc.conf
> or /etc/rc.conf.d/kld. For instance,
>
> % cat /etc/rc.conf.d/kld/filemon
> kld_list="${kld_list} filemon"
>
I'm aware of that. I've been using FreeBSD since version 1 and was also
a committer for a number of years, so I'm not exactly a tyro..
--
Gary Jennejohn
Re: filemon
Miroslav Lachman <000.f...@quip.cz> writes: > Dag-Erling Smørgrav writes: > > This does cause the module to be loaded at boot time, but it's slower > > than loading it later, and it increases memory fragmentation. > Does this also apply today? I recently read from someone on a mailing > list that the kld_list in rc.conf is no longer needed, that any > problems it used to solve are solved, Loader I/O performance is much better these days so loading modules pre-boot doesn't slow the boot down much any more, but it's still more than zero, and it still increases low memory fragmentation, and you still can't unload a module that was loaded pre-boot. > and that the preferred way is to load everything from loader.conf. I suspect you're extrapolating here. There is a very small number of cases where loading pre-boot is required (e.g. zfs.ko if your root is on zfs) or recommended (e.g. USB HID drivers due to probe ordering issues) but in the majority of cases, it is still better (even if only slightly) to wait until after boot. DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: filemon
Hi, On Tue, 30 Jul 2024, at 10:10, Dag-Erling Smørgrav wrote: > void writes: >> How would I go about remedying the issue that usage/examples >> are not present in manpages for either the device line in kernel >> config or filemon.ko ? > > https://reviews.freebsd.org/D46184 thank you!
Re: filemon
On 30/07/2024 11:10, Dag-Erling Smørgrav wrote:
Gary Jennejohn writes:
[..]
I also load it from /boot/loader.conf using filemon_load="YES"
This does cause the module to be loaded at boot time, but it's slower
than loading it later, and it increases memory fragmentation. A better
option is to include "filemon" in the kld_list variable in /etc/rc.conf
or /etc/rc.conf.d/kld. For instance,
% cat /etc/rc.conf.d/kld/filemon
kld_list="${kld_list} filemon"
Does this also apply today? I recently read from someone on a mailing
list that the kld_list in rc.conf is no longer needed, that any problems
it used to solve are solved, and that the preferred way is to load
everything from loader.conf. So I'm curious, what's the right thing to
do then? (I load most of my modules from rc.conf)
Kind regards
Miroslav Lachman
Re: filemon
void writes: > How would I go about remedying the issue that usage/examples > are not present in manpages for either the device line in kernel > config or filemon.ko ? https://reviews.freebsd.org/D46184 DES -- Dag-Erling Smørgrav - d...@freebsd.org
Re: filemon
Gary Jennejohn writes:
> filemon is not a device, it's an option. So you can't have "device
> filemon" in your kernel config file.
There is very little difference between options and devices in kernel
configuration files, but for what it's worth, filemon is a device, not
an option.
> I compile it with makeoptions MODULES_OVERRIDE="filemon ..." in my
> kernel config file.
All that does is build the module as part of the buildkernel process.
It does not include the module in the kernel, nor does it cause the
module to be loaded at boot time.
> I also load it from /boot/loader.conf using filemon_load="YES"
This does cause the module to be loaded at boot time, but it's slower
than loading it later, and it increases memory fragmentation. A better
option is to include "filemon" in the kld_list variable in /etc/rc.conf
or /etc/rc.conf.d/kld. For instance,
% cat /etc/rc.conf.d/kld/filemon
kld_list="${kld_list} filemon"
DES
--
Dag-Erling Smørgrav - d...@freebsd.org
Re: error: unknown type name 'sigset_t'
On 7/29/24 18:04, Nuno Teixeira wrote: Hello all, At main-n271434-b3cec803eaa4 security/s2n-tls fails to build tests with `make test`. I remember that tests were ok about 1 or 2 weeks ago. I will update world soon and continue to monitor this tests failure. Thanks, > Hi, Looking into it- thanks. I suspect it just needs an extra helping of `__BSD_VISIBLE` sprinkled in. Thanks, Kyle Evans
Re: Lua loader shows no menu
I understand the reason. Thanks for your investigation. > 2024/07/30 12:37、Warner Losh のメール: > > That was my fault. > > Turns out I forgot to copy the menu version back from my laptop to my server > before committing. > My laptop is the only place I had the menu. I got this stuff working there > last week after I got it > working on my server... then forgot I'd done that and pushed the wrong > version... So you got the > first, untested draft, not the actual code I'd tested. :( My apologies. > > Warner > > On Mon, Jul 29, 2024 at 6:56 PM 内藤祐一郎 wrote: > My lua boot loader shows no menu after updating the following commit with my > patch in the previous mail. > > FreeBSD vega.yuisoft.com 15.0-CURRENT FreeBSD 15.0-CURRENT #29 > main-n271492-0eac99f76ec3: Tue Jul 30 08:59:51 JST 2024 > yuich...@vega.yuisoft.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG > amd64 > > Both serial and efi consoles neither. > > >__ _ _ > | | | _ \ / | __ \ > | |___ _ __ ___ ___ | |_) | (___ | | | | > | ___| '__/ _ \/ _ \| _ < \___ \| | | | > | | | | | __/ __/| |_) |) | |__| | > | | | | |||| | | | > |_| |_| \___|\___||/|_/|_/ ```` > s` `.---...--.``` -/ > +-- Welcome to FreeBSD ---++o .--` /y:` +. > | | yo`:.:o `+- > | | y/ -/` -o/ > | | .- ::/sy+:. > | | / `-- / > | |`: :` > | |`: :` > | | / / > | | .--. > | | -- -. > | | `:` `:` > | | .-- `--. > | |.---.. > +-+ > > > — > Yuichiro NAITO > naito.yuich...@gmail.com > > > > — Yuichiro NAITO naito.yuich...@gmail.com
Re: Lua loader shows no menu
That was my fault. Turns out I forgot to copy the menu version back from my laptop to my server before committing. My laptop is the only place I had the menu. I got this stuff working there last week after I got it working on my server... then forgot I'd done that and pushed the wrong version... So you got the first, untested draft, not the actual code I'd tested. :( My apologies. Warner On Mon, Jul 29, 2024 at 6:56 PM 内藤祐一郎 wrote: > My lua boot loader shows no menu after updating the following commit with > my patch in the previous mail. > > FreeBSD vega.yuisoft.com 15.0-CURRENT FreeBSD 15.0-CURRENT #29 > main-n271492-0eac99f76ec3: Tue Jul 30 08:59:51 JST 2024 > yuich...@vega.yuisoft.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG > amd64 > > Both serial and efi consoles neither. > > >__ _ _ > | | | _ \ / | __ \ > | |___ _ __ ___ ___ | |_) | (___ | | | | > | ___| '__/ _ \/ _ \| _ < \___ \| | | | > | | | | | __/ __/| |_) |) | |__| | > | | | | |||| | | | > |_| |_| \___|\___||/|_/|_/ ``` > ` > s` `.---...--.``` > -/ > +-- Welcome to FreeBSD ---++o .--` /y:` > +. > | | yo`:.:o > `+- > | | y/ -/` > -o/ > | | .- > ::/sy+:. > | | / > `-- / > | |`: > :` > | |`: > :` > | | / > / > | | .- > -. > | | -- > -. > | | `:` `:` > | | .-- `--. > | |.---.. > +-+ > > > — > Yuichiro NAITO > naito.yuich...@gmail.com > > > > >
Re: lua loader failes
Yes. My fault. I'll fix. I thought I'd tested the menu... but apparently
not. My apologies.
Warner
On Mon, Jul 29, 2024, 6:44 PM 内藤祐一郎 wrote:
> Hi, I updated my FreeBSD current machine to the following commit.
>
> FreeBSD vega.yuisoft.com 15.0-CURRENT FreeBSD 15.0-CURRENT #29
> main-n271492-0eac99f76ec3: Tue Jul 30 08:59:51 JST 2024
> yuich...@vega.yuisoft.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
> amd64
>
> The lua loader fails as follows.
>
> ERROR: error loading module 'menu' from file '/boot/lua/menu.lua':
> /boot/lua/menu.lua:420: '}' expected (to close '{' at line 415) near 'vi
> sible’.
>
> A comma is probably missing. The following patch works for me.
>
> diff --git a/stand/lua/menu.lua b/stand/lua/menu.lua
> index 66d7fe673023..7d295eeb65eb 100644
> --- a/stand/lua/menu.lua
> +++ b/stand/lua/menu.lua
> @@ -416,7 +416,7 @@ menu.welcome = { entry_type =
> core.MENU_SEPARATOR,
> name = function()
> return "Loader requires updating"
> - end
> + end,
> visible = function()
> return core.loaderTooOld()
> end
>
>
> —
> Yuichiro NAITO
> naito.yuich...@gmail.com
>
>
>
>
>
Lua loader shows no menu
My lua boot loader shows no menu after updating the following commit with my patch in the previous mail. FreeBSD vega.yuisoft.com 15.0-CURRENT FreeBSD 15.0-CURRENT #29 main-n271492-0eac99f76ec3: Tue Jul 30 08:59:51 JST 2024 yuich...@vega.yuisoft.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 Both serial and efi consoles neither. __ _ _ | | | _ \ / | __ \ | |___ _ __ ___ ___ | |_) | (___ | | | | | ___| '__/ _ \/ _ \| _ < \___ \| | | | | | | | | __/ __/| |_) |) | |__| | | | | | |||| | | | |_| |_| \___|\___||/|_/|_/ ```` s` `.---...--.``` -/ +-- Welcome to FreeBSD ---++o .--` /y:` +. | | yo`:.:o `+- | | y/ -/` -o/ | | .- ::/sy+:. | | / `-- / | |`: :` | |`: :` | | / / | | .--. | | -- -. | | `:` `:` | | .-- `--. | |.---.. +-+ — Yuichiro NAITO naito.yuich...@gmail.com
lua loader failes
Hi, I updated my FreeBSD current machine to the following commit.
FreeBSD vega.yuisoft.com 15.0-CURRENT FreeBSD 15.0-CURRENT #29
main-n271492-0eac99f76ec3: Tue Jul 30 08:59:51 JST 2024
yuich...@vega.yuisoft.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64
The lua loader fails as follows.
ERROR: error loading module 'menu' from file '/boot/lua/menu.lua':
/boot/lua/menu.lua:420: '}' expected (to close '{' at line 415) near 'vi
sible’.
A comma is probably missing. The following patch works for me.
diff --git a/stand/lua/menu.lua b/stand/lua/menu.lua
index 66d7fe673023..7d295eeb65eb 100644
--- a/stand/lua/menu.lua
+++ b/stand/lua/menu.lua
@@ -416,7 +416,7 @@ menu.welcome = { entry_type =
core.MENU_SEPARATOR,
name = function()
return "Loader requires updating"
- end
+ end,
visible = function()
return core.loaderTooOld()
end
—
Yuichiro NAITO
naito.yuich...@gmail.com
build failure: clang.full
I'm getting the following on an up2date checkout: Building /usr/obj/usr/src/amd64.amd64/usr.bin/clang/clang/clang.full ld: warning: /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a: archive member 'FaultMaps.o' is neither ET_REL nor LLVM bitcode ld: warning: /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a: archive member 'FinalizeISel.o' is neither ET_REL nor LLVM bitcode ld: warning: /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a: archive member 'FixupStatepointCallerSaved.o' is neither ET_REL nor LLVM bitcode ld: warning: /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a: archive member 'FuncletLayout.o' is neither ET_REL nor LLVM bitcode ld: warning: /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a: archive member 'GCEmptyBasicBlocks.o' is neither ET_REL nor LLVM bitcode ld: warning: /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a: archive member 'GCMetadata.o' is neither ET_REL nor LLVM bitcode ld: warning: /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a: archive member 'GCRootLowering.o' is neither ET_REL nor LLVM bitcode ld: warning: /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a: archive member 'GIMatchTableExecutor.o' is neither ET_REL nor LLVM bitcode ld: warning: /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a: archive member 'GISelChangeObserver.o' is neither ET_REL nor LLVM bitcode ld: warning: /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a: archive member 'GISelKnownBits.o' is neither ET_REL nor LLVM bitcode ld: warning: /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a: archive member 'InlineAsmLowering.o' is neither ET_REL nor LLVM bitcode (cd /usr/src/tests/sys/cddl/zfs/tests/txg_integrity && DEPENDFILE=.depend.txg_integrity NO_SUBDIR=1 make -f /usr/src/tests/sys/cddl/zfs/tests/txg_integrity/Makefile _RECURSING_PROGS=t PROG=txg_integrity ) (cd /usr/src/tests/sys/cddl/zfs/tests/txg_integrity && DEPENDFILE=.depend.fsync_integrity NO_SUBDIR=1 make -f /usr/src/tests/sys/cddl/zfs/tests/txg_integrity/Makefile _RECURSING_PROGS=t PROG=fsync_integrity ) Building /usr/obj/usr/src/amd64.amd64/usr.sbin/tcpdump/tcpdump/print-lwres.o (cd /usr/src/tests/sys/devrandom && DEPENDFILE=.depend.uint128_test NO_SUBDIR=1 make -f /usr/src/tests/sys/devrandom/Makefile _RECURSING_PROGS=t PROG=uint128_test ) (cd /usr/src/tests/sys/fifo && DEPENDFILE=.depend.fifo_create NO_SUBDIR=1 make -f /usr/src/tests/sys/fifo/Makefile _RECURSING_PROGS=t PROG=fifo_create ) (cd /usr/src/tests/sys/fifo && DEPENDFILE=.depend.fifo_io NO_SUBDIR=1 make -f /usr/src/tests/sys/fifo/Makefile _RECURSING_PROGS=t PROG=fifo_io ) Building /usr/obj/usr/src/amd64.amd64/usr.sbin/tcpdump/tcpdump/print-m3ua.o (cd /usr/src/tests/sys/fifo && DEPENDFILE=.depend.fifo_misc NO_SUBDIR=1 make -f /usr/src/tests/sys/fifo/Makefile _RECURSING_PROGS=t PROG=fifo_misc ) (cd /usr/src/tests/sys/fifo && DEPENDFILE=.depend.fifo_open NO_SUBDIR=1 make -f /usr/src/tests/sys/fifo/Makefile _RECURSING_PROGS=t PROG=fifo_open ) (cd /usr/src/tests/sys/fifo && DEPENDFILE=.depend.fifo_kqueue NO_SUBDIR=1 make -f /usr/src/tests/sys/fifo/Makefile _RECURSING_PROGS=t PROG=fifo_kqueue ) (cd /usr/src/tests/sys/file && DEPENDFILE=.depend.flock_helper NO_SUBDIR=1 make -f /usr/src/tests/sys/file/Makefile _RECURSING_PROGS=t PROG=flock_helper ) (cd /usr/src/tests/sys/file && DEPENDFILE=.depend.ftruncate_test NO_SUBDIR=1 make -f /usr/src/tests/sys/file/Makefile _RECURSING_PROGS=t PROG=ftruncate_test ) (cd /usr/src/tests/sys/file && DEPENDFILE=.depend.newfileops_on_fork_test NO_SUBDIR=1 make -f /usr/src/tests/sys/file/Makefile _RECURSING_PROGS=t PROG=newfileops_on_fork_test ) (cd /usr/src/tests/sys/file && DEPENDFILE=.depend.closefrom_test NO_SUBDIR=1 make -f /usr/src/tests/sys/file/Makefile _RECURSING_PROGS=t PROG=closefrom_test ) (cd /usr/src/tests/sys/file && DEPENDFILE=.depend.dup_test NO_SUBDIR=1 make -f /usr/src/tests/sys/file/Makefile _RECURSING_PROGS=t PROG=dup_test ) (cd /usr/src/tests/sys/file && DEPENDFILE=.depend.fcntlflags_test NO_SUBDIR=1 make -f /usr/src/tests/sys/file/Makefile _RECURSING_PROGS=t PROG=fcntlflags_test ) Building /usr/obj/usr/src/amd64.amd64/usr.sbin/tcpdump/tcpdump/print-mobile.o ld: error: undefined symbol: llvm::GCLoweringID referenced by TargetPassConfig.cpp:842 (/usr/src/contrib/llvm-project/llvm/lib/CodeGen/TargetPassConfig.cpp:842) TargetPassConfig.o:(llvm::TargetPassConfig::addIRPasses()) in archive /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a ld: error: undefined symbol: llvm::FinalizeISelID referenced by TargetPassConfig.cpp:1045 (/usr/src/contrib/llvm-project/llvm/lib/CodeGen/TargetPassConfig.cpp:1045) TargetPassConfig.o:(llvm::TargetPassConfig::addCoreISelPasses()) in archive /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a ld: error: undefined symbol: llvm::FixupStatepointCallerSavedID referenced by
error: unknown type name 'sigset_t'
Hello all, At main-n271434-b3cec803eaa4 security/s2n-tls fails to build tests with `make test`. I remember that tests were ok about 1 or 2 weeks ago. I will update world soon and continue to monitor this tests failure. Thanks, [ 47% 363/744] /usr/bin/cc -DS2N_ATOMIC_SUPPORTED -DS2N_CLOEXEC_SUPPORTED -DS2N_CLOEXEC_XOPEN_SUPPORTED -DS2N_CPUID_AVAILABLE -DS2N_DIAGNOSTICS_POP_SUPPORTED -DS2N_DIAGNOSTICS_PUSH_SUPPORTED -DS2N_EXECINFO_AVAILA BLE -DS2N_FALL_THROUGH_SUPPORTED -DS2N_LIBCRYPTO_SUPPORTS_EVP_MD5_SHA1_HASH -DS2N_LIBCRYPTO_SUPPORTS_EVP_MD_CTX_SET_PKEY_CTX -DS2N_LIBCRYPTO_SUPPORTS_EVP_RC4 -DS2N_LIBCRYPTO_SUPPORTS_FLAG_NO_CHECK_TIME -DS2N_LIBC RYPTO_SUPPORTS_RSA_PSS_SIGNING -DS2N_LIBCRYPTO_SUPPORTS_X509_STORE_LIST -DS2N_MADVISE_SUPPORTED -DS2N_MINHERIT_SUPPORTED -DS2N_STACKTRACE -D_FORTIFY_SOURCE=2 -D_POSIX_C_SOURCE=200809L -I/wrkdirs/usr/ports/securit y/s2n-tls/work/s2n-tls-1.4.19/. -I/wrkdirs/usr/ports/security/s2n-tls/work/s2n-tls-1.4.19/tests -I/wrkdirs/usr/ports/security/s2n-tls/work/s2n-tls-1.4.19 -I/wrkdirs/usr/ports/security/s2n-tls/work/s2n-tls-1.4.19/ api -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -DNDEBUG -Wall -Wimplicit -Wunused -Wcomment -Wchar-subscripts -Wuninitialized -Wshadow -Wcas t-align -Wwrite-strings -Wformat-security -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-deprecated -fPIC -D_POSIX_C_SOURCE=200809L -std=gnu99 -flto -MD -MT CMakeFiles/s2n_release_non_empty_buffers_test.d ir/tests/unit/s2n_release_non_empty_buffers_test.c.o -MF CMakeFiles/s2n_release_non_empty_buffers_test.dir/tests/unit/s2n_release_non_empty_buffers_test.c.o.d -o CMakeFiles/s2n_release_non_empty_buffers_test.dir/ tests/unit/s2n_release_non_empty_buffers_test.c.o -c /wrkdirs/usr/ports/security/s2n-tls/work/s2n-tls-1.4.19/tests/unit/s2n_release_non_empty_buffers_test.c FAILED: CMakeFiles/s2n_release_non_empty_buffers_test.dir/tests/unit/s2n_release_non_empty_buffers_test.c.o /usr/bin/cc -DS2N_ATOMIC_SUPPORTED -DS2N_CLOEXEC_SUPPORTED -DS2N_CLOEXEC_XOPEN_SUPPORTED -DS2N_CPUID_AVAILABLE -DS2N_DIAGNOSTICS_POP_SUPPORTED -DS2N_DIAGNOSTICS_PUSH_SUPPORTED -DS2N_EXECINFO_AVAILABLE -DS2N_FALL_ THROUGH_SUPPORTED -DS2N_LIBCRYPTO_SUPPORTS_EVP_MD5_SHA1_HASH -DS2N_LIBCRYPTO_SUPPORTS_EVP_MD_CTX_SET_PKEY_CTX -DS2N_LIBCRYPTO_SUPPORTS_EVP_RC4 -DS2N_LIBCRYPTO_SUPPORTS_FLAG_NO_CHECK_TIME -DS2N_LIBCRYPTO_SUPPORTS_ RSA_PSS_SIGNING -DS2N_LIBCRYPTO_SUPPORTS_X509_STORE_LIST -DS2N_MADVISE_SUPPORTED -DS2N_MINHERIT_SUPPORTED -DS2N_STACKTRACE -D_FORTIFY_SOURCE=2 -D_POSIX_C_SOURCE=200809L -I/wrkdirs/usr/ports/security/s2n-tls/work/ s2n-tls-1.4.19/. -I/wrkdirs/usr/ports/security/s2n-tls/work/s2n-tls-1.4.19/tests -I/wrkdirs/usr/ports/security/s2n-tls/work/s2n-tls-1.4.19 -I/wrkdirs/usr/ports/security/s2n-tls/work/s2n-tls-1.4.19/api -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -DNDEBUG -Wall -Wimplicit -Wunused -Wcomment -Wchar-subscripts -Wuninitialized -Wshadow -Wcast-align -Wwrite -strings -Wformat-security -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-deprecated -fPIC -D_POSIX_C_SOURCE=200809L -std=gnu99 -flto -MD -MT CMakeFiles/s2n_release_non_empty_buffers_test.dir/tests/unit/s 2n_release_non_empty_buffers_test.c.o -MF CMakeFiles/s2n_release_non_empty_buffers_test.dir/tests/unit/s2n_release_non_empty_buffers_test.c.o.d -o CMakeFiles/s2n_release_non_empty_buffers_test.dir/tests/unit/s2n_ release_non_empty_buffers_test.c.o -c /wrkdirs/usr/ports/security/s2n-tls/work/s2n-tls-1.4.19/tests/unit/s2n_release_non_empty_buffers_test.c In file included from /wrkdirs/usr/ports/security/s2n-tls/work/s2n-tls-1.4.19/tests/unit/s2n_release_non_empty_buffers_test.c:17: In file included from /usr/include/poll.h:113: /usr/include/ssp/poll.h:49:11: error: unknown type name 'sigset_t' 49 | const sigset_t *__restrict newsigmask)) | ^ /usr/include/ssp/poll.h:49:11: error: unknown type name 'sigset_t' /usr/include/ssp/poll.h:49:11: error: unknown type name 'sigset_t' 3 errors generated. -- Nuno Teixeira FreeBSD UNIX: Web: https://FreeBSD.org
Re: filemon
How would I go about remedying the issue that usage/examples are not present in manpages for either the device line in kernel config or filemon.ko ? --
rebuilding with zfs-on-root on arm64
Hi, What/where are the full instructions for installing new kernel and world in a rpi4/arm64 zfs context? I'm looking for instructions that would account for u-boot, zfs and zfs encryption. --
Re: filemon
On Sat, 27 Jul 2024 19:31:37 +0100 void wrote: > On Sat, Jul 27, 2024 at 03:01:22PM +, Gary Jennejohn wrote: > > >filemon is not a device, it's an option. So you can't have "device > >filemon" in your kernel config file. > > > >I compile it with makeoptions MODULES_OVERRIDE="filemon ..." in my > >kernel config file. > > What's the actual line in your kernel config file please? > makeoptions MODULES_OVERRIDE="cpuctl filemon aesni vesa amdsmn amdtemp" These are the only modules under /usr/src which I use, so I limit building modules using MODULES_OVERRIDE. > >I also load it from /boot/loader.conf using filemon_load="YES" > > Why do you do both? (I presume both as you're saying you 'also load') > Because filemon.ko has to be loaded. But you're right, device filemon works in my kernel config file. I added device filemon (and removed it from MODULES_OVERRIDE) and my kernel compiled successfully. I removed filemon_load="YES" from /boot/loader.conf and booted the new kernel. kldstat -v showed that filemon was in the kernel. So I guess I misunderstood what optional means in /sys/conf/files:dev/filemon/filemon.c optional filemon -- Gary Jennejohn
Re: Files not deleted via update procedure: rescue/gbde usr/include/machine/fiq.h usr/lib/include/machine/fiq.h usr/share/man/man4/CAM.4.gz
On Jul 27, 2024, at 16:07, Mark Millard wrote: > The following old files were in the historically incrementally > updated directory tree but not in the installation to an empty > directory tree (checked via diff -rq): > > /usr/obj/DESTDIRs/main-CA7-poud/rescue/gbde > /usr/obj/DESTDIRs/main-CA7-poud/usr/include/machine/fiq.h > /usr/obj/DESTDIRs/main-CA7-poud/usr/lib/include/machine/fiq.h > /usr/obj/DESTDIRs/main-CA7-poud/usr/share/man/man4/CAM.4.gz That was an armv7 context. For comparison/contrast, aarch64 had: /usr/obj/DESTDIRs/main-CA76-poud/rescue/gbde /usr/obj/DESTDIRs/main-CA76-poud/usr/lib/debug/usr/tests/cddl/usr.sbin/dtrace/amd64/kinst/ /usr/obj/DESTDIRs/main-CA76-poud/usr/lib/debug/usr/tests/lib/libc/ssp/h_raw.debug /usr/obj/DESTDIRs/main-CA76-poud/usr/share/examples/IPv6/USAGE /usr/obj/DESTDIRs/main-CA76-poud/usr/share/man/man2/recvmmsg.2.gz /usr/obj/DESTDIRs/main-CA76-poud/usr/share/man/man2/sendmmsg.2.gz /usr/obj/DESTDIRs/main-CA76-poud/usr/share/man/man4/CAM.4.gz /usr/obj/DESTDIRs/main-CA76-poud/usr/share/man/man4/geom_map.4.gz /usr/obj/DESTDIRs/main-CA76-poud/usr/tests/cddl/usr.sbin/dtrace/amd64/kinst/ /usr/obj/DESTDIRs/main-CA76-poud/usr/tests/lib/libc/ssp/h_raw === Mark Millard marklmi at yahoo.com
Files not deleted via update procedure: rescue/gbde usr/include/machine/fiq.h usr/lib/include/machine/fiq.h usr/share/man/man4/CAM.4.gz
The following old files were in the historically incrementally updated directory tree but not in the installation to an empty directory tree (checked via diff -rq): /usr/obj/DESTDIRs/main-CA7-poud/rescue/gbde /usr/obj/DESTDIRs/main-CA7-poud/usr/include/machine/fiq.h /usr/obj/DESTDIRs/main-CA7-poud/usr/lib/include/machine/fiq.h /usr/obj/DESTDIRs/main-CA7-poud/usr/share/man/man4/CAM.4.gz === Mark Millard marklmi at yahoo.com
Re: filemon
Marek Zarychta wrote: > > What about filesystem perfomnace ? Have you benchmarked your FS and > whole system with and without filemon loaded ? FWIW filemon does nothing unless make opens the device. and then it only impacts syscalls done by that pid and its children. > I am not questionining the usecase, but loading this module only when > it's required seems to be more resonable for me. > > -- > Marek Zarychta
Re: filemon
slightly tangent question but does filemon and consequently WITH_META_MODE=YES work, when /usr/obj is on tmpfs? In my test, it is not and i tested without reboot, so /usr/obj is not removed. Reason is to avoid disk use when building world/kernel. On Sat, Jul 27, 2024 at 6:35 PM void wrote: > On Sat, Jul 27, 2024 at 03:01:22PM +, Gary Jennejohn wrote: > > >filemon is not a device, it's an option. So you can't have "device > >filemon" in your kernel config file. > > man 4 filemon has the following > > NAME > filemon – the filemon device > > [...] > > DESCRIPTION > The filemon device allows a process to collect file operations data > of > its children. The device /dev/filemon responds to two ioctl(2) > calls. > > [...] > > Are you sure it's not a device? The man page suggests otherwise. > > -- > >
Re: filemon
On Sat, Jul 27, 2024 at 03:01:22PM +, Gary Jennejohn wrote: filemon is not a device, it's an option. So you can't have "device filemon" in your kernel config file. man 4 filemon has the following NAME filemon – the filemon device [...] DESCRIPTION The filemon device allows a process to collect file operations data of its children. The device /dev/filemon responds to two ioctl(2) calls. [...] Are you sure it's not a device? The man page suggests otherwise. --
Re: filemon
On Sat, Jul 27, 2024 at 03:01:22PM +, Gary Jennejohn wrote: filemon is not a device, it's an option. So you can't have "device filemon" in your kernel config file. I compile it with makeoptions MODULES_OVERRIDE="filemon ..." in my kernel config file. What's the actual line in your kernel config file please? I also load it from /boot/loader.conf using filemon_load="YES" Why do you do both? (I presume both as you're saying you 'also load') --
Re: armv7 chroot [and lib32] on aarch64 is getting "nfssvc() ERR#78 'Function not implemented'" for "umount /mnt" of a nfs mounted UFS file system
On Jul 26, 2024, at 21:58, Mark Millard wrote:
> On Jul 26, 2024, at 21:20, Mark Millard wrote:
>
>> The original mount was:
>>
>> mount -onoatime 192.168.1.140:/ /mnt
>>
>> For reference:
>> 192.168.1.140:/ on /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/mnt
>> (nfs, noatime)
>>
>> gdb reports:
>>
>> Reading symbols from /sbin/umount...
>> Reading symbols from /usr/lib/debug//sbin/umount.debug...
>> [New LWP 100137]
>> Core was generated by `umount /mnt'.
>> Program terminated with signal SIGSYS, Bad system call.
>> Sent by kernel.
>> #0 nfssvc () at nfssvc.S:4
>>
>> warning: 4 nfssvc.S: No such file or directory
>> (gdb) bt
>> #0 nfssvc () at nfssvc.S:4
>> #1 0x00021be8 in umountfs (sfs=sfs@entry=0xce90) at
>> /home/pkgbuild/worktrees/main/sbin/umount/umount.c:396
>> #2 0x00022400 in checkname (mntname=0xddfb "/mnt",
>> typelist=typelist@entry=0x0) at
>> /home/pkgbuild/worktrees/main/sbin/umount/umount.c:327
>> #3 0x000218a4 in main (argc=, argv=) at
>> /home/pkgbuild/worktrees/main/sbin/umount/umount.c:195
>>
>>
>> truss's output ends with:
>>
>> . . .
>> mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
>> = 537321472 (0x2006e000)
>> statfs("/mnt",{
>> fstypename=nfs,mntonname=/usr/obj/DESTDIRs/main-armv7-chroot-ports-official/mnt,mntfromname=192.168.1.140:/,fsid=18ff003a3a00
>> }) = 0 (0x0)
>> fstatat(AT_FDCWD,"/mnt",{ mode=drwxr-xr-x ,inode=2,size=1536,blksize=4096
>> },0x0) = 0 (0x0)
>> fstatat(AT_FDCWD,"/mnt/..",{ mode=drwxr-xr-x
>> ,inode=73557804,size=512,blksize=32768 },0x0) = 0 (0x0)
>> mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
>> = 537219072 (0x20055000)
>> mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
>> = 537341952 (0x20073000)
>> nfssvc() ERR#78 'Function not implemented'
>> SIGNAL 12 (SIGSYS) code=SI_KERNEL
>> process killed, signal = 12 (core dumped)
>>
>>
>> For reference:
>>
>> if (nfssvc(NFSSVC_DUMPMNTOPTS, ) >= 0) {
>>
>>
>> armv7 chroot:
>>
>> # uname -apKU
>> FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT
>> main-n271408-4fab5f005482 GENERIC-NODEBUG arm armv7 1500021 1500021
>>
>> # ls -lodTt /var/cache/pkg/*.snap*.pkg | grep -v "^l" | sed -E
>> 's@^[^/]*(/.*/pkg/([^-]*-)(.*)(\.snap[^~]*)~[^.]*\.pkg)$@\2\4@' | sort -ru
>> FreeBSD-.snap20240726110821
>>
>>
>> aarch64 host:
>>
>> # uname -apKU
>> FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT
>> main-n271408-4fab5f005482 GENERIC-NODEBUG arm64 aarch64 1500021 1500021
>>
>> # ls -lodTt /var/cache/pkg/*.snap*.pkg | grep -v "^l" | sed -E
>> 's@^[^/]*(/.*/pkg/([^-]*-)(.*)(\.snap[^~]*)~[^.]*\.pkg)$@\2\4@' | sort -ru
>> FreeBSD-.snap20240726112037
>>
>>
>> After exiting the chroot, the aarch64 environment did the unmount /mnt just
>> fine.
>
>
> I set up a context where aarch64 ends up seeing (after chroot
> exit):
>
> # df -m
> Filesystem1M-blocks Used Avail Capacity Mounted on
> /dev/gpt/PBaseUFS 1114846 184896 84076118%/
> devfs 0 0 0 0%/dev
> /dev/gpt/PBaseEFI 244 2621811%/boot/efi
> 192.168.1.140:/ 823229 74755 68261610%
> /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/mnt
>
> I then used the armv7 umount:
>
> # /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/sbin/umount
> /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/mnt
> Bad system call (core dumped)
>
> The truss output for such shows:
>
> . . .
> freebsd32_getfsstat(0x2004e000,11720,MNT_NOWAIT) = 4 (0x4)
> freebsd32_mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
> = 537411584 (0x20084000)
> freebsd32_mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
> = 537423872 (0x20087000)
> freebsd32_mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
> = 537427968 (0x20088000)
> #155() ERR#78 'Function not implemented'
> SIGNAL 12 (SIGSYS) code=SI_KERNEL
> process killed, signal = 12 (core dumped)
>
>
> Side note:
>
> # more ~/pkgbase-snapshot-list.sh
> #! /bin/sh
> ls -lodTt /var/cache/pkg/*.snap*.pkg | grep -v "^l" | sed -E
> 's@^[^/]*(/.*/pkg/([^-]*-)(.*)(-[0-9][0-9]\.snap[^~]*)~[^.]*\.pkg)$@\2*\4@' |
> sort -ru
>
> results in the likes of:
>
> # ~/pkgbase-snapshot-list.sh
> FreeBSD-*-15.snap20240726112037
>
> that reads a little better.
I looked around and this lack of support is deliberate and
has been long term.
That tells me that, despite the amount of nfs mount/umount
activity of UFS file systems I've done over the years, I
just happened to have not done such from a chroot context
before, at least for the umount side of the pair.
===
Mark Millard
marklmi at yahoo.com
Re: filemon
Dnia Sat, Jul 27, 2024 at 03:27:19PM +0100, Nuno Teixeira napisał(a): > Hello, > > I use filemon for builds with WITH_META_MODE loaded from rc.conf: > kld_list="... filemon" for some years on both amd64 and aarch64. What about filesystem perfomnace ? Have you benchmarked your FS and whole system with and without filemon loaded ? I am not questionining the usecase, but loading this module only when it's required seems to be more resonable for me. -- Marek Zarychta
Re: filemon
On Sat, 27 Jul 2024 15:27:19 +0100 Nuno Teixeira wrote: > Hello, > > I use filemon for builds with WITH_META_MODE loaded from rc.conf: > kld_list="... filemon" for some years on both amd64 and aarch64. > > Cheers, > > void escreveu (sábado, 27/07/2024 à(s) 14:50): > > > Is it better to load filemon as kldload filemon, or to > > have it set as a device via 'device filemon' in the kernel > > config file? or to just load it when rebuilding the system? > > > > There is man 4 filemon but nothing there to describe usage as .ko > > or device. System is n271321-9ae91f59c500 on arm64. > > > > -- > > > > > filemon is not a device, it's an option. So you can't have "device filemon" in your kernel config file. I compile it with makeoptions MODULES_OVERRIDE="filemon ..." in my kernel config file. I also load it from /boot/loader.conf using filemon_load="YES" So, there are various ways to get filemon loaded. -- Gary Jennejohn
Re: filemon
Hello, I use filemon for builds with WITH_META_MODE loaded from rc.conf: kld_list="... filemon" for some years on both amd64 and aarch64. Cheers, void escreveu (sábado, 27/07/2024 à(s) 14:50): > Is it better to load filemon as kldload filemon, or to > have it set as a device via 'device filemon' in the kernel > config file? or to just load it when rebuilding the system? > > There is man 4 filemon but nothing there to describe usage as .ko > or device. System is n271321-9ae91f59c500 on arm64. > > -- > > -- Nuno Teixeira FreeBSD UNIX: Web: https://FreeBSD.org
Re: filemon
> On Jul 27, 2024, at 9:49 PM, void wrote: > > Is it better to load filemon as kldload filemon, or to > have it set as a device via 'device filemon' in the kernel config file? or to > just load it when rebuilding the system? > > There is man 4 filemon but nothing there to describe usage as .ko > or device. System is n271321-9ae91f59c500 on arm64. Some module needs to be statically linked ( aka device FOO ) to serve its function. Since filemon can be dynamically loaded I guess it ( dynamically loaded ) has no differences on usage with statically linked one. If it does have, then it should be warned in the man page. > > -- >
filemon
Is it better to load filemon as kldload filemon, or to have it set as a device via 'device filemon' in the kernel config file? or to just load it when rebuilding the system? There is man 4 filemon but nothing there to describe usage as .ko or device. System is n271321-9ae91f59c500 on arm64. --
Re: armv7 chroot [and lib32] on aarch64 is getting "nfssvc() ERR#78 'Function not implemented'" for "umount /mnt" of a nfs mounted UFS file system
On Jul 26, 2024, at 21:20, Mark Millard wrote:
> The original mount was:
>
> mount -onoatime 192.168.1.140:/ /mnt
>
> For reference:
> 192.168.1.140:/ on /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/mnt
> (nfs, noatime)
>
> gdb reports:
>
> Reading symbols from /sbin/umount...
> Reading symbols from /usr/lib/debug//sbin/umount.debug...
> [New LWP 100137]
> Core was generated by `umount /mnt'.
> Program terminated with signal SIGSYS, Bad system call.
> Sent by kernel.
> #0 nfssvc () at nfssvc.S:4
>
> warning: 4 nfssvc.S: No such file or directory
> (gdb) bt
> #0 nfssvc () at nfssvc.S:4
> #1 0x00021be8 in umountfs (sfs=sfs@entry=0xce90) at
> /home/pkgbuild/worktrees/main/sbin/umount/umount.c:396
> #2 0x00022400 in checkname (mntname=0xddfb "/mnt",
> typelist=typelist@entry=0x0) at
> /home/pkgbuild/worktrees/main/sbin/umount/umount.c:327
> #3 0x000218a4 in main (argc=, argv=) at
> /home/pkgbuild/worktrees/main/sbin/umount/umount.c:195
>
>
> truss's output ends with:
>
> . . .
> mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
> = 537321472 (0x2006e000)
> statfs("/mnt",{
> fstypename=nfs,mntonname=/usr/obj/DESTDIRs/main-armv7-chroot-ports-official/mnt,mntfromname=192.168.1.140:/,fsid=18ff003a3a00
> }) = 0 (0x0)
> fstatat(AT_FDCWD,"/mnt",{ mode=drwxr-xr-x ,inode=2,size=1536,blksize=4096
> },0x0) = 0 (0x0)
> fstatat(AT_FDCWD,"/mnt/..",{ mode=drwxr-xr-x
> ,inode=73557804,size=512,blksize=32768 },0x0) = 0 (0x0)
> mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
> = 537219072 (0x20055000)
> mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
> = 537341952 (0x20073000)
> nfssvc() ERR#78 'Function not implemented'
> SIGNAL 12 (SIGSYS) code=SI_KERNEL
> process killed, signal = 12 (core dumped)
>
>
> For reference:
>
>if (nfssvc(NFSSVC_DUMPMNTOPTS, ) >= 0) {
>
>
> armv7 chroot:
>
> # uname -apKU
> FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT
> main-n271408-4fab5f005482 GENERIC-NODEBUG arm armv7 1500021 1500021
>
> # ls -lodTt /var/cache/pkg/*.snap*.pkg | grep -v "^l" | sed -E
> 's@^[^/]*(/.*/pkg/([^-]*-)(.*)(\.snap[^~]*)~[^.]*\.pkg)$@\2\4@' | sort -ru
> FreeBSD-.snap20240726110821
>
>
> aarch64 host:
>
> # uname -apKU
> FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT
> main-n271408-4fab5f005482 GENERIC-NODEBUG arm64 aarch64 1500021 1500021
>
> # ls -lodTt /var/cache/pkg/*.snap*.pkg | grep -v "^l" | sed -E
> 's@^[^/]*(/.*/pkg/([^-]*-)(.*)(\.snap[^~]*)~[^.]*\.pkg)$@\2\4@' | sort -ru
> FreeBSD-.snap20240726112037
>
>
> After exiting the chroot, the aarch64 environment did the unmount /mnt just
> fine.
I set up a context where aarch64 ends up seeing (after chroot
exit):
# df -m
Filesystem1M-blocks Used Avail Capacity Mounted on
/dev/gpt/PBaseUFS 1114846 184896 84076118%/
devfs 0 0 0 0%/dev
/dev/gpt/PBaseEFI 244 2621811%/boot/efi
192.168.1.140:/ 823229 74755 68261610%
/usr/obj/DESTDIRs/main-armv7-chroot-ports-official/mnt
I then used the armv7 umount:
# /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/sbin/umount
/usr/obj/DESTDIRs/main-armv7-chroot-ports-official/mnt
Bad system call (core dumped)
The truss output for such shows:
. . .
freebsd32_getfsstat(0x2004e000,11720,MNT_NOWAIT) = 4 (0x4)
freebsd32_mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
= 537411584 (0x20084000)
freebsd32_mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
= 537423872 (0x20087000)
freebsd32_mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
= 537427968 (0x20088000)
#155() ERR#78 'Function not implemented'
SIGNAL 12 (SIGSYS) code=SI_KERNEL
process killed, signal = 12 (core dumped)
Side note:
# more ~/pkgbase-snapshot-list.sh
#! /bin/sh
ls -lodTt /var/cache/pkg/*.snap*.pkg | grep -v "^l" | sed -E
's@^[^/]*(/.*/pkg/([^-]*-)(.*)(-[0-9][0-9]\.snap[^~]*)~[^.]*\.pkg)$@\2*\4@' |
sort -ru
results in the likes of:
# ~/pkgbase-snapshot-list.sh
FreeBSD-*-15.snap20240726112037
that reads a little better.
===
Mark Millard
marklmi at yahoo.com
armv7 chroot on aarch64 is getting "nfssvc() ERR#78 'Function not implemented'" for "umount /mnt" of a nfs mounted UFS file system
The original mount was:
mount -onoatime 192.168.1.140:/ /mnt
For reference:
192.168.1.140:/ on /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/mnt (nfs,
noatime)
gdb reports:
Reading symbols from /sbin/umount...
Reading symbols from /usr/lib/debug//sbin/umount.debug...
[New LWP 100137]
Core was generated by `umount /mnt'.
Program terminated with signal SIGSYS, Bad system call.
Sent by kernel.
#0 nfssvc () at nfssvc.S:4
warning: 4 nfssvc.S: No such file or directory
(gdb) bt
#0 nfssvc () at nfssvc.S:4
#1 0x00021be8 in umountfs (sfs=sfs@entry=0xce90) at
/home/pkgbuild/worktrees/main/sbin/umount/umount.c:396
#2 0x00022400 in checkname (mntname=0xddfb "/mnt",
typelist=typelist@entry=0x0) at
/home/pkgbuild/worktrees/main/sbin/umount/umount.c:327
#3 0x000218a4 in main (argc=, argv=) at
/home/pkgbuild/worktrees/main/sbin/umount/umount.c:195
truss's output ends with:
. . .
mmap(0x0,20480,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
= 537321472 (0x2006e000)
statfs("/mnt",{
fstypename=nfs,mntonname=/usr/obj/DESTDIRs/main-armv7-chroot-ports-official/mnt,mntfromname=192.168.1.140:/,fsid=18ff003a3a00
}) = 0 (0x0)
fstatat(AT_FDCWD,"/mnt",{ mode=drwxr-xr-x ,inode=2,size=1536,blksize=4096
},0x0) = 0 (0x0)
fstatat(AT_FDCWD,"/mnt/..",{ mode=drwxr-xr-x
,inode=73557804,size=512,blksize=32768 },0x0) = 0 (0x0)
mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
= 537219072 (0x20055000)
mmap(0x0,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGNED(12),-1,0x0)
= 537341952 (0x20073000)
nfssvc() ERR#78 'Function not implemented'
SIGNAL 12 (SIGSYS) code=SI_KERNEL
process killed, signal = 12 (core dumped)
For reference:
if (nfssvc(NFSSVC_DUMPMNTOPTS, ) >= 0) {
armv7 chroot:
# uname -apKU
FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT
main-n271408-4fab5f005482 GENERIC-NODEBUG arm armv7 1500021 1500021
# ls -lodTt /var/cache/pkg/*.snap*.pkg | grep -v "^l" | sed -E
's@^[^/]*(/.*/pkg/([^-]*-)(.*)(\.snap[^~]*)~[^.]*\.pkg)$@\2\4@' | sort -ru
FreeBSD-.snap20240726110821
aarch64 host:
# uname -apKU
FreeBSD aarch64-main-pbase 15.0-CURRENT FreeBSD 15.0-CURRENT
main-n271408-4fab5f005482 GENERIC-NODEBUG arm64 aarch64 1500021 1500021
# ls -lodTt /var/cache/pkg/*.snap*.pkg | grep -v "^l" | sed -E
's@^[^/]*(/.*/pkg/([^-]*-)(.*)(\.snap[^~]*)~[^.]*\.pkg)$@\2\4@' | sort -ru
FreeBSD-.snap20240726112037
After exiting the chroot, the aarch64 environment did the unmount /mnt just
fine.
===
Mark Millard
marklmi at yahoo.com
Re: [main has a fix for] armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023
On Jul 26, 2024, at 16:44, Warner Losh wrote: > On Fri, Jul 26, 2024, 5:37 PM Mark Millard wrote: >> On Jul 26, 2024, at 07:56, Philip Paeps wrote: >> >> > On 2024-07-26 22:46:57 (+0800), Mark Millard wrote: >> >> So, it looks like updating the kernel and world on ampere2 and >> >> enabling builds of main-armv7-default should no longer have >> >> main-armv7-default hang-up during graphviz installation (or >> >> analogous contexts). Hopefully, that means that >> >> main-armv7-default builds will then complete and be distributed. >> > >> > I've set the stop-builds flag on the ampere machines. I'll kick off a >> > cluster build and upgrade them when they finish their current builds (or >> > get stuck). >> > >> > Thanks for chasing this down. >> >> FYI: As stands, only main has the update. The MFC will not happen >> for about a week. ampere1 and ampere3 should probably wait to >> upate until after the MFC since they do not build main-armv7-* . >> >> Note: The fix is a world change, not a kernel change. So it is >> the jail's world that matters. >> >> I'm not sure if any existing releng/13.*/ or releng/14.*/ will >> get an update for this. stable/13/ and stable/14/ are likely to. > > I wonder if a rebuilt system will make it through an armv7 bsd-user poudriere > bulk I assume that this wording is about having amd64 with qemu attempting bulk -a for building amv7 packages, not about having aarch64 (without qemu) bulk -a with armv7 jails do so (which are now being done). Have I got that right? (It appears that main used to have some prior use of the __aeabi_* in question before the failure point, thereby historically avoiding the recursive lock use deadlock. 13 and 14 are still operational for bulk -a on aarch64 for armv7 jails --but are subject to breakage, just like main was.) If spreading the package-building load around more to amd64 contexts was a goal, and if amd64 with qemu worked well for aarch64, one could imagine having some of the aarch64 package builds on amd64 but all the armv7 ones on the ampere*'s. This may be more likely to work better overall than amd64 with qemu ever handling a 32-bit context well (armv7 here). === Mark Millard marklmi at yahoo.com
Re: [main has a fix for] armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023
On Fri, Jul 26, 2024, 5:37 PM Mark Millard wrote: > On Jul 26, 2024, at 07:56, Philip Paeps wrote: > > > On 2024-07-26 22:46:57 (+0800), Mark Millard wrote: > >> So, it looks like updating the kernel and world on ampere2 and > >> enabling builds of main-armv7-default should no longer have > >> main-armv7-default hang-up during graphviz installation (or > >> analogous contexts). Hopefully, that means that > >> main-armv7-default builds will then complete and be distributed. > > > > I've set the stop-builds flag on the ampere machines. I'll kick off a > cluster build and upgrade them when they finish their current builds (or > get stuck). > > > > Thanks for chasing this down. > > FYI: As stands, only main has the update. The MFC will not happen > for about a week. ampere1 and ampere3 should probably wait to > upate until after the MFC since they do not build main-armv7-* . > > Note: The fix is a world change, not a kernel change. So it is > the jail's world that matters. > > I'm not sure if any existing releng/13.*/ or releng/14.*/ will > get an update for this. stable/13/ and stable/14/ are likely to. > I wonder if a rebuilt system will make it through an armv7 bsd-user poudriere bulk Warner === > Mark Millard > marklmi at yahoo.com > > >
Re: [main has a fix for] armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023
On Jul 26, 2024, at 07:56, Philip Paeps wrote: > On 2024-07-26 22:46:57 (+0800), Mark Millard wrote: >> So, it looks like updating the kernel and world on ampere2 and >> enabling builds of main-armv7-default should no longer have >> main-armv7-default hang-up during graphviz installation (or >> analogous contexts). Hopefully, that means that >> main-armv7-default builds will then complete and be distributed. > > I've set the stop-builds flag on the ampere machines. I'll kick off a > cluster build and upgrade them when they finish their current builds (or get > stuck). > > Thanks for chasing this down. FYI: As stands, only main has the update. The MFC will not happen for about a week. ampere1 and ampere3 should probably wait to upate until after the MFC since they do not build main-armv7-* . Note: The fix is a world change, not a kernel change. So it is the jail's world that matters. I'm not sure if any existing releng/13.*/ or releng/14.*/ will get an update for this. stable/13/ and stable/14/ are likely to. === Mark Millard marklmi at yahoo.com
Re: [main has a fix for] armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023
On 2024-07-26 22:46:57 (+0800), Mark Millard wrote: So, it looks like updating the kernel and world on ampere2 and enabling builds of main-armv7-default should no longer have main-armv7-default hang-up during graphviz installation (or analogous contexts). Hopefully, that means that main-armv7-default builds will then complete and be distributed. I've set the stop-builds flag on the ampere machines. I'll kick off a cluster build and upgrade them when they finish their current builds (or get stuck). Thanks for chasing this down. Philip
Re: [main has a fix for] armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023
On Jul 25, 2024, at 09:48, Mark Millard wrote:
> Michal Meloun has committed a fix in main:
>
> See:
> https://lists.freebsd.org/archives/dev-commits-src-main/2024-July/025399.html
>
> that starts with:
>
> From: Michal Meloun
> Date: Thu, 25 Jul 2024 16:25:09 UTC
> The branch main has been updated by mmel:
>
> URL:
> https://cgit.FreeBSD.org/src/commit/?id=5670b8cc3672d5a6bc2c41eb48d7d01343c43ad0
>
> commit 5670b8cc3672d5a6bc2c41eb48d7d01343c43ad0
> Author: Michal Meloun
> AuthorDate: 2024-07-24 15:11:27 +
> Commit: Michal Meloun
> CommitDate: 2024-07-25 16:24:22 +
>
> libthr: Preresolve selected EABI symbols on arm.
>
> Add the ability to pre-resolve architecture-specific EABI symbols and
> use it on arm for selected EABI functions. These functions can be called
> with rtld bind lock write-locked, so they should be resolved in forward.
>
> Reported by: Mark Millard , John F Carr
> Reviewed by: kib, imp
> MFC after: 1 week
> Differential Revision: https://reviews.freebsd.org/D46104
> ---
> lib/libthr/arch/aarch64/include/pthread_md.h | 5 +++
> lib/libthr/arch/amd64/include/pthread_md.h | 5 +++
> lib/libthr/arch/arm/Makefile.inc | 3 ++
> lib/libthr/arch/arm/thr_rtld_arm.c | 67
> lib/libthr/arch/i386/include/pthread_md.h | 5 +++
> lib/libthr/arch/powerpc/include/pthread_md.h | 5 +++
> lib/libthr/arch/riscv/include/pthread_md.h | 5 +++
> lib/libthr/thread/thr_private.h | 1 +
> lib/libthr/thread/thr_rtld.c | 3 ++
> 9 files changed, 99 insertions(+)
>
> . . .
https://pkg.freebsd.org/FreeBSD:15:armv7/base_latest/ has 15.snap20240726110821
and updating to it leads to avoiding the hang-up in my dlopen_test.c testing.
It is based on:
126 static inline size_t
127 round_up(size_t size)
128 {
129 if (size % _thr_page_size != 0)
130 size = ((size / _thr_page_size) + 1) *
131 _thr_page_size;
132 return size;
133 }
that uses the _aeabi_* routine(s) in standard armv7 builds.
But that no longer causes the recursive locking deadlock
problem.
So, it looks like updating the kernel and world on ampere2 and
enabling builds of main-armv7-default should no longer have
main-armv7-default hang-up during graphviz installation (or
analogous contexts). Hopefully, that means that
main-armv7-default builds will then complete and be distributed.
===
Mark Millard
marklmi at yahoo.com
[main has a fix for] Re: armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023
Michal Meloun has committed a fix in main: See: https://lists.freebsd.org/archives/dev-commits-src-main/2024-July/025399.html that starts with: From: Michal Meloun Date: Thu, 25 Jul 2024 16:25:09 UTC The branch main has been updated by mmel: URL: https://cgit.FreeBSD.org/src/commit/?id=5670b8cc3672d5a6bc2c41eb48d7d01343c43ad0 commit 5670b8cc3672d5a6bc2c41eb48d7d01343c43ad0 Author: Michal Meloun AuthorDate: 2024-07-24 15:11:27 + Commit: Michal Meloun CommitDate: 2024-07-25 16:24:22 + libthr: Preresolve selected EABI symbols on arm. Add the ability to pre-resolve architecture-specific EABI symbols and use it on arm for selected EABI functions. These functions can be called with rtld bind lock write-locked, so they should be resolved in forward. Reported by: Mark Millard , John F Carr Reviewed by: kib, imp MFC after: 1 week Differential Revision: https://reviews.freebsd.org/D46104 --- lib/libthr/arch/aarch64/include/pthread_md.h | 5 +++ lib/libthr/arch/amd64/include/pthread_md.h | 5 +++ lib/libthr/arch/arm/Makefile.inc | 3 ++ lib/libthr/arch/arm/thr_rtld_arm.c | 67 lib/libthr/arch/i386/include/pthread_md.h | 5 +++ lib/libthr/arch/powerpc/include/pthread_md.h | 5 +++ lib/libthr/arch/riscv/include/pthread_md.h | 5 +++ lib/libthr/thread/thr_private.h | 1 + lib/libthr/thread/thr_rtld.c | 3 ++ 9 files changed, 99 insertions(+) . . . === Mark Millard marklmi at yahoo.com
Re: armv7-on-aarch64 stuck at urdlck
On Wed, Jul 24, 2024 at 11:34 AM m...@freebsd.org
wrote:
>
>
> On 24.07.2024 17:47, Konstantin Belousov wrote:
> > On Wed, Jul 24, 2024 at 01:07:39PM +, John F Carr wrote:
> >>
> >>
> >>> On Jul 24, 2024, at 06:50, Konstantin Belousov
> wrote:
> >>>
> >>> On Wed, Jul 24, 2024 at 12:34:57PM +0200, m...@freebsd.org wrote:
>
>
> On 24.07.2024 12:24, Konstantin Belousov wrote:
> > On Tue, Jul 23, 2024 at 08:11:13PM +, John F Carr wrote:
> >> On Jul 23, 2024, at 13:46, Michal Meloun
> wrote:
> >>>
> >>> On 23.07.2024 11:36, Konstantin Belousov wrote:
> On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
> > The good news is that I'm finally able to generate a
> working/locking
> > test case. The culprit (at least for me) is if "-mcpu" is used
> when
> > compiling libthr (e.g. indirectly injected via CPUTYPE in
> /etc/make.conf).
> > If it is not used, libthr is broken (regardless of -O level or
> debug/normal
> > build), but -mcpu=cortex-a15 will always produce a working
> libthr.
> I think this is very significant progress.
> Do you plan to drill down more to see what is going on?
> >>>
> >>> So the problem is now clear, and I fear it may apply to other
> architectures as well.
> >>> dlopen_object() (from rtld_elf),
> >>> https://cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766,
> >>> holds the rtld_bind_lock write lock for almost the entire time a
> new library is loaded.
> >>> If the code uses a yet unresolved symbol to load the library, the
> rtl_bind() function attempts to get read lock of rtld_bind_lock and a
> deadlock occurs.
> >>>
> >>> In this case, it round_up() in _thr_stack_fix_protection,
> >>>
> https://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136.
> >>> Issued by __aeabi_uidiv (since not all armv7 processors support HW
> divide).
> >>>
> >>> Unfortunately, I'm not sure how to fix it. The compiler can emit
> __aeabi_<> in any place, and I'm not sure if it can resolve all the symbols
> used by rtld_eld and libthr beforehand.
> >>>
> >>>
> >>> Michal
> >>>
> >>
> >> In this case (but not for all _aeabi_ functions) we can avoid
> division
> >> as long as page size is a power of 2.
> >>
> >> The function is
> >>
> >>static inline size_t
> >>round_up(size_t size)
> >>{
> >> if (size % _thr_page_size != 0)
> >> size = ((size / _thr_page_size) + 1) *
> >> _thr_page_size;
> >> return size;
> >>}
> >>
> >> The body can be condensed to
> >>
> >>return (size + _thr_page_size - 1) & ~(_thr_page_size - 1);
> >>
> >> This is shorter in both lines of code and instruction bytes.
> >
> > Lets not allow this to be lost. Could anybody confirm that the patch
> > below fixes the issue?
> >
> > commit d560f4f6690a48476565278fd07ca131bf4eeb3c
> > Author: Konstantin Belousov
> > Date: Wed Jul 24 13:17:55 2024 +0300
> >
> > rtld: avoid division in __thr_map_stacks_exec()
> > The function is called by rtld with the rtld bind lock
> write-locked,
> > when fixing the stack permission during dso load. Not every
> ARMv7 CPU
> > supports the div, which causes the recursive entry into rtld to
> resolve
> > the __aeabi_uidiv symbol, causing self-lock.
> > Workaround the problem by using roundup2() instead of
> open-coding less
> > efficient formula.
> > Diagnosed by: mmel
> > Based on submission by: John F Carr
> > Sponsored by: The FreeBSD Foundation
> > MFC after: 1 week
> >
> >>> Just realized that it is wrong. Stack size is user-controlled and it
> does
> >>> not need to be power of two.
> >>
> >> Your change is correct. _thr_page_size is set to getpagesize(),
> >> which is a power of 2. The call to roundup2 takes a user-provided
> >> size and rounds it up to a multiple of the system page size.
> >>
> >> I tested the change and it works. My change also works and
> >> should compile to identical code. I forgot there was a standard
> >> function to do the rounding.
> > Right, my bad, thank you for correcting my thinko.
> >
> >>
> >>> For final resolving of deadlocks, after a full day of digging, I'm
> very much
> incline of adding -znow to the linker flags for libthr.so (and maybe
> also
> for ld-elf.so). The runtime cost of resolving all symbols at startup
> is very
> low. Direct pre-solving in _thr_rtld_init() is problematic for the
> _aeabi_*
> symbols, since they don't have an official C prototypes, and some are
> not
> compatible with C calling conventions.
> >>> I do not like it. `-z now' changes (breaks) the ABI and makes some
> symbols
> >>> not preemtible.
> >>>
> >>> In the worst case, we would need a call to
Re: armv7-on-aarch64 stuck at urdlck
On 24.07.2024 17:47, Konstantin Belousov wrote:
On Wed, Jul 24, 2024 at 01:07:39PM +, John F Carr wrote:
On Jul 24, 2024, at 06:50, Konstantin Belousov wrote:
On Wed, Jul 24, 2024 at 12:34:57PM +0200, m...@freebsd.org wrote:
On 24.07.2024 12:24, Konstantin Belousov wrote:
On Tue, Jul 23, 2024 at 08:11:13PM +, John F Carr wrote:
On Jul 23, 2024, at 13:46, Michal Meloun wrote:
On 23.07.2024 11:36, Konstantin Belousov wrote:
On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
The good news is that I'm finally able to generate a working/locking
test case. The culprit (at least for me) is if "-mcpu" is used when
compiling libthr (e.g. indirectly injected via CPUTYPE in /etc/make.conf).
If it is not used, libthr is broken (regardless of -O level or debug/normal
build), but -mcpu=cortex-a15 will always produce a working libthr.
I think this is very significant progress.
Do you plan to drill down more to see what is going on?
So the problem is now clear, and I fear it may apply to other architectures as
well.
dlopen_object() (from rtld_elf),
https://cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766,
holds the rtld_bind_lock write lock for almost the entire time a new library is
loaded.
If the code uses a yet unresolved symbol to load the library, the rtl_bind()
function attempts to get read lock of rtld_bind_lock and a deadlock occurs.
In this case, it round_up() in _thr_stack_fix_protection,
https://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136.
Issued by __aeabi_uidiv (since not all armv7 processors support HW divide).
Unfortunately, I'm not sure how to fix it. The compiler can emit __aeabi_<> in
any place, and I'm not sure if it can resolve all the symbols used by rtld_eld and
libthr beforehand.
Michal
In this case (but not for all _aeabi_ functions) we can avoid division
as long as page size is a power of 2.
The function is
static inline size_t
round_up(size_t size)
{
if (size % _thr_page_size != 0)
size = ((size / _thr_page_size) + 1) *
_thr_page_size;
return size;
}
The body can be condensed to
return (size + _thr_page_size - 1) & ~(_thr_page_size - 1);
This is shorter in both lines of code and instruction bytes.
Lets not allow this to be lost. Could anybody confirm that the patch
below fixes the issue?
commit d560f4f6690a48476565278fd07ca131bf4eeb3c
Author: Konstantin Belousov
Date: Wed Jul 24 13:17:55 2024 +0300
rtld: avoid division in __thr_map_stacks_exec()
The function is called by rtld with the rtld bind lock write-locked,
when fixing the stack permission during dso load. Not every ARMv7 CPU
supports the div, which causes the recursive entry into rtld to resolve
the __aeabi_uidiv symbol, causing self-lock.
Workaround the problem by using roundup2() instead of open-coding less
efficient formula.
Diagnosed by: mmel
Based on submission by: John F Carr
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Just realized that it is wrong. Stack size is user-controlled and it does
not need to be power of two.
Your change is correct. _thr_page_size is set to getpagesize(),
which is a power of 2. The call to roundup2 takes a user-provided
size and rounds it up to a multiple of the system page size.
I tested the change and it works. My change also works and
should compile to identical code. I forgot there was a standard
function to do the rounding.
Right, my bad, thank you for correcting my thinko.
For final resolving of deadlocks, after a full day of digging, I'm very much
incline of adding -znow to the linker flags for libthr.so (and maybe also
for ld-elf.so). The runtime cost of resolving all symbols at startup is very
low. Direct pre-solving in _thr_rtld_init() is problematic for the _aeabi_*
symbols, since they don't have an official C prototypes, and some are not
compatible with C calling conventions.
I do not like it. `-z now' changes (breaks) the ABI and makes some symbols
not preemtible.
In the worst case, we would need a call to the asm routine which causes the
resolution of the _eabi_* symbols on arm.
It would also be possible to link libthr with libgcc.a and use a linker map
to hide the _eabi_ symbols.
In principle yes, but if the ARM ABI states that _eabi symbols must be used,
and exported from libc, then this is also some form of ABI breakage.
I hope that https://reviews.freebsd.org/D46104 is acceptable :)
Re: armv7-on-aarch64 stuck at urdlck
On Wed, Jul 24, 2024 at 01:07:39PM +, John F Carr wrote:
>
>
> > On Jul 24, 2024, at 06:50, Konstantin Belousov wrote:
> >
> > On Wed, Jul 24, 2024 at 12:34:57PM +0200, m...@freebsd.org wrote:
> >>
> >>
> >> On 24.07.2024 12:24, Konstantin Belousov wrote:
> >>> On Tue, Jul 23, 2024 at 08:11:13PM +, John F Carr wrote:
> On Jul 23, 2024, at 13:46, Michal Meloun wrote:
> >
> > On 23.07.2024 11:36, Konstantin Belousov wrote:
> >> On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
> >>> The good news is that I'm finally able to generate a working/locking
> >>> test case. The culprit (at least for me) is if "-mcpu" is used when
> >>> compiling libthr (e.g. indirectly injected via CPUTYPE in
> >>> /etc/make.conf).
> >>> If it is not used, libthr is broken (regardless of -O level or
> >>> debug/normal
> >>> build), but -mcpu=cortex-a15 will always produce a working libthr.
> >> I think this is very significant progress.
> >> Do you plan to drill down more to see what is going on?
> >
> > So the problem is now clear, and I fear it may apply to other
> > architectures as well.
> > dlopen_object() (from rtld_elf),
> > https://cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766,
> > holds the rtld_bind_lock write lock for almost the entire time a new
> > library is loaded.
> > If the code uses a yet unresolved symbol to load the library, the
> > rtl_bind() function attempts to get read lock of rtld_bind_lock and a
> > deadlock occurs.
> >
> > In this case, it round_up() in _thr_stack_fix_protection,
> > https://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136.
> > Issued by __aeabi_uidiv (since not all armv7 processors support HW
> > divide).
> >
> > Unfortunately, I'm not sure how to fix it. The compiler can emit
> > __aeabi_<> in any place, and I'm not sure if it can resolve all the
> > symbols used by rtld_eld and libthr beforehand.
> >
> >
> > Michal
> >
>
> In this case (but not for all _aeabi_ functions) we can avoid division
> as long as page size is a power of 2.
>
> The function is
>
> static inline size_t
> round_up(size_t size)
> {
> if (size % _thr_page_size != 0)
> size = ((size / _thr_page_size) + 1) *
> _thr_page_size;
> return size;
> }
>
> The body can be condensed to
>
> return (size + _thr_page_size - 1) & ~(_thr_page_size - 1);
>
> This is shorter in both lines of code and instruction bytes.
> >>>
> >>> Lets not allow this to be lost. Could anybody confirm that the patch
> >>> below fixes the issue?
> >>>
> >>> commit d560f4f6690a48476565278fd07ca131bf4eeb3c
> >>> Author: Konstantin Belousov
> >>> Date: Wed Jul 24 13:17:55 2024 +0300
> >>>
> >>> rtld: avoid division in __thr_map_stacks_exec()
> >>> The function is called by rtld with the rtld bind lock write-locked,
> >>> when fixing the stack permission during dso load. Not every ARMv7 CPU
> >>> supports the div, which causes the recursive entry into rtld to
> >>> resolve
> >>> the __aeabi_uidiv symbol, causing self-lock.
> >>> Workaround the problem by using roundup2() instead of open-coding less
> >>> efficient formula.
> >>> Diagnosed by: mmel
> >>> Based on submission by: John F Carr
> >>> Sponsored by: The FreeBSD Foundation
> >>> MFC after: 1 week
> >>>
> > Just realized that it is wrong. Stack size is user-controlled and it does
> > not need to be power of two.
>
> Your change is correct. _thr_page_size is set to getpagesize(),
> which is a power of 2. The call to roundup2 takes a user-provided
> size and rounds it up to a multiple of the system page size.
>
> I tested the change and it works. My change also works and
> should compile to identical code. I forgot there was a standard
> function to do the rounding.
Right, my bad, thank you for correcting my thinko.
>
> > For final resolving of deadlocks, after a full day of digging, I'm very much
> >> incline of adding -znow to the linker flags for libthr.so (and maybe also
> >> for ld-elf.so). The runtime cost of resolving all symbols at startup is
> >> very
> >> low. Direct pre-solving in _thr_rtld_init() is problematic for the _aeabi_*
> >> symbols, since they don't have an official C prototypes, and some are not
> >> compatible with C calling conventions.
> > I do not like it. `-z now' changes (breaks) the ABI and makes some symbols
> > not preemtible.
> >
> > In the worst case, we would need a call to the asm routine which causes the
> > resolution of the _eabi_* symbols on arm.
> >
>
> It would also be possible to link libthr with libgcc.a and use a linker map
> to hide the _eabi_ symbols.
In principle yes, but if the ARM ABI states that _eabi symbols must be used,
and
Re: armv7-on-aarch64 stuck at urdlck
> On Jul 24, 2024, at 06:50, Konstantin Belousov wrote:
>
> On Wed, Jul 24, 2024 at 12:34:57PM +0200, m...@freebsd.org wrote:
>>
>>
>> On 24.07.2024 12:24, Konstantin Belousov wrote:
>>> On Tue, Jul 23, 2024 at 08:11:13PM +, John F Carr wrote:
On Jul 23, 2024, at 13:46, Michal Meloun wrote:
>
> On 23.07.2024 11:36, Konstantin Belousov wrote:
>> On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
>>> The good news is that I'm finally able to generate a working/locking
>>> test case. The culprit (at least for me) is if "-mcpu" is used when
>>> compiling libthr (e.g. indirectly injected via CPUTYPE in
>>> /etc/make.conf).
>>> If it is not used, libthr is broken (regardless of -O level or
>>> debug/normal
>>> build), but -mcpu=cortex-a15 will always produce a working libthr.
>> I think this is very significant progress.
>> Do you plan to drill down more to see what is going on?
>
> So the problem is now clear, and I fear it may apply to other
> architectures as well.
> dlopen_object() (from rtld_elf),
> https://cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766,
> holds the rtld_bind_lock write lock for almost the entire time a new
> library is loaded.
> If the code uses a yet unresolved symbol to load the library, the
> rtl_bind() function attempts to get read lock of rtld_bind_lock and a
> deadlock occurs.
>
> In this case, it round_up() in _thr_stack_fix_protection,
> https://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136.
> Issued by __aeabi_uidiv (since not all armv7 processors support HW
> divide).
>
> Unfortunately, I'm not sure how to fix it. The compiler can emit
> __aeabi_<> in any place, and I'm not sure if it can resolve all the
> symbols used by rtld_eld and libthr beforehand.
>
>
> Michal
>
In this case (but not for all _aeabi_ functions) we can avoid division
as long as page size is a power of 2.
The function is
static inline size_t
round_up(size_t size)
{
if (size % _thr_page_size != 0)
size = ((size / _thr_page_size) + 1) *
_thr_page_size;
return size;
}
The body can be condensed to
return (size + _thr_page_size - 1) & ~(_thr_page_size - 1);
This is shorter in both lines of code and instruction bytes.
>>>
>>> Lets not allow this to be lost. Could anybody confirm that the patch
>>> below fixes the issue?
>>>
>>> commit d560f4f6690a48476565278fd07ca131bf4eeb3c
>>> Author: Konstantin Belousov
>>> Date: Wed Jul 24 13:17:55 2024 +0300
>>>
>>> rtld: avoid division in __thr_map_stacks_exec()
>>> The function is called by rtld with the rtld bind lock write-locked,
>>> when fixing the stack permission during dso load. Not every ARMv7 CPU
>>> supports the div, which causes the recursive entry into rtld to resolve
>>> the __aeabi_uidiv symbol, causing self-lock.
>>> Workaround the problem by using roundup2() instead of open-coding less
>>> efficient formula.
>>> Diagnosed by: mmel
>>> Based on submission by: John F Carr
>>> Sponsored by: The FreeBSD Foundation
>>> MFC after: 1 week
>>>
> Just realized that it is wrong. Stack size is user-controlled and it does
> not need to be power of two.
Your change is correct. _thr_page_size is set to getpagesize(),
which is a power of 2. The call to roundup2 takes a user-provided
size and rounds it up to a multiple of the system page size.
I tested the change and it works. My change also works and
should compile to identical code. I forgot there was a standard
function to do the rounding.
> For final resolving of deadlocks, after a full day of digging, I'm very much
>> incline of adding -znow to the linker flags for libthr.so (and maybe also
>> for ld-elf.so). The runtime cost of resolving all symbols at startup is very
>> low. Direct pre-solving in _thr_rtld_init() is problematic for the _aeabi_*
>> symbols, since they don't have an official C prototypes, and some are not
>> compatible with C calling conventions.
> I do not like it. `-z now' changes (breaks) the ABI and makes some symbols
> not preemtible.
>
> In the worst case, we would need a call to the asm routine which causes the
> resolution of the _eabi_* symbols on arm.
>
It would also be possible to link libthr with libgcc.a and use a linker map
to hide the _eabi_ symbols.
Re: armv7-on-aarch64 stuck at urdlck
On Wed, Jul 24, 2024 at 12:34:57PM +0200, m...@freebsd.org wrote:
>
>
> On 24.07.2024 12:24, Konstantin Belousov wrote:
> > On Tue, Jul 23, 2024 at 08:11:13PM +, John F Carr wrote:
> > > On Jul 23, 2024, at 13:46, Michal Meloun wrote:
> > > >
> > > > On 23.07.2024 11:36, Konstantin Belousov wrote:
> > > > > On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
> > > > > > The good news is that I'm finally able to generate a working/locking
> > > > > > test case. The culprit (at least for me) is if "-mcpu" is used when
> > > > > > compiling libthr (e.g. indirectly injected via CPUTYPE in
> > > > > > /etc/make.conf).
> > > > > > If it is not used, libthr is broken (regardless of -O level or
> > > > > > debug/normal
> > > > > > build), but -mcpu=cortex-a15 will always produce a working libthr.
> > > > > I think this is very significant progress.
> > > > > Do you plan to drill down more to see what is going on?
> > > >
> > > > So the problem is now clear, and I fear it may apply to other
> > > > architectures as well.
> > > > dlopen_object() (from rtld_elf),
> > > > https://cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766,
> > > > holds the rtld_bind_lock write lock for almost the entire time a new
> > > > library is loaded.
> > > > If the code uses a yet unresolved symbol to load the library, the
> > > > rtl_bind() function attempts to get read lock of rtld_bind_lock and a
> > > > deadlock occurs.
> > > >
> > > > In this case, it round_up() in _thr_stack_fix_protection,
> > > > https://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136.
> > > > Issued by __aeabi_uidiv (since not all armv7 processors support HW
> > > > divide).
> > > >
> > > > Unfortunately, I'm not sure how to fix it. The compiler can emit
> > > > __aeabi_<> in any place, and I'm not sure if it can resolve all the
> > > > symbols used by rtld_eld and libthr beforehand.
> > > >
> > > >
> > > > Michal
> > > >
> > >
> > > In this case (but not for all _aeabi_ functions) we can avoid division
> > > as long as page size is a power of 2.
> > >
> > > The function is
> > >
> > >static inline size_t
> > >round_up(size_t size)
> > >{
> > > if (size % _thr_page_size != 0)
> > > size = ((size / _thr_page_size) + 1) *
> > > _thr_page_size;
> > > return size;
> > >}
> > >
> > > The body can be condensed to
> > >
> > >return (size + _thr_page_size - 1) & ~(_thr_page_size - 1);
> > >
> > > This is shorter in both lines of code and instruction bytes.
> >
> > Lets not allow this to be lost. Could anybody confirm that the patch
> > below fixes the issue?
> >
> > commit d560f4f6690a48476565278fd07ca131bf4eeb3c
> > Author: Konstantin Belousov
> > Date: Wed Jul 24 13:17:55 2024 +0300
> >
> > rtld: avoid division in __thr_map_stacks_exec()
> > The function is called by rtld with the rtld bind lock write-locked,
> > when fixing the stack permission during dso load. Not every ARMv7 CPU
> > supports the div, which causes the recursive entry into rtld to resolve
> > the __aeabi_uidiv symbol, causing self-lock.
> > Workaround the problem by using roundup2() instead of open-coding less
> > efficient formula.
> > Diagnosed by: mmel
> > Based on submission by: John F Carr
> > Sponsored by: The FreeBSD Foundation
> > MFC after: 1 week
> >
Just realized that it is wrong. Stack size is user-controlled and it does
not need to be power of two.
> For final resolving of deadlocks, after a full day of digging, I'm very much
> incline of adding -znow to the linker flags for libthr.so (and maybe also
> for ld-elf.so). The runtime cost of resolving all symbols at startup is very
> low. Direct pre-solving in _thr_rtld_init() is problematic for the _aeabi_*
> symbols, since they don't have an official C prototypes, and some are not
> compatible with C calling conventions.
I do not like it. `-z now' changes (breaks) the ABI and makes some symbols
not preemtible.
In the worst case, we would need a call to the asm routine which causes the
resolution of the _eabi_* symbols on arm.
>
> Warner, Konstantin, could you please comment on this?
>
>
> Michal
Re: armv7-on-aarch64 stuck at urdlck
On 24.07.2024 12:24, Konstantin Belousov wrote:
On Tue, Jul 23, 2024 at 08:11:13PM +, John F Carr wrote:
On Jul 23, 2024, at 13:46, Michal Meloun wrote:
On 23.07.2024 11:36, Konstantin Belousov wrote:
On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
The good news is that I'm finally able to generate a working/locking
test case. The culprit (at least for me) is if "-mcpu" is used when
compiling libthr (e.g. indirectly injected via CPUTYPE in /etc/make.conf).
If it is not used, libthr is broken (regardless of -O level or debug/normal
build), but -mcpu=cortex-a15 will always produce a working libthr.
I think this is very significant progress.
Do you plan to drill down more to see what is going on?
So the problem is now clear, and I fear it may apply to other architectures as
well.
dlopen_object() (from rtld_elf),
https://cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766,
holds the rtld_bind_lock write lock for almost the entire time a new library is
loaded.
If the code uses a yet unresolved symbol to load the library, the rtl_bind()
function attempts to get read lock of rtld_bind_lock and a deadlock occurs.
In this case, it round_up() in _thr_stack_fix_protection,
https://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136.
Issued by __aeabi_uidiv (since not all armv7 processors support HW divide).
Unfortunately, I'm not sure how to fix it. The compiler can emit __aeabi_<> in
any place, and I'm not sure if it can resolve all the symbols used by rtld_eld and
libthr beforehand.
Michal
In this case (but not for all _aeabi_ functions) we can avoid division
as long as page size is a power of 2.
The function is
static inline size_t
round_up(size_t size)
{
if (size % _thr_page_size != 0)
size = ((size / _thr_page_size) + 1) *
_thr_page_size;
return size;
}
The body can be condensed to
return (size + _thr_page_size - 1) & ~(_thr_page_size - 1);
This is shorter in both lines of code and instruction bytes.
Lets not allow this to be lost. Could anybody confirm that the patch
below fixes the issue?
commit d560f4f6690a48476565278fd07ca131bf4eeb3c
Author: Konstantin Belousov
Date: Wed Jul 24 13:17:55 2024 +0300
rtld: avoid division in __thr_map_stacks_exec()
The function is called by rtld with the rtld bind lock write-locked,
when fixing the stack permission during dso load. Not every ARMv7 CPU
supports the div, which causes the recursive entry into rtld to resolve
the __aeabi_uidiv symbol, causing self-lock.
Workaround the problem by using roundup2() instead of open-coding less
efficient formula.
Diagnosed by: mmel
Based on submission by: John F Carr
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
For final resolving of deadlocks, after a full day of digging, I'm very
much incline of adding -znow to the linker flags for libthr.so (and
maybe also for ld-elf.so). The runtime cost of resolving all symbols at
startup is very low. Direct pre-solving in _thr_rtld_init() is
problematic for the _aeabi_* symbols, since they don't have an official
C prototypes, and some are not compatible with C calling conventions.
Warner, Konstantin, could you please comment on this?
Michal
Re: armv7-on-aarch64 stuck at urdlck
On Tue, Jul 23, 2024 at 08:11:13PM +, John F Carr wrote:
> On Jul 23, 2024, at 13:46, Michal Meloun wrote:
> >
> > On 23.07.2024 11:36, Konstantin Belousov wrote:
> >> On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
> >>> The good news is that I'm finally able to generate a working/locking
> >>> test case. The culprit (at least for me) is if "-mcpu" is used when
> >>> compiling libthr (e.g. indirectly injected via CPUTYPE in /etc/make.conf).
> >>> If it is not used, libthr is broken (regardless of -O level or
> >>> debug/normal
> >>> build), but -mcpu=cortex-a15 will always produce a working libthr.
> >> I think this is very significant progress.
> >> Do you plan to drill down more to see what is going on?
> >
> > So the problem is now clear, and I fear it may apply to other architectures
> > as well.
> > dlopen_object() (from rtld_elf),
> > https://cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766,
> > holds the rtld_bind_lock write lock for almost the entire time a new
> > library is loaded.
> > If the code uses a yet unresolved symbol to load the library, the
> > rtl_bind() function attempts to get read lock of rtld_bind_lock and a
> > deadlock occurs.
> >
> > In this case, it round_up() in _thr_stack_fix_protection,
> > https://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136.
> > Issued by __aeabi_uidiv (since not all armv7 processors support HW divide).
> >
> > Unfortunately, I'm not sure how to fix it. The compiler can emit
> > __aeabi_<> in any place, and I'm not sure if it can resolve all the symbols
> > used by rtld_eld and libthr beforehand.
> >
> >
> > Michal
> >
>
> In this case (but not for all _aeabi_ functions) we can avoid division
> as long as page size is a power of 2.
>
> The function is
>
> static inline size_t
> round_up(size_t size)
> {
> if (size % _thr_page_size != 0)
> size = ((size / _thr_page_size) + 1) *
> _thr_page_size;
> return size;
> }
>
> The body can be condensed to
>
> return (size + _thr_page_size - 1) & ~(_thr_page_size - 1);
>
> This is shorter in both lines of code and instruction bytes.
Lets not allow this to be lost. Could anybody confirm that the patch
below fixes the issue?
commit d560f4f6690a48476565278fd07ca131bf4eeb3c
Author: Konstantin Belousov
Date: Wed Jul 24 13:17:55 2024 +0300
rtld: avoid division in __thr_map_stacks_exec()
The function is called by rtld with the rtld bind lock write-locked,
when fixing the stack permission during dso load. Not every ARMv7 CPU
supports the div, which causes the recursive entry into rtld to resolve
the __aeabi_uidiv symbol, causing self-lock.
Workaround the problem by using roundup2() instead of open-coding less
efficient formula.
Diagnosed by: mmel
Based on submission by: John F Carr
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
diff --git a/lib/libthr/thread/thr_stack.c b/lib/libthr/thread/thr_stack.c
index f576a2c04104..d249bb5606fd 100644
--- a/lib/libthr/thread/thr_stack.c
+++ b/lib/libthr/thread/thr_stack.c
@@ -126,10 +126,7 @@ static char *last_stack = NULL;
static inline size_t
round_up(size_t size)
{
- if (size % _thr_page_size != 0)
- size = ((size / _thr_page_size) + 1) *
- _thr_page_size;
- return size;
+ return (roundup2(size, _thr_page_size));
}
void
Re: armv7-on-aarch64 stuck at urdlck
On Tue, Jul 23, 2024 at 2:11 PM John F Carr wrote:
> On Jul 23, 2024, at 13:46, Michal Meloun wrote:
> >
> > On 23.07.2024 11:36, Konstantin Belousov wrote:
> >> On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
> >>> The good news is that I'm finally able to generate a working/locking
> >>> test case. The culprit (at least for me) is if "-mcpu" is used when
> >>> compiling libthr (e.g. indirectly injected via CPUTYPE in
> /etc/make.conf).
> >>> If it is not used, libthr is broken (regardless of -O level or
> debug/normal
> >>> build), but -mcpu=cortex-a15 will always produce a working libthr.
> >> I think this is very significant progress.
> >> Do you plan to drill down more to see what is going on?
> >
> > So the problem is now clear, and I fear it may apply to other
> architectures as well.
> > dlopen_object() (from rtld_elf),
> > https://cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766,
> > holds the rtld_bind_lock write lock for almost the entire time a new
> library is loaded.
> > If the code uses a yet unresolved symbol to load the library, the
> rtl_bind() function attempts to get read lock of rtld_bind_lock and a
> deadlock occurs.
> >
> > In this case, it round_up() in _thr_stack_fix_protection,
> > https://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136.
> > Issued by __aeabi_uidiv (since not all armv7 processors support HW
> divide).
> >
> > Unfortunately, I'm not sure how to fix it. The compiler can emit
> __aeabi_<> in any place, and I'm not sure if it can resolve all the symbols
> used by rtld_eld and libthr beforehand.
> >
> >
> > Michal
> >
>
> In this case (but not for all _aeabi_ functions) we can avoid division
> as long as page size is a power of 2.
>
> The function is
>
> static inline size_t
> round_up(size_t size)
> {
> if (size % _thr_page_size != 0)
> size = ((size / _thr_page_size) + 1) *
> _thr_page_size;
> return size;
> }
>
> The body can be condensed to
>
> return (size + _thr_page_size - 1) & ~(_thr_page_size - 1);
>
> This is shorter in both lines of code and instruction bytes.
>
I like this change...
But we do need to fix the deadlocks... They seem to be more likely
when building in bsd-user emulation...
Warner
Re: July 2024 stabilization week
On Mon, Jul 22, 2024 at 01:00:11AM -0700, Gleb Smirnoff wrote: T> This is an automated email to inform you that the July 2024 stabilization week T> started with FreeBSD/main at main-n271321-9ae91f59c500, which was tagged as T> main-stabweek-2024-Jul. Testing at Netflix didn't discover any stability or performance regressions compared to June stabweek snapshot. My personal use in a desktop environment also didn't show any problems. Everybody are advised to update their FreeBSD 15.0-CURRENT :) There is one bug report that seems to be a regression: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280290 and it is related to hms(4). Unless we receive any regression report in this email thread until Wednesday morning at 8:00 UTC, let's declare the stabilization cycle done by that time. -- Gleb Smirnoff
Re: armv7-on-aarch64 stuck at urdlck
On Jul 23, 2024, at 13:46, Michal Meloun wrote:
>
> On 23.07.2024 11:36, Konstantin Belousov wrote:
>> On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
>>> The good news is that I'm finally able to generate a working/locking
>>> test case. The culprit (at least for me) is if "-mcpu" is used when
>>> compiling libthr (e.g. indirectly injected via CPUTYPE in /etc/make.conf).
>>> If it is not used, libthr is broken (regardless of -O level or debug/normal
>>> build), but -mcpu=cortex-a15 will always produce a working libthr.
>> I think this is very significant progress.
>> Do you plan to drill down more to see what is going on?
>
> So the problem is now clear, and I fear it may apply to other architectures
> as well.
> dlopen_object() (from rtld_elf),
> https://cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766,
> holds the rtld_bind_lock write lock for almost the entire time a new library
> is loaded.
> If the code uses a yet unresolved symbol to load the library, the rtl_bind()
> function attempts to get read lock of rtld_bind_lock and a deadlock occurs.
>
> In this case, it round_up() in _thr_stack_fix_protection,
> https://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136.
> Issued by __aeabi_uidiv (since not all armv7 processors support HW divide).
>
> Unfortunately, I'm not sure how to fix it. The compiler can emit __aeabi_<>
> in any place, and I'm not sure if it can resolve all the symbols used by
> rtld_eld and libthr beforehand.
>
>
> Michal
>
In this case (but not for all _aeabi_ functions) we can avoid division
as long as page size is a power of 2.
The function is
static inline size_t
round_up(size_t size)
{
if (size % _thr_page_size != 0)
size = ((size / _thr_page_size) + 1) *
_thr_page_size;
return size;
}
The body can be condensed to
return (size + _thr_page_size - 1) & ~(_thr_page_size - 1);
This is shorter in both lines of code and instruction bytes.
John Carr
Re: armv7-on-aarch64 stuck at urdlck
On Tue, Jul 23, 2024 at 07:46:51PM +0200, Michal Meloun wrote: > > > On 23.07.2024 11:36, Konstantin Belousov wrote: > > On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote: > > > The good news is that I'm finally able to generate a working/locking > > > test case. The culprit (at least for me) is if "-mcpu" is used when > > > compiling libthr (e.g. indirectly injected via CPUTYPE in /etc/make.conf). > > > If it is not used, libthr is broken (regardless of -O level or > > > debug/normal > > > build), but -mcpu=cortex-a15 will always produce a working libthr. > > > > I think this is very significant progress. > > > > Do you plan to drill down more to see what is going on? > > So the problem is now clear, and I fear it may apply to other architectures > as well. > dlopen_object() (from rtld_elf), > https://cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766, > holds the rtld_bind_lock write lock for almost the entire time a new library > is loaded. > If the code uses a yet unresolved symbol to load the library, the rtl_bind() > function attempts to get read lock of rtld_bind_lock and a deadlock occurs. > > In this case, it round_up() in _thr_stack_fix_protection, > https://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136. > Issued by __aeabi_uidiv (since not all armv7 processors support HW divide). > > Unfortunately, I'm not sure how to fix it. The compiler can emit __aeabi_<> > in any place, and I'm not sure if it can resolve all the symbols used by > rtld_eld and libthr beforehand. This is a common issue, we pre-resolve a lot of symbols to avoid lock recursion. Please take a look at lib/libthr/thread/thr_rtld.c _thr_rtld_init().
