DRM and Radeon

[Graham Perrin]

On 26/01/2021 07:02, Alexey Dokuchaev wrote:


> Re: loading drm crashes system


> … There are known issues with Radeon cards, they were quite well
> supported a year ago, then something got broken. I've promised to
> bisect this and find the cause, but there were several
> syscall-related changes in -CURRENT though the course of the last
> year, so bisecting just the kernel is not enough (machine won't get
> to login prompt if the userland does not match), which cripples the
> process.
>
> I still intend to take this quest, just not sure when. :(
>
> ./danfe


Any cards in particular?

 
– whilst I didn't mention Radeon there, for me it _was_ the Radeon story 
that seemed to improve a few months ago.


 AMD Thames 
[Radeon HD 7550M/7570M/7650M]


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: loading drm crashes system

[Marek Zarychta]

W dniu 26.01.2021 o 08:02, Alexey Dokuchaev pisze:

On Mon, Jan 25, 2021 at 10:21:16PM -0500, Robert Huff wrote:

Niclas Zeising asks:

When did it stop working?


September ... I _think_.


Yeah, that sounds about right.

There are known issues with Radeon cards, they were quite well supported
a year ago, then something got broken.  I've promised to bisect this and
find the cause, but there were several syscall-related changes in -CURRENT
though the course of the last year, so bisecting just the kernel is not
enough (machine won't get to login prompt if the userland does not match),
which cripples the process.

I still intend to take this quest, just not sure when. :(

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



TBH I have backed up deprecated port graphics/drm-legacy-kmod and use it 
on 13-ALPHA. The port graphics/drm-current-kmod was unusable (console 
resolution, flaky gdm start etc.), tough no panics were observed.
One should be still able to build graphics/drm-legacy-kmod on 14-CURRENT 
for some time till the issue gets resolved.


--
Marek Zarychta
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: loading drm crashes system

[Alexey Dokuchaev]

On Mon, Jan 25, 2021 at 10:21:16PM -0500, Robert Huff wrote:
> Niclas Zeising asks:
> > When did it stop working?
> 
> September ... I _think_.

Yeah, that sounds about right.

There are known issues with Radeon cards, they were quite well supported
a year ago, then something got broken.  I've promised to bisect this and
find the cause, but there were several syscall-related changes in -CURRENT
though the course of the last year, so bisecting just the kernel is not
enough (machine won't get to login prompt if the userland does not match),
which cripples the process.

I still intend to take this quest, just not sure when. :(

./danfe
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

problem building virtualbox-ose-kmod

[monochrome]

having this issue building virtualbox-ose-kmod, its been like this for a 
while but I deinstalled and forgot, for quite a while now, maybe over a 
month. now that I've moved from 13-current to stable/13 I thought I 
would try to put it back, but it still wont build. I haven't seen anyone 
else with this problem, did I miss a memo?


.
.
.

--- semfastmutex-r0drv-freebsd.o ---
cc  -O2 -pipe -fno-strict-aliasing -DRT_OS_FREEBSD -DIN_RING0 -DIN_RT_R0 
-DIN_SUP_R0 -DSUPDRV_WITH_RELEASE_LOGGER -DVBOX -DRT_WITH_VBOX -w 
-DVBOX_WITH_HARDENING -DVBOX_WITH_64_BITS_GUESTS -DRT_ARCH_AMD64 
-Werror -D_KERNEL -DKLD_MODULE -nostdinc  -Iinclude -I. -Ir0drv -include 
/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5.2.44/out/freebsd.amd64/release/bin/src/vboxdrv/opt_global.h 
-I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common 
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
-fdebug-prefix-map=./machine=/usr/src/sys/amd64/include 
-fdebug-prefix-map=./x86=/usr/src/sys/x86/include -MD 
-MF.depend.semfastmutex-r0drv-freebsd.o -MTsemfastmutex-r0drv-freebsd.o 
-mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float 
-fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector 
-Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes 
-Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef 
-Wno-pointer-sign -D__printf__=__freebsd_kprintf__ 
-Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas 
-Wno-error-tautological-compare -Wno-error-empty-body 
-Wno-error-parentheses-equality -Wno-error-unused-function 
-Wno-error-pointer-sign -Wno-error-shift-negative-value 
-Wno-address-of-packed-member -Wno-format-zero-length   -mno-aes 
-mno-avx  -std=iso9899:1999 -c 
/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5.2.44/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/semfastmutex-r0drv-freebsd.c 
-o semfastmutex-r0drv-freebsd.o

--- memobj-r0drv-freebsd.o ---
/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5.2.44/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c:887:80: 
error: too few arguments to function call, expected 6, have 5
int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd, 
ProtectionFlags, FALSE);
  ~~ 
   ^

/usr/src/sys/vm/vm_map.h:517:5: note: 'vm_map_protect' declared here
int vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end,
^
1 error generated.
*** [memobj-r0drv-freebsd.o] Error code 1

make[3]: stopped in 
/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5.2.44/out/freebsd.amd64/release/bin/src/vboxdrv

1 error

make[3]: stopped in 
/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5.2.44/out/freebsd.amd64/release/bin/src/vboxdrv

*** [all] Error code 2

make[2]: stopped in 
/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5.2.44/out/freebsd.amd64/release/bin/src

1 error

make[2]: stopped in 
/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5.2.44/out/freebsd.amd64/release/bin/src

===> Compilation failed unexpectedly.
Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
the maintainer.
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/emulators/virtualbox-ose-kmod
*** Error code 1

Stop.
make: stopped in /usr/ports/emulators/virtualbox-ose-kmod

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: pkg for 14-current

[Philip Paeps]

On 2021-01-26 11:14:53 (+0800), Mark Millard wrote:

Philip Paeps philip at freebsd.org wrote on
Mon Jan 25 21:40:03 UTC 2021 :

The first package build for 14-CURRENT is visible on the mirrors now 
(as

of a couple of minutes ago).


It has been a bit so I tried and it failed for
what I tried so I looked at http://pkg.freebsd.org . It reported:

QUOTE
This is pkg0.tuk.FreeBSD.org - a West Coast, USA mirror for FreeBSD 
downloads.

END QUOTE

But nothing with FreeBSD:14 was listed on the page. So I
explicitly tried:

http://pkg.freebsd.org/FreeBSD:14:i386/
http://pkg.freebsd.org/FreeBSD:14:amd64/
http://pkg.freebsd.org/FreeBSD:14:aarch64/
http://pkg.freebsd.org/FreeBSD:14:powerpc64/

and only the first two were found.


I've not updated the index.html pages on the mirrors yet.  (Actually, I 
did update them, but I forgot to commit the change - I'll go and do that 
now.)


So far, only the amd64 and i386 builds appear to have completed.  I've 
not seen builds completed for the other archs.


Builds should trickle in for the other archs when they complete.

Philip

--
Philip Paeps
Senior Reality Engineer
Alternative Enterprises
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: loading drm crashes system

[Robert Huff]

Niclas Zeising asks:

>   Which version of drm-current-kmod?

5.4.62.g20210118

>   Can you try to remove it and build it directly from an updated ports 
>   tree, without using PORTS_MODULES=, and see if that helps?

It does not.

>   >   The GPU is a Radeon HD 3300, and at one point this used to work.
>   
>   When did it stop working?

September ... I _think_.
After the switch from sc to vt+drm, things worked for a while
... then they didn't for several months ... then - September??? - they
worked for about two weeks ... then they didn't again.


Respectfully,


Robert Huff

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: pkg for 14-current

[Mark Millard via freebsd-current]

Philip Paeps philip at freebsd.org wrote on
Mon Jan 25 21:40:03 UTC 2021 :

> The first package build for 14-CURRENT is visible on the mirrors now (as 
> of a couple of minutes ago).


It has been a bit so I tried and it failed for
what I tried so I looked at http://pkg.freebsd.org . It reported:

QUOTE
This is pkg0.tuk.FreeBSD.org - a West Coast, USA mirror for FreeBSD downloads.
END QUOTE

But nothing with FreeBSD:14 was listed on the page. So I
explicitly tried:

http://pkg.freebsd.org/FreeBSD:14:i386/
http://pkg.freebsd.org/FreeBSD:14:amd64/
http://pkg.freebsd.org/FreeBSD:14:aarch64/
http://pkg.freebsd.org/FreeBSD:14:powerpc64/

and only the first two were found.

I checked those 4 because of previously having looked at
https://pkg-status.freebsd.org and what it then reported
as building or having been built with a main- prefixed
Jail name: main-amd64 , main-i386 , main-arm64 ,
main-powerpc64 .

It looks like the main-arm64 build that is active started
before stable/13 was created.

It looks like the main-powerpc64 build is older (and
it finished) and there will not be powerpc64 materials
until a new build is started and it completes.

I did not see evidence of Jail names like main-armv7 ,
main-armv6 , main-mips , or main-mip64 . So I assume
that those are not being experimented with yet.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: fsck strange output

[Rozhuk Ivan]

On Mon, 25 Jan 2021 20:51:50 +
"Poul-Henning Kamp"  wrote:
> > Disk is 100% alive, got same on other HW.  
> 
> A disk can be alive and still have individually unreadable sectors,
> that is, IMO, the most common failure mode.
> 
> Try:
>   recoverdisk -v /dev/whatever
> 
> That will attempt to read all sectors on the disk.
> 

This happen on 4 different systems, that:
- based on Ryzen zen/zen+
- FreeBSD 13

2 systems have ECC that works and show no errors.

At least on 12 and prev on read error - kernel show
messages from drivers/geom.

recoverdisk -v - show no error.

I can reproduce this in VBox after disable "soft update journaling".
(I hope that you will not require from me to check VBox HW too :) ) 

VBOx - no "CANNOT READ BLK":
# tunefs -p /dev/ada0p2
tunefs: POSIX.1e ACLs: (-a)disabled
tunefs: NFSv4 ACLs: (-N)   disabled
tunefs: MAC multilabel: (-l)   disabled
tunefs: soft updates: (-n) enabled
tunefs: soft update journaling: (-j)   enabled
tunefs: gjournal: (-J) disabled
tunefs: trim: (-t) disabled
tunefs: maximum blocks per file in a cylinder group: (-e)  4096
tunefs: average file size: (-f)16384
tunefs: average number of files in a directory: (-s)   64
tunefs: minimum percentage of free space: (-m) 2%
tunefs: space to hold for metadata blocks: (-k)1600
tunefs: optimization preference: (-o)  space
tunefs: volume label: (-L) 


VBOx - "CANNOT READ BLK" is present:
# tunefs -p /dev/ada0p2
tunefs: POSIX.1e ACLs: (-a)disabled
tunefs: NFSv4 ACLs: (-N)   disabled
tunefs: MAC multilabel: (-l)   disabled
tunefs: soft updates: (-n) enabled
tunefs: soft update journaling: (-j)   disabled
tunefs: gjournal: (-J) disabled
tunefs: trim: (-t) disabled
tunefs: maximum blocks per file in a cylinder group: (-e)  4096
tunefs: average file size: (-f)16384
tunefs: average number of files in a directory: (-s)   64
tunefs: minimum percentage of free space: (-m) 2%
tunefs: space to hold for metadata blocks: (-k)1600
tunefs: optimization preference: (-o)  space
tunefs: volume label: (-L) 


5cc52631b3b88dfc36d8049dc8bece8573c5f9af
[PATCH] Rewrite the disk I/O management system in fsck_ffs(8). Other
Since this commit this issue started.
I check: build system from prev commit - OK, build from this - "CANNOT READ 
BLK".

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: fsck strange output

[Kirk McKusick]

> From: Rozhuk Ivan 
> Date: Mon, 25 Jan 2021 23:29:33 +0300
> To: freebsd-current@freebsd.org
> Cc: Rozhuk Ivan 
> Subject: fsck strange output
> 
> Hi!
> 
> I am on fresh 13 and on auto fsck got:
> 
> Jan 25 23:14:13 3des kernel: Starting file system checks:
> Jan 25 23:14:13 3des kernel: /dev/gptid/81241708-8948-11e9-b1ae-049226c061d6: 
> CANNOT READ BLK: 11072
> Jan 25 23:14:13 3des kernel: /dev/gptid/81241708-8948-11e9-b1ae-049226c061d6: 
> UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY.
> Jan 25 23:14:13 3des kernel: File system preen failed, trying fsck -y -T 
> ffs:-R,-r -T ufs:-R,-r
> Jan 25 23:14:13 3des kernel: ** 
> /dev/gptid/81241708-8948-11e9-b1ae-049226c061d6
> Jan 25 23:14:13 3des kernel: ** Last Mounted on /
> Jan 25 23:14:13 3des kernel: ** Root file system
> Jan 25 23:14:13 3des kernel: ** Phase 1 - Check Blocks and Sizes
> Jan 25 23:14:13 3des kernel: 
> Jan 25 23:14:13 3des kernel: CANNOT READ BLK: 11072
> Jan 25 23:14:13 3des kernel: UNEXPECTED SOFT UPDATE INCONSISTENCY
> Jan 25 23:14:13 3des kernel: 
> Jan 25 23:14:13 3des kernel: CONTINUE? yes
> Jan 25 23:14:13 3des kernel: 
> Jan 25 23:14:13 3des kernel: THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> Jan 25 23:14:13 3des kernel: 
> Jan 25 23:14:13 3des kernel: CANNOT READ BLK: 5129280
> Jan 25 23:14:13 3des kernel: UNEXPECTED SOFT UPDATE INCONSISTENCY
> Jan 25 23:14:13 3des kernel: 
> Jan 25 23:14:13 3des kernel: CONTINUE? yes
> Jan 25 23:14:13 3des kernel: 
> Jan 25 23:14:13 3des kernel: THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> Jan 25 23:14:13 3des kernel: 
> Jan 25 23:14:13 3des kernel: CANNOT READ BLK: 6411520
> Jan 25 23:14:13 3des kernel: UNEXPECTED SOFT UPDATE INCONSISTENCY
> Jan 25 23:14:13 3des kernel: 
> Jan 25 23:14:13 3des kernel: CONTINUE? yes
> Jan 25 23:14:13 3des kernel: 
> Jan 25 23:14:13 3des kernel: THE FOLLOWING DISK SECTORS COULD NOT BE READ:
> Jan 25 23:14:13 3des kernel: 
> Jan 25 23:14:13 3des kernel: CANNOT READ BLK: 7693888
> Jan 25 23:14:13 3des kernel: UNEXPECTED SOFT UPDATE INCONSISTENCY
> Jan 25 23:14:13 3des kernel: 
> Jan 25 23:14:13 3des kernel: CONTINUE? yes
> 
> 
> Disk is 100% alive, got same on other HW.
> fsck -y - have no this strange problem with reading.
> 
> Is it OK "CANNOT READ BLK ..." ?
> 
> 
> >From my rc.conf:
> fsck_y_enable="YES"   # Set to YES to do fsck -y if the initial preen 
> fails.
> fsck_y_flags="-T ffs:-R,-r -T ufs:-R,-r" # Additional flags for fsck -y
> background_fsck="NO"  # Attempt to run fsck in the background where 
> possible.

Please try this patch to fsck_ffs and see if it fixes your problem.

Kirk McKusick

=-=-=

*** sbin/fsck_ffs/inode.c.orig  2021-01-07 15:04:04.969086284 -0800
--- sbin/fsck_ffs/inode.c   2021-01-25 15:29:06.404803358 -0800
***
*** 611,618 
sizeof(struct ufs1_dinode) : sizeof(struct ufs2_dinode));
readpercg = inosused / fullcnt;
partialcnt = inosused % fullcnt;
!   partialsize = partialcnt * ((sblock.fs_magic == FS_UFS1_MAGIC) ?
!   sizeof(struct ufs1_dinode) : sizeof(struct ufs2_dinode));
if (partialcnt != 0) {
readpercg++;
} else {
--- 611,619 
sizeof(struct ufs1_dinode) : sizeof(struct ufs2_dinode));
readpercg = inosused / fullcnt;
partialcnt = inosused % fullcnt;
!   partialsize = fragroundup(,
!   partialcnt * ((sblock.fs_magic == FS_UFS1_MAGIC) ?
!   sizeof(struct ufs1_dinode) : sizeof(struct ufs2_dinode)));
if (partialcnt != 0) {
readpercg++;
} else {
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Getting /usr/src to match specific git hash?

[Warner Losh]

On Mon, Jan 25, 2021 at 3:57 PM tech-lists  wrote:

> On Sun, Jan 24, 2021 at 01:08:05PM +0900, Yasuhiro Kimura wrote:
> >From: Steve Kargl 
> >Subject: Getting /usr/src to match specific git hash?
> >Date: Sat, 23 Jan 2021 19:58:52 -0800
> >
> >> Suppose one has an empty /usr/src.
> >>
> >> Suppose further that one had to re-install a 32-bit
> >> i386-*-freebsd with the 24 Dec 2020 image available
> >> from freebsd.org.
> >>
> >> uname -a for the booted kernel shows
> >>
> >> % uname -a
> >> FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #0 \
> >> 3cc0c0d66a0-c255241(main)-dirty: Thu Dec 24 05:43:23 UTC 2020 \
> >> r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/i386.i386/sys/GENERIC
> i386
> >>
> >> How does one use git to pull the exact sources that match
> >> this specifc kernel?
> >
> >cd /usr
> >git clone https://git.freebsd.org/src.git
> >cd src
> >git checkout 3cc0c0d66a0
>
> I have the exact same issue. The installation I have is:
>
> 13.0-CURRENT #0 2ed50808d2b-c254384(main): Thu Nov 12 10:03:35 UTC 2020
>
> The method described doesn't work for me for some reason:
>
> [...]
> root@rpi4:/usr # git clone https://git.freebsd.org/src.git
> Cloning into 'src'...
> remote: Enumerating objects: 377505, done.
> remote: Counting objects: 100% (377505/377505), done.
> remote: Compressing objects: 100% (26583/26583), done.
> remote: Total 3831969 (delta 371848), reused 350922 (delta 350922),
> pack-reused 3454464
> Receiving objects: 100% (3831969/3831969), 1.14 GiB | 6.28 MiB/s, done.
> Resolving deltas: 100% (3034679/3034679), done.
> Updating files: 100% (85162/85162), done.
> root@rpi4:/usr # cd src
> root@rpi4:/usr/src # git checkout 2ed50808d2b
> error: pathspec '2ed50808d2b' did not match any file(s) known to git
>

For the archives, this is because this hash is from the old beta hashes
that we got rid of. there's another thread that has all the details.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Getting /usr/src to match specific git hash?

[tech-lists]

On Sun, Jan 24, 2021 at 01:08:05PM +0900, Yasuhiro Kimura wrote:

From: Steve Kargl 
Subject: Getting /usr/src to match specific git hash?
Date: Sat, 23 Jan 2021 19:58:52 -0800


Suppose one has an empty /usr/src.

Suppose further that one had to re-install a 32-bit
i386-*-freebsd with the 24 Dec 2020 image available
from freebsd.org.

uname -a for the booted kernel shows

% uname -a
FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT #0 \
3cc0c0d66a0-c255241(main)-dirty: Thu Dec 24 05:43:23 UTC 2020 \
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/i386.i386/sys/GENERIC i386

How does one use git to pull the exact sources that match
this specifc kernel?


cd /usr
git clone https://git.freebsd.org/src.git
cd src
git checkout 3cc0c0d66a0


I have the exact same issue. The installation I have is:

13.0-CURRENT #0 2ed50808d2b-c254384(main): Thu Nov 12 10:03:35 UTC 2020

The method described doesn't work for me for some reason:

[...]
root@rpi4:/usr # git clone https://git.freebsd.org/src.git
Cloning into 'src'...

remote: Enumerating objects: 377505, done.
remote: Counting objects: 100% (377505/377505), done.
remote: Compressing objects: 100% (26583/26583), done.
remote: Total 3831969 (delta 371848), reused 350922 (delta 350922), pack-reused 
3454464
Receiving objects: 100% (3831969/3831969), 1.14 GiB | 6.28 MiB/s, done.
Resolving deltas: 100% (3034679/3034679), done.
Updating files: 100% (85162/85162), done.
root@rpi4:/usr # cd src
root@rpi4:/usr/src # git checkout 2ed50808d2b 
error: pathspec '2ed50808d2b' did not match any file(s) known to git


thanks,
--
J.


signature.asc
Description: PGP signature

Re: ZFS feature compatibility?

[Toomas Soome via freebsd-current]

> On 26. Jan 2021, at 00:23, John Kennedy  wrote:
> 
>> Thanks, I am new to the EFI world.  Does the name now have to be
>> BOOTx64.efi ?
>> 
>> root@zoo2:/boot # ls -l /mnt/EFI/freebsd/
>> total 824
>> -rwxr-xr-x  1 root  wheel  843776 Nov 21 10:50 loader.efi
>> root@zoo2:/boot #
> 


if there is no UEFI bootmanager configured (see man efibootmgr), then (ESP) 
efi/boot/bootx64.efi is default. with efibootmgr(8), you can configure custom 
path, such as (ESP) efi/freebsd/loader.efi

rgds,
toomas



>  I don't know.  This came out of an email thread I had a while ago:
> 
>   Date: Thu, 9 Jul 2020 14:18:54 -0700
>   From: John Kennedy 
>   To: Kyle Evans 
>   Cc: FreeBSD-STABLE Mailing List 
>   Subject: Re: 12.1p7 no longer boots after doing zpool upgrade -a
> 
>  The "new" documentation was here:
> 
>   https://wiki.freebsd.org/UEFI
> 
>  The older stuff is still mentioned here:
> 
>   https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ZFS feature compatibility?

[John Kennedy]

> Thanks, I am new to the EFI world.  Does the name now have to be
> BOOTx64.efi ?
> 
> root@zoo2:/boot # ls -l /mnt/EFI/freebsd/
> total 824
> -rwxr-xr-x  1 root  wheel  843776 Nov 21 10:50 loader.efi
> root@zoo2:/boot #

  I don't know.  This came out of an email thread I had a while ago:

Date: Thu, 9 Jul 2020 14:18:54 -0700
From: John Kennedy 
To: Kyle Evans 
Cc: FreeBSD-STABLE Mailing List 
Subject: Re: 12.1p7 no longer boots after doing zpool upgrade -a

  The "new" documentation was here:

https://wiki.freebsd.org/UEFI

  The older stuff is still mentioned here:

https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD-provided .vhd with VirtualBox: gpart I/O errors after resizing the virtual hard disk

[Graham Perrin]

On 17/01/2021 18:22, Graham Perrin wrote:

VirtualBox 5.2.44 r139111 on FreeBSD-CURRENT.

01. Add FreeBSD-12.2-RELEASE-amd64.vhd to a machine
02. use Virtual Disk Manager to resize it to 2.0 TB
03. apply, close
04. boot single user
05. gpart show /dev/ada0
07. observe reported corruption
08. gpart recover /dev/ada0
09. I/O error 
10. gpart show /dev/ada0
11. no reported corruption
12. shutdown -r now
13. observe reported corruption:

> gptboot: invalid backup GPT header



For me, this seems to be consistently reproducible.

Thoughts?

Boot proceeds and  I guess that the 
UFS file system is automatically grown, but the reported I/O errors 
make me nervous.


% uname -v
FreeBSD 13.0-CURRENT #75 main-c572-g82397d791: Sun Jan  3 20:00:09 GMT 
2021 
root@mowa219-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG

%

With FreeBSD-provided 'FreeBSD-12.1-RELEASE-amd64.vhd', things seem even 
worse. Please see, for example, this screen recording:




What's going wrong?

Is it necessary to boot first from something _other_ than the resized 
disk, for things such as gpart recover to proceed without I/O error for 
the resized disk?


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ZFS feature compatibility?

[Toomas Soome via freebsd-current]

> On 25. Jan 2021, at 23:08, Allan Jude  wrote:
> 
> On 2021-01-25 16:03, Toomas Soome via freebsd-current wrote:
>> 
>> 
>>> On 25. Jan 2021, at 22:15, mike tancsa  wrote:
>>> 
>>> On 1/25/2021 2:37 PM, Toomas Soome via freebsd-current wrote:
 
> On 25. Jan 2021, at 21:31, Michael Butler via freebsd-current 
>  wrote:
> 
> I have a few machines on which I've been hesitant to run 'zpool upgrade' 
> as I'm not sure of the (boot?) implications. They report like this ..
> 
> imb@toshi:/home/imb> uname -a
> FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD 
> 14.0-CURRENT #25 main-eb61de5b78: Fri Jan 22 10:03:02 EST 2021 
> r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI
>  amd64
> 
> imb@toshi:/home/imb> zpool status
> pool: zroot
> state: ONLINE
> status: Some supported features are not enabled on the pool. The pool can
>  still be used, but some features are unavailable.
> action: Enable all features using 'zpool upgrade'. Once this is done,
>  the pool may no longer be accessible by software that does not 
> support
>  the features. See zpool-features(5) for details.
> 
> Is it safe to upgrade the root pool?
> 
>   imb
 We can not boot from encrypted pool and draid. Rest is all ok. Please 
 note, you may need to update the bootblocks.
 
>>> last Friday on zoo.freebsd.org  
>>> >, m...@freebsd.org 
>>>  >> > and I could not boot
>>> again because v2 bookmarks were on the boot pool.  I had to boot from
>>> another disk, remove the bookmarks and then boot. This was on RELENG_13
>>> (stable/13-c256203-g51d73a3e46c)
>>> 
>>>—Mike
>> 
>> /*
>> * List of ZFS features supported for read
>> */
>> static const char *features_for_read[] = {
>>"org.illumos:lz4_compress",
>>"com.delphix:hole_birth",
>>"com.delphix:extensible_dataset",
>>"com.delphix:embedded_data",
>>"org.open-zfs:large_blocks",
>>"org.illumos:sha512",
>>"org.illumos:skein",
>>"org.zfsonlinux:large_dnode",
>>"com.joyent:multi_vdev_crash_dump",
>>"com.delphix:spacemap_histogram",
>>"com.delphix:zpool_checkpoint",
>>"com.delphix:spacemap_v2",
>>"com.datto:encryption",
>>"com.datto:bookmark_v2",
>>"org.zfsonlinux:allocation_classes",
>>"com.datto:resilver_defer",
>>"com.delphix:device_removal",
>>"com.delphix:obsolete_counts",
>>"com.intel:allocation_classes",
>>"org.freebsd:zstd_compress",
>>"com.delphix:bookmark_written",
>>NULL
>> };
>> 
>> Are you sure you have bootblocks updated? ESP for UEFI boot and freebsd-boot 
>> for BIOS boot.
>> 
>> rgds,
>> toomas
>> ___
>> freebsd-current@freebsd.org  mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current 
>> 
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org 
>> "
>> 
> 
> Toomas: how difficult do we think it would be to make a ports version of
> the updated boot code, especially for the case of people using the
> openzfs-kmod on 12.2?
> 
> 

zstd would be interesting…  

rgds,
toomas

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ZFS feature compatibility?

[mike tancsa]

On 1/25/2021 4:51 PM, John Kennedy wrote:
> On Mon, Jan 25, 2021 at 04:17:18PM -0500, mike tancsa wrote:
>> Is there a way to check from the bin if its the right version ? strings
>> of the file doesnt seem to show anything useful.  I wonder if its the
>> UEFI boot that got missed ?  Just
>>
>> gpart bootcode -p /boot/boot1.efifat -i 1ada8
>> gpart bootcode -p /boot/boot1.efifat -i 1ada9
>>
>> I take it ?
>   I don't think that is the way to update UEFI anymore (although last time I
> looked it was still documented that way in one place).
>
>   For my last bootcode (which had UEFI & BIOS) update, I basically did this:
>
>   gpart show nvd0
>   =>   40  976773088  nvd0  GPT  (466G)
>40 409600 1  efi  (200M)
>409640   1024 2  freebsd-boot  (512K)
>410664984- free -  (492K)
>411648   16777216 3  freebsd-swap  (8.0G)
>  17188864  959584256 4  freebsd-zfs  (458G)
> 976773120  8- free -  (4.0K)
>
>   gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 nvd0
>   partcode written to nvd0p2
>   bootcode written to nvd0
>
>   mount -vt msdosfs /dev/nvd0p1 /mnt
>   /dev/nvd0p1 on /mnt (msdosfs, local, writes: sync 1 async 0, 
> reads: sync 13 async 0, fsid 5c003200)
>   install -p -m755 /boot/loader.efi /mnt/efi/boot/BOOTx64.efi
>   umount -v /mnt
>   /dev/nvd0p1: unmount from /mnt

Thanks, I am new to the EFI world.  Does the name now have to be
BOOTx64.efi ?

root@zoo2:/boot # ls -l /mnt/EFI/freebsd/
total 824
-rwxr-xr-x  1 root  wheel  843776 Nov 21 10:50 loader.efi
root@zoo2:/boot #

    ---Mike


>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ZFS feature compatibility?

[John Kennedy]

On Mon, Jan 25, 2021 at 04:17:18PM -0500, mike tancsa wrote:
> Is there a way to check from the bin if its the right version ? strings
> of the file doesnt seem to show anything useful.  I wonder if its the
> UEFI boot that got missed ?  Just
> 
> gpart bootcode -p /boot/boot1.efifat -i 1ada8
> gpart bootcode -p /boot/boot1.efifat -i 1ada9
> 
> I take it ?

  I don't think that is the way to update UEFI anymore (although last time I
looked it was still documented that way in one place).

  For my last bootcode (which had UEFI & BIOS) update, I basically did this:

