Re: change in /usr/bin/bc with CTRL-d no longer exit

[Warner Losh]

On Mon, Sep 16, 2024, 3:13 PM Cy Schubert  wrote:

> In message , void writes:
> > On Sun, Sep 15, 2024 at 03:16:46PM -0500, Dan Mack wrote:
> > >On 14.1 and prior, a CTRL-d will exit a bc session.
> > >
> > >Today I noticed that on 3 different 15-CURRENT systems, it appears to
> > >be ignored.  Works fine otherwise and I can exit the bc session with
> > >the 'quit' command okay.
> > >
> > >I re-tested this on the system console on fresh login just to rule out
> > >any terminal madness.
> > >
> > >Here's a paste of what I see:
> > >
> > >https://tpaste.us/VYya
> > >
> > >I did a fresh install of 14.1 and it works as it did previously.
> > >
> > >No biggie, just wondering if anyone else on -CURRENT can confirm/deny
> > >this change on their system.
> >
> > [void@vm5 ~ ] uname -KU
> > 1400504 1400504
> > [void@vm5 ~ ] echo 2+2 | bc -l
> > 4
> >
> > [void@vm3 ~ ] uname -KU
> > 1500023 1500023
> > [void@vm3 ~ ] echo 2+2 | bc -l
> > 4
>
> Of course the above works because the regression only affects tty users.
> bc(1) now ignores EOF on the terminal while the above still works. You can
> circumvent this by putting "export BC_TTY_MODE=0" into your .profile. The
> side effect is that line editing will no longer work.
>

The irony here is that i fixed thus very bug 2 or 3 years ago.

Warner

> --
> Cheers,
> Cy Schubert 
> FreeBSD UNIX: Web:  https://FreeBSD.org
> NTP:   Web:  https://nwtime.org
>
> e^(i*pi)+1=0
>
>
>
>

Re: Loader needs to be updated message

[Warner Losh]

On Sun, Sep 8, 2024, 10:51 AM void  wrote:

> On Sun, Sep 08, 2024 at 09:14:50AM -0600, Warner Losh wrote:
> >On Sun, Sep 8, 2024, 7:50 AM void  wrote:
> >>
> >> Do you think a source upgrade on the server would fix the issue?
> >>
> >Yes. But the warning at this time isn't super urgent for you. It is
> telling
> >you of problems in the future.
>
> Can confirm - the error message is no longer present on the guest
> after source upgrade on the host.
>

Great. This warning is new so people keep things uptodate. There has been
minor breakage due to really old loader.efi not updating, but i backed that
silent (mostly) breakage and added the loud version thing you see now. It
shouldn't be that regular an occurrence... i wanted some warning to het
people to do something.

Warner


> TYVM :D
> --
>
>

Re: Loader needs to be updated message

[Warner Losh]

On Sun, Sep 8, 2024, 7:50 AM void  wrote:

> On Sat, Sep 07, 2024 at 09:34:27PM -0600, Warner Losh wrote:
> >
> >Yes. If you are getting the too old error, then there is a preupdate world
> >booting a stable/13 after my change I think.
> >
> >Warner
>
> So, on the server (15.0-CURRENT #0 n270917-5dbf886104b4: Thu Jul  4 )
>
> ls -lah /boot/gptzfsboot
> -r--r--r--  1 root wheel  172K Jul  4 17:26 /boot/gptzfsboot
>

Gptzfsboot is not relevant. Userboot.ko would be since that's what provides
the loader interfaces for bhyve.

In the VM (13.4-STABLE stable/13-n258323-e7b4f6e0c064 Sep 6)
>
> ls -lah /boot/gptzfsboot
> -r--r--r--  1 root  wheel   151K Sep  6 23:57 /boot/gptzfsboot
>
> to reiterate:- both these systems are root-on-zfs
>
> Do you think a source upgrade on the server would fix the issue?
>

Yes. But the warning at this time isn't super urgent for you. It is telling
you of problems in the future.

related: do you think i'd have avoided the issue if the guest was ufs only?
>

No. This is a host vs guest crossthreading that's unavoidable.

Warner

>

Re: Loader needs to be updated message

[Warner Losh]

On Sat, Sep 7, 2024, 9:24 PM Tomoaki AOKI  wrote:

> On Sat, 7 Sep 2024 19:52:53 -0700
> Mark Millard  wrote:
>
> > Tomoaki AOKI  wrote on
> > Date: Sun, 08 Sep 2024 01:54:28 UTC :
> >
> > > On Sun, 8 Sep 2024 02:01:02 +0100
> > > void  wrote:
> > >
> > > > On Sun, Sep 08, 2024 at 09:23:02AM +0900, Tomoaki AOKI wrote:
> > > >
> > > > . . .
> > >
> > > If not automounted, you can mount ESP manually as msdosfs there, at
> > > least for bare-metal host. IIUC, recent installation by bsdinstall
> > > creates fstab entry for it by default.
> >
> > void previously reported:
> >
> > QUOTE
> > # gpart list | grep -E '(Name|type|efi|media)'
> > 1. Name: vtbd0p1
> > efimedia: HD(1,GPT,b7731537-61da-11ed-9652-00a0981073a7,0x28,0x400)
> > rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
> > type: freebsd-boot
> > 2. Name: vtbd0p2
> > efimedia: HD(2,GPT,b77a2687-61da-11ed-9652-00a0981073a7,0x800,0x200)
> > rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
> > type: freebsd-swap
> > 3. Name: vtbd0p3
> > efimedia:
> HD(3,GPT,b7836ca4-61da-11ed-9652-00a0981073a7,0x2000800,0xdfff000)
> > rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
> > type: freebsd-zfs
> > 1. Name: vtbd0
> > END QUOTE
> >
> > There is no ESP present in the guest. Instead there is a
> > "type: freebsd-boot" partition for which one of the likes of:
> >
> > # ls -lodT /boot/gpt*boot*
> > -r--r--r--  1 root wheel uarch  62139 Apr  7 15:55:46 2024 /boot/gptboot
> > -r-xr-xr-x  1 root wheel uarch 109568 Apr  7 15:55:46 2024
> /boot/gptboot.efi
> > -r--r--r--  1 root wheel uarch 176062 Apr  8 01:15:54 2024
> /boot/gptzfsboot
> >
> > would be in use. None of the 3 support the combination EFI and
> > ZFS-for-root-file-system. The only one of those 3 supporting zfs
> > is: gptzfsboot
> > It is documented to only supports old style BIOS context:
> >
> > "man 8 gptzfsboot" indicates "gptzfsboot is used on BIOS-based
> > computers to boot from a filesystem in a ZFS pool".
> >
> > gptboot and gptboot.efi only support UFS according to their man
> > pages.
> >
> > If EFI is in use, then the ESP-ish partition is not from the guest
> > context but from some place else --unless the man pages are wildly
> > wrong about what is supported for the gpt*boot 's.
> >
> > ===
> > Mark Millard
> > marklmi at yahoo.com
>
> Ah, I've overlooked that. Thanks.
> So boot1.efi is not usable here just as gptboot.efi.
> gptzfsboot is the only bootcode for freebsd-boot partition on GPT which
> supports ZFS, and corresponding loader WAS zfsloader but IIRC ZFS
> support IS now incorporated into loader[_lua|_4th].
>

Yes. If you are getting the too old error, then there is a preupdate world
booting a stable/13 after my change I think.

Warner

-- 
> Tomoaki AOKI
>
>

Re: Loader needs to be updated message

[Warner Losh]

On Sat, Sep 7, 2024, 9:16 PM Tomoaki AOKI  wrote:

> On Sat, 7 Sep 2024 19:38:47 -0700
> Mark Millard  wrote:
>
> > void  wrote on
> > Date: Sat, 07 Sep 2024 17:27:00 UTC :
> >
> > > On Sat, Sep 07, 2024 at 08:20:07AM -0700, Mark Millard wrote:
> > >
> > > >I'm more interested in what is there than just what is not
> > > >there. May be show something analogous to:
> > > >
> > > ># gpart list | grep -E '(Name|type|efi|media)'
> > > >1. Name: mmcsd1s1
> > > > efimedia: HD(1,MBR,,0x8000,0x3b68000)
> > > > rawtype: 12
> > > > type: fat32lba
> > > >1. Name: mmcsd1
> > > >1. Name: da0p1
> > > > efimedia: HD(1,GPT,81f199f2-5eb9-11ec-b507-a0cec8d68fdc,0x28,0x82000)
> > > > rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b
> > > > label: BPIM3efi
> > > > type: efi
> > > >2. Name: da0p2
> > > > efimedia:
> HD(2,GPT,efa6f52d-c8ca-11ec-bb1e-03fc0558c84f,0x82800,0x366000)
> > > > rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
> > > > type: freebsd-swap
> > > >3. Name: da0p3
> > > > efimedia:
> HD(3,GPT,71abc138-db5e-11ee-bfe1-e352d1095e3c,0x6861c800,0x732800)
> > > > rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
> > > > type: freebsd-swap
> > > >4. Name: da0p4
> > > > efimedia:
> HD(4,GPT,b568945a-5eba-11ec-b507-a0cec8d68fdc,0xa1c800,0x67c0)
> > > > rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b
> > > > type: freebsd-ufs
> > > >1. Name: da0
> > > >
> > > >I'll note that on various type of systems, the (effectively)
> > > >ESP need not be specifically of "type: efi", possibly some
> > > >fat variant instead also works. (Of course, EFI need not be
> > > >the only alternative for various type of contexts.)
> > > >
> > > >I'll note the /boot/efi is normally just an empty directory
> > > >that is possibly used as a mount point.
> > > >
> > > >In some (somewhat older) configurations /boot/msdos is
> > > >similarly an empty directory and possibly used as the mount
> > > >point instead.
> > > >
> > > >> After source building to latest stable in the usual way, same error
> message 'loader needs updating'.
> > >
> > > This is on the guest
> > >
> > > # gpart list | grep -E '(Name|type|efi|media)'
> > > 1. Name: vtbd0p1
> > > efimedia: HD(1,GPT,b7731537-61da-11ed-9652-00a0981073a7,0x28,0x400)
> > > rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
> > > type: freebsd-boot
> >
> > As I understand it, that "type: freebsd-boot" means that one of
> > the likes of:
> >
> > # ls -lodT /boot/gpt*boot*
> > -r--r--r--  1 root wheel uarch  62139 Apr  7 15:55:46 2024 /boot/gptboot
> > -r-xr-xr-x  1 root wheel uarch 109568 Apr  7 15:55:46 2024
> /boot/gptboot.efi
> > -r--r--r--  1 root wheel uarch 176062 Apr  8 01:15:54 2024
> /boot/gptzfsboot
> >
> > is in use inside that freebsd-boot partition (vtbd0p1). But only
> > one of those supports zfs.
> >
> > Fair warning that I never use any of those 3 --nor freebsd-boot
> > partitions. Nor have I ever used Bhyve. Do not blindly believe what I
> > report here. But hopefully it points in a useful direction to
> > initially investigate.
> >
> > Looking at:
> >
> > "man 8 gptboot.efi" indicates that "gptboot.efi works only with UFS
> > root file systems".
> >
> > "man 8 gptboot" indicates that "gptboot is used on BIOS-based
> > computers to boot from a UFS partition on a GPT-partitioned disk".
> >
> > BUT "man 8 gptzfsboot" indicates "gptzfsboot is used on BIOS-based
> > computers to boot from a filesystem in a ZFS pool".
> >
> > So the partitioning is not set up for supporting the combination of:
> > EFI and ZFS-for-root-filesystem: if the gptzfsboot is used then it
> > needs to be old style BIOS-and-ZFS for the context.
> >
> > So my expectation here is that the gptzfsboot content in use in
> > vtbd0p1 (i.e. -i 1 vtbd0 in some commands) is out of date and needs
> > to be updated. To my knowledge, there is no simple technique to look
> > up the vintage present in -i 1 vtbd0 .
> >
> > I have no clue which of the following should be used for your context
> > to be sure that the content ends up up to date:
> >
> > The Protective MBR variant:
> > # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 vtbd0
> >
> > The variant for without the Protective MBR:
> > # gpart bootcode -p /boot/gptzfsboot -i 1 vtbd0
> >
> > Those commands are adjusted variations of what the man page's EXAMPLES
> > section shows, but not using the 2 example's ada0 notation.
> >
> > > 2. Name: vtbd0p2
> > > efimedia:
> HD(2,GPT,b77a2687-61da-11ed-9652-00a0981073a7,0x800,0x200)
> > > rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
> > > type: freebsd-swap
> > > 3. Name: vtbd0p3
> > > efimedia:
> HD(3,GPT,b7836ca4-61da-11ed-9652-00a0981073a7,0x2000800,0xdfff000)
> > > rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
> > > type: freebsd-zfs
> > > 1. Name: vtbd0
> >
> >
> > ===
> > Mark Millard
> > marklmi at yahoo.com
>
> FYI:
> boot1.efi works with ZFS. gptboot.efi is basically the one which
> stripped ZFS-related codes from boot1.efi.
>
> And IIUC, boot1.efi shares most codes with loader.efi (except for its
> own FS module wrap

Re: Loader needs to be updated message

[Warner Losh]

On Sat, Sep 7, 2024, 8:39 PM Mark Millard  wrote:

> void  wrote on
> Date: Sat, 07 Sep 2024 17:27:00 UTC :
>
> > On Sat, Sep 07, 2024 at 08:20:07AM -0700, Mark Millard wrote:
> >
> > >I'm more interested in what is there than just what is not
> > >there. May be show something analogous to:
> > >
> > ># gpart list | grep -E '(Name|type|efi|media)'
> > >1. Name: mmcsd1s1
> > > efimedia: HD(1,MBR,,0x8000,0x3b68000)
> > > rawtype: 12
> > > type: fat32lba
> > >1. Name: mmcsd1
> > >1. Name: da0p1
> > > efimedia: HD(1,GPT,81f199f2-5eb9-11ec-b507-a0cec8d68fdc,0x28,0x82000)
> > > rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b
> > > label: BPIM3efi
> > > type: efi
> > >2. Name: da0p2
> > > efimedia:
> HD(2,GPT,efa6f52d-c8ca-11ec-bb1e-03fc0558c84f,0x82800,0x366000)
> > > rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
> > > type: freebsd-swap
> > >3. Name: da0p3
> > > efimedia:
> HD(3,GPT,71abc138-db5e-11ee-bfe1-e352d1095e3c,0x6861c800,0x732800)
> > > rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
> > > type: freebsd-swap
> > >4. Name: da0p4
> > > efimedia:
> HD(4,GPT,b568945a-5eba-11ec-b507-a0cec8d68fdc,0xa1c800,0x67c0)
> > > rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b
> > > type: freebsd-ufs
> > >1. Name: da0
> > >
> > >I'll note that on various type of systems, the (effectively)
> > >ESP need not be specifically of "type: efi", possibly some
> > >fat variant instead also works. (Of course, EFI need not be
> > >the only alternative for various type of contexts.)
> > >
> > >I'll note the /boot/efi is normally just an empty directory
> > >that is possibly used as a mount point.
> > >
> > >In some (somewhat older) configurations /boot/msdos is
> > >similarly an empty directory and possibly used as the mount
> > >point instead.
> > >
> > >> After source building to latest stable in the usual way, same error
> message 'loader needs updating'.
> >
> > This is on the guest
> >
> > # gpart list | grep -E '(Name|type|efi|media)'
> > 1. Name: vtbd0p1
> > efimedia: HD(1,GPT,b7731537-61da-11ed-9652-00a0981073a7,0x28,0x400)
> > rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
> > type: freebsd-boot
>
> As I understand it, that "type: freebsd-boot" means that one of
> the likes of:
>
> # ls -lodT /boot/gpt*boot*
> -r--r--r--  1 root wheel uarch  62139 Apr  7 15:55:46 2024 /boot/gptboot
> -r-xr-xr-x  1 root wheel uarch 109568 Apr  7 15:55:46 2024
> /boot/gptboot.efi
> -r--r--r--  1 root wheel uarch 176062 Apr  8 01:15:54 2024 /boot/gptzfsboot
>
> is in use inside that freebsd-boot partition (vtbd0p1). But only
> one of those supports zfs.
>
> Fair warning that I never use any of those 3 --nor freebsd-boot
> partitions. Nor have I ever used Bhyve. Do not blindly believe what I
> report here. But hopefully it points in a useful direction to
> initially investigate.
>
> Looking at:
>
> "man 8 gptboot.efi" indicates that "gptboot.efi works only with UFS
> root file systems".
>
> "man 8 gptboot" indicates that "gptboot is used on BIOS-based
> computers to boot from a UFS partition on a GPT-partitioned disk".
>
> BUT "man 8 gptzfsboot" indicates "gptzfsboot is used on BIOS-based
> computers to boot from a filesystem in a ZFS pool".
>
> So the partitioning is not set up for supporting the combination of:
> EFI and ZFS-for-root-filesystem: if the gptzfsboot is used then it
> needs to be old style BIOS-and-ZFS for the context.
>

Yes

So my expectation here is that the gptzfsboot content in use in
> vtbd0p1 (i.e. -i 1 vtbd0 in some commands) is out of date and needs
> to be updated. To my knowledge, there is no simple technique to look
> up the vintage present in -i 1 vtbd0 .
>

No. The message is not from this. But gpart bootcode will update it. It
gets ugly only for MBR systems, not GPT ones. For MBR, there's a dd step.

I have no clue which of the following should be used for your context
> to be sure that the content ends up up to date:
>
> The Protective MBR variant:
> # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 vtbd0
>
> The variant for without the Protective MBR:
> # gpart bootcode -p /boot/gptzfsboot -i 1 vtbd0
>

These are likely fine, but won't stop the out of date message.

Warner

Those commands are adjusted variations of what the man page's EXAMPLES
> section shows, but not using the 2 example's ada0 notation.
>
> > 2. Name: vtbd0p2
> > efimedia: HD(2,GPT,b77a2687-61da-11ed-9652-00a0981073a7,0x800,0x200)
> > rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
> > type: freebsd-swap
> > 3. Name: vtbd0p3
> > efimedia:
> HD(3,GPT,b7836ca4-61da-11ed-9652-00a0981073a7,0x2000800,0xdfff000)
> > rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
> > type: freebsd-zfs
> > 1. Name: vtbd0
>
>
> ===
> Mark Millard
> marklmi at yahoo.com
>
>
>

Re: Loader needs to be updated message

[Warner Losh]

On Sat, Sep 7, 2024 at 12:24 PM void  wrote:

> On Sat, Sep 07, 2024 at 11:47:12AM -0600, Warner Losh wrote:
> >Wait. On the guest?
> >
> >Then what's the VM system you're using?
> >
> >Warner
>
> Bhyve.
>
> The server is freebsd-current. The guest is 13.2-stable.
> I see the error in the ascii beastie menu when booting the guest
> with vmrun.sh
>

Hmmm, So somehow we're using the guest's boot loader and
the host's /boot/lua files then, I think. Uggg.

Warner

Re: Loader needs to be updated message

[Warner Losh]

Wait. On the guest?

Then what's the VM system you're using?

Warner

On Sat, Sep 7, 2024 at 11:27 AM void  wrote:

> On Sat, Sep 07, 2024 at 08:20:07AM -0700, Mark Millard wrote:
>
> >I'm more interested in what is there than just what is not
> >there. May be show something analogous to:
> >
> ># gpart list |  grep -E '(Name|type|efi|media)'
> >1. Name: mmcsd1s1
> >   efimedia: HD(1,MBR,,0x8000,0x3b68000)
> >   rawtype: 12
> >   type: fat32lba
> >1. Name: mmcsd1
> >1. Name: da0p1
> >   efimedia: HD(1,GPT,81f199f2-5eb9-11ec-b507-a0cec8d68fdc,0x28,0x82000)
> >   rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b
> >   label: BPIM3efi
> >   type: efi
> >2. Name: da0p2
> >   efimedia:
> HD(2,GPT,efa6f52d-c8ca-11ec-bb1e-03fc0558c84f,0x82800,0x366000)
> >   rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
> >   type: freebsd-swap
> >3. Name: da0p3
> >   efimedia:
> HD(3,GPT,71abc138-db5e-11ee-bfe1-e352d1095e3c,0x6861c800,0x732800)
> >   rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
> >   type: freebsd-swap
> >4. Name: da0p4
> >   efimedia:
> HD(4,GPT,b568945a-5eba-11ec-b507-a0cec8d68fdc,0xa1c800,0x67c0)
> >   rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b
> >   type: freebsd-ufs
> >1. Name: da0
> >
> >I'll note that on various type of systems, the (effectively)
> >ESP need not be specifically of "type: efi", possibly some
> >fat variant instead also works. (Of course, EFI need not be
> >the only alternative for various type of contexts.)
> >
> >I'll note the /boot/efi is normally just an empty directory
> >that is possibly used as a mount point.
> >
> >In some (somewhat older) configurations /boot/msdos is
> >similarly an empty directory and possibly used as the mount
> >point instead.
> >
> >> After source building to latest stable in the usual way, same error
> message 'loader needs updating'.
>
> This is on the guest
>
> # gpart list |  grep -E '(Name|type|efi|media)'
> 1. Name: vtbd0p1
> efimedia: HD(1,GPT,b7731537-61da-11ed-9652-00a0981073a7,0x28,0x400)
> rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
> type: freebsd-boot
> 2. Name: vtbd0p2
> efimedia:
> HD(2,GPT,b77a2687-61da-11ed-9652-00a0981073a7,0x800,0x200)
> rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
> type: freebsd-swap
> 3. Name: vtbd0p3
> efimedia:
> HD(3,GPT,b7836ca4-61da-11ed-9652-00a0981073a7,0x2000800,0xdfff000)
> rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
> type: freebsd-zfs
> 1. Name: vtbd0
>
> --
>
>

Re: Loader needs to be updated message

[Warner Losh]

On Fri, Sep 6, 2024, 8:44 AM void  wrote:

> On Fri, Sep 06, 2024 at 08:25:16AM -0600, Warner Losh wrote:
> >On Fri, Sep 6, 2024 at 8:13 AM void  wrote:
> >
> >> Hi,
> >>
> >> when booting -current (arm64) after building world & friends and
> rebooting,
> >> the beastie menu shows "Loader needs to be updated".
> >>
> >> I presume this to be gptzfsboot because the system is root-on-zfs.
> >>
> >> The issue I'm having is that I can't see in the manpage how to actually
> >> update it.
> >>
> >> The system uses GELI encryption for zfs. i don't want to break this.
> >>
> >
> >Loader, not boot. /boot/loader or loader.efi does not match (is older than
> >and doesn't has the wrong version) the lua scripts. That needs to be
> >updated.
> >
> >Almost always this means 'you didn't update the ESP' which usually isn't
> >a problem, but can be across major (or multiple major) releases.
> >
> >Warner
>
> Hi Warner,
>
> some more context which I'm sorry I forgot to add
>
> source upgrade on a rpi4 (arm64) from n271321-9ae91f59c500 (28th July) to
> n271832-04262ed78d23
> (today - this machine follows stablisation week)
>
> How is /boot/loader and/or loader.efi updated?
> What is ESP in this context?
>

man loader.efi has the instructions.

Warner

-- 
>
>
>

Re: Loader needs to be updated message

[Warner Losh]

On Fri, Sep 6, 2024 at 8:13 AM void  wrote:

> Hi,
>
> when booting -current (arm64) after building world & friends and rebooting,
> the beastie menu shows "Loader needs to be updated".
>
> I presume this to be gptzfsboot because the system is root-on-zfs.
>
> The issue I'm having is that I can't see in the manpage how to actually
> update it.
>
> The system uses GELI encryption for zfs. i don't want to break this.
>

Loader, not boot. /boot/loader or loader.efi does not match (is older than
and doesn't has the wrong version) the lua scripts. That needs to be
updated.

Almost always this means 'you didn't update the ESP' which usually isn't
a problem, but can be across major (or multiple major) releases.

Warner

Re: Anyone else seeing a stack of newline chars expressed at boot?

[Warner Losh]

On Mon, Sep 2, 2024 at 1:07 AM Dennis Clarke  wrote:

> On 9/1/24 19:28, Warner Losh wrote:
> > On Sun, Sep 1, 2024, 5:26 PM Dennis Clarke 
> wrote:
> >
> >>
> >> I have only been seeing this in the last few weeks. Perhaps ten days or
> >> so. When I see the nice beastie on the console I then get each second
> >> delay expressed with a newline thus :
> >>
> >>| |
> >>+-+
> >>  Autoboot in 10 seconds. [Space] to pause
> >>  Autoboot in 9 seconds. [Space] to pause
> >>  Autoboot in 8 seconds. [Space] to pause
> >>  Autoboot in 7 seconds. [Space] to pause
> >>  Autoboot in 6 seconds. [Space] to pause
> >>  Autoboot in 5 seconds. [Space] to pause
> >>  Autoboot in 4 seconds. [Space] to pause
> >>  Autoboot in 3 seconds. [Space] to pause
> >>  Autoboot in 2 seconds. [Space] to pause
> >>
> >> Seems odd.
> >>
> >> Curious if anyone else sees this?
> >>
> >
> > What kind of console?
> >
>
> Serial. Nothing fancy. The machine I use to watch the serial port is
> running 14.1-RELEASE-p3 and nothing fancy :
>
> callisto$
> callisto$ uname -a
> FreeBSD callisto 14.1-RELEASE-p3 FreeBSD 14.1-RELEASE-p3 GENERIC amd64
> callisto$
> callisto$ id
> uid=1001(admsys) gid=1001(admsys) groups=1001(admsys),0(wheel),68(dialer)
> callisto$
> callisto$ echo $TERM
> vt100
> callisto$
> callisto$ cu -s 38400 -l /dev/cuau0
> Connected
>
> triton#
> triton# uname -apKU
> FreeBSD triton 15.0-CURRENT FreeBSD 15.0-CURRENT #12
> main-n271936-0578fe492284-dirty: Sun Sep  1 22:52:43 GMT 2024
> root@triton:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 amd64
> 1500023 1500023
> triton#
> triton# echo $TERM
> vt100
> triton#
>
>
>
> So there we have it.
>

stty -a?

Warner


>
> --
> --
> Dennis Clarke
> RISC-V/SPARC/PPC/ARM/CISC
> UNIX and Linux spoken
>
>

Re: Anyone else seeing a stack of newline chars expressed at boot?

[Warner Losh]

On Sun, Sep 1, 2024, 5:26 PM Dennis Clarke  wrote:

>
> I have only been seeing this in the last few weeks. Perhaps ten days or
> so. When I see the nice beastie on the console I then get each second
> delay expressed with a newline thus :
>
>   | |
>   +-+
> Autoboot in 10 seconds. [Space] to pause
> Autoboot in 9 seconds. [Space] to pause
> Autoboot in 8 seconds. [Space] to pause
> Autoboot in 7 seconds. [Space] to pause
> Autoboot in 6 seconds. [Space] to pause
> Autoboot in 5 seconds. [Space] to pause
> Autoboot in 4 seconds. [Space] to pause
> Autoboot in 3 seconds. [Space] to pause
> Autoboot in 2 seconds. [Space] to pause
>
> Seems odd.
>
> Curious if anyone else sees this?
>

What kind of console?

Warner

--
> Dennis Clarke
> RISC-V/SPARC/PPC/ARM/CISC
> UNIX and Linux spoken
>
>

Re: buildworld error

[Warner Losh]

On Sun, Aug 25, 2024 at 4:23 AM Gordon Bergling  wrote:

> Hi Warner,
>
> On Sat, Aug 24, 2024 at 03:21:16PM -0600, Warner Losh wrote:
> > On Sat, Aug 24, 2024 at 1:39 PM Gordon Bergling  wrote:
> > > On Sat, Aug 24, 2024 at 01:29:55PM -0600, Warner Losh wrote:
> > > > On Sat, Aug 24, 2024, 1:14 PM Gordon Bergling 
> wrote:
> > > > > I got the following buildworld error a recent -CURRENT
> > > > >
> > > > > ===> stand/i386/pxeldr (all)
> > > > > `kldstat.o' is up to date.
> > > > > -14152 bytes available
> > > > >
> > > > > The same happens on stable/14:
> > > > >
> > > > > ===> stand/i386/pxeldr (all)
> > > > > -22344 bytes available
> > > > > ===> share/misc (all)
> > > > > --- loader ---
> > > > > *** [loader] Error code 1
> > > > >
> > > > > make[5]: stopped in
> /storage/freebsd/src/stable/14/stand/i386/pxeldr
> > > > > 1 error
> > > > >
> > > > > src.conf looks like the following:
> > > > > WITH_BEARSSL=1
> > > > > WITH_RETPOLINE=1
> > > > > WITHOUT_CLEAN=1
> > > > >
> > > > > I remove the whole obj directories and tried several full builds,
> but
> > > the
> > > > > error persists for a while.
> > > > >
> > > > > Has any one a clue how to solve this?
> > > >
> > > > Either disable pxe, raise the pxe limit (though it may not work), or
> > > select
> > > > the 4th loader for pxeboot.
> > > >
> > > > The loader is too big on BIOS to enable all the options.
> > >
> > > I looked at src.conf(5), but didn't found a switch to disable pxe.
> What I
> > > am
> > > wondering about is that no one is facing the problem, since this it is
> a
> > > pretty clean build without and special modifications, despite the ones
> > > mention
> > > above in the src.conf.
> > >
> > > Did you have a hint on how to disable pxe?
> > >
> >
> > I was sure that I'd documented everything, but it seems not:
> >
> > WITHOUT_LOADER_PXEBOOT=t
> > PXEBOOT_DEFAULT_INTERP=4th
> > PXEBOOTSIZE?=525000
> >
> > I'll look to make sure I don't have a commit stuck in a branch
> somewhere
>
> with this values in the src.conf(5) the build finally finished. But I
> wonder
> why I am the only person, who hits that problem since it is a very plain
> -CURRENT build on a Hyper-V instance.
>
> Should these values be default values?
>

You've enabled some big ticket items. It's not at all clear what the default
should be when people grow the loader too big. These options exist because
PXEBOOT larger than about 500k is know to be flakey, though there's no
universally known good upper limit since it depends a lot on the BIOS, what
it does, etc. So upping that limit is off the table (though one can if one
tests
it and finds that works). Some other people don't use PXE at all, so for
them, disabling it makes the most sense. Still others can't up the PXE
limit high enough, and for them, using the 4th loader is a good path
forward.

The other option is for someone to go through /boot/loader and shaving
some additional space. I've found all the easy, low-hanging fruit, plus
turning off all the esoteric filesystems got us down to almost fitting.

Warner

Re: buildworld error

[Warner Losh]

On Sat, Aug 24, 2024 at 1:39 PM Gordon Bergling  wrote:

> Hi Warner,
>
> On Sat, Aug 24, 2024 at 01:29:55PM -0600, Warner Losh wrote:
> > On Sat, Aug 24, 2024, 1:14 PM Gordon Bergling  wrote:
> > > I got the following buildworld error a recent -CURRENT
> > >
> > > ===> stand/i386/pxeldr (all)
> > > `kldstat.o' is up to date.
> > > -14152 bytes available
> > >
> > > The same happens on stable/14:
> > >
> > > ===> stand/i386/pxeldr (all)
> > > -22344 bytes available
> > > ===> share/misc (all)
> > > --- loader ---
> > > *** [loader] Error code 1
> > >
> > > make[5]: stopped in /storage/freebsd/src/stable/14/stand/i386/pxeldr
> > > 1 error
> > >
> > > src.conf looks like the following:
> > > WITH_BEARSSL=1
> > > WITH_RETPOLINE=1
> > > WITHOUT_CLEAN=1
> > >
> > > I remove the whole obj directories and tried several full builds, but
> the
> > > error persists for a while.
> > >
> > > Has any one a clue how to solve this?
> >
> > Either disable pxe, raise the pxe limit (though it may not work), or
> select
> > the 4th loader for pxeboot.
> >
> > The loader is too big on BIOS to enable all the options.
>
> I looked at src.conf(5), but didn't found a switch to disable pxe. What I
> am
> wondering about is that no one is facing the problem, since this it is a
> pretty clean build without and special modifications, despite the ones
> mention
> above in the src.conf.
>
> Did you have a hint on how to disable pxe?
>

I was sure that I'd documented everything, but it seems not:

WITHOUT_LOADER_PXEBOOT=t
PXEBOOT_DEFAULT_INTERP=4th
PXEBOOTSIZE?=525000

I'll look to make sure I don't have a commit stuck in a branch somewhere

Warner

Re: buildworld error

[Warner Losh]

On Sat, Aug 24, 2024, 1:14 PM Gordon Bergling  wrote:

> Hi folks,
>
> I got the following buildworld error a recent -CURRENT
>
> ===> stand/i386/pxeldr (all)
> `kldstat.o' is up to date.
> -14152 bytes available
>
> The same happens on stable/14:
>
> ===> stand/i386/pxeldr (all)
> -22344 bytes available
> ===> share/misc (all)
> --- loader ---
> *** [loader] Error code 1
>
> make[5]: stopped in /storage/freebsd/src/stable/14/stand/i386/pxeldr
> 1 error
>
> src.conf looks like the following:
> WITH_BEARSSL=1
> WITH_RETPOLINE=1
> WITHOUT_CLEAN=1
>
> I remove the whole obj directories and tried several full builds, but the
> error persists for a while.
>
> Has any one a clue how to solve this?


Either disable pxe, raise the pxe limit (though it may not work), or select
the 4th loader for pxeboot.

The loader is too big on BIOS to enable all the options.

Warner

--Gordon
>

Re: Panic on GENERIC @ 6481b4

[Warner Losh]

On Fri, Aug 16, 2024, 5:22 PM Kevin Oberman  wrote:

> On Tue, Aug 13, 2024 at 3:45 PM Warner Losh  wrote:
>
>>
>>
>> On Tue, Aug 13, 2024, 4:02 PM Alexander Ziaee 
>> wrote:
>>
>>> On 2024-08-13 17:51 -04:00 EDT, "Shawn Webb" 
>>> wrote:
>>> > On Tue, Aug 13, 2024 at 09:45:54PM UTC, Alexander Ziaee wrote:
>>>
>>> >> Compiling freebsd-current/generic at head commit 6481b4 on
>>> freebsd-current/generic from July 11th after a `make cleanworld` panics on
>>> bare metal boot on a thinkpad x230.
>>>
>>> > I had the same issue. I rebuilt/reinstalled the
>>> graphics/gpu-firmware-kmod and
>>> > graphics/drm-515-kmod ports. After a reboot, all was well.
>>>
>>> Cool, thanks Shawn!
>>>
>>> Should we put an entry in UPDATING when current will panic without the
>>> latest drm-kmod, or some other type of instruction somewhere?
>>>
>>
>> Every time you update the kernel, you must rebuild drm-kmod. If you don't
>> all bets are off.
>>
>> I have a different panic with the kernel from 20 minutes ago. Joy.
>>
>> Warner
>>
>> Best,
>>> Alex
>>>
>>
> I have long had PORTS_MODULES+= graphics/drm-61-kmod in /etc/src.conf.
> Thei does result in the module being rebuilt every time I build a kernel,
> but it assures that it will work on the boot of the new kernel.
>

It's the only way to be safe.

Warner

> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>

Re: Panic on GENERIC @ 6481b4

[Warner Losh]

On Tue, Aug 13, 2024, 4:02 PM Alexander Ziaee 
wrote:

> On 2024-08-13 17:51 -04:00 EDT, "Shawn Webb" 
> wrote:
> > On Tue, Aug 13, 2024 at 09:45:54PM UTC, Alexander Ziaee wrote:
>
> >> Compiling freebsd-current/generic at head commit 6481b4 on
> freebsd-current/generic from July 11th after a `make cleanworld` panics on
> bare metal boot on a thinkpad x230.
>
> > I had the same issue. I rebuilt/reinstalled the
> graphics/gpu-firmware-kmod and
> > graphics/drm-515-kmod ports. After a reboot, all was well.
>
> Cool, thanks Shawn!
>
> Should we put an entry in UPDATING when current will panic without the
> latest drm-kmod, or some other type of instruction somewhere?
>

Every time you update the kernel, you must rebuild drm-kmod. If you don't
all bets are off.

I have a different panic with the kernel from 20 minutes ago. Joy.

Warner

Best,
> Alex
>

Re: git: ce4dcb97ca43 - main - zfs: merge openzfs/zfs@9c56b8ec7

[Warner Losh]

On Sun, Aug 11, 2024, 10:29 AM Dennis Clarke  wrote:

> On 8/11/24 09:41, Cy Schubert wrote:
> > In message <54076f5e-cd6d-40d6-b4b7-495cf8e67...@blastwave.org>, Dennis
> > Clarke
> > writes:
> >> On 8/10/24 22:15, Cy Schubert wrote:
> >>> In message , Mark
> Millard
> >>> write
> >>> s:
> >>
>    =E2=80=A2 [2:12 PM]Flox: getting this error in ZFS since recent
> =
>  update in HEAD
>    =E2=80=A2 [2:12 PM]Flox:
>  sysctl_warn_reuse: can't re-use a leaf =
>  (kstat.zfs.zroot.dataset.objset-0x204.zil_itx_metaslab_slog_alloc)!
>  pid 58 (zpool) is attempting to use unsafe AIO requests - not logging
> =
>  anymore
> 
>    =E2=80=A2 [2:13 PM]Flox:
>  FreeBSD fbsd15.localdomain 15.0-CURRENT FreeBSD 15.0-CURRENT #0 =
>  main-aea9dba46b: Sat Aug 10 16:48:02 EDT 2024 =
>  mike@fbsd15.localdomain:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
> =
>  amd64
> >>>
> >>> Yeah. I'm getting tons of these on all my machines as well.
> >>>
> >>> sysctl_warn_reuse: can't re-use a leaf
> (kstat.zfs.cwsys.dataset.objset-0x2c
> >> c
> >>> d.zil_itx_metaslab_slog_alloc)!
> >>>
> >>>
> >>
> >>
> >> Yep. Seems to be a real thing just pouring out all over the console here
> >> too :
> >>
> >>
> >> sysctl_warn_reuse: can't re-use a leaf
> >> (kstat.zfs.t1.dataset.objset-0x4b0.zil_itx_metaslab_slog_alloc)!
> >
> > This only happens on import: when the system boots and when any pools are
> > imported later on.
> >
>
> Sadly .. nope ... that is not the case :
>
> triton# uptime
>   4:27PM  up 11:33, 2 users, load averages: 2.76, 0.93, 0.37
> triton#
> triton# sysctl_warn_reuse: can't re-use a leaf
> (kstat.zfs.t1.dataset.objset-0x639a.zil_itx_metaslab_slog_alloc)!
> sysctl_warn_reuse: can't re-use a leaf
> (kstat.zfs.t1.dataset.objset-0x639a.zil_itx_metaslab_slog_alloc)!
> sysctl_warn_reuse: can't re-use a leaf
> (kstat.zfs.t1.dataset.objset-0x639a.zil_itx_metaslab_slog_alloc)!
> sysctl_warn_reuse: can't re-use a leaf
> (kstat.zfs.t1.dataset.objset-0x6508.zil_itx_metaslab_slog_alloc)!
> sysctl_warn_reuse: can't re-use a leaf
> (kstat.zfs.t1.dataset.objset-0x6508.zil_itx_metaslab_slog_alloc)!
> sysctl_warn_reuse: can't re-use a leaf
> (kstat.zfs.t1.dataset.objset-0x6508.zil_itx_metaslab_slog_alloc)!
> sysctl_warn_reuse: can't re-use a leaf
> (kstat.zfs.t1.dataset.objset-0x5e74.zil_itx_metaslab_slog_alloc)!
> sysctl_warn_reuse: can't re-use a leaf
> (kstat.zfs.t1.dataset.objset-0x5e74.zil_itx_metaslab_slog_alloc)!
> sysctl_warn_reuse: can't re-use a leaf
> (kstat.zfs.t1.dataset.objset-0x5e74.zil_itx_metaslab_slog_alloc)!
> sysctl_warn_reuse: can't re-use a leaf
> (kstat.zfs.t1.dataset.objset-0x6603.zil_itx_metaslab_slog_alloc)!
> sysctl_warn_reuse: can't re-use a leaf
> (kstat.zfs.t1.dataset.objset-0x6603.zil_itx_metaslab_slog_alloc)!
> sysctl_warn_reuse: can't re-use a leaf
> (kstat.zfs.t1.dataset.objset-0x6603.zil_itx_metaslab_slog_alloc)!
> sysctl_warn_reuse: can't re-use a leaf
> (kstat.zfs.t1.dataset.objset-0x5e7c.zil_itx_metaslab_slog_alloc)!
> sysctl_warn_reuse: can't re-use a leaf
> (kstat.zfs.t1.dataset.objset-0x5e7c.zil_itx_metaslab_slog_alloc)!
> sysctl_warn_reuse: can't re-use a leaf
> (kstat.zfs.t1.dataset.objset-0x5e7c.zil_itx_metaslab_slog_alloc)!
>
> So seems to be a thing when the machine is running and doing things like
> a poudriere bulk build etc etc ..
>

Poudriere does a lot of ZFS dataset manipulation, so this isn't surprising.

Warner

I have not seen it when the machine is just twiddling its thumbs
>   pondering an existential crisis. Yet.
>
> >>
> >>
> >> Just a tad uncomfortable to see.
> >
> > Uncomfortable but harmless.
> >
>
> In that case let's make it go away .. mmmkay ?
>
> --
> Dennis Clarke
> RISC-V/SPARC/PPC/ARM/CISC
> UNIX and Linux spoken
>
>
>

Re: filemon

[Warner Losh]

On Tue, Jul 30, 2024, 12:54 PM Dag-Erling Smørgrav  wrote:

> Miroslav Lachman <000.f...@quip.cz> writes:
> > I'm a bit confused. If I understand it right, you say loader.conf
> > causes less memory fragmentation, but DES said "it still increases low
> > memory fragmentation". So what is true? And is this something to watch
> > out for, or is memory fragmentation not such a big deal?
>
> I used the wrong term.  The loader loads the kernel and modules into a
> particular region of memory, while modules loaded after boot can go
> anywhere.  Furthermore, modules loaded by the loader cannot be unloaded.
> So loading modules pre-boot does not increase fragmentation, but it uses
> up memory from a much more limited pool than loading them later.
>

Yea. The lower memory addresses used to matter a lot. Now, we don't have
floppies or devices that care <256MB. Some can only do DMA to < 4GB. So
unless you have a huge RAM dusk compiled in, you're not going to
meaningfully depleate the under 4GB.  And we don't treat that memory as
special for allocation so the modules loaded after boot could also wind up
there

So it used to matter a lot. Now it's marginally relevant at best.

Warner

DES
> --
> Dag-Erling Smørgrav - d...@freebsd.org
>

Re: filemon

[Warner Losh]

On Tue, Jul 30, 2024, 4:50 AM Poul-Henning Kamp  wrote:

> 
> Dag-Erling Smørgrav writes:
>
> > There is very little difference between options and devices in kernel
> > configuration files, but for what it's worth, filemon is a device, not
> > an option.
>
> Apart from the internals of config(8) and it's input data, is there
> any actual difference left ?
>

DEV_FOO is defined instead of FOO in the opt_*.h file is the only
difference since otherwise both are added. I think that config's grammer
only lets option foo=bar work, while device foo=bar does not.

For options like filemon that conditionally include whole files without
ifdefs elsewhere, there's no difference.

Warner

-- 
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
>

Re: filemon

[Warner Losh]

On Tue, Jul 30, 2024, 3:39 AM Miroslav Lachman <000.f...@quip.cz> wrote:

> On 30/07/2024 11:10, Dag-Erling Smørgrav wrote:
> > Gary Jennejohn  writes:
>
> [..]
>
> >> I also load it from /boot/loader.conf using filemon_load="YES"
> >
> > This does cause the module to be loaded at boot time, but it's slower
> > than loading it later, and it increases memory fragmentation.  A better
> > option is to include "filemon" in the kld_list variable in /etc/rc.conf
> > or /etc/rc.conf.d/kld.  For instance,
> >
> >  % cat /etc/rc.conf.d/kld/filemon
> >  kld_list="${kld_list} filemon"
>
> Does this also apply today? I recently read from someone on a mailing
> list that the kld_list in rc.conf is no longer needed, that any problems
> it used to solve are solved, and that the preferred way is to load
> everything from loader.conf. So I'm curious, what's the right thing to
> do then? (I load most of my modules from rc.conf)
>

Either or for filemon. Either rc.conf's kld_list or loader.conf's
filemon_load=YES. I've been recommending loader.conf since there's slightly
less memory fragmentation, but even that effect is small. Only drm kmod has
to be in kld_list.

The performance advantage of the former is no longer there (for UEFI
systems) or is very hard to measure on all but super fringe machines (for
BIOS). Net booting would favor kld_list though.

Warner

Kind regards
> Miroslav Lachman
>
>
>
>

Re: Lua loader shows no menu

[Warner Losh]

That was my fault.

Turns out I forgot to copy the menu version back from my laptop to my
server before committing.
My laptop is the only place I had the menu. I got this stuff working there
last week after I got it
working on my server... then forgot I'd done that and pushed the wrong
version... So you got the
first, untested draft, not the actual code I'd tested.  :( My apologies.

Warner

On Mon, Jul 29, 2024 at 6:56 PM 内藤祐一郎  wrote:

> My lua boot loader shows no menu after updating the following commit with
> my patch in the previous mail.
>
> FreeBSD vega.yuisoft.com 15.0-CURRENT FreeBSD 15.0-CURRENT #29
> main-n271492-0eac99f76ec3: Tue Jul 30 08:59:51 JST 2024
>  yuich...@vega.yuisoft.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
> amd64
>
> Both serial and efi consoles neither.
>
>
>__      _ _
>   |  | |  _ \ / |  __ \
>   | |___ _ __ ___  ___ | |_) | (___ | |  | |
>   |  ___| '__/ _ \/ _ \|  _ < \___ \| |  | |
>   | |   | | |  __/  __/| |_) |) | |__| |
>   | |   | | |||| |  |  |
>   |_|   |_|  \___|\___||/|_/|_/  ```
>   `
> s` `.---...--.```
>  -/
>  +-- Welcome to FreeBSD ---++o   .--` /y:`
>   +.
>  | | yo`:.:o
> `+-
>  | |  y/   -/`
>  -o/
>  | | .-
> ::/sy+:.
>  | | /
>  `--  /
>  | |`:
>   :`
>  | |`:
>   :`
>  | | /
>   /
>  | | .-
> -.
>  | |  --
> -.
>  | |   `:`  `:`
>  | | .-- `--.
>  | |.---..
>  +-+
>
>
> —
> Yuichiro NAITO
> naito.yuich...@gmail.com
>
>
>
>
>

Re: lua loader failes

[Warner Losh]

Yes. My fault. I'll fix. I thought I'd tested the menu... but apparently
not. My apologies.

Warner

On Mon, Jul 29, 2024, 6:44 PM 内藤祐一郎  wrote:

> Hi, I updated my FreeBSD current machine to the following commit.
>
> FreeBSD vega.yuisoft.com 15.0-CURRENT FreeBSD 15.0-CURRENT #29
> main-n271492-0eac99f76ec3: Tue Jul 30 08:59:51 JST 2024
>  yuich...@vega.yuisoft.com:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
> amd64
>
> The lua loader fails as follows.
>
> ERROR: error loading module 'menu' from file '/boot/lua/menu.lua':
>   /boot/lua/menu.lua:420: '}' expected (to close '{' at line 415) near 'vi
> sible’.
>
> A comma is probably missing. The following patch works for me.
>
> diff --git a/stand/lua/menu.lua b/stand/lua/menu.lua
> index 66d7fe673023..7d295eeb65eb 100644
> --- a/stand/lua/menu.lua
> +++ b/stand/lua/menu.lua
> @@ -416,7 +416,7 @@ menu.welcome = {  entry_type =
> core.MENU_SEPARATOR,
> name = function()
> return "Loader requires updating"
> -   end
> +   end,
> visible = function()
> return core.loaderTooOld()
> end
>
>
> —
> Yuichiro NAITO
> naito.yuich...@gmail.com
>
>
>
>
>

Re: [main has a fix for] armv7-on-aarch64 stuck at urdlck: I got a replication of the "ampere2" bulk build hangup problem on a Windows DevKit 2023

[Warner Losh]

On Fri, Jul 26, 2024, 5:37 PM Mark Millard  wrote:

> On Jul 26, 2024, at 07:56, Philip Paeps  wrote:
>
> > On 2024-07-26 22:46:57 (+0800), Mark Millard wrote:
> >> So, it looks like updating the kernel and world on ampere2 and
> >> enabling builds of main-armv7-default should no longer have
> >> main-armv7-default hang-up during graphviz installation (or
> >> analogous contexts). Hopefully, that means that
> >> main-armv7-default builds will then complete and be distributed.
> >
> > I've set the stop-builds flag on the ampere machines.  I'll kick off a
> cluster build and upgrade them when they finish their current builds (or
> get stuck).
> >
> > Thanks for chasing this down.
>
> FYI: As stands, only main has the update. The MFC will not happen
> for about a week. ampere1 and ampere3 should probably wait to
> upate until after the MFC since they do not build main-armv7-* .
>
> Note: The fix is a world change, not a kernel change. So it is
> the jail's world that matters.
>
> I'm not sure if any existing releng/13.*/ or releng/14.*/ will
> get an update for this. stable/13/ and stable/14/ are likely to.
>

I wonder if a rebuilt system will make it through an armv7 bsd-user
poudriere bulk

Warner


===
> Mark Millard
> marklmi at yahoo.com
>
>
>

Re: armv7-on-aarch64 stuck at urdlck

[Warner Losh]

On Wed, Jul 24, 2024 at 11:34 AM m...@freebsd.org 
wrote:

>
>
> On 24.07.2024 17:47, Konstantin Belousov wrote:
> > On Wed, Jul 24, 2024 at 01:07:39PM +, John F Carr wrote:
> >>
> >>
> >>> On Jul 24, 2024, at 06:50, Konstantin Belousov 
> wrote:
> >>>
> >>> On Wed, Jul 24, 2024 at 12:34:57PM +0200, m...@freebsd.org wrote:
> 
> 
>  On 24.07.2024 12:24, Konstantin Belousov wrote:
> > On Tue, Jul 23, 2024 at 08:11:13PM +, John F Carr wrote:
> >> On Jul 23, 2024, at 13:46, Michal Meloun 
> wrote:
> >>>
> >>> On 23.07.2024 11:36, Konstantin Belousov wrote:
>  On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
> > The good news is that I'm finally able to generate a
> working/locking
> > test case.  The culprit (at least for me) is if "-mcpu" is used
> when
> > compiling libthr (e.g. indirectly injected via CPUTYPE in
> /etc/make.conf).
> > If it is not used, libthr is broken (regardless of -O level or
> debug/normal
> > build), but -mcpu=cortex-a15 will always produce a working
> libthr.
>  I think this is very significant progress.
>  Do you plan to drill down more to see what is going on?
> >>>
> >>> So the problem is now clear, and I fear it may apply to other
> architectures as well.
> >>> dlopen_object() (from rtld_elf),
> >>> https://cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766,
> >>> holds the rtld_bind_lock write lock for almost the entire time a
> new library is loaded.
> >>> If the code uses a yet unresolved symbol to load the library, the
> rtl_bind() function attempts to get read lock of  rtld_bind_lock and a
> deadlock occurs.
> >>>
> >>> In this case, it round_up() in _thr_stack_fix_protection,
> >>>
> https://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136.
> >>> Issued by __aeabi_uidiv (since not all armv7 processors support HW
> divide).
> >>>
> >>> Unfortunately, I'm not sure how to fix it.  The compiler can emit
> __aeabi_<> in any place, and I'm not sure if it can resolve all the symbols
> used by rtld_eld and libthr beforehand.
> >>>
> >>>
> >>> Michal
> >>>
> >>
> >> In this case (but not for all _aeabi_ functions) we can avoid
> division
> >> as long as page size is a power of 2.
> >>
> >> The function is
> >>
> >>static inline size_t
> >>round_up(size_t size)
> >>{
> >> if (size % _thr_page_size != 0)
> >> size = ((size / _thr_page_size) + 1) *
> >> _thr_page_size;
> >> return size;
> >>}
> >>
> >> The body can be condensed to
> >>
> >>return (size + _thr_page_size - 1) & ~(_thr_page_size - 1);
> >>
> >> This is shorter in both lines of code and instruction bytes.
> >
> > Lets not allow this to be lost.  Could anybody confirm that the patch
> > below fixes the issue?
> >
> > commit d560f4f6690a48476565278fd07ca131bf4eeb3c
> > Author: Konstantin Belousov 
> > Date:   Wed Jul 24 13:17:55 2024 +0300
> >
> >  rtld: avoid division in __thr_map_stacks_exec()
> >  The function is called by rtld with the rtld bind lock
> write-locked,
> >  when fixing the stack permission during dso load.  Not every
> ARMv7 CPU
> >  supports the div, which causes the recursive entry into rtld to
> resolve
> >  the  __aeabi_uidiv symbol, causing self-lock.
> >  Workaround the problem by using roundup2() instead of
> open-coding less
> >  efficient formula.
> >  Diagnosed by:   mmel
> >  Based on submission by: John F Carr 
> >  Sponsored by:   The FreeBSD Foundation
> >  MFC after:  1 week
> >
> >>> Just realized that it is wrong.  Stack size is user-controlled and it
> does
> >>> not need to be power of two.
> >>
> >> Your change is correct.  _thr_page_size is set to getpagesize(),
> >> which is a power of 2.   The call to roundup2 takes a user-provided
> >> size and rounds it up to a multiple of the system page size.
> >>
> >> I tested the change and it works.  My change also works and
> >> should compile to identical code.  I forgot there was a standard
> >> function to do the rounding.
> > Right, my bad, thank you for correcting my thinko.
> >
> >>
> >>> For final resolving of deadlocks, after a full day of digging, I'm
> very much
>  incline  of adding -znow to the linker flags for libthr.so (and maybe
> also
>  for ld-elf.so). The runtime cost of resolving all symbols at startup
> is very
>  low. Direct pre-solving in _thr_rtld_init() is problematic for the
> _aeabi_*
>  symbols, since they don't have an official C prototypes, and some are
> not
>  compatible with C calling conventions.
> >>> I do not like it. `-z now' changes (breaks) the ABI and makes some
> symbols
> >>> not preemtible.
> >>>
> >>> In the worst case, we would need a call to the

Re: armv7-on-aarch64 stuck at urdlck

[Warner Losh]

On Tue, Jul 23, 2024 at 2:11 PM John F Carr  wrote:

> On Jul 23, 2024, at 13:46, Michal Meloun  wrote:
> >
> > On 23.07.2024 11:36, Konstantin Belousov wrote:
> >> On Tue, Jul 23, 2024 at 09:53:41AM +0200, Michal Meloun wrote:
> >>> The good news is that I'm finally able to generate a working/locking
> >>> test case.  The culprit (at least for me) is if "-mcpu" is used when
> >>> compiling libthr (e.g. indirectly injected via CPUTYPE in
> /etc/make.conf).
> >>> If it is not used, libthr is broken (regardless of -O level or
> debug/normal
> >>> build), but -mcpu=cortex-a15 will always produce a working libthr.
> >> I think this is very significant progress.
> >> Do you plan to drill down more to see what is going on?
> >
> > So the problem is now clear, and I fear it may apply to other
> architectures as well.
> > dlopen_object() (from rtld_elf),
> > https://cgit.freebsd.org/src/tree/libexec/rtld-elf/rtld.c#n3766,
> > holds the rtld_bind_lock write lock for almost the entire time a new
> library is loaded.
> > If the code uses a yet unresolved symbol to load the library, the
> rtl_bind() function attempts to get read lock of  rtld_bind_lock and a
> deadlock occurs.
> >
> > In this case, it round_up() in _thr_stack_fix_protection,
> > https://cgit.freebsd.org/src/tree/lib/libthr/thread/thr_stack.c#n136.
> > Issued by __aeabi_uidiv (since not all armv7 processors support HW
> divide).
> >
> > Unfortunately, I'm not sure how to fix it.  The compiler can emit
> __aeabi_<> in any place, and I'm not sure if it can resolve all the symbols
> used by rtld_eld and libthr beforehand.
> >
> >
> > Michal
> >
>
> In this case (but not for all _aeabi_ functions) we can avoid division
> as long as page size is a power of 2.
>
> The function is
>
>   static inline size_t
>   round_up(size_t size)
>   {
> if (size % _thr_page_size != 0)
> size = ((size / _thr_page_size) + 1) *
> _thr_page_size;
> return size;
>   }
>
> The body can be condensed to
>
>   return (size + _thr_page_size - 1) & ~(_thr_page_size - 1);
>
> This is shorter in both lines of code and instruction bytes.
>

I like this change...

But we do need to fix the deadlocks... They seem to be more likely
when building in bsd-user emulation...

Warner

Re: Long time outdated jemalloc

[Warner Losh]

On Sun, Jul 21, 2024 at 2:03 PM cglogic  wrote:

>
> On Sunday, July 21st, 2024 at 6:54 AM, Warner Losh  wrote:
>
>
>
> On Sat, Jul 20, 2024 at 1:59 AM cglogic  wrote:
>
>> Hello FreeBSD community,
>>
>> After Jason Evans stepped aside from maintaining jemalloc in FreeBSD,
>> it's not updating in time anymore.
>> Version 5.3.0 was released May 6, 2022 and FreeBSD still not imported it
>> into the tree.
>>
>> There is a pending review https://reviews.freebsd.org/D41421 from Aug
>> 11, 2023.
>> I'm successfully running FreeBSD/amd64 system with D41421 applied for 8
>> months, as well as many other people.
>>
>> Can it be reviewed and committed to CURRENT?
>> Or, if there is no committers willing to do it, can commit bit be given
>> to submitter or another person willing to do this?
>>
>> It's very disappointing when users spend their time to fill such gaps and
>> their efforts just ignored by the developers.
>> Every year FreeBSD Community Survey asking about user experience in
>> contributing to FreeBSD.
>> Here you can see an example of such contributing.
>>
>>
> First, thank you for being persistent and continuing to bring it up. It's
> important to do that to make sure this (and your many other) contribution
> doesn't fall on the floor.
>
> And to be fair, we're only 3 months since the last update. Still, quite a
> bit longer than you should have to wait, but not nearly the year the
> original date suggests.
>
> And this is a perfect storm of "how the project is bad at accepting
> contributions":
> (1) The original submission was close to the 14 branch creation time. This
> meant that we weren't well prepared to look at it since it is such an
> invasive change (at least on its surface). It also slowed the initial
> response...
> (2) There was a number of back and forth requests for changes, which took
> time to sort out...
> (3) The size of this is huge, well beyond the capacity of Phabricator to
> review accurately...
> (4) It's a vendor import. That means we can't just drop the Phabricator
> review into the tree...
> (5) It's phabricator: this is a great tool for developers, but we have a
> terrible track record of using it for intake from new contributors. We
> don't have any oversight at all over this tool, at there's at best tepid
> and luke warm attempts to look for drop balls.
>
> All of these things are a terrible experience. I can only apologize. These
> days, we might steer this towards github, but the 'vendor import' means you
> really need someone on the inside, or you need to be on the inside to make
> that work.
>
> So, how to move forward? Well, I'd like to propose the following:
> (1) submit all the other Phabricator reviews you have open (they are
> mostly good, or close to good) to github. Github is being actively managed
> and will make it faster to get things it. It's a much better tool for new
> contributors (and even frequent contributors of smallish things).
> (2) I should do an vendor import of 5.3.0 from github, and do the merge to
> a branch and push that to github. You can then layer on your changes and
> those can be reviewed more closely as a pull request against the branch I
> push. I suspect that most of the issues are sorted out already
> (3) I'll land it via that route...
>
> And, if the sum of the other pull requests and this are good (and I
> suspect they will be), then we can talk about commit bits and such.
>
> It's experiences like this which is why I'm trying to stand up github pull
> requests as a reliable way to get things and and the best place to send
> people...
>
> Thanks again for persisting, and also for expressing this criticism that
> we (hopefully) can use to make it better.
>
> Warner
>
>
> Hello.
>
> I'm not the author of D41421. Just applied the patch to test it 8 months
> ago. And recently discovered that it's still not committed.
> I can't copy your message to Phabricator because don't have an account. 
> Please,
> if you have time, help the author in D41421.
>

Ah yes. I've been in touch with the author for other things, and somehow
thought it was you  I'll reach out to him via other means...

Warner

Re: Long time outdated jemalloc

[Warner Losh]

On Sat, Jul 20, 2024 at 1:59 AM cglogic  wrote:

> Hello FreeBSD community,
>
> After Jason Evans stepped aside from maintaining jemalloc in FreeBSD,
> it's not updating in time anymore.
> Version 5.3.0 was released May 6, 2022 and FreeBSD still not imported it
> into the tree.
>
> There is a pending review https://reviews.freebsd.org/D41421 from Aug 11,
> 2023.
> I'm successfully running FreeBSD/amd64 system with D41421 applied for 8
> months, as well as many other people.
>
> Can it be reviewed and committed to CURRENT?
> Or, if there is no committers willing to do it, can commit bit be given to
> submitter or another person willing to do this?
>
> It's very disappointing when users spend their time to fill such gaps and
> their efforts just ignored by the developers.
> Every year FreeBSD Community Survey asking about user experience in
> contributing to FreeBSD.
> Here you can see an example of such contributing.
>
>
First, thank you for being persistent and continuing to bring it up. It's
important to do that to make sure this (and your many other) contribution
doesn't fall on the floor.

And to be fair, we're only 3 months since the last update. Still, quite a
bit longer than you should have to wait, but not nearly the year the
original date suggests.

And this is a perfect storm of "how the project is bad at accepting
contributions":
(1) The original submission was close to the 14 branch creation time. This
meant that we weren't well prepared to look at it since it is such an
invasive change (at least on its surface). It also slowed the initial
response...
(2) There was a number of back and forth requests for changes, which took
time to sort out...
(3) The size of this is huge, well beyond the capacity of Phabricator to
review accurately...
(4) It's a vendor import. That means we can't just drop the Phabricator
review into the tree...
(5) It's phabricator: this is a great tool for developers, but we have a
terrible track record of using it for intake from new contributors. We
don't have any oversight at all over this tool, at there's at best tepid
and luke warm attempts to look for drop balls.

All of these things are a terrible experience. I can only apologize. These
days, we might steer this towards github, but the 'vendor import' means you
really need someone on the inside, or you need to be on the inside to make
that work.

So, how to move forward? Well, I'd like to propose the following:
(1) submit all the other Phabricator reviews you have open (they are mostly
good, or close to good) to github. Github is being actively managed and
will make it faster to get things it. It's a much better tool for new
contributors (and even frequent contributors of smallish things).
(2) I should do an vendor import of 5.3.0 from github, and do the merge to
a branch and push that to github. You can then layer on your changes and
those can be reviewed more closely as a pull request against the branch I
push. I suspect that most of the issues are sorted out already
(3) I'll land it via that route...

And, if the sum of the other pull requests and this are good (and I suspect
they will be), then we can talk about commit bits and such.

It's experiences like this which is why I'm trying to stand up github pull
requests as a reliable way to get things and and the best place to send
people...

Thanks again for persisting, and also for expressing this criticism that we
(hopefully) can use to make it better.

Warner

Re: Keyboard on laptop typing problem

[Warner Losh]

M*ay*be try https://reviews.freebsd.org/D45554 and see if that works?

Warner

On Sun, Jul 14, 2024 at 7:18 AM Dmitry Salychev  wrote:

>
> Goran Mekić  writes:
>
> > On 7/13/24 18:18, Chris wrote:
> >> On 2024-07-13 15:23, Goran Mekić wrote:
> >>> Hello,
> >>>
> >>> I have a laptop with a weird behaving keyboard. Under Linux
> >>> everything is fine,
> >>> but under FreeBSD it is out of sync. On single key stroke of letter
> >>> 'c' (just for
> >>> example) terminal first doesn't do anything for about a second,
> >>> then it prints
> >>> multiple letters 'c' in a row. Is there any way to debug this
> >>> behavior and why
> >>> it's happening? Any chance there's a known workaround? I don't know
> >>> what other
> >>> info would be useable, so if you can tell me what other than
> >>> usbconfig and pciconf
> >>> to look at, I'll be glad to.
> >> It would be very helpful to know what hardware you're using. It's
> >> otherwise very
> >> difficult to answer this sort of question.
> >
> > You can see that yesterday was the hottest day in my city ever. First,
> > I didn't manage to ask what I wanted: what info should I send, second
> > I sent the reply only to one person :facepalm:
> >
> > Anyway, I think the most condensed way to show the hardware is
> > https://bsd-hardware.info/?probe=3400ac8782
> >
> > Regards,
> > meka
>
> IRQ override [1] which breaks active low IRQs on AMD Ryzen 6000+ systems
> might be the reason of your troubles. I don't know the exact place in
> the FreeBSD src/ to check whether the same override is implemented or
> not, but you'd try to patch ACPI tables yourself [2] till it is fixed.
>
> Regards,
> Dmitry
>
> [1]
>
> https://lore.kernel.org/all/CAJZ5v0isLQVX3EqsokFthY5ka=v4vse9t52s3egsv41fkm1...@mail.gmail.com/
> [2]
> https://www.reddit.com/r/linuxhardware/comments/vdc6tz/comment/ijjjwah/
>
> --
> https://wiki.freebsd.org/DmitrySalychev
>
>

Re: pax(1) looping infinitely

[Warner Losh]

The last core team announced one.

But you can add Approved by: imp

Warner


On Sat, Jun 22, 2024, 12:16 AM Ganael Laplanche <
ganael.laplan...@martymac.org> wrote:

>
>
> On 6/21/24 23:41, Yuri Pankov wrote:
>
> > .mailmap
>
> Thanks Yuri!
>
> I cannot see any blanket approval for a ports committer modifying that
> file within the src repo.
>
> Can a src committer approve (or commit) the following change please ? :
>
> diff --git a/.mailmap b/.mailmap
> index 0d0231a3da68..3d33acc8d59a 100644
> --- a/.mailmap
> +++ b/.mailmap
> @@ -16,3 +16,4 @@ Jose Luis Duran 
> 
>   Val Packett  
>   Piotr Paweł Stefaniak  
>   Sumit Saxena  
> +Ganael LAPLANCHE  
>
> Thanks in advance,
> Best regards,
>
> --
> Ganael LAPLANCHE 
> http://www.martymac.org | http://contribs.martymac.org
> FreeBSD: martymac , http://www.FreeBSD.org
>
>

Re: pax(1) looping infinitely

[Warner Losh]

On Fri, Jun 21, 2024 at 10:55 AM Ganael Laplanche <
ganael.laplan...@martymac.org> wrote:

> On 6/21/24 18:44, Warner Losh wrote:
>
> Hi Warner,
>
> > Fixed.
>  >
> > commit 681fd2bed8eaba88693867ba928a1c03a5b152cc (HEAD -> main)
> > Author: Ganael Laplanche 
> Thanks!
>
> > Wrote the commit message and had to guess at the right email to use. But
> > it looked like bz and the mail here were the same.
>
> You could just have used my FreeBSD.org (martymac@) address here.
> Anyway, my personal address is OK too :)
>

My apologies...  I didn't check, but. it's in your sig so I should have.


There's a mapping file that can be updated for cases like this.


> > In the future, simple patches like this might work better as a github
> > pull request, though, since that would resolve all that ambiguity.
>
> Yep, thanks again!
>

You Bet. IT was an easy one to work with since the patch applied cleanly,
it clearly fixed the problem, (which I was able to reproduce and verify
things
were fixed), etc.

Warner


> Cheers,


> --

Ganael LAPLANCHE 

http://www.martymac.org | http://contribs.martymac.org

FreeBSD: martymac , http://www.FreeBSD.org

Re: pax(1) looping infinitely

[Warner Losh]

Fixed.

commit 681fd2bed8eaba88693867ba928a1c03a5b152cc (HEAD -> main)
Author: Ganael Laplanche 
Date:   Fri Jun 21 10:39:09 2024 -0600

pax: Terminate loop for empty directory names
..

Wrote the commit message and had to guess at the right email to use. But it
looked like bz and the mail here were the same.

In the future, simple patches like this might work better as a github pull
request, though, since that would resolve all that ambiguity.

Warner


On Fri, Jun 21, 2024 at 4:51 AM Ganael Laplanche <
ganael.laplan...@martymac.org> wrote:

> Hello,
>
> Our pax(1) implementation has a small bug triggered when it is fed with
> a directory containing a trailing slash.
>
> Could a src committer have a look at:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277060
>
> ?
>
> I've submitted a small patch that fixes the problem.
>
> Thanks!
>
> Cheers,
>
> --
> Ganael LAPLANCHE 
> http://www.martymac.org | http://contribs.martymac.org
> FreeBSD: martymac , http://www.FreeBSD.org
>
>

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

[Warner Losh]

On Tue, Jun 4, 2024 at 8:17 AM Gerrit Kühn  wrote:

> Am Tue, 28 May 2024 11:19:42 +0200
> schrieb Gerrit Kühn :
>
> > > Not sure if it will break your setup, but this already happened with
> > > 13.2 (I cant recall the exact release).
>
> > I have two machines with onboard NICs (Supermicro H12SSL-CT mainboards)
> > running just fine. One is 13.3, the other is 14.0.
>
> I have updated one system to 14.1 now, and it still works happily
> (transferring lots of data in the background while typing this). So
> whatever causes the issues you have seen with the BCM chipset, not all of
> them appear to be affected. Maybe the firmware is making the difference
> here?
>

I merged the next version of the driver from Broadcom to stable/14, but not
14.1 (it
was too late by the time I got around to this). If there's still issues,
maybe try stable/14?

Warner


> cu
>   Gerrit
>

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

[Warner Losh]

On Mon, May 27, 2024 at 3:01 PM Colin Percival  wrote:

> On 5/27/24 13:51, Warner Losh wrote:
> > On Mon, May 27, 2024 at 10:16 AM Santiago Martinez  > <mailto:s...@codenetworks.net>> wrote:
> > Just wondering if anyone has any contact at broadcom.
> >
> > The bnxt drivers on 14.1BETA1 are unusable.
> >
> > Cards stop working randomly, LRO cannot be disable (fail
> FILTER_ALLOT),
> > even chaining mtu renders the card unusable.
> >
> > The cards, is the same it was used to open the original PR.
> >
> >
> > There's a series of reviews that I've reviewed, but haven't yet been
> committed.
> >
> > I think they start at https://reviews.freebsd.org/D45005
> > <https://reviews.freebsd.org/D45005>.
> >
> > I'll see if I can prevail upon them to commit them to -current soon.
> Just to be clear, you're not expecting this to get into 14.1-RELEASE,
> right?
>

I'd like it there, but I think this will need to be a EN to get it into
14.1 given the late date of this commit  Unless we slip 14.1 for other
reasons...

Warner

Re: [Bug 269133] bnxt(4): BCM57416 - HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR error

[Warner Losh]

On Mon, May 27, 2024 at 10:16 AM Santiago Martinez 
wrote:

> Hi Everyone,
>
> Just wondering if anyone has any contact at broadcom.
>
> The bnxt drivers on 14.1BETA1 are unusable.
>
> Cards stop working randomly, LRO cannot be disable (fail FILTER_ALLOT),
> even chaining mtu renders the card unusable.
>
> The cards, is the same it was used to open the original PR.
>

There's a series of reviews that I've reviewed, but haven't yet been
committed.

I think they start at https://reviews.freebsd.org/D45005.

I'll see if I can prevail upon them to commit them to -current soon.

Warner


> Best regards.
>
> Santiago
>
>
> On 5/4/23 14:20, bugzilla-nore...@freebsd.org wrote:
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269133
> >
> > --- Comment #8 from geoffroy desvernay  ---
> > Since upgrade from 12.3p1x to 13.2-RELEASE, we have the same error
> message here
> > with bnxt (not tested with 13.1):
> >
> > dmesg:
> > bnxt0:  mem
> > 0xb9a1-0xb9a1,0xb910-0xb91f,0xb9aa2000-0xb9aa3fff irq 48
> at
> > device 0.0 numa-domain 0 on pci9
> > bnxt0: Using 256 TX descriptors and 256 RX descriptors
> > bnxt0: Using 12 RX queues 12 TX queues
> > bnxt0: Using MSI-X interrupts with 13 vectors
> > bnxt0: Ethernet address: d0:94:66:81:60:e3
> > bnxt0: netmap queues/slots: TX 12/256, RX 12/256
> > bnxt1:  mem
> > 0xb9a0-0xb9a0,0xb880-0xb88f,0xb9aa-0xb9aa1fff irq 52
> at
> > device 0.1 numa-domain 0 on pci9
> > bnxt1: Using 256 TX descriptors and 256 RX descriptors
> > bnxt1: Using 12 RX queues 12 TX queues
> > bnxt1: Using MSI-X interrupts with 13 vectors
> > bnxt1: Ethernet address: d0:94:66:81:60:e4
> > bnxt1: netmap queues/slots: TX 12/256, RX 12/256
> > bnxt0: Link is UP full duplex, FC - none - 1 Mbps
> > bnxt0: link state changed to UP
> > bnxt1: Link is UP full duplex, FC - none - 1 Mbps
> > bnxt1: link state changed to UP
> > bnxt0: Attempt to re-allocate l2 ctx filter (fid: 0x1170204)
> > bnxt1: Attempt to re-allocate l2 ctx filter (fid: 0x11c0003f004)
> > bnxt0: Attempt to re-allocate l2 ctx filter (fid: 0x1250204)
> > bnxt1: Attempt to re-allocate l2 ctx filter (fid: 0x1280003f004)
> > bnxt0: HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR
> error.
> > bnxt0: set_multi: rx_mask set failed
> > bnxt0: HWRM_CFA_L2_SET_RX_MASK command returned RESOURCE_ALLOC_ERROR
> error.
> > bnxt0: set_multi: rx_mask set failed
> > [same messages x 100's]
> >
> >
> > sysctl:
> >
> > dev.bnxt.0.%domain: 0
> > dev.bnxt.0.%parent: pci9
> > dev.bnxt.0.%pnpinfo: vendor=0x14e4 device=0x16d8 subvendor=0x1028
> > subdevice=0x1feb class=0x02
> > dev.bnxt.0.%location: slot=0 function=0 dbsf=pci0:94:0:0
> > dev.bnxt.0.%driver: bnxt
> > dev.bnxt.0.%desc: Broadcom BCM57416 NetXtreme-E 10GBase-T Ethernet
> > dev.bnxt.0.ver.hwrm_min_ver: 1.10.2
> > dev.bnxt.0.ver.package_ver: 
> > dev.bnxt.0.ver.chip_type: ASIC
> > dev.bnxt.0.ver.chip_bond_id: 0
> > dev.bnxt.0.ver.chip_metal: 1
> > dev.bnxt.0.ver.chip_rev: 1
> > dev.bnxt.0.ver.chip_num: 5848
> > dev.bnxt.0.ver.phy_partnumber: 616740003
> > dev.bnxt.0.ver.phy_vendor: Amphenol
> > dev.bnxt.0.ver.roce_fw_name: BONO_FW
> > dev.bnxt.0.ver.netctrl_fw_name: KONG_FW
> > dev.bnxt.0.ver.mgmt_fw_name: AFW_223.0.205.0
> > dev.bnxt.0.ver.hwrm_fw_name: CHIMP_FW
> > dev.bnxt.0.ver.phy: 13.1.11
> > dev.bnxt.0.ver.fw_ver: 223.0.205.0/pkg 22.31.13.70
> > dev.bnxt.0.ver.roce_fw: 223.0.205
> > dev.bnxt.0.ver.netctrl_fw: 223.0.205
> > dev.bnxt.0.ver.mgmt_fw: 223.0.205
> > dev.bnxt.0.ver.hwrm_fw: 223.0.205
> > dev.bnxt.0.ver.driver_hwrm_if: 1.10.2.34
> > dev.bnxt.0.ver.hwrm_if: 1.10.2
> >
>
>

Re: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock @ /..../sys/cam/nvme/nvme_da.c:469

[Warner Losh]

First order:

Looks like we're trying to schedule a trim, but that fails due to a malloc
issue. So then, since it's a
malloc issue, we wind up trying to automatically reschedule this I/O, which
recurses into the driver
with a bad lock held and boop.

Can you reproduce this?

If so, can you test this patch?

diff --git a/sys/cam/nvme/nvme_da.c b/sys/cam/nvme/nvme_da.c
index 3f6cf8702870..357e612200e9 100644
--- a/sys/cam/nvme/nvme_da.c
+++ b/sys/cam/nvme/nvme_da.c
@@ -1077,7 +1077,9 @@ ndastart(struct cam_periph *periph, union ccb
*start_ccb)

trim = malloc(sizeof(*trim), M_NVMEDA, M_ZERO |
M_NOWAIT);
if (trim == NULL) {
+ cam_periph_unlock(periph);
biofinish(bp, NULL, ENOMEM);
+ cam_periph_lock(periph);
xpt_release_ccb(start_ccb);
ndaschedule(periph);
return;

(the mailer may mangle it, so I've also attached it in case people want to
comment on this).

The logic here is that we have special logic in the ENOMEM case that will
recursively
call the start routine, which calls the scheduler which expects to be able
to take out the
periph lock. But it can't, because it's already locked. It also invokes a
pacing protocol that
slows down things even more.

What I'm now not sure about is whether or not we need to just release
start_ccb or if we also need to call ndaschedule too here. Seems like we
might not want to (but it's a safe nop if not). I've cc'd mav@ to see if he
has opinions on what's going on.

Warner


On Wed, May 22, 2024 at 11:22 AM Alexander Leidinger <
alexan...@leidinger.net> wrote:

> Hi,
>
> I got the panic in $Subject. Anyone an idea?
>
> Complete crashlog available at https://wiki.leidinger.net/core.txt.6
> (1.2 MB)
>
> Short version:
> ---snip---
> [11417] KDB: stack backtrace:
> [11417] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe043133f830
> [11417] vpanic() at vpanic+0x13f/frame 0xfe043133f960
> [11417] panic() at panic+0x43/frame 0xfe043133f9c0
> [11417] __mtx_lock_sleep() at __mtx_lock_sleep+0x491/frame
> 0xfe043133fa50
> [11417] __mtx_lock_flags() at __mtx_lock_flags+0x9c/frame
> 0xfe043133fa70
> [11417] ndastrategy() at ndastrategy+0x3c/frame 0xfe043133faa0
> [11417] g_disk_start() at g_disk_start+0x569/frame 0xfe043133fb00
> [11417] g_io_request() at g_io_request+0x2b6/frame 0xfe043133fb30
> [11417] g_io_deliver() at g_io_deliver+0x1cc/frame 0xfe043133fb80
> [11417] g_disk_done() at g_disk_done+0xee/frame 0xfe043133fbc0
> [11417] ndastart() at ndastart+0x4a3/frame 0xfe043133fc20
> [11417] xpt_run_allocq() at xpt_run_allocq+0xa5/frame 0xfe043133fc70
> [11417] ndastrategy() at ndastrategy+0x6d/frame 0xfe043133fca0
> [11417] g_disk_start() at g_disk_start+0x569/frame 0xfe043133fd00
> [11417] g_io_request() at g_io_request+0x2b6/frame 0xfe043133fd30
> [11417] g_io_request() at g_io_request+0x2b6/frame 0xfe043133fd60
> [11417] g_io_request() at g_io_request+0x2b6/frame 0xfe043133fd90
> [11417] vdev_geom_io_start() at vdev_geom_io_start+0x257/frame
> 0xfe043133fdc0
> [11417] zio_vdev_io_start() at zio_vdev_io_start+0x321/frame
> 0xfe043133fe10
> [11417] zio_execute() at zio_execute+0x78/frame 0xfe043133fe40
> [11417] taskqueue_run_locked() at taskqueue_run_locked+0x1c7/frame
> 0xfe043133fec0
> [11417] taskqueue_thread_loop() at taskqueue_thread_loop+0xd3/frame
> 0xfe043133fef0
> ---snip---
>
> This is with a world from 2024-05-17-084543.
>
> Bye,
> Alexander.
>
> --
> http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
> http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF
>
diff --git a/sys/cam/nvme/nvme_da.c b/sys/cam/nvme/nvme_da.c
index 3f6cf8702870..357e612200e9 100644
--- a/sys/cam/nvme/nvme_da.c
+++ b/sys/cam/nvme/nvme_da.c
@@ -1077,7 +1077,9 @@ ndastart(struct cam_periph *periph, union ccb *start_ccb)
 
 			trim = malloc(sizeof(*trim), M_NVMEDA, M_ZERO | M_NOWAIT);
 			if (trim == NULL) {
+cam_periph_unlock(periph);
 biofinish(bp, NULL, ENOMEM);
+cam_periph_lock(periph);
 xpt_release_ccb(start_ccb);
 ndaschedule(periph);
 return;

Re: __memcpy_chk family of functions

[Warner Losh]

On Tue, May 21, 2024 at 12:16 AM Dag-Erling Smørgrav 
wrote:

> Marcin Cieslak  writes:
> > I have updated some binary packages using pkg(8) but neglected to
> > rebuild the world and my favourite web browsers no longer started
> > complaining about the undefined symbol __memcpy_chk@FBSD_1.8
> >
> > Would that be a good idea to add that information to the Handbook and
> > possible bump FreeBSD_version and add this info to UPDATING?
>
> The purpose of UPDATING is to document changes that break backward
> compatibility, i.e. running old binaries on a newer world.  What
> happened here is that you tried to run newer binaries on an older world,
> an issue of _forward_ compatibility, which we've never promised.
> Besides, an entry in UPDATING wouldn't have helped you since your source
> tree predated the change that would have added it.
>

Also, our forward compatibility guarantees are extremely weak.  At most the
outer
bounds are around a sliding window to upgrade from source, using root in
single user
on the console. So having to revert to an old kernel to build a new kernel
when there's
a problem, or having to revert to an old kernel to rebuild old sources. And
even then
it's not something we test, so it's likely broken or broken once you get a
hair's width
away from that path. Plus, with BEs and the easy ability to roll back to
the prior BE,
even this level of forward compat is likely to decay further in the future.

Warner

Re: devd nomatch does not load uslcom anymore

[Warner Losh]

On Tue, May 21, 2024, 1:38 AM Ronald Klop  wrote:

> Hi,
>
> May 16th upgraded the kernel of my RPI4. Previous kernel was fom April
> 10th.
>
> From:
> FreeBSD 15.0-CURRENT #35 main-5716d902ae1: Wed Apr 10 22:59:37 CEST 2024
>
> To:
> FreeBSD 15.0-CURRENT #36 main-42b28f81521: Thu May 16 07:54:05 CEST 2024
>
> Today I noticed my USB serial cable to my RPI3 was not available anymore.
> It hadn't loaded 'uslcom' at boot.
> Adding 'hw.bus.devctl_nomatch_enabled=1' to /boot/loader.conf resolves the
> issue for now.
>
> The proper output during boot is:
> Starting devd.
> Autoloading module: uslcom
> uslcom0 on uhub1
> uslcom0:  rev 1.10/1.00, addr 2> on usbus0
>
> Does anybody need more information about this?
>

I committed a fix a couple of days ago that defaults to always generating
the events.

Or were you wanting a deep dive on usb?

Warner

Regards,
> Ronald.
>
>

Re: usb mouse not work on boot

[Warner Losh]

On Sat, May 18, 2024, 9:22 AM Oleksandr Kryvulia 
wrote:

> 18.05.24 16:06, Warner Losh:
>
>
>
> On Sat, May 18, 2024, 6:51 AM Oleksandr Kryvulia 
> wrote:
>
>> 18.05.24 12:59, Oleksandr Kryvulia:
>>
>> 18.05.24 12:55, Dag-Erling Smørgrav:
>>
>> Oleksandr Kryvulia   writes:
>>
>> Gary Jennejohn   writes:
>>
>> Try adding uhid_load="YES" to your /boot/loader.conf.  With that
>> added the module should be automatically loaded during the kernel
>> boot.
>>
>> As workaround I already have kld_list+="uhid" in /etc/rc.conf.
>>
>> I hope you don't mean that literally, because /etc/rc.conf is a shell
>> script and += is not valid shell syntax.  On the other hand, something
>> like
>>
>> kld_list="${kld_list} uhid"
>>
>> Yes, you are right. I mean
>> sysrc kld_list+="uhid"
>>
>>
>> One more correction. Via kld_list I need load ums(4), loading only
>> uhid(4) does not solve a problem.
>>
>
>
> You don't need to change kld_list. In fact, you should undo any changes
> you've made there. Undo everything in loader.conf you've done.
>
> This is a bug in the boot optimization stuff. Or rather, this exposes a
> long standing bug in the USB code where there's an asymmetry between the
> nomatch events and the bus tree it presents to devctl causing devmatch to
> fail when the nomatch events aren't present on boot.
>
> Just set hw.bus.devctl_nomatch_enabled=1 in /boot/loader.conf and reboot.
> Or update to the change I'm about to make.
>
>
> Thanks for the detailed explanation, Warner. Interesting that on my system
> hw.bus.devctl_nomatch_enabled=1 is set by /etc/rc.d/devmatch but only
> explicit set it in /boot/loader.conf did the trick. That is why I think
> this sysctl don't work in my case.
>

Yea. That's the optimization. We don't start generating events until it is
one. Setting it in the bootloader causes all events to coke through.
Setting it in devmatch turns them on after we run devmatch the first time,
omitting all of the ones generated on boot.

Warner

>

Re: usb mouse not work on boot

[Warner Losh]

On Sat, May 18, 2024 at 6:51 AM Oleksandr Kryvulia 
wrote:

> 18.05.24 12:59, Oleksandr Kryvulia:
>
> 18.05.24 12:55, Dag-Erling Smørgrav:
>
> Oleksandr Kryvulia   writes:
>
> Gary Jennejohn   writes:
>
> Try adding uhid_load="YES" to your /boot/loader.conf.  With that
> added the module should be automatically loaded during the kernel
> boot.
>
> As workaround I already have kld_list+="uhid" in /etc/rc.conf.
>
> I hope you don't mean that literally, because /etc/rc.conf is a shell
> script and += is not valid shell syntax.  On the other hand, something
> like
>
> kld_list="${kld_list} uhid"
>
> Yes, you are right. I mean
> sysrc kld_list+="uhid"
>
>
> One more correction. Via kld_list I need load ums(4), loading only uhid(4)
> does not solve a problem.
>

Also, in this case, kld_list is a terrible place to load the files. You're
better off loading them with xxx_load=YES in loader.conf. The reason is
that both uhid and ums will match your mouse. kld_list loads these in a
random order (effectively) and the first one to load will claim the device,
since there's no re-probe when the next one loads. You should never use it,
unless the module you're loading isn't supported by the boot loader (like
drm-kmod). The old advice was to put everything in kld_list and it would
speed up boot, but all the performance bugs in the boot loader have been
fixed by a combination of moving to UEFI (which is generally faster),
BIOSes with performance bugs disappearing 10 years ago and block caching
being added to the boot loader. It should almost always be empty or just
drm-mod these days (unless you somehow have special needs).

By adding uhid last to this list in this way, you're guaranteeing you'll
hit this bug because it's not after ums, and that things won't work.

Warner

Re: usb mouse not work on boot

[Warner Losh]

On Sat, May 18, 2024, 6:51 AM Oleksandr Kryvulia 
wrote:

> 18.05.24 12:59, Oleksandr Kryvulia:
>
> 18.05.24 12:55, Dag-Erling Smørgrav:
>
> Oleksandr Kryvulia   writes:
>
> Gary Jennejohn   writes:
>
> Try adding uhid_load="YES" to your /boot/loader.conf.  With that
> added the module should be automatically loaded during the kernel
> boot.
>
> As workaround I already have kld_list+="uhid" in /etc/rc.conf.
>
> I hope you don't mean that literally, because /etc/rc.conf is a shell
> script and += is not valid shell syntax.  On the other hand, something
> like
>
> kld_list="${kld_list} uhid"
>
> Yes, you are right. I mean
> sysrc kld_list+="uhid"
>
>
> One more correction. Via kld_list I need load ums(4), loading only uhid(4)
> does not solve a problem.
>


You don't need to change kld_list. In fact, you should undo any changes
you've made there. Undo everything in loader.conf you've done.

This is a bug in the boot optimization stuff. Or rather, this exposes a
long standing bug in the USB code where there's an asymmetry between the
nomatch events and the bus tree it presents to devctl causing devmatch to
fail when the nomatch events aren't present on boot.

Just set hw.bus.devctl_nomatch_enabled=1 in /boot/loader.conf and reboot.
Or update to the change I'm about to make.

Warner

Re: Boot failure, amd64 (HP EliteBook 650 G10)

[Warner Losh]

I'd love to borrow one of these machines fir a week or so.

Warner

On Sat, Mar 9, 2024, 2:52 AM Graham Perrin  wrote:

> 
>
> amd64.
>
> AFAICT the EliteBook 650 G10 was introduced around May 2023.
>
> Does anything in the three photographs tally with a report in Bugzilla?
>
> Any overlap with
> 
>
> for AMD Ryzen 7 CPU (Lenovo ThinkPad P16s Gen2 (AMD; Type 21K9))?
>
>
>
>

Re: Reason why "nocache" option is not displayed in "mount"?

[Warner Losh]

On Thu, Mar 7, 2024 at 1:05 PM Jamie Landeg-Jones  wrote:

> Alexander Leidinger  wrote:
>
> > Hi,
> >
> > what is the reason why "nocache" is not displayed in the output of
> > "mount" for nullfs options?
>
> Good catch. I also notice that "hidden" is not shown either.
>
> I guess that as for some time, "nocache" was a "secret" option, no-one
> update "mount" to display it?
>

So a couple of things to know.

First, there's a list of known options. These are converted to a bitmask.
This is then decoded and reported by mount. The other strings are passed to
the filesystem directly. They decode it and do things, but they don't
export them (that I can find). I believe that's why they aren't reported
with 'mount'. There's a couple of other options in /etc/fstab that are
pseudo options too.

Warner

Re: Unable to boot -CURRENT on Thinkpad P16s G2

[Warner Losh]

On Thu, Mar 7, 2024 at 4:50 PM Doug Ambrisko  wrote:

> On Thu, Mar 07, 2024 at 07:15:48PM +0100, Philipp Ost wrote:
> | On 2/28/24 21:10, Philipp Ost wrote:
> | [boot log stripped]
> | > Does anyone have any suggestions on how to proceed at this point? [..]
> |
> | Short follow-up: disabling uart0 and uart1 at the loader prompt allowed
> us
> | to boot and install FreeBSD (the -CURRENT snapshot from 2024-02-29 in
> case
> | it matters).
>
> UARTS on AMD can be a bit different.  Some BIOS implementations seem
> to set them up to work like legacy ports others do not.  On a Naples
> platform I helped add support for them since they were not setup
> in the legacy configuration.  The AMD servers I'm using now have them
> setup in legacy mode and just work like on other systems.
>
> If I remember right those UARTS were defined in ACPI.  On a laptop they
> probably don't have serial ports and the probe is getting stuck on
> something.  It might be good to instrument it to see what.
>

It might also be time to finally drop the UART fallback when ACPI is
present.
I've seen spotty reports of accessing these registers (for uart, kbd and
maybe
mouse) causing problems. The ACPI definition of the UARTs would be
additional
uart units. The fallback stuff is needed only for extremely edge cases at
this point.

Warner

Re: files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401.gz not found -- snapshot corrupt.

[Warner Losh]

On Thu, Feb 15, 2024, 1:33 PM Mario Marietto  wrote:

> Hello.
>
> What's the correct port tree for FreeBSD 12.04 for arm 32 bit ? A or B ?
>
> A) https://cgit.freebsd.org/ports/snapshot/ports-12.4-eol.tar.gz
>
> B) https://cgit.freebsd.org/ports/snapshot/ports-release/12.4.0.tar.gz
>

A is your best bet.

Warner

thanks.
>
> On Thu, Feb 15, 2024 at 6:34 PM Jamie Landeg-Jones 
> wrote:
>
>> Mario Marietto  wrote:
>>
>> > After a lot of work I've been able to install FreeBSD 12.04 for armv7
>> on my
>> > ARM Chromebook. Now I would like to install some ports. This is what
>> > happens when I try to get a fresh ports tree :
>> > files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401gz
>> > not found -- snapshot corrupt.
>>
>> I'm not sure why the file isn't there - maybe because 12.X is EOL or
>> portsnap
>> is deprecated?
>>
>> Still, the solution is easy:
>>
>> Download the ports tree snapshot as a tar from
>> https://cgit.freebsd.org/ports/
>>
>> Choose a tag, and a format. I suggest 12.4-eol so just fetch
>>
>> https://cgit.freebsd.org/ports/snapshot/ports-12-eol.tar.gz
>>
>> rm -r /usr/ports
>> then untar the downloaded tar file into place.
>>
>> Cheers, Jamie
>>
>>
>
> --
> Mario.
>

Re: files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401.gz not found -- snapshot corrupt.

[Warner Losh]

You may need to grab the repo. You may have to back up to December's ports
tree...

Warner

On Wed, Feb 14, 2024, 5:51 PM Mario Marietto  wrote:

> Hello.
>
> After a lot of work I've been able to install FreeBSD 12.04 for armv7 on
> my ARM Chromebook. Now I would like to install some ports. This is what
> happens when I try to get a fresh ports tree :
>
> marietto@freebsd:/usr # sudo portsnap fetch extract
>
> .
> /usr/ports/databases/py-sqlalchemy10/
> /usr/ports/databases/py-sqlalchemy11/
> /usr/ports/databases/py-sqlalchemy12/
> /usr/ports/databases/py-sqlalchemy13/
> /usr/ports/databases/py-sqlalchemy14/
> /usr/ports/databases/py-sqlalchemy20/
> /usr/ports/databases/py-sqlcipher3/
> files/edd962f76ea4b5869f3c6f8ee5438fb9750b802d02bb8035fe1b7bd0a8ba7401.gz not 
> found -- snapshot corrupt.
>
>
> I repeated the "portsnap fetch extract" command,but I always get the same
> error.
>
> --
> Mario.
>

Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic

[Warner Losh]

Hey John,

On Wed, Feb 14, 2024 at 10:30 AM John Baldwin  wrote:

> On 2/14/24 8:42 AM, Warner Losh wrote:
> > On Wed, Feb 14, 2024 at 9:08 AM John Baldwin  wrote:
> >
> >> On 2/12/24 5:57 PM, Mark Millard wrote:
> >>> On Feb 12, 2024, at 16:36, Mark Millard  wrote:
> >>>
> >>>> On Feb 12, 2024, at 16:10, Mark Millard  wrote:
> >>>>
> >>>>> On Feb 12, 2024, at 12:00, Mark Millard  wrote:
> >>>>>
> >>>>>> [Gack: I was looking at the wrong vintage of source code, predating
> >>>>>> your changes: wrong system used.]
> >>>>>>
> >>>>>>
> >>>>>> On Feb 12, 2024, at 10:41, Mark Millard  wrote:
> >>>>>>
> >>>>>>> On Feb 12, 2024, at 09:32, John Baldwin  wrote:
> >>>>>>>
> >>>>>>>> On 2/9/24 8:13 PM, Mark Millard wrote:
> >>>>>>>>> Summary:
> >>>>>>>>> pcib0:  mem
> >> 0x7d50-0x7d50930f irq 80,81 on simplebus2
> >>>>>>>>> pcib0: parsing FDT for ECAM0:
> >>>>>>>>> pcib0:  PCI addr: 0xc000, CPU addr: 0x6, Size:
> >> 0x4000
> >>>>>>>>> . . .
> >>>>>>>>> rman_manage_region:  request: start
> >> 0x6, end 0x6000f
> >>>>>>>>> panic: Failed to add resource to rman
> >>>>>>>>
> >>>>>>>> Hmmm, I suspect this is due to the way that bus_translate_resource
> >> works which is
> >>>>>>>> fundamentally broken.  It rewrites the start address of a resource
> >> in-situ instead
> >>>>>>>> of keeping downstream resources separate from the upstream
> >> resources.   For example,
> >>>>>>>> I don't see how you could ever release a resource in this design
> >> without completely
> >>>>>>>> screwing up your rman.  That is, I expect trying to detach a PCI
> >> device behind a
> >>>>>>>> translating bridge that uses the current approach should corrupt
> >> the allocated
> >>>>>>>> resource ranges in an rman long before my changes.
> >>>>>>>>
> >>>>>>>> That said, that doesn't really explain the panic.  Hmm, the panic
> >> might be because
> >>>>>>>> for PCI bridge windows the driver now passes RF_ACTIVE and the
> >> bus_translate_resource
> >>>>>>>> hack only kicks in the activate_resource method of
> >> pci_host_generic.c.
> >>>>>>>>
> >>>>>>>>> Detail:
> >>>>>>>>> . . .
> >>>>>>>>> pcib0:  mem
> >> 0x7d50-0x7d50930f irq 80,81 on simplebus2
> >>>>>>>>> pcib0: parsing FDT for ECAM0:
> >>>>>>>>> pcib0: PCI addr: 0xc000, CPU addr: 0x6, Size:
> >> 0x4000
> >>>>>>>>
> >>>>>>>> This indicates this is a translating bus.
> >>>>>>>>
> >>>>>>>>> pcib1:  irq 91 at device 0.0 on pci0
> >>>>>>>>> rman_manage_region:  request: start 0x1, end
> 0x1
> >>>>>>>>> pcib0: rman_reserve_resource: start=0xc000, end=0xc00f,
> >> count=0x10
> >>>>>>>>> rman_reserve_resource_bound:  request: [0xc000,
> >> 0xc00f], length 0x10, flags 102, device pcib1
> >>>>>>>>> rman_reserve_resource_bound: trying 0x
> <0xc000,0xf>
> >>>>>>>>> considering [0xc000, 0x]
> >>>>>>>>> truncated region: [0xc000, 0xc00f]; size 0x10
> >> (requested 0x10)
> >>>>>>>>> candidate region: [0xc000, 0xc00f], size 0x10
> >>>>>>>>> allocating from the beginning
> >>>>>>>>> rman_manage_region:  request: start
> >> 0x6, end 0x6000f
> >>>>>
> >>>>> What you later typed does not match:
> >>>>>
> >>>>> 0x6
> >>>>> 0x6000f
> >>>>>
> >>>>> You later typed:
> 

Re: Recent commits reject RPi4B booting: pcib0 vs. pcib1 "rman_manage_region: request" leads to panic

[Warner Losh]

On Wed, Feb 14, 2024 at 9:08 AM John Baldwin  wrote:

> On 2/12/24 5:57 PM, Mark Millard wrote:
> > On Feb 12, 2024, at 16:36, Mark Millard  wrote:
> >
> >> On Feb 12, 2024, at 16:10, Mark Millard  wrote:
> >>
> >>> On Feb 12, 2024, at 12:00, Mark Millard  wrote:
> >>>
>  [Gack: I was looking at the wrong vintage of source code, predating
>  your changes: wrong system used.]
> 
> 
>  On Feb 12, 2024, at 10:41, Mark Millard  wrote:
> 
> > On Feb 12, 2024, at 09:32, John Baldwin  wrote:
> >
> >> On 2/9/24 8:13 PM, Mark Millard wrote:
> >>> Summary:
> >>> pcib0:  mem
> 0x7d50-0x7d50930f irq 80,81 on simplebus2
> >>> pcib0: parsing FDT for ECAM0:
> >>> pcib0:  PCI addr: 0xc000, CPU addr: 0x6, Size:
> 0x4000
> >>> . . .
> >>> rman_manage_region:  request: start
> 0x6, end 0x6000f
> >>> panic: Failed to add resource to rman
> >>
> >> Hmmm, I suspect this is due to the way that bus_translate_resource
> works which is
> >> fundamentally broken.  It rewrites the start address of a resource
> in-situ instead
> >> of keeping downstream resources separate from the upstream
> resources.   For example,
> >> I don't see how you could ever release a resource in this design
> without completely
> >> screwing up your rman.  That is, I expect trying to detach a PCI
> device behind a
> >> translating bridge that uses the current approach should corrupt
> the allocated
> >> resource ranges in an rman long before my changes.
> >>
> >> That said, that doesn't really explain the panic.  Hmm, the panic
> might be because
> >> for PCI bridge windows the driver now passes RF_ACTIVE and the
> bus_translate_resource
> >> hack only kicks in the activate_resource method of
> pci_host_generic.c.
> >>
> >>> Detail:
> >>> . . .
> >>> pcib0:  mem
> 0x7d50-0x7d50930f irq 80,81 on simplebus2
> >>> pcib0: parsing FDT for ECAM0:
> >>> pcib0: PCI addr: 0xc000, CPU addr: 0x6, Size:
> 0x4000
> >>
> >> This indicates this is a translating bus.
> >>
> >>> pcib1:  irq 91 at device 0.0 on pci0
> >>> rman_manage_region:  request: start 0x1, end 0x1
> >>> pcib0: rman_reserve_resource: start=0xc000, end=0xc00f,
> count=0x10
> >>> rman_reserve_resource_bound:  request: [0xc000,
> 0xc00f], length 0x10, flags 102, device pcib1
> >>> rman_reserve_resource_bound: trying 0x <0xc000,0xf>
> >>> considering [0xc000, 0x]
> >>> truncated region: [0xc000, 0xc00f]; size 0x10
> (requested 0x10)
> >>> candidate region: [0xc000, 0xc00f], size 0x10
> >>> allocating from the beginning
> >>> rman_manage_region:  request: start
> 0x6, end 0x6000f
> >>>
> >>> What you later typed does not match:
> >>>
> >>> 0x6
> >>> 0x6000f
> >>>
> >>> You later typed:
> >>>
> >>> 0x6000
> >>> 0x600fff
> >>>
> >>> This seems to have lead to some confusion from using the
> >>> wrong figure(s).
> >>>
> >> The fact that we are trying to reserve the CPU addresses in the
> rman is because
> >> bus_translate_resource rewrote the start address in the resource
> after it was allocated.
> >>
> >> That said, I can't see why rman_manage_region would actually fail.
> At this point the
> >> rman is empty (this is the first call to rman_manage_region for
> "pcib1 memory window"),
> >> so only the check that should be failing are the checks against
> rm_start and
> >> rm_end.  For the memory window, rm_start is always 0, and rm_end is
> always
> >> 0x, so both the old (0xc - 0xc00f) and new
> (0x6000 - 0x600fff)
> >> ranges are within those bounds.
> >>>
> >>> No:
> >>>
> >>> 0x
> >>>
> >>> .vs (actual):
> >>>
> >>> 0x6
> >>> 0x6000f
>
> Ok, then this explains the failure if the "raw" addresses are above 4G.  I
> have
> access to an emag I'm currently using to test fixes to pci_host_generic.c
> to
> avoid corrupting struct resource objects.  I'll post the diff once I've got
> something verified to work.
>
> > It looks to me like in sys/dev/pci/pci_pci.c the:
> >
> > static void
> > pcib_probe_windows(struct pcib_softc *sc)
> > {
> > . . .
> >  pcib_alloc_window(sc, &sc->mem, SYS_RES_MEMORY, 0, 0x);
> > . . .
> >
> > is just inappropriately restrictive about where in the system
> > address space a PCIe can validly be mapped to on the high end.
> > That, in turn, leads to the rejection on the RPi4B now that
> > the range use is checked.
>
> No, the physical register in PCI-PCI bridges is only 32-bits.  Only the
> prefetchable BAR supports 64-bit addresses.  This is why the host bridge
> is doing a translation from the CPU side (0x6) to the PCI BAR
> addresses (0xc000) so that the BAR addresses are down in the 32-bit
> address range.  It's also true tha

Re: nvme controller reset failures on recent -CURRENT

[Warner Losh]

On Mon, Feb 12, 2024 at 9:15 PM Don Lewis  wrote:

> On 12 Feb, Maxim Sobolev wrote:
> > Might be an overheating. Today's nvme drives are notoriously flaky if you
> > run them without proper heat sink attached to it.
>
> I don't think it is a thermal problem.  According to the drive health
> page, the device temperature has never reached Temperature 2, whatever
> that is.  The room temperature is around 65F.  The system was stable
> last summer when the room temperature spent a lot of time in the 80-85F
> range.  The device temperature depends a lot on the I/O rate, and the
> last panic happened when the I/O rate had been below 40tps for quite a
> while.
>

It did reach temperature 1, though. That's the 'Warning this drive is too
hot' temperature. It has spent 41213 minutes of your 19297 hours of up
time, or an average of 2 minutes per hour. That's too much. Temperature
2 is critical error: we are about to shut down completely due to it
being too hot. It's only a couple degrees below hardware power off
due to temperature in many drives. Some really cheap ones don't really
implement it at all. On my card with the bad heat sink, Warning temp is
70C while critical is 75C while IIRC thermal shutdown is 78C or 80C.

I don't think we report these values in nvmecontrol identify. But you can
do a raw dump with -x look at bytes 266:267 for warning and 268:269
for critical.

In contrast, the few dozen drives that I have, all of which have been
abused in various ways, And only one of them has any heat issues,
and that one is an engineering special / sample with what I think is
a damaged heat sink. If your card has no heat sink, this could well
be what's going on.

This panic means "the nvme card lost its mind and stopped talking
to the host". Its status registers read 0xff's, which means that the card
isn't decoding bus signals. Usually this means that the firmware on the
card has faulted and rebooted. If the card is overheating, then this could
well be what's happening.

There's a tiny chance that this could be something more exotic,
but my money is on hardware gone bad after 2 years of service. I don't think
this is 'wear out' of the NAND (it's only 15TB written, but it could be if
this
drive is really really crappy nand: first generation QLC maybe, but it seems
too new). It might also be a connector problem that's developed over time.
There might be a few other things too, but I don't think this is a U.2 drive
with funky cables.

Warner


> > On Mon, Feb 12, 2024, 4:28 PM Don Lewis  wrote:
> >
> >> I just upgraded my package build machine to:
> >>   FreeBSD 15.0-CURRENT #110 main-n268161-4015c064200e
> >> from:
> >>   FreeBSD 15.0-CURRENT #106 main-n265953-a5ed6a815e38
> >> and I've had two nvme-triggered panics in the last day.
> >>
> >> nvme is being used for swap and L2ARC.  I'm not able to get a crash
> >> dump, probably because the nvme device has gone away and I get an error
> >> about not having a dump device.  It looks like a low-memory panic
> >> because free memory is low and zfs is calling malloc().
> >>
> >> This shows up in the log leading up to the panic:
> >> Feb 12 10:07:41 zipper kernel: nvme0: Resetting controller due to a
> >> timeout a
> >> nd possible hot unplug.
> >> Feb 12 10:07:41 zipper syslogd: last message repeated 1 times
> >> Feb 12 10:07:41 zipper kernel: nvme0: resetting controller
> >> Feb 12 10:07:41 zipper kernel: nvme0: Resetting controller due to a
> >> timeout a
> >> nd possible hot unplug.
> >> Feb 12 10:07:41 zipper syslogd: last message repeated 1 times
> >> Feb 12 10:07:41 zipper kernel: nvme0: Waiting for reset to complete
> >> Feb 12 10:07:41 zipper syslogd: last message repeated 2 times
> >> Feb 12 10:07:41 zipper kernel: nvme0: failing queued i/o
> >> Feb 12 10:07:41 zipper kernel: nvme0: Failed controller, stopping
> watchdog
> >> ti
> >> meout.
> >>
> >> The device looks healthy to me:
> >> SMART/Health Information Log
> >> 
> >> Critical Warning State: 0x00
> >>  Available spare:   0
> >>  Temperature:   0
> >>  Device reliability:0
> >>  Read only: 0
> >>  Volatile memory backup:0
> >> Temperature:312 K, 38.85 C, 101.93 F
> >> Available spare:100
> >> Available spare threshold:  10
> >> Percentage used:3
> >> Data units (512,000 byte) read: 5761183
> >> Data units written: 29911502
> >> Host read commands: 471921188
> >> Host write commands:605394753
> >> Controller busy time (minutes): 32359
> >> Power cycles:   110
> >> Power on hours: 19297
> >> Unsafe shutdowns:   14
> >> Media errors:   0
> >> No. error info log entries: 0
> >> Warning Temp Composite Time:0
> >> Error Temp Composite Time:  0
> >> Temperature 1 Transition Count: 5231
> >> Temperature 2 Transition Count: 0
> >> Total Time For Tempera

Re: libc/libsys split coming soon

[Warner Losh]

On Sat, Feb 3, 2024, 11:02 AM Konstantin Belousov 
wrote:

> On Sat, Feb 03, 2024 at 11:05:10AM -0500, Daniel Eischen wrote:
> > Will this break binary compatibility with older programs expecting those
> symbols in libc and not linked to libsys?
>
> As was mentioned, libc filters libsys.  This means that libc exports all
> the same symbols as before, but forward the implementation to libsys.
> For apps nothing changes, the introduction of libsys is (should be) ABI
> compatible.
>
> More, I would state that no binaries wanting to state binary-compatble
> with future FreeBSD should link to libsys directly, at least for now.
>

How do you view Golang or Rust run times using this then? They try to avoid
libc today.

Warner

Warner

> >
> > > On Feb 3, 2024, at 3:39 AM, Dave Cottlehuber 
> wrote:
> > >
> > > On Fri, 2 Feb 2024, at 23:31, Brooks Davis wrote:
> > >> TL;DR: The implementation of system calls is moving to a seperate
> > >> library (libsys).  No changes are required to existing software
> (except
> > >> to ensure that libsys is present when building custom disk images).
> > >>
> > >> Code: https://github.com/freebsd/freebsd-src/pull/908
> > >>
> > >> After nearly a decade of intermittent work, I'm about to land a series
> > >> of patches which moves system calls, vdso support, and libc's parsing
> of
> > >> the ELF auxiliary argument vector into a separate library (libsys).  I
> > >> plan to do this early next week (February 5th).
> > >>
> > >> This change serves three primary purposes:
> > >>  1. It's easier to completely replace system call implementations for
> > >> tracing or compartmentalization purposes.
> > >>  2. It simplifies the implementation of restrictions on system calls
> such
> > >> as those implemented by OpenBSD's msyscall(2)
> > >> (https://man.openbsd.org/msyscall.2).
> > >>  3. It allows language runtimes to link with libsys for system call
> > >> implementations without requiring libc.
> > >
> > > Awesome! So (3) is generally considered ideal for languages like
> zig[1], rust or go, to use directly?
> > >
> > > What’s the appropriate mechanism for such a language to know which
> version of FreeBSD it’s talking to, to ensure syscall table matches the
> languages expectations?
> > >
> > > It would be nice to hear about any experiments in (2) and how that
> compares to things such as capsicum.
> > >
> > > [1]: https://github.com/ziglang/zig/issues/165
> > >
> > > A+
> > > Dave
> > >
> > >
> >
> >
>
>

Re: 'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b

[Warner Losh]

On Wed, Jan 31, 2024, 6:53 AM Mike Karels  wrote:

>
>
> On 31 Jan 2024, at 7:18, Olivier Cochard-Labbé wrote:
>
>
> On Tue, Jan 30, 2024 at 3:50 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:
>>
>>
> Same problem here.
>
>
> I would check 9cdf326b4faef97f0d3314b5dd693308ac494d48, it changed
> shutdown ordering
>

Yea. Almost certainly. I think David is testing a patch from A

Re: noatime on ufs2

[Warner Losh]

On Mon, Jan 29, 2024 at 2:31 PM Olivier Certner  wrote:

> Hi Mike,
>
> I've re-ordered a bit your mail to group some of my comments more
> logically.
>
> > I am not sure a sysctl is a good mechanism for setting the mount default,
> > especially if it is to be set via the kernel environment from
> > /boot/loader.conf.  That's an obscure place to find file system defaults.
>
> If the setting has to matter for the root filesystem also (I think it
> should), currently the knob should be set in '/boot/loader.conf'.  But if
> "regular" filesystems (those from '/etc/fstab') have an explicit 'atime' or
> 'noatime', '/etc/sysctl.conf' could be enough ('/etc/rc/sysctl' is run very
> early).
>

I strongly oppose this notion to control this from loader.conf. Root is
mounted read-only, so it doesn't matter. That's why I liked Mike's
suggestion: root isn't special.


> > It also seems undesirable to add a sysctl to control a value that the
> > kernel doesn't use.
>
> The kernel has to use it to guarantee some uniform behavior irrespective
> of the mount being performed through mount(8) or by a direct call to
> nmount(2).  I think this consistency is important.  Perhaps all
> auto-mounters and mount helpers always run mount(8) and never deal with
> nmount(2), I would have to check (I seem to remember that, a long time ago,
> when nmount(2) was introduced as an enhancement over mount(2), the stance
> was that applications should use mount(8) and not nmount(2) directly).
> Even if there were no obvious callers of nmount(2), I would be a bit
> uncomfortable with this discrepancy in behavior.
>

I disagree. I think Mike's suggestion was better and dealt with POLA and
POLA breaking in a sane way. If the default is applied universally in user
space, then we need not change the kernel at all. We lose all the chicken
and egg problems and the non-linearness of the sysctl idea.


> > Note that the root file system is mounted specially in the kernel, but
> the
> > noatime option doesn't need to be set at first while the root is
> read-only.
> > It could be updated by mount when remounting read-write from the startup
> > scripts.
>
> That's true.  However, how about other filesystems mounted by rc scripts,
> such as '/tmp'?  I agree that this one is not a good example, since the
> 'tmpfs' script ultimately calls 'mdmfs', which ultimately spawns a new
> process to execute mount(8).  But I fear that, if we don't have the
> consistency exposed just above, we are going to need to audit other
> programs, including external ones, which is precisely what I wanted to
> avoid with a simple default that applies to everything (hence, implemented
> in the kernel).
>

If it's in fstab as default, then it would be read by whatever updates
things in user space.


> > Instead, I'd like to propose that the default be
> > specified in a new entry in /etc/fstab, where it would be much more
> obvious.
> > For example, a line could be placed at the beginning like:
> >
> >   # DeviceMountpoint  FStype  Options
> >   default nonedefault noatime,...
> >
> > It could be retrieved with getfsspec("default") in the fs_mnntops field.
> > I wouldn't include this entry when iterating through the whole file with
> > getfsent() to avoid confusing existing programs.  Then mount, and other
> > utilities such as zfs create, could check it explicitly.  It should be
> > placed in /etc/fstab when it is created: by bsdinstall when it is used,
> > preferably by having the user select this explicitly, but probably with
> > noatime being the default.  It would be in the pre-configured fstab used
> > for VM images and SD card images.  Anyone building a root file system by
> > hand would have to deal with this to set a default.
>
> That could be great.  And it's not necessarily in contradiction with a
> sysctl.  If we have the latter, setting the default could happen through it
> and could be done by some startup script.  Then, the only thing not covered
> is the root filesystem, but even this is fixable by parsing the default
> line from the loader itself (it already parses '/etc/fstab' after all) and
> converting that specification to tunables passed to the kernel.
>

I really like Mike's idea. It obviates the need for the sysctl entirely. It
gets around the need to update loader.conf as well. It concentrates the
change in one place and
does so in a way that's not at all atime focused:  It could also be
generalized so that the FSTYPE could have different settings for different
types of filesystem (maybe unique flags that some file systems don't
understand).



> > I would then have the mount program look up and apply the default for
> things
> > like mounting a file system manually.  Perhaps it could have a -D option
> > to ignore defaults, e.g. for scripts that don't want to be subject to
> local
> > settings.
>
> This is a complication in the case of using sysctl knobs and the kernel
> being in charge of applying them as the default

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Warner Losh]

I'll add it to the gsoc list, unless someone submits a pull request to make
it so in the mean time :)

Warner

On Sun, Jan 28, 2024 at 11:29 AM Tomek CEDRO  wrote:

> Yes! Installer is always used in emergency it would be great to provide
> some servicing tools there too :-)
>
> For years I was using bootable Linux to fix people computers and it would
> be nice to have that in FreeBSD :-)
>
> +1 for memstick full with additional service utilities (fix partitions,
> mount fs, undelete, ntfs support, etc) :-)
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

Re: RCS and $FreeBSD$ purge

[Warner Losh]

On Fri, Jan 26, 2024, 7:32 PM Steve Kargl 
wrote:

> I'm currently syncing src/lib/msun with my private libm
> repository where I do much of my hacking on libm issues.
> In looking at diffs, I see a few lingering RCS and
> $FreeBSD$ tags.  For example, lib/msun/amd64/s_scalbnl.S
> contains
>
> /* RCSID("$NetBSD: s_scalbnf.S,v 1.4 1999/01/02 05:15:40 kristerw Exp $")
> */
>
> Should this be cleaned up or ws intentional left in the
> source code?
>

The NetBSD and OpenBSD ones were intentional.

Warner

>

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Warner Losh]

