Re: Request for Testing: TCP RACK
On Sat, 16 Mar 2024 10:11:22 + Nuno Teixeira wrote: > (...) > > > These entries are missing in GENERIC: > > > > makeoptions WITH_EXTRA_TCP_STACKS=1 > > From > https://cgit.freebsd.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc > WITH_EXTRA_TCP_STACKS was dropped. > > > options TCPHPTS > > That's the missing option in GENERIC that could lead to my slow > opearations problem > > > options TCP_RACK > > Don't think I need this one as I will use kernel module instead of > building it in kernel. > > Resuming I only need to add: > > options TCPHPTS > > Is this correct? > Yeah, that will probably fix it. According to a comment in /usr/src/sys/netinet/tcp_hpts.c it adds a high precision timer system for tcp, used by RACK and BBR. -- Gary Jennejohn
Re: Request for Testing: TCP RACK
On Sat, 16 Mar 2024 09:49:24 + Nuno Teixeira wrote: > Hello Gary, > > Nice that you found this. > > tcp_tack manual doesn't mention that we need extra config in kernel > but it loads module and it is shown in sysctl > net.inet.tcp.functions_available without errors. > > I will add missing config to GENERIC and see how it goes. > All the required information is here: https://freebsdfoundation.org/our-work/journal/browser-based-edition/rack-and-alternate-tcp-stacks-for-freebsd/ -- Gary Jennejohn
Re: Request for Testing: TCP RACK
On Sat, 16 Mar 2024 09:41:13 +0100 tue...@freebsd.org wrote: > > On 16. Mar 2024, at 08:57, Nuno Teixeira wrote: > > > > Hello all, > > > > On a laptop i7/16MB ram, desktop use and port testing (poudriere) I've > > noticed that all operations on OS was increased by 3 to 5 times > > longer. > > examples: > > - firefox took way long time to open > > - poudriere testport tooked up to 3 times longer to finished > > make.conf: > KERNCONF=GENERIC-NODEBUG > src.conf: > WITH_MALLOC_PRODUCTION=yes > > tested on main-n268800-6a6ec90681cf > > How did you enable the RACK stack? Does the poudriere involve > network interaction? > Interesting. RACK works for me: net.inet.tcp.functions_available: Stack D AliasPCB count freebsd freebsd 0 rack* rack 23 I don't see any lags when starting/using FireFox or any other browser. Mail delivery (in/out) is also not affected. But GENERIC, which is loaded by GENERIC-NODEBUG, doesn't support RACK. These entries are missing in GENERIC: makeoptions WITH_EXTRA_TCP_STACKS=1 options TCPHPTS options TCP_RACK -- Gary Jennejohn
Re: Request for Testing: TCP RACK
On Tue, 12 Mar 2024 20:14:17 +0100 tue...@freebsd.org wrote: > > On 12. Mar 2024, at 14:39, Nuno Teixeira wrote: > > > > Hello, > > > > I'm curious about tcp RACK. > > > > As I do not run on a server background, only a laptop and a rpi4 for > > poudriere, git, browsing, some torrent and ssh/sftp connections, will > > I see any difference using RACK? > > What tests should I do for comparison? > You might want to read the following article in the FreeBSD Journal: > https://freebsdfoundation.org/our-work/journal/browser-based-edition/rack-and-alternate-tcp-stacks-for-freebsd/ > > There is no specific area for testing. Just test the stack on > the systems you use with the workload you use and report back > any issues... > In the article we have option TCPHPTS and option TCP_RACK. But in /sys/conf/NOTES we have options TCPHPTS and options TCP_RACK and not option. -- Gary Jennejohn
Re: Missing files on -current
On Sat, 24 Feb 2024 06:53:37 -0800 bob prohaska wrote: > A Pi4 running -current completed a build/install cycle for world and kernel > without obvious errors but failed to reboot, reporting: > ... > Warning: no time-of-day clock registered, system time will not be set > accurately > Dual Console: Serial Primary, Video Secondary > /etc/rc: run_rc_scripts: not found > /etc/rc: run_rc_scripts: not found > /etc/rc: have: not found > > Sat Feb 24 13:42:09 UTC 2024 > 2024-02-24T13:42:10.007616+00:00 - init 31 - - can't exec getty > '/usr/libexec/getty' for port /dev/ttyv1: No such file or directory > ... > > Uname -a reports: > FreeBSD 15.0-CURRENT FreeBSD 15.0-CURRENT #121 main-n268499-b9870ba93ea9: > Fri Feb 23 23:14:59 PST 2024 > b...@nemesis.zefox.com:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC > arm64distribution. > > Power cycling allowed boot to single-user, running fsck -fy reports a clean > root file system. > > /etc/fstab contains > /dev/da0s2a / ufs rw 1 1 > /dev/da0s1 /boot/msdos msdosfs rw,noatime 0 0 > #tmpfs /tmp tmpfs rw,mode=1777,size=50m 0 0 > /dev/da0s2d /usrufs rw 2 2 > /dev/da0s2b noneswapsw > > There does not seem to be a file named run_rc_scripts present > in the filesystem. > > Any suggestions on how to back myself out of this corner > would be much appreciated! > > Thanks for reading, > The function run_rc_scripts is defined in /usr/src/libexec/rc/rc.subr and is called in /usr/src/libexec/rc/rc. /etc/rc includes /etc/rc.subr. So, maybe one of these files is not up to date under /etc? -- Gary Jennejohn
Re: 'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b
On Tue, 30 Jan 2024 08:12:23 -0800
David Wolfskill wrote:
> On Tue, Jan 30, 2024 at 03:49:54PM +0000, Gary Jennejohn wrote:
> > ...
> > I use 'shutdown -p now' and it's never failed to power down my computers.
> >
>
> I could say the same about "poweroff", up to the main-n267808-197944948e62
> -> main-n267841-0b3f9e435f2b transition. And I probably wouldn't
> have mentioned anything, except that each of the 3 machines (one
> headless build machine; 2 laptops) I tested exhibited the same change.
>
> Note, too, from src/sbin/shutdown/shutdown.c:
>
> /*
> * Test for the special case where the utility is called as
> * "poweroff", for which it runs 'shutdown -p now'.
> */
> if ((p = strrchr(argv[0], '/')) == NULL)
> p = argv[0];
> else
> ++p;
> if (strcmp(p, "poweroff") == 0) {
> if (getopt(argc, argv, "") != -1)
> usage((char *)NULL);
> argc -= optind;
> argv += optind;
> if (argc != 0)
> usage((char *)NULL);
> dopower = 1;
> offset = 0;
> (void)time();
> goto poweroff;
>
> (So I believe we are referring to the same code paths, whether by
> "shutdown -p now" or "poweroff".)
>
Interesting, I wasn't aware of this. Reading shutdown(8) I see that
poweroff is equivalent to shutdown -p now. Thanks!
--
Gary Jennejohn
Re: 'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b
On Tue, 30 Jan 2024 07:10:45 -0800 David Wolfskill wrote: > On Tue, Jan 30, 2024 at 03:56:16PM +0100, Tomek CEDRO wrote: > > On Tue, Jan 30, 2024 at 3:49?PM David Wolfskill wrote: > > > The machines where I track head (& stable/14) daily get powered off once > > > they have finished their work for the day; this is done via "poweroff". > > > > > > I noticed (this morning) that one of them never actually powered off > > > yesterday. After today's exercises (including the reboot & subsequent > > > poweroff), I saw on the (serial) console: > > > > Have you tried hw.efi.poweroff=0 in /boot/loader.conf ? :-) > > > > No; I don't mess with /boot/*.conf without a (plausibly good) reason. :-) > > But I can experiment... so I'm trying it now. > ... > Hmm... I don't see any difference in behavior. > > These systems each boot using BIOS (vs. UEFI), in case that's relevant. > I use 'shutdown -p now' and it's never failed to power down my computers. -- Gary Jennejohn
Re: problem updating to CURRENT from source
On Tue, 28 Nov 2023 12:01:47 -0500 Robert Huff wrote: > Hello: > I am trying to update a system running "14.0 CURRENT #0" to last > night's Current using source. > I read the RELNOTES; I read the directions in UPDATING under "To > rebuild everything". > I built world; built kernel; installed kernel; rebooted single > user - no problem. > Ran "etcupdate -p", resolved some existing conflicts - check. > > Ran "make installworld" and got: > > /bin/sh: /usr/obj/usr/src/amd64.amd64/rescue/rescue/rescue: not found > rescue/sh check failed, installation aborted > *** Error code 1 > > <"kicked in the head by a mule" look> > What have I done wrong? > More importantly: how do I fix it? > > I built and installed the latest main source yesterday and I see in my ~/obj usr/src/amd64.amd64/rescue/rescue/rescue (but I was already running FreeBSD-15). Did you do a clean build? This isn't mentioned in the "To rebuild everything" text, but since you're building a different branch I suspect that a clean build would be necessary. -- Gary Jennejohn
Re: uname -KU 1500001 1500000
On Wed, 15 Nov 2023 07:09:39 + Graham Perrin wrote: > On Mon, 2 Oct 2023 at 08:33, Mark Millard wrote: > > > Or file and ls results for the amd64.amd64/usr.bin/uname/uname.o ? > > (Just checking for if there are surprises.) > > Please, where would I find that file? I'm lost > Assuming that you have a /usr/obj and are compiling a AMD64 buildworld it should be here: /usr/obj/usr/src/amd64.amd64/usr.bin/uname/uname.o Otherwise replace amd64 with whatever architecture you're using. -- Gary Jennejohn
Re: Updating motherboard BIOS without MS Windows
On Sat, 11 Nov 2023 10:56:58 + Nuno Teixeira wrote: > Hello all, > > Maybe not the best mailing to ask it but... > > How do you update BIOS without Windows since most brands only have bios > software to windows? > > I'm about to buy a new pc without windows license and I'm looking for > brands that have bios-cli that work in FreeBSD. > > Thanks, > I've used a few different mainboards (Asus, Gigabyte) and I've never used Windows to update the BIOS. Most BIOSes allow updating from 1) a thumb drive with DOS (FreeDOS) installed and the BIOS image present or 2) just a BIOS image on a thumb drive with a FAT32 file system. I always use the second option. You should be able to get the mainboard's manual as a PDF on-line and then take a look at the BIOS description. It should clearly describe all supported options for updating the BIOS. -- Gary Jennejohn
Re: odd bhyve guest message (Khelp module "ertt" can't unload)
On Wed, 18 Oct 2023 12:20:24 +0100 void wrote: > I'm seeing this message on exit from a 14.0-RC1 guest on a host > running main-n265915 when it exits normally (via poweroff within > the guest): > > pflog0: promiscuous mode disabled > Waiting (max 60 seconds) for system process `vnlru' to stop... done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining... 0 0 0 0 done > All buffers synced. > GEOM_ELI: Device vtbd0p2.eli destroyed. > GEOM_ELI: Detached vtbd0p2.eli on last close. > Uptime: 7h26m6s > GEOM_ELI: Device vtbd0p3.eli destroyed. > GEOM_ELI: Detached vtbd0p3.eli on last close. > > Khelp module "ertt" can't unload until its refcount drops from 18 to 0. > > acpi0: Powering system off > > Not sure it's indicative of a problem > -- > I see the ertt message also when I shutdown my FreeBSD-15. I don't think that it's indicative of a problem and I've never seen a shutdown failure. -- Gary Jennejohn
Re: AMD Zen 4 (Ryzen 7000) resource allocation issues (on 14.0)
On Sat, 14 Oct 2023 16:29:41 +0200 Daniel Engberg wrote: > On 2023-10-14T16:12:04.000+02:00, Gary Jennejohn wrote: > [SNIP] > > Considering that none of the current FreeBSD versions work I suspect > > > > that you'll have to flash the previous BIOS version to get a working > > > > system again. > > > > -- > > > > Gary Jennejohn > > Hi, > > That's true although I'm going to guess it's going to be an ongoing > issue as at least one user with an ASRock board also has similar > issues (see PR). Looking into if downgrade is possible too. > I wonder whether Linux would work with your BIOS. If it does that may give developers some pointers to what needs to be changed in FreeBSD. No need to install Linux, I think. Just boot it from a memstick and maybe you can get the boot trace. -- Gary Jennejohn
Re: AMD Zen 4 (Ryzen 7000) resource allocation issues (on 14.0)
On Sat, 14 Oct 2023 15:05:22 +0200 Daniel Engberg wrote: > On 2023-10-14T13:07:11.000+02:00, Daniel Engberg > wrote: > > > Hi, > > > > After updating BIOS on my Asus motherboard (ProArt X670E-CREATOR > > WIFI) the kernel fails to allocate resources for a bunch of devices > > including USB and built-in SATA. This behaviour is also observed on > > at least ASRock boards too so it doesn't seem to be a specific issue > > to one manufacturer or model. If anyone has any ideas how to fix > > this I'd be grateful. > > > > I've tried turning off and on "Fast boot" in BIOS without any > > success, enabing SR-IOV makes the kernel hang during boot. > > > > dmesg with older bios (working): > > > > > >https://forums.freebsd.org/threads/sata-drives-show-in-bios-but-wont-show-in-dev.89656/page-2#post-620854 > > > > dmesg with new bios (not working): > > > > https://reviews.freebsd.org/P612 > > > > Related PR: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272507 > > > > If you need to more information or testing just ask and please CC me > > when replying. > > > > Best regards, > > > > Daniel > > In addition to the above, 13.2-RELEASE fails in the same way, also > 15.0-CURRENT (20231005-8818f0f1124e-265728). In addition to that, USB > also fails to init so USB devices won't work once the kernel boots. > Considering that none of the current FreeBSD versions work I suspect that you'll have to flash the previous BIOS version to get a working system again. -- Gary Jennejohn
'teken_utf8_bytes_to_codepoint' [-Wunused-function]
I just updated my current sources and did a buildworld and buildkernel. This warning was spit out, although it didn't result in buildkernel failing: In file included from /usr/src/sys/teken/teken.c:70: /usr/src/sys/teken/teken_wcwidth.h:128:1: warning: unused function 'teken_utf8_bytes_to_codepoint' [-Wunused-function] teken_utf8_bytes_to_codepoint(uint8_t bytes[4], int nbytes) ^ 1 warning generated. Just FYI. -- Gary Jennejohn
Re: crashinfo fails on 'version'
On Mon, 2 Oct 2023 20:15:30 + (UTC) "Bjoern A. Zeeb" wrote: > On Fri, 29 Sep 2023, Bjoern A. Zeeb wrote: > > > On Fri, 29 Sep 2023, Warner Losh wrote: > > > >> On Fri, Sep 29, 2023, 3:56 PM Bjoern A. Zeeb > >> > >> wrote: > >> > >>> Hi, > >>> > >>> saveinfo wrote a good core, but crashinfo bails on it: > >>> > >>> 'version' has unknown type; cast it to its declared type > >>> 'version' has unknown type; cast it to its declared type > >>> Unable to find matching kernel for /var/crash/vmcore.1 > >>> > >>> I've got gdb-13.1_3 installed. > >>> > >>> Anyone any insights? > >>> > >> > >> What does kgdb say? Iirc crashinfo uses lldb for this. > > > > I would hope the latter was true but: > > > > % grep -i lldb /usr/sbin/crashinfo % > > > > at least on the version here still very much gdb. > > > > > > I have started to trace and manually called the same commands crashinfo > > seems to run (without batch). > > > > It seems the real problem might be that it cannot find debug symbols > > inside the VM. > > > > I am wondering if there was a way to check for that to make the error > > messages less cryptic (e.g., maintenance print symbols empty if it does > > what I would think; I'll hopefully see soon). > > > > Also turns out /etc/src.conf on the provided host had WITHOUT_DEBUG_FILES= > > and even building and installing with -DWITH_DEBUG_FILES does not seem > > to override that (probably by design), which likely was the reason for > > no symbols in first place. > > > > > > I'll hopefully have more answers in 20 minutes. Remote debugging wifi > > less fun than I hoped. > > Well things in src.conf commented out, also tried with > -DWITHOUT_SPLIT_KERNEL_DEBUG, ... I still get no debugging symbols > with a main amd64 GENERIC installed. Neither in /usr/lib/debug not > /boot/kernel/kernel. I am totally confused as to why currently. > > Build host is 14.0-ALPHA1 from mid August. > > Anyone any idea? > This is weird since GENERIC has: GENERIC:makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols Maybe you also need makeoptions DEBUG+=-O0 to get all the debug symbols? -- Gary Jennejohn
Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel
On Sun, 03 Sep 2023 15:17:36 +0200 "Herbert J. Skuhra" wrote: [SNIP] > Probably best to file a PR: https://bugs.freebsd.org/bugzilla/ > Bugzilla 273543 -- Gary Jennejohn
Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel
On Sat, 02 Sep 2023 15:36:36 +0200 "Herbert J. Skuhra" wrote: > On Fri, 01 Sep 2023 18:05:34 +0200, Gary Jennejohn wrote: > > > > On Fri, 1 Sep 2023 14:43:21 + > > Gary Jennejohn wrote: > > > > > A git-bisect is probably required. > > > > > > > I did a bisect and the result was commit > > 9a7add6d01f3c5f7eba811e794cf860d2bce131d. > > > > However, that can't be correct because this commit was made on > > Mon Jul 17 19:29:20 2023 and my FBSD-14 kernel from August 13th > > boots successfully :( > > Commit date is August 19th, 2023(!): > > commit 9a7add6d01f3c5f7eba811e794cf860d2bce131d > Author: Colin Percival > AuthorDate: Mon Jul 17 19:29:20 2023 -0700 > Commit: Colin Percival > CommitDate: Sat Aug 19 22:04:56 2023 -0700 > > > Reverting this commit seems to resolve the issue for me: > > FreeBSD 15.0-CURRENT amd64 150 #0 main-n265137-2ad756a6bbb3 > > $ git status > On branch main > Your branch is up to date with 'freebsd/main'. > > You are currently reverting commit 9a7add6d01f3. > (all conflicts fixed: run "git revert --continue") > (use "git revert --skip" to skip this patch) > (use "git revert --abort" to cancel the revert operation) > > Changes to be committed: > (use "git restore --staged ..." to unstage) > modified: sys/kern/init_main.c > > # dmesg |egrep "(amdsmn|amdtemp)" > amdsmn0: on hostb0 > amdtemp0: on hostb0 > > $ sysctl kern.conftxt |grep amdt > device amdtemp > Really? I did a git log and July 17 is what pops out for this commit. Ah, I see that git log doesn't show the commit date. So I guess that the git bisect really did find the commit which caused all our problems. If reverting it fixes things then this requires some action from Colin Percival. This would also explain why my FBSD-14 kernel from August 13 was OK. -- Gary Jennejohn
Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel
On Fri, 1 Sep 2023 16:00:03 -0600 Warner Losh wrote: > I think that the problem is that admsmn has probed, but not attached (or > failed to attach for some reason), so we find the device, but it's not > initialized yet, so when we call amdsmn_read, it tries to lock a mutex > that's not yet initialized. > > Not sure why this is happening, or why loading it as modules fixes it... > > But since I don't have the hardware, I can't help more. Sorry. > Might it be worth adding an entry to /usr/src/UPDATING for users with older Zen versions like mine (Zen 1 and Zen 2), recommending kldload'ing of amdsmn and amdtemp? -- Gary Jennejohn
Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel
On Fri, 01 Sep 2023 17:14:02 +0200 "Herbert J. Skuhra" wrote: > On Fri, 01 Sep 2023 16:04:41 +0200, Gary Jennejohn wrote: > > > > On Fri, 01 Sep 2023 14:15:20 +0200 > > "Herbert J. Skuhra" wrote: > > > > > On Fri, 01 Sep 2023 13:03:14 +0200, Gary Jennejohn wrote: > > > > > > > > I have a laptop wioth a AMD Ryzen 5 and a tower with a AMD Ryzen 7 > > > > 3700X. > > > > > > > > These are respectively Zen 1 and Zen 2 CPUs. > > > > > > > > I built a kernel on both computers using the FreeBSD-15 source tree. > > > > > > > > If I include the amdtemp device in my kernel file BOTH computers end up > > > > with a kernel panic while trying to attach the amdtemp device. > > > > > > > > If I remove amdtemp both computers boot without any issues. > > > > > > > > I suspect that this commit is the cause: > > > > > > > > commit 323a94afb6236bcec3a07721566aec6f2ea2b209 > > > > Author: Akio Morita > > > > Date: Tue Aug 1 22:32:12 2023 +0200 > > > > > > > > amdsmn(4), amdtemp(4): add support for Zen 4 > > > > > > > > Zen 4 support, tested on Ryzen 9 7900 > > > > > > > > Reviewed by:imp (previous version), mhorne > > > > Approved by:mhorne > > > > Obtained from: > > > > http://jyurai.ddo.jp/~amorita/diary/?date=20221102#p01 > > > > Differential Revision: https://reviews.freebsd.org/D41049 > > > > > > Thanks for sharing your findings. > > > > > > Now I probably know why my old kernel from stable/13 no longer booted > > > after updating to stable/14. I've create a new kernel config and > > > forgot to add "device amdtemp" & "device amdsmn" and forgot about the > > > issue. After removing only "device amdtemp" from my old kernel config > > > it boots again. > > > > > > Unfortunately reverting this commit (git revert -n 323a94afb623) > > > doesn't resolve this issue. Old kernel does not boot if "device > > > amdtemp" is enabled. Probably wrong commit or I am doing somethig > > > wrong!? > > > > > > > Strange. My FreeBSD-14 kernel boots with device amdtemp (which > > automatically > > results in amdsmn being included). It's FreeBSD-15 which fails for me. > > 1. 'kload amdtemp' works: >121 0x81e7c000 3160 amdtemp.ko >131 0x81e8 2138 amdsmn.ko > >amdsmn0: on hostb0 >amdtemp0: on hostb0 > > 2. GENERIC boots fine. The following kernel does not: > >include GENERIC > >ident TEST >device amdtemp > > 3. Unfortunately this is a remote server without a serial console. I > don't get a crashdump and I can't find anything in /var/log/messages. > > 4. I have no good revision for stable/14 and main. On main I always > use GENERIC-NODEBUG. :-( > Thanks, Herbert! kldload'ing amdsmn and amdtemp really does work! Now I can run FBSD-15 :) -- Gary Jennejohn
Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel
On Fri, 1 Sep 2023 14:43:21 + Gary Jennejohn wrote: > A git-bisect is probably required. > I did a bisect and the result was commit 9a7add6d01f3c5f7eba811e794cf860d2bce131d. However, that can't be correct because this commit was made on Mon Jul 17 19:29:20 2023 and my FBSD-14 kernel from August 13th boots successfully :( However, "Herbert J. Skuhra" says that kldload'ing amdtemp works. So I'll give that a try. -- Gary Jennejohn
Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel
On Fri, 1 Sep 2023 14:23:36 + Gary Jennejohn wrote: > Now that I look at the date of my FreeBSD-14 kernel I see that it's from > August 13, so this commit is perhaps not the cause of my FreeBSD-15 > kernel panicking at boot time, since FBSD-14 boots OK. > > Nonetheless, amdtemp or maybe amdsmn seems to be related. > Since my FBSD-14 kernel is from August 13 and FBSD-15 appeared on August 24 there were 10 to 11 days of commits in between. That makes it much more difficult to pinpoint the cause. A git-bisect is probably required. -- Gary Jennejohn
Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel
On Fri, 1 Sep 2023 11:03:14 + Gary Jennejohn wrote: > I have a laptop wioth a AMD Ryzen 5 and a tower with a AMD Ryzen 7 3700X. > > These are respectively Zen 1 and Zen 2 CPUs. > > I built a kernel on both computers using the FreeBSD-15 source tree. > > If I include the amdtemp device in my kernel file BOTH computers end up > with a kernel panic while trying to attach the amdtemp device. > > If I remove amdtemp both computers boot without any issues. > > I suspect that this commit is the cause: > > commit 323a94afb6236bcec3a07721566aec6f2ea2b209 > Author: Akio Morita > Date: Tue Aug 1 22:32:12 2023 +0200 > > amdsmn(4), amdtemp(4): add support for Zen 4 > > Zen 4 support, tested on Ryzen 9 7900 > > Reviewed by:imp (previous version), mhorne > Approved by:mhorne > Obtained from: http://jyurai.ddo.jp/~amorita/diary/?date=20221102#p01 > Differential Revision: https://reviews.freebsd.org/D41049 > Now that I look at the date of my FreeBSD-14 kernel I see that it's from August 13, so this commit is perhaps not the cause of my FreeBSD-15 kernel panicking at boot time, since FBSD-14 boots OK. Nonetheless, amdtemp or maybe amdsmn seems to be related. -- Gary Jennejohn
Re: FreeBSD-15 kernel panic when the amdtemp device is in the kernel
On Fri, 01 Sep 2023 14:15:20 +0200 "Herbert J. Skuhra" wrote: > On Fri, 01 Sep 2023 13:03:14 +0200, Gary Jennejohn wrote: > > > > I have a laptop wioth a AMD Ryzen 5 and a tower with a AMD Ryzen 7 3700X. > > > > These are respectively Zen 1 and Zen 2 CPUs. > > > > I built a kernel on both computers using the FreeBSD-15 source tree. > > > > If I include the amdtemp device in my kernel file BOTH computers end up > > with a kernel panic while trying to attach the amdtemp device. > > > > If I remove amdtemp both computers boot without any issues. > > > > I suspect that this commit is the cause: > > > > commit 323a94afb6236bcec3a07721566aec6f2ea2b209 > > Author: Akio Morita > > Date: Tue Aug 1 22:32:12 2023 +0200 > > > > amdsmn(4), amdtemp(4): add support for Zen 4 > > > > Zen 4 support, tested on Ryzen 9 7900 > > > > Reviewed by:imp (previous version), mhorne > > Approved by:mhorne > > Obtained from: http://jyurai.ddo.jp/~amorita/diary/?date=20221102#p01 > > Differential Revision: https://reviews.freebsd.org/D41049 > > Thanks for sharing your findings. > > Now I probably know why my old kernel from stable/13 no longer booted > after updating to stable/14. I've create a new kernel config and > forgot to add "device amdtemp" & "device amdsmn" and forgot about the > issue. After removing only "device amdtemp" from my old kernel config > it boots again. > > Unfortunately reverting this commit (git revert -n 323a94afb623) > doesn't resolve this issue. Old kernel does not boot if "device > amdtemp" is enabled. Probably wrong commit or I am doing somethig > wrong!? > Strange. My FreeBSD-14 kernel boots with device amdtemp (which automatically results in amdsmn being included). It's FreeBSD-15 which fails for me. -- Gary Jennejohn
FreeBSD-15 kernel panic when the amdtemp device is in the kernel
I have a laptop wioth a AMD Ryzen 5 and a tower with a AMD Ryzen 7 3700X. These are respectively Zen 1 and Zen 2 CPUs. I built a kernel on both computers using the FreeBSD-15 source tree. If I include the amdtemp device in my kernel file BOTH computers end up with a kernel panic while trying to attach the amdtemp device. If I remove amdtemp both computers boot without any issues. I suspect that this commit is the cause: commit 323a94afb6236bcec3a07721566aec6f2ea2b209 Author: Akio Morita Date: Tue Aug 1 22:32:12 2023 +0200 amdsmn(4), amdtemp(4): add support for Zen 4 Zen 4 support, tested on Ryzen 9 7900 Reviewed by:imp (previous version), mhorne Approved by:mhorne Obtained from: http://jyurai.ddo.jp/~amorita/diary/?date=20221102#p01 Differential Revision: https://reviews.freebsd.org/D41049 -- Gary Jennejohn
Re: ssh 9.4 fails to build
On Sat, 12 Aug 2023 08:04:29 +0200 (CEST) Ronald Klop wrote: > Hi, > > I get this error while building world. > NB: I'm building with llvm15 from a pkg. But I don't think that should make a > difference. > ld.lld: error: undefined symbol: Fssh_lib_contains_symbol > >>> referenced by ssh-pkcs11.c:1538 > >>> (/usr/src/crypto/openssh/ssh-pkcs11.c:1538) > >>> ssh-pkcs11.o:(Fssh_pkcs11_add_provider) > > > git reset --hard fixes the build for me. > I just updated my current source tree and ran buildworld and ssh compiled without any errors. ./obj/usr/src/amd64.amd64/secure/usr.bin/ssh/ssh -V OpenSSH_9.4p1, OpenSSL 3.0.9 30 May 2023 But I'm using LLVM16. -- Gary Jennejohn
Re: problems on new -current install with pkg/ssl
On Sun, 9 Jul 2023 17:17:38 +0100 void wrote: > Hi, > > On a fresh 14-current install (main-n263444-653738e895ba) > I try to use pkg for anything and this error > happens: > > # pkg install doas > The package management tool is not yet installed on your system. > Do you want to fetch and install it now? [y/N]: y > Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:14:amd64/latest, > please wait... > Verifying signature with trusted certificate pkg.freebsd.org.2013102301... > done > Installing pkg-1.19.2... > Newer FreeBSD version for package pkg: > To ignore this error set IGNORE_OSVERSION=yes > - package: 1400092 > - running kernel: 1400090 > Ignore the mismatch and continue? [y/N]: y > Extracting pkg-1.19.2: 100% > ld-elf.so.1: Shared object "libssl.so.30" not found, required by "pkg" > > How can I fix? > > -- > pkg works fine for me, but I'm running uname -UK 1400093 1400093 Your kernel is too old and your world probably also. -- Gary Jennejohn
Re: buildworld broken due to INET6 not being set
On Tue, 4 Jul 2023 16:48:10 + Gary Jennejohn wrote: > buildworld breaks because I do not have INET6 defined: > > /usr/src/sbin/ping/main.c:76:7: error: variable 'ipv4' set but not used > [-Werror,-Wunused-but-set-variable] > bool ipv4 = false; > ^ > 1 error generated. > I bit the bullet and enabled INET6, so there won't be any more reports like this from me in the future. -- Gary Jennejohn
buildworld broken due to INET6 not being set
buildworld breaks because I do not have INET6 defined:
/usr/src/sbin/ping/main.c:76:7: error: variable 'ipv4' set but not used
[-Werror,-Wunused-but-set-variable]
bool ipv4 = false;
^
1 error generated.
ipv4 is set in various places but it's _used_ only bracketed in
#if defined(INET) && defined(INET6)...#endif!
Note that ipv6 will have the same error if INET6 is defined but INET is not
defined due to this chunk of code:
#if defined(INET) && defined(INET6)
if (inet_pton(AF_INET, argv[argc - 1], ) == 1) {
if (ipv6)
errx(1, "IPv6 requested but IPv4 target address "
"provided");
hints.ai_family = AF_INET;
}
else if (inet_pton(AF_INET6, argv[argc - 1], ) == 1) {
if (ipv4)
errx(1, "IPv4 requested but IPv6 target address "
"provided");
hints.ai_family = AF_INET6;
} else if (ipv6)
hints.ai_family = AF_INET6;
else if (ipv4)
hints.ai_family = AF_INET;
else {
if (!feature_present("inet6"))
hints.ai_family = AF_INET;
else if (!feature_present("inet"))
hints.ai_family = AF_INET6;
else {
struct addrinfo *res;
memset(, 0, sizeof(hints));
hints.ai_socktype = SOCK_RAW;
hints.ai_family = AF_UNSPEC;
getaddrinfo(argv[argc - 1], NULL, , );
if (res != NULL) {
hints.ai_family = res[0].ai_family;
freeaddrinfo(res);
}
}
}
#elif defined(INET)
hints.ai_family = AF_INET; <== ipv4 set but not used
#elif defined(INET6)
hints.ai_family = AF_INET6; <== ipv6 set but not used
#endif
--
Gary Jennejohn
Re: kernel: sonewconn: pcb 0xfffff8002b255a00 (local:/var/run/devd.seqpacket.pipe): Listen queue overflow: 1 already in queue awaiting acceptance (60 occurrences), ?
On Tue, 20 Jun 2023 12:04:13 +0200 Alexander Leidinger wrote: > Quoting Gary Jennejohn (from Tue, 20 Jun 2023 07:41:08 +): > > > On Tue, 20 Jun 2023 06:25:05 +0100 > > Graham Perrin wrote: > > > >> Please, what's the meaning of the sonewconn lines? > >> > > > > sonewconn is described in socket(9). Below a copy/paste of the description > > from socket(9): > > > > Protocol implementations can use sonewconn() to create a socket and > > attach protocol state to that socket. This can be used to create new > > sockets available for soaccept() on a listen socket. The > > returned socket > > has a reference count of zero. > > > > Apparently there was already a listen socket in the queue which had not been > > consumed by soaccept() when a new sonewconn() call was made. > > > > Anyway, that's my understanding. Might be wrong. > > In other words the software listening on it didn't process the request > fast enough and a backlog piled up (e.g apache ListenBacklog or nginx > "listen X backlog=y" and "sysctl kern.ipx.somaxconn=X" for FreeBSD > itself). You may need faster hardware, more processes/threads to > handle the traffic, or configure your software to do less to produce > the same result (e.g. no real-time DNS resolution in the logging of a > webserver or increasing the amount of allowed items in the backlog). > If you can change the software, there's also the possibility to switch > from blocking sockets to non-blocking sockets (to not have the > select/accept loop block / run into contention) or kqueue. > On my FreeBSD14 system these things are all under kern.ipc. maxconn seems to be an alias for soacceptqueue, which is set to 128 on my machine. However, the software he's using may have set backlog to 1. Hard to say based on the trace he provided. -- Gary Jennejohn
Re: kernel: sonewconn: pcb 0xfffff8002b255a00 (local:/var/run/devd.seqpacket.pipe): Listen queue overflow: 1 already in queue awaiting acceptance (60 occurrences), ?
On Tue, 20 Jun 2023 06:25:05 +0100 Graham Perrin wrote: > Please, what's the meaning of the sonewconn lines? > sonewconn is described in socket(9). Below a copy/paste of the description from socket(9): Protocol implementations can use sonewconn() to create a socket and attach protocol state to that socket. This can be used to create new sockets available for soaccept() on a listen socket. The returned socket has a reference count of zero. Apparently there was already a listen socket in the queue which had not been consumed by soaccept() when a new sonewconn() call was made. Anyway, that's my understanding. Might be wrong. > % tail -f -n 0 /var/log/messages > Jun 20 04:08:41 mowa219-gjp4-8570p-freebsd su[4159]: grahamperrin to > root on /dev/pts/6 > Jun 20 04:12:20 mowa219-gjp4-8570p-freebsd apps.plugin[3178]: Cannot > fetch process 4501 command line (command 'sysctl') > Jun 20 04:30:25 mowa219-gjp4-8570p-freebsd kernel: lock order reversal: > Jun 20 04:30:25 mowa219-gjp4-8570p-freebsd kernel: 1st > 0xfe0103db30e0 filedesc structure (filedesc structure, sx) @ > /usr/src/sys/kern/kern_descrip.c:1397 > Jun 20 04:30:25 mowa219-gjp4-8570p-freebsd kernel: 2nd > 0xf80001df8930 devfs (devfs, lockmgr) @ > /usr/src/sys/kern/vfs_subr.c:6244 > Jun 20 04:30:25 mowa219-gjp4-8570p-freebsd kernel: lock order filedesc > structure -> devfs attempted at: > Jun 20 04:30:25 mowa219-gjp4-8570p-freebsd kernel: #0 0x80bc4573 > at witness_checkorder+0xbb3 > Jun 20 04:30:25 mowa219-gjp4-8570p-freebsd kernel: #1 0x80b21265 > at lockmgr_xlock+0x55 > Jun 20 04:30:25 mowa219-gjp4-8570p-freebsd kernel: #2 0x80c5e4b4 > at _vn_lock+0x54 > Jun 20 04:30:25 mowa219-gjp4-8570p-freebsd kernel: #3 0x80afd13b > at knlist_remove_kq+0x8b > Jun 20 04:30:25 mowa219-gjp4-8570p-freebsd kernel: #4 0x80c517d4 > at filt_vfsdetach+0x24 > Jun 20 04:30:25 mowa219-gjp4-8570p-freebsd kernel: #5 0x80afdad0 > at knote_fdclose+0x180 > Jun 20 04:30:25 mowa219-gjp4-8570p-freebsd kernel: #6 0x80af4f2c > at closefp_impl+0x9c > Jun 20 04:30:25 mowa219-gjp4-8570p-freebsd kernel: #7 0x8104d8e0 > at amd64_syscall+0x140 > Jun 20 04:30:25 mowa219-gjp4-8570p-freebsd kernel: #8 0x81020b3b > at fast_syscall_common+0xf8 > Jun 20 04:34:26 mowa219-gjp4-8570p-freebsd apps.plugin[3178]: heartbeat > clock: woke up 1346787 microseconds later than expected (can be due to > system load or the CLOCK_REALTIME set to the future). > Jun 20 04:35:38 mowa219-gjp4-8570p-freebsd apps.plugin[3178]: Cannot > fetch process 6471 command line (command 'sysctl') > Jun 20 04:55:30 mowa219-gjp4-8570p-freebsd apps.plugin[3178]: Cannot > fetch process 7697 command line (command 'sysctl') > Jun 20 05:07:16 mowa219-gjp4-8570p-freebsd apps.plugin[3178]: Cannot > fetch process 8416 command line (command 'sysctl') > Jun 20 05:17:42 mowa219-gjp4-8570p-freebsd kernel: sonewconn: pcb > 0xf8002b255a00 (local:/var/run/devd.seqpacket.pipe): Listen queue > overflow: 1 already in queue awaiting acceptance (1 occurrences), euid > 0, rgid > 0, jail 0 > Jun 20 05:18:42 mowa219-gjp4-8570p-freebsd kernel: sonewconn: pcb > 0xf8002b255a00 (local:/var/run/devd.seqpacket.pipe): Listen queue > overflow: 1 already in queue awaiting acceptance (60 occurrences), euid > 0, rgi > d 0, jail 0 > Jun 20 05:18:56 mowa219-gjp4-8570p-freebsd apps.plugin[3178]: Cannot > fetch process 9359 command line (command 'git') > Jun 20 05:19:42 mowa219-gjp4-8570p-freebsd kernel: sonewconn: pcb > 0xf8002b255a00 (local:/var/run/devd.seqpacket.pipe): Listen queue > overflow: 1 already in queue awaiting acceptance (60 occurrences), euid > 0, rgi > d 0, jail 0 > Jun 20 05:20:03 mowa219-gjp4-8570p-freebsd apps.plugin[3178]: Cannot > fetch process 9602 command line (command 'cat') > Jun 20 05:20:43 mowa219-gjp4-8570p-freebsd kernel: sonewconn: pcb > 0xf8002b255a00 (local:/var/run/devd.seqpacket.pipe): Listen queue > overflow: 1 already in queue awaiting acceptance (60 occurrences), euid > 0, rgi > d 0, jail 0 > ^C > % sudo sysctl kern.sched.pick_short=1 > grahamperrin's password: > kern.sched.pick_short: 0 -> 1 > % sudo sysctl kern.sched.preempt_thresh=224 > kern.sched.preempt_thresh: 48 -> 224 > % uptime > 6:23a.m. up 2:24, 7 users, load averages: 0.78, 1.24, 1.34 > % uname -aKU > FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #7 > main-n263630-ab3e6234ab6e-dirty: Sun Jun 18 14:56:48 BST 2023 > grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GEN > ERIC amd64 1400090 1400090 > % > > -- Gary Jennejohn
Re: ifconfig dumps core and gdb uses an undefined symbol
On Wed, 14 Jun 2023 11:05:31 +0100 Alexander Chernikov wrote: > > On 14 Jun 2023, at 10:53, Gary Jennejohn wrote: > > > > On Wed, 14 Jun 2023 09:01:35 + > > Gary Jennejohn mailto:ga...@gmx.de>> wrote: > > > >> On Wed, 14 Jun 2023 09:09:04 +0100 > >> Alexander Chernikov wrote: > >> > >>>> On 14 Jun 2023, at 08:59, Gary Jennejohn wrote: > >>> Hi Gary, > >>>> > >>>> So, now I have a new problem with current. > >>>> > >>>> I just now updated my current sources and ran buildworld and buildkernel, > >>>> since Gleb fixed the WITHOUT_PF problem. > >>>> > >>>> After installing the new world and kernel I see that ifconfig is dumping > >>>> a core, apparently when it tries to show lo0, since re0 is correctly > >>>> shown: > >>>> > >>>> ifconfig > >>>> re0: flags=8843 metric 0 mtu > >>>> 4088 > >>>> options=82098 > >>>> ether redacted > >>>> inet 192.168.178.XXX netmask 0xff00 broadcast 192.168.178.255 > >>>> Segmentation fault (core dumped) > >>> Could you please try to narrow down the crashing command? e.g. > >>> Ifconfig lo0 > >>> Ifconfig lo0 net > >>> Ifconfig lo0 inet6 > >>> Could you try to rebuild ifconfig w/o netlink (e.g. set > >>> WITHOUT_NETLINK=yes in the make.conf & make -C sbin/ifconfig clean all > >>> install) and see if the new binary works? > >>> > >> > >> I already have WITHOUT_NETLINK=yes in my /etc/src.conf. > >> > >> I didn't install ifconfig. I simply started it from the build directory. > >> > >> ifconfig lo0 shows the settings for lo0 and then dumps core. > >> > > > > After your most recent changes "ifconfig re0" and "ifconfg lo0" don't > > result in any errors. But "ifconfig" alone still results in a core > > dump, which per gdb is happening in the strlcpy() call at in_status_tunnel() > > in af_inet.c. > Indeed. > > diff --git a/sbin/ifconfig/ifconfig.c b/sbin/ifconfig/ifconfig.c > index d30d3e1909ae..6a80ad5763b2 100644 > --- a/sbin/ifconfig/ifconfig.c > +++ b/sbin/ifconfig/ifconfig.c > @@ -822,6 +822,7 @@ list_interfaces_ioctl(if_ctx *ctx) > continue; > if (!group_member(ifa->ifa_name, args->matchgroup, > args->nogroup)) > continue; > + ctx->ifname = cp; > /* > * Are we just listing the interfaces? > */ > > Does this one fix the crash? > > YES! -- Gary Jennejohn
Re: ifconfig dumps core and gdb uses an undefined symbol
On Wed, 14 Jun 2023 09:01:35 + Gary Jennejohn wrote: > On Wed, 14 Jun 2023 09:09:04 +0100 > Alexander Chernikov wrote: > > > > On 14 Jun 2023, at 08:59, Gary Jennejohn wrote: > > Hi Gary, > > > > > > So, now I have a new problem with current. > > > > > > I just now updated my current sources and ran buildworld and buildkernel, > > > since Gleb fixed the WITHOUT_PF problem. > > > > > > After installing the new world and kernel I see that ifconfig is dumping > > > a core, apparently when it tries to show lo0, since re0 is correctly > > > shown: > > > > > > ifconfig > > > re0: flags=8843 metric 0 mtu 4088 > > > options=82098 > > > ether redacted > > > inet 192.168.178.XXX netmask 0xff00 broadcast 192.168.178.255 > > > Segmentation fault (core dumped) > > Could you please try to narrow down the crashing command? e.g. > > Ifconfig lo0 > > Ifconfig lo0 net > > Ifconfig lo0 inet6 > > Could you try to rebuild ifconfig w/o netlink (e.g. set WITHOUT_NETLINK=yes > > in the make.conf & make -C sbin/ifconfig clean all install) and see if the > > new binary works? > > > > I already have WITHOUT_NETLINK=yes in my /etc/src.conf. > > I didn't install ifconfig. I simply started it from the build directory. > > ifconfig lo0 shows the settings for lo0 and then dumps core. > After your most recent changes "ifconfig re0" and "ifconfg lo0" don't result in any errors. But "ifconfig" alone still results in a core dump, which per gdb is happening in the strlcpy() call at in_status_tunnel() in af_inet.c. -- Gary Jennejohn
Re: ifconfig dumps core and gdb uses an undefined symbol
On Wed, 14 Jun 2023 11:14:13 +0200 Juraj Lutter wrote: > > On 14 Jun 2023, at 11:12, Juraj Lutter wrote: > > > > > > > >> On 14 Jun 2023, at 11:01, Gary Jennejohn wrote: > >> I compiled gbd under /usr/ports and it now works, although it's emitting > >> some weird errors. > >> > >> -O0 -g3 removes too much and gdb shows no useful information. > > > > Build it with: > > > > WITH_DEBUG=1 DEBUG_FLAGS="-O3 -g3" > > > > Silly me. > > Actually with: > > WITH_DEBUG=1 DEBUG_FLAGS="-O0 -g3" > Thanks, but doesn't work: #0 0x2efcf61186c8 in ?? () (gdb) bt #0 0x2efcf61186c8 in ?? () #1 0x2f051a2fe000 in ?? () #2 0x in ?? () (gdb) I've been a UNIX developer since 1984, so I have some experience using gdb. -- Gary Jennejohn
Re: ifconfig dumps core and gdb uses an undefined symbol
On Wed, 14 Jun 2023 09:09:04 +0100 Alexander Chernikov wrote: > > On 14 Jun 2023, at 08:59, Gary Jennejohn wrote: > Hi Gary, > > > > So, now I have a new problem with current. > > > > I just now updated my current sources and ran buildworld and buildkernel, > > since Gleb fixed the WITHOUT_PF problem. > > > > After installing the new world and kernel I see that ifconfig is dumping > > a core, apparently when it tries to show lo0, since re0 is correctly > > shown: > > > > ifconfig > > re0: flags=8843 metric 0 mtu 4088 > > options=82098 > > ether redacted > > inet 192.168.178.XXX netmask 0xff00 broadcast 192.168.178.255 > > Segmentation fault (core dumped) > Could you please try to narrow down the crashing command? e.g. > Ifconfig lo0 > Ifconfig lo0 net > Ifconfig lo0 inet6 > Could you try to rebuild ifconfig w/o netlink (e.g. set WITHOUT_NETLINK=yes > in the make.conf & make -C sbin/ifconfig clean all install) and see if the > new binary works? > I already have WITHOUT_NETLINK=yes in my /etc/src.conf. I didn't install ifconfig. I simply started it from the build directory. ifconfig lo0 shows the settings for lo0 and then dumps core. > > > > Unfortunately, I see this error message when I try to look at the core > > file with gdb: > > > > gdb /sbin/ifconfig ifconfig.core > > ld-elf.so.1: Undefined symbol "rl_eof_found" referenced from COPY > > relocation in /usr/local/bin/gdb > Not a specialist here, but if you could build the binary with debug > (make DEBUG_FLAGS=-O0 -g3 sbin/ifconfig clean all install) & share the > binary & core with me, I could take a look on what?s happening. > > I compiled gbd under /usr/ports and it now works, although it's emitting some weird errors. -O0 -g3 removes too much and gdb shows no useful information. With just -g3 I get this output from gdb after running the newly compiled ifconfig: Program terminated with signal SIGSEGV, Segmentation fault warning: Section `.reg-xstate/100294' in core file too small. #0 lagg_status (ctx=0x2f051660ba00) at /usr/src/sbin/ifconfig/iflagg.c:223 223 const int verbose = ctx->args->verbose; (gdb) bt #0 lagg_status (ctx=0x2f051660ba00) at /usr/src/sbin/ifconfig/iflagg.c:223 #1 0x2efcf610ea55 in af_other_status (ctx=0x2f051660ba00) at /usr/src/sbin/ifconfig/ifconfig.c:964 #2 status (args=0x2f051660ba70, ifa=0x2f051a2f2000, sdl=) at /usr/src/sbin/ifconfig/ifconfig.c:1788 #3 list_interfaces_ioctl (args=0x2f051660ba70) at /usr/src/sbin/ifconfig/ifconfig.c:845 #4 list_interfaces (args=0x2f051660ba70) at /usr/src/sbin/ifconfig/ifconfig.c:428 #5 main (ac=, av=) at /usr/src/sbin/ifconfig/ifconfig.c:724 (gdb) I looked at ctx: (gdb) p ctx $1 = (if_ctx *) 0x2f051660ba00 (gdb) p/x *0x2f051660ba00 $2 = 0x0 <== (gdb) So, looks like the problem is in iflagg and ctx is NULL. -- Gary Jennejohn
ifconfig dumps core and gdb uses an undefined symbol
So, now I have a new problem with current. I just now updated my current sources and ran buildworld and buildkernel, since Gleb fixed the WITHOUT_PF problem. After installing the new world and kernel I see that ifconfig is dumping a core, apparently when it tries to show lo0, since re0 is correctly shown: ifconfig re0: flags=8843 metric 0 mtu 4088 options=82098 ether redacted inet 192.168.178.XXX netmask 0xff00 broadcast 192.168.178.255 Segmentation fault (core dumped) Unfortunately, I see this error message when I try to look at the core file with gdb: gdb /sbin/ifconfig ifconfig.core ld-elf.so.1: Undefined symbol "rl_eof_found" referenced from COPY relocation in /usr/local/bin/gdb pkg claims that my packages are all up to date. Not exactly a fatal error, but still rather surprising. -- Gary Jennejohn
addition of pflog_if_print to the tcpdump code can break buildworld
The addition of pflog_if_print to the tcpdump code breaks buildworld if WITHOUT_PF= is set in /etc/src.conf. I do not use PF and have WITHOUT_PF= set in /etc/src.conf. If I comment out WITHOUT_PF= buildworld succeeds. But I have no use for PF and don't want to build it. Here's the error code emitted when WITHOUT_PF= is defined: ld: error: undefined symbol: pflog_if_print >>> referenced by print.c >>> print.o:(printers) >>> did you mean: nflog_if_print >>> defined in: print-nflog.o cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [tcpdump] Error code 1 If all else fails the WITHOUT_PF option should be removed, if a fix in tcpdump isn't possible. -- Gary Jennejohn
Re: Error building kernel in current
On Fri, 02 Jun 2023 19:57:40 +0100 "Alexander Chernikov" wrote: > On Fri, 2 Jun 2023, at 4:30 PM, Gary Jennejohn wrote: > > On Fri, 2 Jun 2023 09:59:40 + > > Gary Jennejohn wrote: > > > > > On Fri, 2 Jun 2023 09:56:44 + > > > Gary Jennejohn wrote: > > > > > > > Error building kernel in current: > > > > > > > > -- > > > > >>> stage 3.1: building everything > > > > -- > > > > /usr/src/sys/netlink/route/iface.c:1315:22: error: use of undeclared > > > > identifier 'if_flags' > > > > if (error == 0 && !(if_flags & IFF_UP) && (if_getflags(ifp) & > > > > IFF_UP)) > > > > ^ > > > > 1 error generated. > > > > --- iface.o --- > > > > *** [iface.o] Error code 1 > Sorry for the breakage, I?ll fix it in a couple of hours. > > > > > > > > My source tree was updated just a few minutes ago and I didn't see any > > > > recent changes to iface.c. > > > > > > > > I have WITHOUT_NETLINK_SUPPORT= in my src.conf. > > > > > > > > > > Ah, my error. The failure occurs while building the kernel, so I fixed > > > Subject accordingly. > > > > > > > OK, this is another INET6 error. I don't have INET6 enabled. > > > > At line 1280 we have: > > #ifdef INET6 > > int if_flags = if_getflags(ifp); > > #endif > > > > and if_flags is used at line 1315 without checking whether INET6 is > > defined. > > > > if_flags seems to be totally redundant, since the code at line 1315 will > > invoke if_getflags(ifp) if !(if_flags & IFF_UP) is true. > > > I wish it was true. The case here is that interface flags can change > after adding the address, as many interface drivers silently bring the > interface up upon the first address addition. Please see > https://cgit.freebsd.org/src/commit/sys/netinet6?id=a77facd27368f618520d25391cfce11149879a41 > description for a more detailed explanation. I suspected that may have been the reason, but I wasn't sure. Thanks for the link. -- Gary Jennejohn
Re: Error building kernel in current
On Fri, 2 Jun 2023 09:59:40 + Gary Jennejohn wrote: > On Fri, 2 Jun 2023 09:56:44 + > Gary Jennejohn wrote: > > > Error building kernel in current: > > > > -- > > >>> stage 3.1: building everything > > -- > > /usr/src/sys/netlink/route/iface.c:1315:22: error: use of undeclared > > identifier 'if_flags' > > if (error == 0 && !(if_flags & IFF_UP) && (if_getflags(ifp) & > > IFF_UP)) > > ^ > > 1 error generated. > > --- iface.o --- > > *** [iface.o] Error code 1 > > > > My source tree was updated just a few minutes ago and I didn't see any > > recent changes to iface.c. > > > > I have WITHOUT_NETLINK_SUPPORT= in my src.conf. > > > > Ah, my error. The failure occurs while building the kernel, so I fixed > Subject accordingly. > OK, this is another INET6 error. I don't have INET6 enabled. At line 1280 we have: #ifdef INET6 int if_flags = if_getflags(ifp); #endif and if_flags is used at line 1315 without checking whether INET6 is defined. if_flags seems to be totally redundant, since the code at line 1315 will invoke if_getflags(ifp) if !(if_flags & IFF_UP) is true. -- Gary Jennejohn
Re: Error building kernel in current
On Fri, 2 Jun 2023 09:56:44 + Gary Jennejohn wrote: > Error building kernel in current: > > -- > >>> stage 3.1: building everything > -- > /usr/src/sys/netlink/route/iface.c:1315:22: error: use of undeclared > identifier 'if_flags' > if (error == 0 && !(if_flags & IFF_UP) && (if_getflags(ifp) & IFF_UP)) > ^ > 1 error generated. > --- iface.o --- > *** [iface.o] Error code 1 > > My source tree was updated just a few minutes ago and I didn't see any > recent changes to iface.c. > > I have WITHOUT_NETLINK_SUPPORT= in my src.conf. > Ah, my error. The failure occurs while building the kernel, so I fixed Subject accordingly. -- Gary Jennejohn
Error building world in current
Error building world in current: -- >>> stage 3.1: building everything -- /usr/src/sys/netlink/route/iface.c:1315:22: error: use of undeclared identifier 'if_flags' if (error == 0 && !(if_flags & IFF_UP) && (if_getflags(ifp) & IFF_UP)) ^ 1 error generated. --- iface.o --- *** [iface.o] Error code 1 My source tree was updated just a few minutes ago and I didn't see any recent changes to iface.c. I have WITHOUT_NETLINK_SUPPORT= in my src.conf. -- Gary Jennejohn
Re: WITH_BEARSSL: -8112 bytes available
On Wed, 31 May 2023 14:41:23 -0600 Warner Losh wrote: > On Wed, May 31, 2023 at 1:30?PM Gary Jennejohn wrote: > > > On Wed, 31 May 2023 12:15:12 -0600 > > Warner Losh wrote: > > > > [SNIP irrelevant text] > > > > > And no, I really do not want to support 'loadable modules'. BIOS booting > > is > > > on the way out, and people > > > that want to do complex stuff in the boot loader will simply have to do > > > that in UEFI or maybe kboot/LinuxBoot. > > > > So, what exactly does "BIOS booting is on the way out" mean? I have four > > computers which use BIOS booting. Three are too old to support UEFI and > > the other one I simply set to BIOS booting out of habit. > > > > New computers aren't supporting it. Its days are numbered. It's longevity is > much shorter than UEFI's. These are all indisputable. I'm not planning on > dropping it in 15, but the number of people that are using it is a declining > group over time. Time spent making EFI more effective will affect more > people. That's what I mean. So I don't want to sink a ton of time into it. > OK, that makes sense. If it disappears after 15 I guess I'll have to maintain it myself. Should be doable. -- Gary Jennejohn
Re: WITH_BEARSSL: -8112 bytes available
On Wed, 31 May 2023 12:15:12 -0600 Warner Losh wrote: [SNIP irrelevant text] > And no, I really do not want to support 'loadable modules'. BIOS booting is > on the way out, and people > that want to do complex stuff in the boot loader will simply have to do > that in UEFI or maybe kboot/LinuxBoot. So, what exactly does "BIOS booting is on the way out" mean? I have four computers which use BIOS booting. Three are too old to support UEFI and the other one I simply set to BIOS booting out of habit. The only computer I have which uses UEFI is a laptop which was already set up to use UEFI and I was too lazy to change it. > There's low RoI on adding this complexity, imho. We'd be better off, imho, > making things like the graphics > console optional since the fonts and code for that free up about 30k in > stupid experiments that I've done > (it's hard since vidconsole has a lot of calls into the graphics system > that aren't optional and easy to disable, > so I've had to do hack and slash to produce a super ugly result that is > only suggestive of the final savings): > -rw-r--r-- 1 imp imp 352256 May 31 12:04 loader_simp > I don't know if I slashed too much, or not enough since the code is rather > hard to separate out, so if you > really wanted to go down this path, it would take a lot of work and patient > understanding to make it so with > the low end of savings 20k and the high end on the order of maybe 40k. > > There's likely other ways to conserve space. We've not had space issues > with loader, et al, in the past, > so it's not well setup for subsetting. Though the different filesystem > support might also net you a fair amount: > LOADER_NET_SUPPORT?=yes > LOADER_NFS_SUPPORT?=yes > LOADER_TFTP_SUPPORT?= yes > LOADER_CD9660_SUPPORT?= yes > LOADER_EXT2FS_SUPPORT?= yes > LOADER_MSDOS_SUPPORT?= yes > LOADER_UFS_SUPPORT?=yes > LOADER_GZIP_SUPPORT?= yes > LOADER_BZIP2_SUPPORT?= yes > as would compiling w/o ZFS, which uses its own method (eg > WITHOUT_LOADER_ZFS). Tuning the loader > at this level does start to get into the weeds a bit, but can offer ~40k > savings turning off all but NET and UFS: > -rw-r--r-- 1 imp imp 344064 May 31 12:11 loader_simp > you get even about ~100k when you disable ZFS support with > -DWITHOUT_LOADER_ZFS: > -rw-r--r-- 1 imp imp 241664 May 31 12:12 loader_simp > (both of these are with the graphics console enabled without the silly > hacks to see how much that takes up). > Without the extras and ZFS, you might have bearssl and lua together even... > > Hope this helps. > This is interesting information. -- Gary Jennejohn
Re: PinePhone Pro Boots On CURRENT
On Wed, 31 May 2023 15:48:44 +0200 Mario Marietto wrote: > ---> Android remains the OS for the phone. > > I'm not sure but I see that he talks even about Linux as main os that can > be installed on the phone > No, Linux is installed in a chroot. So it's not replacing Android. See chroot(2) and chroot(8). The developer used Linux Deploy, an app from Google, which creates a chroot on a SD card and copies Linux to it. Since Android only supports FAT32 that means that the Linux distribution has to be smaller than 4GiB (about 4.295 billion bytes). Would be nice if there were an app like that for FreeBSD. > ---> FreeBSD does not have the required proprietary driver blobs which are > used by Android and I greatly doubt > that FreeBSD running in a KVM will have access to all (or any) of these > hardware elements. > > This is true. But AFAIK qemu can provide the missing software > components replacing > them with the virtual ones. > I can't imagine how that could work without the proprietary driver blobs. There are lots of drivers in the source tree, but based on the names it's difficult to tell just which hardware is supported. Not clear whether the modem is in the tree or a driver blob is required. -- Gary Jennejohn
Re: PinePhone Pro Boots On CURRENT
On Wed, 31 May 2023 12:00:43 +0200 Mario Marietto wrote: > ---> No, with this you cannot replace Android with Linux. This hack merely > provides a way to run a different OS in a KVM. > > ok,but what do I see as soon as I have flashed the boot.img to the phone > with odin ? can I virtualize freebsd,right ? What tool can I use in FreeBSD > to place phone calls and to send sms ? because this is what I want to do. A > freeBSD powered phone. > You'll see the hacked Android version which the developer has provided. Android remains the OS for the phone. FreeBSD does not have the requiired proprietary driver blobs which are used by Android and I greatly doubt that FreeBSD running in a KVM will have access to all (or any) of the these hardware elements. Click on raspiduino/a6lte-kvm in the upper left corner of the github link. This will take you to the source repository which has a long document about his hack. Read it. [SNIP] -- Gary Jennejohn
Re: PinePhone Pro Boots On CURRENT
On Tue, 30 May 2023 20:50:52 +0200 Mario Marietto wrote: > Check at this,also : https://github.com/raspiduino/a6lte-kvm/releases > This would definitely be the best approach, since the developer has already tested Linux in the KVM. Odin, which I've used to install custom ROMs from xda, is a Windows program. If you have Windows then this would be a way to do the installation. The developer also mentions using Heimdall under Linux. There's a Heimdall port for FreeBSD, so that might also be an option. > What I would like to know is if I can install Linux as the main OS,instead > of Android. Thanks. > No, with this you cannot replace Android with Linux. This hack merely provides a way to run a different OS in a KVM. [SNIP] -- Gary Jennejohn
Re: PinePhone Pro Boots On CURRENT
On Tue, 30 May 2023 15:02:38 +0200 Mario Marietto wrote: > That's interesting. As I have already said,I haven't bought the pinephone > pro,because it is expensive for me. So I'm working on a parallel project. > I've bought this phone,instead : > > https://www.hdblog.it/schede-tecniche/samsung-galaxy-a6_i3655/ > > That's cheaper. Between the specs I read that it has a mali gpu,too : > Mali-T830MP2 > > so,eventually,I can use the Lima and the PanFrost driver even for my > samsung galaxy A6 ? I've started planning to install FreeBSD on top of the > Android Kernel,using a specific patch,but now I'm thinking that maybe,I can > install FreeBSD there natively. Can someone tell me if it is doable,giving > a look at the specs of that phone model ? thanks. > Based on my experience with Samsung it probably won't be a simple task. Samsung tends to block the bootloader such that it's very difficult to install anything but Android. https://www.xda-developers.com/ has a fair amount of info on the A6. It could be worth your while to take a look at what's there. -- Gary Jennejohn
Re: builworld fails due to error in af_inet.c
On Mon, 22 May 2023 16:03:37 +0100 Alexander Chernikov wrote: > Sorry for the breakage (and thanks for markj@ for the prompt fix) > No big deal. It was easy to find the cause and temporarily fix it. > > On 22 May 2023, at 16:00, Gary Jennejohn wrote: > > > > I just ran buildworld using the latest current source. > > > > It dies due to this error in line 385 of /usr/src/sbin/ifconfig/af_inet.c: > > > > static void > > warn_nomask(ifflags) > > > > The compiler really doesn't like not seeing a type for ifflags and bails > > out as the result. > > > > Strangely enough, in_proc() a few lines later clearly has int ifflags in > > its list of variables. > > > > Setting ifflags to int in warn_nomask() fixes the build. > > > > Wasn't this compile tested before it was committed? > It was & it didn't yell on my setup. > That's interesting. Maybe I have some different settings. But the error message was the standard one about badly formed prototypes. -- Gary Jennejohn
Re: builworld fails due to error in af_inet.c
On Mon, 22 May 2023 15:00:00 + Gary Jennejohn wrote: > I just ran buildworld using the latest current source. > > It dies due to this error in line 385 of /usr/src/sbin/ifconfig/af_inet.c: > > static void > warn_nomask(ifflags) > > The compiler really doesn't like not seeing a type for ifflags and bails > out as the result. > > Strangely enough, in_proc() a few lines later clearly has int ifflags in > its list of variables. > > Setting ifflags to int in warn_nomask() fixes the build. > > Wasn't this compile tested before it was committed? > Woops! It turns out that my source was NOT fully up to date. I just saw that af_inet.c was fixed. Sorry for the noise. -- Gary Jennejohn
builworld fails due to error in af_inet.c
I just ran buildworld using the latest current source. It dies due to this error in line 385 of /usr/src/sbin/ifconfig/af_inet.c: static void warn_nomask(ifflags) The compiler really doesn't like not seeing a type for ifflags and bails out as the result. Strangely enough, in_proc() a few lines later clearly has int ifflags in its list of variables. Setting ifflags to int in warn_nomask() fixes the build. Wasn't this compile tested before it was committed? -- Gary Jennejohn
/usr/src/sys/netlink/route/iface.c:738:1: warning: unused function
This isn't a fatal error, but it would be easy to fix: /usr/src/sys/netlink/route/iface.c:738:1: warning: unused function 'inet6_get_plen' [-Wunused-function] inet6_get_plen(const struct in6_addr *addr) ^ 1 warning generated. This function is called in get_sa_plen(const struct sockaddr *sa) and the call is done inside #ifdef INET6...#endif, whereas the implementation is NOT inside #ifdef INET6...#endif, as it should be. I do not have INET6 in my kernel config file. -- Gary Jennejohn
Re: PORTS_MODULES fails with beinstall.sh
On Tue, 7 Mar 2023 13:47:53 +
Nuno Teixeira wrote:
> Hello all,
>
> I'm trying make.conf PORTS_MODULES=x11/nvidia-driver and it fails with
> beinstall.sh:
> ---
> [...]
> cd ${PORTSDIR:-/usr/ports}/x11/nvidia-driver; env -u CC -u CXX -u CPP
> -u MAKESYSPATH -u MK_AUTO_OBJ -u MAKEOBJDIR
> MAKEFLAGS="DESTDIR=/tmp/beinstall.6sMgsC/mnt KERNEL=kernel TARGET=amd64
> TARGET_ARCH=amd64" SYSDIR=/usr/src/sys
>
> PATH=/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
> SRC_BASE=/usr/src OSVERSION=1400081
> WRKDIRPREFIX=/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG make -B
> deinstall reinstall
> [...]
> cd: /tmp/mountpoint.CagxU8/usr/ports/x11/nvidia-driver: No such file or
> directory
> make: don't know how to make deinstall. Stop
> ---
>
> Any hints?
>
Read the shell script.
It only mounts srcdir, objdir and devfs under BE_MNTPT. The shell script
has absolutely no knowledge of other directories.
You could hack the script by adding e.g. portsdir=/usr/ports and then mount
it with
mount -t nullfs "${portsdir}" "${BE_MNTPT}${portsdir}" || errx "Unable to
mount ports"
Probably best to create a private copy named e.g. beinstall+ports.sh and
put it in your home directory.
--
Gary Jennejohn
Re: Build breakage with WITH_BEARSSL=1
On Sun, 12 Feb 2023 11:54:47 +0100 Gordon Bergling wrote: > Hi, > > I am currently seeing a build breakage when building -CURRENT with > WITH_BEARSSL=1. > > The error is the following > > make[5]: "/boiler/nfs/src/lib/libsecureboot/local.trust.mk" line 109: > warning: "cd /boiler/nfs/src/lib/libsecureboot && 'ls' -1 *.pem t*.asc 2> > /dev/null" returned non-zero status > /boiler/nfs/src/contrib/bearssl/src/rsa/rsa_i62_keygen.c:43:22: error: a > function declaration without a prototype is deprecat ed in all versions of C > [-Werror,-Wstrict-prototypes] > br_rsa_i62_keygen_get() >^ > void > 1 error generated. > --- rsa_i62_keygen.pico --- > > > When disabling BEARSSL in the src.conf the build succeeds as usual. > > Has anyone also seen this build error. Sources are very recent and the > src.conf is the following: > > WITH_EXTRA_TCP_STACKS=1 > #WITH_BEARSSL=1 > WITH_PIE=1 > WITH_RETPOLINE=1 > WITH_INIT_ALL_ZERO=1 > WITH_OPENSSL_KTLS=1 > WITHOUT_CLEAN=1 > > Any help is very appreciated. > The current clang wants to see br_rsa_i62_keygen_get(void), that's why void was emitted. The other routine in this file has the same error. Could be that this code has this problem in many places. There might a flag which one could pass to clang so that it would not choke on such an error, but I don't know clang well enough to figure that out. Maybe someone in the know could supply that info. -- Gary Jennejohn
Re: kernel compile fails if device bpf is not enabled
On Wed, 8 Feb 2023 12:49:46 +0800 Zhenlei Huang wrote: Hi Zhenlei, > Thanks for the report! Post the fix to Phabricator > https://reviews.freebsd.org/D38432 <https://reviews.freebsd.org/D38432> . > > Best regards, > Zhenlei > Thanks! I see it's been accepted. > > On Feb 7, 2023, at 5:08 PM, Gary Jennejohn wrote: > > > > I just saw this error today because I didn't have device bpf enabled in > > my kernel configuration file: > > > > -- > >>>> stage 3.1: building everything > > -- > > linking kernel.full > > ld: error: undefined symbol: bpf_mtap_if > >>>> referenced by if.c:4724 (/usr/src/sys/net/if.c:4724) > >>>> if.o:(if_bpfmtap) > >>>> referenced by if_tuntap.c:1717 (/usr/src/sys/net/if_tuntap.c:1717) > >>>> if_tuntap.o:(tunread) > >>>> referenced by if_vlan.c:1292 (/usr/src/sys/net/if_vlan.c:1292) > >>>> if_vlan.o:(vlan_transmit) > > > > ld: error: undefined symbol: bpf_mtap2_if > >>>> referenced by if_gif.c:323 (/usr/src/sys/net/if_gif.c:323) > >>>> if_gif.o:(gif_transmit) > >>>> referenced by if_tuntap.c:1816 (/usr/src/sys/net/if_tuntap.c:1816) > >>>> if_tuntap.o:(tunwrite) > > --- kernel.full --- > > *** [kernel.full] Error code 1 > > > > This happens because a dummy bpf_mtap_if() (called a NOP stub in bpf.c) > > isn't being defined if bpf is not enabled. > > > > -- > > Gary Jennejohn > > -- Gary Jennejohn
kernel compile fails if device bpf is not enabled
I just saw this error today because I didn't have device bpf enabled in my kernel configuration file: -- >>> stage 3.1: building everything -- linking kernel.full ld: error: undefined symbol: bpf_mtap_if >>> referenced by if.c:4724 (/usr/src/sys/net/if.c:4724) >>> if.o:(if_bpfmtap) >>> referenced by if_tuntap.c:1717 (/usr/src/sys/net/if_tuntap.c:1717) >>> if_tuntap.o:(tunread) >>> referenced by if_vlan.c:1292 (/usr/src/sys/net/if_vlan.c:1292) >>> if_vlan.o:(vlan_transmit) ld: error: undefined symbol: bpf_mtap2_if >>> referenced by if_gif.c:323 (/usr/src/sys/net/if_gif.c:323) >>> if_gif.o:(gif_transmit) >>> referenced by if_tuntap.c:1816 (/usr/src/sys/net/if_tuntap.c:1816) >>> if_tuntap.o:(tunwrite) --- kernel.full --- *** [kernel.full] Error code 1 This happens because a dummy bpf_mtap_if() (called a NOP stub in bpf.c) isn't being defined if bpf is not enabled. -- Gary Jennejohn
Re: TP-LINK USB no carrier after speed test
On Tue, 17 Jan 2023 19:58:54 -0300 (-03) Ivan Quitschal wrote: > On Tue, 27 Sep 2022, Hans Petter Selasky wrote: > > > > > FYI: There is some experimental thunderbolt support at: > > > > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhselasky%2Fusb4data=05%7C01%7C%7C14c86eee9f5d492c41d508daa0b49bdb%7C84df9e7fe9f640afb435%7C1%7C0%7C637998994857157968%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=%2FOnIO3esoAmi1FSPkHRYpHCHkcN6U2rO9WhaimdaVbk%3Dreserved=0 > > > > But I'm not sure if it supports the hardware you've got. > > > > --HPS > > > > > Hi Hans > > i just told you early today that the problem was solved by sticking it into > USB > 2.0, well i was wrong. problem came back just like before > > I see Alexander also has the same XHCI that i have here > > xhci0@pci0:0:20:0: class=0x0c0330 rev=0x20 hdr=0x00 vendor=0x8086 > device=0xa0ed > subvendor=0x1028 subdevice=0x0ab0 > vendor = 'Intel Corporation' > device = 'Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller' > class = serial bus > subclass = USB > > > maybe this tiger lake support is the problem? > > > I have checked your git repository above, how could i test it here ? what > dirs am i supposed to copy to my /usr/src ? > > thank you > That information is in the README.md: This implements a basic kernel driver and userland tool for USB4 and Thunderbolt3. The relevant code is in the following locations: sys/dev/thunderbolt sys/modules/thunderbolt usr.sbin/tbtconfig So, you need the contents of those directories. You'll have to build a module under sys/modules/thunderbolt, which should result in a tb.ko file, which will have to be loaded using kldload. You also have to go into /usr/src/usr.sbin/tbtconfig and build that binary. There's a manpage there. It's not clear from the content of README.md whether Hans has added thunderbolt to the files under /sys/conf. -- Gary Jennejohn
Re: Build failure: main-n259988-48dc9150ac36 -> main-n260011-40bb52c89b87
On Thu, 12 Jan 2023 10:37:34 -0700 Warner Losh wrote: > On Thu, Jan 12, 2023 at 4:44 AM David Wolfskill > wrote: > > > > I had this problem also. After deleting obj/usr the buildworld > succeeded. > > > > > > > > > > > > > Empirically: > > rm -fr /usr/obj/usr/src/amd64.amd64/usr.sbin/zic > > > > got through the issue on my build machine. (I expect that it will also > > do so on the others where I track head, but they are presently building > > lang/rust.) > > > > Perhaps an UPDATING entry would suffice? > > > > NO_CLEAN is the new default, so we need to fix this. There's a place that > we can add this workaround, which is why I cc'd emaste (who wrote the > framework) and des (who made the commit). > I actually initially ran: pushd /usr/src;make clean;time make -s -j14 buildworld;popd which didn't fix the problem because the .meta files were apparently not removed. That's why I ended up deleting obj/usr, since it guaranteed that the buildworld would really run in a clean environment. -- Gary Jennejohn
Re: Build failure: main-n259988-48dc9150ac36 -> main-n260011-40bb52c89b87
On Fri, 13 Jan 2023 01:31:59 +0900 Tomoaki AOKI wrote: > On Thu, 12 Jan 2023 14:41:19 + > Gary Jennejohn wrote: > [SNIP] > > > > I installed the new world on my tower this morning. Now I see a new > > problem. > > > > I don't know whether this new problem is related to the new tzcode, but > > apps like gkrellm2 and xclock now display the time one hour earlier > > than the actual time output by date(1), e.g. 10AM rather than 11AM. > > > > I had to set my /etc/localtime to GMT+0 to get the correct time output > > even though I live in Germany and the correct value would be either > > Europe/Berlin or CET. > > > > My laptop, which still has the old tzcode installed, did not exhibit > > that weird error. > > > > Do you have /etc/wall_cmos_clock? > Otherwise, FreeBSD base system thinks that the CMOS clock is set to UTC. > A blank file (just `touch`ed to create) is enough. > > IIUC, your laptop has it, but your tower has none. > Both the tower and the laptop have /etc/wall_cmos_clock, so that's not the cause of my problem. -- Gary Jennejohn
Re: Build failure: main-n259988-48dc9150ac36 -> main-n260011-40bb52c89b87
On Thu, 12 Jan 2023 03:44:03 -0800 David Wolfskill wrote: > On Wed, Jan 11, 2023 at 07:12:46AM -0700, Warner Losh wrote: > > looks like we may need another 'unclean' workaround for this? > > > > Warner > > > > On Wed, Jan 11, 2023 at 6:32 AM Gary Jennejohn wrote: > > ... > > > I had this problem also. After deleting obj/usr the buildworld succeeded. > > > > > > > Empirically: > rm -fr /usr/obj/usr/src/amd64.amd64/usr.sbin/zic > > got through the issue on my build machine. (I expect that it will also > do so on the others where I track head, but they are presently building > lang/rust.) > > Perhaps an UPDATING entry would suffice? > Didn't work for me when I decided to update my laptop, which had rather old /usr/src contents. I ended up deleting obj/usr again. I installed the new world on my tower this morning. Now I see a new problem. I don't know whether this new problem is related to the new tzcode, but apps like gkrellm2 and xclock now display the time one hour earlier than the actual time output by date(1), e.g. 10AM rather than 11AM. I had to set my /etc/localtime to GMT+0 to get the correct time output even though I live in Germany and the correct value would be either Europe/Berlin or CET. My laptop, which still has the old tzcode installed, did not exhibit that weird error. -- Gary Jennejohn
Re: Build failure: main-n259988-48dc9150ac36 -> main-n260011-40bb52c89b87
On Wed, 11 Jan 2023 04:05:43 -0800 David Wolfskill wrote: > Running: > FreeBSD freebeast.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #275 > main-n259988-48dc9150ac36: Tue Jan 10 12:20:47 UTC 2023 > r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC > amd64 > > and performing an in-place source update to main-n260011-40bb52c89b87 > using META mode, I encountered: > > Building /common/S4/obj/usr/src/amd64.amd64/usr.bin/tar/tests/test_option_k.o > Building /common/S4/obj/usr/src/amd64.amd64/usr.bin/calendar/tests/legacy_test > Building /common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic/zic > objcopy: open zic failed: Is a directory > *** [zic] Error code 1 > > make[4]: stopped in /usr/src/usr.sbin/zic > .ERROR_TARGET='zic' > .ERROR_META_FILE='/common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic/zic.meta' > .MAKE.LEVEL='4' > MAKEFILE='' > .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' > _ERROR_CMD='objcopy --strip-debug --add-gnu-debuglink=zic.debug zic.full > zic;' > .CURDIR='/usr/src/usr.sbin/zic' > .MAKE='make' > .OBJDIR='/common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic' > .TARGETS='all' > DESTDIR='/common/S4/obj/usr/src/amd64.amd64/tmp' > LD_LIBRARY_PATH='' > MACHINE='amd64' > MACHINE_ARCH='amd64' > MAKEOBJDIRPREFIX='' > MAKESYSPATH='/usr/src/share/mk' > MAKE_VERSION='20220726' > I had this problem also. After deleting obj/usr the buildworld succeeded. > Contents of the META_FILE: > # Meta data file /common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic/zic.meta > CMD objcopy --strip-debug --add-gnu-debuglink=zic.debug zic.full zic > CWD /common/S4/obj/usr/src/amd64.amd64/usr.sbin/zic > TARGET zic > OODATE zic.full zic.debug > -- command output -- > objcopy: open zic failed: Is a directory > > *** Error code 1 > > -- filemon acquired metadata -- > # filemon version 5 > # Target pid 76995 > # Start 1673437990.835926 > V 5 > E 84537 /bin/sh > R 84537 /etc/libmap.conf > R 84537 /var/run/ld-elf.so.hints > R 84537 /lib/libedit.so.8 > R 84537 /lib/libc.so.7 > R 84537 /lib/libtinfow.so.9 > R 84537 /usr/share/locale/en_US.UTF-8/LC_COLLATE > R 84537 /usr/share/locale/en_US.UTF-8/LC_CTYPE > R 84537 /usr/share/locale/en_US.UTF-8/LC_MONETARY > R 84537 /usr/share/locale/en_US.UTF-8/LC_NUMERIC > R 84537 /usr/share/locale/en_US.UTF-8/LC_TIME > R 84537 /usr/share/locale/en_US.UTF-8/LC_MESSAGES > F 84537 84538 > E 84538 /common/S4/obj/usr/src/amd64.amd64/tmp/usr/bin/objcopy > R 84538 zic.full > X 84538 1 0 > X 84537 1 0 > # Stop 1673437990.838926 > # Bye bye > > This is on a 32-core amd64 machine with 256GiB RAM (in case that's > relevant). > > Peace, > david > -- > David H. Wolfskill da...@catwhisker.org > Putin seems to use the word "peace" in the way that Neville Chamberlain did. > > See https://www.catwhisker.org/~david/publickey.gpg for my public key. -- Gary Jennejohn
Re: buildkernel doesn't respect PORTSDIR with PORTS_MODULES
On Thu, 24 Nov 2022 12:02:35 + Nuno Teixeira wrote: > Hello, > > I'm trying PORT_MODULES with make.conf: > --- > PORTSDIR=/work/freebsd/ports > DISTDIR=/work/DISTFILES > PORTS_MODULES=graphics/drm-kmod x11/nvidia-driver > --- > and `make buildkernel` fails: > --- > linking kernel.full > ctfmerge -L VERSION -g -o kernel.full ... > text data bssdec hex filename > 22977071 1848409 4437760 29263240 0x1be8588 kernel.full > cd: /usr/ports/graphics/drm-kmod: No such file or directory > --- > > Any hint? > Thanks, > bsd.port.mk and bsd.port.subdir.mk use _PORTSDIR. You could try adding that to your list. -- Gary Jennejohn
Re: dmesg content lifetime
On Wed, 23 Nov 2022 07:16:19 +0900 Tomoaki AOKI wrote: > On Tue, 22 Nov 2022 19:13:18 +0100 > Gary Jennejohn wrote: > > Or look at /var/run/dmesg.boot. It doesn't get overwritten. > > > > It may be overwritten on reboot. > And there are dmesg.[today|yesterday] on /var/log/, too. > Rotated daily. > Yes, it definitely does get overwritten on reboot. But at least its contents are stable between boots. -- Gary Jennejohn
Re: dmesg content lifetime
On Wed, 23 Nov 2022 01:16:55 +0900 Tomoaki AOKI wrote: > On Tue, 22 Nov 2022 09:47:10 -0600 (CST) > Dan Mack wrote: > > > On Tue, 22 Nov 2022, Alexander Kabaev wrote: > > > > > On Tue, 22 Nov 2022 09:12:28 -0600 (CST) > > > Dan Mack wrote: > > > > > >> It seems like dmesg content ages out over time. Is there a way to > > >> leave the contents based on a fixed memory size instead? > > >> > > >> Dan > > >> > > > I think this is how it works: the kernel message bugger is of fixed > > > size and kernel and syslog sequences (dmesg -a) share it. The other > > > syslog users eventually puts enough content in there to displace all of > > > kernel messages. If the kernel stays quiet, 'dmesg' then returns > > > nothing, as by default it filters syslog entries that do not KERN > > > facility out, see sbin/dmesg/dmesg.c. > > > > > > -- > > > Alexander Kabaev > > > > > > > Thank you Alexander, I did not know this. I'll USL (use-the-source-luke) > > :-) > > > > Dan > > Increase kern.msgbufsize tunable on /boot/loader.conf if you want dmesg > to live longer. For example, recommended value by iwlwifi team is > 1146880. Much larger than default. > > Note that this is actually a tunable and can be set only on boot time. > Or look at /var/run/dmesg.boot. It doesn't get overwritten. -- Gary Jennejohn
Re: build world fails on raw_ip.c
On Tue, 4 Oct 2022 15:20:05 +0200 Hans Petter Selasky wrote: > On 10/4/22 15:14, Johan Hendriks wrote: > > I just updated the source today but now i get an error building world. > > The old build was from yesterday which was fine! > > > > Building /usr/obj/usr/src/amd64.amd64/sys/KRNL/raw_ip.o > > cc -target x86_64-unknown-freebsd14.0 > > > --sysroot=/usr/obj/usr/src/amd64.amd64/tmp > > > -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -c -O2 -pipe > > > -fno-strict-aliasing -march=broadwell -g -nostdinc -I. -I/usr/src/sys > > > -I/usr/src/sys/contrib/ck/include -I/usr/src/sys/contrib/libfdt > -D_KERNEL > > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > > > -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer > > > -fdebug-prefix-map=./machine=/usr/src/sys/amd64/include > > > -fdebug-prefix-map=./x86=/usr/src/sys/x86/include > > > -fdebug-prefix-map=./i386=/usr/src/sys/i386/include -mcmodel=kernel > > > -mno-red-zone -mno-mmx -mno-sse -msoft-float > > > -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector > > > -Wall -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes > > > -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign > > > -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs > > > -fdiagnostics-show-option -Wno-unknown-pragmas > > > -Wno-error=tautological-compare -Wno-error=empty-body > > > -Wno-error=parentheses-equality -Wno-error=unused-function > > > -Wno-error=pointer-sign -Wno-error=shift-negative-value > > > -Wno-address-of-packed-member -Wno-format-zero-length -mno-aes > -mno-avx > > -std=iso9899:1999 -Werror /usr/src/sys/netinet/raw_ip.c > > /usr/src/sys/netinet/raw_ip.c:811:3: error: too few arguments to > function > > call, expected 4, have 2 > > IPSEC_CTLINPUT(ipv4, icmp); > > ^~ > > /usr/src/sys/netipsec/ipsec_support.h:222:61: note: expanded from macro > > > 'IPSEC_CTLINPUT' > > ipsec_kmod_ctlinput(proto ## _ipsec_support, __VA_ARGS__) > > ~~~ ^ > > /usr/src/sys/netipsec/ipsec_support.h:196:5: note: 'ipsec_kmod_ctlinput' > > > declared here > > int ipsec_kmod_ctlinput(struct ipsec_support * const, int, > > ^ > > 1 error generated. > > *** Error code 1 > > > > I've mailed the responsible committer. > > Just do: > > diff --git a/sys/amd64/conf/GENERIC b/sys/amd64/conf/GENERIC > index 9178abba36cc..ed8045e48257 100644 > --- a/sys/amd64/conf/GENERIC > +++ b/sys/amd64/conf/GENERIC > @@ -30,7 +30,7 @@ options PREEMPTION # Enable kernel > thread preemption > optionsVIMAGE # Subsystem virtualization, e.g. VNET > optionsINET# InterNETworking > optionsINET6 # IPv6 communications protocols > -optionsIPSEC_SUPPORT # Allow kldload of ipsec and tcpmd5 > +# options IPSEC_SUPPORT # Allow kldload of ipsec and tcpmd5 > optionsROUTE_MPATH # Multipath routing support > optionsFIB_ALGO# Modular fib lookups > optionsTCP_OFFLOAD # TCP offload > > > > For now. > There are the usual other problems, like always assuming the every user has INET6 defined in their kernel config file. Here's an error I just saw: /usr/src/sys/netinet/tcp_subr.c:136:8: error: unknown type name 'ip6proto_ctlinput_t'; did you mean 'ipproto_ctlinput_t'? static ip6proto_ctlinput_t tcp6_ctlinput; ^~~ ipproto_ctlinput_t /usr/src/sys/netinet/ip_var.h:242:14: note: 'ipproto_ctlinput_t' declared here typedef voidipproto_ctlinput_t(struct icmp *); ^ 1 error generated. --- tcp_subr.o --- *** [tcp_subr.o] Error code 1 -- Gary Jennejohn
Re: build of vfs_lookup.c now broken in non-INVARIANTS kernels
On Sat, 17 Sep 2022 12:46:36 +0200 Mateusz Guzik wrote: > fixed in > https://cgit.freebsd.org/src/commit/?id=b77bdfdb67c2e9660658a0373662e4263a905e90 > > On 9/17/22, Gary Jennejohn wrote: > > Compiling vfs_lookup.c now fails when NONINVARIANTS is not included in > > the kernel config file because NDVALIDATE is defined as NDVALIDATE_impl, > > which itself is only defined when NONINVARIANTS is also defined. > > > > This breaks buildkernel. > > Thanks! -- Gary Jennejohn
Re: build of vfs_lookup.c now broken in non-INVARIANTS kernels
On Sat, 17 Sep 2022 12:41:25 +0200 Gary Jennejohn wrote: > Compiling vfs_lookup.c now fails when NONINVARIANTS is not included in > the kernel config file because NDVALIDATE is defined as NDVALIDATE_impl, > which itself is only defined when NONINVARIANTS is also defined. > > This breaks buildkernel. > Woops. NONINVARIANTS should be INVARIANTS. -- Gary Jennejohn
build of vfs_lookup.c now broken in non-INVARIANTS kernels
Compiling vfs_lookup.c now fails when NONINVARIANTS is not included in the kernel config file because NDVALIDATE is defined as NDVALIDATE_impl, which itself is only defined when NONINVARIANTS is also defined. This breaks buildkernel. -- Gary Jennejohn
Re: What are the in-kernel functions to format time?
On Fri, 11 Mar 2022 11:01:03 +0100 Hans Petter Selasky wrote: > On 3/11/22 10:49, Alexander Leidinger wrote: > > Hi, > > > > I'm looking for a function to convert bintime to a human readable format > > > in the kernel... and what is the usual format we use? > > > > > > The use case for this is: if something throws a log from the kernel > about > > a signal, I want to know when it happened, or in terms of code see > below > > (tabs are most probably messed up). > > > > Do we have some kind of policy in terms of kernel messages and > > > timestamps? Like "do not commit logging with timestamps"? I have the > code > > below because I needed it at least once and think something like > this (in > > a human readably shape) would be beneficial to have in the tree. > > > > Hi, > > I think our kernel printer doesn't support this: > > sys/kern/subr_prf.c > Do you mean the %zd? kvprintf() checks for a zflag and handles the argument as size_t or ssize_t, depending on whether the sign is positive or negative. However, %n isn't supported. > If you need to extend the format, please check other OS'es too, like > OpenBSD, NetBSD and Linux, what they support, so there won't be any > obvious conflicts when moving code cross platforms! > -- Gary Jennejohn
Re: test-includes breaks buildworld when WITHOUT_PF is set in src.conf
On Wed, 09 Feb 2022 11:08:44 +0100
Kristof Provost wrote:
> On 9 Feb 2022, at 10:57, Gary Jennejohn wrote:
> > test-includes uses pf.h when checking usage of pfvar.h.
> >
> > But, these lines in include/Makefile remove pf.h when WITHOUT_PF is
> > set in src.conf:
> >
> > .if ${MK_PF} != "no"
> > INCSGROUPS+= PF
> > .endif
> >
> > This breaks buildworld. The error message:
> >
> > In file included from net_pfvar.c:1:
> > /usr/obj/usr/src/amd64.amd64/tmp/usr/include/net/pfvar.h:65:10: fatal error:
> > 'netpfil/pf/pf.h' file not found
> > #include
> > ^
> > 1 error generated.
> > --- net_pfvar.o ---
> > *** [net_pfvar.o] Error code 1
> >
> > make[3]: stopped in /usr/src/tools/build/test-includes
> > .ERROR_TARGET='net_pfvar.o'
> >
> > Removing the .if/.endif fixes it for me, although there may be a better
> > way to avoid the error.
> >
> Warner's working on a better fix. See https://reviews.freebsd.org/D34009 for
> the discussion.
>
Thanks for the info.
--
Gary Jennejohn
fd7daa727126 breaks buildkernel when KERN_TLS is not defined
Commit fd7daa727126 to /usr/src/sys/netinet/tcp_usrreq.c breaks buildkernel
when KERN_TLS is not defined.
This patch fixes it for me:
--- tcp_usrreq.c.orig 2022-02-09 10:25:46.851034000 +
+++ tcp_usrreq.c2022-02-09 10:30:27.541058000 +
@@ -2119,12 +2119,12 @@
int
tcp_default_ctloutput(struct inpcb *inp, struct sockopt *sopt)
{
- struct socket *so = inp->inp_socket;
struct tcpcb *tp = intotcpcb(inp);
int error, opt, optval;
u_int ui;
struct tcp_info ti;
#ifdef KERN_TLS
+ struct socket *so = inp->inp_socket;
struct tls_enable tls;
#endif
char*pbuf, buf[TCP_LOG_ID_LEN];
@@ -2136,7 +2136,9 @@
INP_WLOCK_ASSERT(inp);
KASSERT((inp->inp_flags & (INP_TIMEWAIT | INP_DROPPED)) == 0,
("inp_flags == %x", inp->inp_flags));
+#ifdef KERN_TLS
KASSERT(so != NULL, ("inp_socket == NULL"));
+#endif
switch (sopt->sopt_level) {
#ifdef INET6
--
Gary Jennejohn
test-includes breaks buildworld when WITHOUT_PF is set in src.conf
test-includes uses pf.h when checking usage of pfvar.h.
But, these lines in include/Makefile remove pf.h when WITHOUT_PF is
set in src.conf:
.if ${MK_PF} != "no"
INCSGROUPS+= PF
.endif
This breaks buildworld. The error message:
In file included from net_pfvar.c:1:
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/net/pfvar.h:65:10: fatal error:
'netpfil/pf/pf.h' file not found
#include
^
1 error generated.
--- net_pfvar.o ---
*** [net_pfvar.o] Error code 1
make[3]: stopped in /usr/src/tools/build/test-includes
.ERROR_TARGET='net_pfvar.o'
Removing the .if/.endif fixes it for me, although there may be a better
way to avoid the error.
--
Gary Jennejohn
recent commit breaks buildkernel
commit ff3a85d32411cdd7894f932b1d3d7ce01ec7a648 breaks buildkernel if options INET6 is not in the kernel config file. The breakage is in the new lltable_get function. It needs #ifdef INET6 around case AF_INET6. -- Gary Jennejohn
Re: WITHOUT_PF breaks buildworld
On Wed, 22 Dec 2021 12:52:15 -0600 Warner Losh wrote: > On Wed, Dec 22, 2021, 12:37 PM Gary Jennejohn wrote: > [snip patch] > > > > Since pf.h is used so widely in the tree it's probably the simplest > > fix. > > > > > > > > > > I like this. I'd unconditionally remove the test in preference to adding > > it conditionally. > > > > > > > If I still had my commit bit I'd do it myself :-) > > > > I can do it tonight. I'm on the road today dri ING back from Omaha.. > Thanks. Then I can remove my hack to patch the Makefile. -- Gary Jennejohn
Re: WITHOUT_PF breaks buildworld
On Wed, 22 Dec 2021 10:58:50 -0600
Warner Losh wrote:
> On Wed, Dec 22, 2021, 10:02 AM Gary Jennejohn wrote:
>
> >
> > This simple patch to /usr/src/include/Makefile fixes it for me:
> >
> > --- Makefile.orig 2021-12-22 13:37:02.817745000 +0100
> > +++ Makefile2021-12-22 13:37:12.177336000 +0100
> > @@ -246,9 +246,7 @@
> > INCSGROUPS+= IPFILTER
> > .endif
> >
> > -.if ${MK_PF} != "no"
> > INCSGROUPS+= PF
> > -.endif
> >
> > .if ${MK_CDDL} != "no"
> > INCSGROUPS+= NVPAIR
> >
> > Since pf.h is used so widely in the tree it's probably the simplest fix.
> >
>
> I like this. I'd unconditionally remove the test in preference to adding it
> conditionally.
>
If I still had my commit bit I'd do it myself :-)
--
Gary Jennejohn
Re: WITHOUT_PF breaks buildworld
On Wed, 22 Dec 2021 16:51:54 +0100
Gary Jennejohn wrote:
On Wed, 22 Dec 2021 16:27:52 +0100
Kristof Provost wrote:
> On 22 Dec 2021, at 8:21, Konrad Sewi??o-Jopek wrote:
> > Hi,
> >
> > I think the reason is somewhere in tools/build/test-includes:
> >
> > --- net/if_pfsync.o ---
> > In file included from net/if_pfsync.c:1:
> > In file included from
> > [...]freebsd/arm64.aarch64/tmp/usr/include/net/if_pfsync.h:56:
> > [...]freebsd/arm64.aarch64/tmp/usr/include/net/pfvar.h:65:10: fatal error:
> > 'netpfil/pf/pf.h' file not found
> > #include
> > ^
> > 1 error generated.
> > *** [net/if_pfsync.o] Error code 1
> >
> > make[3]: stopped in [...]freebsd/tools/build/test-includes
> > --- net/pfvar.o ---
> > > In file included from net/pfvar.c:1:
> > > [...]freebsd/arm64.aarch64/tmp/usr/include/net/pfvar.h:65:10: fatal error:
> > > 'netpfil/pf/pf.h' file not found
> > > #include
> > > ^
> > > 1 error generated.
> > > *** [net/pfvar.o] Error code 1
> > >
> > > make[3]: stopped in [...]freebsd/tools/build/test-includes
> > > 2 errors
> > >
> > > make[3]: stopped in [...]freebsd/tools/build/test-includes
> > > *** [test-includes] Error code 2
> > >
> > > make[2]: stopped in [...]freebsd
> > > 1 error
> > >
> > > Best regards,
> > > Konrad Sewi??o-Jopek
> > >
> > >
> > > niedz., 19 gru 2021 o 12:26 Gary Jennejohn
> > > napisa?(a):
> > >
> > >> On Sun, 19 Dec 2021 19:05:35 +0800
> > >> Alastair Hogge wrote:
> > >>
> > >>> On Sunday, 19 December 2021 6:47:23 PM AWST Gary Jennejohn wrote:
> > >>>> Some recent change, probably in a .mk file, breaks builworld on HEAD
> > >>>> when WITHOUT_PF is enabled in src.conf.
> > >>>
> > >>> I have had to disable WITHOUT_PF since 2020-07-27, but probably earlier.
> > >>>
> > >>
> > >> Hmm. I did a successful buildworld a few days ago with WITHOUT_PF
> > >> enabled, so it's new breakge for me at least.
> > >>
> > >> I don't enable pf in the kernel and don't need it in userland.
> > >>
> > >>>> Disabling WITHOUT_PF results in a successful buildworld.
> > >>>>
> > >>>> The reported error is that netpfil/pf/pf.h can't be found.
> > >>>
> > >>> Some ports depend on that too.
> > >>>
> > >>
> This is the test-includes target, which validates that include files are
> self-contained (that is, you can '#include <$file>' without prerequisites.
> The target fails because it looks at all headers in /usr/src/sys and then
> tries to build them, but some of those headers (like the pf headers) include
> other headers that may not be getting installed because they're disabled.
>
> I'm not quite sure how to best fix this.
>
> Note that it is not happening because some pf tools are still getting built.
> This is a validation target that fails.
>
> We could potentially add the pf headers to BADHDRS depending on the WITHOUT_
> flag, but that would mean manually maintaining badfiles.inc.
> Or perhaps we should keep installing the pf headers even when WITHOUT_PF is
> set, but I'm not actually sure how we convince the build system to do that.
> Or if it's a good idea.
>
> Warner might have better ideas on how to fix this.
>
This simple patch to /usr/src/include/Makefile fixes it for me:
--- Makefile.orig 2021-12-22 13:37:02.817745000 +0100
+++ Makefile2021-12-22 13:37:12.177336000 +0100
@@ -246,9 +246,7 @@
INCSGROUPS+= IPFILTER
.endif
-.if ${MK_PF} != "no"
INCSGROUPS+= PF
-.endif
.if ${MK_CDDL} != "no"
INCSGROUPS+= NVPAIR
Since pf.h is used so widely in the tree it's probably the simplest fix.
--
Gary Jennejohn
Re: WITHOUT_PF breaks buildworld
On Wed, 22 Dec 2021 12:04:01 +0100 Gary Jennejohn wrote: > On Wed, 22 Dec 2021 08:21:35 +0100 > Konrad Sewi??o-Jopek wrote: > > > Hi, > > > > I think the reason is somewhere in tools/build/test-includes: > > > > --- net/if_pfsync.o --- > > In file included from net/if_pfsync.c:1: > > In file included from > > [...]freebsd/arm64.aarch64/tmp/usr/include/net/if_pfsync.h:56: > > [...]freebsd/arm64.aarch64/tmp/usr/include/net/pfvar.h:65:10: fatal error: > > 'netpfil/pf/pf.h' file not found > > #include > > ^ > > 1 error generated. > > *** [net/if_pfsync.o] Error code 1 > > > > make[3]: stopped in [...]freebsd/tools/build/test-includes > > --- net/pfvar.o --- > > In file included from net/pfvar.c:1: > > [...]freebsd/arm64.aarch64/tmp/usr/include/net/pfvar.h:65:10: fatal error: > > 'netpfil/pf/pf.h' file not found > > #include > > ^ > > 1 error generated. > > *** [net/pfvar.o] Error code 1 > > > > make[3]: stopped in [...]freebsd/tools/build/test-includes > > 2 errors > > > > make[3]: stopped in [...]freebsd/tools/build/test-includes > > *** [test-includes] Error code 2 > > > > make[2]: stopped in [...]freebsd > > 1 error > > > > Could be. With WITHOUT_PF include/netpfil/pf/pf.h disappears from obj. > But since buildworld still tries to build net/if_pfsync.c and other > pf-related binaries the buildworld fails. > > One would thank the WITHOUT_PF should also block building ALL pf-related > binaries, but that's not the case. > Ah well, pf.h is used in so many places under /usr/src that the best approach might be to simply remove the WITHOUT_PF build option. -- Gary Jennejohn
Re: WITHOUT_PF breaks buildworld
On Wed, 22 Dec 2021 08:21:35 +0100 Konrad Sewi??o-Jopek wrote: > Hi, > > I think the reason is somewhere in tools/build/test-includes: > > --- net/if_pfsync.o --- > In file included from net/if_pfsync.c:1: > In file included from > [...]freebsd/arm64.aarch64/tmp/usr/include/net/if_pfsync.h:56: > [...]freebsd/arm64.aarch64/tmp/usr/include/net/pfvar.h:65:10: fatal error: > 'netpfil/pf/pf.h' file not found > #include > ^ > 1 error generated. > *** [net/if_pfsync.o] Error code 1 > > make[3]: stopped in [...]freebsd/tools/build/test-includes > --- net/pfvar.o --- > In file included from net/pfvar.c:1: > [...]freebsd/arm64.aarch64/tmp/usr/include/net/pfvar.h:65:10: fatal error: > 'netpfil/pf/pf.h' file not found > #include > ^ > 1 error generated. > *** [net/pfvar.o] Error code 1 > > make[3]: stopped in [...]freebsd/tools/build/test-includes > 2 errors > > make[3]: stopped in [...]freebsd/tools/build/test-includes > *** [test-includes] Error code 2 > > make[2]: stopped in [...]freebsd > 1 error > Could be. With WITHOUT_PF include/netpfil/pf/pf.h disappears from obj. But since buildworld still tries to build net/if_pfsync.c and other pf-related binaries the buildworld fails. One would thank the WITHOUT_PF should also block building ALL pf-related binaries, but that's not the case. -- Gary Jennejohn
Re: WITHOUT_PF breaks buildworld
On Sun, 19 Dec 2021 19:05:35 +0800 Alastair Hogge wrote: > On Sunday, 19 December 2021 6:47:23 PM AWST Gary Jennejohn wrote: > > Some recent change, probably in a .mk file, breaks builworld on HEAD > > when WITHOUT_PF is enabled in src.conf. > > I have had to disable WITHOUT_PF since 2020-07-27, but probably earlier. > Hmm. I did a successful buildworld a few days ago with WITHOUT_PF enabled, so it's new breakge for me at least. I don't enable pf in the kernel and don't need it in userland. > > Disabling WITHOUT_PF results in a successful buildworld. > > > > The reported error is that netpfil/pf/pf.h can't be found. > > Some ports depend on that too. > It may not be a problem for ports. Depends on where they look for it. The file is still there under /sys and /usr/include. -- Gary Jennejohn
WITHOUT_PF breaks buildworld
Some recent change, probably in a .mk file, breaks builworld on HEAD when WITHOUT_PF is enabled in src.conf. Disabling WITHOUT_PF results in a successful buildworld. The reported error is that netpfil/pf/pf.h can't be found. -- Gary Jennejohn
Re: build failure on -current
On Fri, 17 Dec 2021 09:44:20 -0800 Chuck Tuffli wrote: > When building current from git, I keep hitting the error below. This > is with meta-mode, but I've also tried deleting the object directory. > The system also has a couple of tweaks to src-env.conf that were an > attempt to avoid building any (most?) of clang. Relevant system > information: > > $ uname -mrsv > FreeBSD 14.0-CURRENT FreeBSD 14.0-CURRENT main-22c4ab6cb0 GENERIC amd64 > $ cat /etc/src-env.conf > WITH_META_MODE=YES > WITHOUT_CLANG=YES > WITHOUT_CLANG_BOOTSTRAP=YES > $ env MAKEOBJDIRPREFIX=$(realpath ../obj) make buildworld -j$(sysctl -n > hw.ncpu) > > --- Core/ModuleList.o --- > In file included from > /usr/home/ctuffli/dev/freebsd/src.git/contrib/llvm-project/lldb/source/Core/ModuleList.cpp:34: > In file included from > /usr/home/ctuffli/dev/freebsd/src.git/contrib/llvm-project/clang/include/clang/Driver/Driver.h:12: > In file included from > /usr/home/ctuffli/dev/freebsd/src.git/contrib/llvm-project/clang/include/clang/Basic/Diagnostic.h:17: > /usr/home/ctuffli/dev/freebsd/src.git/contrib/llvm-project/clang/include/clang/Basic/DiagnosticIDs.h:71:10: > fatal error: 'clang/Basic/DiagnosticCommonKinds.inc' file not found > #include "clang/Basic/DiagnosticCommonKinds.inc" > ^~~ > 1 error generated. > *** [Core/ModuleList.o] Error code 1 > > Where did I goof? TIA > Do you need lldb? If not you could try adding WITHOUT_LLDB to src-env.conf and see what happens. -- Gary Jennejohn
Re: make cleandiry tries to access /lib/geom
On Wed, 24 Nov 2021 10:03:22 -0700 Warner Losh wrote: > On Wed, Nov 24, 2021 at 9:52 AM John Baldwin wrote: > > > On 11/24/21 3:30 AM, Bjoern A. Zeeb wrote: > > > Hi, > > > > > > 673 ===> usr.bin/diff/tests (cleandir) > > > 674 ===> lib/geom (cleandir) > > > 675 ===> sbin/mount_udf (cleandir) > > > 676 make[6] warning: /lib/geom: Permission denied. > > > > > > not sure what is going on here? > > > > > > 677 ===> share/i18n/esdb/ISO-8859 (cleandir) > > > 678 ===> tests/sys/cddl/zfs/tests/cli_root/zfs_clone (cleandir) > > > > I think Jess has a possible fix. This is some regression added in the > > build system several months ago. > > > https://reviews.freebsd.org/D30990 I have MAKEOBJDIRPREFIX pointing to ~/obj. This works for me, no longer any /xxx/yyy/ permisson denied errors. -- Gary Jennejohn
Re: zfskeys does not exist
On Sat, 13 Nov 2021 11:33:01 + Graham Perrin wrote: > <https://cgit.freebsd.org/src/commit/?id=33ff39796ffe469a764e485ac49c31700a51fd6f> > (2021-07-28): > > > Add zfskeys rc.d script for auto-loading encryption keys > > <https://cgit.freebsd.org/src/log/?qt=grep=zfskeys> finds only the July > commit. > > Below, I don't have zfskeys. Please, can anyone explain? > > Thanks > /usr/src/libexec/rc/rc.d/zfskeys Maybe it isn't being installed automatically? No idea and I don't use ZFS myself. > > > root@mowa219-gjp4-8570p-freebsd:~ # service zfskeys status > zfskeys does not exist in /etc/rc.d or the local startup > directories (/usr/local/etc/rc.d), or is not executable > root@mowa219-gjp4-8570p-freebsd:~ # ls -hl /etc/rc.d/zfs* > -r-xr-xr-x 1 root wheel 872B Jan 1 2021 /etc/rc.d/zfs > -r-xr-xr-x 1 root wheel 1.7K Jan 1 2021 /etc/rc.d/zfsbe > -r-xr-xr-x 1 root wheel 209B Jan 1 2021 /etc/rc.d/zfsd > root@mowa219-gjp4-8570p-freebsd:~ # ls /usr/local/etc/rc.d > amd gpsd sndiod > aria2 grafana snmpd > atop iocage snmptrapd > avahi-daemon jackd stunnel > avahi-dnsconfd microcode_update svnserve > bsdstats miniupnpc tcsd > clamav-clamd mysql-server tor > clamav-freshclam netdata tpmd > clamav-milter php-fpm ubuntu > cpupdate poudriered uuidd > croc powerdxx vboxheadless > cups_browsed rdnssd vboxnet > cupsd rsyncd vboxwatchdog > dbus samba_server vboxwebsrv > dsbmd saned virtual_oss > gdm sddm vm > git_daemon slpd webcamd > gkrellmd smartd > root@mowa219-gjp4-8570p-freebsd:~ # date > Sat Nov 13 10:21:22 GMT 2021 > root@mowa219-gjp4-8570p-freebsd:~ # uname -aKU > FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #114 > main-n > 250511-5f73b3338ee: Sat Nov 6 21:15:23 GMT 2021 > root@mowa219-gjp4-8570p-fre > ebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400040 1400040 > root@mowa219-gjp4-8570p-freebsd:~ # -- Gary Jennejohn
Re: Curious minds .. etc
On Fri, 22 Oct 2021 01:07:47 -0700 Julian Elischer wrote: > Several years ago (OK, maybe 12 years ago) I did an experiment where I > unpacked a > freebsd 1.1 (or maybe 2.0?) image into a subdirectory, and after installing > various > compat packagesand options and a.out support and changing MAX_PID to be > 6, I was able to > chroot to it and do a "make world". Things were stupidly fast. > > > Has anyone been able to do such a thing in recent years? One wonders what > options one > would need and what the oldest Version we could run in this way was.. > Well, there's still a /usr/ports/misc/compat4x, which is the oldest version supported. So that could still work, although it's not obvious whether it will work with e.g. FBSD-14. The most recent compat version is for 12x. The good old days, when the kernel was on the order of 90kB and 256kB of memory was a lot and big disks had one or two hundred MB. -- Gary Jennejohn
Re: Is dialog4ports built in/for releng/13.0 also supposed to work under main [so: 14]? It gets SIGSEGV in my context.
On Thu, 21 Oct 2021 01:34:47 -0700 Mark Millard via freebsd-current wrote: > I get the following crash (amd64 example shown), as reported > via gdb afterwards. (devel/llvm13 is just an example context.) > > gdb `which dialog4ports` devel/llvm13/dialog4ports.core > . . . > Core was generated by `/usr/local/bin/dialog4ports'. > Program terminated with signal SIGSEGV, Segmentation fault. > Address not mapped to object. > #0 vfprintf_l (fp=0x4d4940, locale=0x8004d4128 <__xlocale_global_locale>, > fmt0=0x201f64 "\"%s\"", ap=ap@entry=0x7fffcf00) at > /usr/main-src/lib/libc/stdio/vfprintf.c:281 > 281 if ((fp->_flags & (__SNBF|__SWR|__SRW)) == (__SNBF|__SWR) && > (gdb) bt > #0 vfprintf_l (fp=0x4d4940, locale=0x8004d4128 <__xlocale_global_locale>, > fmt0=0x201f64 "\"%s\"", ap=ap@entry=0x7fffcf00) at > /usr/main-src/lib/libc/stdio/vfprintf.c:281 > #1 0x000800409283 in fprintf (fp=0x800411660 <__stdio_cancel_cleanup>, > fmt=0x7fffcdd0 "0\317\377\377\377\177") at > /usr/main-src/lib/libc/stdio/fprintf.c:57 > #2 0x0020399d in main (argc=, argv=) > at dialog4ports.c:332 > (gdb) quit > > The crash happens after selecting OK but not after selecting Cancel. The > display is also odd before that (no line drawing, just odd text instead), > but is sufficient to be usable at that stage. > This is an indication that something is missing in dialog4ports which is required by FBSD-14 but not FBSD-13. I had a similar problem with dialog4ports under FBSD-14 some weeks ago, because i had a really old version installed. After upgrading it using the pkg repositories for FBSD-14 all problems, in particular garbled text, disappeared. IIRC there were updates to ncurses in FBSD-14 fairly recently which would explain the problem with old versions of dialog4ports. > I've not had any other of the ports that I built in/for releng/13.0 > (and have used) fail to operate under main [so: under 14]. (But the > variety used is not wide.) > > For reference . . . > > # uname -apKU > FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #3 > main-n249978-032448cd2c52-dirty: Fri Oct 8 23:57:23 PDT 2021 > root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG > amd64 amd64 1400036 1400036 > > (Not a debug build but has debug symbols enabled.) > > # pwd > /usr/ports > # ~/fbsd-based-on-what-commit.sh > branch: main > merge-base: 4116dc2f1f6385b42fb668badb6b4c1cbb195f9d > merge-base: CommitDate: 2021-10-17 21:52:37 + > 4116dc2f1f63 (HEAD -> main, freebsd/main, freebsd/HEAD) > ports-mgmt/poudriere-devel: Update to 3.3.0-1022-g964cf327f > n562472 (--first-parent --count for merge-base) > > # file `which dialog4ports` > /usr/local/bin/dialog4ports: ELF 64-bit LSB executable, x86-64, version 1 > (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD > 13.0 (1300139), FreeBSD-style, with debug_info, not stripped > > # ldd `which dialog4ports` > /usr/local/bin/dialog4ports: > libncursesw.so.9 => /lib/libncursesw.so.9 (0x800248000) > libm.so.5 => /lib/libm.so.5 (0x800281000) > libdialog.so.9 => /usr/lib/libdialog.so.9 (0x8002b8000) > libc.so.7 => /lib/libc.so.7 (0x8002f6000) > libtinfow.so.9 => /lib/libtinfow.so.9 (0x800703000) > > Note: The dialog4ports is a non-debug build but with debug symbols, > as is normal for my port builds via poudriere-devel . > > As for the poudriere-devel build context for the ports: > > # chroot /usr/obj/DESTDIRs/13_0R-amd64-poud/ > # uname -apKU > FreeBSD amd64_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #3 > main-n249978-032448cd2c52-dirty: Fri Oct 8 23:57:23 PDT 2021 > root@amd64_ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG > amd64 amd64 1400036 1300139 > > # cd /usr/13_0R-src/ > # ~/fbsd-based-on-what-commit.sh > branch: releng/13.0 > merge-base: 940681634ee17d12225ecd722c07fef1a0bde813 > merge-base: CommitDate: 2021-08-24 18:23:29 + > 940681634ee1 (HEAD -> releng/13.0, freebsd/releng/13.0) Add UPDATING entries > and bump version. > n244760 (--first-parent --count for merge-base) > > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > -- Gary Jennejohn
Re: [HEADSUP] making /bin/sh the default shell for root
On Tue, 12 Oct 2021 14:42:48 +0200 Guido Falsi via freebsd-current wrote: > On 12/10/21 14:21, Gary Jennejohn wrote: > > On Tue, 12 Oct 2021 06:59:00 -0400 > > grarpamp wrote: > > > >>> No. The system shell is supposed to make the system usable > >>> by the users. Actually, the real problem is that the easiest way > >>> to shoot one's own foot is by changing the language (say, the > >>> shell) spoken by default by FreeBSD. > >> > >> Well, the FreeBSD system speaks sh for its own use, this is clearly > >> documented as the shell called by init(8), and later by rc(8), > >> it should probably be the root:0 entry at least for consistancy. > >> No other shell is called by the FreeBSD system there. > >> Whatever the users want for their own shells is really up > >> to them to decide after that. > >> > >> "Default" is bit of low context word, as there is no falling > >> back to some shell occuring, no filling in for some missing > >> option, etc. Maybe use word "shipped" or "root" instead. > >> > >> Everyone said they already do, and will continue to, > >> exec whatever shell they like, whether after login, > >> or by changing the entry. So in addition to the user > >> being ultimately responsible for their own box and usage, > >> this well announced entry for UPDATING cannot therein > >> really be responsible for any user self-shooting. > >> > >>> This is non-sense. > >> > >> Well, FreeBSD does not add every shell in base, > >> does not add every app to base, etc. > >> Some reasons for those limits should be obvious. > >> This update gives further distilling clarity by > >> limiting the number of shipped uid 0 entries to 1, > >> with that 1 being sh. > >> > >>> Every unix user should know that it's > >>> possible to changing the used shell by using > >>> chsh and this includes root. > >> > >> Then for every user, this update is not a problem. > >> > > > > I've been using UNIX both privately and professionally since 1984 > > and I must admit that I never heard of chsh before seeing this > > e-mail. I simply use vipw; it's the logical way to do this sort > > of thing IMHO. But I suppose that this is the way to go for users > > who don't have root access (which I always have). > > AFAIK only root can use vipw, while chsh is usable by all system users. > Which is pretty much what I wrote above. > Guess you've been root since 1984 :) > On the systems I've had control of, always. I started out with 4.2BSD running on a VAX, which didn't have chpass, so csh was the default. The VAX was used to cross-compile AT III/IV/V to run on Motorola CPUs. I always had full control of the target machines, although the Bourne shell was pretty much the only shell available then. After relocating for that employer from Berkeley to Germany I helped administer the VAX, so I had to have root access. Unfortunately, the german spinoff went tits up in 1989 and I decided to stay in Germany. And, no matter where I was employed after that, I was always able to get root access, which I never abused. But since 2000 I've administered my own FreeBSD machines at home as a freelancer (but I'm now retired), so root access is always required. -- Gary Jennejohn
Re: [HEADSUP] making /bin/sh the default shell for root
On Tue, 12 Oct 2021 06:59:00 -0400 grarpamp wrote: > > No. The system shell is supposed to make the system usable > > by the users. Actually, the real problem is that the easiest way > > to shoot one's own foot is by changing the language (say, the > > shell) spoken by default by FreeBSD. > > Well, the FreeBSD system speaks sh for its own use, this is clearly > documented as the shell called by init(8), and later by rc(8), > it should probably be the root:0 entry at least for consistancy. > No other shell is called by the FreeBSD system there. > Whatever the users want for their own shells is really up > to them to decide after that. > > "Default" is bit of low context word, as there is no falling > back to some shell occuring, no filling in for some missing > option, etc. Maybe use word "shipped" or "root" instead. > > Everyone said they already do, and will continue to, > exec whatever shell they like, whether after login, > or by changing the entry. So in addition to the user > being ultimately responsible for their own box and usage, > this well announced entry for UPDATING cannot therein > really be responsible for any user self-shooting. > > > This is non-sense. > > Well, FreeBSD does not add every shell in base, > does not add every app to base, etc. > Some reasons for those limits should be obvious. > This update gives further distilling clarity by > limiting the number of shipped uid 0 entries to 1, > with that 1 being sh. > > > Every unix user should know that it's > > possible to changing the used shell by using > > chsh and this includes root. > > Then for every user, this update is not a problem. > I've been using UNIX both privately and professionally since 1984 and I must admit that I never heard of chsh before seeing this e-mail. I simply use vipw; it's the logical way to do this sort of thing IMHO. But I suppose that this is the way to go for users who don't have root access (which I always have). > > BTW, toor default to sh, not tcsh. > > No one said that the toor entry does not use sh. > -- Gary Jennejohn
Re: [HEADSUP] making /bin/sh the default shell for root
On Wed, 22 Sep 2021 08:52:53 -0700 (PDT) "Rodney W. Grimes" wrote: > > On Wed, Sep 22, 2021 at 08:34:58AM -0700, John Baldwin wrote: > > > On 9/22/21 1:36 AM, Baptiste Daroussin wrote: > > > > Hello, > > > > > > > > TL;DR: this is not a proposal to deorbit csh from base!!! > > > > > > > > For years now, csh is the default root shell for FreeBSD, csh can be > > > > confusing > > > > as a default shell for many as all other unix like settled on a bourne > > > > shell > > > > compatible interactive shell: zsh, bash, or variant of ksh. > > > > > > > > Recently our sh(1) has receive update to make it more user friendly in > > > > interactive mode: > > > > * command completion (thanks pstef@) > > > > * improvement in the emacs mode, to make it behave by default like > > > > other shells > > > > * improvement in the vi mode (in particular the vi edit to respect > > > > $EDITOR) > > > > * support for history as described by POSIX. > > > > > > > > This makes it a usable shell by default, which is why I would like to > > > > propose to > > > > make it the default shell for root starting FreeBSD 14.0-RELEASE (not > > > > MFCed) > > > > > > > > If no strong arguments has been raised until October 15th, I will make > > > > this > > > > proposal happen. > > > > > > > > Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE! > > > > > > I think this is fine. I would also be fine with either removing 'toor' > > > from the > > > default password file or just leaving it as-is for POLA. (I would > > > probably > > > prefer removing it outright.) > > > > HardenedBSD recently removed toor. No one has complained (yet?). A > > small Twitter poll[0] showed that 85% of people who responded do not > > use toor. > > A truely disastisified customer does not complain, they simply > go some place else for there products. Be carefull in what you > believe silence to be saying. > I use toor on every FreeBSD machine as the root login using bash. I never log in as root. But removing it wouldn't be a deal breaker for me. I'd just put it back into /etc/passwd. > > > > [0]: https://twitter.com/HardenedBSD/status/1415781911063056389 > > > > Thanks, > > > > -- > > Shawn Webb > > Cofounder / Security Engineer > > HardenedBSD > > > > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > > > > -- > Rod Grimes rgri...@freebsd.org > -- Gary Jennejohn
Re: git commit for WITH_DETECT_TZ_CHANGES breaks date, et al
On Mon, 13 Sep 2021 21:30:02 -0400 Michael Butler via freebsd-current wrote: > After commit ddedf2a11eb20af1ee52cb3da70a57c21904af8f date fails to recognize > any configured timezone when WITH_DETECT_TZ_CHANGES is not set. > > For example .. > > imb@vm01:/home/imb> date > Tue Sep 14 01:25:57 2021 > > Every other daemon also thinks it's running in UTC+0 :-( > > When libc is recompiled with WITH_DETECT_TZ_CHANGES=yes in /etc/src.conf, the > output is (for me) .. > > imb@vm01:/usr/src/lib/libc> date > Mon Sep 13 21:28:29 EDT 2021 > Same here. After instaling the new world this morning I was suddenly in UTC instead of CEST (2 hours difference). Thanks for the fix :-) -- Gary Jennejohn
Re: OpenSSH issue: 14-Current rejects non-publickey scp/ssh/rsync connectiosn all of the sudden
On Fri, 10 Sep 2021 10:29:46 +0200 Gary Jennejohn wrote: > On Thu, 9 Sep 2021 19:37:39 -0400 > Ed Maste wrote: > > > On Thu, 9 Sept 2021 at 15:18, FreeBSD User wrote: > > > > > > /etc/ssh/sshd_config line 89: Unsupported option UsePAM > > > > Sorry, it turns out I had the wrong version of config.h in my commit. > > > > I'm running a build now and will commit it once a test with that > > change passes. I will look into all of the reported issues, but I'd be > > much obliged if you can rebuild sshd and try again (once the config.h > > commit lands). > > > > This is interesting. > > Was the config.h in the patch the same as the one you committed? > > When I ran my tests one machine was running the new ssh (from the > patch) and the other was running the old ssh, and I didn't have any > connection errors. > I now have two HEAD systems running the latest world and ssh works again. Yay! -- Gary Jennejohn
compile failure in /usr/src/stand/libsa
So, a new problem with buildworld in HEAD.
Building in /usr/src/stand/libsa fails because dosfs.c, ufs.c and
geli/gelidev.c can't find disk.h. But disk.h is located in ../common.
I had to modify all three of these files to get the compile to finish
by using ../common/disk.h.
In /usr/src/stand/defs.mk I find LDRSRC= ${BOOTSRC}/common and defs.mk
is included in /usr/src/stand/Makefile.inc. So it seems like the C-files
under libsa should find the includes.
However, I'm not sure whether LDSRC is the correct value to be using
in defs.mk, because I'm not sure what it means.
I saw this error on two different machines with the latst HEAD tree.
--
Gary Jennejohn
Re: error installing stand/i386/loader_4th in HEAD
On Thu, 9 Sep 2021 10:37:30 -0600 Warner Losh wrote: > On Thu, Sep 9, 2021, 10:03 AM Gary Jennejohn wrote: > > > On Thu, 9 Sep 2021 09:07:08 -0600 > > Warner Losh wrote: > > > > > On Thu, Sep 9, 2021, 7:11 AM Gary Jennejohn > > wrote: > > > > > > > I got a very strange error while trying to make installworld on HEAD: > > > > > > > > stand/i386/loader_4th (install) > > > > /tmp/install.rIhHqnPC/sh: cc not found > > > > *** Error code 127 > > > > > > > > This from a tree which I updated at 08:37 UTC. According to uname -a > > > > the tree is at commit main-n249276-fc29a8b9d95. > > > > > > > > I booted the new kernel from this tree. > > > > > > > > I've never seen this error before. Why in the world would install need > > > > cc? > > > > > > > > > > The usual cause of this error is time skew. There were some build issues > > > that I've fixed that I was sure I merged to stable/13, but I'll check > > > when I get home. > > > > > > > Thanks. I'll check the times set under /usr/src and /usr/obj. > > > > If you have a reliable way to reproduce this, I'd be quite interested if > it isn't a typical "oops" on dates > Well, the dates under /usr/obj are all more recent than under /usr/src/stand/i386/loader_4th. Seems like installworld should not fail the installation based on the dates alone. Since I'm having probelms with ssh I'm going to update the tree and do a buildworld. I'll see what happens after that. -- Gary Jennejohn
Re: OpenSSH issue: 14-Current rejects non-publickey scp/ssh/rsync connectiosn all of the sudden
On Thu, 9 Sep 2021 19:37:39 -0400 Ed Maste wrote: > On Thu, 9 Sept 2021 at 15:18, FreeBSD User wrote: > > > > /etc/ssh/sshd_config line 89: Unsupported option UsePAM > > Sorry, it turns out I had the wrong version of config.h in my commit. > > I'm running a build now and will commit it once a test with that > change passes. I will look into all of the reported issues, but I'd be > much obliged if you can rebuild sshd and try again (once the config.h > commit lands). > This is interesting. Was the config.h in the patch the same as the one you committed? When I ran my tests one machine was running the new ssh (from the patch) and the other was running the old ssh, and I didn't have any connection errors. -- Gary Jennejohn
Re: error installing stand/i386/loader_4th in HEAD
On Thu, 9 Sep 2021 09:07:08 -0600 Warner Losh wrote: > On Thu, Sep 9, 2021, 7:11 AM Gary Jennejohn wrote: > > > I got a very strange error while trying to make installworld on HEAD: > > > > stand/i386/loader_4th (install) > > /tmp/install.rIhHqnPC/sh: cc not found > > *** Error code 127 > > > > This from a tree which I updated at 08:37 UTC. According to uname -a > > the tree is at commit main-n249276-fc29a8b9d95. > > > > I booted the new kernel from this tree. > > > > I've never seen this error before. Why in the world would install need > > cc? > > > > The usual cause of this error is time skew. There were some build issues > that I've fixed that I was sure I merged to stable/13, but I'll check > when I get home. > Thanks. I'll check the times set under /usr/src and /usr/obj. -- Gary Jennejohn
error installing stand/i386/loader_4th in HEAD
I got a very strange error while trying to make installworld on HEAD: stand/i386/loader_4th (install) /tmp/install.rIhHqnPC/sh: cc not found *** Error code 127 This from a tree which I updated at 08:37 UTC. According to uname -a the tree is at commit main-n249276-fc29a8b9d95. I booted the new kernel from this tree. I've never seen this error before. Why in the world would install need cc? Note that I copied the contents of /usr/src/etc/mtree to /etc/mtree before starting the installation. -- Gary Jennejohn
Re: -CURRENT compilation time
On Wed, 8 Sep 2021 09:57:50 +0100 David Chisnall wrote: > On 07/09/2021 18:02, Stefan Esser wrote: > > Wouldn't this break META_MODE? > > I have never managed to get META_MODE to work but my understanding > is that META_MODE is addressing a problem that doesn't really exist > in any other build system that I've used: that dependencies are not > properly tracked. > META_MODE requires filemon(4) to be in the kernel or loaded as a module. make(1) will use if it's available with .MAKE.MODE=meta. > When I do a build of LLVM with the upstream build system with no > changes, it takes Ninja approximately a tenth of a second to stat > all of the relevant files and tell me that I have no work to do. > META_MODE apparently lets the FreeBSD build system extract these > dependencies and do something similar, but it's not enabled by > default and it's difficult to make work. > > > I'd rather be able to continue building the world within a few > > minutes (generally much less than 10 minutes, as long as there is > > no major LLVM upgrade) than have a faster LLVM build and then a > > slower build of the world ... > > The rest of this thread has determined that building LLVM accounts > for half of the build time in a clean FreeBSD build. LLVM's CMake > is not a great example: it has been incrementally improved since > CMake 2.8 and doesn't yet use any of the modern CMake features that > allow encapsulating targets and providing import / export > configurations. > > In spite of that, it generates a ninja file that compiles > *significantly* faster than the bmake-based system in FreeBSD. In > other projects that I've worked on with a similar-sized codebase to > FreeBSD that use CMake + Ninja, I've never had the same problems > with build speed that I have with FreeBSD. > > Working on LLVM, I generally spend well under 10% of my time either > waiting for builds or fighting the build system. Working on > FreeBSD, I generally spend over 90% of my time waiting for builds or > fighting the build system. This means that my productivity > contributing to FreeBSD is almost zero. > > For reference, changes to LLVM typically build for me in under 30 > seconds with Ninja, unless I've changed a header that everything > > In particular, building FreeBSD on a 10-24 core machine has very > long periods where a number of the cores are completely idle. > > Ninja also has a few other nice features that improve performance > relative to bmake: > > - It lets you put jobs in different pools. In LLVM this is used to > put link and compile jobs in different pools because linking with > LLD uses multiple threads and a lot more memory than compilation, so > a 10-core machine may want to do 12 compile jobs in parallel but > only 2 link jobs. This makes it much easier to completely saturate > the machine. > - Ninja provides each parallel build task with a separate pipe for > stdout and stderr, and does not print their output unless a build > step fails (or unless you build with -v). With bmake, if a parallel > build fails I have to rerun the build without -j, because the output > is interleaved with succeeding jobs and it's difficult to see what > actually failed. With ninja, the output is from each failed job, > with no interleaving. > ninja sounds really neat and it's available as /usr/ports/devel/ninja. Seems to me that there was an earlier mail about getting CMAKE to work with FreeBSD builds. Could be worthwhile to look into getting ninja to work also. But I could understand that there might be push-back, since the project prefers to use utilities from the source tree. -- Gary Jennejohn
Re: dumpdev AUTO in rc.conf does not work
On Mon, 09 Aug 2021 17:17:00 + "Dave Cottlehuber" wrote: > On Mon, 9 Aug 2021, at 15:54, Gary Jennejohn wrote: > > Maybe his problem arises from use of /dev/gpt/swap? That's a difference > > between his setup and your setup. > > good point, after amending fstab and checking gpt labels carefully, it still > works ok for me: > > root@a01 /u/h/dch# gpart show > => 40 97677232 da0 GPT (47G) > 405324801 efi (260M) > 532520 2008 - free - (1.0M) > 534528 83886082 freebsd-swap (4.0G) >8923136 887541363 freebsd-zfs (42G) > > root@a01 /u/h/dch# grep swap /etc/fstab > /dev/gpt/swap0 noneswapsw 0 > 0 > > root@a01 /u/h/dch# swapinfo > Device 512-blocks UsedAvail Capacity > /dev/gpt/swap0 83886080 8388608 0% > > root@a01 /u/h/dch# sysrc dumpdev > dumpdev: AUTO > > root@a01 /u/h/dch# dumpon -l > gpt/swap0 > Thanks! Very useful information. > I do have these set in loader.conf, though, switching them off makes > no difference: > > root@a01 /u/h/dch# grep geom /boot/loader.conf > kern.geom.label.disk_ident.enable="0" > kern.geom.label.gptid.enable="0" > These are the default values - well, on amd64 they are: sysctl kern.geom.label kern.geom.label.disk_ident.enable: 0 kern.geom.label.gptid.enable: 0 kern.geom.label.gpt.enable: 1 kern.geom.label.ufs.enable: 1 kern.geom.label.ufsid.enable: 1 kern.geom.label.reiserfs.enable: 1 kern.geom.label.ntfs.enable: 1 kern.geom.label.msdosfs.enable: 1 kern.geom.label.iso9660.enable: 1 kern.geom.label.flashmap.enable: 1 kern.geom.label.ext2fs.enable: 1 kern.geom.label.debug: 0 -- Gary Jennejohn
Re: dumpdev AUTO in rc.conf does not work
On Mon, 09 Aug 2021 15:45:19 + "Dave Cottlehuber" wrote: > On Mon, 9 Aug 2021, at 06:54, Gary Jennejohn wrote: > > On Sun, 8 Aug 2021 18:01:18 -0400 > > Daniel Morante via freebsd-current wrote: > > > It looks though that this issue might only happen on arm64? I tried > > > to reproduce on amd64 without any luck. > > seems fine on arm64 14.0-CURRENT to me, this is built from src today BTW: > > root@a01 /u/h/dch# gpart show > => 40 97677232 da0 GPT (47G) > 405324801 efi (260M) > 532520 2008 - free - (1.0M) > 534528 83886082 freebsd-swap (4.0G) >8923136 887541363 freebsd-zfs (42G) > > root@a01 /u/h/dch# swapinfo -h > Device Size UsedAvail Capacity > /dev/da0p2 4.0G 0B 4.0G 0% > > root@a01 /u/h/dch# dumpon -l > da0p2 > > root@a01 /u/h/dch# sysrc dumpdev > dumpdev: AUTO > > root@a01 /u/h/dch# grep swap /etc/fstab > /dev/da0p2noneswapsw 0 > Maybe his problem arises from use of /dev/gpt/swap? That's a difference between his setup and your setup. > root@a01 /u/h/dch# grep -i dump /etc/rc.conf > # Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable > dumpdev=AUTO > > root@a01 /u/h/dch# uname -a > FreeBSD a01.cabal5.net 14.0-CURRENT FreeBSD 14.0-CURRENT > main-n248554-66b8eced972 GENERIC arm64 > > I've not got geli or gbde encrypted swap enabled, though, happy to > try that out later. > -- Gary Jennejohn
Re: dumpdev AUTO in rc.conf does not work
On Sun, 8 Aug 2021 18:01:18 -0400 Daniel Morante via freebsd-current wrote: > Yes my fstab entry is: > > /dev/gpt/swap none > swap sw > 0 0 > > It looks though that this issue might only happen on arm64? I tried > to reproduce on amd64 without any luck. > Could be. I also tested it on amd64. I don't have any arm64 boxes. Maybe you could try the test with /bin/sh -x like I did and send the output to current@. Someone might be able to figure out what's causing the problem. > On 8/8/2021 3:03 AM, Gary Jennejohn wrote: > > On Sat, 7 Aug 2021 20:10:50 -0400 > > Daniel Morante via freebsd-current wrote: > > > > >> Hello, > >> > >> I am running 14.0-CURRENT using the snapshot from 2021-08-05.__ It loo > ks > >> as if setting dumpdev="AUTO" in /etc/rc.conf has no effect on enabli > ng > >> kernel crash dumps. > >> > >> root@callisto:~ # uname -a > >> FreeBSD callisto 14.0-CURRENT FreeBSD 14.0-CURRENT #0 > >> main-n248478-f3a3b061216: Thu Aug__ 5 06:03:20 UTC 2021 root@releng > >> 1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 > >> > >> root@callisto:~ # swapinfo -h > >> DeviceSize Used Avail Capacity > >> /dev/gpt/swap 30G030G0% > >> > >> root@callisto:~ # dumpon -l > >> /dev/null > >> > >> root@callisto:~ # sysrc dumpdev > >> dumpdev: AUTO > >> > >> I have to manually enable it via dumpon even though it's set to AUTO i > n__ > >> rc.conf > >> > >> root@callisto:~ # dumpon /dev/gpt/swap > >> root@callisto:~ # dumpon -l > >> gpt/swap > >> > > Works for me if I set dumpdev to AUTO. > > > > I ran '/bin/sh -x dumpon start' and it found the swap entry in /etc/fst > ab, > > as expected. > > > > Does your /etc/fstab entry for swap have the correct syntax? Mine look > s > > like this: > > /dev/ada0p5 noneswapsw 0 0 > > > -- Gary Jennejohn
Re: dumpdev AUTO in rc.conf does not work
On Sat, 7 Aug 2021 20:10:50 -0400 Daniel Morante via freebsd-current wrote: > Hello, > > I am running 14.0-CURRENT using the snapshot from 2021-08-05.__ It looks > as if setting dumpdev="AUTO" in /etc/rc.conf has no effect on enabling > kernel crash dumps. > > root@callisto:~ # uname -a > FreeBSD callisto 14.0-CURRENT FreeBSD 14.0-CURRENT #0 > main-n248478-f3a3b061216: Thu Aug__ 5 06:03:20 UTC 2021 root@releng > 1.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 > > root@callisto:~ # swapinfo -h > DeviceSize Used Avail Capacity > /dev/gpt/swap 30G030G0% > > root@callisto:~ # dumpon -l > /dev/null > > root@callisto:~ # sysrc dumpdev > dumpdev: AUTO > > I have to manually enable it via dumpon even though it's set to AUTO in__ > rc.conf > > root@callisto:~ # dumpon /dev/gpt/swap > root@callisto:~ # dumpon -l > gpt/swap > Works for me if I set dumpdev to AUTO. I ran '/bin/sh -x dumpon start' and it found the swap entry in /etc/fstab, as expected. Does your /etc/fstab entry for swap have the correct syntax? Mine looks like this: /dev/ada0p5 noneswapsw 0 0 -- Gary Jennejohn
Re: boot hangs after installworld at FreeBSD 14.0-CURRENT main-n248198-72f7ddb587a
On Mon, 26 Jul 2021 08:19:41 +0200 Gary Jennejohn wrote: > On Sun, 25 Jul 2021 19:02:29 +0200 > Gary Jennejohn wrote: > > > On Sun, 25 Jul 2021 09:54:35 -0600 > > Warner Losh wrote: > > > > > On Sun, Jul 25, 2021 at 3:30 AM Gary Jennejohn > > > wrote: > > > > > > > I updated my FBSD-14 tree yesterday. > > > > > > > > uname -a shows FreeBSD 14.0-CURRENT #5 main-n248198-72f7ddb587a. > > > > > > > > Did a buildkernel and a clean buildworld yesterday. > > > > > > > > This morning I booted the new kernel, did an installworld and rebooted > > > > the new kernel. > > > > > > > > Or, should I say, I tried to reboot the new kernel. > > > > > > > > During boot I see the following outptut: > > > > > > > > loading /boot/defaults/loader.conf > > > > / > > > > > > > > and the boot hangs. > > > > > > > > The second line should have contained > > > > /boot/test/kernel (I always install new kernels to /boot/test) > > > > > > > > followed by lines containing the various modules which get loaded. > > > > > > > > Luckily, I had a USB thumb drive with a FreeBSD memstick.img AND a > > > > complete backup of the old /boot, so I could boot from the thumb > > > > drive and restore /boot (but I moved /boot to /boot.bad before I > > > > did that just in case). With the restored (old) /boot everything > > > > works. > > > > > > > > > > Little has changed in the boot loader. Do you know the hash that worked? > > > Or > > > if I misread above, the has that failed? > > > > > > > The /boot code which works was installed at 07:36 UTC July 9th. So, > > every change to the boot code since then is a culprit. > > > > Example: 9c1c02093b90ae49745a174eb26ea85dd1990eec change to support.4th. > > It just so happens that I had a nextboot.conf in the "bad" /boot at the > > time that the hang occurred. This is the only potential candidate I > > can see. > > > > So I'll try overwriting support.4th with the known-good version and > > see what happens. But probably not until tomorrow my time. > > > > After deleting the nextboot.conf from the "bad" /boot I was able to > boot using the "bad" /boot. That's the only change between this boot > and the previous boot which hung the computer. Whether this is a > strong hint that the change to support.4th is the culprit I can't say, > but since the commit message explicitly mentions nextboot.conf as a > reason for the change, that may very well be the case. > > I decided that removing nextboot.conf was a better test than using > the old support.4th. > > The change looks very simple and innocent, but my 4th knowledge is > pretty much non-existent, so I don't really understand what it does. > > I went back to the "old" /boot because I use nextboot.conf a lot. > I decided to do a further test. I wanted to check whether some other change in the loader might be implicated in the hung boot. I copied the old support.4th to the bad /boot (/boot.b). I then mv'd /boot to /boot.g and /boot.b to /boot and created a nextboot.conf there. After these steps I was still able to boot successfully. So, I'd say that this result is a pretty strong indication that the new support.4th together with a nextboot.conf results in the hung boot. -- Gary Jennejohn
Re: boot hangs after installworld at FreeBSD 14.0-CURRENT main-n248198-72f7ddb587a
On Sun, 25 Jul 2021 19:02:29 +0200 Gary Jennejohn wrote: > On Sun, 25 Jul 2021 09:54:35 -0600 > Warner Losh wrote: > > > On Sun, Jul 25, 2021 at 3:30 AM Gary Jennejohn wrote: > > > > > I updated my FBSD-14 tree yesterday. > > > > > > uname -a shows FreeBSD 14.0-CURRENT #5 main-n248198-72f7ddb587a. > > > > > > Did a buildkernel and a clean buildworld yesterday. > > > > > > This morning I booted the new kernel, did an installworld and rebooted > > > the new kernel. > > > > > > Or, should I say, I tried to reboot the new kernel. > > > > > > During boot I see the following outptut: > > > > > > loading /boot/defaults/loader.conf > > > / > > > > > > and the boot hangs. > > > > > > The second line should have contained > > > /boot/test/kernel (I always install new kernels to /boot/test) > > > > > > followed by lines containing the various modules which get loaded. > > > > > > Luckily, I had a USB thumb drive with a FreeBSD memstick.img AND a > > > complete backup of the old /boot, so I could boot from the thumb > > > drive and restore /boot (but I moved /boot to /boot.bad before I > > > did that just in case). With the restored (old) /boot everything > > > works. > > > > > > > Little has changed in the boot loader. Do you know the hash that worked? Or > > if I misread above, the has that failed? > > > > The /boot code which works was installed at 07:36 UTC July 9th. So, > every change to the boot code since then is a culprit. > > Example: 9c1c02093b90ae49745a174eb26ea85dd1990eec change to support.4th. > It just so happens that I had a nextboot.conf in the "bad" /boot at the > time that the hang occurred. This is the only potential candidate I > can see. > > So I'll try overwriting support.4th with the known-good version and > see what happens. But probably not until tomorrow my time. > After deleting the nextboot.conf from the "bad" /boot I was able to boot using the "bad" /boot. That's the only change between this boot and the previous boot which hung the computer. Whether this is a strong hint that the change to support.4th is the culprit I can't say, but since the commit message explicitly mentions nextboot.conf as a reason for the change, that may very well be the case. I decided that removing nextboot.conf was a better test than using the old support.4th. The change looks very simple and innocent, but my 4th knowledge is pretty much non-existent, so I don't really understand what it does. I went back to the "old" /boot because I use nextboot.conf a lot. -- Gary Jennejohn