gpart show nvd0
=>   40  976773088  nvd0  GPT  (466G)
 40 409600 1  efi  (200M)
 409640   1024 2  freebsd-boot  (512K)
 410664984- free -  (492K)
 411648   16777216 3  freebsd-swap  (8.0G)
   17188864  959584256 4  freebsd-zfs  (458G)
  976773120  8- free -  (4.0K)

gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 nvd0
partcode written to nvd0p2
bootcode written to nvd0

mount -vt msdosfs /dev/nvd0p1 /mnt
/dev/nvd0p1 on /mnt (msdosfs, local, writes: sync 1 async 0, 
reads: sync 13 async 0, fsid 5c003200)
install -p -m755 /boot/loader.efi /mnt/efi/boot/BOOTx64.efi
umount -v /mnt
/dev/nvd0p1: unmount from /mnt

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: pkg for 14-current

[Philip Paeps]

On 2021-01-24 18:18:29 (+0800), Yasuhiro Kimura wrote:


From: Masachika ISHIZUKA 
Subject: pkg for 14-current
Date: Sun, 24 Jan 2021 19:11:28 +0900 (JST)


  Hi.

  I updated to 14-current from 13-current and reinstalled 
ports-mgmt/pkg.

  I cannot get meta files for 14-current.
  How can I use pkg on 14-current ?