On Sat, Jan 27, 2024, 1:26 PM Cy Schubert  wrote:

> On January 26, 2024 7:13:15 PM PST, Ed Maste  wrote:
> >On Wed, 24 Jan 2024 at 15:43, Julian H. Stacey  wrote:
> >>
> >> Probably many do, clueless there's a proposal to remove them,
> >> as many wont be tracking lists (I havent been tracking lately,
> >> focused on moving home, other will have other distractions)
> >
> >As Rod suggested I'll have the tools emit a warning when they are run,
> >so that those users will become aware.
> >https://reviews.freebsd.org/D43585
> >https://reviews.freebsd.org/D43586
> >
>
> We can also point people to the two new ports.
>

The other thing we learned was that people use the installer to do
interesting things in the emergency holographic shell or the installer w/o
installing a system. We should look at ways we can shift to "mfs" so pkg
add can work in that env. Then the basis of the objections collapse. Then
it won't matter it isn't in base. Pkg add whatever recovery tools you think
you need or like to use, formerly in base or no... sure, it will go away...
but 99% of things are useful right away w/o a reboot...

I don't think it would be a hard project... likely one that could be done
by creating a miniroot that can create the mfs, extract a tarnall to it
then pivot root to that pkg could be bootsrrapped and it would be easy
from there...

