subject:"new."


On 9/24/24 15:26, Warner Losh wrote:


Thinking about it, I found a hole. If gptzfsboot picked the wrong BE 
this could happen. And updating it might fix a bug that's causing it. 
Knowing when your system last updated the gptzfsboot would be useful...


The last time that my gptzfsboot was updated was 9/16/2024.  I copied it 
to the boot partition this morning before I sent this note to the group.


Tom

--
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF

Re: New console output at boot?

2024-09-24 Thread Warner Losh

On Tue, Sep 24, 2024, 11:55 AM Warner Losh  wrote:

>
>
> On Tue, Sep 24, 2024, 11:47 AM Thomas Laus  wrote:
>
>> On 9/24/24 11:04, Warner Losh wrote:
>> > On Sun, Sep 22, 2024 at 6:21 PM Kevin Oberman > > <mailto:rkober...@gmail.com>> wrote:
>> >
>> > Since an update to current a couple of weeks ago, I now see several
>> > lines (6 or 7) early in the boot. I'm not sure whether it is from
>> > one of the boots or the loader, but it comes out so quickly (and so
>> > briefly) but it vanishes on my display before I can read it. I'm
>> > guessing that some part of the boot. I'm guessing it is a warning to
>> > update one or more of the files.
>> >
>> > I'm running main-n272093-705583b76f3f on an amd64 system with UEFI
>> > boot of a UFS2 file system. So far, I've seen nothing in UPDATING
>> > that references it.
>> >
>> >
>> > I'll have to look at UPDATING.
>> >
>> > tl;dr: It's telling you your loader.efi is too old and needs to be
>> > updated. Too old here is somewhat too strict (since
>> > it requires a version bump recently, not the actual commits that
>> > introduced the compat code that I'd like to remove).
>> > It's harmless, at the moment, but is warning of potential problems in
>> > the future,
>> >
>> I see this same issue when 'gptzfsboot' on a non UEFI system is booted
>> and before the startup menu is displayed and have for over a month.
>> I've updated my boot partition to:
>>
>> FreeBSD 15.0-CURRENT #13 1c6bb4c57
>>
>
> Impossible. Gptzfsboot is an earlier phase than the new message. It can't
> produce a mismatch. Only loader/loader.efi vs /boot/lua/* can cause this.
> And usually in this setup both are updated as a pair.
>

Thinking about it, I found a hole. If gptzfsboot picked the wrong BE this
could happen. And updating it might fix a bug that's causing it. Knowing
when your system last updated the gptzfsboot would be useful...

Warner

Ps sorry for the strong absolute tone...

Warner
>
>
> Tom
>>
>>
>>
>> --
>> Public Keys:
>> PGP KeyID = 0x5F22FDC1
>> GnuPG KeyID = 0x620836CF
>>
>>

Re: New console output at boot?


On 9/24/24 14:42, Thomas Laus wrote:

On 9/24/24 13:55, Warner Losh wrote:

    FreeBSD 15.0-CURRENT #13 1c6bb4c57


Impossible. Gptzfsboot is an earlier phase than the new message. It 
can't produce a mismatch. Only loader/loader.efi vs /boot/lua/* can 
cause this. And usually in this setup both are updated as a pair.


It might not be the same problem but has similar symptoms.  I see a few 
dozen lines complaining about something missing and then the boot menu 
is displayed.  It scrolls to fast to read but everything is good after 
the boot menu gets shown.  I don't see this on my computers that have 
UEFI booting.


This happens immediately after GELI description keys are generated and 
before the boot menu gets displayed.


Tom


--
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF

Re: New console output at boot?


On 9/24/24 13:55, Warner Losh wrote:

FreeBSD 15.0-CURRENT #13 1c6bb4c57


Impossible. Gptzfsboot is an earlier phase than the new message. It 
can't produce a mismatch. Only loader/loader.efi vs /boot/lua/* can 
cause this. And usually in this setup both are updated as a pair.


It might not be the same problem but has similar symptoms.  I see a few 
dozen lines complaining about something missing and then the boot menu 
is displayed.  It scrolls to fast to read but everything is good after 
the boot menu gets shown.  I don't see this on my computers that have 
UEFI booting.


Tom

--
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF

Re: New console output at boot?

2024-09-24 Thread Warner Losh

On Tue, Sep 24, 2024, 11:47 AM Thomas Laus  wrote:

> On 9/24/24 11:04, Warner Losh wrote:
> > On Sun, Sep 22, 2024 at 6:21 PM Kevin Oberman  > <mailto:rkober...@gmail.com>> wrote:
> >
> > Since an update to current a couple of weeks ago, I now see several
> > lines (6 or 7) early in the boot. I'm not sure whether it is from
> > one of the boots or the loader, but it comes out so quickly (and so
> > briefly) but it vanishes on my display before I can read it. I'm
> > guessing that some part of the boot. I'm guessing it is a warning to
> > update one or more of the files.
> >
> > I'm running main-n272093-705583b76f3f on an amd64 system with UEFI
> > boot of a UFS2 file system. So far, I've seen nothing in UPDATING
> > that references it.
> >
> >
> > I'll have to look at UPDATING.
> >
> > tl;dr: It's telling you your loader.efi is too old and needs to be
> > updated. Too old here is somewhat too strict (since
> > it requires a version bump recently, not the actual commits that
> > introduced the compat code that I'd like to remove).
> > It's harmless, at the moment, but is warning of potential problems in
> > the future,
> >
> I see this same issue when 'gptzfsboot' on a non UEFI system is booted
> and before the startup menu is displayed and have for over a month.
> I've updated my boot partition to:
>
> FreeBSD 15.0-CURRENT #13 1c6bb4c57
>

Impossible. Gptzfsboot is an earlier phase than the new message. It can't
produce a mismatch. Only loader/loader.efi vs /boot/lua/* can cause this.
And usually in this setup both are updated as a pair.

Warner


Tom
>
>
>
> --
> Public Keys:
> PGP KeyID = 0x5F22FDC1
> GnuPG KeyID = 0x620836CF
>
>

Re: New console output at boot?


On 9/24/24 11:04, Warner Losh wrote:
On Sun, Sep 22, 2024 at 6:21 PM Kevin Oberman > wrote:


Since an update to current a couple of weeks ago, I now see several
lines (6 or 7) early in the boot. I'm not sure whether it is from
one of the boots or the loader, but it comes out so quickly (and so
briefly) but it vanishes on my display before I can read it. I'm
guessing that some part of the boot. I'm guessing it is a warning to
update one or more of the files.

I'm running main-n272093-705583b76f3f on an amd64 system with UEFI
boot of a UFS2 file system. So far, I've seen nothing in UPDATING
that references it.


I'll have to look at UPDATING.

tl;dr: It's telling you your loader.efi is too old and needs to be 
updated. Too old here is somewhat too strict (since
it requires a version bump recently, not the actual commits that 
introduced the compat code that I'd like to remove).
It's harmless, at the moment, but is warning of potential problems in 
the future,


I see this same issue when 'gptzfsboot' on a non UEFI system is booted 
and before the startup menu is displayed and have for over a month. 
I've updated my boot partition to:


FreeBSD 15.0-CURRENT #13 1c6bb4c57

Tom



--
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF

Re: New console output at boot?

2024-09-24 Thread Warner Losh

On Sun, Sep 22, 2024 at 6:21 PM Kevin Oberman  wrote:

> Since an update to current a couple of weeks ago, I now see several lines
> (6 or 7) early in the boot. I'm not sure whether it is from one of the
> boots or the loader, but it comes out so quickly (and so briefly) but it
> vanishes on my display before I can read it. I'm guessing that some part of
> the boot. I'm guessing it is a warning to update one or more of the files.
>
> I'm running main-n272093-705583b76f3f on an amd64 system with UEFI boot of
> a UFS2 file system. So far, I've seen nothing in UPDATING that references
> it.
>

I'll have to look at UPDATING.

tl;dr: It's telling you your loader.efi is too old and needs to be updated.
Too old here is somewhat too strict (since
it requires a version bump recently, not the actual commits that introduced
the compat code that I'd like to remove).
It's harmless, at the moment, but is warning of potential problems in the
future.

Warner

New console output at boot?

2024-09-22 Thread Kevin Oberman

Since an update to current a couple of weeks ago, I now see several lines
(6 or 7) early in the boot. I'm not sure whether it is from one of the
boots or the loader, but it comes out so quickly (and so briefly) but it
vanishes on my display before I can read it. I'm guessing that some part of
the boot. I'm guessing it is a warning to update one or more of the files.

I'm running main-n272093-705583b76f3f on an amd64 system with UEFI boot of
a UFS2 file system. So far, I've seen nothing in UPDATING that references
it.
-- 
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

new tls-cert-store and cert-bundle methods

2024-02-16 Thread void


Hello,

Now that we have system tls-cert-store, if one needs to reference
a tls-cert-bundle like provided by ca_root_nss, do we need
to concatenate all of the certs listed in /usr/share/certs/trusted
into, for example cert.pem then symlink /etc/ssl/cert.pem to
that concatenated file?

thanks in advance for any help/pointers/links
--

New FreeBSD snapshots available: stable/14 (ALPHA4) (20230901 4c3f144478d4)

2023-09-01 Thread Glen Barber

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

New FreeBSD development branch installation ISOs and virtual machine
disk images have been uploaded to the FreeBSD Project mirrors.

As with any development branch, the installation snapshots are not
intended for use on production systems.  We do, however, encourage
testing on non-production systems as much as possible.

Please also consider installing the sysutils/panicmail port, which can
help in providing FreeBSD developers the necessary information regarding
system crashes.

Checksums for the installation ISOs and the VM disk images follow at
the end of this email.

=== Installation ISOs ===

Installation images are available for:

o 14.0-ALPHA4 amd64 GENERIC
o 14.0-ALPHA4 i386 GENERIC
o 14.0-ALPHA4 powerpc GENERIC
o 14.0-ALPHA4 powerpc64 GENERIC64
o 14.0-ALPHA4 powerpc64le GENERIC64LE
o 14.0-ALPHA4 powerpcspe MPC85XXSPE
o 14.0-ALPHA4 armv7 GENERICSD
o 14.0-ALPHA4 aarch64 GENERIC
o 14.0-ALPHA4 aarch64 RPI
o 14.0-ALPHA4 aarch64 PINE64
o 14.0-ALPHA4 aarch64 PINE64-LTS
o 14.0-ALPHA4 aarch64 PINEBOOK
o 14.0-ALPHA4 aarch64 ROCK64
o 14.0-ALPHA4 aarch64 ROCKPRO64
o 14.0-ALPHA4 riscv64 GENERIC
o 14.0-ALPHA4 riscv64 GENERICSD

Note regarding arm/armv{6,7} images: For convenience for those without
console access to the system, a freebsd user with a password of
freebsd is available by default for ssh(1) access.  Additionally,
the root user password is set to root, which it is strongly
recommended to change the password for both users after gaining
access to the system.

Snapshots may be downloaded from the corresponding architecture
directory from:

https://download.freebsd.org/snapshots/ISO-IMAGES/

Please be patient if your local mirror has not yet caught up with the
changes.

Problems, bug reports, or regression reports should be reported through
the Bugzilla PR system or the appropriate mailing list such as -current@
or -stable@ .

=== Virtual Machine Disk Images ===

VM disk images are available for the following architectures:

o 14.0-ALPHA4 amd64
o 14.0-ALPHA4 i386
o 14.0-ALPHA4 aarch64
o 14.0-ALPHA4 riscv64
o 14.0-ALPHA4 amd64 BASIC-CI

Disk images may be downloaded from the following URL (or any of the
FreeBSD Project mirrors):

https://download.freebsd.org/snapshots/VM-IMAGES/

Images are available in the following disk image formats:

~ RAW
~ QCOW2 (qemu)
~ VMDK (qemu, VirtualBox, VMWare)
~ VHD (qemu, xen)

The partition layout for UFS images is:

~ 512k - freebsd-boot GPT partition type (bootfs GPT label)
~ 1GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 24GB - freebsd-ufs GPT partition type (rootfs GPT label)

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  This is provided by the emulators/qemu port.

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  
-bios /usr/local/share/qemu/edk2-aarch64-code.fd 
-serial telnet::,server -nographic 
-drive if=none,file=VMDISK,id=hd0 
-device virtio-blk-device,drive=hd0 
-device virtio-net-device,netdev=net0 
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

BASIC-CI images can be found at:

https://download.freebsd.org/snapshots/CI-IMAGES/

=== Amazon EC2 AMI Images ===

Amazon EC2 AMI images available for FreeBSD/amd64.

These AMI IDs can be retrieved from the Systems Manager Parameter Store
in each region using the keys:

/aws/service/freebsd/amd64/base/ufs/14.0/ALPHA4
/aws/service/freebsd/amd64/base/zfs/14.0/ALPHA4

Amazon EC2 aarch64 AMI images are not available for this snapshot.

=== Vagrant Images ===

FreeBSD/amd64 images are available on the Hashicorp Atlas site for the
VMWare Desktop and VirtualBox providers, and can be installed by
running:

% vagrant init freebsd/FreeBSD-14.0-ALPHA4
% vagrant up

== ISO CHECKSUMS ==

o 14.0-ALPHA4 amd64 GENERIC:
  SHA512 (FreeBSD-14.0-ALPHA4-amd64-20230901-4c3f144478d4-265026-bootonly.iso) 
= 
be2a357b798b3a455da597bde4f89592eb73248cae7c61d613b523856c5f21b4e8607e9bb7f79eea74abab47cc0bb6007d6e207ef7fed558ad267c8162b6c8fe
  SHA512 
(FreeBSD-14.0-ALPHA4-amd64-20230901-4c3f144478d4-265026-bootonly.iso.xz) = 
750595e6f51553b468eb47b2ab0003a326903edc80b793da84fef827ec67532a9abdecc406d117762fa638b0bc8f3d9105f8bbda566d9410444c474281414180
  SHA512 (FreeBSD-14.0-ALPHA4-amd64-20230901-4c3f144478d4-265026-disc1.iso) = 
5546879f2af755060905aa78e8f573e20ff3e318c42f56595a7db816f19a219f0cd1e8cbf72da2761757ae21278e507f8e17221a30c83b805e944d4ac5ee4aae
  SHA512 (FreeBSD-14.0-ALPHA4-amd64-20230901-4c3f144478d4-265026-disc1.iso.xz) 
= 
5168322946ed1a0a4ec69229eb51e798c037635aa849805d458a818d9930ece03a1d28b46c33987219074212c8ded60ba8ecbe3f5c06ed90718730b86351b7f1
  SHA512 (FreeBSD-14.0-ALPHA4-amd64-20230901-4c3f144478d4-265026-me

Re: Question about KBI change / new feature

2023-08-27 Thread Zhenlei Huang



> On Aug 23, 2023, at 1:06 AM, Warner Losh  wrote:
> 
> 
> 
> On Mon, Aug 21, 2023 at 9:42 AM Zhenlei Huang  <mailto:z...@freebsd.org>> wrote:
> Hi,
> 
> The https://www.freebsd.org/releases/14.0R/schedule/ 
> <https://www.freebsd.org/releases/14.0R/schedule/> says CURRENT/14 's KBI is 
> froze
> and new features should be avoided.
> 
> I'm working on https://reviews.freebsd.org/D39638 
> <https://reviews.freebsd.org/D39638> (sysctl(9): Enable vnet sysctl variables 
> be loader tunable)
> and I think it is new feature, but not quite sure whether the KBI changed.
> 
> So,
> 
> 1. Is it a KBI change ?
> 
> IMHO, It's a KPI change, not a KBI breakage. So from that perspective, it's 
> OK.

Thanks for the explanation !

>  
> 2. It is a simple change ( while so far as I know currently only tested by 
> myself on x86 and qemu riscv ), can
> it catch up with 14 ?
> 
> That I'm less sure of. I think it's good, but I'm gun shy about approving / 
> committing vnet things. The review suggests,
> though, there's at least some consensus for having this in the tree.

I always hesitate to PING someone to review ;)

Well I'm going to prepare to commit some of the stack, D41525, D39638, D39852, 
D39866, if no objections.

As for D40127, I have mixed filling about it. It might be too complex (for a 
simple function).
I wonder if we can have per-vnet `loader tunnable` to archive the same goal.

Best regards,
Zhenlei

New FreeBSD snapshots available: stable/14 (ALPHA3) (20230825 2af9390e54ed)

2023-08-25 Thread Glen Barber

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

New FreeBSD development branch installation ISOs and virtual machine
disk images have been uploaded to the FreeBSD Project mirrors.

As with any development branch, the installation snapshots are not
intended for use on production systems.  We do, however, encourage
testing on non-production systems as much as possible.

Please also consider installing the sysutils/panicmail port, which can
help in providing FreeBSD developers the necessary information regarding
system crashes.

Checksums for the installation ISOs and the VM disk images follow at
the end of this email.

=== Installation ISOs ===

Installation images are available for:

o 14.0-ALPHA3 amd64 GENERIC
o 14.0-ALPHA3 i386 GENERIC
o 14.0-ALPHA3 powerpc GENERIC
o 14.0-ALPHA3 powerpc64 GENERIC64
o 14.0-ALPHA3 powerpc64le GENERIC64LE
o 14.0-ALPHA3 powerpcspe MPC85XXSPE
o 14.0-ALPHA3 armv7 GENERICSD
o 14.0-ALPHA3 aarch64 GENERIC
o 14.0-ALPHA3 aarch64 RPI
o 14.0-ALPHA3 aarch64 PINE64
o 14.0-ALPHA3 aarch64 PINE64-LTS
o 14.0-ALPHA3 aarch64 PINEBOOK
o 14.0-ALPHA3 aarch64 ROCK64
o 14.0-ALPHA3 aarch64 ROCKPRO64
o 14.0-ALPHA3 riscv64 GENERIC
o 14.0-ALPHA3 riscv64 GENERICSD

Note, armv6 RPI-B images have been removed from the list of builds as
it is intended to be removed during the 14.0-RELEASE cycle.

Note regarding arm/armv{6,7} images: For convenience for those without
console access to the system, a freebsd user with a password of
freebsd is available by default for ssh(1) access.  Additionally,
the root user password is set to root, which it is strongly
recommended to change the password for both users after gaining
access to the system.

Snapshots may be downloaded from the corresponding architecture
directory from:

https://download.freebsd.org/snapshots/ISO-IMAGES/

Please be patient if your local mirror has not yet caught up with the
changes.

Problems, bug reports, or regression reports should be reported through
the Bugzilla PR system or the appropriate mailing list such as -current@
or -stable@ .

=== Virtual Machine Disk Images ===

VM disk images are available for the following architectures:

o 14.0-ALPHA3 amd64
o 14.0-ALPHA3 i386
o 14.0-ALPHA3 aarch64
o 14.0-ALPHA3 riscv64
o 14.0-ALPHA3 amd64 BASIC-CI

Disk images may be downloaded from the following URL (or any of the
FreeBSD Project mirrors):

https://download.freebsd.org/snapshots/VM-IMAGES/

Images are available in the following disk image formats:

~ RAW
~ QCOW2 (qemu)
~ VMDK (qemu, VirtualBox, VMWare)
~ VHD (qemu, xen)

The partition layout for UFS is:

~ 512k - freebsd-boot GPT partition type (bootfs GPT label)
~ 1GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 24GB - freebsd-ufs GPT partition type (rootfs GPT label)

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  This is provided by the emulators/qemu port.

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  
-bios /usr/local/share/qemu/edk2-aarch64-code.fd 
-serial telnet::,server -nographic 
-drive if=none,file=VMDISK,id=hd0 
-device virtio-blk-device,drive=hd0 
-device virtio-net-device,netdev=net0 
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

BASIC-CI images can be found at:

https://download.freebsd.org/snapshots/VM-IMAGES/

=== Amazon EC2 AMI Images ===

FreeBSD amd64 and aarch64 EC2 AMIs are available for both UFS and ZFS.

These AMI IDs can be retrieved from the Systems Manager Parameter Store
in each region using the keys:

/aws/service/freebsd/amd64/base/ufs/14.0/ALPHA3
/aws/service/freebsd/amd64/base/zfs/14.0/ALPHA3

/aws/service/freebsd/arm64/base/ufs/14.0/ALPHA3
/aws/service/freebsd/arm64/base/zfs/14.0/ALPHA3

=== Vagrant Images ===

FreeBSD/amd64 images are available on the Hashicorp Atlas site for the
VMWare Desktop and VirtualBox providers, and can be installed by
running:

% vagrant init freebsd/FreeBSD-14.0-ALPHA3
% vagrant up

== ISO CHECKSUMS ==

o 14.0-ALPHA3 amd64 GENERIC:
  SHA512 (FreeBSD-14.0-ALPHA3-amd64-20230825-2af9390e54ed-265022-bootonly.iso) 
= 
7c7dd389aba9de05bc5a44c3268541fc336aa2bd4ede294a98d913ff1a79776a1bf974a828c81fcc7e44351685b89c5d6154563baec6e8c11859e546b3ee8a79
  SHA512 
(FreeBSD-14.0-ALPHA3-amd64-20230825-2af9390e54ed-265022-bootonly.iso.xz) = 
6a48dbddd901da8312a891a9f26309a443f9100dcbb88d9c78c20305917ba5da750de2d381e53118a704f88e83a29aec3d5365a87a37696ef01b98c6c08ab79b
  SHA512 (FreeBSD-14.0-ALPHA3-amd64-20230825-2af9390e54ed-265022-disc1.iso) = 
f6903f80d8d6bf4498bc9df32d7d605e16061743fb7cd3935ed9aba337c18ac048c751443718bb395b8d20c178f31778f1057104ee225f0a4f7cbfa36563ddaa
  SHA512 (FreeBSD-14.0-ALPHA3-amd64-20230825-2af9390e54ed-265022-di

Re: poudriere bulk with ZFS and USE_TMPFS=no on main [14-ALPHA2 based]: extensive vlruwk for cpdup's on new builders after pkg builds in first builder

2023-08-24 Thread Mark Millard

On Aug 24, 2023, at 00:22, Mark Millard  wrote:

> On Aug 23, 2023, at 22:54, Mateusz Guzik  wrote:
> 
>> On 8/24/23, Mark Millard  wrote:
>>> On Aug 23, 2023, at 15:10, Mateusz Guzik  wrote:
>>> 
 On 8/23/23, Mark Millard  wrote:
> [Forked off the ZFS deadlock 14 discussion, per feedback.]
> . . .
 
 This is a known problem, but it is unclear if you should be running
 into it in this setup.
>>> 
>>> The changed fixed the issue: so I do run into the the issue
>>> for this setup. See below.
>>> 
 Can you try again but this time *revert*
 138a5dafba312ff39ce0eefdbe34de95519e600d, like so:
 git revert 138a5dafba312ff39ce0eefdbe34de95519e600d
 
 may want to switch to a different branch first, for example: git
 checkout -b vfstesting
>>> 
>>> # git -C /usr/main-src/ diff sys/kern/vfs_subr.c
>>> diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c
>>> index 0f3f00abfd4a..5dff556ac258 100644
>>> --- a/sys/kern/vfs_subr.c
>>> +++ b/sys/kern/vfs_subr.c
>>> @@ -3528,25 +3528,17 @@ vdbatch_process(struct vdbatch *vd)
>>>   MPASS(curthread->td_pinned > 0);
>>>   MPASS(vd->index == VDBATCH_SIZE);
>>> +   mtx_lock(&vnode_list_mtx);
>>>   critical_enter();
>>> -   if (mtx_trylock(&vnode_list_mtx)) {
>>> -   for (i = 0; i < VDBATCH_SIZE; i++) {
>>> -   vp = vd->tab[i];
>>> -   vd->tab[i] = NULL;
>>> -   TAILQ_REMOVE(&vnode_list, vp, v_vnodelist);
>>> -   TAILQ_INSERT_TAIL(&vnode_list, vp, v_vnodelist);
>>> -   MPASS(vp->v_dbatchcpu != NOCPU);
>>> -   vp->v_dbatchcpu = NOCPU;
>>> -   }
>>> -   mtx_unlock(&vnode_list_mtx);
>>> -   } else {
>>> -   for (i = 0; i < VDBATCH_SIZE; i++) {
>>> -   vp = vd->tab[i];
>>> -   vd->tab[i] = NULL;
>>> -   MPASS(vp->v_dbatchcpu != NOCPU);
>>> -   vp->v_dbatchcpu = NOCPU;
>>> -   }
>>> +   for (i = 0; i < VDBATCH_SIZE; i++) {
>>> +   vp = vd->tab[i];
>>> +   TAILQ_REMOVE(&vnode_list, vp, v_vnodelist);
>>> +   TAILQ_INSERT_TAIL(&vnode_list, vp, v_vnodelist);
>>> +   MPASS(vp->v_dbatchcpu != NOCPU);
>>> +   vp->v_dbatchcpu = NOCPU;
>>>   }
>>> +   mtx_unlock(&vnode_list_mtx);
>>> +   bzero(vd->tab, sizeof(vd->tab));
>>>   vd->index = 0;
>>>   critical_exit();
>>> }
>>> 
>>> Still with:
>>> 
>>> # grep USE_TMPFS= /usr/local/etc/poudriere.conf
>>> # EXAMPLE: USE_TMPFS="wrkdir data"
>>> #USE_TMPFS=all
>>> #USE_TMPFS="data"
>>> USE_TMPFS=no
>>> 
>>> 
>>> That allowed the other builders to eventually reach "Builder started"
>>> and later activity, [00:05:50] [27] [00:02:29] Builder started
>>> being the first non-[01] to do so, no vlruwk's observed in what
>>> I saw in top:
>>> 
>>> . . .
>>> 
>>> Now testing for the zfs deadlock issue should be possible for
>>> this setup.
>>> 
>> 
>> Thanks for testing, I wrote a fix:
>> 
>> https://people.freebsd.org/~mjg/vfs-recycle-fix.diff
>> 
>> Applies to *stock* kernel (as in without the revert).
> 
> I'm going to leave the deadlock test running for when
> I sleep tonight. So it is going to be a while before
> I get to testing this. $ work will likely happen first
> as well. (No deadlock observed yet, by the way. 6+ hrs
> and 3000+ ports built so far.)
> 
> I can easily restore the sys/kern/vfs_subr.c to then
> do normal 14.0-ALPHA2-ish based patching with: so not
> a problem. Thanks.
> 

I stopped the deadlock experiment, cleaned out the partial
bulk -a, put back the modern sys/kern/vfs_subr.c , applied
your patch, built, installed, rebooted, and started another
bulk -a run. It made progress on all the builders to and
past "Builder started":

. . .
[00:01:34] Building 34042 packages using up to 32 builders
[00:01:34] Hit CTRL+t at any time to see build progress and stats
[00:01:34] [01] [00:00:00] Builder starting
[00:01:57] [01] [00:00:23] Builder started
[00:01:57] [01] [00:00:00] Building ports-mgmt/pkg | pkg-1.20.4
[00:03:09] [01] [00:01:12] Finished ports-mgmt/pkg | pkg-1.20.4: Success
[00:03:22] [01] [00:00:00] Building print/indexinfo | indexinfo-0.3.1
[00:03:22] [02] [00:00:00] Builder starting
[00:03:22] [03] [00:00:00] Builder starting
[00:03:22] [04] [00:00:00] Builder starting
[00:03:22] [05] [00:00:00] Builder starting
[00:03:22] [06] [00:00:00] Builder starting
[00:03:22] [07] [00:00:00] Builder starting
[00:03:22] [08] [00:00:00] Builder starting
[00:03:22] [09] [00:00:00] Builder starting
[00:03:22] [10] [00:00:00] Builder starting
[00:03:22] [11] [00:00:00] Builder starting
[00:03:22] [12] [00:00:00] Builder starting
[00:03:22] [13] [00:00:00] Builder starting
[00:03:22] [14] [00:00:00] Builder starting
[00:03:22] [15] [00:00:00] Builder starting
[00:03:22] [16] [00:00:00] Builder starting
[00:03:22] [17] [00:00:00] Builder s

Re: poudriere bulk with ZFS and USE_TMPFS=no on main [14-ALPHA2 based]: extensive vlruwk for cpdup's on new builders after pkg builds in first builder

2023-08-24 Thread Mark Millard

On Aug 23, 2023, at 22:54, Mateusz Guzik  wrote:

> On 8/24/23, Mark Millard  wrote:
>> On Aug 23, 2023, at 15:10, Mateusz Guzik  wrote:
>> 
>>> On 8/23/23, Mark Millard  wrote:
 [Forked off the ZFS deadlock 14 discussion, per feedback.]
 . . .
>>> 
>>> This is a known problem, but it is unclear if you should be running
>>> into it in this setup.
>> 
>> The changed fixed the issue: so I do run into the the issue
>> for this setup. See below.
>> 
>>> Can you try again but this time *revert*
>>> 138a5dafba312ff39ce0eefdbe34de95519e600d, like so:
>>> git revert 138a5dafba312ff39ce0eefdbe34de95519e600d
>>> 
>>> may want to switch to a different branch first, for example: git
>>> checkout -b vfstesting
>> 
>> # git -C /usr/main-src/ diff sys/kern/vfs_subr.c
>> diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c
>> index 0f3f00abfd4a..5dff556ac258 100644
>> --- a/sys/kern/vfs_subr.c
>> +++ b/sys/kern/vfs_subr.c
>> @@ -3528,25 +3528,17 @@ vdbatch_process(struct vdbatch *vd)
>>MPASS(curthread->td_pinned > 0);
>>MPASS(vd->index == VDBATCH_SIZE);
>>  +   mtx_lock(&vnode_list_mtx);
>>critical_enter();
>> -   if (mtx_trylock(&vnode_list_mtx)) {
>> -   for (i = 0; i < VDBATCH_SIZE; i++) {
>> -   vp = vd->tab[i];
>> -   vd->tab[i] = NULL;
>> -   TAILQ_REMOVE(&vnode_list, vp, v_vnodelist);
>> -   TAILQ_INSERT_TAIL(&vnode_list, vp, v_vnodelist);
>> -   MPASS(vp->v_dbatchcpu != NOCPU);
>> -   vp->v_dbatchcpu = NOCPU;
>> -   }
>> -   mtx_unlock(&vnode_list_mtx);
>> -   } else {
>> -   for (i = 0; i < VDBATCH_SIZE; i++) {
>> -   vp = vd->tab[i];
>> -   vd->tab[i] = NULL;
>> -   MPASS(vp->v_dbatchcpu != NOCPU);
>> -   vp->v_dbatchcpu = NOCPU;
>> -   }
>> +   for (i = 0; i < VDBATCH_SIZE; i++) {
>> +   vp = vd->tab[i];
>> +   TAILQ_REMOVE(&vnode_list, vp, v_vnodelist);
>> +   TAILQ_INSERT_TAIL(&vnode_list, vp, v_vnodelist);
>> +   MPASS(vp->v_dbatchcpu != NOCPU);
>> +   vp->v_dbatchcpu = NOCPU;
>>}
>> +   mtx_unlock(&vnode_list_mtx);
>> +   bzero(vd->tab, sizeof(vd->tab));
>>vd->index = 0;
>>critical_exit();
>> }
>> 
>> Still with:
>> 
>> # grep USE_TMPFS= /usr/local/etc/poudriere.conf
>> # EXAMPLE: USE_TMPFS="wrkdir data"
>> #USE_TMPFS=all
>> #USE_TMPFS="data"
>> USE_TMPFS=no
>> 
>> 
>> That allowed the other builders to eventually reach "Builder started"
>> and later activity, [00:05:50] [27] [00:02:29] Builder started
>> being the first non-[01] to do so, no vlruwk's observed in what
>> I saw in top:
>> 
>> . . .
>> 
>> Now testing for the zfs deadlock issue should be possible for
>> this setup.
>> 
> 
> Thanks for testing, I wrote a fix:
> 
> https://people.freebsd.org/~mjg/vfs-recycle-fix.diff
> 
> Applies to *stock* kernel (as in without the revert).

I'm going to leave the deadlock test running for when
I sleep tonight. So it is going to be a while before
I get to testing this. $ work will likely happen first
as well. (No deadlock observed yet, by the way. 6+ hrs
and 3000+ ports built so far.)

I can easily restore the sys/kern/vfs_subr.c to then
do normal 14.0-ALPHA2-ish based patching with: so not
a problem. Thanks.


===
Mark Millard
marklmi at yahoo.com

Re: poudriere bulk with ZFS and USE_TMPFS=no on main [14-ALPHA2 based]: extensive vlruwk for cpdup's on new builders after pkg builds in first builder

2023-08-23 Thread Mateusz Guzik

t; zoptb/BUILDs/main-amd64-dbg-clang9.96G   765G  9.96G
>>> /usr/obj/BUILDs/main-amd64-dbg-clang
>>> zoptb/BUILDs/main-amd64-dbg-gccxtc   38.5M   765G  38.5M
>>> /usr/obj/BUILDs/main-amd64-dbg-gccxtc
>>> zoptb/BUILDs/main-amd64-nodbg-clang  10.3G   765G  10.3G
>>> /usr/obj/BUILDs/main-amd64-nodbg-clang
>>> zoptb/BUILDs/main-amd64-nodbg-clang-alt  37.2M   765G  37.2M
>>> /usr/obj/BUILDs/main-amd64-nodbg-clang-alt
>>> zoptb/BUILDs/main-amd64-nodbg-gccxtc 94.6M   765G  94.6M
>>> /usr/obj/BUILDs/main-amd64-nodbg-gccxtc
>>> zoptb/DESTDIRs   4.33G   765G   104K
>>> /usr/obj/DESTDIRs
>>> zoptb/DESTDIRs/main-amd64-poud   2.16G   765G  2.16G
>>> /usr/obj/DESTDIRs/main-amd64-poud
>>> zoptb/DESTDIRs/main-amd64-poud-bulk_a2.16G   765G  2.16G
>>> /usr/obj/DESTDIRs/main-amd64-poud-bulk_a
>>> zoptb/ROOT   13.1G   765G96K  none
>>> zoptb/ROOT/build_area_for-main-amd64 5.03G   765G  3.24G  none
>>> zoptb/ROOT/main-amd648.04G   765G  3.23G  none
>>> zoptb/poudriere  6.58G   765G   112K
>>> /usr/local/poudriere
>>> zoptb/poudriere/data 6.58G   765G   128K
>>> /usr/local/poudriere/data
>>> zoptb/poudriere/data/.m   112K   765G   112K
>>> /usr/local/poudriere/data/.m
>>> zoptb/poudriere/data/cache   17.4M   765G  17.4M
>>> /usr/local/poudriere/data/cache
>>> zoptb/poudriere/data/images96K   765G96K
>>> /usr/local/poudriere/data/images
>>> zoptb/poudriere/data/logs2.72G   765G  2.72G
>>> /usr/local/poudriere/data/logs
>>> zoptb/poudriere/data/packages3.84G   765G  3.84G
>>> /usr/local/poudriere/data/packages
>>> zoptb/poudriere/data/wrkdirs  112K   765G   112K
>>> /usr/local/poudriere/data/wrkdirs
>>> zoptb/poudriere/jails  96K   765G96K
>>> /usr/local/poudriere/jails
>>> zoptb/poudriere/ports  96K   765G96K
>>> /usr/local/poudriere/ports
>>> zoptb/tmp68.5M   765G  68.5M  /tmp
>>> zoptb/usr35.1G   765G96K  /usr
>>> zoptb/usr/13_0R-src  2.64G   765G  2.64G
>>> /usr/13_0R-src
>>> zoptb/usr/alt-main-src 96K   765G96K
>>> /usr/alt-main-src
>>> zoptb/usr/home181M   765G   181M
>>> /usr/home
>>> zoptb/usr/local  5.08G   765G  5.08G
>>> /usr/local
>>> zoptb/usr/main-src833M   765G   833M
>>> /usr/main-src
>>> zoptb/usr/ports  26.4G   765G  26.4G
>>> /usr/ports
>>> zoptb/usr/src  96K   765G96K
>>> /usr/src
>>> zoptb/var52.6M   765G96K  /var
>>> zoptb/var/audit   356K   765G   356K
>>> /var/audit
>>> zoptb/var/crash   128K   765G   128K
>>> /var/crash
>>> zoptb/var/db 49.7M   765G96K
>>> /var/db
>>> zoptb/var/db/pkg 49.4M   765G  49.4M
>>> /var/db/pkg
>>> zoptb/var/db/ports164K   765G   164K
>>> /var/db/ports
>>> zoptb/var/log1.61M   765G  1.61M
>>> /var/log
>>> zoptb/var/mail632K   765G   632K
>>> /var/mail
>>> zoptb/var/tmp 128K   765G   128K
>>> /var/tmp
>>>
>>> # poudriere jail -jmain-amd64-bulk_a -i
>>> Jail name: main-amd64-bulk_a
>>> Jail version:  14.0-ALPHA2
>>> Jail arch: amd64
>>> Jail method:   null
>>> Jail mount:/usr/obj/DESTDIRs/main-amd64-poud-bulk_a
>>> Jail fs:
>>> Jail updated:  2021-12-04 14:55:22
>>> Jail pkgbase:  disabled
>>>
>>>
>>>
>>> So, setting up another test with some related information
>>> shown before, during, and after. sysctl output is from
>>> another ssh session than the bulk -a run.
>>>
>>> # sysctl -a | grep vnode
>>> kern.maxvnodes: 2213808
>>

Re: poudriere bulk with ZFS and USE_TMPFS=no on main [14-ALPHA2 based]: extensive vlruwk for cpdup's on new builders after pkg builds in first builder

2023-08-23 Thread Mark Millard

zoptb/BUILDs/main-amd64-dbg-clang9.96G   765G  9.96G
>>> /usr/obj/BUILDs/main-amd64-dbg-clang
>>> zoptb/BUILDs/main-amd64-dbg-gccxtc   38.5M   765G  38.5M
>>> /usr/obj/BUILDs/main-amd64-dbg-gccxtc
>>> zoptb/BUILDs/main-amd64-nodbg-clang  10.3G   765G  10.3G
>>> /usr/obj/BUILDs/main-amd64-nodbg-clang
>>> zoptb/BUILDs/main-amd64-nodbg-clang-alt  37.2M   765G  37.2M
>>> /usr/obj/BUILDs/main-amd64-nodbg-clang-alt
>>> zoptb/BUILDs/main-amd64-nodbg-gccxtc 94.6M   765G  94.6M
>>> /usr/obj/BUILDs/main-amd64-nodbg-gccxtc
>>> zoptb/DESTDIRs   4.33G   765G   104K
>>> /usr/obj/DESTDIRs
>>> zoptb/DESTDIRs/main-amd64-poud   2.16G   765G  2.16G
>>> /usr/obj/DESTDIRs/main-amd64-poud
>>> zoptb/DESTDIRs/main-amd64-poud-bulk_a2.16G   765G  2.16G
>>> /usr/obj/DESTDIRs/main-amd64-poud-bulk_a
>>> zoptb/ROOT   13.1G   765G96K  none
>>> zoptb/ROOT/build_area_for-main-amd64 5.03G   765G  3.24G  none
>>> zoptb/ROOT/main-amd648.04G   765G  3.23G  none
>>> zoptb/poudriere  6.58G   765G   112K
>>> /usr/local/poudriere
>>> zoptb/poudriere/data 6.58G   765G   128K
>>> /usr/local/poudriere/data
>>> zoptb/poudriere/data/.m   112K   765G   112K
>>> /usr/local/poudriere/data/.m
>>> zoptb/poudriere/data/cache   17.4M   765G  17.4M
>>> /usr/local/poudriere/data/cache
>>> zoptb/poudriere/data/images96K   765G96K
>>> /usr/local/poudriere/data/images
>>> zoptb/poudriere/data/logs2.72G   765G  2.72G
>>> /usr/local/poudriere/data/logs
>>> zoptb/poudriere/data/packages3.84G   765G  3.84G
>>> /usr/local/poudriere/data/packages
>>> zoptb/poudriere/data/wrkdirs  112K   765G   112K
>>> /usr/local/poudriere/data/wrkdirs
>>> zoptb/poudriere/jails  96K   765G96K
>>> /usr/local/poudriere/jails
>>> zoptb/poudriere/ports  96K   765G96K
>>> /usr/local/poudriere/ports
>>> zoptb/tmp68.5M   765G  68.5M  /tmp
>>> zoptb/usr35.1G   765G96K  /usr
>>> zoptb/usr/13_0R-src  2.64G   765G  2.64G
>>> /usr/13_0R-src
>>> zoptb/usr/alt-main-src 96K   765G96K
>>> /usr/alt-main-src
>>> zoptb/usr/home181M   765G   181M  /usr/home
>>> zoptb/usr/local  5.08G   765G  5.08G
>>> /usr/local
>>> zoptb/usr/main-src833M   765G   833M
>>> /usr/main-src
>>> zoptb/usr/ports  26.4G   765G  26.4G
>>> /usr/ports
>>> zoptb/usr/src  96K   765G96K  /usr/src
>>> zoptb/var52.6M   765G96K  /var
>>> zoptb/var/audit   356K   765G   356K
>>> /var/audit
>>> zoptb/var/crash   128K   765G   128K
>>> /var/crash
>>> zoptb/var/db 49.7M   765G96K  /var/db
>>> zoptb/var/db/pkg 49.4M   765G  49.4M
>>> /var/db/pkg
>>> zoptb/var/db/ports164K   765G   164K
>>> /var/db/ports
>>> zoptb/var/log1.61M   765G  1.61M  /var/log
>>> zoptb/var/mail632K   765G   632K  /var/mail
>>> zoptb/var/tmp 128K   765G   128K  /var/tmp
>>> 
>>> # poudriere jail -jmain-amd64-bulk_a -i
>>> Jail name: main-amd64-bulk_a
>>> Jail version:  14.0-ALPHA2
>>> Jail arch: amd64
>>> Jail method:   null
>>> Jail mount:/usr/obj/DESTDIRs/main-amd64-poud-bulk_a
>>> Jail fs:
>>> Jail updated:  2021-12-04 14:55:22
>>> Jail pkgbase:  disabled
>>> 
>>> 
>>> 
>>> So, setting up another test with some related information
>>> shown before, during, and after. sysctl output is from
>>> another ssh session than the bulk -a run.
>>> 
>>> # sysctl -a | grep vnode
>>> kern.maxvnodes: 2213808
>>> kern.ipc.umtx_vnode_persistent: 0
>>

Re: poudriere bulk with ZFS and USE_TMPFS=no on main [14-ALPHA2 based]: extensive vlruwk for cpdup's on new builders after pkg builds in first builder

2023-08-23 Thread Mark Millard

>> zoptb/BUILDs/main-amd64-nodbg-clang-alt  37.2M   765G  37.2M
>> /usr/obj/BUILDs/main-amd64-nodbg-clang-alt
>> zoptb/BUILDs/main-amd64-nodbg-gccxtc 94.6M   765G  94.6M
>> /usr/obj/BUILDs/main-amd64-nodbg-gccxtc
>> zoptb/DESTDIRs   4.33G   765G   104K
>> /usr/obj/DESTDIRs
>> zoptb/DESTDIRs/main-amd64-poud   2.16G   765G  2.16G
>> /usr/obj/DESTDIRs/main-amd64-poud
>> zoptb/DESTDIRs/main-amd64-poud-bulk_a2.16G   765G  2.16G
>> /usr/obj/DESTDIRs/main-amd64-poud-bulk_a
>> zoptb/ROOT   13.1G   765G96K  none
>> zoptb/ROOT/build_area_for-main-amd64 5.03G   765G  3.24G  none
>> zoptb/ROOT/main-amd648.04G   765G  3.23G  none
>> zoptb/poudriere  6.58G   765G   112K
>> /usr/local/poudriere
>> zoptb/poudriere/data 6.58G   765G   128K
>> /usr/local/poudriere/data
>> zoptb/poudriere/data/.m   112K   765G   112K
>> /usr/local/poudriere/data/.m
>> zoptb/poudriere/data/cache   17.4M   765G  17.4M
>> /usr/local/poudriere/data/cache
>> zoptb/poudriere/data/images96K   765G96K
>> /usr/local/poudriere/data/images
>> zoptb/poudriere/data/logs2.72G   765G  2.72G
>> /usr/local/poudriere/data/logs
>> zoptb/poudriere/data/packages3.84G   765G  3.84G
>> /usr/local/poudriere/data/packages
>> zoptb/poudriere/data/wrkdirs  112K   765G   112K
>> /usr/local/poudriere/data/wrkdirs
>> zoptb/poudriere/jails  96K   765G96K
>> /usr/local/poudriere/jails
>> zoptb/poudriere/ports  96K   765G96K
>> /usr/local/poudriere/ports
>> zoptb/tmp68.5M   765G  68.5M  /tmp
>> zoptb/usr35.1G   765G96K  /usr
>> zoptb/usr/13_0R-src  2.64G   765G  2.64G
>> /usr/13_0R-src
>> zoptb/usr/alt-main-src 96K   765G96K
>> /usr/alt-main-src
>> zoptb/usr/home181M   765G   181M  /usr/home
>> zoptb/usr/local  5.08G   765G  5.08G
>> /usr/local
>> zoptb/usr/main-src833M   765G   833M
>> /usr/main-src
>> zoptb/usr/ports  26.4G   765G  26.4G
>> /usr/ports
>> zoptb/usr/src  96K   765G96K  /usr/src
>> zoptb/var52.6M   765G96K  /var
>> zoptb/var/audit   356K   765G   356K
>> /var/audit
>> zoptb/var/crash   128K   765G   128K
>> /var/crash
>> zoptb/var/db 49.7M   765G96K  /var/db
>> zoptb/var/db/pkg 49.4M   765G  49.4M
>> /var/db/pkg
>> zoptb/var/db/ports164K   765G   164K
>> /var/db/ports
>> zoptb/var/log1.61M   765G  1.61M  /var/log
>> zoptb/var/mail632K   765G   632K  /var/mail
>> zoptb/var/tmp 128K   765G   128K  /var/tmp
>> 
>> # poudriere jail -jmain-amd64-bulk_a -i
>> Jail name: main-amd64-bulk_a
>> Jail version:  14.0-ALPHA2
>> Jail arch: amd64
>> Jail method:   null
>> Jail mount:/usr/obj/DESTDIRs/main-amd64-poud-bulk_a
>> Jail fs:
>> Jail updated:  2021-12-04 14:55:22
>> Jail pkgbase:  disabled
>> 
>> 
>> 
>> So, setting up another test with some related information
>> shown before, during, and after. sysctl output is from
>> another ssh session than the bulk -a run.
>> 
>> # sysctl -a | grep vnode
>> kern.maxvnodes: 2213808
>> kern.ipc.umtx_vnode_persistent: 0
>> kern.minvnodes: 553452
>> vm.vnode_pbufs: 2048
>> vm.stats.vm.v_vnodepgsout: 0
>> vm.stats.vm.v_vnodepgsin: 272429
>> vm.stats.vm.v_vnodeout: 0
>> vm.stats.vm.v_vnodein: 12461
>> vfs.vnode_alloc_sleeps: 0
>> vfs.wantfreevnodes: 553452
>> vfs.freevnodes: 962766
>> vfs.vnodes_created: 2538980
>> vfs.numvnodes: 1056233
>> vfs.cache.debug.vnodes_cel_3_failures: 0
>> vfs.cache.stats.heldvnodes: 91878
>> debug.vnode_domainset: 
>> debug.sizeof.vnode: 448
>> debug.fail_point.status_fill_kinfo_vnode__random_path: off
>> debug.fail_point.fill_kinfo_vnode__random_path: off
>> 
>> # poudriere bulk -jmain-amd64-bulk_a -a
>>

Re: poudriere bulk with ZFS and USE_TMPFS=no on main [14-ALPHA2 based]: extensive vlruwk for cpdup's on new builders after pkg builds in first builder

2023-08-23 Thread Mateusz Guzik

n-amd64-poud
> zoptb/DESTDIRs/main-amd64-poud-bulk_a2.16G   765G  2.16G
> /usr/obj/DESTDIRs/main-amd64-poud-bulk_a
> zoptb/ROOT   13.1G   765G96K  none
> zoptb/ROOT/build_area_for-main-amd64 5.03G   765G  3.24G  none
> zoptb/ROOT/main-amd648.04G   765G  3.23G  none
> zoptb/poudriere  6.58G   765G   112K
> /usr/local/poudriere
> zoptb/poudriere/data 6.58G   765G   128K
> /usr/local/poudriere/data
> zoptb/poudriere/data/.m   112K   765G   112K
> /usr/local/poudriere/data/.m
> zoptb/poudriere/data/cache   17.4M   765G  17.4M
> /usr/local/poudriere/data/cache
> zoptb/poudriere/data/images96K   765G96K
> /usr/local/poudriere/data/images
> zoptb/poudriere/data/logs2.72G   765G  2.72G
> /usr/local/poudriere/data/logs
> zoptb/poudriere/data/packages3.84G   765G  3.84G
> /usr/local/poudriere/data/packages
> zoptb/poudriere/data/wrkdirs  112K   765G   112K
> /usr/local/poudriere/data/wrkdirs
> zoptb/poudriere/jails  96K   765G96K
> /usr/local/poudriere/jails
> zoptb/poudriere/ports  96K   765G96K
> /usr/local/poudriere/ports
> zoptb/tmp68.5M   765G  68.5M  /tmp
> zoptb/usr35.1G   765G96K  /usr
> zoptb/usr/13_0R-src  2.64G   765G  2.64G
> /usr/13_0R-src
> zoptb/usr/alt-main-src 96K   765G96K
> /usr/alt-main-src
> zoptb/usr/home181M   765G   181M  /usr/home
> zoptb/usr/local  5.08G   765G  5.08G
> /usr/local
> zoptb/usr/main-src833M   765G   833M
> /usr/main-src
> zoptb/usr/ports  26.4G   765G  26.4G
> /usr/ports
> zoptb/usr/src  96K   765G96K  /usr/src
> zoptb/var52.6M   765G96K  /var
> zoptb/var/audit   356K   765G   356K
> /var/audit
> zoptb/var/crash   128K   765G   128K
> /var/crash
> zoptb/var/db 49.7M   765G96K  /var/db
> zoptb/var/db/pkg 49.4M   765G  49.4M
> /var/db/pkg
> zoptb/var/db/ports164K   765G   164K
> /var/db/ports
> zoptb/var/log1.61M   765G  1.61M  /var/log
> zoptb/var/mail632K   765G   632K  /var/mail
> zoptb/var/tmp 128K   765G   128K  /var/tmp
>
> # poudriere jail -jmain-amd64-bulk_a -i
> Jail name: main-amd64-bulk_a
> Jail version:  14.0-ALPHA2
> Jail arch: amd64
> Jail method:   null
> Jail mount:/usr/obj/DESTDIRs/main-amd64-poud-bulk_a
> Jail fs:
> Jail updated:  2021-12-04 14:55:22
> Jail pkgbase:  disabled
>
>
>
> So, setting up another test with some related information
> shown before, during, and after. sysctl output is from
> another ssh session than the bulk -a run.
>
> # sysctl -a | grep vnode
> kern.maxvnodes: 2213808
> kern.ipc.umtx_vnode_persistent: 0
> kern.minvnodes: 553452
> vm.vnode_pbufs: 2048
> vm.stats.vm.v_vnodepgsout: 0
> vm.stats.vm.v_vnodepgsin: 272429
> vm.stats.vm.v_vnodeout: 0
> vm.stats.vm.v_vnodein: 12461
> vfs.vnode_alloc_sleeps: 0
> vfs.wantfreevnodes: 553452
> vfs.freevnodes: 962766
> vfs.vnodes_created: 2538980
> vfs.numvnodes: 1056233
> vfs.cache.debug.vnodes_cel_3_failures: 0
> vfs.cache.stats.heldvnodes: 91878
> debug.vnode_domainset: 
> debug.sizeof.vnode: 448
> debug.fail_point.status_fill_kinfo_vnode__random_path: off
> debug.fail_point.fill_kinfo_vnode__random_path: off
>
> # poudriere bulk -jmain-amd64-bulk_a -a
> . . .
> [00:01:34] Building 34042 packages using up to 32 builders
> [00:01:34] Hit CTRL+t at any time to see build progress and stats
> [00:01:34] [01] [00:00:00] Builder starting
> [00:01:57] [01] [00:00:23] Builder started
> [00:01:57] [01] [00:00:00] Building ports-mgmt/pkg | pkg-1.20.4
> [00:03:09] [01] [00:01:12] Finished ports-mgmt/pkg | pkg-1.20.4: Success
> [00:03:22] [01] [00:00:00] Building print/indexinfo | indexinfo-0.3.1
> [00:03:22] [02] [00:00:00] Builder starting
> [00:03:22] [03] [00:00:00] Builder starting
> . . .
> [00:03:22] [31] [00:00:00] Builder starting
> [00:03:22] [32] [00:00:00] Builder starting
> [00:03:31] [01] [00:00:09] Finished print/indexinfo | indexinfo-0.3.1:
> Success
> [00:03:31] [01] [00:00:00

poudriere bulk with ZFS and USE_TMPFS=no on main [14-ALPHA2 based]: extensive vlruwk for cpdup's on new builders after pkg builds in first builder

2023-08-23 Thread Mark Millard

 112K  
/usr/local/poudriere
zoptb/poudriere/data 6.58G   765G   128K  
/usr/local/poudriere/data
zoptb/poudriere/data/.m   112K   765G   112K  
/usr/local/poudriere/data/.m
zoptb/poudriere/data/cache   17.4M   765G  17.4M  
/usr/local/poudriere/data/cache
zoptb/poudriere/data/images96K   765G96K  
/usr/local/poudriere/data/images
zoptb/poudriere/data/logs2.72G   765G  2.72G  
/usr/local/poudriere/data/logs
zoptb/poudriere/data/packages3.84G   765G  3.84G  
/usr/local/poudriere/data/packages
zoptb/poudriere/data/wrkdirs  112K   765G   112K  
/usr/local/poudriere/data/wrkdirs
zoptb/poudriere/jails  96K   765G96K  
/usr/local/poudriere/jails
zoptb/poudriere/ports  96K   765G96K  
/usr/local/poudriere/ports
zoptb/tmp68.5M   765G  68.5M  /tmp
zoptb/usr35.1G   765G96K  /usr
zoptb/usr/13_0R-src  2.64G   765G  2.64G  /usr/13_0R-src
zoptb/usr/alt-main-src 96K   765G96K  
/usr/alt-main-src
zoptb/usr/home181M   765G   181M  /usr/home
zoptb/usr/local  5.08G   765G  5.08G  /usr/local
zoptb/usr/main-src833M   765G   833M  /usr/main-src
zoptb/usr/ports  26.4G   765G  26.4G  /usr/ports
zoptb/usr/src  96K   765G96K  /usr/src
zoptb/var52.6M   765G96K  /var
zoptb/var/audit   356K   765G   356K  /var/audit
zoptb/var/crash   128K   765G   128K  /var/crash
zoptb/var/db 49.7M   765G96K  /var/db
zoptb/var/db/pkg 49.4M   765G  49.4M  /var/db/pkg
zoptb/var/db/ports164K   765G   164K  /var/db/ports
zoptb/var/log1.61M   765G  1.61M  /var/log
zoptb/var/mail632K   765G   632K  /var/mail
zoptb/var/tmp 128K   765G   128K  /var/tmp

# poudriere jail -jmain-amd64-bulk_a -i
Jail name: main-amd64-bulk_a
Jail version:  14.0-ALPHA2
Jail arch: amd64
Jail method:   null
Jail mount:/usr/obj/DESTDIRs/main-amd64-poud-bulk_a
Jail fs:   
Jail updated:  2021-12-04 14:55:22
Jail pkgbase:  disabled



So, setting up another test with some related information
shown before, during, and after. sysctl output is from
another ssh session than the bulk -a run.

# sysctl -a | grep vnode
kern.maxvnodes: 2213808
kern.ipc.umtx_vnode_persistent: 0
kern.minvnodes: 553452
vm.vnode_pbufs: 2048
vm.stats.vm.v_vnodepgsout: 0
vm.stats.vm.v_vnodepgsin: 272429
vm.stats.vm.v_vnodeout: 0
vm.stats.vm.v_vnodein: 12461
vfs.vnode_alloc_sleeps: 0
vfs.wantfreevnodes: 553452
vfs.freevnodes: 962766
vfs.vnodes_created: 2538980
vfs.numvnodes: 1056233
vfs.cache.debug.vnodes_cel_3_failures: 0
vfs.cache.stats.heldvnodes: 91878
debug.vnode_domainset: 
debug.sizeof.vnode: 448
debug.fail_point.status_fill_kinfo_vnode__random_path: off
debug.fail_point.fill_kinfo_vnode__random_path: off

# poudriere bulk -jmain-amd64-bulk_a -a
. . .
[00:01:34] Building 34042 packages using up to 32 builders
[00:01:34] Hit CTRL+t at any time to see build progress and stats
[00:01:34] [01] [00:00:00] Builder starting
[00:01:57] [01] [00:00:23] Builder started
[00:01:57] [01] [00:00:00] Building ports-mgmt/pkg | pkg-1.20.4
[00:03:09] [01] [00:01:12] Finished ports-mgmt/pkg | pkg-1.20.4: Success
[00:03:22] [01] [00:00:00] Building print/indexinfo | indexinfo-0.3.1
[00:03:22] [02] [00:00:00] Builder starting
[00:03:22] [03] [00:00:00] Builder starting
. . .
[00:03:22] [31] [00:00:00] Builder starting
[00:03:22] [32] [00:00:00] Builder starting
[00:03:31] [01] [00:00:09] Finished print/indexinfo | indexinfo-0.3.1: Success
[00:03:31] [01] [00:00:00] Building devel/gettext-runtime | gettext-runtime-0.22
. . .

Note that only [01] makes progress: no new "Builder started"
notices occur. top shows 31 of the pattern:
cpdup -i0 -o ref ??

Then during the 31 cpudup's showing vlruwk most of the time:

# sysctl -a | grep vnode
kern.maxvnodes: 2213808
kern.ipc.umtx_vnode_persistent: 0
kern.minvnodes: 553452
vm.vnode_pbufs: 2048
vm.stats.vm.v_vnodepgsout: 22844
vm.stats.vm.v_vnodepgsin: 582398
vm.stats.vm.v_vnodeout: 890
vm.stats.vm.v_vnodein: 34296
vfs.vnode_alloc_sleeps: 2994
vfs.wantfreevnodes: 553452
vfs.freevnodes: 2209662
vfs.vnodes_created: 12206299
vfs.numvnodes: 2214071
vfs.cache.debug.vnodes_cel_3_failures: 0
vfs.cache.stats.heldvnodes: 459
debug.vnode_domainset: 
debug.sizeof.vnode: 448
debug.fail_point.status_fill_kinfo_vnode__random_path: off
debug.fail_point.fill_kinfo_vnode__random_path: off

Wait a while bu

Re: Question about KBI change / new feature

2023-08-22 Thread Warner Losh

On Mon, Aug 21, 2023 at 9:42 AM Zhenlei Huang  wrote:

> Hi,
>
> The https://www.freebsd.org/releases/14.0R/schedule/ says CURRENT/14 's
> KBI is froze
> and new features should be avoided.
>
> I'm working on https://reviews.freebsd.org/D39638 (sysctl(9): Enable vnet
> sysctl variables be loader tunable)
> and I think it is new feature, but not quite sure whether the KBI changed.
>
> So,
>
> 1. Is it a KBI change ?
>

IMHO, It's a KPI change, not a KBI breakage. So from that perspective, it's
OK.

> 2. It is a simple change ( while so far as I know currently only tested by
> myself on x86 and qemu riscv ), can
> it catch up with 14 ?

That I'm less sure of. I think it's good, but I'm gun shy about approving /
committing vnet things. The review suggests,
though, there's at least some consensus for having this in the tree.

> Best regards,
> Zhenlei
>
>
>

Question about KBI change / new feature

2023-08-21 Thread Zhenlei Huang

Hi,

The https://www.freebsd.org/releases/14.0R/schedule/ says CURRENT/14 's KBI is 
froze
and new features should be avoided.

I'm working on https://reviews.freebsd.org/D39638 (sysctl(9): Enable vnet 
sysctl variables be loader tunable)
and I think it is new feature, but not quite sure whether the KBI changed.

So,

1. Is it a KBI change ?

2. It is a simple change ( while so far as I know currently only tested by 
myself on x86 and qemu riscv ), can
it catch up with 14 ?


Best regards,
Zhenlei

New FreeBSD snapshots available: main (ALPHA2) (20230819 77013f29d048)

2023-08-18 Thread Glen Barber

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

New FreeBSD development branch installation ISOs and virtual machine
disk images have been uploaded to the FreeBSD Project mirrors.

As with any development branch, the installation snapshots are not
intended for use on production systems.  We do, however, encourage
testing on non-production systems as much as possible.

Please also consider installing the sysutils/panicmail port, which can
help in providing FreeBSD developers the necessary information regarding
system crashes.

Checksums for the installation ISOs and the VM disk images follow at
the end of this email.

=== Installation ISOs ===

Installation images are available for:

o 14.0-ALPHA2 amd64 GENERIC
o 14.0-ALPHA2 i386 GENERIC
o 14.0-ALPHA2 powerpc GENERIC
o 14.0-ALPHA2 powerpc64 GENERIC64
o 14.0-ALPHA2 powerpc64le GENERIC64LE
o 14.0-ALPHA2 powerpcspe MPC85XXSPE
o 14.0-ALPHA2 armv6 RPI-B
o 14.0-ALPHA2 armv7 GENERICSD
o 14.0-ALPHA2 aarch64 GENERIC
o 14.0-ALPHA2 aarch64 RPI
o 14.0-ALPHA2 aarch64 PINE64
o 14.0-ALPHA2 aarch64 PINE64-LTS
o 14.0-ALPHA2 aarch64 PINEBOOK
o 14.0-ALPHA2 aarch64 ROCK64
o 14.0-ALPHA2 aarch64 ROCKPRO64
o 14.0-ALPHA2 riscv64 GENERIC
o 14.0-ALPHA2 riscv64 GENERICSD

Note regarding arm/armv{6,7} images: For convenience for those without
console access to the system, a freebsd user with a password of
freebsd is available by default for ssh(1) access.  Additionally,
the root user password is set to root, which it is strongly
recommended to change the password for both users after gaining
access to the system.

Snapshots may be downloaded from the corresponding architecture
directory from:

https://download.freebsd.org/snapshots/ISO-IMAGES/

Please be patient if your local mirror has not yet caught up with the
changes.

Problems, bug reports, or regression reports should be reported through
the Bugzilla PR system or the appropriate mailing list such as -current@
or -stable@ .

=== Virtual Machine Disk Images ===

VM disk images are available for the following architectures:

o 14.0-ALPHA2 amd64
o 14.0-ALPHA2 i386
o 14.0-ALPHA2 aarch64
o 14.0-ALPHA2 riscv64
o 14.0-ALPHA2 amd64 BASIC-CI

Disk images may be downloaded from the following URL (or any of the
FreeBSD Project mirrors):

https://download.freebsd.org/snapshots/VM-IMAGES/

Images are available in the following disk image formats:

~ RAW
~ QCOW2 (qemu)
~ VMDK (qemu, VirtualBox, VMWare)
~ VHD (qemu, xen)

The partition layout is:

~ 512k - freebsd-boot GPT partition type (bootfs GPT label)
~ 1GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 24GB - freebsd-ufs GPT partition type (rootfs GPT label)

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  This is provided by the emulators/qemu port.

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  
-bios /usr/local/share/qemu/edk2-aarch64-code.fd 
-serial telnet::,server -nographic 
-drive if=none,file=VMDISK,id=hd0 
-device virtio-blk-device,drive=hd0 
-device virtio-net-device,netdev=net0 
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

BASIC-CI images can be found at:

https://download.freebsd.org/snapshots/VM-IMAGES/

=== Amazon EC2 AMI Images ===

FreeBSD amd64 and aarch64 EC2 AMIs are available for both UFS and ZFS.
The AMI IDs can be retreived from the Systems Manager Parameter Store in
each region using the keys:

/aws/service/freebsd/amd64/base/ufs/14.0/ALPHA2
/aws/service/freebsd/arm64/base/ufs/14.0/ALPHA2

/aws/service/freebsd/amd64/base/zfs/14.0/ALPHA2
/aws/service/freebsd/arm64/base/zfs/14.0/ALPHA2

=== Vagrant Images ===

FreeBSD/amd64 images are available on the Hashicorp Atlas site for the
VMWare Desktop and VirtualBox providers, and can be installed by
running:

% vagrant init freebsd/FreeBSD-14.0-ALPHA2
% vagrant up

== ISO CHECKSUMS ==

o 14.0-ALPHA2 amd64 GENERIC:
  SHA512 (FreeBSD-14.0-ALPHA2-amd64-20230818-77013f29d048-264841-bootonly.iso) 
= 
02b4a7ba3a9520031607e6ebcbdf6cd142044aa1af40ad452c9d9793c5e70ebad94b13e679f5cb0aaa473e20f9da1f63b335b0cd25323aa03b14bd539b565ee1
  SHA512 
(FreeBSD-14.0-ALPHA2-amd64-20230818-77013f29d048-264841-bootonly.iso.xz) = 
966041afcb3df8cc35063592d67ad146453783941bff80fa019d42df6e624dca2a8763940f20a7cc3857bf708e6f76e1420ed18af4a1d287cec004bdd31893ee
  SHA512 (FreeBSD-14.0-ALPHA2-amd64-20230818-77013f29d048-264841-disc1.iso) = 
76f8ff46e679d4920cfe67179a587abdfd323e83c3e3f79f39678f6a956b888cf4a2a1962f9a0549a1fb481912ef41fb666bd518dc1775e90488c31b841d6aca
  SHA512 (FreeBSD-14.0-ALPHA2-amd64-20230818-77013f29d048-264841-disc1.iso.xz) 
= 
c61970abd7f2b7c0a81d5bf702e3cc65129843e3624b1a93a1476ffe535adb8dbb13378b3b049d2e742e47383c3f6bb3b2b0678977ee11873c0b50414070ea1e
  SHA512 (FreeBSD-1

Re: Lacking "arminess" (was Re: New FreeBSD snapshots available) (OFF TOPIC)

2023-08-13 Thread Glen Barber

Ship it!

Glen
Sent from my phone.
Please excuse my brevity and/or typos.

> On Aug 13, 2023, at 2:39 PM, George Mitchell  wrote:
> 
> On 8/11/23 23:15, Glen Barber wrote:
>> [...]
>> It was discovered that due to human error (my own) the arm64 are, as
>> Colin put it very politely, are "lacking 'arminess'".  So, unfortunately
>> the arm64 AMIs for 14.0-ALPHA1 are incorrectly uploaded as amd64.
>> [...]
> Many years ago, one member of M.I.T.'s Tech Model Railroad Club had the
> annoying habit of assembling his model airplanes in the clubroom.  Soon,
> the club enacted a rule banning all objects capable of sustained flight
> from the club for a period o ninety-nine years and one day.  Thereafter,
> it became established procedure for the club to issue reprimands by
> declaring certain people "capable of sustained flight."
> 
> I now propose to express my displeasure with aspects of FreeBSD (which
> almost never happens, honestly!) by declaring them to "lack arminess."
> 
> My thanks to Glen Barber and Colin for creating this terminology.
> -- George
>

Re: New FreeBSD snapshots available: stable/14 (ALPHA1) (20230811 136fc495615f)

2023-08-11 Thread Glen Barber

On Fri, Aug 11, 2023 at 08:53:12PM +, Glen Barber wrote:
[...]

> FreeBSD/aarch64 UFS EC2 AMIs are available in the following regions:
> 
[...]

> 
> FreeBSD/aarch64 ZFS EC2 AMIs are available in the following regions:
> 

[...]

It was discovered that due to human error (my own) the arm64 are, as
Colin put it very politely, are "lacking 'arminess'".  So, unfortunately
the arm64 AMIs for 14.0-ALPHA1 are incorrectly uploaded as amd64.

But you will receive a message stating it is the incorrect architecture,
which is better than passively failing.

Apologies for the inconvenience.

Glen

signature.asc
Description: PGP signature

New FreeBSD snapshots available: stable/14 (ALPHA1) (20230811 136fc495615f)

2023-08-11 Thread Glen Barber

New FreeBSD development branch installation ISOs and virtual machine
disk images have been uploaded to the FreeBSD Project mirrors.

As with any development branch, the installation snapshots are not
intended for use on production systems.  We do, however, encourage
testing on non-production systems as much as possible.

Please also consider installing the sysutils/panicmail port, which can
help in providing FreeBSD developers the necessary information regarding
system crashes.

Checksums for the installation ISOs and the VM disk images follow at
the end of this email.

=== Installation ISOs ===

Installation images are available for:

o 14.0-ALPHA1 amd64 GENERIC
o 14.0-ALPHA1 i386 GENERIC
o 14.0-ALPHA1 powerpc GENERIC
o 14.0-ALPHA1 powerpc64 GENERIC64
o 14.0-ALPHA1 powerpc64le GENERIC64LE
o 14.0-ALPHA1 armv6 RPI-B
o 14.0-ALPHA1 armv7 GENERICSD
o 14.0-ALPHA1 aarch64 GENERIC
o 14.0-ALPHA1 aarch64 RPI
o 14.0-ALPHA1 aarch64 PINE64
o 14.0-ALPHA1 aarch64 PINE64-LTS
o 14.0-ALPHA1 aarch64 PINEBOOK
o 14.0-ALPHA1 aarch64 ROCK64
o 14.0-ALPHA1 aarch64 ROCKPRO64
o 14.0-ALPHA1 riscv64 GENERIC
o 14.0-ALPHA1 riscv64 GENERICSD

Note regarding arm/armv{6,7} images: For convenience for those without
console access to the system, a freebsd user with a password of
freebsd is available by default for ssh(1) access.  Additionally,
the root user password is set to root, which it is strongly
recommended to change the password for both users after gaining
access to the system.

Snapshots may be downloaded from the corresponding architecture
directory from:

https://download.freebsd.org/snapshots/ISO-IMAGES/

Please be patient if your local mirror has not yet caught up with the
changes.

Problems, bug reports, or regression reports should be reported through
the Bugzilla PR system or the appropriate mailing list such as -current@
or -stable@ .

=== Virtual Machine Disk Images ===

VM disk images are available for the following architectures:

o 14.0-ALPHA1 amd64
o 14.0-ALPHA1 i386
o 14.0-ALPHA1 aarch64
o 14.0-ALPHA1 riscv64
o 14.0-ALPHA1 amd64 BASIC-CI

Disk images may be downloaded from the following URL (or any of the
FreeBSD Project mirrors):

https://download.freebsd.org/snapshots/VM-IMAGES/

Images are available in the following disk image formats:

~ RAW
~ QCOW2 (qemu)
~ VMDK (qemu, VirtualBox, VMWare)
~ VHD (qemu, xen)

The partition layout for UFS is:

~ 512k - freebsd-boot GPT partition type (bootfs GPT label)
~ 1GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 24GB - freebsd-ufs GPT partition type (rootfs GPT label)

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  This is provided by the emulators/qemu port.

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  
-bios /usr/local/share/qemu/edk2-aarch64-code.fd 
-serial telnet::,server -nographic 
-drive if=none,file=VMDISK,id=hd0 
-device virtio-blk-device,drive=hd0 
-device virtio-net-device,netdev=net0 
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

BASIC-CI images can be found at:

https://download.freebsd.org/snapshots/CI-IMAGES/

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 UFS EC2 AMIs are available in the following regions:

  ap-south-2 region: ami-0ee95230becf80778
  ap-south-1 region: ami-03ad9777ff8bc0b6e
  eu-south-1 region: ami-0fdfdb9f7c3a58c46
  eu-south-2 region: ami-0ebed85d055e70b39
  me-central-1 region: ami-02c67cb3a99d57d57
  ca-central-1 region: ami-0d0bbdaefd0c0e181
  eu-central-1 region: ami-0a80119c6edde9265
  eu-central-2 region: ami-0a12f1c8e051dfae9
  us-west-1 region: ami-0ea4f8fce960ef2c4
  us-west-2 region: ami-09f3a6925f77e203e
  af-south-1 region: ami-0ef9719a1228e32a5
  eu-north-1 region: ami-02e6c8bc0ce909cbe
  eu-west-3 region: ami-0aa3da21b9907069a
  eu-west-2 region: ami-092c172d577027092
  eu-west-1 region: ami-04cd2017e63b5ebda
  ap-northeast-3 region: ami-077b46cc5d1c68523
  ap-northeast-2 region: ami-00aafa3de31692805
  me-south-1 region: ami-011ee7fb4001bf69f
  ap-northeast-1 region: ami-08ff003b6ff73de93
  sa-east-1 region: ami-052f0128aed100b4a
  ap-east-1 region: ami-05bcf396a33918e60
  ap-southeast-1 region: ami-0b56d17b45366f1bf
  ap-southeast-2 region: ami-01b1c6fd1bb35074d
  ap-southeast-3 region: ami-017073fdb4ae76333
  us-east-1 region: ami-029e7b689f77cce2c
  us-east-2 region: ami-0047bb65a2d73065f

FreeBSD/amd64 ZFS EC2 AMIs are available in the following regions:

  ap-south-2 region: ami-0d3f563d617979348
  ap-south-1 region: ami-03f77404c21fb5a25
  eu-south-1 region: ami-0731187e3d49f6795
  eu-south-2 region: ami-068b99a06abbe9a85
  me-central-1 region: ami-0904554cdebb1ddab
  ca-central-1 region: ami-0e96429bf976b35cb
  eu-central-1 region: ami-0cb9214edc051fc88
  eu-central-2 region: ami-0c4e6aad76680d64d

Re: problems on new -current install with pkg/ssl

2023-07-12 Thread void


thanks everyone it's working normally now after full buildworld
kernel then forced rebuild of all ports from their updated
sources
--

Re: problems on new -current install with pkg/ssl

2023-07-09 Thread Ronald Klop


On 7/9/23 18:27, void wrote:

On Sun, Jul 09, 2023 at 05:17:38PM +0100, void wrote:

Hi,

On a fresh 14-current install (main-n263444-653738e895ba)
I try to use pkg for anything and this error
happens:

# pkg install doas
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y
Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:14:amd64/latest, 
please wait...
Verifying signature with trusted certificate pkg.freebsd.org.2013102301... done
Installing pkg-1.19.2...
Newer FreeBSD version for package pkg:
To ignore this error set IGNORE_OSVERSION=yes
- package: 1400092
- running kernel: 1400090
Ignore the mismatch and continue? [y/N]: y
Extracting pkg-1.19.2: 100%
ld-elf.so.1: Shared object "libssl.so.30" not found, required by "pkg"

How can I fix?


I was able to fix this by downloading 
https://download.freebsd.org/ports/ports/ports.tar.xz
manually to /usr and building from the ports tree



If you upgrade your FreeBSD 14 to the latest version it will work also. OpenSSL 
3.0 is imported into 14 which gives a small overlapping time window in which 
users can still be running older FreeBSD versions with OpenSSL 1.1.1 while the 
official pkg repo compiles using 3.0.

After you upgraded FreeBSD please make sure to upgrade pkg to use openssl3.0 before you 
run "make delete-old-libs".

Regards,
Ronald.

Re: problems on new -current install with pkg/ssl

2023-07-09 Thread Gary Jennejohn

On Sun, 9 Jul 2023 17:17:38 +0100
void  wrote:

> Hi,
>
> On a fresh 14-current install (main-n263444-653738e895ba)
> I try to use pkg for anything and this error
> happens:
>
> # pkg install doas
> The package management tool is not yet installed on your system.
> Do you want to fetch and install it now? [y/N]: y
> Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:14:amd64/latest, 
> please wait...
> Verifying signature with trusted certificate pkg.freebsd.org.2013102301... 
> done
> Installing pkg-1.19.2...
> Newer FreeBSD version for package pkg:
> To ignore this error set IGNORE_OSVERSION=yes
> - package: 1400092
> - running kernel: 1400090
> Ignore the mismatch and continue? [y/N]: y
> Extracting pkg-1.19.2: 100%
> ld-elf.so.1: Shared object "libssl.so.30" not found, required by "pkg"
>
> How can I fix?
>
> --
>

pkg works fine for me, but I'm running

uname -UK
1400093 1400093

Your kernel is too old and your world probably also.

--
Gary Jennejohn

Re: problems on new -current install with pkg/ssl

2023-07-09 Thread Yuri

void wrote:
> Hi,
> 
> On a fresh 14-current install (main-n263444-653738e895ba) I try to use
> pkg for anything and this error
> happens:
> 
> # pkg install doas
> The package management tool is not yet installed on your system.
> Do you want to fetch and install it now? [y/N]: y
> Bootstrapping pkg from
> pkg+http://pkg.FreeBSD.org/FreeBSD:14:amd64/latest, please wait...
> Verifying signature with trusted certificate
> pkg.freebsd.org.2013102301... done
> Installing pkg-1.19.2...
> Newer FreeBSD version for package pkg:
> To ignore this error set IGNORE_OSVERSION=yes
> - package: 1400092
> - running kernel: 1400090
> Ignore the mismatch and continue? [y/N]: y
> Extracting pkg-1.19.2: 100%
> ld-elf.so.1: Shared object "libssl.so.30" not found, required by "pkg"
> 
> How can I fix?

That's the case where you should NOT ignore the "Newer FreeBSD version
for package pkg" warning and update the base OS first, see "OpenSSL 3.0
is in the tree" message on this list.

Re: problems on new -current install with pkg/ssl

2023-07-09 Thread David Wolfskill

On Sun, Jul 09, 2023 at 05:17:38PM +0100, void wrote:
> Hi,
> 
> On a fresh 14-current install (main-n263444-653738e895ba) I try to use pkg
> for anything and this error
> happens:
> 
> # pkg install doas
> The package management tool is not yet installed on your system.
> Do you want to fetch and install it now? [y/N]: y
> Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:14:amd64/latest, 
> please wait...
> Verifying signature with trusted certificate pkg.freebsd.org.2013102301... 
> done
> Installing pkg-1.19.2...
> Newer FreeBSD version for package pkg:
> To ignore this error set IGNORE_OSVERSION=yes
> - package: 1400092
> - running kernel: 1400090

That's warning you that the "pkg" version you're selecting is for
FreeBSD 14 with a "FreeBSD version" of 1400092, but what you're running
is at "1400090".

> Ignore the mismatch and continue? [y/N]: y
> Extracting pkg-1.19.2: 100%
> ld-elf.so.1: Shared object "libssl.so.30" not found, required by "pkg"

So your FreeBSD installtion appears to have been from before the import
of OpenSSL 3, while the "pkg" you just installed requires OpenSSL 3.

> How can I fix?

Either upgrade your FreeBSD installation to some point after the OpenSSL
3 import -- here's the src/UPDATING entry:

20230623:
OpenSSL has been updated to version 3.0, including changes throughout
the base system.  It is important to rebuild third-party software
after upgrading.

The commit was at main-n263775-b077aed33b7b, but there was a bit
of "turbulence"for a few days after that, so I suggest updating to
something more recent.  (My latest successful was
main-n264066-e64780fbc394, FWIW.)

Or downgrade to an older "pkg".  In your position, I'd do the former.

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
"Putin supports any set of ideas to end the conflict,” -- Dmitry Peskov
Putin is the source of the conflict.  Remove the source; end of conflict.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.

signature.asc
Description: PGP signature

Re: problems on new -current install with pkg/ssl

2023-07-09 Thread void


On Sun, Jul 09, 2023 at 05:17:38PM +0100, void wrote:

Hi,

On a fresh 14-current install (main-n263444-653738e895ba)
I try to use pkg for anything and this error
happens:

# pkg install doas
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y
Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:14:amd64/latest, 
please wait...
Verifying signature with trusted certificate pkg.freebsd.org.2013102301... done
Installing pkg-1.19.2...
Newer FreeBSD version for package pkg:
To ignore this error set IGNORE_OSVERSION=yes
- package: 1400092
- running kernel: 1400090
Ignore the mismatch and continue? [y/N]: y
Extracting pkg-1.19.2: 100%
ld-elf.so.1: Shared object "libssl.so.30" not found, required by "pkg"

How can I fix?


I was able to fix this by downloading 
https://download.freebsd.org/ports/ports/ports.tar.xz
manually to /usr and building from the ports tree

--

problems on new -current install with pkg/ssl

2023-07-09 Thread void


Hi,

On a fresh 14-current install (main-n263444-653738e895ba) 
I try to use pkg for anything and this error

happens:

# pkg install doas
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y
Bootstrapping pkg from pkg+http://pkg.FreeBSD.org/FreeBSD:14:amd64/latest, 
please wait...
Verifying signature with trusted certificate pkg.freebsd.org.2013102301... done
Installing pkg-1.19.2...
Newer FreeBSD version for package pkg:
To ignore this error set IGNORE_OSVERSION=yes
- package: 1400092
- running kernel: 1400090
Ignore the mismatch and continue? [y/N]: y
Extracting pkg-1.19.2: 100%
ld-elf.so.1: Shared object "libssl.so.30" not found, required by "pkg"

How can I fix? 


--

Re: No new FreeBSD images on Google Cloud since 13-April

2023-07-03 Thread Alan Somers

On Mon, Jun 19, 2023 at 12:11 PM Alan Somers  wrote:
>
> New builds of stable/13, stable/12, and current used to appear in
> Google Cloud about once per week.  But the latest builds all date from
> 13-April-2023.  Does some script need to be kicked?  To see the
> currently available images, do:
>
> pkg install google-cloud-sdk
> gcloud compute images list --project freebsd-org-cloud-dev 
> --no-standard-images

The situation just got worse.  As a result of the libssl-3.0 upgrade
on 14, all 14.0 images on google cloud are now basically useless.
Among other problems, this means that most downstream projects' CI
workflows on FreeBSD 14 are broken now.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272354

new syctl to allow ignoring time from fs if no rtc found

2023-06-20 Thread Sulev-Madis Silber

unsure if anybody else needs that functionality. i was suggested to submit
it into actual code review place, but i'm unsure. it's from 2014, it still
cleanly applies. probably because noone needed to touch working code!
anyway, i used it in in arm board development, in bbb, to default system
time to "visually invalid" 1970 when no other source was found. i found
getting time from filesystem causing much confusion when files were created
before ntp sync. so i added this hack

http://ketas.si.pri.ee/bbb/src-patches/debug-no-timestamp-from-filesystem.diff

Index: sys/kern/vfs_mountroot.c
===
--- sys/kern/vfs_mountroot.c (revision 274644)
+++ sys/kern/vfs_mountroot.c (working copy)
@@ -968,14 +968,16 @@
* timestamps we encounter.
*/
timebase = 0;
- mtx_lock(&mountlist_mtx);
- mp = TAILQ_FIRST(&mountlist);
- while (mp != NULL) {
- if (mp->mnt_time > timebase)
- timebase = mp->mnt_time;
- mp = TAILQ_NEXT(mp, mnt_list);
+ if (kern_getenv("debug.no_timestamp_from_filesystem") == NULL) {
+ mtx_lock(&mountlist_mtx);
+ mp = TAILQ_FIRST(&mountlist);
+ while (mp != NULL) {
+ if (mp->mnt_time > timebase)
+ timebase = mp->mnt_time;
+ mp = TAILQ_NEXT(mp, mnt_list);
+ }
+ mtx_unlock(&mountlist_mtx);
}
- mtx_unlock(&mountlist_mtx);
inittodr(timebase);

/* Keep prison0's root in sync with the global rootvnode. */
Index: sys/kern/vfs_mountroot.c
===
--- sys/kern/vfs_mountroot.c	(revision 274644)
+++ sys/kern/vfs_mountroot.c	(working copy)
@@ -968,14 +968,16 @@
 	 * timestamps we encounter.
 	 */
 	timebase = 0;
-	mtx_lock(&mountlist_mtx);
-	mp = TAILQ_FIRST(&mountlist);
-	while (mp != NULL) {
-		if (mp->mnt_time > timebase)
-			timebase = mp->mnt_time;
-		mp = TAILQ_NEXT(mp, mnt_list);
+	if (kern_getenv("debug.no_timestamp_from_filesystem") == NULL) {
+		mtx_lock(&mountlist_mtx);
+		mp = TAILQ_FIRST(&mountlist);
+		while (mp != NULL) {
+			if (mp->mnt_time > timebase)
+timebase = mp->mnt_time;
+			mp = TAILQ_NEXT(mp, mnt_list);
+		}
+		mtx_unlock(&mountlist_mtx);
 	}
-	mtx_unlock(&mountlist_mtx);
 	inittodr(timebase);
 
 	/* Keep prison0's root in sync with the global rootvnode. */

No new FreeBSD images on Google Cloud since 13-April

2023-06-19 Thread Alan Somers

New builds of stable/13, stable/12, and current used to appear in
Google Cloud about once per week.  But the latest builds all date from
13-April-2023.  Does some script need to be kicked?  To see the
currently available images, do:

pkg install google-cloud-sdk
gcloud compute images list --project freebsd-org-cloud-dev --no-standard-images

Re: Seemingly random nvme (nda) write error on new drive (retries exhausted)

2023-06-08 Thread Rebecca Cran


On 6/8/23 05:48, Warner Losh wrote:



On Thu, Jun 8, 2023, 4:35 AM Rebecca Cran  wrote:

It's ZFS, using the default options when creating it via the FreeBSD
installer so I presume TRIM is enabled. Without a reliable way to
reproduce the error I'm not sure disabling TRIM will help at the
moment.

I don't think there's any newer firmware for it.


pci gen 4 has a highter error rate so that needs to be managed with 
retries.  There's a whole protocol to do that which linux implements. 
I suspect the time has come for us to do so too. There's some code 
floating around I'll have to track down.


Thanks. I dropped the configuration down to PCIe gen 3 and the errors 
have so far gone away.



nda0: nvme version 1.3 x8 (max x8) lanes PCIe Gen3 (max Gen4) link
nda1: nvme version 1.3 x4 (max x4) lanes PCIe Gen3 (max Gen4) link

--
Rebecca Cran

Re: Seemingly random nvme (nda) write error on new drive (retries exhausted)

2023-06-08 Thread Warner Losh

On Thu, Jun 8, 2023, 4:35 AM Rebecca Cran  wrote:

> It's ZFS, using the default options when creating it via the FreeBSD
> installer so I presume TRIM is enabled. Without a reliable way to
> reproduce the error I'm not sure disabling TRIM will help at the moment.
>
> I don't think there's any newer firmware for it.
>

pci gen 4 has a highter error rate so that needs to be managed with
retries.  There's a whole protocol to do that which linux implements. I
suspect the time has come for us to do so too. There's some code floating
around I'll have to track down.

Warner

-- 
>
> Rebecca Cran
>
>
> On 6/8/23 04:25, Tomek CEDRO wrote:
> > what filesystem? is TRIM enabled on that drive? have you tried
> > disabling trim? i had similar ssd related problem on samsung's ssd
> > long time ago that was related to trim. maybe drive firmware can be
> > updated too? :-)
> >
> > --
> > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>
>

Re: Seemingly random nvme (nda) write error on new drive (retries exhausted)

2023-06-08 Thread Rebecca Cran

It's ZFS, using the default options when creating it via the FreeBSD 
installer so I presume TRIM is enabled. Without a reliable way to 
reproduce the error I'm not sure disabling TRIM will help at the moment.


I don't think there's any newer firmware for it.


--

Rebecca Cran


On 6/8/23 04:25, Tomek CEDRO wrote:
what filesystem? is TRIM enabled on that drive? have you tried 
disabling trim? i had similar ssd related problem on samsung's ssd 
long time ago that was related to trim. maybe drive firmware can be 
updated too? :-)


--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: Seemingly random nvme (nda) write error on new drive (retries exhausted)

2023-06-08 Thread Tomek CEDRO

what filesystem? is TRIM enabled on that drive? have you tried disabling
trim? i had similar ssd related problem on samsung's ssd long time ago that
was related to trim. maybe drive firmware can be updated too? :-)