# pkg update
Updating FreeBSD repository catalogue...
pkg: http://pkgmir.geo.freebsd.org/FreeBSD:14:amd64/latest/meta.txz: 
Not Found

repository FreeBSD has no meta file, using default settings
pkg: 
http://pkgmir.geo.freebsd.org/FreeBSD:14:amd64/latest/packagesite.txz: 
Not Found

Unable to update repository FreeBSD
Error updating repositories!


All what you can do is to wait until build of offical packages for
14-CURRENT has completed unless you build them by yourself.


The first package build for 14-CURRENT is visible on the mirrors now (as 
of a couple of minutes ago).


Philip

--
Philip Paeps
Senior Reality Engineer
Alternative Enterprises
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ZFS feature compatibility?

[mike tancsa]

On 1/25/2021 4:03 PM, Toomas Soome wrote:
>
>
>> On 25. Jan 2021, at 22:15, mike tancsa > > wrote:
>>
>> On 1/25/2021 2:37 PM, Toomas Soome via freebsd-current wrote:
>>>
 On 25. Jan 2021, at 21:31, Michael Butler via freebsd-current
 mailto:freebsd-current@freebsd.org>>
 wrote:

 I have a few machines on which I've been hesitant to run 'zpool
 upgrade' as I'm not sure of the (boot?) implications. They report
 like this ..

 imb@toshi:/home/imb> uname -a
 FreeBSD toshi.auburn.protected-networks.net
  14.0-CURRENT FreeBSD
 14.0-CURRENT #25 main-eb61de5b78: Fri Jan 22 10:03:02 EST 2021
 r...@toshi.auburn.protected-networks.net
 :/usr/obj/usr/src/amd64.amd64/sys/TOSHI
 amd64

 imb@toshi:/home/imb> zpool status
 pool: zroot
 state: ONLINE
 status: Some supported features are not enabled on the pool. The
 pool can
   still be used, but some features are unavailable.
 action: Enable all features using 'zpool upgrade'. Once this is done,
   the pool may no longer be accessible by software that does
 not support
   the features. See zpool-features(5) for details.

 Is it safe to upgrade the root pool?

 imb