Warner


-- 
> Cheers,
> Cy Schubert 
> FreeBSD UNIX:Web:  https://FreeBSD.org
> NTP: Web:  https://nwtime.org
> e^(i*pi)+1=0
>
> Pardon the typos. Small keyboard in use.
>
>

Re: meta mode

[Warner Losh]

On Sat, Jan 27, 2024, 6:12 AM void  wrote:

> Hi,
>
> I use meta-mode in /etc/src-env.conf so that if (for example) a small
> change in the kernel config is made, the machine doesn't take hours
> recompiling.
>
> Also, (I *think* it works this way) if src gets updated by git and
> world/kernel rebuilt it won't recompile already compiled files provided
> I don't delete /usr/obj/*
>
> But, from time to time, one might be required to make
> cleanworld && make cleandir (to be sure) && make clean (to be *really*
> sure)
>
> What circumstances & notices in /usr/src/UPDATING would require it?
>

Approximately never. The only time I've had issues were when the machine
crashed due to sudden power failure during the build which lead to the last
few .o files to be zero length with UFS.

Non clean normal builds have lots of issues with moved files. But meta mode
steers clear of them.

Warner

>

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Warner Losh]

On Fri, Jan 26, 2024 at 9:17 AM Rodney W. Grimes <
freebsd-...@gndrsh.dnsmgr.net> wrote:

> [ Charset UTF-8 unsupported, converting... ]
> > On Thu, Jan 25, 2024, 10:49?AM Rodney W. Grimes <
> > freebsd-...@gndrsh.dnsmgr.net> wrote:
> >
> > > > On Thu, Jan 25, 2024, 9:11?AM Ed Maste  wrote:
> > > >
> > > > > On Thu, 25 Jan 2024 at 11:00, Rodney W. Grimes
> > > > >  wrote:
> > > > > >
> > > > > > > These will need to be addressed before actually removing any of
> > > these
> > > > > > > binaries, of course.
> > > > > >
> > > > > > You seem to have missed /rescue.  Now think about that long
> > > > > > and hard, these tools classified as so important that they
> > > > > > are part of /rescue.  Again I can not stress enough how often
> > > > > > I turn to these tools in a repair mode situation.
> > > > >
> > > > > I haven't missed rescue, it is included in the work in progress I
> > > > > mentioned. Note that rescue has included gpart since 2007.
> > > > >
> > > >
> > > > What can fdisk and/or disklabel repair that gpart can't?
> > >
> > > As far as I know there is no way in gpart to get to the
> > > MBR cyl/hd/sec values, you can only get to the LBA start
> > > and end values:
> > >
> >
> > In the last 20 years when have you needed this?
>
> Last week, and probably about every other month for the last
> 30 years.
>

What. specifically did you need to change, for what hardware, etc?


> >
> > LBA start/end is all that's relevant these days. The CHS values are
> > completely ignored
> > by FreeBSD. We use packet mode in the boot loader since about Pentium
> 150MHz
> > or so.
>
> WORLD != FreeBSD, please STOP trying to assume that the users OF FreeBSD
> are ONLY using FreeBSD
>

Yes. And the world stopped using them too around that time, give or take 5
years.


> >
> > I did have to change these back in the day when we inferred what the CHS
> > geometry
> > was from the drive by looking at the MBR's partitions that you knew
> > (assumed really)
> > started on a cylinder value. This hasn't mattered in FreeBSD since sos
> > rewrote ata
> > the second time. DOS had to do these things because old-school MFM, RLL,
> etc
> > disks couldn't return their CHS, so DOS had to enshrine them in the MBR
> to
> > get
> > a hint (or have the drive type BIOS to just know). Since we use LBA
> > exclusively,
> > none of this matter to FreeBSD.
>
> WORLD != FreeBSD, and weither you like it or not your BIOS and CSM
> and UEFI are PROPBABLY reading those values and might even do a
> nice divide by zero for you should you write 0 in them.
>

Maybe rather than using all caps you could give a specific example. I've
not had to help anybody with CHS values in maybe 15 years, and even
then it was rare. In the prior 10 years to that I went from shipping product
where CHS had to be right, to shipping product where it didn't matter at
all on a set of SBCs that were lagging the industry by 5 years.

Also, UEFI doesn't care: It has no CHS APIs. It's all LBA. The only places
in the
standard where 'Cylinder' is mentioned is the (now obsolete) name for
fields in
a ATA packet that now mean different parts of the LBA for modern commands.


> >
> > I've certainly never needed to tweak these in single user mode on an
> > emergency
> > basis. Why? Because you can't get to single user mode because the kernel
> > won't
> > even load if you have these wrong. So either you are booting some rescue
> > disk
> > to fix that (in which case you can craft it for your special
> environment).,
> > or you are
>
> rescue disk == any FreeBSD install media from the last 20 years.
> your REALLY stuck in a small box Warner, please think outside
> that box.   You keep repeating FreeBSD FreeBSD FreeBSD, I have to
> inform you many of us who USE FreeBSD also USE other stuff, but
> we prefer to have FreeBSD be our goto system for this type of work.
>

Yes. I understand that. And with the packages installed, you still can
do that.


> > creating a special thing in multi-user, so you can install  For all these
> > use cases, fdisk
> > as a port is fine.
>
> I really do not want to have to maintain my own distribution.
>

And the project can no longer support programs that have buffer overflows
and other dangerous behavior when presented with untrusted information
from the disks that matters only to a few users.


> >
> > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
> > > start 63, size 8388513 (4095 Meg), flag 80 (active)
> > > beg: cyl 0/ head 1/ sector 1;
> > > end: cyl 1023/ head 15/ sector 63
> > >
> > > gpart show ada0
> > > => 63  8388545  ada0  MBR  (4.0G)
> > >63  8388513 1  freebsd  [active]  (4.0G)
> > >   8388576   32- free -  (16K)
> > >
> > > Now I have learned that gpart backup/restore CAN get me
> > > at least basic bsdlabel -e function, but again it has
> > > no access to all the stuff stored that showsup with
> > > bsdlabel -A.  Which this is now the third time I have
> > > asked "how do I do bsdlabel -A -e wit

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Warner Losh]

On Fri, Jan 26, 2024 at 9:02 AM Rodney W. Grimes <
freebsd-...@gndrsh.dnsmgr.net> wrote:

> -- Start of PGP signed section.
> > Am 2024-01-25 18:49, schrieb Rodney W. Grimes:
> > >> On Thu, Jan 25, 2024, 9:11?AM Ed Maste  wrote:
> > >>
> > >> > On Thu, 25 Jan 2024 at 11:00, Rodney W. Grimes
> > >> >  wrote:
> > >> > >
> > >> > > > These will need to be addressed before actually removing any of
> these
> > >> > > > binaries, of course.
> > >> > >
> > >> > > You seem to have missed /rescue.  Now think about that long
> > >> > > and hard, these tools classified as so important that they
> > >> > > are part of /rescue.  Again I can not stress enough how often
> > >> > > I turn to these tools in a repair mode situation.
> > >> >
> > >> > I haven't missed rescue, it is included in the work in progress I
> > >> > mentioned. Note that rescue has included gpart since 2007.
> > >> >
> > >>
> > >> What can fdisk and/or disklabel repair that gpart can't?
> > >
> > > As far as I know there is no way in gpart to get to the
> > > MBR cyl/hd/sec values, you can only get to the LBA start
> > > and end values:
> > > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
> > > start 63, size 8388513 (4095 Meg), flag 80 (active)
> > > beg: cyl 0/ head 1/ sector 1;
> > > end: cyl 1023/ head 15/ sector 63
> > >
> > > gpart show ada0
> > > => 63  8388545  ada0  MBR  (4.0G)
> > >63  8388513 1  freebsd  [active]  (4.0G)
> > >   8388576   32- free -  (16K)
> >
> > What are you using cyl/hd/sec values for on a system which runs FreeBSD
> > current or on which you would have to use FreeBSD-current in case of a
> > repair need? What is the disk hardware on those systems that you still
> > need cyl/hd/sec and LBA doesn't work? Serious questions out of
> > curiosity.
>
> Your making way to many assuptions, I deal with all sorts of operating
> systems, not just FreeBSD, and I often many drives from many systems
> connected to a FreeBSD box doing work to repair various anomolyies.
> FreeBSD is my swiss army knife of choice for fixing things.
>

Then install the port and be done with it.


> UEFI CMS and BIOS emplemntations can get very confused about a
> disk if these values are not properly set.  Also make a big
> mental note that GPT is really just a BIOS type 0x238 MBR
> entry and if that entry is messed up you are screwed.  I am
> not sure gpart has anyway to fix the protective MBR other
> than to rewrite it, probably destroying access to the whole
> contents of the disk.
>

That might be a legitimate complaint. But you can still fix that with
a port. Nothing stopping you from adding packages. And as pkgbase
rolls into life for FreeBSD 15, these would be omitted by default
anyway: they are too niche for today's needs to be in the already
too large default bundle.


> I am getting rather tired of hearing from people who just simply
> do not use these tools or can not phantom there are legitamate
> uses for them.  But it is evident the project has decided to
> remote them to ports no matter what, so be it, yet another
> reason for me to use less FreeBSD and more of someone elses
> product.
>

I'm saying that for most users gpart is sufficient. You have special needs
that the project can no longer meet with in-tree tools, but provides an easy
way to add them on by ports. None of your use cases require them to
be available in /rescue or single-user scenarios. They are all adequately
covered by a pkg install. Just like hundreds of other special use cases
that need a pkg. Need to partition your MMC card, install mmc-util. Need
to boot the NanoPi P2S card, install u-boot-nanopi-p2s. Etc. While cross
BSD functionality is nice to have, the current tools don't even support that
very well (try to use a address sanitizer version of disklabel and discover
the buffer overflows). So if it's important to you and maybe some others,
you'll need to "pay the freight" of that functionality by making these ports
and having the community of users that needs this to work continue making
them work as new bugs come to light.

FreeBSD's fdisk and disklabel are flawed in a number of other ways.
They most work cross platform, but aren't 100% what you want in all
cases. You can't write big endian disk labels on a little endian machine,
for example. The CHS handling in fdisk isn't quite right always for drives
that are larger than 1023 cylinders: we round differently than at least
3.0ish
Linux expects. disklabel has trouble writing to alternate locations that
some
BSD architectures need. Given that none of these problems have been fixed
in the 20ish years that I've been at least dimly aware of them suggests that
there's not a huge demand for coping with these edge cases.

Warner

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Warner Losh]

On Thu, Jan 25, 2024, 10:49 AM Rodney W. Grimes <
freebsd-...@gndrsh.dnsmgr.net> wrote:

> > On Thu, Jan 25, 2024, 9:11?AM Ed Maste  wrote:
> >
> > > On Thu, 25 Jan 2024 at 11:00, Rodney W. Grimes
> > >  wrote:
> > > >
> > > > > These will need to be addressed before actually removing any of
> these
> > > > > binaries, of course.
> > > >
> > > > You seem to have missed /rescue.  Now think about that long
> > > > and hard, these tools classified as so important that they
> > > > are part of /rescue.  Again I can not stress enough how often
> > > > I turn to these tools in a repair mode situation.
> > >
> > > I haven't missed rescue, it is included in the work in progress I
> > > mentioned. Note that rescue has included gpart since 2007.
> > >
> >
> > What can fdisk and/or disklabel repair that gpart can't?
>
> As far as I know there is no way in gpart to get to the
> MBR cyl/hd/sec values, you can only get to the LBA start
> and end values:
>

In the last 20 years when have you needed this?

LBA start/end is all that's relevant these days. The CHS values are
completely ignored
by FreeBSD. We use packet mode in the boot loader since about Pentium 150MHz
or so.

I did have to change these back in the day when we inferred what the CHS
geometry
was from the drive by looking at the MBR's partitions that you knew
(assumed really)
started on a cylinder value. This hasn't mattered in FreeBSD since sos
rewrote ata
the second time. DOS had to do these things because old-school MFM, RLL, etc
disks couldn't return their CHS, so DOS had to enshrine them in the MBR to
get
a hint (or have the drive type BIOS to just know). Since we use LBA
exclusively,
none of this matter to FreeBSD.

I've certainly never needed to tweak these in single user mode on an
emergency
basis. Why? Because you can't get to single user mode because the kernel
won't
even load if you have these wrong. So either you are booting some rescue
disk
to fix that (in which case you can craft it for your special environment).,
or you are
creating a special thing in multi-user, so you can install  For all these
use cases, fdisk
as a port is fine.

sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
> start 63, size 8388513 (4095 Meg), flag 80 (active)
> beg: cyl 0/ head 1/ sector 1;
> end: cyl 1023/ head 15/ sector 63
>
> gpart show ada0
> => 63  8388545  ada0  MBR  (4.0G)
>63  8388513 1  freebsd  [active]  (4.0G)
>   8388576   32- free -  (16K)
>
> Now I have learned that gpart backup/restore CAN get me
> at least basic bsdlabel -e function, but again it has
> no access to all the stuff stored that showsup with
> bsdlabel -A.  Which this is now the third time I have
> asked "how do I do bsdlabel -A -e with gpart"?  One
> person at least answered that with:
> gpart backup GEOM >backup
> vi backup
> gpart restore GEOM
>

OK Let's look at these extra fields:

# /dev/md0:
type: unknown
disk: amnesiac
label:
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 130
sectors/unit: 2097152
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0 # milliseconds
track-to-track seek: 0 # milliseconds
drivedata: 0

type isn't used at all in FreeBSD.
disk is for /etc/disktab, something we've not really needed since FreeBSD 3
or so.
label can be set with gpart add/modify -l.
I've never used flags. Can't speak to that.
bytes/sector: This is a physical property of the drive, not the label.  You
can find it with gpart list:
   % gpart list md0
   
   Consumers:
   1. Name: md0
  Mediasize: 1073741824 (1.0G)
  Sectorsize: 512
The rest of this/that are reported or you can do math:
fwheads: 255 <- tracks/cylinder
fwsectors: 63 <-- sectors/track
last: 2097151 <-- sectors/unit - 1
now, cylenders and sectors/cylinder you can compute. geom does this for
reading/writing disk labels.
rpm is hard coded to 3600 these days. FreeBSD doesn't care.
The rest are for interleaving, which FreeBSD doesn't do, so we don't care.

So you can influence the values, but they aren't used for anything by
FreeBSD
that matters.

What if you need them for something else? Then just use the disklabel port.
You'll never need to hack them tn single user mode, so you can use the port
for all use cases.

Warner


> Warner
> --
> Rod Grimes
> rgri...@freebsd.org
>

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Warner Losh]

On Thu, Jan 25, 2024, 9:11 AM Ed Maste  wrote:

> On Thu, 25 Jan 2024 at 11:00, Rodney W. Grimes
>  wrote:
> >
> > > These will need to be addressed before actually removing any of these
> > > binaries, of course.
> >
> > You seem to have missed /rescue.  Now think about that long
> > and hard, these tools classified as so important that they
> > are part of /rescue.  Again I can not stress enough how often
> > I turn to these tools in a repair mode situation.
>
> I haven't missed rescue, it is included in the work in progress I
> mentioned. Note that rescue has included gpart since 2007.
>

What can fdisk and/or disklabel repair that gpart can't?

Warner

>

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Warner Losh]

On Wed, Jan 24, 2024, 10:07 PM Cy Schubert 
wrote:

> In message <202401242347.40onlwkz099...@gndrsh.dnsmgr.net>, "Rodney W.
> Grimes"
> writes:
> > > I would agree personally, to moving to ports (eg ports/sysutils) with
> > > a DEPRECATED in the DESCR or something, or better yet a Make
> > > invokation event to say "superceded, here is how to proceed against
> > > advice") or something.
> >
> > They are totally useless as ports when your booted from install
> > media and working from a standalone shell.  These are the exact
> > times you want things like fdisk and bsdlabel so you can figure
> > out wtf is going on, and bsdinstall is NOT gona help you.
>
> This is certainly a good point.
>

What can they do that gpart can't do?

Warner

>
> >
> > I know there are a boat load of people that have built there
> > own installers for VM's and stuff, running UFS and I bet you
> > they are using MBR disks too.  PLEASE do not kick these tiny
> > little and very usable and pretty univeral (as far as I know
> > ALL BSD's have fdisk and bsdlabel/disklabel) tools out of
> > the base system.
> >
> > The world is NOT 2TB nvme drives with GPT, EFI and ZFS,
> > yours might not be, but I am pretty certain I am not
> > alone in this other world.
> >
> > > -G
> > >
> > > On Thu, Jan 25, 2024 at 3:30?AM Warner Losh  wrote:
> > > >
> > > > On Wed, Jan 24, 2024 at 8:45?AM Ed Maste  wrote:
> > > >>
> > > >> MBR (PC BIOS) partition tables were historically maintained with
> > > >> fdisk(8), but gpart(8) has long been the preferred method for
> working
> > > >> with partition tables of all types. fdisk has been declared as
> > > >> obsolete in the man page since 2015. Similarly BSD disklabels were
> > > >> historically maintained with bsdlabel. It does not yet have a
> > > >> deprecation notice - I have proposed a man page addition in
> > > >> https://reviews.freebsd.org/D43563.
> > > >>
> > > >> I would like to disconnect these from the build, and subsequently
> > > >> remove them. This is prompted by a recent bsdlabel bug report which
> > > >> uncovered a longstanding buffer overflow in that tool. Effort is
> much
> > > >> better focused on contemporary, maintained tools rather than
> > > >> investigating issues in deprecated ones. Removing these tools would
> > > >> happen in FreeBSD 15 only (no change in 14 or 13).
> > > >>
> > > >> Code review to disconnect fdisk: https://reviews.freebsd.org/D43575
> > > >>
> > > >> Note that this effort is limited to these maintenance tools only -
> > > >> there is no change to kernel or gpart support for MBR or BSD
> > > >> disklablel partitioning. That said, MBR partitioning and BSD
> > > >> disklabels are best considered legacy formats and should be avoided
> > > >> for new installations, if possible.
> > > >>
> > > >> If anyone is using fdisk and/or bsdlabel rather than gpart I would
> > > >> appreciate knowing what is preventing you from using the
> contemporary
> > > >> tools.
> > > >
> > > >
> > > > nanobsd's legacy.sh still is using disklabel in two spots.
> > > >
> > > > But one is to just do gpart create -s bsd and the other is to
> display it.
> >  Easy
> > > > to fix, but even easier to delete legacy.sh entirely. It's not
> really nee
> > ded any
> > > > more and was a product of CHS addressing... Now that we use LBA, it's
> > > > better to use the new embedded ones. Even at $WORK where we kinda
> > > > use legacy, we replace the partitioning stuff with our own custom
> thing..
> > .
> > > >
> > > > Those are the only users in the tree, but not for long :)
> > > >
> > > > fdisk was good, but somewhere around the CHS -> LBA transition things
> > > > got weird with it, and for really big disks there were reports of
> issues
> > that
> > > > I could never encounter when I set out to fix them... Most likely
> due to
> > a
> > > > mismatch in the CHS data and the LBA data being recorded in the MBR.
> > > > The in-kernel gpart copes so much better.
> > > >
> > > > I wouldn't object to making these ports, but both these programs use
> 'sek
> > ret'
> > > > bits from the kernel that might not remain exposed as we clean
> things up.
> > > > Though the IOCTLs they do (or used to do) may no longer be relevant.
> It's
> > > > been so long that I've forgotten
> > > >
> > > > Warner
> > --
> > Rod Grimes
>  rgri...@freebsd.or
> > g
> >
>
>
> --
> Cheers,
> Cy Schubert 
> FreeBSD UNIX: Web:  https://FreeBSD.org
> NTP:   Web:  https://nwtime.org
>
> e^(i*pi)+1=0
>
>
>

Re: Removing fdisk and bsdlabel (legacy partition tools)

[Warner Losh]

On Wed, Jan 24, 2024 at 8:45 AM Ed Maste  wrote:

> MBR (PC BIOS) partition tables were historically maintained with
> fdisk(8), but gpart(8) has long been the preferred method for working
> with partition tables of all types. fdisk has been declared as
> obsolete in the man page since 2015. Similarly BSD disklabels were
> historically maintained with bsdlabel. It does not yet have a
> deprecation notice - I have proposed a man page addition in
> https://reviews.freebsd.org/D43563.
>
> I would like to disconnect these from the build, and subsequently
> remove them. This is prompted by a recent bsdlabel bug report which
> uncovered a longstanding buffer overflow in that tool. Effort is much
> better focused on contemporary, maintained tools rather than
> investigating issues in deprecated ones. Removing these tools would
> happen in FreeBSD 15 only (no change in 14 or 13).
>
> Code review to disconnect fdisk: https://reviews.freebsd.org/D43575
>
> Note that this effort is limited to these maintenance tools only -
> there is no change to kernel or gpart support for MBR or BSD
> disklablel partitioning. That said, MBR partitioning and BSD
> disklabels are best considered legacy formats and should be avoided
> for new installations, if possible.
>
> If anyone is using fdisk and/or bsdlabel rather than gpart I would
> appreciate knowing what is preventing you from using the contemporary
> tools.
>

nanobsd's legacy.sh still is using disklabel in two spots.

But one is to just do gpart create -s bsd and the other is to display it.
Easy
to fix, but even easier to delete legacy.sh entirely. It's not really
needed any
more and was a product of CHS addressing... Now that we use LBA, it's
better to use the new embedded ones. Even at $WORK where we kinda
use legacy, we replace the partitioning stuff with our own custom thing...

Those are the only users in the tree, but not for long :)

fdisk was good, but somewhere around the CHS -> LBA transition things
got weird with it, and for really big disks there were reports of issues
that
I could never encounter when I set out to fix them... Most likely due to a
mismatch in the CHS data and the LBA data being recorded in the MBR.
The in-kernel gpart copes so much better.

I wouldn't object to making these ports, but both these programs use
'sekret'
bits from the kernel that might not remain exposed as we clean things up.
Though the IOCTLs they do (or used to do) may no longer be relevant. It's
been so long that I've forgotten

Warner

Re: How to upgrade an EOL FreeBSD release or how to make it working again

[Warner Losh]

On Wed, Jan 17, 2024 at 3:54 PM Mario Marietto 
wrote:

> Hello to everyone.
>
> I'm trying to copy the Chromebook's SNOW source files that have been included 
> on the FreeBSD 11
> revision 269385 to the new FreeBSD 13 revision 373300. It has compiled 
> correctly world,but when it
> starts to compile the kernel,it gives a lot of "unknown option" errors. Is 
> there a way to fix them ?
>
> # svn co http://svn.freebsd.org/base/head@269385 ./head-269385 ; taken from 
> this tutorial :
>
> https://wiki.freebsd.org/arm/Chromebook
>
> # svn co http://svn.freebsd.org/base/head ./head-373300
> # cp ./head-269395/sys/arm/conf/CHROMEBOOK-SNOW ./head-373300/sys/arm/conf
> # cd ./head-373300
> # make TARGET_ARCH=armv7 KERNCONF=CHROMEBOOK-SNOW buildworld buildkernel
>
> I tried also with : make TARGET_ARCH=armv6 KERNCONF=CHROMEBOOK-SNOW 
> buildworld buildkernel,but it
> didn't make any difference.
>
> .
> .
> --
> >>> World build completed on Wed Jan 17 21:27:04 CET 2024
> >>> World built in 14203 seconds, ncpu: 16
> --
> make[1]: "/mnt/zroot2/zroot2/OS/Chromebook/head-373300/Makefile.inc1" line 
> 341: SYSTEM_COMPILER: lib
> clang will be built for bootstrapping a cross-compiler.
> make[1]: "/mnt/zroot2/zroot2/OS/Chromebook/head-373300/Makefile.inc1" line 
> 346: SYSTEM_LINKER: libcl
> ang will be built for bootstrapping a cross-linker.
>
> --
> >>> Kernel build for CHROMEBOOK-SNOW started on Wed Jan 17 21:27:04 CET 2024
> --
> ===> CHROMEBOOK-SNOW
> mkdir -p /usr/obj/mnt/zroot2/zroot2/OS/Chromebook/head-373300/arm.armv7/sys
>
> --
> >>> stage 1: configuring the kernel
> --
> cd /mnt/zroot2/zroot2/OS/Chromebook/head-373300/sys/arm/conf;  
> PATH=/usr/obj/mnt/zroot2/zroot2/OS/Ch
> romebook/head-373300/arm.armv7/tmp/bin:/usr/obj/mnt/zroot2/zroot2/OS/Chromebook/head-373300/arm.armv
> 7/tmp/usr/sbin:/usr/obj/mnt/zroot2/zroot2/OS/Chromebook/head-373300/arm.armv7/tmp/usr/bin:/usr/obj/m
> nt/zroot2/zroot2/OS/Chromebook/head-373300/arm.armv7/tmp/legacy/usr/sbin:/usr/obj/mnt/zroot2/zroot2/
> OS/Chromebook/head-373300/arm.armv7/tmp/legacy/usr/bin:/usr/obj/mnt/zroot2/zroot2/OS/Chromebook/head
> -373300/arm.armv7/tmp/legacy/bin:/usr/obj/mnt/zroot2/zroot2/OS/Chromebook/head-373300/arm.armv7/tmp/
> legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin  config  -d 
> /usr/obj/mnt/zroot2/zroot2/OS/Chromebo
> ok/head-373300/arm.armv7/sys/CHROMEBOOK-SNOW  -I 
> '/mnt/zroot2/zroot2/OS/Chromebook/head-373300/sys/a
> rm/conf' -I '/mnt/zroot2/zroot2/OS/Chromebook/head-373300/sys/arm/conf'  
> '/mnt/zroot2/zroot2/OS/Chro
> mebook/head-373300/sys/arm/conf/CHROMEBOOK-SNOW'
> WARNING: duplicate option `DEBUG' encountered.
>
> ./head-373300/sys/arm/conf/CHROMEBOOK-SNOW: unknown option "IPI_IRQ_END" / 
> "IPI_IRQ_START / ARM_L2_PIPT"
>
> and so on...
>
> these options are included inside the file "std.exynos5250" (that I have 
> copied from the old to the new
>
> source code). What I'm trying to do to stop these error is to comment the 
> offending lines :
>
>
> nano ./head-373300/sys/arm/samsung/exynos/std.exynos5250 :
>
> #optionsIPI_IRQ_START=0
> #optionsIPI_IRQ_END=15
>
>
These likely require changes to adopt exynos to INTRNG.


> #optionsARM_L2_PIPT
>
> This is likely a nop. It was for ARMv4/5 only and google tells me
exynos5250 was a dual core Cortex A-15, which is armv7.



> but I suspect that a lot of options will be missing and the more comments
> I will make,the more the chance that it will not work will increase. ...
>

There's likely a lot of work here...

Warner


>
> On Mon, Jan 15, 2024 at 7:48 PM Mario Marietto 
> wrote:
>
>> Hello.
>>
>> Do you have deleted forever the set of packages and ports for FreeBSD 11
>> or you keep them stored in DVDs that I can buy or download for a small
>> amount of money ? If yes,where ? To rebuild everything is out of my
>> expertise.
>>
>> On Mon, Jan 15, 2024 at 7:15 PM David Chisnall 
>> wrote:
>>
>>> On 15 Jan 2024, at 16:46, Mario Marietto  wrote:
>>> >
>>> > The ARM Chromebook is based on armv7,it is still recent.
>>>
>>> For reference, the ARMv7 architecture was introduced in 2005.  The last
>>> cores that implemented the architecture were released in 2014.  This is not
>>> a ‘recent’ architecture, it’s one that’s 19 years old and has been largely
>>> dead for several years.
>>>
>>> > But let's change perspective for a moment,don't think about the ARM
>>> Chromebook. My question is : how to upgrade FreeBSD when it goes EOL.
>>>
>>> Generally, run `freebsd-update`.  This is a very different question from
>>> ‘how do I do a new install of an old an unsupported version?'
>>>
>>> > I ask this because there is a huge differ

Re: suspend to idle support

[Warner Losh]

On Mon, Jan 15, 2024 at 10:24 AM Oleksandr Kryvulia 
wrote:

> Hello,
> What is a status of support suspend to idle? I found only two related
> reviews D17675 and D17676 and no more any information. It is a very
> desirable thing on modern laptops, where s3 is not supported like my X1
> Carbon gen11[1].
>
> [1] https://wiki.freebsd.org/Laptops/Thinkpad_X1_Carbon
>

It works for me on my Lenovo Yoga that's a couple of years old, modulo the
build-in wifi card.

Warner

Re: noatime on ufs2

[Warner Losh]

On Sun, Jan 14, 2024, 10:24 AM Lyndon Nerenberg (VE7TFX/VE6BBM) <
lyn...@orthanc.ca> wrote:

> > > I do not have a strong opinion w.r.t. atime, but I do believe that
> > > changing the default would be a POLA violation.
>
> I'm not prepared to just accept that at face value.
>
> I can't think of a single instance in at least the last three decades
> where I have actually used or needed atime for *anything*.  And
> over that time period I have been responsible for running hundreds
> of UNIX servers.
>
> I'm really interested in hearing from people who actively use
> atime on a regular basis for non-trivial purposes.  What are
> the modern use cases for atime?
>

The consensus was we'd fix it in the installer.

We can't change ZFS easily, and discovery of the problem, should your
assertion be wrong, for UFS means metadata loss that can't be recovered.

By pushing to the installer, most installations get most of benefits. And
people with special needs see the issue and can make an informed choice.

Though in all honesty, I've never been able to measure a speed difference.
Nor have I worn out a ssd due to the tiny increase in write amp. Old
(<100MB) SD and CF cards included. This includes my armv7 based dns server
that I ran for a decade on a 256MB SD card with no special settings and
full read/write and lots of logging. So the harm is minimal typically. I'm
sure there are cases that it matters more than my experience. And it is
good practice to enable noatime. Just that failure to do so typically has
only a marginal effect.

Warner

--lyndon
>
>

Re: noatime on ufs2

[Warner Losh]

On Thu, Jan 11, 2024 at 6:59 AM Mike Karels  wrote:

> On 11 Jan 2024, at 7:30, Miroslav Lachman wrote:
>
> > On 11/01/2024 09:54, Tomoaki AOKI wrote:
> >> On Thu, 11 Jan 2024 08:36:24 +0100
> >> Alexander Leidinger  wrote:
> >
> > [..]
> >
> >>> There's one possibility which nobody talked about yet... changing the
> >>> default to noatime at install time in fstab / zfs set.
> >>>
> >>> I fully agree to not violate POLA by changing the default to noatime in
> >>> any FS. I always set noatime everywhere on systems I take care about,
> no
> >>> exceptions (any user visible mail is handled via maildir/IMAP, not
> >>> mbox). I haven't made up my mind if it would be a good idea to change
> >>> bsdinstall to set noatime (after asking the user about it, and later
> >>> maybe offer  the possibility to use relatime in case it gets
> >>> implemented). I think it is at least worthwile to discuss this
> >>> possibility (including what the default setting of bsdinstall should be
> >>> for this option).
> >
> > [..]
> >
> >> A different aspect of view.
> >> Nowadays, storages are quickly moving from HDD, aka spinning rust, to
> >> SSD.
> >> And SSD has a risk of sudden-death of wearing out. In ancient days, HDD
> >> dies not suddenly and at least some cases admins could have time to
> >> replace suspicious drives. But SSD dies basically suddenly.
> >>
> >> IMHO, this could be a valid reason to violate POLA. In limited use
> >> cases, atime is useful, at the cost of amplified write accesses.
> >> But in most cases, it doesn't have positive functionality nowadays.
> >>
> >> Anyway, we should have time to discuss whether it should be done or not
> >> until upcoming stable/15 branch. stable/14 is already here and it
> >> wouldn't be a good thing to MFC. Only *.0-RELEASE should be the point
> >> to introduce this, unlike discussion about vi and ee on forums.
> >
> > The default values change over time as the needs of people, programs and
> hardware change. Many values for sysctls changed over time.
> > If "noatime" can help people to not trash SSD / SD storage, I can
> imagine that bsdinstall will detect the storage type (simple guess can be
> made by diskinfo -v) and offer a "noatime" option that the user can
> check/uncheck. This option can be pre-selected for flash based storage.
> > I don't care defaults for my-self, I can change them, but sane defaults
> should be beneficial for new users without much background knowledge.
> >
> > Kind regards
> > Miroslav Lachman
>
> I like the idea of an option in bsdinstall, but I don't think it is
> necessary
> to check the storage type.  It could simply default to noatime.
>
> I think we should automatically use noatime on SD card images (where
> bsdinstall
> doesn't get used).
>
> Separately, I think a relatime option would be a good compromise, and I
> would
> probably use it.
>

I think these are sensible steps. We already do something similar for ZFS.

Warner

Re: noatime on ufs2

[Warner Losh]

On Wed, Jan 10, 2024 at 3:01 AM Olivier Certner  wrote:

> Hi Warner,
>
> > It has also been used for almost as long to see if log files have changed
> > if you set your MAIL variable to that. So not just for email...
>
> This seems to be an example in point of a "niche" scenario, both in terms
> of spread of usage (even then) and the fact that it's easy to get the
> functionality by other means.
>

Yea... tail -f does it too... But this is a useful way to get your shell to
tell you when something has changed. It's a widely used trick (or has been
in the past). But it really has nothing to do with atime... Just a clever
use of MAIL variable.


> Again, I'm not opposing anyone from working on "relatime" if they
> personally have a strong need and motivation.  I'm not even asking for
> removing the "atime" functionality, which can have its uses.
>

Yea, relatime has some interesting use cases: Is this binary / library in
use is one such case. The fact that you've completely omitted that use case
suggests that the analysis of atime's usefulness (or its lack) is at least
incomplete.


> What I'm saying is that, based on others' input so far, my own (long, even
> if not as long as yours) experience and some late reflection, is that
> "noatime" should be the default (everywhere, all mounts and all FSes), and
> that working on "relatime" won't make any real difference for most users
> (IOW, I think that developing "relatime" is a bad idea *in general*).  And
> I think this is a sufficiently reasonable conclusion that anyone with the
> same inputs would conclude the same.  So, if it's not the case, I would be
> interested in knowing why, ideally.
>

relatime would work great on /usr/local where you have a lot of programs:
you reduce a lot of traffic. It's quite useful to know what packages are in
use or not based on when they were last accessed, not just last installed.

I'm not sure this is a great notion to have everywhere. I think your
analysis needs more inputs.

Warner


> Regards.
>
> --
> Olivier Certner

Re: noatime on ufs2

[Warner Losh]

On Tue, Jan 9, 2024, 11:11 AM Steffen Nurpmeso  wrote:

> rob...@rrbrussell.com wrote in
>  <5f370bce-bcdb-47ea-aaa7-551ee092a...@app.fastmail.com>:
>  |On Tue, Jan 9, 2024, at 05:13, void wrote:
>  |> On Tue, Jan 09, 2024 at 09:47:59AM +0100, Olivier Certner wrote:i
>  |>> So, to me, at this point, it still sounds more than a gimmick
>  |>> than something really useful.  If someone has a precise use case
>
> Email existence checks are in UNIX for many decades.
> In fact since 1974-11-26 when Ken Thompson added that to login(1).
> "You have new mail" is in BSD since
>
>   Commit: Bill Joy 
>   CommitDate: 1978-11-05 19:59:54 -0800
>

It has also been used for almost as long to see if log files have changed
if you set your MAIL variable to that. So not just for email...

Warner

Start development on BSD 3
> Create reference copy of all prior development files
>
> in BSD Mail and csh(1).
> And today in bash(1), for example, there can be read
>
> /* If the user has just run a program which manipulates the
>mail file, then don't bother explaining that the mail
>file has been manipulated.  Since some systems don't change
>the access time to be equal to the modification time when
>the mail in the file is manipulated, check the size also.  If
>the file has not grown, continue. */
> if ((atime >= mtime) && !file_is_bigger)
>   continue;
>
> /* If the mod time is later than the access time and the file
>has grown, note the fact that this is *new* mail. */
> if (use_user_notification == 0 && (atime < mtime) &&
> file_is_bigger)
>   message = _("You have new mail in $_");
>
> I would not exactly call this a gimmick.
> On Linux mount(8) from https://github.com/karelzak/util-linux says
>
>relatime
>Update inode access times relative to modify or change time. Access
>time is only updated if the previous access time was earlier than
>or equal to the current modify or change time. (Similar to noatime,
>but it doesn’t break mutt(1) or other applications that need to
>know if a file has been read since the last time it was modified.)
>
> and this is what i use, except for some noatime mount points
> (/x/doc, /x/music, /x/pub, to be exact).
>
> --steffen
> |
> |Der Kragenbaer,The moon bear,
> |der holt sich munter   he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
>
>

Re: noatime on ufs2

[Warner Losh]

On Mon, Jan 8, 2024 at 1:41 PM Xin LI  wrote:

>
>
> On Sun, Jan 7, 2024 at 5:27 AM void  wrote:
>
>> Hi,
>>
>> Does /var/mail still need atime?
>>
>> I've installed a ufs2-based -current main-n267425-aa1223ac3afc on
>> rpi4/8BG which installs into one / . If it's mounted with noatime,
>> will it have consequences for /var/mail ?
>
>
> It doesn't matter if you don't normally receive emails locally (nowadays,
> it's rare).
>
> If you do receive emails locally, it depends on what application(s) that
> you are using.  Most applications nowadays check both mtime and atime plus
> sizes of the mailbox file and do not rely on atime (because they saved the
> previous mtime).  Without atime updates, some application may claim that
> you have new mail when the mailbox is not empty when they first start.
>
> That's said, if I were you and I'm using some flash based storage (with
> rpi it's highly likely) regardless if I'm using mail locally; most of the
> time the data is not really useful for anything, and it does increase the
> wear of your storage.
>
> This reminds me that -- we probably should have implemented the Linux
> "relative atime" (update atime iff (atime <= mtime || atime <= ctime) ||
> atime is older than a day) and "no diratime" (don't update directory atime)
> for UFS and make the "relatime" option the default; I had an
> incomplete implementation about a decade ago somewhere but with the recent
> VFS changes it's probably easier to start over.  IMHO, updating atime every
> time when a file is accessed is not really providing useful data (like who
> accessed the file, etc.) for audit purposes and does come with performance
> (more write I/O) and reliability (wear of SSD and other flash devices)
> cost, therefore not generally useful in modern days.  The Linux relative
> atime is a pretty clever idea that has covered the most useful use case for
> atime (Did I accessed the file after it was last modified) and also
> provided a coarse-grained update (capped to daily, which is a reasonable
> compromise) to the atime.
>

I like that compromise. It will miss a lot, but that 'miss' results in
atime being good to only about a day, which for the vast majority of things
is fine.

Warner


> Cheers,
>

Re: Move u2f-devd into base?

[Warner Losh]

On Mon, Jan 8, 2024 at 10:30 AM Xin LI  wrote:

> On Mon, Jan 8, 2024 at 7:19 AM Warner Losh  wrote:
>
>> On Mon, Jan 8, 2024, 7:55 AM Christian Weisgerber 
>> wrote:
>>
>>> We have FIDO/U2F support for SSH in base.
>>>
>>> We also have a group "u2f", 116, in the default /etc/group file.
>>>
>>> Why do we keep the devd configuration (to chgrp the device nodes)
>>> in a port, security/u2f-devd?  Can't we just add this to base, too?
>>> It's just another devd configuration file.
>>>
>>
>> This properly belongs to devfs.conf no? Otherwise it's a race...
>>
>
> That's a good point.  But I think in practice the race (if I'm
> understanding correctly, there would be a window where the device node
> showed up, but with the standard permissions until devd kicks in and runs
> "action" steps to change it) would probably not matter because the
> consumers (Chromium?) would be polling for the device and when opening
> failed, they would retry, as the security key is not guaranteed to be
> present when a website asks for it, and it's perfectly natural for the
> browser to see the security key getting attached and detached while it is
> running.
>

I just don't like this depending on devd not dropping the arrival bit (due
to too much congestion of events) and having a resulting broken system.
It's half-assed today, but it's half-assed enough that it works enough of
the time the issue hasn't been pressing (which is my way of agreeing with
you: its imperfect, but it works almost all the time today). Working well
enough suggests we shouldn't 'gate' this change to a perfect solution
Especially since we're a bit short handed in the usb world after Hans'
tragic passing.


> I would say it's a good idea to have something there in place to support
> these security keys (possibly also cameras, etc.), especially considering
> the base OpenSSH now supports U2F devices.  It's probably a good idea to
> have adduser / installer to have a defined "interactive local user" groups
> (u2f, video, etc. come to mind) that users are added into by default to
> provide a reasonable out-of-box default too.
>

Totally agree here.

Warner

Re: Move u2f-devd into base?

[Warner Losh]

On Mon, Jan 8, 2024 at 9:35 AM Kyle Evans  wrote:

> On 1/8/24 10:30, Tomoaki AOKI wrote:
> > On Mon, 8 Jan 2024 08:18:38 -0700
> > Warner Losh  wrote:
> >
> >> On Mon, Jan 8, 2024, 7:55〓AM Christian Weisgerber 
> >> wrote:
> >>
> >>> We have FIDO/U2F support for SSH in base.
> >>>
> >>> We also have a group "u2f", 116, in the default /etc/group file.
> >>>
> >>> Why do we keep the devd configuration (to chgrp the device nodes)
> >>> in a port, security/u2f-devd?  Can't we just add this to base, too?
> >>> It's just another devd configuration file.
> >>>
> >>
> >> This properly belongs to devfs.conf no? Otherwise it's a race...
> >>
> >> Warner
> >>
> >> --
> >>> Christian "naddy" Weisgerber
> na...@mips.inka.de
> >
> > It's devd.conf materials. It actually is security/usf-devd/files
> > u2f.conf and its contents is sets of notify 100 { match "vendor" ...
> > match "product" ... action "chgrpy u2f ..." };.
> > Some hase more items in it, though.
> >
> > So it should be in ports to adapt for latest products more quickly than
> > in base, I think.
> >
>
> I don't see any obvious reason that we can't compromise and have a
> baseline of products in base and just use the port for new products not
> yet known to base.  These vendors presumably aren't going to quickly
> repurpose some PID for a non-u2f thing, much less in a way that we care
> about.
>

Yea, I just wonder why it has to be devd.conf, and not devfs.conf. What are
we missing from that to make this doable generically? If we want it safe, we
may need some additional work around the whole ugen thing it uses.

Warner

Re: Move u2f-devd into base?

[Warner Losh]

On Mon, Jan 8, 2024, 7:55 AM Christian Weisgerber 
wrote:

> We have FIDO/U2F support for SSH in base.
>
> We also have a group "u2f", 116, in the default /etc/group file.
>
> Why do we keep the devd configuration (to chgrp the device nodes)
> in a port, security/u2f-devd?  Can't we just add this to base, too?
> It's just another devd configuration file.
>

This properly belongs to devfs.conf no? Otherwise it's a race...

Warner

-- 
> Christian "naddy" Weisgerber  na...@mips.inka.de
>
>

Re: git repo port issues?

[Warner Losh]

On Thu, Jan 4, 2024, 12:14 PM Jamie Landeg-Jones  wrote:

> Tomoaki AOKI  wrote:
>
> >
> > Or create database (key-value store would be sufficient) storing commit
> > order (like r* of svn) and commit hash.
> > I'm still not certain whether commit order or commit hash should be the
> > "key". Possibly store hash as the key fisrt and store assigned MONOTONIC
> > order as value, then, add the just-stored order as key and hash as
> > value in another database would be neeed. If the database can contain 2
> > value for 1 key, it would be suitable for you to store the assigned
> > time in UTC as "when it is committed to FreeBSD master repo".
>
> I do miss the incrementing "r" value - it's a nice immediate way to
> tell which update is more recent. Actually, to me, that is more important
> than the date - I've attempted to base my changes on the date due to the
> absense of such a useful field.
>

See sys/conf/newvers.sh for the 'n' value we use in uname strings.  It's a
linear count of commits on the first-parent branch back to the start of the
repo.

Also, the dates usualy are first order correct and i use them for the stats
i run. Though I've also just dropped tags on the first commit of each year
too...

Also be advised that the pre FreeBSD 8 or so tree still has some surprising
artifacts in it.

Warner

Actually, I think I may implement such a thing on my local cgit repo.
>
> https://cgit.dyslexicfish.net/ports/latest/tree/
> https://cgit.dyslexicfish.net/src/current/tree/
>
> Cheers, Jamie
>
>

Re: devel/nspr: Fails to build on 1500008 5f71f9636efa

[Warner Losh]

On Fri, Dec 29, 2023, 6:52 AM  wrote:

>
>
> > On Dec 29, 2023, at 14:43, tue...@freebsd.org wrote:
> >
> >> On Dec 29, 2023, at 14:07, Konstantin Belousov 
> wrote:
> >>
> >> On Fri, Dec 29, 2023 at 01:50:34PM +0100, Dimitry Andric wrote:
> >>> The problem is really that our kernel headers (those under sys/)
> require C99. The only thing that
> https://cgit.freebsd.org/src/commit/?id=a8b70cf26030d68631200619bd1b0ad35b34b6b8
> did was move two static inline functions from sys/netinet/tcp_var.h to
> sys/netinet/tcp.h, and it looks like the former header is never directly
> included by ports. The latter is, so those ports should be switched to C99,
> or the sys/netinet/tcp.h header should be fixed to use __inline instead.
> >>>
> >> netinet/tcp.h is required by POSIX, and as far as we support
> applications
> >> using C89, it must stay C89 compatible.
> >>
> >> But why userspace would need these newish accessors at all?  IMO at
> least
> > TCP is now using flags that are not contained in the th_flags field
> anymore,
> > but also use the th_x2 field.
> >
> > People were assuming that all flags are in th_flags and th_x2 is not
> used and
> > used it for internal processing. This was causing problems.
> >
> > Using the accessor functions hides the split between th_flags and th_x2.
> > See, for example,
> >
> https://cgit.FreeBSD.org/src/commit/?id=a8b70cf26030d68631200619bd1b0ad35b34b6b8
> <
> https://cgit.freebsd.org/src/commit/?id=a8b70cf26030d68631200619bd1b0ad35b34b6b8
> >
> >> for userspace they do not add any value except additional namespace
> pollution.
> >> They should be hidden under #ifdef _KERNEL.
> > That might be possible. A kernel build with this completes. Haven't
> checked a
> > buildlworld. Will report when its done.
> Thinking about it: since we expose the TCP flags to the world, we should
> also expose the accessors related to it.
>

Yea. __inline is the way to go.

I should add this test to the includes test we already run at buildworld
time...

Warner

Best regards
> Michael
> >
> > Best regards
> > Michael
> >>
> >>> -Dimitry
> >>>
>  On 29 Dec 2023, at 13:30, Nuno Teixeira  wrote:
> 
>  (...)
>  -ansi == Same as -std=c89
> 
>  So it seems correct to remove it when -std=c99 is used.
> 
>  Nuno Teixeira  escreveu no dia sexta,
> 29/12/2023 à(s) 12:03:
> 
> 
> 
>  I think we have two options:
>  1. Build the ports with a C version of at least C99.
> 
>  - Adding USE_CSTD=c99
>  - Removing -ansi:
>  --- configure.orig 2023-12-29 11:54:11 UTC
>  +++ configure
>  -CFLAGS="$CFLAGS $(DSO_CFLAGS) -ansi -Wall"
>  +CFLAGS="$CFLAGS $(DSO_CFLAGS) -Wall"
> 
>  Fix build.
> 
>  Notes:
> 
>  Adding USE_CSTD=c99 doesn't fix build by itself like we seen on some
> ports that were fixed by it.
> 
>  Something have changed from current 157 to 158.
> 
>  2. Remove the inline from tcp_[gs]et_flags().
> 
>  Best regards
>  Michael
> > --
> > Nuno Teixeira
> > FreeBSD Committer (ports)
> 
> 
> 
>  --
>  Nuno Teixeira
>  FreeBSD Committer (ports)
> 
> 
>  --
>  Nuno Teixeira
>  FreeBSD Committer (ports)
> >>>
> >>>
> >
> >
>
>
>

Re: kernel: psm: keyboard controller failed at git revision 3334a537ed38

[Warner Losh]

On Wed, Dec 27, 2023, 2:24 PM Juraj Lutter  wrote:

>
>
> On 27 Dec 2023, at 21:44, Ruslan Makhmatkhanov  wrote:
>
> Hello,
>
> I updated my tree to revision 3334a537ed38, made buildworld and kernel as
> usual.
> Booting with new kernel leads to keyboard not working at system login
> prompt and the message "kernel: psm: keyboard controller failed" in
> /var/log/messages.
>
> Reverting to boot the old kernel main-n266238-03e2fc4c4446 makes keyboard
> and system working again.
>
>
>
> Did you try to git bisect between the working and non-working commits?
>

Also a dmesg from before and after. And a quick description of your system
hardware.

Warner

> —
> Juraj Lutter
> o...@freebsd.org
>
>

Re: symlink to /boot/loader.efi

[Warner Losh]

On Fri, Dec 22, 2023 at 8:00 AM Tomoaki AOKI 
wrote:

> On Fri, 22 Dec 2023 12:02:54 +0200
> Toomas Soome  wrote:
>
> > > On 22. Dec 2023, at 11:54, Mark Millard  wrote:
> > >
> > > On Dec 22, 2023, at 01:36, Toomas Soome  wrote:
> > >>
> > >>
> > >>
> > >>> On 22. Dec 2023, at 11:09, Mark Millard  wrote:
> > >>>
> > >>> Tomoaki AOKI  wrote on
> > >>> Date: Thu, 21 Dec 2023 23:21:00 UTC :
> > >>>
> >  On Thu, 21 Dec 2023 14:22:14 +0100
> >  Dimitry Andric  wrote:
> > 
> > > Yeah, my procedure is the same as yours: I first copy
> /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, then
> copy the freshly built and installed /boot/loader.efi to
> /boot/efi/efi/freebsd/loader.efi. I don't see a technical reason why this
> could not be just another step in the installworld procedure.
> > >
> > > That said, I am unsure if the pathname /boot/efi/efi is always the
> same, at least for all UEFI systems. It is the default layout when you do a
> regular install with recent installer onto a UEFI system, but some users
> may use completely different mount points. So you should still have some
> way of configuring the default location for loader installation.
> > >
> > > Also, on default installations a fallback entry named
> /boot/efi/efi/boot/bootx64.efi is made, essentially another copy of
> loader.efi but with a different name. Namely, the default name that UEFI
> (on x86_64 at least) searches for, if it doesn't know anything else. I.e.
> if it isn't configured via efibootmgr(8), or the EFI variables have been
> junked for some reason. It might make sense to also update that file.
> > >
> > > -Dimitry
> > 
> >  Just an idea.
> > 
> >  It would be nice if loader.efi (hopefully, boot1.efi,too) could pass
> >  "where am I placed?" info, maybe via kenv.
> > 
> >  Would need boot1.efi to pass something (ideally, "where am I booted
> >  from?", but "boot1_used=1" is sufficient).
> > 
> >  To do so, loader.efi can confirm whether it was loaded via
> boot1.efi or
> >  directly from UEFI firmware. If nothing is passed to it, it can
> probe
> >  "where it is?" using UEFI call and set it, otherwise, it should
> >  be /boot/loader.efi, so nothing is needed to do.
> > >>>
> > >>> To my knowledge aarch64 and armv7 never use the copy in
> > >>> /boot/loader.efi during a boot. It has to have been copied
> > >>> into the appropriate msdosfs such that it has an
> > >>> appropriate path and name there. That is what is found
> > >>> and used during the boot.
> > >>
> > >>
> > >> All UEFI systems start from ESP (EFI System Partition). The only good
> reason to install boot1.efi there is when you have very small ESP and need
> to save that space - and in that case the boot1.esp will search and execute
> /boot/loader.efi.
>
> Or if you need the functionality the patch at Bug 207940 [1] provides,
> which is not yet implemented on loader.efi. ;-)
>
> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207940
>
>
> > > Yep. May be I misinterpreted what the text strongly tied to
> > > "it should be /boot/loader.efi" and so ended up not pointing
> > > out an actual distinction.
>
> Ah, sorry for mis-leading words.
>
>
> > >> The problem about boot1.efi (or any other UEFI chainload) is that
> loading file and executing it will not replace current program in memory,
> but will add new one, this may be problem with systems with minimal memory
> configurations. And yes, boot1.efi is not really platform specific - it is
> just another EFI application - one can build and use it on arm (or any
> other) systems
> > >
> > > Not powerpc (32-bit), powerpc64, or powerpc64le: these are
> > > not UEFI systems at all, if I understand right.
> >
> >
> > Yes, building EFI application implies platform with UEFI support.
> >
> > rgds,
> > toomas
> >
> > >
> > > Of course, if only tier 1 is documented, such would not be
> > > covered. But documentation that is limited to tier 1 should
> > > say so explicitly --but various examples have historically
> > > not done so.
> > >
> > >> and then it will load and start /boot/loader.efi.
> > >>
> > >> starting loader directly from ESP has few advantages — you wont waste
> memory for boot1.efi, you save a bit of boot time, you can use auxiliary
> files from ESP to pass some information to loader.efi (for example to tell
> where your rootfs is in case of multiboot setups).
> > >>
> > >> the boot1.efi could be a bit more appealing if it would be able to
> load and start kernel directly, allowing to build very memory limited
> setups, but then again, it does sound like very specific corner case.
> > >
> > > Thanks for the UEFi-context notes that go well beyond anything
> > > I referenced. Good stuff.
> > >
> > >> rgds,
> > >> toomas
> > >>
> > >>
> > >>>
> >  If no related kenv is set and freebsd-boot partition exists, it
> should
> >  be booted with legacy (BIOS) boot.
> > >>>
> > >>> If there even is a "l

Re: symlink to /boot/loader.efi

[Warner Losh]

On Fri, Dec 22, 2023 at 2:36 AM Toomas Soome  wrote:

>
>
> > On 22. Dec 2023, at 11:09, Mark Millard  wrote:
> >
> > Tomoaki AOKI  wrote on
> > Date: Thu, 21 Dec 2023 23:21:00 UTC :
> >
> >> On Thu, 21 Dec 2023 14:22:14 +0100
> >> Dimitry Andric  wrote:
> >>
> >>> Yeah, my procedure is the same as yours: I first copy
> /boot/efi/efi/freebsd/loader.efi to /boot/efi/efi/freebsd/loader.old, then
> copy the freshly built and installed /boot/loader.efi to
> /boot/efi/efi/freebsd/loader.efi. I don't see a technical reason why this
> could not be just another step in the installworld procedure.
> >>>
> >>> That said, I am unsure if the pathname /boot/efi/efi is always the
> same, at least for all UEFI systems. It is the default layout when you do a
> regular install with recent installer onto a UEFI system, but some users
> may use completely different mount points. So you should still have some
> way of configuring the default location for loader installation.
> >>>
> >>> Also, on default installations a fallback entry named
> /boot/efi/efi/boot/bootx64.efi is made, essentially another copy of
> loader.efi but with a different name. Namely, the default name that UEFI
> (on x86_64 at least) searches for, if it doesn't know anything else. I.e.
> if it isn't configured via efibootmgr(8), or the EFI variables have been
> junked for some reason. It might make sense to also update that file.
> >>>
> >>> -Dimitry
> >>
> >> Just an idea.
> >>
> >> It would be nice if loader.efi (hopefully, boot1.efi,too) could pass
> >> "where am I placed?" info, maybe via kenv.
> >>
> >> Would need boot1.efi to pass something (ideally, "where am I booted
> >> from?", but "boot1_used=1" is sufficient).
> >>
> >> To do so, loader.efi can confirm whether it was loaded via boot1.efi or
> >> directly from UEFI firmware. If nothing is passed to it, it can probe
> >> "where it is?" using UEFI call and set it, otherwise, it should
> >> be /boot/loader.efi, so nothing is needed to do.
> >
> > To my knowledge aarch64 and armv7 never use the copy in
> > /boot/loader.efi during a boot. It has to have been copied
> > into the appropriate msdosfs such that it has an
> > appropriate path and name there. That is what is found
> > and used during the boot.
>
>
> All UEFI systems start from ESP (EFI System Partition). The only good
> reason to install boot1.efi there is when you have very small ESP and need
> to save that space - and in that case the boot1.esp will search and execute
> /boot/loader.efi.
>

Yes. I consider this a legacy need only. Part of the problem with 'fixing'
boot1.efi to include all the newest filesystems, crypto, etc means that it
grows too large for this use case.


> The problem about boot1.efi (or any other UEFI chainload) is that loading
> file and executing it will not replace current program in memory, but will
> add new one, this may be problem with systems with minimal memory
> configurations. And yes, boot1.efi is not really platform specific - it is
> just another EFI application - one can build and use it on arm (or any
> other) systems and then it will load and start /boot/loader.efi.
>
> starting loader directly from ESP has few advantages — you wont waste
> memory for boot1.efi, you save a bit of boot time, you can use auxiliary
> files from ESP to pass some information to loader.efi (for example to tell
> where your rootfs is in case of multiboot setups).
>
> the boot1.efi could be a bit more appealing if it would be able to load
> and start kernel directly, allowing to build very memory limited setups,
> but then again, it does sound like very specific corner case.
>

Yes. boot1.efi is a bit of a special case. It originally was done as a
quick port of boot1 from powerpc and was quite small. However, as we
expanded the supported boot paths, it grew.

And growth isn't the only problem. boot1.efi uses its own drivers and
filesystems that do leverage the base libsa stuff, but do it in slightly
different ways that loader.efi does. It also largely duplicates loader.efi
functionality, just to read loader.efi. And with all the ZFS, crypto,
compression, it's too much.

I get the appeal for having a boot1.efi that's super simple, but our system
is a poor fit to that, especially with ZFS's high velocity. It's a big
reason I've not merged things in.

Warner


> rgds,
> toomas
>
>
> >
> >> If no related kenv is set and freebsd-boot partition exists, it should
> >> be booted with legacy (BIOS) boot.
> >
> > If there even is a "legacy (BIOS) boot" is a platform
> > specific issue as far as I know.
> >
> >> The easiest to be set by loader.efi and/or boot1.efi would be raw UEFI
> >> device path. So would need analyzing where actually is on booted
> >> FreeBBSD environment.
> >
> > See the earlier point about aarch64 and armv7 not using
> > /boot/* files while loading the FreeBSD loader: the
> > FreeBSD loader variant used is the first stage able to
> > look inside UFS or ZFS file systems. Loading and
> > starting the FreeBSD loade

Re: symlink to /boot/loader.efi

[Warner Losh]

On Thu, Dec 21, 2023, 8:18 AM Jeffrey Bouquet 
wrote:

> I am wondering if all the information in this thread present and future
> should be included in
> the scenarios at the bottom of /usr/ports/UPDATING with technical
> explanations about
> how and why? AFAIK the file was created before UEFI and thus in that
> regard obsolete.


There is more info on updating noe on the man pages, but we likely aren't
there yet. A note in UPDATING sounds like a great idea.

Warner

On Thu, 21 Dec 2023 12:59:54 +, Nuno Teixeira 
> wrote:
>
> > Hello Dimitry,
> >
> > For a moment I forgot that efiboot is a fat system...
> > I am inspired on what installworld does to kernel and kernel.old.
> > I was thinking in something like it but with efi boot, something
> automatic.
> >
> > Thanks!
> >
> > Dimitry Andric  escreveu no dia quinta, 21/12/2023 à(s)
> > 12:48:
> >
> > > On 21 Dec 2023, at 13:22, Nuno Teixeira  wrote:
> > > >
> > > > On every current upgrade I update efi/freebsd/loader.efi (amd64) and
> > > efi/boot/boota64 (aarch64) with new copies on /boot/loader.efi.
> > > > For safety reasons I always have a copy of last running loader by
> > > appending "-old.efi" to loader or boota64 and use beinstall to get BEs
> if
> > > needed.
> > > >
> > > > Is that possible to link, e.g., /boot/efi/efi/freebsd/loader.efi ->
> > > /boot/loader.efi ?
> > >
> > > Symlinks do not work on FAT file systems, so I assume you mean a
> symlink
> > > placed in /boot (assuming that is UFS or ZFS), which points to
> > > /boot/efi/efi/freebsd?
> > >
> > > At the moment I think installworld would not write 'through' such a
> > > symlink. In fact, it makes a hard link from /boot/loader_lua.efi to
> > > /boot/loader.efi, unlinking any previous /boot/loader.efi.
> > >
> > > That said, it would be nice to have some sort of semi-official way of
> > > upgrading the real EFI loader through installworld. It would probably
> > > require some top-level Makefile magic.
> > >
> > > -Dimitry
> > >
> > >
> >
> > --
> > Nuno Teixeira
> > FreeBSD Committer (ports)
>
>
>
>

Re: upgrade failure

[Warner Losh]

I think this is the make delete-old issue You usually can get away w/o
running that step, but not this time, alas.

Warner

On Mon, Dec 11, 2023 at 8:24 PM Pete Wright  wrote:

>
>
> On 12/11/23 18:19, AN wrote:
> > I just had this failure trying to upgrade from 14 to 15.  Any help
> > fixing this would be appreciated.
> >
> >
> > --- _SERINS ---
> > install  -C -o root -g wheel -m 444
> > /usr/src/contrib/llvm-project/libcxx/include/__system_error/errc.h
> >
> /usr/src/contrib/llvm-project/libcxx/include/__system_error/error_category.h
>
> > /usr/src/contrib/llvm-project/libcxx/include/__system_error/error_code.h
> >
> /usr/src/contrib/llvm-project/libcxx/include/__system_error/error_condition.h
>
> >
> /usr/src/contrib/llvm-project/libcxx/include/__system_error/system_error.h
> > /usr/include/c++/v1/__system_error/
> > --- _THRINS ---
> > install  -C -o root -g wheel -m 444
> > /usr/src/contrib/llvm-project/libcxx/include/__thread/formatter.h
> > /usr/src/contrib/llvm-project/libcxx/include/__thread/id.h
> >
> /usr/src/contrib/llvm-project/libcxx/include/__thread/poll_with_backoff.h
> > /usr/src/contrib/llvm-project/libcxx/include/__thread/this_thread.h
> > /usr/src/contrib/llvm-project/libcxx/include/__thread/thread.h
> >
> /usr/src/contrib/llvm-project/libcxx/include/__thread/timed_backoff_policy.h
>
> > /usr/include/c++/v1/__thread/
> > --- _TUPINS ---
> > install  -C -o root -g wheel -m 444
> > /usr/src/contrib/llvm-project/libcxx/include/__tuple/make_tuple_types.h
> > /usr/src/contrib/llvm-project/libcxx/include/__tuple/pair_like.h
> > /usr/src/contrib/llvm-project/libcxx/include/__tuple/sfinae_helpers.h
> > /usr/src/contrib/llvm-project/libcxx/include/__tuple/tuple_element.h
> > /usr/src/contrib/llvm-project/libcxx/include/__tuple/tuple_indices.h
> > /usr/src/contrib/llvm-project/libcxx/include/__tuple/tuple_like.h
> > /usr/src/contrib/llvm-project/libcxx/include/__tuple/tuple_like_ext.h
> > /usr/src/contrib/llvm-project/libcxx/include/__tuple/tuple_size.h
> > /usr/src/contrib/llvm-project/libcxx/include/__tuple/tuple_types.h
> > /usr/include/c++/v1/__tuple/
> > install: target directory `/usr/include/c++/v1/__tuple/' does not exist
>
> did you run "make clean" before doing make buildworld/buildkernel?
>
> -pete
>
> --
> Pete Wright
> p...@nomadlogic.org
> @nomadlogicLA
>
>
>