--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: Seemingly random nvme (nda) write error on new drive (retries exhausted)

2023-06-08 Thread Rebecca Cran


On 6/8/23 00:24, Warner Losh wrote:

PCIe 3 or PCIe 4?


PCIe 4.


nda0 at nvme0 bus 0 scbus0 target 0 lun 1
nda0: 
nda0: Serial Number S55KNC0TC00168
nda0: nvme version 1.3 x8 (max x8) lanes PCIe Gen4 (max Gen4) link
nda0: 6104710MB (12502446768 512 byte sectors)

--

Rebecca Cran

Re: Seemingly random nvme (nda) write error on new drive (retries exhausted)

2023-06-07 Thread Warner Losh

On Wed, Jun 7, 2023 at 11:12 PM Rebecca Cran  wrote:

> I got a seemingly random nvme data transfer error on my new arm64 Ampere
> Altra machine, which has a Samsung PM1735 PCIe AIC NVMe drive.
>
> Since it's a new drive and smartctl doesn't show any errors I thought it
> might be worth mentioning here.
>
> I'm running 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n263139-baef3a5b585f.
>
>
> dmesg contains:
>
> nvme0: WRITE sqid:16 cid:126 nsid:1 lba:2550684560 len:8
> nvme0: DATA TRANSFER ERROR (00/04) crd:0 m:0 dnr:0 sqid:16 cid:126 cdw0:0
> (nda0:nvme0:0:0:1): WRITE. NCB: opc=1 fuse=0 nsid=1 prp1=0 prp2=0
> cdw=98085b90 0 7 0 0 0
> (nda0:nvme0:0:0:1): CAM status: CCB request completed with an error
> (nda0:nvme0:0:0:1): Error 5, Retries exhausted
>
>
> nvmecontrol identify nvme0 shows:
>
> Vendor ID:   144d
> Subsystem Vendor ID: 144d
> Model Number:SAMSUNG MZPLJ6T4HALA-7
> Firmware Version:EPK9CB5Q
> Recommended Arb Burst:   8
> IEEE OUI Identifier: 00 25 38
> Multi-Path I/O Capabilities: Multiple controllers, Multiple ports
> Max Data Transfer Size:  131072 bytes
> Sanitize Crypto Erase:   Supported
> Sanitize Block Erase:Supported
> Sanitize Overwrite:  Not Supported
> Sanitize NDI:Not Supported
> Sanitize NODMMAS:Undefined
> Controller ID:   0x0041
> Version: 1.3.0
>