>>> We can not boot from encrypted pool and draid. Rest is all ok.
>>> Please note, you may need to update the bootblocks.
>>>
>> last Friday on zoo.freebsd.org
>> , m...@freebsd.org
>>  and I could not boot
>> again because v2 bookmarks were on the boot pool.  I had to boot from
>> another disk, remove the bookmarks and then boot. This was on RELENG_13
>> (stable/13-c256203-g51d73a3e46c)
>>
>>     —Mike
>
> /*
>  * List of ZFS features supported for read
>  */
> static const char *features_for_read[] = {
>         "org.illumos:lz4_compress",
>         "com.delphix:hole_birth",
>         "com.delphix:extensible_dataset",
>         "com.delphix:embedded_data",
>         "org.open-zfs:large_blocks",
>         "org.illumos:sha512",
>         "org.illumos:skein",
>         "org.zfsonlinux:large_dnode",
>         "com.joyent:multi_vdev_crash_dump",
>         "com.delphix:spacemap_histogram",
>         "com.delphix:zpool_checkpoint",
>         "com.delphix:spacemap_v2",
>         "com.datto:encryption",
>         "com.datto:bookmark_v2",
>         "org.zfsonlinux:allocation_classes",
>         "com.datto:resilver_defer",
>         "com.delphix:device_removal",
>         "com.delphix:obsolete_counts",
>         "com.intel:allocation_classes",
>         "org.freebsd:zstd_compress",
>         "com.delphix:bookmark_written",
>         NULL
> };
>
> Are you sure you have bootblocks updated? ESP for UEFI boot and
> freebsd-boot for BIOS boot.
>
>
mjg did them IIRC.  I just checked to make sure both were done and they
seem identical

root@zoo2:/home/mdtancsa # dd if=/dev/ada8p2 of=/tmp/8
1024+0 records in
1024+0 records out
524288 bytes transferred in 0.046479 secs (11280092 bytes/sec)
root@zoo2:/home/mdtancsa # dd if=/dev/ada9p2 of=/tmp/9
1024+0 records in
1024+0 records out
524288 bytes transferred in 0.054717 secs (9581751 bytes/sec)
root@zoo2:/home/mdtancsa # md5 /tmp/8 /tmp/9
MD5 (/tmp/8) = e294b1344cbb49c751474facc39998ec
MD5 (/tmp/9) = e294b1344cbb49c751474facc39998ec
root@zoo2:/home/mdtancsa #

Is there a way to check from the bin if its the right version ? strings
of the file doesnt seem to show anything useful.  I wonder if its the
UEFI boot that got missed ?  Just

gpart bootcode -p /boot/boot1.efifat -i 1ada8

gpart bootcode -p /boot/boot1.efifat -i 1ada9

I take it ?

MD5 (/tmp/81) = ff8762fa2b885347a0030b45b0f3844e
MD5 (/tmp/91) = e0fa5369ddb0471373bca6b29e027680
MD5 (/boot/boot1.efi) = c023e2c74479b2f0710ab0337a7bab4f

root@zoo2:/boot # dd if=/dev/ada9p1 of=/tmp/91 bs=1m
200+0 records in
200+0 records out
209715200 bytes transferred in 0.557007 secs (376503669 bytes/sec)
root@zoo2:/boot # dd if=/dev/ada8p1 of=/tmp/81 bs=1m
200+0 records in
200+0 records out
209715200 bytes transferred in 0.475806 secs (440757874 bytes/sec)
root@zoo2:/boot # md5 /tmp/81 /tmp/91 /boot/boot1
boot1  boot1.efi*
root@zoo2:/boot # md5 /tmp/81 /tmp/91 /boot/boot1.efi
MD5 (/tmp/81) = ff8762fa2b885347a0030b45b0f3844e
MD5 (/tmp/91) = e0fa5369ddb0471373bca6b29e027680
MD5 (/boot/boot1.efi) = c023e2c74479b2f0710ab0337a7bab4f

I am guessing they extracted boot blocks should match, no ?

    ---Mike


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ZFS feature compatibility?

[Allan Jude]

On 2021-01-25 16:03, Toomas Soome via freebsd-current wrote:
> 
> 
>> On 25. Jan 2021, at 22:15, mike tancsa  wrote:
>>
>> On 1/25/2021 2:37 PM, Toomas Soome via freebsd-current wrote:
>>>
 On 25. Jan 2021, at 21:31, Michael Butler via freebsd-current 
  wrote:

 I have a few machines on which I've been hesitant to run 'zpool upgrade' 
 as I'm not sure of the (boot?) implications. They report like this ..

 imb@toshi:/home/imb> uname -a
 FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD 
 14.0-CURRENT #25 main-eb61de5b78: Fri Jan 22 10:03:02 EST 2021 
 r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI
  amd64

 imb@toshi:/home/imb> zpool status
 pool: zroot
 state: ONLINE
 status: Some supported features are not enabled on the pool. The pool can
   still be used, but some features are unavailable.
 action: Enable all features using 'zpool upgrade'. Once this is done,
   the pool may no longer be accessible by software that does not 
 support
   the features. See zpool-features(5) for details.

 Is it safe to upgrade the root pool?

imb
>>> We can not boot from encrypted pool and draid. Rest is all ok. Please note, 
>>> you may need to update the bootblocks.
>>>
>> last Friday on zoo.freebsd.org , m...@freebsd.org 
>>  and I could not boot
>> again because v2 bookmarks were on the boot pool.  I had to boot from
>> another disk, remove the bookmarks and then boot. This was on RELENG_13
>> (stable/13-c256203-g51d73a3e46c)
>>
>> —Mike
> 
> /*
>  * List of ZFS features supported for read
>  */
> static const char *features_for_read[] = {
> "org.illumos:lz4_compress",
> "com.delphix:hole_birth",
> "com.delphix:extensible_dataset",
> "com.delphix:embedded_data",
> "org.open-zfs:large_blocks",
> "org.illumos:sha512",
> "org.illumos:skein",
> "org.zfsonlinux:large_dnode",
> "com.joyent:multi_vdev_crash_dump",
> "com.delphix:spacemap_histogram",
> "com.delphix:zpool_checkpoint",
> "com.delphix:spacemap_v2",
> "com.datto:encryption",
> "com.datto:bookmark_v2",
> "org.zfsonlinux:allocation_classes",
> "com.datto:resilver_defer",
> "com.delphix:device_removal",
> "com.delphix:obsolete_counts",
> "com.intel:allocation_classes",
> "org.freebsd:zstd_compress",
> "com.delphix:bookmark_written",
> NULL
> };
> 
> Are you sure you have bootblocks updated? ESP for UEFI boot and freebsd-boot 
> for BIOS boot.
> 
> rgds,
> toomas
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

Toomas: how difficult do we think it would be to make a ports version of
the updated boot code, especially for the case of people using the
openzfs-kmod on 12.2?


-- 
Allan Jude
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ZFS feature compatibility?

[Toomas Soome via freebsd-current]

> On 25. Jan 2021, at 22:15, mike tancsa  wrote:
> 
> On 1/25/2021 2:37 PM, Toomas Soome via freebsd-current wrote:
>> 
>>> On 25. Jan 2021, at 21:31, Michael Butler via freebsd-current 
>>>  wrote:
>>> 
>>> I have a few machines on which I've been hesitant to run 'zpool upgrade' as 
>>> I'm not sure of the (boot?) implications. They report like this ..
>>> 
>>> imb@toshi:/home/imb> uname -a
>>> FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD 
>>> 14.0-CURRENT #25 main-eb61de5b78: Fri Jan 22 10:03:02 EST 2021 
>>> r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI
>>>  amd64
>>> 
>>> imb@toshi:/home/imb> zpool status
>>> pool: zroot
>>> state: ONLINE
>>> status: Some supported features are not enabled on the pool. The pool can
>>>   still be used, but some features are unavailable.
>>> action: Enable all features using 'zpool upgrade'. Once this is done,
>>>   the pool may no longer be accessible by software that does not support
>>>   the features. See zpool-features(5) for details.
>>> 
>>> Is it safe to upgrade the root pool?
>>> 
>>> imb
>> We can not boot from encrypted pool and draid. Rest is all ok. Please note, 
>> you may need to update the bootblocks.
>> 
> last Friday on zoo.freebsd.org , m...@freebsd.org 
>  and I could not boot
> again because v2 bookmarks were on the boot pool.  I had to boot from
> another disk, remove the bookmarks and then boot. This was on RELENG_13
> (stable/13-c256203-g51d73a3e46c)
> 
> —Mike

/*
 * List of ZFS features supported for read
 */