Re: nvme timeout issues with hardware and bhyve vm's

[Warner Losh]

On Thu, Dec 7, 2023 at 4:09 PM Tomoaki AOKI 
wrote:

> On Thu, 7 Dec 2023 14:38:37 -0800
> Pete Wright  wrote:
>
> >
> >
> > On 10/13/23 7:34 PM, Warner Losh wrote:
> > >
> >
> > >
> > > the messages i posted in the start of the thread are from the VM
> itself
> > > (13.2-RELEASE).  The zpool on the hypervisor (13.2-RELEASE) showed
> no
> > > such issues.
> > >
> > > Based on your comment about the improvements in 14 I'll focus my
> > > efforts
> > > on my workstation, it seemed to happen regularly so hopefully i can
> > > find
> > > a repo case.
> > >
> > >
> > > Let me now if you see similar messages in stable/14. I think I've
> fixed
> > > all the
> > > issues with timeouts, though you shouldn't ever seem them in a vm setup
> > > unless something else weird is going on.
> > >
> >
> >
> > Hi Warner, just resurfacing this thread because I've had a few lockups
> > on my workstation running 14.0-STABLE.  I was able to capture a photo of
> > the hang and this seems to be the most important line:
> >
> > nvme0: Resetting controller due to a timeout and possible hot unplug.
> >
> > When I scan the device after reboot I don't see any errors, but if there
> > is a particular thing I should check via nvmecontrol please let me know.
> >   Also, since it mentions possible hot unplug I wonder if this is
> > hardware/firmware related to my system?
> >
> > Anyway, haven't found a repro case yet but it has locked up a few times
> > the past two weeks.
> >
> > -pete
> >
> >
> > --
> > Pete Wright
> > p...@nomadlogic.org
>
> If I myself encounter this kind of problem ON BARE METAL HARDWARE,
> I would usually suspect
>
>  *Overheating caused hang of NVMe controller or PCI bridge on SSD, or
>

Yes. Most drive's firmware when it overheats resets. There might be
something
that the pci code can do when this happens to retrain the link, reprogram
the
config registers, etc.


>  *Unstable physical connection (bad contact)
>

Yea, hot plug controller is required for this, but this will be bouncing.

Warner

Re: nvme timeout issues with hardware and bhyve vm's

[Warner Losh]

On Thu, Dec 7, 2023 at 3:38 PM Pete Wright  wrote:

>
>
> On 10/13/23 7:34 PM, Warner Losh wrote:
> >
>
> >
> > the messages i posted in the start of the thread are from the VM
> itself
> > (13.2-RELEASE).  The zpool on the hypervisor (13.2-RELEASE) showed no
> > such issues.
> >
> > Based on your comment about the improvements in 14 I'll focus my
> > efforts
> > on my workstation, it seemed to happen regularly so hopefully i can
> > find
> > a repo case.
> >
> >
> > Let me now if you see similar messages in stable/14. I think I've fixed
> > all the
> > issues with timeouts, though you shouldn't ever seem them in a vm setup
> > unless something else weird is going on.
> >
>
>
> Hi Warner, just resurfacing this thread because I've had a few lockups
> on my workstation running 14.0-STABLE.  I was able to capture a photo of
> the hang and this seems to be the most important line:
>
> nvme0: Resetting controller due to a timeout and possible hot unplug.
>
> When I scan the device after reboot I don't see any errors, but if there
> is a particular thing I should check via nvmecontrol please let me know.
>   Also, since it mentions possible hot unplug I wonder if this is
> hardware/firmware related to my system?
>
> Anyway, haven't found a repro case yet but it has locked up a few times
> the past two weeks.
>

What the message means is that (a) we stopped getting interrupts from the
device and (b) when we went to check on the status of the device it read
back like missing hardware.

So is this from inside the VM running under bhyve, or in the host that's
hosting the VM? We have different next steps depending on where it is.

Warner

Re: aarch64 and armv6 vs. armv7 support: armv6 is not supported, despite what "man arch" reports

[Warner Losh]

On Thu, Dec 7, 2023, 2:19 AM Dimitry Andric  wrote:

> On 7 Dec 2023, at 05:31, Mark Millard  wrote:
> >
> > man arch reports:
> >
> > QUOTE
> > Some machines support more than one FreeBSD ABI.  Typically these are
> > 64-bit machines, where the “native” LP64 execution environment is
> > accompanied by the “legacy” ILP32 environment, which was the
> historical
> > 32-bit predecessor for 64-bit evolution.  Examples are:
> >
> >   LP64 ILP32 counterpart
> >   amd64i386
> >   powerpc64powerpc
> >   aarch64  armv6/armv7
>
> So, this might be replaced with "armv6^armv7" or "armv6 xor armv7", then?
>

The binaries are basically the same. But you need one set of libraries or
the other since the calling conversations differ. I think you'll need to
enhance the current sysctl to be per jail.

Or you could migrate away from armv6. It's days are numbered in main.

Warner


> -Dimitry
>
>

Heads up: lots of churn, nothing interesting will come of it (I hope)

[Warner Losh]

OK. I have pushed 4 series of commits. (1) remove sccs IDs by and large (a
couple of exceptions where @(#) didn't mark an SCCS id). (2) remove if 0'd
copyright strings. (3) Mechanical changes to most of the tree to cleanup
style divots after these changes (and the $FreeBSD$ removal) (4) cdefs.h
cleanups. I also bumped FreeBSD_version. I chunked these a bit differently
than for $FreeBSD$ so any given file will only have 2 or 3 commits rather
than half a dozen. I've done a test MFC and this chunking shouldn't cause
problems, but I've not pushed that since a couple of last second snags
changed most of the hashes, so I have to redo it.

I did all of these all at once so that there'd be only one rebuild for most
people. I plan on doing a MFC to stable/14 (it doesn't look too horrible),
but not to stable/13 unless there's demand. It's too churny, IMHO, for a
branch at that point of maturity.

I tried to triple check everything, and to not delete too much. I did an
exp run on the cdefs changes. All most people will notice is really long
incremental rebuilds  I hope...

This should be the last wide-scale cleanup like this. There may be some
minor mop of that follows this commit, but there's no more tree-wide
changes on the horizon. I do plan on plowing forward, though, with my
cdefs.h cleanup, though not until after the first of the year.

If my expectations are in error, or you've noticed a mistake in all this,
please let me know.

Warner

Re: Should we boot the FreeBSD kernel in ELF format or in zImage format ? How?

[Warner Losh]

On Sat, Nov 25, 2023 at 4:41 AM Mario Marietto 
wrote:

> Hello to everyone.
>
> we have just virtualized Debian 12 on our arm (32 bit) Chromebook. As host
> / dom0 we have chosen Devuan 5,and for guest / domU,Debian 12. It works
> great. But our goal is different. We want to virtualize FreeBSD as domU.
> Can we have a working Xen PV network driver for a FreeBSD arm guest ?. I
> found that Julien Grall has ported the Xen drivers to FreeBSD on arm. I
> would like to know if Julien's work was accepted upstream by FreeBSD, in
> which case FreeBSD as a Xen guest on arm should work if we enable the Xen
> PV drivers in the FreeBSD on arm kernel. If Julien's work was not accepted
> upstream by FreeBSD, we will have to find his patches and apply them
> ourselves to the FreeBSD on arm kernel.
>
> We found these slides :
>
>
> https://events.static.linuxfound.org/sites/events/files/slides/Porting%20FreeBSD%20on%20Xen%20on%20ARM%20.pdf
>
> Slide 13 refers to a XENHVM FreeBSD on arm kernel config - that is what we
> want to find.
>
> It looks like when that slide presentation was written, there were some
> limitations on FreeBSD Xen guests. For example, for our debian bookworm
> guest, I am using vcpus = '2' to match the number of real cpus on our
> Chromebook, but slide 13 mentions support for only 1 VCPU with a FreeBSD
> guest, so I will need to change that vcpus = '1' in the FreeBSD guest
> config unless support for 2 or more vcpus was added later, which is
> possible because that slide presentation is 9 years old.
>
> Here is where I would expect to find the XENHVM FreeBSD on arm kernel
> config file:
>
> https://cgit.freebsd.org/src/tree/sys/arm/conf
>
> But it is not there unless I am not understanding something correctly. For
> now, unfortunately conclude that the support for Xen on arm that Julien
> Grall mentioned in that slide presentation 9 years ago was never added to
> the official FreeBSD source code. I am searching the web now to see if the
> patches that Julien Grall wrote are still posted somewhere online. If we
> cannot find them, we can ask here and on the xen-users mailing list. Julien
> regularly reads that list and responds to question about Xen on arm, so I
> think he will tell us how to find the patches if we cannot find them online.
>
> According to this page from the FreeBSD wiki:
>
> https://wiki.freebsd.org/Xen
>
> I think FreeBSD only supports Xen on x86, not arm. So this is going to be
> a bit of a challenge to get a Xen FreeBSD guest on arm working. We know
> Julien Grall has some patches that made it work in the past !
>
> I found a slightly newer slide presentation by Julien here:
>
> https://www.slideshare.net/xen_com_mgr/bsdcan-2015-how-to-port-your-bsd
>
> It is about the same, but it mentions the GENERIC FreeBSD kernel supports
> Xen on arm64, but still says we need the XENHVM FreeBSD config for Xen on
> arm 32 bit, which I haven't found online yet.
>
> Please,take a look at this output of the linux kernel that can boot on
> Xen, and the FreeBSD kernel that cannot :
>
>
> % file zImage-6.1.59-stb-xen-cbe+
> zImage-6.1.59-stb-xen-cbe+: Linux kernel ARM boot executable zImage 
> (little-endian)
>
> % file FREEBSD-XENVIRT
> FREEBSD-XENVIRT: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), 
> dynamically linked, interpreter /red/herring, for FreeBSD 11.0 (1100048), not 
> stripped
>
>
> The FreeBSD kernel that won't boot is in ELF format but the Linux kernel
> that does boot is in zImage format.
>
> I spent time reading the docs on xenbits.xenproject.org, and according to
> those docs Xen on arm only knows how to boot a kernel in the zImage format,
> so the FreeBSD kernel is in a format that modern Xen incorrectly detects as
> an x86 kernel.
>
> I also watched Julien Grall's 30 minute video presentation of his work to
> boot FreeBSD/arm on Xen at FOSDEM 2014 here :
>
> https://archive.fosdem.org/2014/schedule/event/freebsd_xen_arm/
>
> In that video, and in other places, Julien mentions that the boot ABI for
> FreeBSD/arm on Xen was not yet developed and he was getting occasional
> crashes and needed to investigate the problem. He mentioned the zImage ABI
> that Linux uses, but pointed out FreeBSD does not use that format, and back
> then it was an open question which format to use to boot FreeBSD/arm on
> Xen. Unfortunately, nine years later, the only supported format is still
> the zImage format that Linux uses.
>
> It looks like Julien's work back then was using an ELF binary to boot
> FreeBSD/arm on Xen instead of the supported zImage format that Linux uses
> and the modern Xen toolstack exits with an error when trying to boot the
> FreeBSD ELF formatted binary that Julien's patch creates. So the best
> solution would be to try to port the rules to build a FreeBSD kernel in the
> zImage format instead of the ELF format. I have been studying the Makefiles
> in Linux to see how Linux builds the Linux arm kernel in the zImage format,
> but it is not trivial to understand
>

Loo

Re: RFC: #f FreeBSD_version of #ifdef for OpenZFS pull request

[Warner Losh]

On Wed, Nov 22, 2023, 1:24 PM Rick Macklem  wrote:

> Hi,
>
> I have a patch currently under review at D42672 that fixes visibility
> of snapshots under .zfs/snapshot for NFS clients.
> It adds a new function called vfs_exjail_clone(), which the ZFS
> code needs to use to fill in the mnt_exjail field.
>
> Since the OpenZFS code is supposed to build for 12.2 or later,
> I can see two ways of doing this:
> (A) #if on the FreeBSD_versions, which will look something like:
>
> #if (__FreeBSD_version >= 1300xxx && __FreeBSD_version < 140) ||
>  (__FreeBSD_version >= 1400yyy && __FreeBSD_version < 1400500) ||
>  (__FreeBSD_version >= 1400zzz && __FreeBSD_version < 150) ||
>  __FreeBSD_version >= 1500
>  vfs_exjail_clone();
> #endif
>
> The problem with this one is I do not know what www, xxx, yyy and zzz are
> until I have MFC'd the patch and bumped __FreeBSD_version.
> --> I cannot generate the OpenZFS pull request until after that and,
>  since I am headed to Florida for a few weeks, it would be late
> December
>  at the earliest.
> OR
> (B) add a line like
> #define VFS_SUPPORTS_EXJAIL_CLONE1
> to mount.h in the patch and then:
>
> #ifdef VFS_SUPPORTS_EXJAIL_CLONE
>  vfs_exjail_clone();
> #endif
>
> The adavntage of (B) is that I can do the pull request on OpenZFS
> right away and commit the patch to main, etc as soon as possible,
>
> So, which do you think is preferred? rick
> ps: Unless D42672 gets reviewed soon, it won't really matter w.r.t. timing.
>

I'd do B if I were doing this. With a comment for why I'm doing this
define. Then version numbers don't matter unless we botch something badly
and need them as a fallback.

Warner

Re: HEADSUP: panic: running without device atpic requires a local APIC on UEFI systems after 0b01d45783c3

[Warner Losh]

On Mon, Nov 20, 2023 at 8:48 PM Xin Li  wrote:

> On 2023-11-20 19:33, Warner Losh wrote:
> >
> >
> > On Mon, Nov 20, 2023 at 6:21 PM Xin Li  > <mailto:delp...@delphij.net>> wrote:
> >
> > Hi,
> >
> > It seems that the recent improvements of ACPI detection (e0f3dc82727f
> > and 0b01d45783c3) would leave the system in an unbootable state if
> the
> > UEFI files are not being updated at the same time of "make
> > installworld".  At early boot the kernel would panic with:
> >
> > panic: running without device atpic requires a local APIC on UEFI
> > systems
> >
> > To recover a system in this state, at loader prompt, use:
> >
> > unset hint.acpi.0.disabled
> > boot
> >
> > (I think core.lua should be modified to be compatible with an older
> > UEFI
> > payload, possibly issuing a warning that gets logged; and this
> > should be
> > mentioned in UPDATING)
> >
> >
> > I just pushed
> >
> https://cgit.freebsd.org/src/commit/?id=f213da893ca8c7c76e1656b36d3a10f93f9a1760
> <
> https://cgit.freebsd.org/src/commit/?id=f213da893ca8c7c76e1656b36d3a10f93f9a1760>
> which should fix the issue for x86, with an UPDATING entry for aarch64.
> >
> > This is at best a stop-gap kludge. The real solution would be for
> > loader.efi to publish a list of interfaces it implements and then the
> > lua code can cope with old/new better.
>
> Yeah I think it (I assume you mean
>
> https://cgit.freebsd.org/src/commit/?id=0abe05aeac29d99786401b9078e97dcead35f7f3
> ) should be sufficient for x86 systems to boot.  Thanks!
>

Yes. Clicked on the wrong commit.  Kyle and I will come up with something
to allow easier transitions in the future.

Warner


> Cheers,
>
>

Re: HEADSUP: panic: running without device atpic requires a local APIC on UEFI systems after 0b01d45783c3

[Warner Losh]

On Mon, Nov 20, 2023 at 6:21 PM Xin Li  wrote:

> Hi,
>
> It seems that the recent improvements of ACPI detection (e0f3dc82727f
> and 0b01d45783c3) would leave the system in an unbootable state if the
> UEFI files are not being updated at the same time of "make
> installworld".  At early boot the kernel would panic with:
>
> panic: running without device atpic requires a local APIC on UEFI systems
>
> To recover a system in this state, at loader prompt, use:
>
> unset hint.acpi.0.disabled
> boot
>
> (I think core.lua should be modified to be compatible with an older UEFI
> payload, possibly issuing a warning that gets logged; and this should be
> mentioned in UPDATING)
>

I just pushed
https://cgit.freebsd.org/src/commit/?id=f213da893ca8c7c76e1656b36d3a10f93f9a1760
which should fix the issue for x86, with an UPDATING entry for aarch64.

This is at best a stop-gap kludge. The real solution would be for
loader.efi to publish a list of interfaces it implements and then the lua
code can cope with old/new better.

Warner

Re: HEADSUP: panic: running without device atpic requires a local APIC on UEFI systems after 0b01d45783c3

[Warner Losh]

I have a patch cooking for this... I was almost done when I had to leave
for karate.

Warner

On Mon, Nov 20, 2023, 6:21 PM Xin Li  wrote:

> Hi,
>
> It seems that the recent improvements of ACPI detection (e0f3dc82727f
> and 0b01d45783c3) would leave the system in an unbootable state if the
> UEFI files are not being updated at the same time of "make
> installworld".  At early boot the kernel would panic with:
>
> panic: running without device atpic requires a local APIC on UEFI systems
>
> To recover a system in this state, at loader prompt, use:
>
> unset hint.acpi.0.disabled
> boot
>
> (I think core.lua should be modified to be compatible with an older UEFI
> payload, possibly issuing a warning that gets logged; and this should be
> mentioned in UPDATING)
>
> Cheers,
>

Re: How much survives an install/reboot cycle?

[Warner Losh]

On Sun, Nov 19, 2023 at 8:51 AM bob prohaska  wrote:

> How much of a running system's state survives a reboot? I used to think
> the answer was "nothing", but from time to time a second reboot behaves
> a  little differently from the previous one.
>
> The most recent example was an update to bpf.c: Prior to the update an
> armv7 system had been inclined to drop ssh connections left up for days.
> After updating and running a build/install cycle the behavior persisted,
> but since a second reboot with no intentional changes it has stopped.
>
> I've not tampered with nextboot, so I don't think that's it. Maybe I'm
> just imagining imagining things
>

Generally, nothing survives reboot. Nothing in RAM that is. Everything
on disk should survie. swap survives boot, but we ignore it unless
there's a core dump in there.  Dirty pages in the buffer cache will be
flushed to disk, unless the reboot is a crash.

And sometimes, RAM will survive a reboot. It all depends on what the BIOS
does. I've had dmesg survie several reboots because the kernel was the same
and the msgbuf wound up in the same place and we recovered (And appended to)
that (though saying that now, I'm not sure how FreeBSD does that). Some
machines
don't destructively memory test all RAM and/or clear RAM on a warm reboot.

ssh dropping connections, though, may be a feature of ssh. Check that the
following options haven't change and/or aren't causing you problems:
ServerAliveCountMax, ServerAliveInterval, or TCPKeepAlive (for the client)
and
ChanelTimeout, UnusedConnectionTimeout, ClientAliveCountMax,
ClientAliveInterval,
or TCPKeepAlive (for the server). I hit this with ForwardX11Timeout which
I had set to 9w but now have to set it to 999w since sshd rejected such
a long time. The default values of these change at random (at least
seemingly
so for people like me that can't be bothered to read the release notes).
I'm not
completely sure this is your problem, but if it is weird, it may be.

Warner

Re: kldunload kernel: How should the kernel behave when it is requested to unload itself

[Warner Losh]

Yea. Kexec is what you'd need to do to get a new kernel... and we don't
support kexec... so I agree this is good..

Warner

On Thu, Nov 9, 2023, 9:34 AM Doug Rabson  wrote:

> I think your intuition is correct - it never makes sense to unload the
> kernel (IMO). I approved the review.
>
> Doug.
>
>
> On Thu, 9 Nov 2023 at 16:10, Zhenlei Huang  wrote:
>
>> Hi,
>>
>> This is *NOT* joking.
>>
>> While working on https://reviews.freebsd.org/D42527 I realized the
>> module kernel also has userrefs, that is to say, userland can request
>> to unload kernel, aka `kldunload kernel`.
>>
>> This is interesting. Well no doubt that the loader can unload kernel.
>> Then after the kernel is loaded and has been initialized (SYSINIT), how
>> should it behave when it get an unload request?
>>
>> I'm proposing https://reviews.freebsd.org/D42530 to do not allow
>> unloading
>> the kernel. It is by intuition.
>>
>> What do you think ?
>>
>>
>> Best regards,
>> Zhenlei
>>
>>

Re: revision not displayed in a2440348eed7

[Warner Losh]

Do you have WITHOUT_REPRODUCEABLE_BUILDS=YES in your src.conf?

Warner

On Wed, Nov 8, 2023, 9:03 PM Cy Schubert  wrote:

> On Wed, 8 Nov 2023 15:14:34 +0100
> Marek Zarychta  wrote:
>
> > W dniu 8.11.2023 o 14:10, Marek Zarychta pisze:
> > >
> > > W dniu 27.09.2023 o 01:07, Tomoaki AOKI pisze:
> > >> On Tue, 26 Sep 2023 15:19:46 -0700
> > >> Cy Schubert  wrote:
> > >>
> > >>> In message <20230926231431.20f42fec1075c3980446c...@dec.sakura.ne.jp
> >,
> > >>> Tomoaki
> > >>> AOKI writes:
> >  On Tue, 26 Sep 2023 15:48:50 +0200
> >  Marek Zarychta  wrote:
> > 
> > > W dniu 26.09.2023 o 13:30, KIRIYAMA Kazuhiko pisze:
> > >> At least up to 15.0-CURRENT, nothing has happend by
> > >> WITHOUT_REPRODUCIBLE_BUILD=yes. Something has changed in
> > >> 15.0-CURRENT at some time. I've rebuilded with 3fb80f1476c7,
> > >> but revision not showed by `uname -a' ;-(
> > >>
> > >> What changed 
> > > Nothing changed. Perhaps your build system can't check git hash ?
> If
> > > your sources are from git repository, you need at least git-lite
> > > installed and full git repository available on build machine. If
> you
> > > checked out the repository with gitup and have gitup installed, it
> > > should also work. It won't work if your build machine has accessÂ
> to
> > > only a part of the repository like worktree.
> > >
> > > Cheers
> > >
> > > --
> > > Marek Zarychta
> >  Just a possibility, but copying src tree to directory other than the
> >  directory where checked out from git repo and building there could
> >  lose track with git hash.
> > 
> >  Another possibility is that if you build src with any user other
> than
> >  the one owning local (pulled) git repo could also lose track with
> git
> >  hash. For example, if I `git log HEAD` with regular user and the
> local
> >  repo is pulled by root, it fails. No special configuration is done.
> > 
> >  % git log HEAD
> >  fatal: detected dubious ownership in repository at '/usr/src'
> >  To add an exception for this directory, call:
> > 
> >   git config --global --add safe.directory /usr/src
> > 
> > 
> > >>> This could be due to e6dc6a27230, which was committed this morning.
> > >>> There
> > >>> is discussion on the src commits ML (dev-commits-src-all,
> > >>> dev-commits-src-main) about reverting the change.
> > >>>
> > >>>
> > >>> --
> > >>> Cheers,
> > >>> Cy Schubert 
> > >>> FreeBSD UNIX: Web: https://FreeBSD.org
> > >>> NTP:   Web: https://nwtime.org
> > >>>
> > >>> e^(i*pi)+1=0
> > >> Would be unrelated here, unfortunately.
> > >> As the subject says, the commit the original reporter is bitten at
> (not
> > >> bi-sected) is at a2440348eed7, which is before e6dc6a27230.
> > >
> > > Let's refresh this thread. It looks like (at least for stable/14)
> > > build system doesn't hardcode revision into the kernel anymore. Last
> > > time it worked to me was just after branching stable/14. Today I tried
> > > to build kernel from sources mounted over NFS and I ened with:
> > >
> > > # strings /usr/obj/usr/src/amd64.amd64/sys/BSDONDELL/kernel | grep
> > > 14.0-STABLE
> > > @(#)FreeBSD 14.0-STABLE #6 -dirty: Tue Nov  7 14:04:35 CET 2023
> > > FreeBSD 14.0-STABLE #6 -dirty: Tue Nov  7 14:04:35 CET 2023
> > > 14.0-STABLE
> > >
> > > the source repository is updated, consisted, but mounted read-only
> > > over NFS
> > >
> > > /usr/src# git status
> > > On branch stable/14
> > > Your branch is up to date with 'origin/stable/14'.
> > >
> > > Untracked files:
> > >   (use "git add ..." to include in what will be committed)
> > > sys/amd64/conf/BSDONDELL
> > >
> > > It took 2.53 seconds to enumerate untracked files.
> > > See 'git help status' for information on how to improve this.
> > >
> > > nothing added to commit but untracked files present (use "git add" to
> > > track)
> > >
> > >
> > > Any clues what could be wrong ? Does /usr/src/  require write
> > > permissions now ?
> >
> >
> > I am sorry for the false alarm. It looks like using META MODE prevented
> > updating this info. After cleaning obj dir and rebuilding revision is
> > visible:
> > # strings /usr/obj/usr/src/amd64.amd64/sys/BSDONDELL/kernel | grep
> > 14.0-STABLE
> > @(#)FreeBSD 14.0-STABLE #0 stable/14-n265707-d2c65a1c9486: Wed Nov  8
> > 14:16:31 CET 2023
> > FreeBSD 14.0-STABLE #0 stable/14-n265707-d2c65a1c9486: Wed Nov  8
> > 14:16:31 CET 2023
> >
>
> sys/conf/newvers.sh is responsible for getting the git hash into the
> kernel. If it finds a .git directory it will extract the hash to insert
> it into the kernel.
>
> I suspect there is something about your source tree that causes it to
> think there is no .git directory. In sys/conf/newvers.sh you will see
> where it sets $git_cmd when a .git directory exists. It subsequently
> tests for a non-zero $git_cmd string whereby it extracts the git hash.
>
> You might want

Re: atrtc0: non-PNP ISA device will be removed from GENERIC in FreeBSD 14

[Warner Losh]

On Sat, Oct 28, 2023, 11:04 AM Zhenlei Huang  wrote:

> Hi Warner,
>
> I see this from boot log of 14.0-RC3:
>
> > FreeBSD 14.0-RC3 #0 releng/14.0-n265368-c6cfdc130554: Fri Oct 27
> 05:57:28 UTC 2023
> > ...
> > atrtc0: non-PNP ISA device will be removed from GENERIC in FreeBSD 14.
>
> I guess atrtc(4) is still supported by FreeBSD 14.
> So this should be bumped to 15 at least. Am I right ?
>

Yes. Someone, maybe you, submitted a pr to do that.

Warner

Best regards,
> Zhenlei
>
>

Re: Ventoy support

[Warner Losh]

On Thu, Oct 26, 2023 at 11:22 AM Ed Maste  wrote:

> On Tue, 24 Oct 2023 at 21:24, Kyle Evans  wrote:
> >
> > On 10/24/23 20:03, Rodney W. Grimes wrote:
> > >
> > > What "modules" are being provied by Ventoy, I do not know
> > > of any FreeBSD modules being provided by Ventoy, it is an
> > > EFI shim that loads the FreeBSD loader, and the loader
> > > does all the work.
> > >
> > > Again, perhaps I do not see this as I am only using ventoy
> > > in EFI mode.
> >
> > There's an accompanying geom module as well, source available[0] for
> > every version they support (except 14.x, apparently, despite having a
> > built blob in the geom_ventoy_ko dir).  It's a little annoying to try
> > and understand the problems they're running into from version to
> > version, IMO, since they just publish the entire module again for each
> > version rather than maintaining some __FreeBSD_version shims or
> something.
>
> In particular, the kernel does not use EFI services for the root
> filesystem.
>

I've looked to pass the root filesystem into FreeBSD via a UEFI file path,
which FreeBSD has most, but not quite all, of the infrastructure to do.
I've been slowly adding pieces to round this out. For simple filesystems
on simple devices, it can be made to work. ZFS can be made to work too,
but requires fairly different code (also, for ZFS, we can cheat and pass
in a name that the boot loader and the OS share).

The Ventoy stuff is interesting as well...  Ed has some good ideas here
and we've also done some work to have a unified .mem and .iso image
as well... Though, honestly, the .iso format is getting rather long-of-tooth
and we might be better off leaving it behind like others have done.

Warner

Re: nvme timeout issues with hardware and bhyve vm's

[Warner Losh]

On Sun, Oct 15, 2023, 9:47 AM void  wrote:

> On Sun, 15 Oct 2023, at 15:35, Warner Losh wrote:
>
> > I've fixed all known nvme issues in current that aren't caused by other
> > parts of the system. If it isn't a very recent 15 or 14,  then there
> > are known issues and you'll need to try those first.
>
> The problem manifested with a source upgrade on the 30th September.
>
> > On arm it could be a lot of things. I keep seeing problems in other
> > area that are hard to track down without the systems in hand and
> > time to look at complex problems it can take a while to track down.
> >
> > I'll need a simple reproducer to look at things...
>
> If you can tell me what to do, i'm happy to test.
>
> Additionally, I can provide a connected instance to you for destructive
> testing on arm64. It would take me about 24hrs to set up as I'd
> need to backup the disk. Let me know if you need it.
>

The one with the uboot traceback? I can't help you there. The report is
confusing. I don't know the error / problem being reported to even know
what to look at.  Or is it a different thing? I'm so confused at this
point. I also think we need to recreate it on as a!clean system as
possible. Weird problems in the boot chain prior to loader.efi, I have
little interest in and no time to look at...

Warner

>

Re: nvme timeout issues with hardware and bhyve vm's

[Warner Losh]

On Sun, Oct 15, 2023, 9:28 AM void  wrote:

> Hi,
>
> On Fri, 13 Oct 2023, at 03:40, Pete Wright wrote:
> > I had similar issues on my workstation as well.  Scrubbing the NVMe
> > device on my real-hardware workstation hasn't turned up any issues, but
> > the system has locked up a handful of times.
> >
> > Just curious if others have seen the same, or if someone could point me
> > in the right direction...
>
> I've seen similar issues (zpool timeout) in a quite different context
> (arm64, usb3-connected disk, not-vm) which i posted about here:
>
> https://lists.freebsd.org/archives/freebsd-arm/2023-September/003122.html
>
> Unsure if these have been fixed yet?
>

I've fixed all known nvme issues in current that aren't caused by other
parts of the system. If it isn't a very recent 15 or 14,  then there are
known issues and you'll need to try those first.

On arm it could be a lot of things. I keep seeing problems in other area
that are hard to track down without the systems in hand and time to
look at complex problems it can take a while to track down.

I'll need a simple reproducer to look at things...

Warner

>

Re: nvme timeout issues with hardware and bhyve vm's

[Warner Losh]

On Fri, Oct 13, 2023 at 11:47 AM Pete Wright  wrote:

>
>
> On 10/13/23 6:24 AM, Warner Losh wrote:
> >
> >
> > On Thu, Oct 12, 2023, 10:53 PM Pete Wright  > <mailto:p...@nomadlogic.org>> wrote:
> >
> >
> >
> > On 10/12/23 8:45 PM, Warner Losh wrote:
> >  > What version is that kernel?
> >
> > oh dang i sent this to the wrong list, i'm not running current.  the
> > hypervisor and vm are both 13.2 and my workstation is a recent 14.0
> > pre-release build.  i'll do more homework tomorrow and post to
> > questions
> > or a more appropriate list.
> >
> >
> > Are the messages from the VM? Stable/14 should have the important nvme
> > changes I've made lately. The bhyve in 13.2 is lacking a number of nvme
> > fixes that have gone into current and stable/14. It's hard to say where
> > the fault is coming from.
> >
>
>
> the messages i posted in the start of the thread are from the VM itself
> (13.2-RELEASE).  The zpool on the hypervisor (13.2-RELEASE) showed no
> such issues.
>
> Based on your comment about the improvements in 14 I'll focus my efforts
> on my workstation, it seemed to happen regularly so hopefully i can find
> a repo case.
>

Let me now if you see similar messages in stable/14. I think I've fixed all
the
issues with timeouts, though you shouldn't ever seem them in a vm setup
unless something else weird is going on.

Warner

Re: nvme timeout issues with hardware and bhyve vm's

[Warner Losh]

On Thu, Oct 12, 2023, 10:53 PM Pete Wright  wrote:

>
>
> On 10/12/23 8:45 PM, Warner Losh wrote:
> > What version is that kernel?
>
> oh dang i sent this to the wrong list, i'm not running current.  the
> hypervisor and vm are both 13.2 and my workstation is a recent 14.0
> pre-release build.  i'll do more homework tomorrow and post to questions
> or a more appropriate list.
>

Are the messages from the VM? Stable/14 should have the important nvme
changes I've made lately. The bhyve in 13.2 is lacking a number of nvme
fixes that have gone into current and stable/14. It's hard to say where the
fault is coming from.

Warner

-pete
>
> --
> Pete Wright
> p...@nomadlogic.org
>

Re: nvme timeout issues with hardware and bhyve vm's

[Warner Losh]

What version is that kernel?

Warner

On Thu, Oct 12, 2023, 9:41 PM Pete Wright  wrote:

> hey there - i was curious if anyone has had issues with nvme devices
> recently.  i'm chasing down similar issues on my workstation which has a
> physical NVMe zroot, and on a bhyve VM which has a large pool exposed as
> a NVMe device (and is backed by a zvol).
>
> on the most recent bhyve issue the VM reported this:
>
> Oct 13 02:52:52 emby kernel: nvme1: RECOVERY_START 13737432416007567 vs
> 13737432371683671
> Oct 13 02:52:52 emby kernel: nvme1: RECOVERY_START 13737432718499597 vs
> 13737432371683671
> Oct 13 02:52:52 emby kernel: nvme1: timeout with nothing complete,
> resetting
> Oct 13 02:52:52 emby kernel: nvme1: Resetting controller due to a timeout.
> Oct 13 02:52:52 emby kernel: nvme1: RECOVERY_WAITING
> Oct 13 02:52:52 emby kernel: nvme1: resetting controller
> Oct 13 02:52:53 emby kernel: nvme1: waiting
> Oct 13 02:53:23 emby syslogd: last message repeated 114 times
> Oct 13 02:53:23 emby kernel: nvme1: controller ready did not become 1
> within 30500 ms
> Oct 13 02:53:23 emby kernel: nvme1: failing outstanding i/o
> Oct 13 02:53:23 emby kernel: nvme1: WRITE sqid:1 cid:119 nsid:1
> lba:4968850592 len:256
> Oct 13 02:53:23 emby kernel: nvme1: ABORTED - BY REQUEST (00/07) crd:0
> m:0 dnr:1 sqid:1 cid:119 cdw0:0
> Oct 13 02:53:23 emby kernel: nvme1: failing outstanding i/o
> Oct 13 02:53:23 emby kernel: nvme1: WRITE sqid:6 cid:0 nsid:1
> lba:5241952432 len:32
> Oct 13 02:53:23 emby kernel: nvme1: WRITE sqid:3 cid:123 nsid:1
> lba:4968850336 len:256
> Oct 13 02:53:23 emby kernel: nvme1: ABORTED - BY REQUEST (00/07) crd:0
> m:0 dnr:1 sqid:3 cid:123 cdw0:0
> Oct 13 02:53:23 emby kernel: nvme1: WRITE sqid:3 cid:0 nsid:1
> lba:5242495888 len:256
> Oct 13 02:53:23 emby kernel: nvme1: ABORTED - BY REQUEST (00/07) crd:0
> m:0 dnr:0 sqid:3 cid:0 cdw0:0
> Oct 13 02:53:23 emby kernel: nvme1: READ sqid:3 cid:0 nsid:1 lba:528 len:16
> Oct 13 02:53:23 emby kernel: nvme1: WRITE sqid:5 cid:0 nsid:1
> lba:4934226784 len:96
> Oct 13 02:53:23 emby kernel: nvme1: ABORTED - BY REQUEST (00/07) crd:0
> m:0 dnr:0 sqid:3 cid:0 cdw0:0
> Oct 13 02:53:23 emby kernel: nvme1: READ sqid:3 cid:0 nsid:1
> lba:6442449936 len:16
> Oct 13 02:53:25 emby kernel: nvme1: ABORTED - BY REQUEST (00/07) crd:0
> m:0 dnr:0 sqid:3 cid:0 cdw0:0
> Oct 13 02:53:25 emby kernel: nvme1: READ sqid:3 cid:0 nsid:1
> lba:6442450448 len:16
> Oct 13 02:53:25 emby kernel: nvme1: ABORTED - BY REQUEST (00/07) crd:0
> m:0 dnr:0 sqid:3 cid:0 cdw0:0
> Oct 13 02:53:25 emby kernel: nvme1: ABORTED - BY REQUEST (00/07) crd:0
> m:0 dnr:0 sqid:5 cid:0 cdw0:0
> Oct 13 02:53:25 emby kernel: nvme1: ABORTED - BY REQUEST (00/07) crd:0
> m:0 dnr:0 sqid:6 cid:0 cdw0:0
> Oct 13 02:53:25 emby kernel: nvd1: detached
>
>
>
> I had similar issues on my workstation as well.  Scrubbing the NVMe
> device on my real-hardware workstation hasn't turned up any issues, but
> the system has locked up a handful of times.
>
> Just curious if others have seen the same, or if someone could point me
> in the right direction...
>
> thanks!
> -pete
>
> --
> Pete Wright
> p...@nomadlogic.org
>
>

Re: something magic about the size of a ports tree

[Warner Losh]

On Tue, Oct 3, 2023, 10:24 AM Dag-Erling Smørgrav  wrote:

> Matthias Apitz  writes:
> > I have on my poudriere build host a ports tree and wanted to move it to
> > the host where the resulting packages are installed:
> >
> > root@jet:/usr/local/poudriere/ports # du -sh ports20230806
> > 397Mports20230806
> > root@jet:/usr/local/poudriere/ports # tar cf p.tar ports20230806
> > root@jet:/usr/local/poudriere/ports # ls -lh p.tar
> > -rw-r--r--  1 root wheel  672M Oct  3 18:00 p.tar
> >
> > already the size of the tar file is somewhat magic; but if you un-tar it
> > on the other host I will get:
> >
> > [guru@c720-1400094 ~]$ ls -lh p.tar
> > -rw-r--r--  1 guru wheel  672M  3 oct.  18:00 p.tar
> > [guru@c720-1400094 ~]$ tar xf p.tar
> > [guru@c720-1400094 ~]$ du -sh ports20230806
> > 1,2G  ports20230806
> >
> > How this is possible?
>
> Most files in the ports tree are very small.  On disk, each file gets
> rounded up to the nearest multiple of the filesystem block size, which
> could be as small as 512 bytes or as large as 8 kB (or even more in
> pathological cases).  In a tarball, they get rounded up to the nearest
> multiple of 512 bytes plus an additional 512 bytes per file for
> metadata.
>
> For instance, your average distinfo file (of which there are 30k in the
> ports tree) is only 200-250 bytes long, but it occupies 512 bytes on an
> FFS filesystem, 1 kB in a tarball, and 4 kB on a typical ZFS filesystem.
>
> Note that if the target system is FreeBSD 14 or newer, you can simply
> mount the tarball (`sudo mount -rt tarfs p.tar /usr/ports`).
>

Do we support any compression on top of that? Has support for poudriere
been added for it?

Aldo I want a pony I'm mostly curious... I have no immediate plans here
(though aligning with the boot loader and supporting this on a block device
to support rootfs would be cool). Maybe some or all of these wishes would
make good GSOC projects?

Warner

DES
> --
> Dag-Erling Smørgrav - d...@freebsd.org
>
>

Re: crashinfo fails on 'version'

[Warner Losh]

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.

Warner

-- 
> Bjoern A. Zeeb r15:7
>
>