PCIe 3 or PCIe 4?

So the only documented reason for this error is if we setup the memory wrong
such that the drive couldn't start a transfer from the specified address.
This seems
weird to me... But in the prior paragraph it talks about other types of
aborts that
need software intervention. If this is a transient error, then  maybe we
should retry
it as part of the data recovery. Unless this do not retry bit is set. which
it isn't. I wonder
this is retried 5 times or not before generating the error...

Warner

Seemingly random nvme (nda) write error on new drive (retries exhausted)

2023-06-07 Thread Rebecca Cran

I got a seemingly random nvme data transfer error on my new arm64 Ampere 
Altra machine, which has a Samsung PM1735 PCIe AIC NVMe drive.


Since it's a new drive and smartctl doesn't show any errors I thought it 
might be worth mentioning here.


I'm running 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n263139-baef3a5b585f.


dmesg contains:

nvme0: WRITE sqid:16 cid:126 nsid:1 lba:2550684560 len:8
nvme0: DATA TRANSFER ERROR (00/04) crd:0 m:0 dnr:0 sqid:16 cid:126 cdw0:0
(nda0:nvme0:0:0:1): WRITE. NCB: opc=1 fuse=0 nsid=1 prp1=0 prp2=0 
cdw=98085b90 0 7 0 0 0