static const char *features_for_read[] = {
"org.illumos:lz4_compress",
"com.delphix:hole_birth",
"com.delphix:extensible_dataset",
"com.delphix:embedded_data",
"org.open-zfs:large_blocks",
"org.illumos:sha512",
"org.illumos:skein",
"org.zfsonlinux:large_dnode",
"com.joyent:multi_vdev_crash_dump",
"com.delphix:spacemap_histogram",
"com.delphix:zpool_checkpoint",
"com.delphix:spacemap_v2",
"com.datto:encryption",
"com.datto:bookmark_v2",
"org.zfsonlinux:allocation_classes",
"com.datto:resilver_defer",
"com.delphix:device_removal",
"com.delphix:obsolete_counts",
"com.intel:allocation_classes",
"org.freebsd:zstd_compress",
"com.delphix:bookmark_written",
NULL
};

Are you sure you have bootblocks updated? ESP for UEFI boot and freebsd-boot 
for BIOS boot.

rgds,
toomas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: fsck strange output

[Poul-Henning Kamp]

Rozhuk Ivan writes:

> Disk is 100% alive, got same on other HW.

A disk can be alive and still have individually unreadable sectors,
that is, IMO, the most common failure mode.

Try:
recoverdisk -v /dev/whatever

That will attempt to read all sectors on the disk.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

fsck strange output

[Rozhuk Ivan]

Hi!


I am on fresh 13 and on auto fsck got:

Jan 25 23:14:13 3des kernel: Starting file system checks:
Jan 25 23:14:13 3des kernel: /dev/gptid/81241708-8948-11e9-b1ae-049226c061d6: 
CANNOT READ BLK: 11072
Jan 25 23:14:13 3des kernel: /dev/gptid/81241708-8948-11e9-b1ae-049226c061d6: 
UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY.
Jan 25 23:14:13 3des kernel: File system preen failed, trying fsck -y -T 
ffs:-R,-r -T ufs:-R,-r
Jan 25 23:14:13 3des kernel: ** /dev/gptid/81241708-8948-11e9-b1ae-049226c061d6
Jan 25 23:14:13 3des kernel: ** Last Mounted on /
Jan 25 23:14:13 3des kernel: ** Root file system
Jan 25 23:14:13 3des kernel: ** Phase 1 - Check Blocks and Sizes
Jan 25 23:14:13 3des kernel: 
Jan 25 23:14:13 3des kernel: CANNOT READ BLK: 11072
Jan 25 23:14:13 3des kernel: UNEXPECTED SOFT UPDATE INCONSISTENCY
Jan 25 23:14:13 3des kernel: 
Jan 25 23:14:13 3des kernel: CONTINUE? yes
Jan 25 23:14:13 3des kernel: 
Jan 25 23:14:13 3des kernel: THE FOLLOWING DISK SECTORS COULD NOT BE READ:
Jan 25 23:14:13 3des kernel: 
Jan 25 23:14:13 3des kernel: CANNOT READ BLK: 5129280
Jan 25 23:14:13 3des kernel: UNEXPECTED SOFT UPDATE INCONSISTENCY
Jan 25 23:14:13 3des kernel: 
Jan 25 23:14:13 3des kernel: CONTINUE? yes
Jan 25 23:14:13 3des kernel: 
Jan 25 23:14:13 3des kernel: THE FOLLOWING DISK SECTORS COULD NOT BE READ:
Jan 25 23:14:13 3des kernel: 
Jan 25 23:14:13 3des kernel: CANNOT READ BLK: 6411520
Jan 25 23:14:13 3des kernel: UNEXPECTED SOFT UPDATE INCONSISTENCY
Jan 25 23:14:13 3des kernel: 
Jan 25 23:14:13 3des kernel: CONTINUE? yes
Jan 25 23:14:13 3des kernel: 
Jan 25 23:14:13 3des kernel: THE FOLLOWING DISK SECTORS COULD NOT BE READ:
Jan 25 23:14:13 3des kernel: 
Jan 25 23:14:13 3des kernel: CANNOT READ BLK: 7693888
Jan 25 23:14:13 3des kernel: UNEXPECTED SOFT UPDATE INCONSISTENCY
Jan 25 23:14:13 3des kernel: 
Jan 25 23:14:13 3des kernel: CONTINUE? yes


Disk is 100% alive, got same on other HW.
fsck -y - have no this strange problem with reading.

Is it OK "CANNOT READ BLK ..." ?


>From my rc.conf:
fsck_y_enable="YES" # Set to YES to do fsck -y if the initial preen 
fails.
fsck_y_flags="-T ffs:-R,-r -T ufs:-R,-r" # Additional flags for fsck -y
background_fsck="NO"# Attempt to run fsck in the background where 
possible.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ZFS feature compatibility?

[mike tancsa]

On 1/25/2021 2:37 PM, Toomas Soome via freebsd-current wrote:
>
>> On 25. Jan 2021, at 21:31, Michael Butler via freebsd-current 
>>  wrote:
>>
>> I have a few machines on which I've been hesitant to run 'zpool upgrade' as 
>> I'm not sure of the (boot?) implications. They report like this ..
>>
>> imb@toshi:/home/imb> uname -a
>> FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD 
>> 14.0-CURRENT #25 main-eb61de5b78: Fri Jan 22 10:03:02 EST 2021 
>> r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI
>>   amd64
>>
>> imb@toshi:/home/imb> zpool status
>>  pool: zroot
>> state: ONLINE
>> status: Some supported features are not enabled on the pool. The pool can
>>still be used, but some features are unavailable.
>> action: Enable all features using 'zpool upgrade'. Once this is done,
>>the pool may no longer be accessible by software that does not support
>>the features. See zpool-features(5) for details.
>>
>> Is it safe to upgrade the root pool?
>>
>>  imb
> We can not boot from encrypted pool and draid. Rest is all ok. Please note, 
> you may need to update the bootblocks.
>
last Friday on zoo.freebsd.org, m...@freebsd.org and I could not boot
again because v2 bookmarks were on the boot pool.  I had to boot from
another disk, remove the bookmarks and then boot. This was on RELENG_13
(stable/13-c256203-g51d73a3e46c)

    ---Mike


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ZFS feature compatibility?

[mike tancsa]

I ran into an issue not being able to boot because of v2 bookmarks on
the boot pool on RELENG_13 just last Friday.

    ---Mike

On 1/25/2021 2:31 PM, Michael Butler via freebsd-current wrote:
> I have a few machines on which I've been hesitant to run 'zpool
> upgrade' as I'm not sure of the (boot?) implications. They report like
> this ..
>
> imb@toshi:/home/imb> uname -a
> FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD
> 14.0-CURRENT #25 main-eb61de5b78: Fri Jan 22 10:03:02 EST 2021
> r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI
>  amd64
>
> imb@toshi:/home/imb> zpool status
>   pool: zroot
>  state: ONLINE
> status: Some supported features are not enabled on the pool. The pool can
>     still be used, but some features are unavailable.
> action: Enable all features using 'zpool upgrade'. Once this is done,
>     the pool may no longer be accessible by software that does not
> support
>     the features. See zpool-features(5) for details.
>
> Is it safe to upgrade the root pool?
>
> imb
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org"
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Can In-Kernel TLS (kTLS) work with any OpenSSL Application?

[John Baldwin]

On 1/20/21 12:21 PM, Neel Chauhan wrote:

Hi freebsd-current@,

I know that In-Kernel TLS was merged into the FreeBSD HEAD tree a while
back.

With 13.0-RELEASE around the corner, I'm thinking about upgrading my
home server, well if I can accelerate any SSL application.

I'm asking because I have a home server on a symmetrical Gigabit
connection (Google Fiber/Webpass), and that server runs a Tor relay. If
you're interested in how Tor works, the EFF has a writeup:
https://www.eff.org/pages/what-tor-relay

But the main point for you all is: more-or-less Tor relays deal with
1000s TLS connections going into and out of the server.

Would In-Kernel TLS help with an application like Tor (or even load
balancers/TLS termination), or is it more for things like web servers
sending static files via sendfile() (e.g. CDN used by Netflix).


It depends.  Applications with allow OpenSSL to use a socket directly
(e.g. via SSL_set_fd() or via SSL_connect() or the like) will work with
kernel TLS transparently.  This includes things like apache, nginx,
fetch, wget, curl, etc.  However, some applications use OpenSSL purely
as a data transformation library and manage the socket I/O separately
(e.g. OpenVPN).  KTLS will not work with these applications since
OpenSSL doesn't "know" about the socket in question.


My server could also work with Intel's QuickAssist (since it has an
Intel Xeon "Scalable" CPU). Would QuickAssist SSL be more helpful here?


You can use this with ktls_ocf.ko and the qat(4) drivers.

I am working, btw, on merging KTLS into base OpenSSL and hope to have
it present in 13.0.

As you noted, applications would need to be changed to use SSL_sendfile()
to get the best performance on TX.  We don't really have an analog on
the receive side in our syscall API.  One might be able to do some
creative things with aio_read(4) perhaps, but I haven't implemented that.

Also, currently RX offload always returns individual records with the
full TLS header via recvmsg().  Linux's RX offload only includes the
message for non-application-data messages so that one could in theory
do bulk read(2) calls larger than a single TLS record.  OpenSSL itself
though always reads a single TLS record at a time, so if I were to change
this (e.g. with a new socket option to toggle headers for application
data), this would only be relevant to software that "knew" it was using
KTLS and would use direct read/write after letting OpenSSL (or a similar
library) handle the handshake.

--
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: 13-alpha2 libncurses removal breaks ports build

[Kostya Berger via freebsd-current]

Builds OK from inside clean install. Which is all I needed this far. Thank you.

With kindest regards,
Kostya Berger
 
 

On Sunday, 24 January 2021, 17:53:41 GMT+3, Kostya Berger 
 wrote:  
 
 OK, building ports against a clean installation of 13.0-ALPHA2 has no problem 
with ncurses. 
But devel/glib20 fails for no obvious reason closer to the end of building 
process... I just wonder: do I need to report this to port maintainers or wait 
till it settles up  somehow? A good deal of ports depend  on it.

With kindest regards,
Kostya Berger
 
 

On Sunday, 24 January 2021, 01:40:57 GMT+3, Kostya Berger 
 wrote:  
 
 Hi everyone,I don't seem to find any mentioning in the /usr/ports/UPDATING 
about how one should handle the removal of libncurses.so.9 from base. 
Source UPDATING only says:ncurses installation has been modified to only keep 
the widechar
    enabled version.  Incremental build is broken for that change, so it
    requires a clean build.