(nda0:nvme0:0:0:1): CAM status: CCB request completed with an error
(nda0:nvme0:0:0:1): Error 5, Retries exhausted


nvmecontrol identify nvme0 shows:

Vendor ID:   144d
Subsystem Vendor ID: 144d
Model Number:    SAMSUNG MZPLJ6T4HALA-7
Firmware Version:    EPK9CB5Q
Recommended Arb Burst:   8
IEEE OUI Identifier: 00 25 38
Multi-Path I/O Capabilities: Multiple controllers, Multiple ports
Max Data Transfer Size:  131072 bytes
Sanitize Crypto Erase:   Supported
Sanitize Block Erase:    Supported
Sanitize Overwrite:  Not Supported
Sanitize NDI:    Not Supported
Sanitize NODMMAS:    Undefined
Controller ID:   0x0041
Version: 1.3.0


--

Rebecca Cran

Re: photo/video on tty console with the new VT/framebuffer

2023-05-20 Thread Jan Beich

Alastair Hogge  writes:

> On 2023-05-19 11:04, Ivan Quitschal wrote:
>
>> Hi all
>> 
>> i have a question. searched everywhere and found nothing about.
>> 
>> Is it possible to visualize photos on tty console like we used to on old 
>> SYSCONS by using zgv or something?

See https://github.com/mpv-player/mpv/issues/7983

>> Or watching videos with mpv/mplayer + sdl 2.0/openGL or something?
>
> As long as those packages support DRMKMS and does your GPU, you can to a
> degree. I noticed video works for mpv and games/sdl, tho, I cannot get
> input working. I tried the Doom 3 port, and watched movies with mpv all
> from the vty just a couple of months ago.

mpv doesn't call KDSKBMODE ioctl, so input remains under VT control but
not visible due to video showing on top. One can still control mpv via
stdin(4) using a keyboard but keybindings would be limited by termios(4).
For example, Ctrl+S would pause playback after a few seconds instead of
taking a screenshot.

SDL2 probably has a bug. SDL1 uses vgl(3) instead of KDSKBMODE directly.

Re: photo/video on tty console with the new VT/framebuffer







Btw. freebsd-questions list is better place for this kind of
questions. freebsd-current is specific for CURRENT branch development
related discussions :-)



that was precisely my question, if it is possible to do *on current* at all. 
because as i pointed out, i havent found almost anyone saying it does on my 
searches.


what i know is that it works with the linux framebuffer sdl directfb. thats it

example, mpv on ports doesnt even seem to have sdl support, neither sdl from 
ports support to drm.


thanks

--tzk

Re: photo/video on tty console with the new VT/framebuffer





On Fri, 19 May 2023, Alastair Hogge wrote:


On 2023-05-19 12:51, Ivan Quitschal wrote:

hi Alastair


Hey Ivan,


could you please tell us how did you do to make mpv working ?

when i try to run it, i get something like this:

$ mpv --vo=drm video.mp4
 (+) Video --vid=1 (*) (h264 424x240 30.000fps)
 (+) Audio --aid=1 (*) (aac 2ch 44100Hz)
[vo/drm] No primary DRM device could be picked!
[vo/drm] Failed to find a usable DRM primary node!
[vo/drm] Failed to create KMS.
Error opening/initializing the selected video_out (--vo) device.
Video: no video

Exiting... (Errors when loading file)


thats what i should use correct ? --vo=drm ?


What video card are you using? Have you loaded the kernel driver for it?

To health and anarchy,
Alastair



yes i do. intel hd graphics

 71 0x82f26000   19c948 i915kms.ko

drm.ko is already loaded on the kernel


thats the reason of my question, if bsd can do it to begin with. the zgv app 
that i mentioned for example. the closest thing i found for current vt newcons 
is /usr/ports/graphics/viu (which is not what im after of course)


thanks

--tzk

Re: photo/video on tty console with the new VT/framebuffer

2023-05-19 Thread Alastair Hogge

On 2023-05-19 12:51, Ivan Quitschal wrote:
> hi Alastair

Hey Ivan,
 
> could you please tell us how did you do to make mpv working ?
> 
> when i try to run it, i get something like this:
> 
> $ mpv --vo=drm video.mp4
>  (+) Video --vid=1 (*) (h264 424x240 30.000fps)
>  (+) Audio --aid=1 (*) (aac 2ch 44100Hz)
> [vo/drm] No primary DRM device could be picked!
> [vo/drm] Failed to find a usable DRM primary node!
> [vo/drm] Failed to create KMS.
> Error opening/initializing the selected video_out (--vo) device.
> Video: no video
> 
> Exiting... (Errors when loading file)
> 
> 
> thats what i should use correct ? --vo=drm ?

What video card are you using? Have you loaded the kernel driver for it?

To health and anarchy,
Alastair

Re: photo/video on tty console with the new VT/framebuffer

On Fri, May 19, 2023 at 2:51 PM Ivan Quitschal wrote:
> could you please tell us how did you do to make mpv working ?
>
> when i try to run it, i get something like this:
> $ mpv --vo=drm video.mp4
>   (+) Video --vid=1 (*) (h264 424x240 30.000fps)
>   (+) Audio --aid=1 (*) (aac 2ch 44100Hz)
> [vo/drm] No primary DRM device could be picked!
> [vo/drm] Failed to find a usable DRM primary node!
> [vo/drm] Failed to create KMS.
> Error opening/initializing the selected video_out (--vo) device.
> Video: no video

I have it working just with mpv file. Do you have drm kernel module installed?

Btw. freebsd-questions list is better place for this kind of
questions. freebsd-current is specific for CURRENT branch development
related discussions :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: photo/video on tty console with the new VT/framebuffer




On Fri, 19 May 2023, Alastair Hogge wrote:


On 2023-05-19 11:04, Ivan Quitschal wrote:

Hi all

i have a question. searched everywhere and found nothing about.

Is it possible to visualize photos on tty console like we used to on old 
SYSCONS by using zgv or something?

Or watching videos with mpv/mplayer + sdl 2.0/openGL or something?


As long as those packages support DRMKMS and does your GPU, you can to a
degree. I noticed video works for mpv and games/sdl, tho, I cannot get
input working. I tried the Doom 3 port, and watched movies with mpv all
from the vty just a couple of months ago.

To health and anarchy,
Alastair



hi Alastair

could you please tell us how did you do to make mpv working ?

when i try to run it, i get something like this:

$ mpv --vo=drm video.mp4
 (+) Video --vid=1 (*) (h264 424x240 30.000fps)
 (+) Audio --aid=1 (*) (aac 2ch 44100Hz)
[vo/drm] No primary DRM device could be picked!
[vo/drm] Failed to find a usable DRM primary node!
[vo/drm] Failed to create KMS.
Error opening/initializing the selected video_out (--vo) device.
Video: no video

Exiting... (Errors when loading file)


thats what i should use correct ? --vo=drm ?


thanks

--tzk

Re: photo/video on tty console with the new VT/framebuffer

On Fri, May 19, 2023 at 2:29 PM Yuri wrote:
> Tomek CEDRO wrote:
> > On Fri, May 19, 2023 at 1:44 PM Alastair Hogge wrote:
> >> On 2023-05-19 11:30, Tomek CEDRO wrote:
> >>> On Fri, May 19, 2023 at 1:28 PM Alastair Hogge wrote:
>  As long as those packages support DRMKMS and does your GPU, you can to a
>  degree. I noticed video works for mpv and games/sdl, tho, I cannot get
>  input working. I tried the Doom 3 port, and watched movies with mpv all
>  from the vty just a couple of months ago.
> >>>
> >>> Yeah, I have input problem too, maybe worth investigating as this is
> >>> really neat feature to have gfx with no Xorg :-)
> >>
> >> It is worth investigating! In a long dead ago project, the input,
> >> events, and displays were all integrated into the vty and mux'd from
> >> there. The kernel provides evdev devices now, and there is a library,
> >> tho I do not know how to get vt(4) to integrate with evdev, or if the
> >> library is the way to do it? Any other ideas?
> >
> > Hey there Niclas :-) Do you know how to enable input devices
> > (keyboard/mouse) in the console graphical applications? Is it
> > possible? :-)
> Wayland something?

We have graphical applications (i.e. SDL) working on a DRM KMS console
with no Xorg nor Wayland.. but no input.. looking for a solution :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: photo/video on tty console with the new VT/framebuffer

2023-05-19 Thread Yuri

Tomek CEDRO wrote:
> On Fri, May 19, 2023 at 1:44 PM Alastair Hogge wrote:
>> On 2023-05-19 11:30, Tomek CEDRO wrote:
>>> On Fri, May 19, 2023 at 1:28 PM Alastair Hogge wrote:
 As long as those packages support DRMKMS and does your GPU, you can to a
 degree. I noticed video works for mpv and games/sdl, tho, I cannot get
 input working. I tried the Doom 3 port, and watched movies with mpv all
 from the vty just a couple of months ago.
>>>
>>> Yeah, I have input problem too, maybe worth investigating as this is
>>> really neat feature to have gfx with no Xorg :-)
>>
>> It is worth investigating! In a long dead ago project, the input,
>> events, and displays were all integrated into the vty and mux'd from
>> there. The kernel provides evdev devices now, and there is a library,
>> tho I do not know how to get vt(4) to integrate with evdev, or if the
>> library is the way to do it? Any other ideas?
> 
> Hey there Niclas :-) Do you know how to enable input devices
> (keyboard/mouse) in the console graphical applications? Is it
> possible? :-)
Wayland something?

Re: photo/video on tty console with the new VT/framebuffer

On Fri, May 19, 2023 at 1:44 PM Alastair Hogge wrote:
> On 2023-05-19 11:30, Tomek CEDRO wrote:
> > On Fri, May 19, 2023 at 1:28 PM Alastair Hogge wrote:
> >> As long as those packages support DRMKMS and does your GPU, you can to a
> >> degree. I noticed video works for mpv and games/sdl, tho, I cannot get
> >> input working. I tried the Doom 3 port, and watched movies with mpv all
> >> from the vty just a couple of months ago.
> >
> > Yeah, I have input problem too, maybe worth investigating as this is
> > really neat feature to have gfx with no Xorg :-)
>
> It is worth investigating! In a long dead ago project, the input,
> events, and displays were all integrated into the vty and mux'd from
> there. The kernel provides evdev devices now, and there is a library,
> tho I do not know how to get vt(4) to integrate with evdev, or if the
> library is the way to do it? Any other ideas?

Hey there Niclas :-) Do you know how to enable input devices
(keyboard/mouse) in the console graphical applications? Is it
possible? :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: photo/video on tty console with the new VT/framebuffer

2023-05-19 Thread Alastair Hogge