If that means to just build all ports anew, then it doesn't work as ports don't 
seem to incorporate any change related to this one. It would seem default 
configuration should take into account this, but it doesn't.

The ports just use --with-libncurses-prefix=/usr, and there is no ncurses libs 
found there. This make it skip MOST of the ports I'm using.

Working Copy Root Path: /usr/ports
URL: https://svn.freebsd.org/ports/head
Relative URL: ^/head
Repository Root: https://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 562417
Node Kind: directory
Schedule: normal
Last Changed Author: 0mp
Last Changed Rev: 562417
Last Changed Date: 2021-01-23 23:01:38 +0300 (Sat, 23 Jan 2021)

With kindest regards,
Kostya Berger
 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: using git to get a particular version of src

[Warner Losh]

On Mon, Jan 25, 2021 at 12:35 PM Warner Losh  wrote:

>
>
> On Mon, Jan 25, 2021 at 11:55 AM Warner Losh  wrote:
>
>>
>>
>> On Mon, Jan 25, 2021 at 11:11 AM Yasuhiro Kimura 
>> wrote:
>>
>>> From: Chris 
>>> Subject: Re: using git to get a particular version of src
>>> Date: Mon, 25 Jan 2021 09:21:44 -0800
>>>
>>> >> Hi,
>>> >> I have this version installed:
>>> >> 13.0-CURRENT #0 2ed50808d2b-c254384(main): Thu Nov 12 10:03:35 UTC
>>> >> 2020
>>> >> I'd like to get the sources for this (want to make a no-debug kernel)
>>> >> as I know
>>> >> this version works on this hardware.
>>> >> But -current has gone to 14 and what was -current is now
>>> >> 13-stable. What git
>>> >> incantation is required to get 2ed50808d2b-c254384 sources, given an
>>> >> empty
>>> >> /usr/src and git method of ssh://anon...@git.freebsd.org ?
>>> > I am by *no* means a GIT expert
>>> > but will
>>> > cd /usr/src
>>> > git up 2ed50808d2b
>>> > accomplish your intended task?
>>>
>>> Unfortunately it doesn't work as is expected in this case because hashes
>>> of src repostory changed on Dec 6 when it was still beta.
>>>
>>> HEADS UP: src hashes will respin/change this Sunday
>>> https://lists.freebsd.org/pipermail/freebsd-git/2020-December/000548.html
>>>
>>> In original case it was after this change so hash value can be used to
>>> checkout it. But this case is befere hash change. So there isn't hash
>>> 2ed50808d2b in current src repository any more.
>>>
>>> I also faced this problem when I tried to checkout source tree that
>>> corresponds to 20201119 snapshot of 13-CURRENT. Fortunately I still
>>> kept ISO image of it. So I did following steps to get the source tree.
>>>
>>> 1. Mount the ISO image
>>> 2. Extract src.txz in the ISO image to somewhere (e.g. /tmp/usr/src)
>>> 3. cd /usr
>>> 4. git clone https://git.freebsd.org/src.git
>>> 5. cd src
>>> 6. Checkout 65c207758a9 that was committed at Thu Nov 19 21:10:36
>>>2020 + (the last one committed on Nov 19, 2020)
>>> 7. diff -ru /tmp/usr/src /usr/src
>>> 8. If there are any differences, checkout f9fe7b28bc2 that is just
>>>previous commit of 65c207758a9
>>> 9. Repeat step 7 and 8 until there is no difference between
>>>/tmp/usr/src and /usr/src.
>>>
>>
>> We should see how hard it would be to convert c254384 into a git hash...
>>
>> So, for me:
>>
>> % git describe
>> vendor/tzdata/tzdata2020f-255971-gfa6662b3689e (so my tip of main is
>> 255971 vs 254384 or +1587)
>> % git log -1 main~1587
>> commit dda1987fe5dbf418b55195990896b0ef0a5b8e4a
>> Author: Mateusz Piotrowski <0...@freebsd.org>
>> Date:   Tue Nov 17 12:04:29 2020 +
>>
>> Add an example for the -s flag
>>
>> which is a little late. If you checked out the source and built it ASAP,
>> then I'd suggest:
>>
>> commit f14436adc61a52b29d035791c0b90c0b221bea9a
>> Author: Hans Petter Selasky 
>> Date:   Thu Nov 12 09:26:01 2020 +
>>
>> Add a tunable sysctl, hw.usb.uaudio.handle_hid, to allow disabling the
>> the HID volume keys support in the USB audio driver.
>>
>> which is the version just before that. Or if you installed from a
>> snapshot and rebuilt, The 20201112 snapshot was likely built from
>>
>> commit 38033780a3f4ed616d638fc0e9ef9a4d309f1fb3
>> Author: Kyle Evans 
>> Date:   Wed Nov 11 22:35:23 2020 +
>>
>> umtx: drop incorrect timespec32 definition
>>
>
> Oh! git describe is the wrong thing. We're using git rev-list --count, so:
>
> % git rev-list --count main
> 256115
> %  echo $((256115-254384)
> 1731
> % git log -1 main~1731
> git log -1 main~1731
> commit 94275e3e698b223ccc42e3a637b6667216ca6360
> Author: Mateusz Guzik 
> Date:   Tue Nov 10 01:31:06 2020 +
>
> threads: remove the unused TID_BUFFER_SIZE macro
>
> But, there's a problem, or a disconnect. git rev-list counts both the
> commits on main, and the number of commits for merge commits that are on
> the second parent back to the last common ancestor. this is surprising
> behavior, and we'll likely change it, but for systems before the change you
> need to do some searching:
>
> % git rev-list --count main~1731
> 254360
> % git rev-list --count main~1707
> 254384
>
> So this is the one you really want:
>
> commit 26007fe37c06fe0b61634083befb7f9eb87c08c0
> Author: Mateusz Guzik 
> Date:   Wed Nov 11 08:51:04 2020 +
>
> thread: add more fine-grained tidhash locking
>
> (that's assuming the commit counts from before the re-hashing were
> identical, which I have no way of knowing or testing).
>
> The truth is, though, any of these will likely be 'good enough' to have a
> working system.
>

P.S. Due to this mismatch, I'm going to propose we move to git rev-list
--first-parent  --count

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ZFS feature compatibility?

[Toomas Soome via freebsd-current]

> On 25. Jan 2021, at 21:31, Michael Butler via freebsd-current 
>  wrote:
> 
> I have a few machines on which I've been hesitant to run 'zpool upgrade' as 
> I'm not sure of the (boot?) implications. They report like this ..
> 
> imb@toshi:/home/imb> uname -a
> FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD 14.0-CURRENT 
> #25 main-eb61de5b78: Fri Jan 22 10:03:02 EST 2021 
> r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI
>   amd64
> 
> imb@toshi:/home/imb> zpool status
>  pool: zroot
> state: ONLINE
> status: Some supported features are not enabled on the pool. The pool can
>still be used, but some features are unavailable.
> action: Enable all features using 'zpool upgrade'. Once this is done,
>the pool may no longer be accessible by software that does not support
>the features. See zpool-features(5) for details.
> 
> Is it safe to upgrade the root pool?
> 
>   imb

We can not boot from encrypted pool and draid. Rest is all ok. Please note, you 
may need to update the bootblocks.

rgds,
toomas

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: service -e doesn't really sort does it? the cool tip is slightly off

[John Baldwin]

On 1/16/21 3:28 PM, Dennis Clarke wrote:

root@rhea:/usr/src/freebsd-src # diff -u
usr.bin/fortune/datfiles/freebsd-tips.orig
usr.bin/fortune/datfiles/freebsd-tips
--- usr.bin/fortune/datfiles/freebsd-tips.orig  2021-01-15
00:37:37.863506000 +
+++ usr.bin/fortune/datfiles/freebsd-tips   2021-01-16
07:46:57.335803000 +
@@ -517,7 +517,7 @@

 -- Lars Engels 
  %
-If you want to get a sorted list of all services that are started when
FreeBSD boots,
+If you want to get a list of all services that are started when FreeBSD
boots,
  enter "service -e".

 -- Lars Engels 
root@rhea:/usr/src/freebsd-src #

Sorry for being all OCD here. Perhaps it should say sorted in the order
in which they were started. Something like that.


I think the "sorted" detail is relevant, but describing the key (how it is
sorted) is certainly a missing detail, maybe:

If you want to get a list of all services started when FreeBSD boots
in the order they are started, enter "service-e".

?

--
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: using git to get a particular version of src

[Warner Losh]

On Mon, Jan 25, 2021 at 11:55 AM Warner Losh  wrote:

>
>
> On Mon, Jan 25, 2021 at 11:11 AM Yasuhiro Kimura  wrote:
>
>> From: Chris 
>> Subject: Re: using git to get a particular version of src
>> Date: Mon, 25 Jan 2021 09:21:44 -0800
>>
>> >> Hi,
>> >> I have this version installed:
>> >> 13.0-CURRENT #0 2ed50808d2b-c254384(main): Thu Nov 12 10:03:35 UTC
>> >> 2020
>> >> I'd like to get the sources for this (want to make a no-debug kernel)
>> >> as I know
>> >> this version works on this hardware.
>> >> But -current has gone to 14 and what was -current is now
>> >> 13-stable. What git
>> >> incantation is required to get 2ed50808d2b-c254384 sources, given an
>> >> empty
>> >> /usr/src and git method of ssh://anon...@git.freebsd.org ?
>> > I am by *no* means a GIT expert
>> > but will
>> > cd /usr/src
>> > git up 2ed50808d2b
>> > accomplish your intended task?
>>
>> Unfortunately it doesn't work as is expected in this case because hashes
>> of src repostory changed on Dec 6 when it was still beta.
>>
>> HEADS UP: src hashes will respin/change this Sunday
>> https://lists.freebsd.org/pipermail/freebsd-git/2020-December/000548.html
>>
>> In original case it was after this change so hash value can be used to
>> checkout it. But this case is befere hash change. So there isn't hash
>> 2ed50808d2b in current src repository any more.
>>
>> I also faced this problem when I tried to checkout source tree that
>> corresponds to 20201119 snapshot of 13-CURRENT. Fortunately I still
>> kept ISO image of it. So I did following steps to get the source tree.
>>
>> 1. Mount the ISO image
>> 2. Extract src.txz in the ISO image to somewhere (e.g. /tmp/usr/src)
>> 3. cd /usr
>> 4. git clone https://git.freebsd.org/src.git
>> 5. cd src
>> 6. Checkout 65c207758a9 that was committed at Thu Nov 19 21:10:36
>>2020 + (the last one committed on Nov 19, 2020)
>> 7. diff -ru /tmp/usr/src /usr/src
>> 8. If there are any differences, checkout f9fe7b28bc2 that is just
>>previous commit of 65c207758a9
>> 9. Repeat step 7 and 8 until there is no difference between
>>/tmp/usr/src and /usr/src.
>>
>
> We should see how hard it would be to convert c254384 into a git hash...
>
> So, for me:
>
> % git describe
> vendor/tzdata/tzdata2020f-255971-gfa6662b3689e (so my tip of main is
> 255971 vs 254384 or +1587)
> % git log -1 main~1587
> commit dda1987fe5dbf418b55195990896b0ef0a5b8e4a
> Author: Mateusz Piotrowski <0...@freebsd.org>
> Date:   Tue Nov 17 12:04:29 2020 +
>
> Add an example for the -s flag
>
> which is a little late. If you checked out the source and built it ASAP,
> then I'd suggest:
>
> commit f14436adc61a52b29d035791c0b90c0b221bea9a
> Author: Hans Petter Selasky 
> Date:   Thu Nov 12 09:26:01 2020 +
>
> Add a tunable sysctl, hw.usb.uaudio.handle_hid, to allow disabling the
> the HID volume keys support in the USB audio driver.
>
> which is the version just before that. Or if you installed from a snapshot
> and rebuilt, The 20201112 snapshot was likely built from
>
> commit 38033780a3f4ed616d638fc0e9ef9a4d309f1fb3
> Author: Kyle Evans 
> Date:   Wed Nov 11 22:35:23 2020 +
>
> umtx: drop incorrect timespec32 definition
>

Oh! git describe is the wrong thing. We're using git rev-list --count, so:

% git rev-list --count main
256115
%  echo $((256115-254384)
1731
% git log -1 main~1731
git log -1 main~1731
commit 94275e3e698b223ccc42e3a637b6667216ca6360
Author: Mateusz Guzik 
Date:   Tue Nov 10 01:31:06 2020 +

threads: remove the unused TID_BUFFER_SIZE macro

But, there's a problem, or a disconnect. git rev-list counts both the
commits on main, and the number of commits for merge commits that are on
the second parent back to the last common ancestor. this is surprising
behavior, and we'll likely change it, but for systems before the change you
need to do some searching:

% git rev-list --count main~1731
254360
% git rev-list --count main~1707
254384

So this is the one you really want:

commit 26007fe37c06fe0b61634083befb7f9eb87c08c0
Author: Mateusz Guzik 
Date:   Wed Nov 11 08:51:04 2020 +

thread: add more fine-grained tidhash locking

(that's assuming the commit counts from before the re-hashing were
identical, which I have no way of knowing or testing).

The truth is, though, any of these will likely be 'good enough' to have a
working system.

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

ZFS feature compatibility?

[Michael Butler via freebsd-current]

I have a few machines on which I've been hesitant to run 'zpool upgrade' 
as I'm not sure of the (boot?) implications. They report like this ..


imb@toshi:/home/imb> uname -a
FreeBSD toshi.auburn.protected-networks.net 14.0-CURRENT FreeBSD 
14.0-CURRENT #25 main-eb61de5b78: Fri Jan 22 10:03:02 EST 2021 
r...@toshi.auburn.protected-networks.net:/usr/obj/usr/src/amd64.amd64/sys/TOSHI 
 amd64


imb@toshi:/home/imb> zpool status
  pool: zroot
 state: ONLINE
status: Some supported features are not enabled on the pool. The pool can
still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
the pool may no longer be accessible by software that does not 
support

the features. See zpool-features(5) for details.

Is it safe to upgrade the root pool?

imb
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Re: Files in /usr/share/misc

[mj-mailinglist]

Thank you all for the input.

So, this directory is a little bit like the bottom drawer on my desk, where i 
put things, i don't know where to put else :)


the hier man page states:
misc/   miscellaneous system-wide ASCII text files

About half of the files are ASCII text, according to the file command.
The others are UTF-8, ISO-8859 or even binary. There seems a little bit of 
divergence from the "text" :)

--
Martin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: using git to get a particular version of src

[Warner Losh]

On Mon, Jan 25, 2021 at 11:11 AM Yasuhiro Kimura  wrote:

> From: Chris 
> Subject: Re: using git to get a particular version of src
> Date: Mon, 25 Jan 2021 09:21:44 -0800
>
> >> Hi,
> >> I have this version installed:
> >> 13.0-CURRENT #0 2ed50808d2b-c254384(main): Thu Nov 12 10:03:35 UTC
> >> 2020
> >> I'd like to get the sources for this (want to make a no-debug kernel)
> >> as I know
> >> this version works on this hardware.
> >> But -current has gone to 14 and what was -current is now
> >> 13-stable. What git
> >> incantation is required to get 2ed50808d2b-c254384 sources, given an
> >> empty
> >> /usr/src and git method of ssh://anon...@git.freebsd.org ?
> > I am by *no* means a GIT expert
> > but will
> > cd /usr/src
> > git up 2ed50808d2b
> > accomplish your intended task?
>
> Unfortunately it doesn't work as is expected in this case because hashes
> of src repostory changed on Dec 6 when it was still beta.
>
> HEADS UP: src hashes will respin/change this Sunday
> https://lists.freebsd.org/pipermail/freebsd-git/2020-December/000548.html
>
> In original case it was after this change so hash value can be used to
> checkout it. But this case is befere hash change. So there isn't hash
> 2ed50808d2b in current src repository any more.
>
> I also faced this problem when I tried to checkout source tree that
> corresponds to 20201119 snapshot of 13-CURRENT. Fortunately I still
> kept ISO image of it. So I did following steps to get the source tree.
>
> 1. Mount the ISO image
> 2. Extract src.txz in the ISO image to somewhere (e.g. /tmp/usr/src)
> 3. cd /usr
> 4. git clone https://git.freebsd.org/src.git
> 5. cd src
> 6. Checkout 65c207758a9 that was committed at Thu Nov 19 21:10:36
>2020 + (the last one committed on Nov 19, 2020)
> 7. diff -ru /tmp/usr/src /usr/src
> 8. If there are any differences, checkout f9fe7b28bc2 that is just
>previous commit of 65c207758a9
> 9. Repeat step 7 and 8 until there is no difference between
>/tmp/usr/src and /usr/src.
>

We should see how hard it would be to convert c254384 into a git hash...

So, for me:

% git describe
vendor/tzdata/tzdata2020f-255971-gfa6662b3689e (so my tip of main is 255971
vs 254384 or +1587)
% git log -1 main~1587
commit dda1987fe5dbf418b55195990896b0ef0a5b8e4a
Author: Mateusz Piotrowski <0...@freebsd.org>
Date:   Tue Nov 17 12:04:29 2020 +

Add an example for the -s flag

which is a little late. If you checked out the source and built it ASAP,
then I'd suggest:

commit f14436adc61a52b29d035791c0b90c0b221bea9a
Author: Hans Petter Selasky 
Date:   Thu Nov 12 09:26:01 2020 +

Add a tunable sysctl, hw.usb.uaudio.handle_hid, to allow disabling the
the HID volume keys support in the USB audio driver.

which is the version just before that. Or if you installed from a snapshot
and rebuilt, The 20201112 snapshot was likely built from

commit 38033780a3f4ed616d638fc0e9ef9a4d309f1fb3
Author: Kyle Evans 
Date:   Wed Nov 11 22:35:23 2020 +

umtx: drop incorrect timespec32 definition

Warner
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: using git to get a particular version of src

[Yasuhiro Kimura]

From: Chris 
Subject: Re: using git to get a particular version of src
Date: Mon, 25 Jan 2021 09:21:44 -0800

>> Hi,
>> I have this version installed:
>> 13.0-CURRENT #0 2ed50808d2b-c254384(main): Thu Nov 12 10:03:35 UTC
>> 2020
>> I'd like to get the sources for this (want to make a no-debug kernel)
>> as I know
>> this version works on this hardware.
>> But -current has gone to 14 and what was -current is now
>> 13-stable. What git
>> incantation is required to get 2ed50808d2b-c254384 sources, given an
>> empty
>> /usr/src and git method of ssh://anon...@git.freebsd.org ?
> I am by *no* means a GIT expert
> but will
> cd /usr/src
> git up 2ed50808d2b
> accomplish your intended task?

Unfortunately it doesn't work as is expected in this case because hashes
of src repostory changed on Dec 6 when it was still beta.

HEADS UP: src hashes will respin/change this Sunday
https://lists.freebsd.org/pipermail/freebsd-git/2020-December/000548.html

In original case it was after this change so hash value can be used to
checkout it. But this case is befere hash change. So there isn't hash
2ed50808d2b in current src repository any more.

I also faced this problem when I tried to checkout source tree that
corresponds to 20201119 snapshot of 13-CURRENT. Fortunately I still
kept ISO image of it. So I did following steps to get the source tree.

1. Mount the ISO image
2. Extract src.txz in the ISO image to somewhere (e.g. /tmp/usr/src)
3. cd /usr
4. git clone https://git.freebsd.org/src.git
5. cd src
6. Checkout 65c207758a9 that was committed at Thu Nov 19 21:10:36
   2020 + (the last one committed on Nov 19, 2020)
7. diff -ru /tmp/usr/src /usr/src
8. If there are any differences, checkout f9fe7b28bc2 that is just
   previous commit of 65c207758a9
9. Repeat step 7 and 8 until there is no difference between
   /tmp/usr/src and /usr/src.

---
Yasuhiro Kimura
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: using git to get a particular version of src

[Chris]

On 2021-01-25 08:31, tech-lists wrote:

Hi,

I have this version installed:

13.0-CURRENT #0 2ed50808d2b-c254384(main): Thu Nov 12 10:03:35 UTC 2020

I'd like to get the sources for this (want to make a no-debug kernel) as I 
know

this version works on this hardware.

But -current has gone to 14 and what was -current is now 13-stable. What git
incantation is required to get 2ed50808d2b-c254384 sources, given an empty
/usr/src and git method of ssh://anon...@git.freebsd.org ?

I am by *no* means a GIT expert
but will
cd /usr/src
git up 2ed50808d2b
accomplish your intended task?

HTH


thanks,

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: using git to get a particular version of src

[tech-lists]

On Mon, Jan 25, 2021 at 04:31:13PM +, tech-lists wrote:

Hi,

I have this version installed:

13.0-CURRENT #0 2ed50808d2b-c254384(main): Thu Nov 12 10:03:35 UTC 2020

I'd like to get the sources for this (want to make a no-debug kernel) as I know
this version works on this hardware.

But -current has gone to 14 and what was -current is now 13-stable. What git
incantation is required to get 2ed50808d2b-c254384 sources, given an empty
/usr/src and git method of ssh://anon...@git.freebsd.org ?


OOPS sorry seems this exact same q was asked/answered earlier, pls ignore

thanks
--
J.


signature.asc
Description: PGP signature

using git to get a particular version of src

[tech-lists]

Hi,

I have this version installed:

13.0-CURRENT #0 2ed50808d2b-c254384(main): Thu Nov 12 10:03:35 UTC 2020

I'd like to get the sources for this (want to make a no-debug kernel) as I know 
this version works on this hardware. 

But -current has gone to 14 and what was -current is now 13-stable. What git 
incantation is required to get 2ed50808d2b-c254384 sources, given an empty 
/usr/src and git method of ssh://anon...@git.freebsd.org ?


thanks,
--
J.


signature.asc
Description: PGP signature

Re: loading drm crashes system

[Niclas Zeising]

On 2021-01-25 00:19, Robert Huff wrote:


Hello:
On a system now running:

14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-d6327ae8c1: Sun Jan 24
14:16:54 EST 2021 amd64

(src+ports updated at midnight US EST)
with PORTS_MODULES="drm-current-kmod gpu-firmware-kmod", starting
the system _without_ loading drm results in a usable system.
Loading drm - whether via kldlist in rc.conf or by kldload at the
console immediately after start-up - instantly crashes the system; the
screen goes blank and the lights on the monitor report no signal
from the system.


[snip error log]



[insert image of open jaw and glassy-eyed stare]
The GPU is a Radeon HD 3300, and at one point this used to work.
Help, please?



When did it stop working?
Which version of drm-current-kmod?
Can you try to remove it and build it directly from an updated ports 
tree, without using PORTS_MODULES=, and see if that helps?

Regards
--
Niclas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Can In-Kernel TLS (kTLS) work with any OpenSSL Application?

[Rick Macklem]

Benjamin Kaduk wrote:
>On Sat, Jan 23, 2021 at 03:25:59PM +, Rick Macklem wrote:
>> Ronald Klop wrote:
>> >On Wed, 20 Jan 2021 21:21:15 +0100, Neel Chauhan  wrote:
>> >But I think for Tor to support KTLS it needs to implement some things
>> >itself. More information about that could be asked at the maintainer of
>> >the port (https://www.freshports.org/security/tor/) or upstream at the Tor
>> >project.
>> To just make it work, I don't think changes are needed beyond linking to
>> the correct OpenSSL libraries (assuming it uses OpenSSL, of course).
>> (There are new library calls an application can use to check to see if
>> KTLS is enabled for the connection, but if it doesn't care, I don't think
>> those calls are needed?)
>>
>> You do need to run a kernel with "options KERN_TLS" and set
>> kern.ipc.tls.enable=1
>> kern.ipc.mb_use_ext_pgs=1
>
>Note that upstream openssl is expecting to change in what ways ktls is
>(en/dis)abled by default; see
>https://github.com/openssl/openssl/issues/13794
Thanks for the pointer Ben.
It appears that
SSL_CTX_clear_mode(ctx, SSL_MODE_NO_KTLS_TX | SSL_MODE_NO_KTLS_RX)
or similar will soon be needed to enable it.
I'll add this call to the nfs-over-tls daemons, since it should be harmless to 
do.

Thanks for mentioning this, rick

-Ben
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Poudriere failed to build pkg in 13-stable jail under 12-stable

[Baptiste Daroussin]

On Mon, Jan 25, 2021 at 12:46:43PM +0800, Thomas Legg wrote:
> The build of a 13-stable source and kernel were a success under 12-stable
> (though with some issues on freeze-ups and hard reboots that I suspect
> might be related to the bufdaemon issue and my 0x15 gen AMD cpu).
> 
> Created a 13-stable poudriere jail with the knowledge that there may be
> issues with builds under a 12-stable r369076 kernel. I didn't expect this
> failure on packaging pkg.
> 
> > Compressing man pages (compress-man)
> ===>   Installing ldconfig configuration file
> ===
> ===
> ===>  Building package for pkg-1.16.2
> cp: /wrkdirs/usr/ports/ports-mgmt/pkg/work/pkg/pkg-1.16.2.txz: Function not
> implemented
> *** Error code 1
> 

cp on head and 13 is using copy_file_range(2), introduced in 13-CURRENT
recentish, this is what is failing here.

Best regards,
Bapt


signature.asc
Description: PGP signature

Poudriere failed to build pkg in 13-stable jail under 12-stable

[Thomas Legg]

The build of a 13-stable source and kernel were a success under 12-stable
(though with some issues on freeze-ups and hard reboots that I suspect
might be related to the bufdaemon issue and my 0x15 gen AMD cpu).

Created a 13-stable poudriere jail with the knowledge that there may be
issues with builds under a 12-stable r369076 kernel. I didn't expect this
failure on packaging pkg.

> Compressing man pages (compress-man)
===>   Installing ldconfig configuration file
===
===
===>  Building package for pkg-1.16.2
cp: /wrkdirs/usr/ports/ports-mgmt/pkg/work/pkg/pkg-1.16.2.txz: Function not
implemented
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/ports-mgmt/pkg
*** Error code 1

Stop.
make: stopped in /usr/ports/ports-mgmt/pkg
=>> Cleaning up wrkdir
===>  Cleaning for pkg-1.16.2
build of ports-mgmt/pkg | pkg-1.16.2 ended at Mon Jan 25 12:16:12 HKT 2021
build time: 00:02:01
!!! build failure encountered !!!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

13.0-CURRENT r368448 panic

[Sergey V. Dyatko]

Hi,

Some time ago I was writting about this kernel panic. But due to the fact that
there was very little information I haven't receive any reply (I hope that is
was a reason). Luckily I have a host with a single interface (w/o lagg) and
I was able to set up netdump.
I observe this panic on all servers running this revision.

More information:

GNU gdb (GDB) 9.2 [GDB v9.2 for FreeBSD]
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd13.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./kernel.debug...

Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 04
fault virtual address   = 0x18
fault code  = supervisor read data, page not present
instruction pointer = 0x20:0x80c8b3c8
stack pointer   = 0x28:0xfe019b3302e0
frame pointer   = 0x28:0xfe019b330350
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (if_io_tqg_2)
trap number = 12
panic: page fault
cpuid = 2
time = 1611366676
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe019b32ff90
vpanic() at vpanic+0x181/frame 0xfe019b32ffe0
panic() at panic+0x43/frame 0xfe019b330040
trap_fatal() at trap_fatal+0x387/frame 0xfe019b3300a0
trap_pfault() at trap_pfault+0x4f/frame 0xfe019b330100
trap() at trap+0x27d/frame 0xfe019b330210
calltrap() at calltrap+0x8/frame 0xfe019b330210
--- trap 0xc, rip = 0x80c8b3c8, rsp = 0xfe019b3302e0, rbp = 
0xfe019b330350 ---
m_copydata() at m_copydata+0x58/frame 0xfe019b330350
tcp_output() at tcp_output+0x100b/frame 0xfe019b3304f0
tcp_do_segment() at tcp_do_segment+0x2867/frame 0xfe019b3305e0
tcp_input() at tcp_input+0xabe/frame 0xfe019b330710
ip_input() at ip_input+0x125/frame 0xfe019b3307a0
netisr_dispatch_src() at netisr_dispatch_src+0xca/frame 0xfe019b3307f0
ether_demux() at ether_demux+0x138/frame 0xfe019b330820
ether_nh_input() at ether_nh_input+0x351/frame 0xfe019b330880
netisr_dispatch_src() at netisr_dispatch_src+0xca/frame 0xfe019b3308d0
ether_input() at ether_input+0x69/frame 0xfe019b330930
tcp_flush_out_le() at tcp_flush_out_le+0x221/frame 0xfe019b330950
tcp_lro_flush() at tcp_lro_flush+0x2b2/frame 0xfe019b330980
tcp_lro_flush_all() at tcp_lro_flush_all+0x13b/frame 0xfe019b3309c0
iflib_rxeof() at iflib_rxeof+0xc7a/frame 0xfe019b330ac0
_task_fn_rx() at _task_fn_rx+0x72/frame 0xfe019b330b00
gtaskqueue_run_locked() at gtaskqueue_run_locked+0x15d/frame 0xfe019b330b80
gtaskqueue_thread_loop() at gtaskqueue_thread_loop+0xac/frame 0xfe019b330bb0
fork_exit() at fork_exit+0x7e/frame 0xfe019b330bf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe019b330bf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
Uptime: 2d11h32m6s
debugnet: overwriting mbuf zone pointers
debugnet_connect: searching for gateway MAC...
netdumping to 212.8.xx.yy (48:5b:39:09:5b:8e)
Dumping 9708 out of 130919 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55  __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct 
pcpu,
(kgdb) bt
#0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:399
#2  0x80bf87bb in kern_reboot (howto=260) at 
/usr/src/sys/kern/kern_shutdown.c:486
#3  0x80bf8c40 in vpanic (fmt=, ap=) at 
/usr/src/sys/kern/kern_shutdown.c:919
#4  0x80bf8a43 in panic (fmt=) at 
/usr/src/sys/kern/kern_shutdown.c:843
#5  0x8102cf17 in trap_fatal (frame=0xfe019b330220, eva=24) at 
/usr/src/sys/amd64/amd64/trap.c:915
#6  0x8102cf6f in trap_pfault (frame=0xfe019b330220, 
usermode=, signo=, ucode=) at 
/usr/src/sys/amd64/amd64/trap.c:732
#7  0x8102c5cd in trap (frame=0xfe019b330220) at 
/usr/src/sys/amd64/amd64/trap.c:398
#8  
#9  m_copydata (m=0x0, off=0, len=1, cp=) at 
/usr/src/sys/kern/uipc_mbuf.c:656
#10 0x80db9fab in tcp_output (tp=0xfe05449d48f0) at 
/usr/src/sys/netinet/tcp_output.c:1065
#11 0x80db1fd7 in tcp_do_segment (m=0xf802150f8100, th=, so=, tp=0xfe05449d48f0,