On 2023-05-19 11:30, Tomek CEDRO wrote:
> On Fri, May 19, 2023 at 1:28 PM Alastair Hogge wrote:
>> As long as those packages support DRMKMS and does your GPU, you can to a
>> degree. I noticed video works for mpv and games/sdl, tho, I cannot get
>> input working. I tried the Doom 3 port, and watched movies with mpv all
>> from the vty just a couple of months ago.
> 
> Yeah, I have input problem too, maybe worth investigating as this is
> really neat feature to have gfx with no Xorg :-)

It is worth investigating! In a long dead ago project, the input,
events, and displays were all integrated into the vty and mux'd from
there. The kernel provides evdev devices now, and there is a library,
tho I do not know how to get vt(4) to integrate with evdev, or if the
library is the way to do it? Any other ideas?

Re: photo/video on tty console with the new VT/framebuffer

On Fri, May 19, 2023 at 1:28 PM Alastair Hogge wrote:
> As long as those packages support DRMKMS and does your GPU, you can to a
> degree. I noticed video works for mpv and games/sdl, tho, I cannot get
> input working. I tried the Doom 3 port, and watched movies with mpv all
> from the vty just a couple of months ago.

Yeah, I have input problem too, maybe worth investigating as this is
really neat feature to have gfx with no Xorg :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: photo/video on tty console with the new VT/framebuffer

2023-05-19 Thread Alastair Hogge

On 2023-05-19 11:04, Ivan Quitschal wrote:
> Hi all
> 
> i have a question. searched everywhere and found nothing about.
> 
> Is it possible to visualize photos on tty console like we used to on old 
> SYSCONS by using zgv or something?
> 
> Or watching videos with mpv/mplayer + sdl 2.0/openGL or something?

As long as those packages support DRMKMS and does your GPU, you can to a
degree. I noticed video works for mpv and games/sdl, tho, I cannot get
input working. I tried the Doom 3 port, and watched movies with mpv all
from the vty just a couple of months ago.

To health and anarchy,
Alastair

photo/video on tty console with the new VT/framebuffer


Hi all

i have a question. searched everywhere and found nothing about.

Is it possible to visualize photos on tty console like we used to on old 
SYSCONS by using zgv or something?

Or watching videos with mpv/mplayer + sdl 2.0/openGL or something?

Or seeing pictures on w3m-img like unix does ?


thanks all

--tzk

Re: RFC: A new NFS mount option to encourage use of Kerberized mounts

2023-03-14 Thread Rick Macklem

On Tue, Mar 14, 2023 at 11:53 AM Pete Wright  wrote:
>
> On Mon, Mar 13, 2023 at 07:25:07PM -0700, Rick Macklem wrote:
> > Hi,
> >
> > I have implemented a new mount option for NFSv4.1/4.2 mounts
> > that I hope will encourage use of Kerberos and TLS to help
> > secure NFS mounts.  Although I do not know why users choose
> > to not use Kerberized NFS mounts, I think that the administrative
> > issues related to the "machine credential" is a factor.
> > This new option, which I have called "syskrb5" (feel free to
> > suggest a better name), avoids the need for a Kerberos machine
> > credential.
> >
> 
> >
> > So, does this sound like something that should be committed
> > to FreeBSD?
> >
>
> speaking as an enduser..
>
> this sounds pretty fantastic, i have several workloads in public
> cloud that use NFS, and having this added layer of auth would be
> really beneficial from a security perspective.  i also like how
> it should be much easier for me to manage as well.
>
> one question - do you see other NFS implementations getting ready
> to roll out this support on their end?  i ask because it would be
> nice to have this client support working and well tested by the time
> other vendors start offering this support server side.  for example
> AWS EFS.
Well, there are three components:
1 - SP4_NONE, which is what the FreeBSD NFSv4.1/4.2 client
 always uses, so as far as I know, all the servers support it.
 (I have only been able to test against the FreeBSD and Linux
  knfsd at this point, so there may be surprises with other servers.)
2 - Kerberized NFSv4. It is required by the RFCs and is supported by
 at least most servers. I do not know if AWS EFS supports Kerberos?
3 - NFS-over-TLS (the RFC authors prefer RPC-with-TLS).  At this time,
 only the FreeBSD server and a userland server called DesyFS
 (and maybe Ganesha) have support. There are experimental patches
  for the Linux knfsd, but I do not know how close they are to being
  in a mainstream kernel.
  Other server verdors should be working on this, but I have no idea
  what their current status is.
#3 is not needed for this mount case, but it will be nice to have.
(And the above may not be accurate. It is just what I have observed.)

Thanks for your comments, rick

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

Re: RFC: A new NFS mount option to encourage use of Kerberized mounts

2023-03-14 Thread Pete Wright

On Mon, Mar 13, 2023 at 07:25:07PM -0700, Rick Macklem wrote:
> Hi,
> 
> I have implemented a new mount option for NFSv4.1/4.2 mounts
> that I hope will encourage use of Kerberos and TLS to help
> secure NFS mounts.  Although I do not know why users choose
> to not use Kerberized NFS mounts, I think that the administrative
> issues related to the "machine credential" is a factor.
> This new option, which I have called "syskrb5" (feel free to
> suggest a better name), avoids the need for a Kerberos machine
> credential.
> 

> 
> So, does this sound like something that should be committed
> to FreeBSD?
>

speaking as an enduser..

this sounds pretty fantastic, i have several workloads in public
cloud that use NFS, and having this added layer of auth would be
really beneficial from a security perspective.  i also like how
it should be much easier for me to manage as well.

one question - do you see other NFS implementations getting ready
to roll out this support on their end?  i ask because it would be
nice to have this client support working and well tested by the time
other vendors start offering this support server side.  for example
AWS EFS.

thanks!
-pete

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

RFC: A new NFS mount option to encourage use of Kerberized mounts

2023-03-13 Thread Rick Macklem

Hi,

I have implemented a new mount option for NFSv4.1/4.2 mounts
that I hope will encourage use of Kerberos and TLS to help
secure NFS mounts.  Although I do not know why users choose
to not use Kerberized NFS mounts, I think that the administrative
issues related to the "machine credential" is a factor.
This new option, which I have called "syskrb5" (feel free to
suggest a better name), avoids the need for a Kerberos machine
credential.

I discussed doing this type of mount on the IETF and Linux
nfs mailing lists and there seemed to be support for the
concept.

Without this patch, a Kerberized NFSv4.1/4.2 mount must provide
a Kerberos credential for the client at mount time.  This credential
is typically referred to as a "machine credential".  It can be
created one of two ways:
- The user (usually root) has a valid TGT at the time the mount
  is done and this becomes the machine credential.
  There are two problems with this.
  1 - The user doing the mount must have a valid TGT for a user
  principal at mount time.  As such, the mount cannot be put
  in fstab(5) or similar.
  2 - When the TGT expires, the mount breaks.
- The client machine has a service principal in its default keytab
  file and this service principal (typically called a host-based
  initiator credential) is used as the machine credential.
  There are problems with this approach as well:
  1 - There is a certain amount of administrative overhead creating
  the service principal for the NFS client, creating a keytab
  entry for this principal and then copying the keytab entry
  into the client's default keytab file via some secure means.
  2 - The NFS client must have a fixed, well known, DNS name, since
  that FQDN is in the service principal name as the instance.

This patch uses a feature of NFSv4.1/4.2 called SP4_NONE, which
allows the state maintenance operations to be performed by any
authentication mechanism, to do these operations via AUTH_SYS
instead of RPCSEC_GSS (Kerberos).  As such, neither of the above
mechanisms is needed.

This new NFSv4.1/4.2 mount option, called "syskrb5" must be used
with "sec=krb5[ip]" to avoid the need for either of the above
Kerberos setups to be done by the client.

Note that all file access/modification operations still require
users on the NFS client to have a valid TGT recognized by the
NFSv4.1/4.2 server.  As such, this option allows, at most, a
malicious client to do some sort of DOS attack.

Although not required, use of "tls" with this new option is
encouraged, since it provides on-the-wire encryption plus,
optionally, client identity verification via a X.509
certificate provided to the server during TLS handshake.
Alternately, "sec=krb5p" does provide on-the-wire
encryption of file data.

So, does this sound like something that should be committed
to FreeBSD?

Thanks for any comments, rick

Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot

2023-02-25 Thread Mike Karels

On 25 Feb 2023, at 11:02, bob prohaska wrote:

> On Sat, Feb 25, 2023 at 10:33:23AM -0600, Mike Karels wrote:
>> On 25 Feb 2023, at 10:16, bob prohaska wrote:
>>
>>> On Sat, Feb 25, 2023 at 12:21:09AM +0100, Ronald Klop wrote:
>>>>
>>>> UFS stores the current timestamp in the superblock of the FS on clean
>>>> shutdown/unmount. On boot it reads the time from the timestamp in the
>>>> superblock of the root FS. Of coarse this timestamp is behind for the
>>>> duration that the machine was off or rebooting so you need to adjust that
>>>> using ntp. For ZFS root you can use the fakertc port to do something
>>>> similar.
>>>>
>>>>
>>> Mark Millard points out:
>>>  /etc/localtimeCurrent zoneinfo file, see tzsetup(8) and zic(8).
>>>
>>>  /etc/wall_cmos_clock  Empty file.  Its presence indicates that the
>>>machine's CMOS clock is set to local time, while
>>>its absence indicates a UTC CMOS clock.
>>>
>>> Since there is no /etc/wall_cmos_clock on the newly-installed filesystem
>>> it appears the superblock timestamp is then interpreted as UTC when a Pi
>>> boots, using whatever happens to be set in /etc/localtime. My confusion
>>> is reduced somewhat. On first boot, what is the state of /etc/localtime?
>>>
>>> I've neglected to run tzsetup immediately on many previous installations
>>> and not noticed any complaints about mis-set clocks in buildworld. Is this
>>> new behavior?
>>
>> /etc/localtime is used in formatting dates (e.g. for ls), but is not
>> involved in storage of timestamps.  Timestamps on files, system time, etc,
>> are all in UTC.  So the system should act normally if there is no
>> /etc/localtime, and after one is added.
>
> Does formatting include calculating offsets from UTC for display?

Yes, I was referring to the process of converting from a binary timestamp
in seconds since the epoch to a string with day/month/year/hour/minute etc
in the local timezone.

> On at least a couple of installs I've observed date reporting UTC time.
> After running tzsetup, set to PST, date then reported the same numerical
> time with a PST time zone. This happened very early in an installation
> lifecycle and seemed to just "go away" after a few reboots, though I
> never paid close attention since it caused no complaints.

I have never seen such a thing.  On the contrary, I have noticed files with
timestamps that seemed to be in the future, then realized that they were in
UTC; I set the timezone, and then they appeared to have recent times.  I’d
expect similar behavior from date unless the -u flag was used or the
timezone was different in the environment.

Mike

Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot

2023-02-25 Thread bob prohaska

On Sat, Feb 25, 2023 at 10:33:23AM -0600, Mike Karels wrote:
> On 25 Feb 2023, at 10:16, bob prohaska wrote:
> 
> > On Sat, Feb 25, 2023 at 12:21:09AM +0100, Ronald Klop wrote:
> >>
> >> UFS stores the current timestamp in the superblock of the FS on clean
> >> shutdown/unmount. On boot it reads the time from the timestamp in the
> >> superblock of the root FS. Of coarse this timestamp is behind for the
> >> duration that the machine was off or rebooting so you need to adjust that
> >> using ntp. For ZFS root you can use the fakertc port to do something
> >> similar.
> >>
> >>
> > Mark Millard points out:
> >  /etc/localtimeCurrent zoneinfo file, see tzsetup(8) and zic(8).
> >
> >  /etc/wall_cmos_clock  Empty file.  Its presence indicates that the
> >machine's CMOS clock is set to local time, while
> >its absence indicates a UTC CMOS clock.
> >
> > Since there is no /etc/wall_cmos_clock on the newly-installed filesystem
> > it appears the superblock timestamp is then interpreted as UTC when a Pi
> > boots, using whatever happens to be set in /etc/localtime. My confusion
> > is reduced somewhat. On first boot, what is the state of /etc/localtime?
> >
> > I've neglected to run tzsetup immediately on many previous installations
> > and not noticed any complaints about mis-set clocks in buildworld. Is this
> > new behavior?
> 
> /etc/localtime is used in formatting dates (e.g. for ls), but is not
> involved in storage of timestamps.  Timestamps on files, system time, etc,
> are all in UTC.  So the system should act normally if there is no
> /etc/localtime, and after one is added.

Does formatting include calculating offsets from UTC for display?

On at least a couple of installs I've observed date reporting UTC time. 
After running tzsetup, set to PST, date then reported the same numerical
time with a PST time zone. This happened very early in an installation
lifecycle and seemed to just "go away" after a few reboots, though I
never paid close attention since it caused no complaints.

Thanks for replying!

bob prohaska

Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot

2023-02-25 Thread Mike Karels

On 25 Feb 2023, at 10:16, bob prohaska wrote:

> On Sat, Feb 25, 2023 at 12:21:09AM +0100, Ronald Klop wrote:
>>
>> UFS stores the current timestamp in the superblock of the FS on clean
>> shutdown/unmount. On boot it reads the time from the timestamp in the
>> superblock of the root FS. Of coarse this timestamp is behind for the
>> duration that the machine was off or rebooting so you need to adjust that
>> using ntp. For ZFS root you can use the fakertc port to do something
>> similar.
>>
>>
> Mark Millard points out:
>  /etc/localtimeCurrent zoneinfo file, see tzsetup(8) and zic(8).
>
>  /etc/wall_cmos_clock  Empty file.  Its presence indicates that the
>machine's CMOS clock is set to local time, while
>its absence indicates a UTC CMOS clock.
>
> Since there is no /etc/wall_cmos_clock on the newly-installed filesystem
> it appears the superblock timestamp is then interpreted as UTC when a Pi
> boots, using whatever happens to be set in /etc/localtime. My confusion
> is reduced somewhat. On first boot, what is the state of /etc/localtime?
>
> I've neglected to run tzsetup immediately on many previous installations
> and not noticed any complaints about mis-set clocks in buildworld. Is this
> new behavior?

/etc/localtime is used in formatting dates (e.g. for ls), but is not
involved in storage of timestamps.  Timestamps on files, system time, etc,
are all in UTC.  So the system should act normally if there is no
/etc/localtime, and after one is added.

Mike

> Thanks to both Mark and Ronald!
>
> bob prohaska

Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot

2023-02-25 Thread bob prohaska

On Sat, Feb 25, 2023 at 12:21:09AM +0100, Ronald Klop wrote:
> 
> UFS stores the current timestamp in the superblock of the FS on clean
> shutdown/unmount. On boot it reads the time from the timestamp in the
> superblock of the root FS. Of coarse this timestamp is behind for the
> duration that the machine was off or rebooting so you need to adjust that
> using ntp. For ZFS root you can use the fakertc port to do something
> similar.
> 
> 
Mark Millard points out:
 /etc/localtimeCurrent zoneinfo file, see tzsetup(8) and zic(8).

 /etc/wall_cmos_clock  Empty file.  Its presence indicates that the
   machine's CMOS clock is set to local time, while
   its absence indicates a UTC CMOS clock.

Since there is no /etc/wall_cmos_clock on the newly-installed filesystem
it appears the superblock timestamp is then interpreted as UTC when a Pi
boots, using whatever happens to be set in /etc/localtime. My confusion
is reduced somewhat. On first boot, what is the state of /etc/localtime?

I've neglected to run tzsetup immediately on many previous installations
and not noticed any complaints about mis-set clocks in buildworld. Is this
new behavior?

Thanks to both Mark and Ronald!

bob prohaska

Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot

2023-02-24 Thread Ronald Klop

Van: bob prohaska
Datum: 24 februari 2023 22:05
Aan: freebsd-current@freebsd.org
CC: freebsd-...@freebsd.org
Onderwerp: Timekeeping problem in /usr/src on new RPI aarch64 snapshot

After installing
FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20230223-fe5c211ba873-261074.img

on a Pi3 and setting up the hard disk to use separate swap and /usr partitions
an oddity came to light regarding dates.

The image file was written to disk the night of the 23rd, from a Pi3 with
a correctly-set time and date. It was left idle overnight, configured the
morning of the 24th and booted without issue. It then cloned -current into
/usr/src, at which point the time was noticed to be wrong, apparently fast.

It turned out ntpdate wasn't running, so it was started and then tzsetup
run. After a reboot the time reported correctly.

However, make buildworld in /usr/src triggers an exhortation to "check
your time" and refuses run further.

running date on the system reports
Fri Feb 24 12:49:41 PST 2023
but ls -l /usr/src reports time around
Feb 24 19:10

an obvious inconsistency.

Presumably just waiting until the system clock catches

up with the /usr/src timestamps will fix the error. Is
there a better method?

Still, the date and time handling don't seem quite right.
In at least one earlier instance it appeared that tzsetup
altered the reported timeszone without shifting the time

stamp by the UTC/PDT offset. I always thought timestamps
were internally in UTC+timezone, displayed with the right
offset. It looks to a casual observer like something else
is going on.

An earlier fiasco (on this same Pi3) included wildly wrong
timestamps in a filesystem. The Pi3 has no hardware clock,
how does it set time when booted without a reference?

Thanks for reading,

bob prohaska

UFS stores the current timestamp in the superblock of the FS on clean shutdown/unmount. On boot it reads the time from the timestamp in the superblock of the root FS. Of coarse this timestamp is behind for the duration that the machine was off or rebooting so you need to adjust that using ntp.
For ZFS root you can use the fakertc port to do something similar.

You can use the command “touch“ to manipulate the time of your /usr/src dir.

Regards,
Ronald

Re: Timekeeping problem in /usr/src on new RPI aarch64 snapshot

2023-02-24 Thread Mark Millard

On Feb 24, 2023, at 13:05, bob prohaska  wrote:

> After installing 
> FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20230223-fe5c211ba873-261074.img
> on a Pi3 and setting up the hard disk to use separate swap and /usr partitions
> an oddity came to light regarding dates.
> 
> The image file was written to disk the night of the 23rd, from a Pi3 with
> a correctly-set time and date. It was left idle overnight, configured the
> morning of the 24th and booted without issue. It then cloned -current into
> /usr/src, at which point the time was noticed to be wrong, apparently fast.
> 
> It turned out ntpdate wasn't running, so it was started and then tzsetup
> run. After a reboot the time reported correctly. 
> 
> However, make buildworld in /usr/src triggers an exhortation to "check
> your time" and refuses run further. 
> 
> running date on the system reports
> Fri Feb 24 12:49:41 PST 2023
> but ls -l /usr/src reports time around 
> Feb 24 19:10
> an obvious inconsistency.
> 
> Presumably just waiting until the system clock catches
> up with the /usr/src timestamps will fix the error. Is
> there a better method?
> 
> Still, the date and time handling don't seem quite right. 
> In at least one earlier instance it appeared that tzsetup 
> altered the reported timeszone without shifting the time
> stamp by the UTC/PDT offset. I always thought timestamps
> were internally in UTC+timezone, displayed with the right
> offset. It looks to a casual observer like something else
> is going on. 
> 
> An earlier fiasco (on this same Pi3) included wildly wrong
> timestamps in a filesystem. The Pi3 has no hardware clock,
> how does it set time when booted without a reference?

There are 2 files involved:

 /etc/localtimeCurrent zoneinfo file, see tzsetup(8) and zic(8).

 /etc/wall_cmos_clock  Empty file.  Its presence indicates that the
   machine's CMOS clock is set to local time, while
   its absence indicates a UTC CMOS clock.

An oddity here is that there is no existing
CMOS clock but the /etc/wall_cmos_clock
status still has consequences, as I remember.

Various related man pages are:

adjkerntz(8)
tzseteup(8)
zic(8)

From an RPi4B:

# ls -Tld /etc/wall_cmos_clock
ls: /etc/wall_cmos_clock: No such file or directory
# sysctl machdep.wall_cmos_clock
machdep.wall_cmos_clock: 0

(So: As if a CMOS clock was using UTC time.)


# strings /etc/localtime | tail -1
PST8PDT,M3.2.0,M11.1.0

# sysctl machdep.adjkerntz
machdep.adjkerntz: 0

# date
Fri Feb 24 13:42:52 PST 2023

(Matching the local time.)

So, as configured, /etc/localtime is used to
specify covert kernel UTC to local time as
needed: no addition non-zero offsets.

As I remember, things can be odd with file
systems from Windows variants and the time
stamps interpretation. Keeping such matching
vs. not can get into the choice of if
/etc/wall_cmos_clock is to exist or not.

It can be a seprate issue if time tracking
is off rate or some such.

===
Mark Millard
marklmi at yahoo.com

Timekeeping problem in /usr/src on new RPI aarch64 snapshot

2023-02-24 Thread bob prohaska

After installing 
FreeBSD-14.0-CURRENT-arm64-aarch64-RPI-20230223-fe5c211ba873-261074.img
on a Pi3 and setting up the hard disk to use separate swap and /usr partitions
an oddity came to light regarding dates.

The image file was written to disk the night of the 23rd, from a Pi3 with
a correctly-set time and date. It was left idle overnight, configured the
morning of the 24th and booted without issue. It then cloned -current into
/usr/src, at which point the time was noticed to be wrong, apparently fast.

It turned out ntpdate wasn't running, so it was started and then tzsetup
run. After a reboot the time reported correctly. 

However, make buildworld in /usr/src triggers an exhortation to "check
your time" and refuses run further. 

running date on the system reports
Fri Feb 24 12:49:41 PST 2023
but ls -l /usr/src reports time around 
Feb 24 19:10
an obvious inconsistency.
 
Presumably just waiting until the system clock catches
up with the /usr/src timestamps will fix the error. Is
there a better method?

Still, the date and time handling don't seem quite right. 
In at least one earlier instance it appeared that tzsetup 
altered the reported timeszone without shifting the time
stamp by the UTC/PDT offset. I always thought timestamps
were internally in UTC+timezone, displayed with the right
offset. It looks to a casual observer like something else
is going on. 

An earlier fiasco (on this same Pi3) included wildly wrong
timestamps in a filesystem. The Pi3 has no hardware clock,
how does it set time when booted without a reference?

Thanks for reading,

bob prohaska

Re: [RFC] Proposal adding new sorting algorithm, bsort() to libc

2022-09-08 Thread Hans Petter Selasky


On 9/8/22 12:50, Hans Petter Selasky wrote:

See:
https://reviews.freebsd.org/D36493

Looking through base I see qsort() being used in places it shouldn't be 
used. For example in fts_open().


If for example you fill a directory with 64k simply numerical file names 
in the wrong order and ask fts_open() to sort these ascending for 
example, qsort() will end stuck for a long-long time. So either switch 
to mergesort, or if malloc() is unacceptable, use something like bsort() 
which I've implemented in the above review as a drop-in replacement for 
qsort(). The advantage with bsort() is that in can be CPU accelerated, 
due to fixed comparison patterns.


Quick sort is not always a quick sorting algorithm. Quick means simple, 
and not clever this time.


For the qsort's bad pattern, sorting 4096 entries 1024 times in a row took:

qsort: 15 seconds
bsort: 230 milliseconds (non-CPU accelerated)
mergesort: 30 milliseconds

The problem with qsort() is that as the array size grows, the time 
consumption just gets worse and worse for the bad-patterns.


Sorry there is no nice and fancy paper yet about this.

--HPS



Hi,

Also see the "kill_ls.c" test program I attached to D36493, which shows 
the direct affect of qsort() on the regular "ls" command!


--HPS

[RFC] Proposal adding new sorting algorithm, bsort() to libc

2022-09-08 Thread Hans Petter Selasky


See:
https://reviews.freebsd.org/D36493

Looking through base I see qsort() being used in places it shouldn't be 
used. For example in fts_open().


If for example you fill a directory with 64k simply numerical file names 
in the wrong order and ask fts_open() to sort these ascending for 
example, qsort() will end stuck for a long-long time. So either switch 
to mergesort, or if malloc() is unacceptable, use something like bsort() 
which I've implemented in the above review as a drop-in replacement for 
qsort(). The advantage with bsort() is that in can be CPU accelerated, 
due to fixed comparison patterns.


Quick sort is not always a quick sorting algorithm. Quick means simple, 
and not clever this time.


For the qsort's bad pattern, sorting 4096 entries 1024 times in a row took:

qsort: 15 seconds
bsort: 230 milliseconds (non-CPU accelerated)
mergesort: 30 milliseconds

The problem with qsort() is that as the array size grows, the time 
consumption just gets worse and worse for the bad-patterns.


Sorry there is no nice and fancy paper yet about this.

--HPS

Re: New panic in main-n253273-a52d8d4a6c6:

2022-02-22 Thread Rob Wing

Hey Mike,

Should be fixed in commit 0a2f498234023008d9a3b13ad7fc8fd81d384bab
<https://cgit.freebsd.org/src/commit/?id=0a2f498234023008d9a3b13ad7fc8fd81d384bab>

Thanks for the report

-Rob

On Mon, Feb 21, 2022 at 7:48 PM Rob Wing  wrote:

> Think that's it...thanks for testing for the patch.
>
> I opened up https://reviews.freebsd.org/D34335 for review.
>
> -Rob
>
> On Mon, Feb 21, 2022 at 6:05 PM Michael Jung <
> mi...@paymentallianceintl.com> wrote:
>
>> Rob:
>>
>>
>>
>> I did not remove Hans earlier patch, but your “latest” patch applied and
>> compiled with no errors.
>>
>>
>>
>> I can now watch and control a TTY (v0) or a SSH session (pts/1) without
>> crashing.
>>
>>
>>
>> Anything else you would like me to try?
>>
>>
>>
>> --mikej
>>
>>
>>
>>
>>
>> *From:* Rob Wing [mailto:rob.fx...@gmail.com]
>> *Sent:* Monday, February 21, 2022 9:30 PM
>> *To:* Michael Jung 
>> *Cc:* Hans Petter Selasky ; freebsd-current <
>> freebsd-current@freebsd.org>
>> *Subject:* Re: New panic in main-n253273-a52d8d4a6c6:
>>
>>
>>
>> The previous attached patch should work for testing purposes, but it's
>> incorrect if an error occurs.
>>
>>
>>
>> The fhold() should be below FILEDESC_SUNLOCK(), this patch addresses that.
>>
>>
>>
>> On Mon, Feb 21, 2022 at 5:18 PM Rob Wing  wrote:
>>
>> try the attached patch
>>
>>
>>
>> On Mon, Feb 21, 2022 at 5:14 PM Michael Jung <
>> mi...@paymentallianceintl.com> wrote:
>>
>>
>>
>>
>>
>>
>>
>> CONFIDENTIALITY NOTE: This message is intended only for the use
>> of the individual or entity to whom it is addressed and may
>> contain information that is privileged, confidential, and
>> exempt from disclosure under applicable law. If the reader
>> of this message is not the intended recipient, you are hereby
>> notified that any dissemination, distribution or copying
>> of this communication is strictly prohibited. If you have
>> received this transmission in error, please notify us by
>> telephone at (502) 212-4000 or notify us at: PAI, Dept. 99,
>> 2101 High Wickham Place, Suite 101, Louisville, KY 40245
>>
>>
>> *From:* Michael Jung
>> *Sent:* Monday, February 21, 2022 9:06 PM
>> *To:* 'Hans Petter Selasky' ; freebsd-current <
>> freebsd-current@freebsd.org>
>> *Subject:* RE: New panic in main-n253273-a52d8d4a6c6:
>>
>>
>>
>> *From:* Hans Petter Selasky [mailto:h...@selasky.org ]
>> *Sent:* Monday, February 21, 2022 8:34 PM
>> *To:* Michael Jung ; freebsd-current <
>> freebsd-current@freebsd.org>
>> *Subject:* Re: New panic in main-n253273-a52d8d4a6c6:
>>
>>
>>
>> On 2/22/22 00:42, Michael Jung wrote:
>> > Hi:
>> >
>> > I was trying to remember what I did that was odd when this crash
>> occurred then it
>> > hit me. You can repeat this panic by doing:
>> >
>> > # watch -I -W pts/0
>> >
>> > Here is another panic that happened write after issuing "watch" for
>> comparison.
>> >
>> > http://mail.mikej.com/core.txt.1
>> >
>> > http://mail.mikej.com/info.1
>> >
>> > http://mail.mikej.com/vmcore.1
>> >
>>
>> I also need your kernel and debug kernel to fully debug this.
>>
>> 1) Do ssh to machine.
>> 2) watch -i -W pts/0 (does not panic over here)
>>
>> Can you explain what step 1 is? An scp ?
>>
>> Refcount is -1.
>> f_count = 0x
>>
>> f_data = 0xf800158b0400
>>
>> In your KGDB, can you enter:
>>
>> info 0x81b052d0
>>
>> Does the attached patch make any difference?
>>
>> --HPS
>>
>>
>>
>>
>>
>> So sorry, yes step one, ssh to machine….
>>
>>
>>
>> Even open a second console on the computer, no SSH and do “watch –I  -W
>> v0” it panics.
>>
>>
>>
>> Example of “watch –I –W v0” for comparison – kernel/kernel.full have not
>> changed since .2
>>
>>
>>
>> http://mail.mikej.com/core.txt.3
>>
>>
>>
>> http://mail.mikej.com/info.3
>>
>>
>>
>> http://mail.mikej.com/vmcore.3
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Disclaimer*
>>
>> The information contained in this communication from the send

Re: New panic in main-n253273-a52d8d4a6c6:

Think that's it...thanks for testing for the patch.

I opened up https://reviews.freebsd.org/D34335 for review.

-Rob

On Mon, Feb 21, 2022 at 6:05 PM Michael Jung 
wrote:

> Rob:
>
>
>
> I did not remove Hans earlier patch, but your “latest” patch applied and
> compiled with no errors.
>
>
>
> I can now watch and control a TTY (v0) or a SSH session (pts/1) without
> crashing.
>
>
>
> Anything else you would like me to try?
>
>
>
> --mikej
>
>
>
>
>
> *From:* Rob Wing [mailto:rob.fx...@gmail.com]
> *Sent:* Monday, February 21, 2022 9:30 PM
> *To:* Michael Jung 
> *Cc:* Hans Petter Selasky ; freebsd-current <
> freebsd-current@freebsd.org>
> *Subject:* Re: New panic in main-n253273-a52d8d4a6c6:
>
>
>
> The previous attached patch should work for testing purposes, but it's
> incorrect if an error occurs.
>
>
>
> The fhold() should be below FILEDESC_SUNLOCK(), this patch addresses that.
>
>
>
> On Mon, Feb 21, 2022 at 5:18 PM Rob Wing  wrote:
>
> try the attached patch
>
>
>
> On Mon, Feb 21, 2022 at 5:14 PM Michael Jung <
> mi...@paymentallianceintl.com> wrote:
>
>
>
>
>
>
>
> CONFIDENTIALITY NOTE: This message is intended only for the use
> of the individual or entity to whom it is addressed and may
> contain information that is privileged, confidential, and
> exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby
> notified that any dissemination, distribution or copying
> of this communication is strictly prohibited. If you have
> received this transmission in error, please notify us by
> telephone at (502) 212-4000 or notify us at: PAI, Dept. 99,
> 2101 High Wickham Place, Suite 101, Louisville, KY 40245
>
>
> *From:* Michael Jung
> *Sent:* Monday, February 21, 2022 9:06 PM
> *To:* 'Hans Petter Selasky' ; freebsd-current <
> freebsd-current@freebsd.org>
> *Subject:* RE: New panic in main-n253273-a52d8d4a6c6:
>
>
>
> *From:* Hans Petter Selasky [mailto:h...@selasky.org ]
> *Sent:* Monday, February 21, 2022 8:34 PM
> *To:* Michael Jung ; freebsd-current <
> freebsd-current@freebsd.org>
> *Subject:* Re: New panic in main-n253273-a52d8d4a6c6:
>
>
>
> On 2/22/22 00:42, Michael Jung wrote:
> > Hi:
> >
> > I was trying to remember what I did that was odd when this crash
> occurred then it
> > hit me. You can repeat this panic by doing:
> >
> > # watch -I -W pts/0
> >
> > Here is another panic that happened write after issuing "watch" for
> comparison.
> >
> > http://mail.mikej.com/core.txt.1
> >
> > http://mail.mikej.com/info.1
> >
> > http://mail.mikej.com/vmcore.1
> >
>
> I also need your kernel and debug kernel to fully debug this.
>
> 1) Do ssh to machine.
> 2) watch -i -W pts/0 (does not panic over here)
>
> Can you explain what step 1 is? An scp ?
>
> Refcount is -1.
> f_count = 0x
>
> f_data = 0xf800158b0400
>
> In your KGDB, can you enter:
>
> info 0x81b052d0
>
> Does the attached patch make any difference?
>
> --HPS
>
>
>
>
>
> So sorry, yes step one, ssh to machine….
>
>
>
> Even open a second console on the computer, no SSH and do “watch –I  -W
> v0” it panics.
>
>
>
> Example of “watch –I –W v0” for comparison – kernel/kernel.full have not
> changed since .2
>
>
>
> http://mail.mikej.com/core.txt.3
>
>
>
> http://mail.mikej.com/info.3
>
>
>
> http://mail.mikej.com/vmcore.3
>
>
>
>
>
>
>
>
>
> *Disclaimer*
>
> The information contained in this communication from the sender is
> confidential. It is intended solely for use by the recipient and others
> authorized to receive it. If you are not the recipient, you are hereby
> notified that any disclosure, copying, distribution or taking action in
> relation of the contents of this information is strictly prohibited and may
> be unlawful.
>
> This email has been scanned for viruses and malware, and may have been
> automatically archived by Mimecast, a leader in email security and cyber
> resilience. Mimecast integrates email defenses with brand protection,
> security awareness training, web security, compliance and other essential
> capabilities. Mimecast helps protect large and small organizations from
> malicious activity, human error and technology failure; and to lead the
> movement toward building a more resilient world. To find out more, visit
> our website.
>
>
>
> *Disclaimer*
>
> The information contained in t

RE: New panic in main-n253273-a52d8d4a6c6:

Rob:

I did not remove Hans earlier patch, but your “latest” patch applied and 
compiled with no errors.

I can now watch and control a TTY (v0) or a SSH session (pts/1) without 
crashing.

Anything else you would like me to try?

--mikej

From: Rob Wing [mailto:rob.fx...@gmail.com]
Sent: Monday, February 21, 2022 9:30 PM
To: Michael Jung 
Cc: Hans Petter Selasky ; freebsd-current 

Subject: Re: New panic in main-n253273-a52d8d4a6c6:

The previous attached patch should work for testing purposes, but it's 
incorrect if an error occurs.

The fhold() should be below FILEDESC_SUNLOCK(), this patch addresses that.

On Mon, Feb 21, 2022 at 5:18 PM Rob Wing 
mailto:rob.fx...@gmail.com>> wrote:
try the attached patch

On Mon, Feb 21, 2022 at 5:14 PM Michael Jung 
mailto:mi...@paymentallianceintl.com>> wrote:

CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at: PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245

From: Michael Jung
Sent: Monday, February 21, 2022 9:06 PM
To: 'Hans Petter Selasky' mailto:h...@selasky.org>>; 
freebsd-current 
mailto:freebsd-current@freebsd.org>>
Subject: RE: New panic in main-n253273-a52d8d4a6c6:

From: Hans Petter Selasky [mailto:h...@selasky.org]
Sent: Monday, February 21, 2022 8:34 PM
To: Michael Jung 
mailto:mi...@paymentallianceintl.com>>; 
freebsd-current 
mailto:freebsd-current@freebsd.org>>
Subject: Re: New panic in main-n253273-a52d8d4a6c6:

On 2/22/22 00:42, Michael Jung wrote:
> Hi:
>
> I was trying to remember what I did that was odd when this crash occurred 
> then it
> hit me. You can repeat this panic by doing:
>
> # watch -I -W pts/0
>
> Here is another panic that happened write after issuing "watch" for 
> comparison.
>
> http://mail.mikej.com/core.txt.1<http://mail.mikej.com/core.txt.1>
>
> http://mail.mikej.com/info.1<http://mail.mikej.com/info.1>
>
> http://mail.mikej.com/vmcore.1<http://mail.mikej.com/vmcore.1>
>

I also need your kernel and debug kernel to fully debug this.

1) Do ssh to machine.
2) watch -i -W pts/0 (does not panic over here)

Can you explain what step 1 is? An scp ?

Refcount is -1.
f_count = 0x

f_data = 0xf800158b0400

In your KGDB, can you enter:

info 0x81b052d0

Does the attached patch make any difference?

--HPS

So sorry, yes step one, ssh to machine….

Even open a second console on the computer, no SSH and do “watch –I  -W v0” it 
panics.

Example of “watch –I –W v0” for comparison – kernel/kernel.full have not 
changed since .2

http://mail.mikej.com/core.txt.3<http://mail.mikej.com/core.txt.3>

http://mail.mikej.com/info.3<http://mail.mikej.com/info.3>

http://mail.mikej.com/vmcore.3<http://mail.mikej.com/vmcore.3>

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast, a leader in email security and cyber 
resilience. Mimecast integrates email defenses with brand protection, security 
awareness training, web security, compliance and other essential capabilities. 
Mimecast helps protect large and small organizations from malicious activity, 
human error and technology failure; and to lead the movement toward building a 
more resilient world. To find out more, visit our website.

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast, a leader in email security and cyber 
resilience. Mimecast integrates email defenses with brand protection, security 
awareness training, web security, compliance and other essential capabilities. 
Mimecast helps protect large and small organizations from malicious activity, 
human error and technology failure; and to lead the movement toward building a 
more resilient world. To find out more, visit our website.

Re: New panic in main-n253273-a52d8d4a6c6:

The previous attached patch should work for testing purposes, but it's
incorrect if an error occurs.

The fhold() should be below FILEDESC_SUNLOCK(), this patch addresses that.

On Mon, Feb 21, 2022 at 5:18 PM Rob Wing  wrote:

> try the attached patch
>
> On Mon, Feb 21, 2022 at 5:14 PM Michael Jung <
> mi...@paymentallianceintl.com> wrote:
>
>>
>>
>>
>>
>>
>> CONFIDENTIALITY NOTE: This message is intended only for the use
>> of the individual or entity to whom it is addressed and may
>> contain information that is privileged, confidential, and
>> exempt from disclosure under applicable law. If the reader
>> of this message is not the intended recipient, you are hereby
>> notified that any dissemination, distribution or copying
>> of this communication is strictly prohibited. If you have
>> received this transmission in error, please notify us by
>> telephone at (502) 212-4000 or notify us at: PAI, Dept. 99,
>> 2101 High Wickham Place, Suite 101, Louisville, KY 40245
>>
>>
>>
>> *From:* Michael Jung
>> *Sent:* Monday, February 21, 2022 9:06 PM
>> *To:* 'Hans Petter Selasky' ; freebsd-current <
>> freebsd-current@freebsd.org>
>> *Subject:* RE: New panic in main-n253273-a52d8d4a6c6:
>>
>>
>>
>> *From:* Hans Petter Selasky [mailto:h...@selasky.org ]
>> *Sent:* Monday, February 21, 2022 8:34 PM
>> *To:* Michael Jung ; freebsd-current <
>> freebsd-current@freebsd.org>
>> *Subject:* Re: New panic in main-n253273-a52d8d4a6c6:
>>
>>
>>
>> On 2/22/22 00:42, Michael Jung wrote:
>> > Hi:
>> >
>> > I was trying to remember what I did that was odd when this crash
>> occurred then it
>> > hit me. You can repeat this panic by doing:
>> >
>> > # watch -I -W pts/0
>> >
>> > Here is another panic that happened write after issuing "watch" for
>> comparison.
>> >
>> > http://mail.mikej.com/core.txt.1
>> >
>> > http://mail.mikej.com/info.1
>> >
>> > http://mail.mikej.com/vmcore.1
>> >
>>
>> I also need your kernel and debug kernel to fully debug this.
>>
>> 1) Do ssh to machine.
>> 2) watch -i -W pts/0 (does not panic over here)
>>
>> Can you explain what step 1 is? An scp ?
>>
>> Refcount is -1.
>> f_count = 0x
>>
>> f_data = 0xf800158b0400
>>
>> In your KGDB, can you enter:
>>
>> info 0x81b052d0
>>
>> Does the attached patch make any difference?
>>
>> --HPS
>>
>>
>>
>>
>>
>> So sorry, yes step one, ssh to machine….
>>
>>
>>
>> Even open a second console on the computer, no SSH and do “watch –I  -W
>> v0” it panics.
>>
>>
>>
>> Example of “watch –I –W v0” for comparison – kernel/kernel.full have not
>> changed since .2
>>
>>
>>
>> http://mail.mikej.com/core.txt.3
>>
>>
>>
>> http://mail.mikej.com/info.3
>>
>>
>>
>> http://mail.mikej.com/vmcore.3
>>
>>
>>
>>
>>
>>
>>
>>
>> *Disclaimer*
>>
>> The information contained in this communication from the sender is
>> confidential. It is intended solely for use by the recipient and others
>> authorized to receive it. If you are not the recipient, you are hereby
>> notified that any disclosure, copying, distribution or taking action in
>> relation of the contents of this information is strictly prohibited and may
>> be unlawful.
>>
>> This email has been scanned for viruses and malware, and may have been
>> automatically archived by Mimecast, a leader in email security and cyber
>> resilience. Mimecast integrates email defenses with brand protection,
>> security awareness training, web security, compliance and other essential
>> capabilities. Mimecast helps protect large and small organizations from
>> malicious activity, human error and technology failure; and to lead the
>> movement toward building a more resilient world. To find out more, visit
>> our website.
>>
>
diff --git a/sys/kern/tty.c b/sys/kern/tty.c
index ebb32f698e88..2c60a7e42580 100644
--- a/sys/kern/tty.c
+++ b/sys/kern/tty.c
@@ -2086,6 +2086,8 @@ ttyhook_register(struct tty **rtp, struct proc *p, int fd, struct ttyhook *th,
 	FILEDESC_SUNLOCK(fdp);
 	if (error != 0)
 		return (error);
+	if (!fhold(fp))
+		return (EBADF);
 	if (fp->f_ops == &badfileops) {
 		error = EBADF;
 		goto done1;

Re: New panic in main-n253273-a52d8d4a6c6:

try the attached patch

On Mon, Feb 21, 2022 at 5:14 PM Michael Jung 
wrote:

>
>
>
>
>
> CONFIDENTIALITY NOTE: This message is intended only for the use
> of the individual or entity to whom it is addressed and may
> contain information that is privileged, confidential, and
> exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby
> notified that any dissemination, distribution or copying
> of this communication is strictly prohibited. If you have
> received this transmission in error, please notify us by
> telephone at (502) 212-4000 or notify us at: PAI, Dept. 99,
> 2101 High Wickham Place, Suite 101, Louisville, KY 40245
>
>
>
> *From:* Michael Jung
> *Sent:* Monday, February 21, 2022 9:06 PM
> *To:* 'Hans Petter Selasky' ; freebsd-current <
> freebsd-current@freebsd.org>
> *Subject:* RE: New panic in main-n253273-a52d8d4a6c6:
>
>
>
> *From:* Hans Petter Selasky [mailto:h...@selasky.org ]
> *Sent:* Monday, February 21, 2022 8:34 PM
> *To:* Michael Jung ; freebsd-current <
> freebsd-current@freebsd.org>
> *Subject:* Re: New panic in main-n253273-a52d8d4a6c6:
>
>
>
> On 2/22/22 00:42, Michael Jung wrote:
> > Hi:
> >
> > I was trying to remember what I did that was odd when this crash
> occurred then it
> > hit me. You can repeat this panic by doing:
> >
> > # watch -I -W pts/0
> >
> > Here is another panic that happened write after issuing "watch" for
> comparison.
> >
> > http://mail.mikej.com/core.txt.1
> >
> > http://mail.mikej.com/info.1
> >
> > http://mail.mikej.com/vmcore.1
> >
>
> I also need your kernel and debug kernel to fully debug this.
>
> 1) Do ssh to machine.
> 2) watch -i -W pts/0 (does not panic over here)
>
> Can you explain what step 1 is? An scp ?
>
> Refcount is -1.
> f_count = 0x
>
> f_data = 0xf800158b0400
>
> In your KGDB, can you enter:
>
> info 0x81b052d0
>
> Does the attached patch make any difference?
>
> --HPS
>
>
>
>
>
> So sorry, yes step one, ssh to machine….
>
>
>
> Even open a second console on the computer, no SSH and do “watch –I  -W
> v0” it panics.
>
>
>
> Example of “watch –I –W v0” for comparison – kernel/kernel.full have not
> changed since .2
>
>
>
> http://mail.mikej.com/core.txt.3
>
>
>
> http://mail.mikej.com/info.3
>
>
>
> http://mail.mikej.com/vmcore.3
>
>
>
>
>
>
>
>
> *Disclaimer*
>
> The information contained in this communication from the sender is
> confidential. It is intended solely for use by the recipient and others
> authorized to receive it. If you are not the recipient, you are hereby
> notified that any disclosure, copying, distribution or taking action in
> relation of the contents of this information is strictly prohibited and may
> be unlawful.
>
> This email has been scanned for viruses and malware, and may have been
> automatically archived by Mimecast, a leader in email security and cyber
> resilience. Mimecast integrates email defenses with brand protection,
> security awareness training, web security, compliance and other essential
> capabilities. Mimecast helps protect large and small organizations from
> malicious activity, human error and technology failure; and to lead the
> movement toward building a more resilient world. To find out more, visit
> our website.
>
diff --git a/sys/kern/tty.c b/sys/kern/tty.c
index ebb32f698e88..e98b2d10b810 100644
--- a/sys/kern/tty.c
+++ b/sys/kern/tty.c
@@ -2083,6 +2083,8 @@ ttyhook_register(struct tty **rtp, struct proc *p, int fd, struct ttyhook *th,
 	FILEDESC_SLOCK(fdp);
 	error = fget_cap_locked(fdp, fd, cap_rights_init_one(&rights, CAP_TTYHOOK),
 	&fp, NULL);
+	if (error == 0 && !fhold(fp))
+		return (EBADF);
 	FILEDESC_SUNLOCK(fdp);
 	if (error != 0)
 		return (error);

RE: New panic in main-n253273-a52d8d4a6c6:

CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at: PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245

From: Michael Jung
Sent: Monday, February 21, 2022 9:06 PM
To: 'Hans Petter Selasky' ; freebsd-current 

Subject: RE: New panic in main-n253273-a52d8d4a6c6:

From: Hans Petter Selasky [mailto:h...@selasky.org]
Sent: Monday, February 21, 2022 8:34 PM
To: Michael Jung 
mailto:mi...@paymentallianceintl.com>>; 
freebsd-current 
mailto:freebsd-current@freebsd.org>>
Subject: Re: New panic in main-n253273-a52d8d4a6c6:

On 2/22/22 00:42, Michael Jung wrote:
> Hi:
>
> I was trying to remember what I did that was odd when this crash occurred 
> then it
> hit me. You can repeat this panic by doing:
>
> # watch -I -W pts/0
>
> Here is another panic that happened write after issuing "watch" for 
> comparison.
>
> http://mail.mikej.com/core.txt.1<http://mail.mikej.com/core.txt.1>
>
> http://mail.mikej.com/info.1<http://mail.mikej.com/info.1>
>
> http://mail.mikej.com/vmcore.1<http://mail.mikej.com/vmcore.1>
>

I also need your kernel and debug kernel to fully debug this.

1) Do ssh to machine.
2) watch -i -W pts/0 (does not panic over here)

Can you explain what step 1 is? An scp ?

Refcount is -1.
f_count = 0x

f_data = 0xf800158b0400

In your KGDB, can you enter:

info 0x81b052d0

Does the attached patch make any difference?

--HPS

So sorry, yes step one, ssh to machine….

Even open a second console on the computer, no SSH and do “watch –I  -W v0” it 
panics.

Example of “watch –I –W v0” for comparison – kernel/kernel.full have not 
changed since .2

http://mail.mikej.com/core.txt.3

http://mail.mikej.com/info.3

http://mail.mikej.com/vmcore.3

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast, a leader in email security and cyber 
resilience. Mimecast integrates email defenses with brand protection, security 
awareness training, web security, compliance and other essential capabilities. 
Mimecast helps protect large and small organizations from malicious activity, 
human error and technology failure; and to lead the movement toward building a 
more resilient world. To find out more, visit our website.

RE: New panic in main-n253273-a52d8d4a6c6:

CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at: PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245

From: Hans Petter Selasky [mailto:h...@selasky.org]
Sent: Monday, February 21, 2022 8:34 PM
To: Michael Jung ; freebsd-current 

Subject: Re: New panic in main-n253273-a52d8d4a6c6:

On 2/22/22 00:42, Michael Jung wrote:
> Hi:
>
> I was trying to remember what I did that was odd when this crash occurred 
> then it
> hit me. You can repeat this panic by doing:
>
> # watch -I -W pts/0
>
> Here is another panic that happened write after issuing "watch" for 
> comparison.
>
> http://mail.mikej.com/core.txt.1<http://mail.mikej.com/core.txt.1>
>
> http://mail.mikej.com/info.1<http://mail.mikej.com/info.1>
>
> http://mail.mikej.com/vmcore.1<http://mail.mikej.com/vmcore.1>
>

I also need your kernel and debug kernel to fully debug this.

1) Do ssh to machine.
2) watch -i -W pts/0 (does not panic over here)

Can you explain what step 1 is? An scp ?

Refcount is -1.
f_count = 0x

f_data = 0xf800158b0400

In your KGDB, can you enter:

info 0x81b052d0

Does the attached patch make any difference?

--HPS

Patch made no difference, instant panic.

These are will the patch applied.

http://mail.mikej.com/vmcore.2

http://mail.mikej.com/core.txt.2

http://mail.mikej.com/info.2

http://mail.mikej.com/kernel.2

http://mail.mikej.com/kernel.full.2

--mikej

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast, a leader in email security and cyber 
resilience. Mimecast integrates email defenses with brand protection, security 
awareness training, web security, compliance and other essential capabilities. 
Mimecast helps protect large and small organizations from malicious activity, 
human error and technology failure; and to lead the movement toward building a 
more resilient world. To find out more, visit our website.

Re: New panic in main-n253273-a52d8d4a6c6:

kinda thinking this might be related to commit f40dd6c8034b ("tty: switch
ttyhook_register to use fget_cap_locked")

fget_unlocked() must have grabbed an extra reference count on the file
pointer that fget_cap_locked() doesn't get

On Mon, Feb 21, 2022 at 4:35 PM Hans Petter Selasky  wrote:

> On 2/22/22 00:42, Michael Jung wrote:
> > Hi:
> >
> > I was trying to remember what I did that was odd when this crash
> occurred then it
> > hit me.  You can repeat this panic by doing:
> >
> > # watch -I -W pts/0
> >
> > Here is another panic that happened write after issuing "watch" for
> comparison.
> >
> > http://mail.mikej.com/core.txt.1
> >
> > http://mail.mikej.com/info.1
> >
> > http://mail.mikej.com/vmcore.1
> >
>
> I also need your kernel and debug kernel to fully debug this.
>
> 1) Do ssh to machine.
> 2) watch -i -W pts/0 (does not panic over here)
>
> Can you explain what step 1 is? An scp ?
>
> Refcount is -1.
> f_count = 0x
>
> f_data = 0xf800158b0400
>
> In your KGDB, can you enter:
>
> info 0x81b052d0
>
> Does the attached patch make any difference?
>
> --HPS

Re: New panic in main-n253273-a52d8d4a6c6:

2022-02-21 Thread Hans Petter Selasky


On 2/22/22 00:42, Michael Jung wrote:

Hi:

I was trying to remember what I did that was odd when this crash occurred then 
it
hit me.  You can repeat this panic by doing:

# watch -I -W pts/0

Here is another panic that happened write after issuing "watch" for comparison.

http://mail.mikej.com/core.txt.1

http://mail.mikej.com/info.1

http://mail.mikej.com/vmcore.1



I also need your kernel and debug kernel to fully debug this.

1) Do ssh to machine.
2) watch -i -W pts/0 (does not panic over here)

Can you explain what step 1 is? An scp ?

Refcount is -1.
f_count = 0x

f_data = 0xf800158b0400

In your KGDB, can you enter:

info 0x81b052d0

Does the attached patch make any difference?

--HPSdiff --git a/sys/dev/snp/snp.c b/sys/dev/snp/snp.c
index 64e2d0f6453..6eec4a5a632 100644
--- a/sys/dev/snp/snp.c
+++ b/sys/dev/snp/snp.c
@@ -86,6 +86,7 @@ static d_poll_t		snp_poll;
 
 static struct cdevsw snp_cdevsw = {
 	.d_version	= D_VERSION,
+	.d_flags	= D_TRACKCLOSE,
 	.d_open		= snp_open,
 	.d_read		= snp_read,
 	.d_write	= snp_write,

RE: New panic in main-n253273-a52d8d4a6c6:

Hi:

I was trying to remember what I did that was odd when this crash occurred then 
it
hit me.  You can repeat this panic by doing:

# watch -I -W pts/0

Here is another panic that happened write after issuing "watch" for comparison.

http://mail.mikej.com/core.txt.1

http://mail.mikej.com/info.1

http://mail.mikej.com/vmcore.1

--mikej

-Original Message-
From: Michael Jung
Sent: Monday, February 21, 2022 6:22 PM
To: 'Hans Petter Selasky' ; freebsd-current 

Subject: RE: New panic in main-n253273-a52d8d4a6c6:

-Original Message-
From: Hans Petter Selasky [mailto:h...@selasky.org]
Sent: Monday, February 21, 2022 8:53 AM
To: Michael Jung ; freebsd-current 

Subject: Re: New panic in main-n253273-a52d8d4a6c6:

On 2/21/22 14:07, Michael Jung wrote:
> (kgdb) fram 16
> #16 0x80bad587 in closefp_impl (fdp=0xfe012b7c0430, fd=4, 
> fp=0xf801cc119280, td=0xfe00df8d0560, audit=true) at 
> /usr/src/sys/kern/kern_descrip.c:1300
> 1300error = closef(fp, td);
>
> (kgdb) print /x *fdp
> $1 = {fd_files = 0xfe00df6d9000, fd_map = 0xf80001bb1800, fd_freefile 
> = 0x4, fd_refcnt = 0x1, fd_holdcnt = 0x1, fd_sx = {lock_object = {lo_name = 
> 0x8124f6a9, lo_flags = 0x233, lo_data = 0x0,
>lo_witness = 0xf8041eb94000}, sx_lock = 0x1}, fd_kqlist =
> {tqh_first = 0x0, tqh_last = 0x0}, fd_holdleaderscount = 0x0,
> fd_holdleaderswakeup = 0x0}
> (kgdb)

Can you also:

print /x *fp

in the same frame?

--HPS

Unread portion of the kernel message buffer:
panic: refcount 0xf801cc119284 wraparound cpuid = 7 time = 1645382575
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0119a83c80
vpanic() at vpanic+0x17f/frame 0xfe0119a83cd0
panic() at panic+0x43/frame 0xfe0119a83d30
fdclose() at fdclose/frame 0xfe0119a83dc0
closefp_impl() at closefp_impl+0x77/frame 0xfe0119a83e00
amd64_syscall() at amd64_syscall+0x12e/frame 0xfe0119a83f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0119a83f30
--- syscall (6, FreeBSD ELF64, sys_close), rip = 0x3309a531b62a, rsp = 
0x3309a2802bc8, rbp = 0x3309a2803000 ---
KDB: enter: panic

__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55  __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct 
pcpu,

(kgdb) frame 16
#16 0x80bad587 in closefp_impl (fdp=0xfe012b7c0430, fd=4, 
fp=0xf801cc119280, td=0xfe00df8d0560, audit=true) at 
/usr/src/sys/kern/kern_descrip.c:1300
1300error = closef(fp, td);

(kgdb) print /x *fp
$1 = {f_flag = 0x5, f_count = 0x, f_data = 0xf800158b0400, f_ops = 
0x81b052d0, f_vnode = 0xf800d9156000, f_cred = 0xf801d81be400, 
f_type = 0x1, f_vnread_flags = 0x0, {f_seqcount = {0x0,
  0x0}, f_pipegen = 0x0}, f_nextoff = {0x0, 0x0}, f_vnun = {fvn_cdevpriv = 
0x0, fvn_advice = 0x0}, f_offset = 0x0}
(kgdb)

CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast, a leader in email security and cyber 
resilience. Mimecast integrates email defenses with brand protection, security 
awareness training, web security, compliance and other essential capabilities. 
Mimecast helps protect large and small organizations from malicious activity, 
human error and technology failure; and to lead the movement toward building a 
more resilient world. To find out more, visit our website.

RE: New panic in main-n253273-a52d8d4a6c6:

-Original Message-
From: Hans Petter Selasky [mailto:h...@selasky.org]
Sent: Monday, February 21, 2022 8:53 AM
To: Michael Jung ; freebsd-current 

Subject: Re: New panic in main-n253273-a52d8d4a6c6:

On 2/21/22 14:07, Michael Jung wrote:
> (kgdb) fram 16
> #16 0x80bad587 in closefp_impl (fdp=0xfe012b7c0430, fd=4, 
> fp=0xf801cc119280, td=0xfe00df8d0560, audit=true) at 
> /usr/src/sys/kern/kern_descrip.c:1300
> 1300error = closef(fp, td);
>
> (kgdb) print /x *fdp
> $1 = {fd_files = 0xfe00df6d9000, fd_map = 0xf80001bb1800, fd_freefile 
> = 0x4, fd_refcnt = 0x1, fd_holdcnt = 0x1, fd_sx = {lock_object = {lo_name = 
> 0x8124f6a9, lo_flags = 0x233, lo_data = 0x0,
>lo_witness = 0xf8041eb94000}, sx_lock = 0x1}, fd_kqlist = 
> {tqh_first = 0x0, tqh_last = 0x0}, fd_holdleaderscount = 0x0, 
> fd_holdleaderswakeup = 0x0}
> (kgdb)

Can you also:

print /x *fp

in the same frame?

--HPS

Unread portion of the kernel message buffer:
panic: refcount 0xf801cc119284 wraparound
cpuid = 7
time = 1645382575
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0119a83c80
vpanic() at vpanic+0x17f/frame 0xfe0119a83cd0
panic() at panic+0x43/frame 0xfe0119a83d30
fdclose() at fdclose/frame 0xfe0119a83dc0
closefp_impl() at closefp_impl+0x77/frame 0xfe0119a83e00
amd64_syscall() at amd64_syscall+0x12e/frame 0xfe0119a83f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0119a83f30
--- syscall (6, FreeBSD ELF64, sys_close), rip = 0x3309a531b62a, rsp = 
0x3309a2802bc8, rbp = 0x3309a2803000 ---
KDB: enter: panic

__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55  __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct 
pcpu,

(kgdb) frame 16
#16 0x80bad587 in closefp_impl (fdp=0xfe012b7c0430, fd=4, 
fp=0xf801cc119280, td=0xfe00df8d0560, audit=true) at 
/usr/src/sys/kern/kern_descrip.c:1300
1300error = closef(fp, td);

(kgdb) print /x *fp
$1 = {f_flag = 0x5, f_count = 0x, f_data = 0xf800158b0400, f_ops = 
0x81b052d0, f_vnode = 0xf800d9156000, f_cred = 0xf801d81be400, 
f_type = 0x1, f_vnread_flags = 0x0, {f_seqcount = {0x0,
  0x0}, f_pipegen = 0x0}, f_nextoff = {0x0, 0x0}, f_vnun = {fvn_cdevpriv = 
0x0, fvn_advice = 0x0}, f_offset = 0x0}
(kgdb)

CONFIDENTIALITY NOTE: This message is intended only for the use
of the individual or entity to whom it is addressed and may
contain information that is privileged, confidential, and
exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying
of this communication is strictly prohibited. If you have
received this transmission in error, please notify us by
telephone at (502) 212-4000 or notify us at PAI, Dept. 99,
2101 High Wickham Place, Suite 101, Louisville, KY 40245

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby notified 
that any disclosure, copying, distribution or taking action in relation of the 
contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast, a leader in email security and cyber 
resilience. Mimecast integrates email defenses with brand protection, security 
awareness training, web security, compliance and other essential capabilities. 
Mimecast helps protect large and small organizations from malicious activity, 
human error and technology failure; and to lead the movement toward building a 
more resilient world. To find out more, visit our website.

Re: New panic in main-n253273-a52d8d4a6c6:

2022-02-21 Thread Hans Petter Selasky


On 2/21/22 14:07, Michael Jung wrote:

(kgdb) fram 16
#16 0x80bad587 in closefp_impl (fdp=0xfe012b7c0430, fd=4, 
fp=0xf801cc119280, td=0xfe00df8d0560, audit=true) at 
/usr/src/sys/kern/kern_descrip.c:1300
1300error = closef(fp, td);

(kgdb) print /x *fdp
$1 = {fd_files = 0xfe00df6d9000, fd_map = 0xf80001bb1800, fd_freefile = 
0x4, fd_refcnt = 0x1, fd_holdcnt = 0x1, fd_sx = {lock_object = {lo_name = 
0x8124f6a9, lo_flags = 0x233, lo_data = 0x0,
   lo_witness = 0xf8041eb94000}, sx_lock = 0x1}, fd_kqlist = {tqh_first 
= 0x0, tqh_last = 0x0}, fd_holdleaderscount = 0x0, fd_holdleaderswakeup = 0x0}
(kgdb)


Can you also:

print /x *fp

in the same frame?

--HPS

RE: New panic in main-n253273-a52d8d4a6c6: