From grahamperrin at gmail.com  Tue Dec  1 07:04:29 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Tue, 1 Dec 2020 07:04:22 +0000
Subject: Microsoft Teams with Linuxulator
Message-ID: <7bc9e4b3-8e4a-ae19-74b6-5d74747e5684@gmail.com>

 From <https://redd.it/k4fba9>:

----

I have Teams 1.3.00.25560 at /compat/ubuntu/usr/bin/teams

When run, it seems to get no further than this (from htop):

?
PID USER????? PRI? NI? VIRT?? RES S CPU% MEM%?? TIME+? Command
 ??? 0 root????? -16?? 0???? 0? 6416 S? 5.4? 0.0? 1h08:14 kernel
 ??? 1 root?????? 52?? 0 11928?? 124 S? 0.0? 0.0? 0:00.09 ?? init
99908 grahamper? 20?? 0 2193M? 115M S? 0.0? 0.7? 0:04.46??? ?? teams
99924 grahamper? 20?? 0? 911M 93160 S? 0.0? 0.6? 0:00.29??? ?? ?? Watchdog
99909 grahamper? 52?? 0? 356M 41936 S? 0.0? 0.3? 0:00.08??? ?? ?? teams 
--type=zygote --no-sandbox
?

? and later:

?
99908 grahamper? 20?? 0 2193M? 115M S? 0.0? 0.7? 0:04.68??? ?? teams
99924 grahamper? 20?? 0? 911M 93160 S? 0.0? 0.6? 0:00.29??? ?? ?? 
Chrome_ChildIOT
99909 grahamper? 52?? 0? 356M 41936 S? 0.0? 0.3? 0:00.08??? ?? ?? teams 
--type=zygote --no-sandbox
?

? no GUI.

Any suggestions?

TIA

From freebsd at omnilan.de  Tue Dec  1 08:43:41 2020
From: freebsd at omnilan.de (Harry Schmalzbauer)
Date: Tue, 1 Dec 2020 09:43:26 +0100
Subject: rc.d/zpool runs before ada(4) attaches
Message-ID: <b55604d6-5c23-a590-859c-a52f36386d44@omnilan.de>

Hello,? I'm playing with HEAD (post r364746, Merge OpenZFS support in to 
HEAD) on some of my non-out-of-box setups.


One machine fails importing zpool because the correponding vdevs (ada0-ada2)
are not available at the time rc.d/zpool runs.


Adhoc? I'm not aware of any rc(8) vs. driver awareness.
Is there any?

Suggestions how to fix else than 'sleep 1'?

Thanks,

-harry

P.S.: ahci(4) is compiled into kernel, machine is a HPE U48 (Gen 10 plus 
MicroServer), zfsloader loads root_MFS kernel module


From ronald-lists at klop.ws  Tue Dec  1 09:33:33 2020
From: ronald-lists at klop.ws (Ronald Klop)
Date: Tue, 1 Dec 2020 10:33:26 +0100 (CET)
Subject: rc.d/zpool runs before ada(4) attaches
In-Reply-To: <b55604d6-5c23-a590-859c-a52f36386d44@omnilan.de>
References: <b55604d6-5c23-a590-859c-a52f36386d44@omnilan.de>
Message-ID: <1439301337.11.1606815206810@localhost>

 
Van: Harry Schmalzbauer <freebsd at omnilan.de>
Datum: dinsdag, 1 december 2020 09:43
Aan: freebsd-current at freebsd.org
Onderwerp: rc.d/zpool runs before ada(4) attaches
> 
> Hello,  I'm playing with HEAD (post r364746, Merge OpenZFS support in to HEAD) on some of my non-out-of-box setups.
> 
> 
> One machine fails importing zpool because the correponding vdevs (ada0-ada2)
> are not available at the time rc.d/zpool runs.
> 
> 
> Adhoc  I'm not aware of any rc(8) vs. driver awareness.
> Is there any?
> 
> Suggestions how to fix else than 'sleep 1'?
> 
> Thanks,
> 
> -harry
> 
> P.S.: ahci(4) is compiled into kernel, machine is a HPE U48 (Gen 10 plus MicroServer), zfsloader loads root_MFS kernel module
>  


There have been some changes to etc/rc.d/zpool in September.
Do you have the latest version? Compare with:
https://github.com/freebsd/freebsd/blob/master/libexec/rc/rc.d/zpool
or
https://svnweb.freebsd.org/base/head/libexec/rc/rc.d/zpool?revision=365354&view=markup

Otherwise it would be helpful for readers if you could post some logs which indicate what is happening.
/var/run/dmesg.boot or the output of "dmesg"
Part of /var/log/messages
Part of /var/log/console.log if it exists.

Regards,
Ronald.
 

From cglogic at protonmail.com  Tue Dec  1 11:14:33 2020
From: cglogic at protonmail.com (cglogic)
Date: Tue, 01 Dec 2020 11:14:24 +0000
Subject: pam_zfs_key
Message-ID: <3w4nMQm06IvdFCRTkIZ2qXRp_tj6yYhMxPua6tZSEcn4OyznSL3PEUdXNpcZNFWmt227e1OOhKNzmx4jUIdJzIqFFvCd8PlnwD47i3l31Fo=@protonmail.com>

Hi there!

Is pam_zfs_key available in 13-CURRENT? I want to setup automatically loading zfs encryption keys for home datasets.

Thanks!

From freebsd at omnilan.de  Tue Dec  1 11:51:26 2020
From: freebsd at omnilan.de (Harry Schmalzbauer)
Date: Tue, 1 Dec 2020 12:51:21 +0100
Subject: rc.d/zpool runs before ada(4) attaches
In-Reply-To: <1439301337.11.1606815206810@localhost>
References: <b55604d6-5c23-a590-859c-a52f36386d44@omnilan.de>
 <1439301337.11.1606815206810@localhost>
Message-ID: <08815f92-742c-2934-e746-fd04ca9b4e16@omnilan.de>

Am 01.12.2020 um 10:33 schrieb Ronald Klop:
:
:
:
>> One machine fails importing zpool because the correponding vdevs 
>> (ada0-ada2)
>> are not available at the time rc.d/zpool runs.
>>
>>
>> Adhoc? I'm not aware of any rc(8) vs. driver awareness.
>> Is there any?
>>
>> Suggestions how to fix else than 'sleep 1'?
>>
>> Thanks,
>>
>> -harry
>>
>> P.S.: ahci(4) is compiled into kernel, machine is a HPE U48 (Gen 10 
>> plus MicroServer), zfsloader loads root_MFS kernel module
>>
>
>
> There have been some changes to etc/rc.d/zpool in September.
> Do you have the latest version? Compare with:
> https://github.com/freebsd/freebsd/blob/master/libexec/rc/rc.d/zpool
> or
> https://svnweb.freebsd.org/base/head/libexec/rc/rc.d/zpool?revision=365354&view=markup 
>
>
> Otherwise it would be helpful for readers if you could post some logs 
> which indicate what is happening.
> /var/run/dmesg.boot or the output of "dmesg"
> Part of /var/log/messages
> Part of /var/log/console.log if it exists.
>

Thanks, I'm on -current from view days ago.
The problem is that cam(4) is still probing devices, when rc.d/zpool 
runs, since mount_root_from succeeded, because it is a RAM disk, so 
succeeds independent of any real drive/controller probing.
I can imagine of other seldom edgecases hitting the issue too.

So my proposed patch, working for me, looks like this:
Index: libexec/rc/rc.d/zpool
===================================================================
--- libexec/rc/rc.d/zpool?????? (revision 368202)
+++ libexec/rc/rc.d/zpool?????? (working copy)
@@ -18,8 +18,16 @@

 ?zpool_start()
 ?{
-?????? local cachefile
+??????? local cachefile n=0 camlist=`camcontrol devlist -v`

+?????? # Wait for cam(4) devices attaching, 4 times at max by increasing
+?????? # 1s each (10s max in total)
+??????? while [ X"${camlist#*target*lun*probe}" != X"${camlist}" ]; do
+?????????????? [ $n -lt 4 ] || break
+?????????????? sleep $((n+=1))
+?????????????? camlist=`camcontrol devlist -v`
+?????? done
+
 ??????? for cachefile in /etc/zfs/zpool.cache /boot/zfs/zpool.cache; do
 ??????????????? if [ -r $cachefile ]; then
 ??????????????????????? zpool import -c $cachefile -a -N && break

best,
-harry

From ali.abdallah at suse.com  Tue Dec  1 13:14:34 2020
From: ali.abdallah at suse.com (Ali Abdallah)
Date: Tue, 1 Dec 2020 14:14:30 +0100
Subject: Issues with USB-C external monitors
Message-ID: <20201201131430.ol7pzms24h743iwf@frix230>

Hello,

I have a T495 with a USB-C docking station with two external monitors,
running current to get the vega 10 amdgpu to work.

When the power is lost for on the USB-C dock, then the X server looses
all external monitors. They appear as disconnected after running xrandr
and I cannot figure out a way to bring them back without killing my
current session and start X again, but that is very annoying...

I tried to debug the issue and I'm pretty sure that the X server on
FreeBSD is not reconfiguring the drm connectors automatically.

Let's say I have DP-4 as external connector, when the power is lost,
DP-4 disappears, when the power is back, DP-4 re-appear again but in
unknown status.

$ sysctl sys.class.drm | grep DP-4
sys.class.drm.card0-DP-4.modes:
sys.class.drm.card0-DP-4.dpms: Off
sys.class.drm.card0-DP-4.enabled: disabled
sys.class.drm.card0-DP-4.status: unknown

Now just running a simple libdrm code to rescan the connectors:

__snippet__
res = drmModeGetResources(fd);
for (int i = 0; i < res->count_connectors; ++i) {
   conn = drmModeGetConnector(fd, res->connectors[i]);

After running the above code, the drm stack is somehow triggered to
re-read the DP-4.status, which appears now to be connected, but not
configured.

$ sysctl sys.class.drm | grep DP-4
sys.class.drm.card0-DP-4.modes: 1920x1080
sys.class.drm.card0-DP-4.dpms: Off
sys.class.drm.card0-DP-4.enabled: disabled
sys.class.drm.card0-DP-4.status: connected

I didn't dig further to see if I can trigger the X server to re-scan drm
connectors and eventually remove those that vanished, and add newly
detected connectors. On Linux that seems to work automatically.

Any thoughts?

Regards,
Ali.

From hps at selasky.org  Tue Dec  1 14:01:09 2020
From: hps at selasky.org (Hans Petter Selasky)
Date: Tue, 1 Dec 2020 15:00:55 +0100
Subject: Issues with USB-C external monitors
In-Reply-To: <20201201131430.ol7pzms24h743iwf@frix230>
References: <20201201131430.ol7pzms24h743iwf@frix230>
Message-ID: <342519ee-6f73-98be-29b1-cea7890ccb1e@selasky.org>

On 12/1/20 2:14 PM, Ali Abdallah wrote:
> Hello,
> 
> I have a T495 with a USB-C docking station with two external monitors,
> running current to get the vega 10 amdgpu to work.
> 
> When the power is lost for on the USB-C dock, then the X server looses
> all external monitors. They appear as disconnected after running xrandr
> and I cannot figure out a way to bring them back without killing my
> current session and start X again, but that is very annoying...
> 
> I tried to debug the issue and I'm pretty sure that the X server on
> FreeBSD is not reconfiguring the drm connectors automatically.
> 
> Let's say I have DP-4 as external connector, when the power is lost,
> DP-4 disappears, when the power is back, DP-4 re-appear again but in
> unknown status.
> 
> $ sysctl sys.class.drm | grep DP-4
> sys.class.drm.card0-DP-4.modes:
> sys.class.drm.card0-DP-4.dpms: Off
> sys.class.drm.card0-DP-4.enabled: disabled
> sys.class.drm.card0-DP-4.status: unknown
> 
> Now just running a simple libdrm code to rescan the connectors:
> 
> __snippet__
> res = drmModeGetResources(fd);
> for (int i = 0; i < res->count_connectors; ++i) {
>     conn = drmModeGetConnector(fd, res->connectors[i]);
> 
> After running the above code, the drm stack is somehow triggered to
> re-read the DP-4.status, which appears now to be connected, but not
> configured.
> 
> $ sysctl sys.class.drm | grep DP-4
> sys.class.drm.card0-DP-4.modes: 1920x1080
> sys.class.drm.card0-DP-4.dpms: Off
> sys.class.drm.card0-DP-4.enabled: disabled
> sys.class.drm.card0-DP-4.status: connected
> 
> I didn't dig further to see if I can trigger the X server to re-scan drm
> connectors and eventually remove those that vanished, and add newly
> detected connectors. On Linux that seems to work automatically.
> 
> Any thoughts?

There is missing code in the kernel to handle USB-C PCI express 
attach/detach. CC'ing Scott Long.

--HPS

From ronald-lists at klop.ws  Tue Dec  1 15:22:16 2020
From: ronald-lists at klop.ws (Ronald Klop)
Date: Tue, 1 Dec 2020 16:22:10 +0100 (CET)
Subject: rc.d/zpool runs before ada(4) attaches
In-Reply-To: <08815f92-742c-2934-e746-fd04ca9b4e16@omnilan.de>
References: <b55604d6-5c23-a590-859c-a52f36386d44@omnilan.de>
 <1439301337.11.1606815206810@localhost>
 <08815f92-742c-2934-e746-fd04ca9b4e16@omnilan.de>
Message-ID: <286917313.21.1606836130991@localhost>

 
Van: Harry Schmalzbauer <freebsd at omnilan.de>
Datum: dinsdag, 1 december 2020 12:51
Aan: Ronald Klop <ronald-lists at klop.ws>, FreeBSD Current <freebsd-current at freebsd.org>
Onderwerp: Re: rc.d/zpool runs before ada(4) attaches
> 
> Am 01.12.2020 um 10:33 schrieb Ronald Klop:
> :
> :
> :
> >> One machine fails importing zpool because the correponding vdevs >> (ada0-ada2)
> >> are not available at the time rc.d/zpool runs.
> >>
> >>
> >> Adhoc  I'm not aware of any rc(8) vs. driver awareness.
> >> Is there any?
> >>
> >> Suggestions how to fix else than 'sleep 1'?
> >>
> >> Thanks,
> >>
> >> -harry
> >>
> >> P.S.: ahci(4) is compiled into kernel, machine is a HPE U48 (Gen 10 >> plus MicroServer), zfsloader loads root_MFS kernel module
> >>
> >
> >
> > There have been some changes to etc/rc.d/zpool in September.
> > Do you have the latest version? Compare with:
> > https://github.com/freebsd/freebsd/blob/master/libexec/rc/rc.d/zpool
> > or
> > https://svnweb.freebsd.org/base/head/libexec/rc/rc.d/zpool?revision=365354&view=markup >
> >
> > Otherwise it would be helpful for readers if you could post some logs > which indicate what is happening.
> > /var/run/dmesg.boot or the output of "dmesg"
> > Part of /var/log/messages
> > Part of /var/log/console.log if it exists.
> >
> 
> Thanks, I'm on -current from view days ago.
> The problem is that cam(4) is still probing devices, when rc.d/zpool runs, since mount_root_from succeeded, because it is a RAM disk, so succeeds independent of any real drive/controller probing.
> I can imagine of other seldom edgecases hitting the issue too.
> 
> So my proposed patch, working for me, looks like this:
> Index: libexec/rc/rc.d/zpool
> ===================================================================
> --- libexec/rc/rc.d/zpool       (revision 368202)
> +++ libexec/rc/rc.d/zpool       (working copy)
> @@ -18,8 +18,16 @@
> 
>   zpool_start()
>   {
> -       local cachefile
> +        local cachefile n=0 camlist=`camcontrol devlist -v`
> 
> +       # Wait for cam(4) devices attaching, 4 times at max by increasing
> +       # 1s each (10s max in total)
> +        while [ X"${camlist#*target*lun*probe}" != X"${camlist}" ]; do
> +               [ $n -lt 4 ] || break
> +               sleep $((n+=1))
> +               camlist=`camcontrol devlist -v`
> +       done
> +
>          for cachefile in /etc/zfs/zpool.cache /boot/zfs/zpool.cache; do
>                  if [ -r $cachefile ]; then
>                          zpool import -c $cachefile -a -N && break
> 
> best,
> -harry
> 
> 
> 

You can define these in /boot/loader.conf:
#kern.cam.boot_delay="10000" # Delay (in ms) of root mount for CAM bus
#kern.cam.scsi_delay="2000" # Delay (in ms) before probing SCSI

Maybe that helps.

Ronald.
 

From ian at freebsd.org  Tue Dec  1 15:34:39 2020
From: ian at freebsd.org (Ian Lepore)
Date: Tue, 01 Dec 2020 08:34:33 -0700
Subject: rc.d/zpool runs before ada(4) attaches
In-Reply-To: <286917313.21.1606836130991@localhost>
References: <b55604d6-5c23-a590-859c-a52f36386d44@omnilan.de>
 <1439301337.11.1606815206810@localhost>
 <08815f92-742c-2934-e746-fd04ca9b4e16@omnilan.de>
 <286917313.21.1606836130991@localhost>
Message-ID: <786faeee90e79aa0175b298ec859265ff57a3129.camel@freebsd.org>

On Tue, 2020-12-01 at 16:22 +0100, Ronald Klop wrote:
>  
> Van: Harry Schmalzbauer <freebsd at omnilan.de>
> Datum: dinsdag, 1 december 2020 12:51
> Aan: Ronald Klop <ronald-lists at klop.ws>, FreeBSD Current <
> freebsd-current at freebsd.org>
> Onderwerp: Re: rc.d/zpool runs before ada(4) attaches
> > 
> > Am 01.12.2020 um 10:33 schrieb Ronald Klop:
> > :
> > :
> > :
> > > > One machine fails importing zpool because the correponding
> > > > vdevs >> (ada0-ada2)
> > > > are not available at the time rc.d/zpool runs.
> > > > 
> > > > 
> > > > Adhoc  I'm not aware of any rc(8) vs. driver awareness.
> > > > Is there any?
> > > > 
> > > > Suggestions how to fix else than 'sleep 1'?
> > > > 
> > > > Thanks,
> > > > 
> > > > -harry
> > > > 
> > > > P.S.: ahci(4) is compiled into kernel, machine is a HPE U48
> > > > (Gen 10 >> plus MicroServer), zfsloader loads root_MFS kernel
> > > > module
> > > > 
> > > 
> > > 
> > > There have been some changes to etc/rc.d/zpool in September.
> > > Do you have the latest version? Compare with:
> > > 
https://github.com/freebsd/freebsd/blob/master/libexec/rc/rc.d/zpool
> > > or
> > > 
https://svnweb.freebsd.org/base/head/libexec/rc/rc.d/zpool?revision=365354&view=markup
> > >  >
> > > 
> > > Otherwise it would be helpful for readers if you could post some
> > > logs > which indicate what is happening.
> > > /var/run/dmesg.boot or the output of "dmesg"
> > > Part of /var/log/messages
> > > Part of /var/log/console.log if it exists.
> > > 
> > 
> > Thanks, I'm on -current from view days ago.
> > The problem is that cam(4) is still probing devices, when
> > rc.d/zpool runs, since mount_root_from succeeded, because it is a
> > RAM disk, so succeeds independent of any real drive/controller
> > probing.
> > I can imagine of other seldom edgecases hitting the issue too.
> > 
> > So my proposed patch, working for me, looks like this:
> > Index: libexec/rc/rc.d/zpool
> > ===================================================================
> > --- libexec/rc/rc.d/zpool       (revision 368202)
> > +++ libexec/rc/rc.d/zpool       (working copy)
> > @@ -18,8 +18,16 @@
> > 
> >   zpool_start()
> >   {
> > -       local cachefile
> > +        local cachefile n=0 camlist=`camcontrol devlist -v`
> > 
> > +       # Wait for cam(4) devices attaching, 4 times at max by
> > increasing
> > +       # 1s each (10s max in total)
> > +        while [ X"${camlist#*target*lun*probe}" != X"${camlist}"
> > ]; do
> > +               [ $n -lt 4 ] || break
> > +               sleep $((n+=1))
> > +               camlist=`camcontrol devlist -v`
> > +       done
> > +
> >          for cachefile in /etc/zfs/zpool.cache
> > /boot/zfs/zpool.cache; do
> >                  if [ -r $cachefile ]; then
> >                          zpool import -c $cachefile -a -N && break
> > 
> > best,
> > -harry
> > 
> > 
> > 
> 
> You can define these in /boot/loader.conf:
> #kern.cam.boot_delay="10000" # Delay (in ms) of root mount for CAM
> bus
> #kern.cam.scsi_delay="2000" # Delay (in ms) before probing SCSI
> 
> Maybe that helps.
> 
> Ronald.
> 

Those settings control waiting before mounting root.  Harry's problem
is that root is mounted quickly, before other drives are ready for zfs.
 
The zpool script waits for 'disks'.  It would be nice if the cam
subsystem had something like a sysctl it set to indicate when initial
probing for disks was done, then there could be an rc.d/camprobe script
with 'PROVIDE: disks' which waits for the probing to complete.

-- Ian



From ronald-lists at klop.ws  Tue Dec  1 15:47:09 2020
From: ronald-lists at klop.ws (Ronald Klop)
Date: Tue, 1 Dec 2020 16:47:04 +0100 (CET)
Subject: rc.d/zpool runs before ada(4) attaches
In-Reply-To: <786faeee90e79aa0175b298ec859265ff57a3129.camel@freebsd.org>
References: <b55604d6-5c23-a590-859c-a52f36386d44@omnilan.de>
 <1439301337.11.1606815206810@localhost>
 <08815f92-742c-2934-e746-fd04ca9b4e16@omnilan.de>
 <286917313.21.1606836130991@localhost>
 <786faeee90e79aa0175b298ec859265ff57a3129.camel@freebsd.org>
Message-ID: <657848968.24.1606837624286@localhost>

 
Van: Ian Lepore <ian at freebsd.org>
Datum: dinsdag, 1 december 2020 16:34
Aan: Ronald Klop <ronald-lists at klop.ws>, FreeBSD Current <freebsd-current at freebsd.org>
Onderwerp: Re: rc.d/zpool runs before ada(4) attaches
> 
> On Tue, 2020-12-01 at 16:22 +0100, Ronald Klop wrote:
> >  
> > Van: Harry Schmalzbauer <freebsd at omnilan.de>
> > Datum: dinsdag, 1 december 2020 12:51
> > Aan: Ronald Klop <ronald-lists at klop.ws>, FreeBSD Current <
> > freebsd-current at freebsd.org>
> > Onderwerp: Re: rc.d/zpool runs before ada(4) attaches
> > >
> > > Am 01.12.2020 um 10:33 schrieb Ronald Klop:
> > > :
> > > :
> > > :
> > > > > One machine fails importing zpool because the correponding
> > > > > vdevs >> (ada0-ada2)
> > > > > are not available at the time rc.d/zpool runs.
> > > > >
> > > > >
> > > > > Adhoc  I'm not aware of any rc(8) vs. driver awareness.
> > > > > Is there any?
> > > > >
> > > > > Suggestions how to fix else than 'sleep 1'?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > -harry
> > > > >
> > > > > P.S.: ahci(4) is compiled into kernel, machine is a HPE U48
> > > > > (Gen 10 >> plus MicroServer), zfsloader loads root_MFS kernel
> > > > > module
> > > > >
> > > >
> > > >
> > > > There have been some changes to etc/rc.d/zpool in September.
> > > > Do you have the latest version? Compare with:
> > > >
> https://github.com/freebsd/freebsd/blob/master/libexec/rc/rc.d/zpool
> > > > or
> > > >
> https://svnweb.freebsd.org/base/head/libexec/rc/rc.d/zpool?revision=365354&view=markup
> > > >  >
> > > >
> > > > Otherwise it would be helpful for readers if you could post some
> > > > logs > which indicate what is happening.
> > > > /var/run/dmesg.boot or the output of "dmesg"
> > > > Part of /var/log/messages
> > > > Part of /var/log/console.log if it exists.
> > > >
> > >
> > > Thanks, I'm on -current from view days ago.
> > > The problem is that cam(4) is still probing devices, when
> > > rc.d/zpool runs, since mount_root_from succeeded, because it is a
> > > RAM disk, so succeeds independent of any real drive/controller
> > > probing.
> > > I can imagine of other seldom edgecases hitting the issue too.
> > >
> > > So my proposed patch, working for me, looks like this:
> > > Index: libexec/rc/rc.d/zpool
> > > ===================================================================
> > > --- libexec/rc/rc.d/zpool       (revision 368202)
> > > +++ libexec/rc/rc.d/zpool       (working copy)
> > > @@ -18,8 +18,16 @@
> > >
> > >   zpool_start()
> > >   {
> > > -       local cachefile
> > > +        local cachefile n=0 camlist=`camcontrol devlist -v`
> > >
> > > +       # Wait for cam(4) devices attaching, 4 times at max by
> > > increasing
> > > +       # 1s each (10s max in total)
> > > +        while [ X"${camlist#*target*lun*probe}" != X"${camlist}"
> > > ]; do
> > > +               [ $n -lt 4 ] || break
> > > +               sleep $((n+=1))
> > > +               camlist=`camcontrol devlist -v`
> > > +       done
> > > +
> > >          for cachefile in /etc/zfs/zpool.cache
> > > /boot/zfs/zpool.cache; do
> > >                  if [ -r $cachefile ]; then
> > >                          zpool import -c $cachefile -a -N && break
> > >
> > > best,
> > > -harry
> > >
> > >
> > >
> >
> > You can define these in /boot/loader.conf:
> > #kern.cam.boot_delay="10000" # Delay (in ms) of root mount for CAM
> > bus
> > #kern.cam.scsi_delay="2000" # Delay (in ms) before probing SCSI
> >
> > Maybe that helps.
> >
> > Ronald.
> >
> 
> Those settings control waiting before mounting root.  Harry's problem
> is that root is mounted quickly, before other drives are ready for zfs.
>  
> The zpool script waits for 'disks'.  It would be nice if the cam
> subsystem had something like a sysctl it set to indicate when initial
> probing for disks was done, then there could be an rc.d/camprobe script
> with 'PROVIDE: disks' which waits for the probing to complete.
> 
> -- Ian
> 
>  
> 
> 
> 

Or a devd event "ada-arrived" which calls rc.d/zpool.
It sounds a bit like we need systemd. :-)

Ronald.
 

From greg at unrelenting.technology  Tue Dec  1 17:10:23 2020
From: greg at unrelenting.technology (myfreeweb)
Date: Tue, 01 Dec 2020 17:10:17 +0000
Subject: Issues with USB-C external monitors
In-Reply-To: <342519ee-6f73-98be-29b1-cea7890ccb1e@selasky.org>
References: <20201201131430.ol7pzms24h743iwf@frix230>
 <342519ee-6f73-98be-29b1-cea7890ccb1e@selasky.org>
Message-ID: <BD186C8D-AF73-4182-BF89-89005854F618@unrelenting.technology>



On December 1, 2020 2:00:55 PM UTC, Hans Petter Selasky <hps at selasky.org> wrote:
>On 12/1/20 2:14 PM, Ali Abdallah wrote:
>> Hello,
>> 
>> I have a T495 with a USB-C docking station with two external monitors,
>> running current to get the vega 10 amdgpu to work.
>> 
>> When the power is lost for on the USB-C dock, then the X server looses
>> all external monitors. They appear as disconnected after running xrandr
>> and I cannot figure out a way to bring them back without killing my
>> current session and start X again, but that is very annoying...
>> 
>> I tried to debug the issue and I'm pretty sure that the X server on
>> FreeBSD is not reconfiguring the drm connectors automatically.
>> 
>> Let's say I have DP-4 as external connector, when the power is lost,
>> DP-4 disappears, when the power is back, DP-4 re-appear again but in
>> unknown status.
>> 
>> $ sysctl sys.class.drm | grep DP-4
>> sys.class.drm.card0-DP-4.modes:
>> sys.class.drm.card0-DP-4.dpms: Off
>> sys.class.drm.card0-DP-4.enabled: disabled
>> sys.class.drm.card0-DP-4.status: unknown
>> 
>> Now just running a simple libdrm code to rescan the connectors:
>> 
>> __snippet__
>> res = drmModeGetResources(fd);
>> for (int i = 0; i < res->count_connectors; ++i) {
>>     conn = drmModeGetConnector(fd, res->connectors[i]);

Note: you can run graphics/drm_info instead of writing custom code.

>> After running the above code, the drm stack is somehow triggered to
>> re-read the DP-4.status, which appears now to be connected, but not
>> configured.
>> 
>> $ sysctl sys.class.drm | grep DP-4
>> sys.class.drm.card0-DP-4.modes: 1920x1080
>> sys.class.drm.card0-DP-4.dpms: Off
>> sys.class.drm.card0-DP-4.enabled: disabled
>> sys.class.drm.card0-DP-4.status: connected
>> 
>> I didn't dig further to see if I can trigger the X server to re-scan drm
>> connectors and eventually remove those that vanished, and add newly
>> detected connectors. On Linux that seems to work automatically.
>> 
>> Any thoughts?

devd (really drm in the kernel) provides hotplug events (system DRM, type HOTPLUG).
libudev-devd translates these to UD_ACTION_HOTPLUG.
This works well with wlroots compositors at least.
How xorg does this I have no idea, as I don't use xorg.
If your xorg is built with DEVD instead of UDEV option, it shouldn't work, I don't recall anyone adding support for that there.
With UDEV it might work?

>There is missing code in the kernel to handle USB-C PCI express 
>attach/detach. CC'ing Scott Long.

Seems like this is about regular DisplayPort over USB-C (the USB side almost always handled in firmware for this on non-embedded computers).
I don't think I've ever seen a *monitor* connecting over PCIe to an existing GPU ;)
(in this case card0, the onboard vega)

From ali.abdallah at suse.com  Tue Dec  1 17:32:27 2020
From: ali.abdallah at suse.com (Ali Abdallah)
Date: Tue, 1 Dec 2020 18:32:23 +0100
Subject: Issues with USB-C external monitors
In-Reply-To: <BD186C8D-AF73-4182-BF89-89005854F618@unrelenting.technology>
References: <20201201131430.ol7pzms24h743iwf@frix230>
 <342519ee-6f73-98be-29b1-cea7890ccb1e@selasky.org>
 <BD186C8D-AF73-4182-BF89-89005854F618@unrelenting.technology>
Message-ID: <20201201173223.mwmrkogcjmtc4k2j@frix230>

On 01.12.2020 17:10, myfreeweb wrote:
> >> __snippet__
> >> res = drmModeGetResources(fd);
> >> for (int i = 0; i < res->count_connectors; ++i) {
> >>     conn = drmModeGetConnector(fd, res->connectors[i]);
>
> Note: you can run graphics/drm_info instead of writing custom code.

Thanks for the tip.

> devd (really drm in the kernel) provides hotplug events (system DRM, type HOTPLUG).
> libudev-devd translates these to UD_ACTION_HOTPLUG.
> This works well with wlroots compositors at least.
>
> How xorg does this I have no idea, as I don't use xorg.
> If your xorg is built with DEVD instead of UDEV option, it shouldn't work, I don't recall anyone adding support for that there.
> With UDEV it might work?

On current, for now I'm using the standard xorg-server from pkg, built
with UDEV according to [1], so apparently that is not working either. At
least in my case.

Will dig futher into it.

>
> >There is missing code in the kernel to handle USB-C PCI express
> >attach/detach. CC'ing Scott Long.
>
> Seems like this is about regular DisplayPort over USB-C (the USB side almost always handled in firmware for this on non-embedded computers).
> I don't think I've ever seen a *monitor* connecting over PCIe to an existing GPU ;)
> (in this case card0, the onboard vega)

Yes, this is just the DisplayPort over USB-C from the onboard vega GPU.

[1] https://www.freshports.org/x11-servers/xorg-server/



From scottl at samsco.org  Tue Dec  1 18:08:31 2020
From: scottl at samsco.org (Scott Long)
Date: Tue, 1 Dec 2020 11:08:23 -0700
Subject: Issues with USB-C external monitors
In-Reply-To: <20201201173223.mwmrkogcjmtc4k2j@frix230>
References: <20201201131430.ol7pzms24h743iwf@frix230>
 <342519ee-6f73-98be-29b1-cea7890ccb1e@selasky.org>
 <BD186C8D-AF73-4182-BF89-89005854F618@unrelenting.technology>
 <20201201173223.mwmrkogcjmtc4k2j@frix230>
Message-ID: <68205920-BE4F-460D-BF70-1A84FE3BC536@samsco.org>


> On Dec 1, 2020, at 10:32 AM, Ali Abdallah <ali.abdallah at suse.com> wrote:
> 
> On 01.12.2020 17:10, myfreeweb wrote:
>>>> __snippet__
>>>> res = drmModeGetResources(fd);
>>>> for (int i = 0; i < res->count_connectors; ++i) {
>>>>    conn = drmModeGetConnector(fd, res->connectors[i]);
>> 
>> Note: you can run graphics/drm_info instead of writing custom code.
> 
> Thanks for the tip.
> 
>> devd (really drm in the kernel) provides hotplug events (system DRM, type HOTPLUG).
>> libudev-devd translates these to UD_ACTION_HOTPLUG.
>> This works well with wlroots compositors at least.
>> 
>> How xorg does this I have no idea, as I don't use xorg.
>> If your xorg is built with DEVD instead of UDEV option, it shouldn't work, I don't recall anyone adding support for that there.
>> With UDEV it might work?
> 
> On current, for now I'm using the standard xorg-server from pkg, built
> with UDEV according to [1], so apparently that is not working either. At
> least in my case.
> 
> Will dig futher into it.
> 
>> 
>>> There is missing code in the kernel to handle USB-C PCI express
>>> attach/detach. CC'ing Scott Long.
>> 
>> Seems like this is about regular DisplayPort over USB-C (the USB side almost always handled in firmware for this on non-embedded computers).
>> I don't think I've ever seen a *monitor* connecting over PCIe to an existing GPU ;)
>> (in this case card0, the onboard vega)
> 
> Yes, this is just the DisplayPort over USB-C from the onboard vega GPU.
> 
> [1] https://www.freshports.org/x11-servers/xorg-server/
> 
> 

I have a work-in-progress to support Thunderbolt, but that?s not always the same as just DisplayPort-over-USBC.  If your connector has the Thunderbolt logo, then it?s Thunderbolt, if it has the DP logo then it?s not.  Even then, the Thunderbolt component only controls enable/disable permissions and bandwidth partitioning.  The graphics chip and DRM code does the rest of the work, and it sounds like the problems here are with those components.

Scott


From haramrae at gmail.com  Tue Dec  1 19:42:46 2020
From: haramrae at gmail.com (Alban Hertroys)
Date: Tue, 1 Dec 2020 20:42:41 +0100
Subject: KLD zfs.ko: depends on kernel - not available or version mismatch
Message-ID: <5C36F5ED-D643-4A65-92CA-D6FB9008C908@gmail.com>

I?ve been trying to get a fresh world running (for the eventual purpose of running amdgpu against my recent graphics adapter), but I run into trouble with core loadable kernel modules, such as zfs.ko from the subject. It also happens with other modules that I tried randomly, for example, geom_mirror.ko.

I updated to the latest current using svn up in /usr/src, then:
	make clean
	make buildworld kernel -j12
	shutdown -r now

boot to single user mode

	kldload zfs

Which results in dmesg messages:

KLD zfs.ko: depends on kernel - not available or version mismatch
linker_load_file: /boot/kernel/zfs.ko - unsupported file type
KLD zfs.ko: depends on kernel - not available or version mismatch
linker_load_file: /boot/kernel/zfs.ko - unsupported file type
KLD zfs.ko: depends on kernel - not available or version mismatch
linker_load_file: /boot/kernel/zfs.ko - unsupported file type
KLD zfs.ko: depends on kernel - not available or version mismatch
linker_load_file: /boot/kernel/zfs.ko - unsupported file type


I can load the zfs kernel module from kernel.old just fine:

ZFS filesystem version: 5
ZFS storage pool version: features support (5000)


This happens with any kernel module I?ve tried, such as geom_mirror and amdgpu (from ports/graphics/drm-current-kmod - the latter causes a kernel panic with kernel.old BTW).

I?ve gone back as far as Oct 7 (before changes to kern/elf_load_obj.c off the top of my head), looked at mailing list archives and forums etc, all to no avail.

I have / on UFS+J and /usr on ZFS and nothing in /etc/src.conf. I had /etc/malloc.conf with the recommended symlink from UPDATING, but the same happens with that moved out of the way. Nothing seems to help.

Do I need to go back further to get into a usable state or is there something else I should be doing?

Regards,
Alban Hertroys
--
There is always an exception to always.





From tech-lists at zyxst.net  Tue Dec  1 20:24:03 2020
From: tech-lists at zyxst.net (tech-lists)
Date: Tue, 1 Dec 2020 20:23:58 +0000
Subject: rc.d/zpool runs before ada(4) attaches
In-Reply-To: <786faeee90e79aa0175b298ec859265ff57a3129.camel@freebsd.org>
References: <b55604d6-5c23-a590-859c-a52f36386d44@omnilan.de>
 <1439301337.11.1606815206810@localhost>
 <08815f92-742c-2934-e746-fd04ca9b4e16@omnilan.de>
 <286917313.21.1606836130991@localhost>
 <786faeee90e79aa0175b298ec859265ff57a3129.camel@freebsd.org>
Message-ID: <X8amXv2L66HQC8mS@rpi4.local>

On Tue, Dec 01, 2020 at 08:34:33AM -0700, Ian Lepore wrote:
>On Tue, 2020-12-01 at 16:22 +0100, Ronald Klop wrote:
>>
>> You can define these in /boot/loader.conf:
>> #kern.cam.boot_delay="10000" # Delay (in ms) of root mount for CAM
>> bus
>> #kern.cam.scsi_delay="2000" # Delay (in ms) before probing SCSI
>>
>> Maybe that helps.
>>
>> Ronald.
>>
>
>Those settings control waiting before mounting root.  Harry's problem
>is that root is mounted quickly, before other drives are ready for zfs.
>
>The zpool script waits for 'disks'.  It would be nice if the cam
>subsystem had something like a sysctl it set to indicate when initial
>probing for disks was done, then there could be an rc.d/camprobe script
>with 'PROVIDE: disks' which waits for the probing to complete.
>
>-- Ian

kern.cam.boot_delay should still fix it because what is required is a delay
while the devices (all of the disks, zfs or not) get ready. Because root 
has to happen before disks/zfs. 
-- 
J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20201201/7821c9da/attachment.sig>

From phk at phk.freebsd.dk  Tue Dec  1 20:34:08 2020
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Tue, 01 Dec 2020 20:33:57 +0000
Subject: Issues with USB-C external monitors
In-Reply-To: <68205920-BE4F-460D-BF70-1A84FE3BC536@samsco.org>
References: <20201201131430.ol7pzms24h743iwf@frix230>
 <342519ee-6f73-98be-29b1-cea7890ccb1e@selasky.org>
 <BD186C8D-AF73-4182-BF89-89005854F618@unrelenting.technology>
 <20201201173223.mwmrkogcjmtc4k2j@frix230>
 <68205920-BE4F-460D-BF70-1A84FE3BC536@samsco.org>
Message-ID: <5381.1606854837@critter.freebsd.dk>

--------

When I last tried this on my T480/T3-Dock/xorg, the screen comes back, but
xrandr shows it with ever increasing names "DP-3", "DP-4" etc.

For now I've given up and use the T480's HDMI output instead.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at 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.

From osidorkin at gmail.com  Tue Dec  1 20:47:36 2020
From: osidorkin at gmail.com (Oleg Sidorkin)
Date: Tue, 1 Dec 2020 23:47:23 +0300
Subject: rc.d/zpool runs before ada(4) attaches
In-Reply-To: <X8amXv2L66HQC8mS@rpi4.local>
References: <b55604d6-5c23-a590-859c-a52f36386d44@omnilan.de>
 <1439301337.11.1606815206810@localhost>
 <08815f92-742c-2934-e746-fd04ca9b4e16@omnilan.de>
 <286917313.21.1606836130991@localhost>
 <786faeee90e79aa0175b298ec859265ff57a3129.camel@freebsd.org>
 <X8amXv2L66HQC8mS@rpi4.local>
Message-ID: <CAGw+upK=G68MehBU5Q5i9K0tXdcJ8yp+0ereTbf3TmJgXk0uGQ@mail.gmail.com>

Tue, 1 Dec. 2020 ?. ? 23:24, tech-lists <tech-lists at zyxst.net>:
>
> On Tue, Dec 01, 2020 at 08:34:33AM -0700, Ian Lepore wrote:
> >On Tue, 2020-12-01 at 16:22 +0100, Ronald Klop wrote:
> >>
> >> You can define these in /boot/loader.conf:
> >> #kern.cam.boot_delay="10000" # Delay (in ms) of root mount for CAM
> >> bus
> >> #kern.cam.scsi_delay="2000" # Delay (in ms) before probing SCSI
> >>
> >> Maybe that helps.
> >>
> >> Ronald.
> >>
> >
> >Those settings control waiting before mounting root.  Harry's problem
> >is that root is mounted quickly, before other drives are ready for zfs.
> >
> >The zpool script waits for 'disks'.  It would be nice if the cam
> >subsystem had something like a sysctl it set to indicate when initial
> >probing for disks was done, then there could be an rc.d/camprobe script
> >with 'PROVIDE: disks' which waits for the probing to complete.
> >
> >-- Ian
>
> kern.cam.boot_delay should still fix it because what is required is a delay
> while the devices (all of the disks, zfs or not) get ready. Because root
> has to happen before disks/zfs.
> --
> J.

I've reported a similar problem here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242189 some time
ago.
I just added the patch that solves it for me by delaying startup until
CAM and USB scan is complete (that's overkill probably).


-- 
Oleg Sidorkin

From ali.abdallah at suse.com  Wed Dec  2 07:00:15 2020
From: ali.abdallah at suse.com (Ali Abdallah)
Date: Wed, 2 Dec 2020 08:00:11 +0100
Subject: Issues with USB-C external monitors
In-Reply-To: <68205920-BE4F-460D-BF70-1A84FE3BC536@samsco.org>
References: <20201201131430.ol7pzms24h743iwf@frix230>
 <342519ee-6f73-98be-29b1-cea7890ccb1e@selasky.org>
 <BD186C8D-AF73-4182-BF89-89005854F618@unrelenting.technology>
 <20201201173223.mwmrkogcjmtc4k2j@frix230>
 <68205920-BE4F-460D-BF70-1A84FE3BC536@samsco.org>
Message-ID: <20201202070011.amdv7hxpq52x7zjw@frix230>

On 01.12.2020 11:08, Scott Long wrote:
> I have a work-in-progress to support Thunderbolt, but that?s not always the same as just DisplayPort-over-USBC.  If your connector has the Thunderbolt logo, then it?s Thunderbolt, if it has the DP logo then it?s not.  Even then, the Thunderbolt component only controls enable/disable permissions and bandwidth partitioning.  The graphics chip and DRM code does the rest of the work, and it sounds like the problems here are with those components.

T495 has AMD Ryzen silicon, and AMD never associated Thunderbolt with
its Ryzen platforms. The dock connector is just a USB-C.

On dock removal, the devd events (system DRM, type HOTPLUG) are
correctly generated and received by libudev-devd, but then for some
reason UD_ACTION_HOTPLUG is not causing the X server to re-scan drm
connectors and to re-configure them.

Will dig further into the issue as I feel it should be easy to solve.

> 
> Scott
> 

Ali

From ali.abdallah at suse.com  Wed Dec  2 07:08:26 2020
From: ali.abdallah at suse.com (Ali Abdallah)
Date: Wed, 2 Dec 2020 08:08:24 +0100
Subject: Issues with USB-C external monitors
In-Reply-To: <5381.1606854837@critter.freebsd.dk>
References: <20201201131430.ol7pzms24h743iwf@frix230>
 <342519ee-6f73-98be-29b1-cea7890ccb1e@selasky.org>
 <BD186C8D-AF73-4182-BF89-89005854F618@unrelenting.technology>
 <20201201173223.mwmrkogcjmtc4k2j@frix230>
 <68205920-BE4F-460D-BF70-1A84FE3BC536@samsco.org>
 <5381.1606854837@critter.freebsd.dk>
Message-ID: <20201202070824.pqorztnkkbxmbbox@frix230>

On 01.12.2020 20:33, Poul-Henning Kamp wrote:
> --------
> 
> When I last tried this on my T480/T3-Dock/xorg, the screen comes back, but
> xrandr shows it with ever increasing names "DP-3", "DP-4" etc.
> 
> For now I've given up and use the T480's HDMI output instead.

I've noticed that as well, the sys.class.drm.card0-DP-3 disappears and
sys.class.drm.card0-DP-4 is created instead.

I need to drive two external monitors, that's why I need the external dock.


From ali.abdallah at suse.com  Wed Dec  2 10:28:46 2020
From: ali.abdallah at suse.com (Ali Abdallah)
Date: Wed, 2 Dec 2020 11:28:41 +0100
Subject: Issues with USB-C external monitors
In-Reply-To: <BD186C8D-AF73-4182-BF89-89005854F618@unrelenting.technology>
References: <20201201131430.ol7pzms24h743iwf@frix230>
 <342519ee-6f73-98be-29b1-cea7890ccb1e@selasky.org>
 <BD186C8D-AF73-4182-BF89-89005854F618@unrelenting.technology>
Message-ID: <20201202102841.ysv52uc6oseuurwh@frix230>

On 01.12.2020 17:10, myfreeweb wrote:
> devd (really drm in the kernel) provides hotplug events (system DRM, type HOTPLUG).
> libudev-devd translates these to UD_ACTION_HOTPLUG.
> This works well with wlroots compositors at least.
> How xorg does this I have no idea, as I don't use xorg.
> If your xorg is built with DEVD instead of UDEV option, it shouldn't work, I don't recall anyone adding support for that there.
> With UDEV it might work?

Actually Xorg on FreeBSD with UDEV is compiled with
--disable-config-udev-kms, thus the server never calls:

udev_monitor_filter_add_match_subsystem_devtype

for GPU devices, and thus libudev-devd doesn't forward kms events to the
server. Actually Xorg doesn't even process them, even if the filter check
is bypassed in libudev-devd (udev-monitor.c:261).

Basically Xorg is missing bsd platform code for drm devices, on Linux
the code that implements that can be found in:
hw/xfree86/os-support/linux/lnx_platform.c

Compiling the server with --enable-config-udev-kms, the server expects
to have the following functions implemented

xf86PlatformReprobeDevice, xf86PlatformDeviceProbe, DeleteGPUDeviceRequest and
xf86PlatformDeviceCheckBusID.

Those are fairly easy to implement to enable Xorg to listen to
libudev-devd drm events and to re-configure the drm connectors. I have
already some scratch code, will test more and probably send upstream.

I will probably also add devd code for that, as I use xorg server
with devd on my FreeBSD 12.x machines.

Thanks,
Ali

From markj at freebsd.org  Wed Dec  2 16:52:24 2020
From: markj at freebsd.org (Mark Johnston)
Date: Wed, 2 Dec 2020 11:52:18 -0500
Subject: dtrace: give %'d a chance?
In-Reply-To: <5b87b1af-2c19-7f41-60f0-1e578c72e17d@FreeBSD.org>
References: <d832ce96-c7a9-7aac-b761-27522a02d0ef@FreeBSD.org>
 <X7aH5suHtYUsNq0x@raichu>
 <5b87b1af-2c19-7f41-60f0-1e578c72e17d@FreeBSD.org>
Message-ID: <X8fGQnn2uJ43RsNP@raichu>

On Mon, Nov 30, 2020 at 03:50:53PM +0200, Andriy Gapon wrote:
> On 19/11/2020 16:57, Mark Johnston wrote:
> > On Thu, Nov 19, 2020 at 01:28:56PM +0200, Andriy Gapon wrote:
> >>
> >> what do people think about adding
> >>     setlocale(LC_NUMERIC, "");
> >> to dtrace's main function?
> > 
> > That seems reasonable to me.
> > 
> >> My primary interest is to (pretty-)print some numbers with a thousands separator.
> >>
> >> Not sure if any other LC_ types are worth bothering.
> > 
> > Maybe LC_TIME?  libdtrace a couple of date formatters, %T and %Y.  A
> > locale-aware formatter might be worth having.
> 
> FWIW, I've just discovered that despite what
> http://dtrace.org/guide/chp-fmt.html says about %Y its output is not dependent
> on locale settings.
> A quick look at the code confirms that -- pfprint_time uses ctime_r.
> But %T (undocumented at the above link) indeed depends on LC_TIME as
> pfprint_time822 uses strftime("%a, %d %b %G %T %Z").
> 
> Sample output in C locale:
> 10000000
> Mon, 30 Nov 2020 13:47:24 UTC
> 2020 Nov 30 13:47:24
> 
> The same formats (%'d, %T, %Y) in uk_UA locale:
> 10?000?000
> ??, 30 ????. 2020 13:43:11 UTC
> 2020 Nov 30 13:43:11

So to be clear, there is nothing that needs to be done for time locales?

In any case, I'm fine with adding the %'d formatter.

From emaste at freebsd.org  Wed Dec  2 17:44:00 2020
From: emaste at freebsd.org (Ed Maste)
Date: Wed, 2 Dec 2020 12:43:46 -0500
Subject: Removing obsolete GDB 6.1.1 for FreeBSD 13
Message-ID: <CAPyFy2AxAycToQxTgGq+WMfED1UiRGgPzox6c8A49P6gErgwJw@mail.gmail.com>

We currently have an obsolete version of GDB 6.1 installed as
/usr/libexec/gdb, kept only for use by crashinfo(8), which extracts
some basic information from a kernel core dump after a crash. If the
gdb port is installed crashinfo will use that in preference to
/usr/libexec/gdb. If neither exists it will not perform any analysis,
reporting "Unable to find a kernel debugger."

GDB 6.1.1 was released in June 2004 and is long obsolete. It does not
support all of the architectures that FreeBSD does, and imposes
limitations on the FreeBSD kernel build - the continued use of DWARF2.

I would like to remove GDB 6.1.1 before FreeBSD 13, and propose to
switch the GDB knob to default to NO in the near future. If the
crashinfo utility and related man pages do not already include
references to installing the gdb port/package I will add those before
making the change.

In the fullness of time we may use LLDB to extract the same
information, or provide other tooling to do so, but I do not want to
block GDB 6.1.1's removal on this.

Please let me know of any objections or comments.

From imp at bsdimp.com  Wed Dec  2 17:52:38 2020
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 2 Dec 2020 10:52:24 -0700
Subject: Removing obsolete GDB 6.1.1 for FreeBSD 13
In-Reply-To: <CAPyFy2AxAycToQxTgGq+WMfED1UiRGgPzox6c8A49P6gErgwJw@mail.gmail.com>
References: <CAPyFy2AxAycToQxTgGq+WMfED1UiRGgPzox6c8A49P6gErgwJw@mail.gmail.com>
Message-ID: <CANCZdfqGKVkrGY-K4Pt-vm=ih1Y_P2J2n_5qPqZzBdt29--SSA@mail.gmail.com>

On Wed, Dec 2, 2020 at 10:44 AM Ed Maste <emaste at freebsd.org> wrote:

> We currently have an obsolete version of GDB 6.1 installed as
> /usr/libexec/gdb, kept only for use by crashinfo(8), which extracts
> some basic information from a kernel core dump after a crash. If the
> gdb port is installed crashinfo will use that in preference to
> /usr/libexec/gdb. If neither exists it will not perform any analysis,
> reporting "Unable to find a kernel debugger."
>
> GDB 6.1.1 was released in June 2004 and is long obsolete. It does not
> support all of the architectures that FreeBSD does, and imposes
> limitations on the FreeBSD kernel build - the continued use of DWARF2.
>
> I would like to remove GDB 6.1.1 before FreeBSD 13, and propose to
> switch the GDB knob to default to NO in the near future. If the
> crashinfo utility and related man pages do not already include
> references to installing the gdb port/package I will add those before
> making the change.
>
> In the fullness of time we may use LLDB to extract the same
> information, or provide other tooling to do so, but I do not want to
> block GDB 6.1.1's removal on this.
>
> Please let me know of any objections or comments.
>

I fully support this action. We kept gdb on board for 12 (and 11?) for
crashinfo as a transition to the new gdb port and to help smooth over bumps
from moving kgdb support into that port. jhb@ has done a great job in
getting kgdb moved into the port. I use the port exclusively these days for
all the kernel debugging I have to do from panics in our fleet (although I
have some minorly special needs so I use a special script to fit into our
buildenv vs deployed env). The current gdb in the base can't cope with
anything more complicated than 'hello world'. It's broken for threads. It's
broken for much of the code clang generates. It's useless for kernel dumps
(even tracebacks are unreliable in my experience). There's little to no
value that having gdb in the tree at this point.

I also agree that none of this should be gated on lldb. gdb in tree is so
out of date that we are much better off removing it, even if lldb isn't a
complete drop in replacement (I've not used it at all, so I can't say one
way or another).

Warner

From emaste at freebsd.org  Wed Dec  2 17:58:39 2020
From: emaste at freebsd.org (Ed Maste)
Date: Wed, 2 Dec 2020 12:58:25 -0500
Subject: Removing obsolete GDB 6.1.1 for FreeBSD 13
In-Reply-To: <CANCZdfqGKVkrGY-K4Pt-vm=ih1Y_P2J2n_5qPqZzBdt29--SSA@mail.gmail.com>
References: <CAPyFy2AxAycToQxTgGq+WMfED1UiRGgPzox6c8A49P6gErgwJw@mail.gmail.com>
 <CANCZdfqGKVkrGY-K4Pt-vm=ih1Y_P2J2n_5qPqZzBdt29--SSA@mail.gmail.com>
Message-ID: <CAPyFy2DE1K11FAE0bU=152NP4gQ+qn9vw-fKfRdh=PCj5TxTQw@mail.gmail.com>

On Wed, 2 Dec 2020 at 12:52, Warner Losh <imp at bsdimp.com> wrote:
>
> even if lldb isn't a complete drop in replacement (I've not used it at all, so I can't say one way or another).

Quick comment on this point - the FreeBSD Foundation has been
sponsoring Moritz Systems to improve LLDB on FreeBSD, and they've done
great work getting it into shape. Their work is in LLVM upstream now,
and they're iterating on fixing issues found by LLDB's test suite.
LLDB 12 should provide a capable userland debugging experience in
FreeBSD 13, although I suspect many users will still install the gdb
port or package for the familiar command line interface.

There's no FreeBSD kernel support in LLDB yet, but it's being investigated.

From avg at FreeBSD.org  Wed Dec  2 21:20:27 2020
From: avg at FreeBSD.org (Andriy Gapon)
Date: Wed, 2 Dec 2020 23:20:23 +0200
Subject: dtrace: give %'d a chance?
In-Reply-To: <X8fGQnn2uJ43RsNP@raichu>
References: <d832ce96-c7a9-7aac-b761-27522a02d0ef@FreeBSD.org>
 <X7aH5suHtYUsNq0x@raichu> <5b87b1af-2c19-7f41-60f0-1e578c72e17d@FreeBSD.org>
 <X8fGQnn2uJ43RsNP@raichu>
Message-ID: <a4ac3a1e-7528-929a-8c20-bd95a22a3dde@FreeBSD.org>

On 02/12/2020 18:52, Mark Johnston wrote:
> On Mon, Nov 30, 2020 at 03:50:53PM +0200, Andriy Gapon wrote:
>> On 19/11/2020 16:57, Mark Johnston wrote:
>>> On Thu, Nov 19, 2020 at 01:28:56PM +0200, Andriy Gapon wrote:
>>>>
>>>> what do people think about adding
>>>>     setlocale(LC_NUMERIC, "");
>>>> to dtrace's main function?
>>>
>>> That seems reasonable to me.
>>>
>>>> My primary interest is to (pretty-)print some numbers with a thousands separator.
>>>>
>>>> Not sure if any other LC_ types are worth bothering.
>>>
>>> Maybe LC_TIME?  libdtrace a couple of date formatters, %T and %Y.  A
>>> locale-aware formatter might be worth having.
>>
>> FWIW, I've just discovered that despite what
>> http://dtrace.org/guide/chp-fmt.html says about %Y its output is not dependent
>> on locale settings.
>> A quick look at the code confirms that -- pfprint_time uses ctime_r.
>> But %T (undocumented at the above link) indeed depends on LC_TIME as
>> pfprint_time822 uses strftime("%a, %d %b %G %T %Z").
>>
>> Sample output in C locale:
>> 10000000
>> Mon, 30 Nov 2020 13:47:24 UTC
>> 2020 Nov 30 13:47:24
>>
>> The same formats (%'d, %T, %Y) in uk_UA locale:
>> 10?000?000
>> ??, 30 ????. 2020 13:43:11 UTC
>> 2020 Nov 30 13:43:11
> 
> So to be clear, there is nothing that needs to be done for time locales?

Sorry, it was I who was not clear.  The above output is after adding setlocale()
calls.  Stock dtrace always operates in C locale.

> In any case, I'm fine with adding the %'d formatter.

It's already there and it delegates the work to the C printf.
Hence the need for setlocale.

-- 
Andriy Gapon

From avg at FreeBSD.org  Wed Dec  2 21:53:46 2020
From: avg at FreeBSD.org (Andriy Gapon)
Date: Wed, 2 Dec 2020 23:53:41 +0200
Subject: rand() is racy in multi-threaded programs?
Message-ID: <5b827768-eb46-07f3-5b44-49627779786e@FreeBSD.org>


Specifically, concurrent "first" calls to rand().
There can be a moment when rand3_state is allocated but not completely set up
with initstate_r().
Is this a known / documented issue?
Should we try to do better?

P.S.
I am seeing this issue from time to time when running ztest program (from ZFS).
I guess that it uses rand() just because that's what OpenZFS did / does on
illumos and Linux.

P.P.S.
Just realized that the problem can be relatively recent.
https://svnweb.freebsd.org/base?view=revision&revision=357382

-- 
Andriy Gapon

From cem at freebsd.org  Wed Dec  2 23:20:41 2020
From: cem at freebsd.org (Conrad Meyer)
Date: Wed, 2 Dec 2020 15:20:28 -0800
Subject: rand() is racy in multi-threaded programs?
In-Reply-To: <5b827768-eb46-07f3-5b44-49627779786e@FreeBSD.org>
References: <5b827768-eb46-07f3-5b44-49627779786e@FreeBSD.org>
Message-ID: <CAG6CVpXdrivsAk45dDKtk_0M3wuZ-WkdBz1HWHtr2GwRa6v78Q@mail.gmail.com>

Hi Andriy,

Rand(3) is explicitly unsafe to use from concurrent threads without some
external serialization, even after initialization. I?d suggest using a
different API.

Best,
Conrad

On Wed, Dec 2, 2020 at 13:53 Andriy Gapon <avg at freebsd.org> wrote:

>
> Specifically, concurrent "first" calls to rand().
> There can be a moment when rand3_state is allocated but not completely set
> up
> with initstate_r().
> Is this a known / documented issue?
> Should we try to do better?
>
> P.S.
> I am seeing this issue from time to time when running ztest program (from
> ZFS).
> I guess that it uses rand() just because that's what OpenZFS did / does on
> illumos and Linux.
>
> P.P.S.
> Just realized that the problem can be relatively recent.
> https://svnweb.freebsd.org/base?view=revision&revision=357382
>
> --
> Andriy Gapon
>

From ali.abdallah at suse.com  Thu Dec  3 07:05:53 2020
From: ali.abdallah at suse.com (Ali Abdallah)
Date: Thu, 3 Dec 2020 08:05:49 +0100
Subject: Issues with USB-C external monitors
In-Reply-To: <20201202102841.ysv52uc6oseuurwh@frix230>
References: <20201201131430.ol7pzms24h743iwf@frix230>
 <342519ee-6f73-98be-29b1-cea7890ccb1e@selasky.org>
 <BD186C8D-AF73-4182-BF89-89005854F618@unrelenting.technology>
 <20201202102841.ysv52uc6oseuurwh@frix230>
Message-ID: <20201203070549.d7or5kb43jm3rztz@frix230>

On 02.12.2020 11:28, Ali Abdallah wrote:
> Actually Xorg on FreeBSD with UDEV is compiled with
> --disable-config-udev-kms, thus the server never calls:
> 
> udev_monitor_filter_add_match_subsystem_devtype
> 
> for GPU devices, and thus libudev-devd doesn't forward kms events to the
> server. Actually Xorg doesn't even process them, even if the filter check
> is bypassed in libudev-devd (udev-monitor.c:261).
> 
> Basically Xorg is missing bsd platform code for drm devices, on Linux
> the code that implements that can be found in:
> hw/xfree86/os-support/linux/lnx_platform.c

I'm attaching two patches that make hotpluggable drm connectors work on
FreeBSD with xorg-server compiled with UDEV.

If you want to give them a try, for libudev-devd it is enough to apply
patch-libudev-devd-drm-hotplug.c, but for xorg-server you need to change
its Makefile to enable udev-kms, and apply patch-xorg-server-drm-bsd-platform.c

UDEV_CONFIGURE_ON=      --disable-config-udev-kms

to

UDEV_CONFIGURE_ON=      --enabled-config-udev-kms

The bsd-platform code for the xorg-server is basically the same as Linux,
expect for the systemd bit obviously. For now, I appended the code to
hw/xfree86/os-support/bsd/bsd_VTsw.c just because I didn't want to patch
the Makefile.in or Makefile.am and fight with autotools. But that code
should finish in the future in bsd_platform.c.

It is working perfectly fine for me, also got positive feedback from a
friend using it on a Thinkpad X280 with a USB-C dock.

The patches even for onboard connectors deliver for "complete" desktop
plugging/unplugging external monitors events (such as Xfce, gnome, KDE),
and then the external monitors are configured automatically.

I will also later on work on DEVD support as well.

Regards.

-- 
Ali Abdallah | SUSE Linux L3 Engineer
GPG fingerprint: 51A0 F4A0 C8CF C98F 842E  A9A8 B945 56F8 1C85 D0D5

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20201203/f71be715/attachment.sig>

From avg at FreeBSD.org  Thu Dec  3 07:34:01 2020
From: avg at FreeBSD.org (Andriy Gapon)
Date: Thu, 3 Dec 2020 09:33:57 +0200
Subject: rand() is racy in multi-threaded programs?
In-Reply-To: <CAG6CVpXdrivsAk45dDKtk_0M3wuZ-WkdBz1HWHtr2GwRa6v78Q@mail.gmail.com>
References: <5b827768-eb46-07f3-5b44-49627779786e@FreeBSD.org>
 <CAG6CVpXdrivsAk45dDKtk_0M3wuZ-WkdBz1HWHtr2GwRa6v78Q@mail.gmail.com>
Message-ID: <22f5dfc1-c709-6911-b8b0-121e4c40affc@FreeBSD.org>

On 03/12/2020 01:20, Conrad Meyer wrote:
> Hi Andriy,
> 
> Rand(3) is explicitly unsafe to use from concurrent threads without some
> external serialization, even after initialization. I?d suggest using a different
> API.

Conrad,

thank you!
Just want to check, unsafe in terms of bogus results (with respect to
randomness) or unsafe as in may crash?


> On Wed, Dec 2, 2020 at 13:53 Andriy Gapon <avg at freebsd.org
> <mailto:avg at freebsd.org>> wrote:
> 
> 
>     Specifically, concurrent "first" calls to rand().
>     There can be a moment when rand3_state is allocated but not completely set up
>     with initstate_r().
>     Is this a known / documented issue?
>     Should we try to do better?
> 
>     P.S.
>     I am seeing this issue from time to time when running ztest program (from ZFS).
>     I guess that it uses rand() just because that's what OpenZFS did / does on
>     illumos and Linux.
> 
>     P.P.S.
>     Just realized that the problem can be relatively recent.
>     https://svnweb.freebsd.org/base?view=revision&revision=357382
> 
>     -- 
>     Andriy Gapon
> 


-- 
Andriy Gapon

From cem at freebsd.org  Thu Dec  3 07:44:37 2020
From: cem at freebsd.org (Conrad Meyer)
Date: Wed, 2 Dec 2020 23:44:23 -0800
Subject: rand() is racy in multi-threaded programs?
In-Reply-To: <22f5dfc1-c709-6911-b8b0-121e4c40affc@FreeBSD.org>
References: <5b827768-eb46-07f3-5b44-49627779786e@FreeBSD.org>
 <CAG6CVpXdrivsAk45dDKtk_0M3wuZ-WkdBz1HWHtr2GwRa6v78Q@mail.gmail.com>
 <22f5dfc1-c709-6911-b8b0-121e4c40affc@FreeBSD.org>
Message-ID: <CAG6CVpXekxF27L5dQrdDY=AAnjgPQ=2W9GM4wmhA91J5tjik1g@mail.gmail.com>

Hi Andriy,

On Wed, Dec 2, 2020 at 11:34 PM Andriy Gapon <avg at freebsd.org> wrote:
>
> On 03/12/2020 01:20, Conrad Meyer wrote:
> > Rand(3) is explicitly unsafe to use from concurrent threads without some
> > external serialization, even after initialization. I?d suggest using a different
> > API.
>
> thank you!
> Just want to check, unsafe in terms of bogus results (with respect to
> randomness) or unsafe as in may crash?

Well, unsafe in that it's a data race, which is formally undefined
behavior in C (if I understand correctly).  So anything could happen,
including a crash.  In practice, you would probably see something more
like the former (bogus results, e.g., multiple calls returning the
same number because the state wasn't updated atomically, or something
like that) rather than a crash.

Best,
Conrad

From ali.abdallah at suse.com  Thu Dec  3 08:02:51 2020
From: ali.abdallah at suse.com (Ali Abdallah)
Date: Thu, 3 Dec 2020 09:02:47 +0100
Subject: Issues with USB-C external monitors
In-Reply-To: <20201203070549.d7or5kb43jm3rztz@frix230>
References: <20201201131430.ol7pzms24h743iwf@frix230>
 <342519ee-6f73-98be-29b1-cea7890ccb1e@selasky.org>
 <BD186C8D-AF73-4182-BF89-89005854F618@unrelenting.technology>
 <20201202102841.ysv52uc6oseuurwh@frix230>
 <20201203070549.d7or5kb43jm3rztz@frix230>
Message-ID: <20201203080247.4uqjhkdhucflfxiq@frix230>

Sorry for the noise, you can the patches at the following link:

https://github.com/Alix82/FreeBSD-xorg-drm-hotplug

On 03.12.2020 08:05, Ali Abdallah wrote:
> On 02.12.2020 11:28, Ali Abdallah wrote:
> > Actually Xorg on FreeBSD with UDEV is compiled with
> > --disable-config-udev-kms, thus the server never calls:
> > 
> > udev_monitor_filter_add_match_subsystem_devtype
> > 
> > for GPU devices, and thus libudev-devd doesn't forward kms events to the
> > server. Actually Xorg doesn't even process them, even if the filter check
> > is bypassed in libudev-devd (udev-monitor.c:261).
> > 
> > Basically Xorg is missing bsd platform code for drm devices, on Linux
> > the code that implements that can be found in:
> > hw/xfree86/os-support/linux/lnx_platform.c
> 
> I'm attaching two patches that make hotpluggable drm connectors work on
> FreeBSD with xorg-server compiled with UDEV.
> 
> If you want to give them a try, for libudev-devd it is enough to apply
> patch-libudev-devd-drm-hotplug.c, but for xorg-server you need to change
> its Makefile to enable udev-kms, and apply patch-xorg-server-drm-bsd-platform.c
> 
> UDEV_CONFIGURE_ON=      --disable-config-udev-kms
> 
> to
> 
> UDEV_CONFIGURE_ON=      --enabled-config-udev-kms
> 
> The bsd-platform code for the xorg-server is basically the same as Linux,
> expect for the systemd bit obviously. For now, I appended the code to
> hw/xfree86/os-support/bsd/bsd_VTsw.c just because I didn't want to patch
> the Makefile.in or Makefile.am and fight with autotools. But that code
> should finish in the future in bsd_platform.c.
> 
> It is working perfectly fine for me, also got positive feedback from a
> friend using it on a Thinkpad X280 with a USB-C dock.
> 
> The patches even for onboard connectors deliver for "complete" desktop
> plugging/unplugging external monitors events (such as Xfce, gnome, KDE),
> and then the external monitors are configured automatically.
> 
> I will also later on work on DEVD support as well.
> 
> Regards.
> 
> -- 
> Ali Abdallah | SUSE Linux L3 Engineer
> GPG fingerprint: 51A0 F4A0 C8CF C98F 842E  A9A8 B945 56F8 1C85 D0D5
> 






-- 
Ali Abdallah | SUSE Linux L3 Engineer
GPG fingerprint: 51A0 F4A0 C8CF C98F 842E  A9A8 B945 56F8 1C85 D0D5


From phk at phk.freebsd.dk  Thu Dec  3 09:46:24 2020
From: phk at phk.freebsd.dk (Poul-Henning Kamp)
Date: Thu, 03 Dec 2020 09:46:20 +0000
Subject: Issues with USB-C external monitors
In-Reply-To: <20201203080247.4uqjhkdhucflfxiq@frix230>
References: <20201201131430.ol7pzms24h743iwf@frix230>
 <342519ee-6f73-98be-29b1-cea7890ccb1e@selasky.org>
 <BD186C8D-AF73-4182-BF89-89005854F618@unrelenting.technology>
 <20201202102841.ysv52uc6oseuurwh@frix230>
 <20201203070549.d7or5kb43jm3rztz@frix230>
 <20201203080247.4uqjhkdhucflfxiq@frix230>
Message-ID: <60304.1606988780@critter.freebsd.dk>

--------
Ali Abdallah writes:
> Sorry for the noise, you can the patches at the following link:
>
> https://github.com/Alix82/FreeBSD-xorg-drm-hotplug

Thanks a lot Ali!

With these patches my T480+TB3 dock works, with the following footnotes:

I have disabled "TB3 Bios assist" in the BIOS and use a USB-C cable
instead of the TB-3 cable, to keep TB3 out of this.

At some point, probably years ago, I ran "make config" in
x11-servers/xorg-server, and the state-file left in /var/db/ports
kept UDEV disabled, despite the patch to Makefile in the bundle above.

You can either remove the state-file or run "make config" again and
select UDEV.

Poul-Henning


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at 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.

From trond.endrestol at ximalas.info  Thu Dec  3 10:43:22 2020
From: trond.endrestol at ximalas.info (=?UTF-8?Q?Trond_Endrest=C3=B8l?=)
Date: Thu, 3 Dec 2020 11:43:07 +0100 (CET)
Subject: page fault due to close(2), possibly drm and i915kms related
Message-ID: <8b62fa1c-8d22-b0c5-239d-56f0bcad081@ximalas.info>

Fam,

After close(2) got fixed in r368006 last week, my laptop at home has 
been acting up.

It currently runs:

FreeBSD E590T.ufp 13.0-CURRENT FreeBSD 13.0-CURRENT #870 r368192: Mon Nov 30 20:29:15 CET 2020     root at E590T.ufp:/usr/obj/usr/src/amd64.amd64/sys/E590T  amd64 1300130 1300130 a5c28607a47e84c68f4c8063d23189c475e61ac8

The DRM and KMS drivers (i915kms) are compiled from the source code of 
graphics/drm-kmod and are automatically installed along with the 
kernel.

>From time to time whenever I'm logged in using X.org, I sometimes get 
crashes like this one:

Script started on Thu Dec  3 07:13:33 2020
Command: kkgdb /boot/kernel/kernel /var/crash/vmcore.2
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
[160176] 
[160176] 
[160176] Fatal trap 12: page fault while in kernel mode
[160176] cpuid = 0; apic id = 00
[160176] fault virtual address	= 0x440
[160176] fault code		= supervisor read data, page not present
[160176] instruction pointer	= 0x20:0xffffffff808cbd2c
[160176] stack pointer	        = 0x28:0xfffffe018500e700
[160176] frame pointer	        = 0x28:0xfffffe018500e780
[160176] code segment		= base 0x0, limit 0xfffff, type 0x1b
[160176] 			= DPL 0, pres 1, long 1, def32 0, gran 1
[160176] processor eflags	= interrupt enabled, resume, IOPL = 0
[160176] current process		= 3874 (wc)
[160176] trap number		= 12
[160176] WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:621
[160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
[160176] #1 0xffffffff830fb3c3 at drm_atomic_helper_check_modeset+0xb3
[160176] #2 0xffffffff831dfd9d at intel_atomic_check+0x8d
[160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
[160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
[160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
[160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
[160176] #7 0xffffffff8314a7d7 at drm_fb_helper_restore_fbdev_mode_unlocked+0x77
[160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
[160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
[160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
[160176] #11 0xffffffff80887c36 at cngrab+0x16
[160176] #12 0xffffffff808ee35c at vpanic+0xec
[160176] #13 0xffffffff808ee263 at panic+0x43
[160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
[160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
[160176] #16 0xffffffff80cf71ad at trap+0x27d
[160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
[160176] WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:621
[160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
[160176] #1 0xffffffff830fb3c3 at drm_atomic_helper_check_modeset+0xb3
[160176] #2 0xffffffff831dfd9d at intel_atomic_check+0x8d
[160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
[160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
[160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
[160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
[160176] #7 0xffffffff8314a7d7 at drm_fb_helper_restore_fbdev_mode_unlocked+0x77
[160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
[160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
[160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
[160176] #11 0xffffffff80887c36 at cngrab+0x16
[160176] #12 0xffffffff808ee35c at vpanic+0xec
[160176] #13 0xffffffff808ee263 at panic+0x43
[160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
[160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
[160176] #16 0xffffffff80cf71ad at trap+0x27d
[160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
[160176] WARNING !drm_modeset_is_locked(&crtc->mutex) failed at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:621
[160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
[160176] #1 0xffffffff830fb3c3 at drm_atomic_helper_check_modeset+0xb3
[160176] #2 0xffffffff831dfd9d at intel_atomic_check+0x8d
[160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
[160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
[160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
[160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
[160176] #7 0xffffffff8314a7d7 at drm_fb_helper_restore_fbdev_mode_unlocked+0x77
[160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
[160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
[160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
[160176] #11 0xffffffff80887c36 at cngrab+0x16
[160176] #12 0xffffffff808ee35c at vpanic+0xec
[160176] #13 0xffffffff808ee263 at panic+0x43
[160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
[160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
[160176] #16 0xffffffff80cf71ad at trap+0x27d
[160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
[160176] WARNING !drm_modeset_is_locked(&dev->mode_config.connection_mutex) failed at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:666
[160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
[160176] #1 0xffffffff830fb553 at drm_atomic_helper_check_modeset+0x243
[160176] #2 0xffffffff831dfd9d at intel_atomic_check+0x8d
[160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
[160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
[160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
[160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
[160176] #7 0xffffffff8314a7d7 at drm_fb_helper_restore_fbdev_mode_unlocked+0x77
[160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
[160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
[160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
[160176] #11 0xffffffff80887c36 at cngrab+0x16
[160176] #12 0xffffffff808ee35c at vpanic+0xec
[160176] #13 0xffffffff808ee263 at panic+0x43
[160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
[160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
[160176] #16 0xffffffff80cf71ad at trap+0x27d
[160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
[160176] WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:871
[160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
[160176] #1 0xffffffff830fc620 at drm_atomic_helper_check_planes+0xb0
[160176] #2 0xffffffff831e0f11 at intel_atomic_check+0x1201
[160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
[160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
[160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
[160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
[160176] #7 0xffffffff8314a7d7 at drm_fb_helper_restore_fbdev_mode_unlocked+0x77
[160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
[160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
[160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
[160176] #11 0xffffffff80887c36 at cngrab+0x16
[160176] #12 0xffffffff808ee35c at vpanic+0xec
[160176] #13 0xffffffff808ee263 at panic+0x43
[160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
[160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
[160176] #16 0xffffffff80cf71ad at trap+0x27d
[160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
[160176] WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:871
[160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
[160176] #1 0xffffffff830fc620 at drm_atomic_helper_check_planes+0xb0
[160176] #2 0xffffffff831e0f11 at intel_atomic_check+0x1201
[160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
[160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
[160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
[160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
[160176] #7 0xffffffff8314a7d7 at drm_fb_helper_restore_fbdev_mode_unlocked+0x77
[160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
[160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
[160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
[160176] #11 0xffffffff80887c36 at cngrab+0x16
[160176] #12 0xffffffff808ee35c at vpanic+0xec
[160176] #13 0xffffffff808ee263 at panic+0x43
[160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
[160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
[160176] #16 0xffffffff80cf71ad at trap+0x27d
[160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
[160176] WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:871
[160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
[160176] #1 0xffffffff830fc620 at drm_atomic_helper_check_planes+0xb0
[160176] #2 0xffffffff831e0f11 at intel_atomic_check+0x1201
[160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
[160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
[160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
[160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
[160176] #7 0xffffffff8314a7d7 at drm_fb_helper_restore_fbdev_mode_unlocked+0x77
[160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
[160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
[160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
[160176] #11 0xffffffff80887c36 at cngrab+0x16
[160176] #12 0xffffffff808ee35c at vpanic+0xec
[160176] #13 0xffffffff808ee263 at panic+0x43
[160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
[160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
[160176] #16 0xffffffff80cf71ad at trap+0x27d
[160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
[160176] WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:871
[160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
[160176] #1 0xffffffff830fc620 at drm_atomic_helper_check_planes+0xb0
[160176] #2 0xffffffff831e0f11 at intel_atomic_check+0x1201
[160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
[160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
[160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
[160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
[160176] #7 0xffffffff8314a7d7 at drm_fb_helper_restore_fbdev_mode_unlocked+0x77
[160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
[160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
[160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
[160176] #11 0xffffffff80887c36 at cngrab+0x16
[160176] #12 0xffffffff808ee35c at vpanic+0xec
[160176] #13 0xffffffff808ee263 at panic+0x43
[160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
[160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
[160176] #16 0xffffffff80cf71ad at trap+0x27d
[160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
[160176] WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:871
[160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
[160176] #1 0xffffffff830fc620 at drm_atomic_helper_check_planes+0xb0
[160176] #2 0xffffffff831e0f11 at intel_atomic_check+0x1201
[160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
[160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
[160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
[160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
[160176] #7 0xffffffff8314a7d7 at drm_fb_helper_restore_fbdev_mode_unlocked+0x77
[160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
[160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
[160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
[160176] #11 0xffffffff80887c36 at cngrab+0x16
[160176] #12 0xffffffff808ee35c at vpanic+0xec
[160176] #13 0xffffffff808ee263 at panic+0x43
[160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
[160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
[160176] #16 0xffffffff80cf71ad at trap+0x27d
[160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
[160176] WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:871
[160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
[160176] #1 0xffffffff830fc620 at drm_atomic_helper_check_planes+0xb0
[160176] #2 0xffffffff831e0f11 at intel_atomic_check+0x1201
[160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
[160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
[160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
[160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
[160176] #7 0xffffffff8314a7d7 at drm_fb_helper_restore_fbdev_mode_unlocked+0x77
[160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
[160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
[160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
[160176] #11 0xffffffff80887c36 at cngrab+0x16
[160176] #12 0xffffffff808ee35c at vpanic+0xec
[160176] #13 0xffffffff808ee263 at panic+0x43
[160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
[160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
[160176] #16 0xffffffff80cf71ad at trap+0x27d
[160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
[160176] WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:871
[160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
[160176] #1 0xffffffff830fc620 at drm_atomic_helper_check_planes+0xb0
[160176] #2 0xffffffff831e0f11 at intel_atomic_check+0x1201
[160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
[160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
[160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
[160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
[160176] #7 0xffffffff8314a7d7 at drm_fb_helper_restore_fbdev_mode_unlocked+0x77
[160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
[160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
[160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
[160176] #11 0xffffffff80887c36 at cngrab+0x16
[160176] #12 0xffffffff808ee35c at vpanic+0xec
[160176] #13 0xffffffff808ee263 at panic+0x43
[160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
[160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
[160176] #16 0xffffffff80cf71ad at trap+0x27d
[160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
[160176] WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:871
[160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
[160176] #1 0xffffffff830fc620 at drm_atomic_helper_check_planes+0xb0
[160176] #2 0xffffffff831e0f11 at intel_atomic_check+0x1201
[160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
[160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
[160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
[160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
[160176] #7 0xffffffff8314a7d7 at drm_fb_helper_restore_fbdev_mode_unlocked+0x77
[160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
[160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
[160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
[160176] #11 0xffffffff80887c36 at cngrab+0x16
[160176] #12 0xffffffff808ee35c at vpanic+0xec
[160176] #13 0xffffffff808ee263 at panic+0x43
[160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
[160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
[160176] #16 0xffffffff80cf71ad at trap+0x27d
[160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
[160176] WARNING !drm_modeset_is_locked(&plane->mutex) failed at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:871
[160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
[160176] #1 0xffffffff830fc620 at drm_atomic_helper_check_planes+0xb0
[160176] #2 0xffffffff831e0f11 at intel_atomic_check+0x1201
[160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
[160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
[160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
[160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
[160176] #7 0xffffffff8314a7d7 at drm_fb_helper_restore_fbdev_mode_unlocked+0x77
[160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
[160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
[160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
[160176] #11 0xffffffff80887c36 at cngrab+0x16
[160176] #12 0xffffffff808ee35c at vpanic+0xec
[160176] #13 0xffffffff808ee263 at panic+0x43
[160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
[160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
[160176] #16 0xffffffff80cf71ad at trap+0x27d
[160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
<4>[160176] WARN_ON(!mutex_is_locked(&dev->struct_mutex))
[160176]                           
<4>[160176] WARN_ON(!mutex_is_locked(&fbc->lock))
[160176]  
<4>[160176] WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock))
[160176] panic: page fault
[160176] cpuid = 0
[160176] time = 1606962312
[160176] KDB: stack backtrace:
[160176] db_trace_self_wrapper() at 0xffffffff805df8bb = db_trace_self_wrapper+0x2b/frame 0xfffffe018500e3b0
[160176] vpanic() at 0xffffffff808ee3f1 = vpanic+0x181/frame 0xfffffe018500e400
[160176] panic() at 0xffffffff808ee263 = panic+0x43/frame 0xfffffe018500e460
[160176] trap_fatal() at 0xffffffff80cf7af7 = trap_fatal+0x387/frame 0xfffffe018500e4c0
[160176] trap_pfault() at 0xffffffff80cf7b4f = trap_pfault+0x4f/frame 0xfffffe018500e520
[160176] trap() at 0xffffffff80cf71ad = trap+0x27d/frame 0xfffffe018500e630
[160176] calltrap() at 0xffffffff80ccf3e8 = calltrap+0x8/frame 0xfffffe018500e630
[160176] --- trap 0xc, rip = 0xffffffff808cbd2c, rsp = 0xfffffe018500e700, rbp = 0xfffffe018500e780 ---
[160176] __mtx_lock_sleep() at 0xffffffff808cbd2c = __mtx_lock_sleep+0xfc/frame 0xfffffe018500e780
[160176] doselwakeup() at 0xffffffff8095fbee = doselwakeup+0xde/frame 0xfffffe018500e7c0
[160176] sowakeup() at 0xffffffff80988c7e = sowakeup+0x1e/frame 0xfffffe018500e7f0
[160176] soisdisconnected() at 0xffffffff8099235a = soisdisconnected+0x8a/frame 0xfffffe018500e810
[160176] unp_disconnect() at 0xffffffff8099a9fe = unp_disconnect+0x12e/frame 0xfffffe018500e850
[160176] uipc_disconnect() at 0xffffffff809982a2 = uipc_disconnect+0x42/frame 0xfffffe018500e870
[160176] soclose() at 0xffffffff8098cc96 = soclose+0x76/frame 0xfffffe018500e8d0
[160176] _fdrop() at 0xffffffff80891eb1 = _fdrop+0x11/frame 0xfffffe018500e8f0
[160176] closef() at 0xffffffff80895098 = closef+0x278/frame 0xfffffe018500e980
[160176] closefp() at 0xffffffff808921d9 = closefp+0x89/frame 0xfffffe018500e9c0
[160176] amd64_syscall() at 0xffffffff80cf8a45 = amd64_syscall+0x755/frame 0xfffffe018500eaf0
[160176] fast_syscall_common() at 0xffffffff80ccfd0e = fast_syscall_common+0xf8/frame 0xfffffe018500eaf0
[160176] --- syscall (6, FreeBSD ELF64, sys_close), rip = 0x8003b0d7a, rsp = 0x7fffffffe998, rbp = 0x7fffffffe9b0 ---
[160176] Uptime: 1d20h29m36s
[160176] Dumping 6415 out of 32449 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

No symbol "zombproc" in current context.
Reading symbols from /boot/kernel/dtraceall.ko...Reading symbols from /usr/lib/debug//boot/kernel/dtraceall.ko.debug...done.
done.
Loaded symbols for /boot/kernel/dtraceall.ko
Reading symbols from /boot/kernel/profile.ko...Reading symbols from /usr/lib/debug//boot/kernel/profile.ko.debug...done.
done.
Loaded symbols for /boot/kernel/profile.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.
done.
Loaded symbols for /boot/kernel/opensolaris.ko
Reading symbols from /boot/kernel/dtrace.ko...Reading symbols from /usr/lib/debug//boot/kernel/dtrace.ko.debug...done.
done.
Loaded symbols for /boot/kernel/dtrace.ko
Reading symbols from /boot/kernel/systrace_freebsd32.ko...Reading symbols from /usr/lib/debug//boot/kernel/systrace_freebsd32.ko.debug...done.
done.
Loaded symbols for /boot/kernel/systrace_freebsd32.ko
Reading symbols from /boot/kernel/systrace.ko...Reading symbols from /usr/lib/debug//boot/kernel/systrace.ko.debug...done.
done.
Loaded symbols for /boot/kernel/systrace.ko
Reading symbols from /boot/kernel/sdt.ko...Reading symbols from /usr/lib/debug//boot/kernel/sdt.ko.debug...done.
done.
Loaded symbols for /boot/kernel/sdt.ko
Reading symbols from /boot/kernel/fasttrap.ko...Reading symbols from /usr/lib/debug//boot/kernel/fasttrap.ko.debug...done.
done.
Loaded symbols for /boot/kernel/fasttrap.ko
Reading symbols from /boot/kernel/fbt.ko...Reading symbols from /usr/lib/debug//boot/kernel/fbt.ko.debug...done.
done.
Loaded symbols for /boot/kernel/fbt.ko
Reading symbols from /boot/kernel/dtnfscl.ko...Reading symbols from /usr/lib/debug//boot/kernel/dtnfscl.ko.debug...done.
done.
Loaded symbols for /boot/kernel/dtnfscl.ko
Reading symbols from /boot/kernel/dtmalloc.ko...Reading symbols from /usr/lib/debug//boot/kernel/dtmalloc.ko.debug...done.
done.
Loaded symbols for /boot/kernel/dtmalloc.ko
Reading symbols from /boot/modules/sysctlinfo.ko...done.
Loaded symbols for /boot/modules/sysctlinfo.ko
Reading symbols from /boot/kernel/cc_htcp.ko...Reading symbols from /usr/lib/debug//boot/kernel/cc_htcp.ko.debug...done.
done.
Loaded symbols for /boot/kernel/cc_htcp.ko
Reading symbols from /boot/kernel/lindebugfs.ko...Reading symbols from /usr/lib/debug//boot/kernel/lindebugfs.ko.debug...done.
done.
Loaded symbols for /boot/kernel/lindebugfs.ko
Reading symbols from /boot/kernel/linuxkpi.ko...Reading symbols from /usr/lib/debug//boot/kernel/linuxkpi.ko.debug...done.
done.
Loaded symbols for /boot/kernel/linuxkpi.ko
Reading symbols from /boot/kernel/pchtherm.ko...Reading symbols from /usr/lib/debug//boot/kernel/pchtherm.ko.debug...done.
done.
Loaded symbols for /boot/kernel/pchtherm.ko
Reading symbols from /boot/kernel/drm.ko...Reading symbols from /usr/lib/debug//boot/kernel/drm.ko.debug...done.
done.
Loaded symbols for /boot/kernel/drm.ko
Reading symbols from /boot/kernel/linuxkpi_gplv2.ko...Reading symbols from /usr/lib/debug//boot/kernel/linuxkpi_gplv2.ko.debug...done.
done.
Loaded symbols for /boot/kernel/linuxkpi_gplv2.ko
Reading symbols from /boot/kernel/i915kms.ko...Reading symbols from /usr/lib/debug//boot/kernel/i915kms.ko.debug...done.
done.
Loaded symbols for /boot/kernel/i915kms.ko
Reading symbols from /boot/modules/i915_kbl_dmc_ver1_04_bin.ko...done.
Loaded symbols for /boot/modules/i915_kbl_dmc_ver1_04_bin.ko
Reading symbols from /boot/kernel/mac_ntpd.ko...Reading symbols from /usr/lib/debug//boot/kernel/mac_ntpd.ko.debug...done.
done.
Loaded symbols for /boot/kernel/mac_ntpd.ko
#0  doadump (textdump=1) at src/sys/amd64/include/pcpu_aux.h:55
55		__asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu,
(kgdb) q

Command exit status: 0
Script done on Thu Dec  3 07:13:48 2020

kkgdb is a shell script of mine that prepends /usr/libexec to PATH and 
exec's kgdb with the given command line. That shell script makes life 
in kgdb bearable.

The minidump is available on request.

Is this a known case?

-- 
Trond.

From mjguzik at gmail.com  Thu Dec  3 10:46:05 2020
From: mjguzik at gmail.com (Mateusz Guzik)
Date: Thu, 3 Dec 2020 11:45:56 +0100
Subject: page fault due to close(2), possibly drm and i915kms related
In-Reply-To: <8b62fa1c-8d22-b0c5-239d-56f0bcad081@ximalas.info>
References: <8b62fa1c-8d22-b0c5-239d-56f0bcad081@ximalas.info>
Message-ID: <CAGudoHENrDzV=uFU7wEzLZbwOw6OR9TuUjas2jkchon0JDzEbg@mail.gmail.com>

This should be fixed by r368271

On 12/3/20, Trond Endrest?l <trond.endrestol at ximalas.info> wrote:
> Fam,
>
> After close(2) got fixed in r368006 last week, my laptop at home has
> been acting up.
>
> It currently runs:
>
> FreeBSD E590T.ufp 13.0-CURRENT FreeBSD 13.0-CURRENT #870 r368192: Mon Nov 30
> 20:29:15 CET 2020     root at E590T.ufp:/usr/obj/usr/src/amd64.amd64/sys/E590T
> amd64 1300130 1300130 a5c28607a47e84c68f4c8063d23189c475e61ac8
>
> The DRM and KMS drivers (i915kms) are compiled from the source code of
> graphics/drm-kmod and are automatically installed along with the
> kernel.
>
> From time to time whenever I'm logged in using X.org, I sometimes get
> crashes like this one:
>
> Script started on Thu Dec  3 07:13:33 2020
> Command: kkgdb /boot/kernel/kernel /var/crash/vmcore.2
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd"...
>
> Unread portion of the kernel message buffer:
> [160176]
> [160176]
> [160176] Fatal trap 12: page fault while in kernel mode
> [160176] cpuid = 0; apic id = 00
> [160176] fault virtual address	= 0x440
> [160176] fault code		= supervisor read data, page not present
> [160176] instruction pointer	= 0x20:0xffffffff808cbd2c
> [160176] stack pointer	        = 0x28:0xfffffe018500e700
> [160176] frame pointer	        = 0x28:0xfffffe018500e780
> [160176] code segment		= base 0x0, limit 0xfffff, type 0x1b
> [160176] 			= DPL 0, pres 1, long 1, def32 0, gran 1
> [160176] processor eflags	= interrupt enabled, resume, IOPL = 0
> [160176] current process		= 3874 (wc)
> [160176] trap number		= 12
> [160176] WARNING !drm_modeset_is_locked(&crtc->mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:621
> [160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
> [160176] #1 0xffffffff830fb3c3 at drm_atomic_helper_check_modeset+0xb3
> [160176] #2 0xffffffff831dfd9d at intel_atomic_check+0x8d
> [160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
> [160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
> [160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
> [160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
> [160176] #7 0xffffffff8314a7d7 at
> drm_fb_helper_restore_fbdev_mode_unlocked+0x77
> [160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
> [160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
> [160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
> [160176] #11 0xffffffff80887c36 at cngrab+0x16
> [160176] #12 0xffffffff808ee35c at vpanic+0xec
> [160176] #13 0xffffffff808ee263 at panic+0x43
> [160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
> [160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
> [160176] #16 0xffffffff80cf71ad at trap+0x27d
> [160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
> [160176] WARNING !drm_modeset_is_locked(&crtc->mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:621
> [160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
> [160176] #1 0xffffffff830fb3c3 at drm_atomic_helper_check_modeset+0xb3
> [160176] #2 0xffffffff831dfd9d at intel_atomic_check+0x8d
> [160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
> [160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
> [160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
> [160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
> [160176] #7 0xffffffff8314a7d7 at
> drm_fb_helper_restore_fbdev_mode_unlocked+0x77
> [160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
> [160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
> [160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
> [160176] #11 0xffffffff80887c36 at cngrab+0x16
> [160176] #12 0xffffffff808ee35c at vpanic+0xec
> [160176] #13 0xffffffff808ee263 at panic+0x43
> [160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
> [160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
> [160176] #16 0xffffffff80cf71ad at trap+0x27d
> [160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
> [160176] WARNING !drm_modeset_is_locked(&crtc->mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:621
> [160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
> [160176] #1 0xffffffff830fb3c3 at drm_atomic_helper_check_modeset+0xb3
> [160176] #2 0xffffffff831dfd9d at intel_atomic_check+0x8d
> [160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
> [160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
> [160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
> [160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
> [160176] #7 0xffffffff8314a7d7 at
> drm_fb_helper_restore_fbdev_mode_unlocked+0x77
> [160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
> [160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
> [160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
> [160176] #11 0xffffffff80887c36 at cngrab+0x16
> [160176] #12 0xffffffff808ee35c at vpanic+0xec
> [160176] #13 0xffffffff808ee263 at panic+0x43
> [160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
> [160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
> [160176] #16 0xffffffff80cf71ad at trap+0x27d
> [160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
> [160176] WARNING !drm_modeset_is_locked(&dev->mode_config.connection_mutex)
> failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:666
> [160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
> [160176] #1 0xffffffff830fb553 at drm_atomic_helper_check_modeset+0x243
> [160176] #2 0xffffffff831dfd9d at intel_atomic_check+0x8d
> [160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
> [160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
> [160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
> [160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
> [160176] #7 0xffffffff8314a7d7 at
> drm_fb_helper_restore_fbdev_mode_unlocked+0x77
> [160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
> [160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
> [160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
> [160176] #11 0xffffffff80887c36 at cngrab+0x16
> [160176] #12 0xffffffff808ee35c at vpanic+0xec
> [160176] #13 0xffffffff808ee263 at panic+0x43
> [160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
> [160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
> [160176] #16 0xffffffff80cf71ad at trap+0x27d
> [160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
> [160176] WARNING !drm_modeset_is_locked(&plane->mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:871
> [160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
> [160176] #1 0xffffffff830fc620 at drm_atomic_helper_check_planes+0xb0
> [160176] #2 0xffffffff831e0f11 at intel_atomic_check+0x1201
> [160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
> [160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
> [160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
> [160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
> [160176] #7 0xffffffff8314a7d7 at
> drm_fb_helper_restore_fbdev_mode_unlocked+0x77
> [160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
> [160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
> [160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
> [160176] #11 0xffffffff80887c36 at cngrab+0x16
> [160176] #12 0xffffffff808ee35c at vpanic+0xec
> [160176] #13 0xffffffff808ee263 at panic+0x43
> [160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
> [160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
> [160176] #16 0xffffffff80cf71ad at trap+0x27d
> [160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
> [160176] WARNING !drm_modeset_is_locked(&plane->mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:871
> [160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
> [160176] #1 0xffffffff830fc620 at drm_atomic_helper_check_planes+0xb0
> [160176] #2 0xffffffff831e0f11 at intel_atomic_check+0x1201
> [160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
> [160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
> [160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
> [160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
> [160176] #7 0xffffffff8314a7d7 at
> drm_fb_helper_restore_fbdev_mode_unlocked+0x77
> [160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
> [160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
> [160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
> [160176] #11 0xffffffff80887c36 at cngrab+0x16
> [160176] #12 0xffffffff808ee35c at vpanic+0xec
> [160176] #13 0xffffffff808ee263 at panic+0x43
> [160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
> [160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
> [160176] #16 0xffffffff80cf71ad at trap+0x27d
> [160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
> [160176] WARNING !drm_modeset_is_locked(&plane->mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:871
> [160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
> [160176] #1 0xffffffff830fc620 at drm_atomic_helper_check_planes+0xb0
> [160176] #2 0xffffffff831e0f11 at intel_atomic_check+0x1201
> [160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
> [160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
> [160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
> [160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
> [160176] #7 0xffffffff8314a7d7 at
> drm_fb_helper_restore_fbdev_mode_unlocked+0x77
> [160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
> [160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
> [160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
> [160176] #11 0xffffffff80887c36 at cngrab+0x16
> [160176] #12 0xffffffff808ee35c at vpanic+0xec
> [160176] #13 0xffffffff808ee263 at panic+0x43
> [160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
> [160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
> [160176] #16 0xffffffff80cf71ad at trap+0x27d
> [160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
> [160176] WARNING !drm_modeset_is_locked(&plane->mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:871
> [160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
> [160176] #1 0xffffffff830fc620 at drm_atomic_helper_check_planes+0xb0
> [160176] #2 0xffffffff831e0f11 at intel_atomic_check+0x1201
> [160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
> [160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
> [160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
> [160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
> [160176] #7 0xffffffff8314a7d7 at
> drm_fb_helper_restore_fbdev_mode_unlocked+0x77
> [160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
> [160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
> [160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
> [160176] #11 0xffffffff80887c36 at cngrab+0x16
> [160176] #12 0xffffffff808ee35c at vpanic+0xec
> [160176] #13 0xffffffff808ee263 at panic+0x43
> [160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
> [160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
> [160176] #16 0xffffffff80cf71ad at trap+0x27d
> [160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
> [160176] WARNING !drm_modeset_is_locked(&plane->mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:871
> [160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
> [160176] #1 0xffffffff830fc620 at drm_atomic_helper_check_planes+0xb0
> [160176] #2 0xffffffff831e0f11 at intel_atomic_check+0x1201
> [160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
> [160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
> [160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
> [160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
> [160176] #7 0xffffffff8314a7d7 at
> drm_fb_helper_restore_fbdev_mode_unlocked+0x77
> [160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
> [160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
> [160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
> [160176] #11 0xffffffff80887c36 at cngrab+0x16
> [160176] #12 0xffffffff808ee35c at vpanic+0xec
> [160176] #13 0xffffffff808ee263 at panic+0x43
> [160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
> [160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
> [160176] #16 0xffffffff80cf71ad at trap+0x27d
> [160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
> [160176] WARNING !drm_modeset_is_locked(&plane->mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:871
> [160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
> [160176] #1 0xffffffff830fc620 at drm_atomic_helper_check_planes+0xb0
> [160176] #2 0xffffffff831e0f11 at intel_atomic_check+0x1201
> [160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
> [160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
> [160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
> [160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
> [160176] #7 0xffffffff8314a7d7 at
> drm_fb_helper_restore_fbdev_mode_unlocked+0x77
> [160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
> [160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
> [160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
> [160176] #11 0xffffffff80887c36 at cngrab+0x16
> [160176] #12 0xffffffff808ee35c at vpanic+0xec
> [160176] #13 0xffffffff808ee263 at panic+0x43
> [160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
> [160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
> [160176] #16 0xffffffff80cf71ad at trap+0x27d
> [160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
> [160176] WARNING !drm_modeset_is_locked(&plane->mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:871
> [160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
> [160176] #1 0xffffffff830fc620 at drm_atomic_helper_check_planes+0xb0
> [160176] #2 0xffffffff831e0f11 at intel_atomic_check+0x1201
> [160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
> [160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
> [160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
> [160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
> [160176] #7 0xffffffff8314a7d7 at
> drm_fb_helper_restore_fbdev_mode_unlocked+0x77
> [160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
> [160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
> [160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
> [160176] #11 0xffffffff80887c36 at cngrab+0x16
> [160176] #12 0xffffffff808ee35c at vpanic+0xec
> [160176] #13 0xffffffff808ee263 at panic+0x43
> [160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
> [160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
> [160176] #16 0xffffffff80cf71ad at trap+0x27d
> [160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
> [160176] WARNING !drm_modeset_is_locked(&plane->mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:871
> [160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
> [160176] #1 0xffffffff830fc620 at drm_atomic_helper_check_planes+0xb0
> [160176] #2 0xffffffff831e0f11 at intel_atomic_check+0x1201
> [160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
> [160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
> [160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
> [160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
> [160176] #7 0xffffffff8314a7d7 at
> drm_fb_helper_restore_fbdev_mode_unlocked+0x77
> [160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
> [160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
> [160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
> [160176] #11 0xffffffff80887c36 at cngrab+0x16
> [160176] #12 0xffffffff808ee35c at vpanic+0xec
> [160176] #13 0xffffffff808ee263 at panic+0x43
> [160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
> [160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
> [160176] #16 0xffffffff80cf71ad at trap+0x27d
> [160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
> [160176] WARNING !drm_modeset_is_locked(&plane->mutex) failed at
> /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:871
> [160176] #0 0xffffffff82766583 at linux_dump_stack+0x23
> [160176] #1 0xffffffff830fc620 at drm_atomic_helper_check_planes+0xb0
> [160176] #2 0xffffffff831e0f11 at intel_atomic_check+0x1201
> [160176] #3 0xffffffff830fa360 at drm_atomic_check_only+0x400
> [160176] #4 0xffffffff830fa793 at drm_atomic_commit+0x13
> [160176] #5 0xffffffff83107948 at drm_client_modeset_commit_atomic+0x148
> [160176] #6 0xffffffff83107671 at drm_client_modeset_commit_force+0x71
> [160176] #7 0xffffffff8314a7d7 at
> drm_fb_helper_restore_fbdev_mode_unlocked+0x77
> [160176] #8 0xffffffff831445d1 at vt_kms_postswitch+0x191
> [160176] #9 0xffffffff8076202b at vt_window_switch+0x12b
> [160176] #10 0xffffffff8075f12f at vtterm_cngrab+0x1f
> [160176] #11 0xffffffff80887c36 at cngrab+0x16
> [160176] #12 0xffffffff808ee35c at vpanic+0xec
> [160176] #13 0xffffffff808ee263 at panic+0x43
> [160176] #14 0xffffffff80cf7af7 at trap_fatal+0x387
> [160176] #15 0xffffffff80cf7b4f at trap_pfault+0x4f
> [160176] #16 0xffffffff80cf71ad at trap+0x27d
> [160176] #17 0xffffffff80ccf3e8 at calltrap+0x8
> <4>[160176] WARN_ON(!mutex_is_locked(&dev->struct_mutex))
> [160176]
> <4>[160176] WARN_ON(!mutex_is_locked(&fbc->lock))
> [160176]
> <4>[160176]
> WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock))WARN_ON(!mutex_is_locked(&fbc->lock))
> [160176] panic: page fault
> [160176] cpuid = 0
> [160176] time = 1606962312
> [160176] KDB: stack backtrace:
> [160176] db_trace_self_wrapper() at 0xffffffff805df8bb =
> db_trace_self_wrapper+0x2b/frame 0xfffffe018500e3b0
> [160176] vpanic() at 0xffffffff808ee3f1 = vpanic+0x181/frame
> 0xfffffe018500e400
> [160176] panic() at 0xffffffff808ee263 = panic+0x43/frame
> 0xfffffe018500e460
> [160176] trap_fatal() at 0xffffffff80cf7af7 = trap_fatal+0x387/frame
> 0xfffffe018500e4c0
> [160176] trap_pfault() at 0xffffffff80cf7b4f = trap_pfault+0x4f/frame
> 0xfffffe018500e520
> [160176] trap() at 0xffffffff80cf71ad = trap+0x27d/frame 0xfffffe018500e630
> [160176] calltrap() at 0xffffffff80ccf3e8 = calltrap+0x8/frame
> 0xfffffe018500e630
> [160176] --- trap 0xc, rip = 0xffffffff808cbd2c, rsp = 0xfffffe018500e700,
> rbp = 0xfffffe018500e780 ---
> [160176] __mtx_lock_sleep() at 0xffffffff808cbd2c =
> __mtx_lock_sleep+0xfc/frame 0xfffffe018500e780
> [160176] doselwakeup() at 0xffffffff8095fbee = doselwakeup+0xde/frame
> 0xfffffe018500e7c0
> [160176] sowakeup() at 0xffffffff80988c7e = sowakeup+0x1e/frame
> 0xfffffe018500e7f0
> [160176] soisdisconnected() at 0xffffffff8099235a =
> soisdisconnected+0x8a/frame 0xfffffe018500e810
> [160176] unp_disconnect() at 0xffffffff8099a9fe = unp_disconnect+0x12e/frame
> 0xfffffe018500e850
> [160176] uipc_disconnect() at 0xffffffff809982a2 =
> uipc_disconnect+0x42/frame 0xfffffe018500e870
> [160176] soclose() at 0xffffffff8098cc96 = soclose+0x76/frame
> 0xfffffe018500e8d0
> [160176] _fdrop() at 0xffffffff80891eb1 = _fdrop+0x11/frame
> 0xfffffe018500e8f0
> [160176] closef() at 0xffffffff80895098 = closef+0x278/frame
> 0xfffffe018500e980
> [160176] closefp() at 0xffffffff808921d9 = closefp+0x89/frame
> 0xfffffe018500e9c0
> [160176] amd64_syscall() at 0xffffffff80cf8a45 = amd64_syscall+0x755/frame
> 0xfffffe018500eaf0
> [160176] fast_syscall_common() at 0xffffffff80ccfd0e =
> fast_syscall_common+0xf8/frame 0xfffffe018500eaf0
> [160176] --- syscall (6, FreeBSD ELF64, sys_close), rip = 0x8003b0d7a, rsp =
> 0x7fffffffe998, rbp = 0x7fffffffe9b0 ---
> [160176] Uptime: 1d20h29m36s
> [160176] Dumping 6415 out of 32449
> MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
>
> No symbol "zombproc" in current context.
> Reading symbols from /boot/kernel/dtraceall.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/dtraceall.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/dtraceall.ko
> Reading symbols from /boot/kernel/profile.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/profile.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/profile.ko
> Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/opensolaris.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/opensolaris.ko
> Reading symbols from /boot/kernel/dtrace.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/dtrace.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/dtrace.ko
> Reading symbols from /boot/kernel/systrace_freebsd32.ko...Reading symbols
> from /usr/lib/debug//boot/kernel/systrace_freebsd32.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/systrace_freebsd32.ko
> Reading symbols from /boot/kernel/systrace.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/systrace.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/systrace.ko
> Reading symbols from /boot/kernel/sdt.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/sdt.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/sdt.ko
> Reading symbols from /boot/kernel/fasttrap.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/fasttrap.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/fasttrap.ko
> Reading symbols from /boot/kernel/fbt.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/fbt.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/fbt.ko
> Reading symbols from /boot/kernel/dtnfscl.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/dtnfscl.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/dtnfscl.ko
> Reading symbols from /boot/kernel/dtmalloc.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/dtmalloc.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/dtmalloc.ko
> Reading symbols from /boot/modules/sysctlinfo.ko...done.
> Loaded symbols for /boot/modules/sysctlinfo.ko
> Reading symbols from /boot/kernel/cc_htcp.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/cc_htcp.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/cc_htcp.ko
> Reading symbols from /boot/kernel/lindebugfs.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/lindebugfs.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/lindebugfs.ko
> Reading symbols from /boot/kernel/linuxkpi.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/linuxkpi.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/linuxkpi.ko
> Reading symbols from /boot/kernel/pchtherm.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/pchtherm.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/pchtherm.ko
> Reading symbols from /boot/kernel/drm.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/drm.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/drm.ko
> Reading symbols from /boot/kernel/linuxkpi_gplv2.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/linuxkpi_gplv2.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/linuxkpi_gplv2.ko
> Reading symbols from /boot/kernel/i915kms.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/i915kms.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/i915kms.ko
> Reading symbols from /boot/modules/i915_kbl_dmc_ver1_04_bin.ko...done.
> Loaded symbols for /boot/modules/i915_kbl_dmc_ver1_04_bin.ko
> Reading symbols from /boot/kernel/mac_ntpd.ko...Reading symbols from
> /usr/lib/debug//boot/kernel/mac_ntpd.ko.debug...done.
> done.
> Loaded symbols for /boot/kernel/mac_ntpd.ko
> #0  doadump (textdump=1) at src/sys/amd64/include/pcpu_aux.h:55
> 55		__asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu,
> (kgdb) q
>
> Command exit status: 0
> Script done on Thu Dec  3 07:13:48 2020
>
> kkgdb is a shell script of mine that prepends /usr/libexec to PATH and
> exec's kgdb with the given command line. That shell script makes life
> in kgdb bearable.
>
> The minidump is available on request.
>
> Is this a known case?
>
> --
> Trond.
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>


-- 
Mateusz Guzik <mjguzik gmail.com>

From hps at selasky.org  Thu Dec  3 10:47:00 2020
From: hps at selasky.org (Hans Petter Selasky)
Date: Thu, 3 Dec 2020 11:46:49 +0100
Subject: page fault due to close(2), possibly drm and i915kms related
In-Reply-To: <8b62fa1c-8d22-b0c5-239d-56f0bcad081@ximalas.info>
References: <8b62fa1c-8d22-b0c5-239d-56f0bcad081@ximalas.info>
Message-ID: <c204cbdc-b950-0285-2f5f-86928c9cf378@selasky.org>

On 12/3/20 11:43 AM, Trond Endrest?l wrote:
> [160176] --- trap 0xc, rip = 0xffffffff808cbd2c, rsp = 0xfffffe018500e700, rbp = 0xfffffe018500e780 ---
> [160176] __mtx_lock_sleep() at 0xffffffff808cbd2c = __mtx_lock_sleep+0xfc/frame 0xfffffe018500e780
> [160176] doselwakeup() at 0xffffffff8095fbee = doselwakeup+0xde/frame 0xfffffe018500e7c0
> [160176] sowakeup() at 0xffffffff80988c7e = sowakeup+0x1e/frame 0xfffffe018500e7f0
> [160176] soisdisconnected() at 0xffffffff8099235a = soisdisconnected+0x8a/frame 0xfffffe018500e810
> [160176] unp_disconnect() at 0xffffffff8099a9fe = unp_disconnect+0x12e/frame 0xfffffe018500e850
> [160176] uipc_disconnect() at 0xffffffff809982a2 = uipc_disconnect+0x42/frame 0xfffffe018500e870
> [160176] soclose() at 0xffffffff8098cc96 = soclose+0x76/frame 0xfffffe018500e8d0
> [160176] _fdrop() at 0xffffffff80891eb1 = _fdrop+0x11/frame 0xfffffe018500e8f0
> [160176] closef() at 0xffffffff80895098 = closef+0x278/frame 0xfffffe018500e980
> [160176] closefp() at 0xffffffff808921d9 = closefp+0x89/frame 0xfffffe018500e9c0
> [160176] amd64_syscall() at 0xffffffff80cf8a45 = amd64_syscall+0x755/frame 0xfffffe018500eaf0
> [160176] fast_syscall_common() at 0xffffffff80ccfd0e = fast_syscall_common+0xf8/frame 0xfffffe018500eaf0
> [160176] --- syscall (6, FreeBSD ELF64, sys_close), rip = 0x8003b0d7a, rsp = 0x7fffffffe998, rbp = 0x7fffffffe9b0 ---
> [160176] Uptime: 1d20h29m36s
> [160176] Dumping 6415 out of 32449 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%

I wonder if this issue was fixed by:

https://svnweb.freebsd.org/changeset/base/368271

--HPS

From trond.endrestol at ximalas.info  Thu Dec  3 10:53:23 2020
From: trond.endrestol at ximalas.info (=?UTF-8?Q?Trond_Endrest=C3=B8l?=)
Date: Thu, 3 Dec 2020 11:53:18 +0100 (CET)
Subject: page fault due to close(2), possibly drm and i915kms related
In-Reply-To: <CAGudoHENrDzV=uFU7wEzLZbwOw6OR9TuUjas2jkchon0JDzEbg@mail.gmail.com>
References: <8b62fa1c-8d22-b0c5-239d-56f0bcad081@ximalas.info>
 <CAGudoHENrDzV=uFU7wEzLZbwOw6OR9TuUjas2jkchon0JDzEbg@mail.gmail.com>
Message-ID: <3193e597-ec45-b9f-aaf3-1fa0a8174365@ximalas.info>

On Thu, 3 Dec 2020 11:45+0100, Mateusz Guzik wrote:

> This should be fixed by r368271

Thank you, guys. I'll upgrade my laptop when I get home.

--
Trond.

From chuck at freebsd.org  Thu Dec  3 21:09:05 2020
From: chuck at freebsd.org (Chuck Tuffli)
Date: Thu, 3 Dec 2020 13:08:52 -0800
Subject: port build fails with missing sys/smr_types.h
Message-ID: <CAKAYmMJ0WbDXcamCHv1WL1Vpabm1ypKDOCkgf2yrGfLto=dHmw@mail.gmail.com>

Hi

I'm trying to fix the build of qemu-utils but am seeing failures on
CURRENT (13.0-HEAD-9e082d278b9) like:

In file included from util/oslib-posix.c:50:
In file included from /usr/include/sys/user.h:51:
In file included from /usr/include/sys/proc.h:50:
/usr/include/sys/filedesc.h:47:10: fatal error: 'sys/smr_types.h' file not found
#include <sys/smr_types.h>
         ^~~~~~~~~~~~~~~~~

# uname -a
FreeBSD sv0.tuffli.net 13.0-HEAD-9e082d278b9 FreeBSD
13.0-HEAD-9e082d278b9 #0 9e082d278b91-c254726(HEAD)-dirty: Fri Nov 27
00:09:50 PST 2020
root at freebsd:/build/9e082d278b9/obj/build/9e082d278b9/src/amd64.amd64/sys/GENERIC-NODEBUG
 amd64
# ls -l /usr/include/sys/*smr*
-r--r--r--  1 root  wheel  1988 Nov 30 14:04 /usr/include/sys/_smr.h
-r--r--r--  1 root  wheel  7822 Nov 30 14:04 /usr/include/sys/smr.h

So it appears the file is missing. Any ideas?

--chuck

From asomers at freebsd.org  Thu Dec  3 23:02:02 2020
From: asomers at freebsd.org (Alan Somers)
Date: Thu, 3 Dec 2020 16:01:49 -0700
Subject: port build fails with missing sys/smr_types.h
In-Reply-To: <CAKAYmMJ0WbDXcamCHv1WL1Vpabm1ypKDOCkgf2yrGfLto=dHmw@mail.gmail.com>
References: <CAKAYmMJ0WbDXcamCHv1WL1Vpabm1ypKDOCkgf2yrGfLto=dHmw@mail.gmail.com>
Message-ID: <CAOtMX2ig1X9T1mpq3L9OjNehC82dwNte9c9vVDrsACBf6vErGw@mail.gmail.com>

On Thu, Dec 3, 2020 at 2:09 PM Chuck Tuffli <chuck at freebsd.org> wrote:

> Hi
>
> I'm trying to fix the build of qemu-utils but am seeing failures on
> CURRENT (13.0-HEAD-9e082d278b9) like:
>
> In file included from util/oslib-posix.c:50:
> In file included from /usr/include/sys/user.h:51:
> In file included from /usr/include/sys/proc.h:50:
> /usr/include/sys/filedesc.h:47:10: fatal error: 'sys/smr_types.h' file not
> found
> #include <sys/smr_types.h>
>          ^~~~~~~~~~~~~~~~~
>
> # uname -a
> FreeBSD sv0.tuffli.net 13.0-HEAD-9e082d278b9 FreeBSD
> 13.0-HEAD-9e082d278b9 #0 9e082d278b91-c254726(HEAD)-dirty: Fri Nov 27
> 00:09:50 PST 2020
> root at freebsd
> :/build/9e082d278b9/obj/build/9e082d278b9/src/amd64.amd64/sys/GENERIC-NODEBUG
>  amd64
> # ls -l /usr/include/sys/*smr*
> -r--r--r--  1 root  wheel  1988 Nov 30 14:04 /usr/include/sys/_smr.h
> -r--r--r--  1 root  wheel  7822 Nov 30 14:04 /usr/include/sys/smr.h
>
> So it appears the file is missing. Any ideas?
>
> --chuck
>

That file doesn't get installed into /usr/include, but it exists in
/usr/src.  A few ports need /usr/src.  See  devel/py-libzfs/Makefile for an
example of how to find it.
-Alan

From yuripv at yuripv.dev  Thu Dec  3 23:14:49 2020
From: yuripv at yuripv.dev (Yuri Pankov)
Date: Fri, 4 Dec 2020 02:14:43 +0300
Subject: port build fails with missing sys/smr_types.h
In-Reply-To: <CAOtMX2ig1X9T1mpq3L9OjNehC82dwNte9c9vVDrsACBf6vErGw@mail.gmail.com>
References: <CAKAYmMJ0WbDXcamCHv1WL1Vpabm1ypKDOCkgf2yrGfLto=dHmw@mail.gmail.com>
 <CAOtMX2ig1X9T1mpq3L9OjNehC82dwNte9c9vVDrsACBf6vErGw@mail.gmail.com>
Message-ID: <6aa60217-32bb-32b3-9264-520962519743@yuripv.dev>

Alan Somers wrote:
> On Thu, Dec 3, 2020 at 2:09 PM Chuck Tuffli <chuck at freebsd.org> wrote:
> 
>> Hi
>>
>> I'm trying to fix the build of qemu-utils but am seeing failures on
>> CURRENT (13.0-HEAD-9e082d278b9) like:
>>
>> In file included from util/oslib-posix.c:50:
>> In file included from /usr/include/sys/user.h:51:
>> In file included from /usr/include/sys/proc.h:50:
>> /usr/include/sys/filedesc.h:47:10: fatal error: 'sys/smr_types.h' file not
>> found
>> #include <sys/smr_types.h>
>>           ^~~~~~~~~~~~~~~~~
>>
>> # uname -a
>> FreeBSD sv0.tuffli.net 13.0-HEAD-9e082d278b9 FreeBSD
>> 13.0-HEAD-9e082d278b9 #0 9e082d278b91-c254726(HEAD)-dirty: Fri Nov 27
>> 00:09:50 PST 2020
>> root at freebsd
>> :/build/9e082d278b9/obj/build/9e082d278b9/src/amd64.amd64/sys/GENERIC-NODEBUG
>>   amd64
>> # ls -l /usr/include/sys/*smr*
>> -r--r--r--  1 root  wheel  1988 Nov 30 14:04 /usr/include/sys/_smr.h
>> -r--r--r--  1 root  wheel  7822 Nov 30 14:04 /usr/include/sys/smr.h
>>
>> So it appears the file is missing. Any ideas?
>>
>> --chuck
>>
> 
> That file doesn't get installed into /usr/include, but it exists in
> /usr/src.  A few ports need /usr/src.  See  devel/py-libzfs/Makefile for an
> example of how to find it.

But it's included from the header that *is* in /usr/include/, not 
directly by external code.  Should not such dependencies all be in 
/usr/include/?

From markj at freebsd.org  Thu Dec  3 23:18:20 2020
From: markj at freebsd.org (Mark Johnston)
Date: Thu, 3 Dec 2020 18:18:12 -0500
Subject: port build fails with missing sys/smr_types.h
In-Reply-To: <CAKAYmMJ0WbDXcamCHv1WL1Vpabm1ypKDOCkgf2yrGfLto=dHmw@mail.gmail.com>
References: <CAKAYmMJ0WbDXcamCHv1WL1Vpabm1ypKDOCkgf2yrGfLto=dHmw@mail.gmail.com>
Message-ID: <X8lyNECcN3jnunKh@raichu>

On Thu, Dec 03, 2020 at 01:08:52PM -0800, Chuck Tuffli wrote:
> Hi
> 
> I'm trying to fix the build of qemu-utils but am seeing failures on
> CURRENT (13.0-HEAD-9e082d278b9) like:
> 
> In file included from util/oslib-posix.c:50:
> In file included from /usr/include/sys/user.h:51:
> In file included from /usr/include/sys/proc.h:50:
> /usr/include/sys/filedesc.h:47:10: fatal error: 'sys/smr_types.h' file not found
> #include <sys/smr_types.h>
>          ^~~~~~~~~~~~~~~~~
> 
> # uname -a
> FreeBSD sv0.tuffli.net 13.0-HEAD-9e082d278b9 FreeBSD
> 13.0-HEAD-9e082d278b9 #0 9e082d278b91-c254726(HEAD)-dirty: Fri Nov 27
> 00:09:50 PST 2020
> root at freebsd:/build/9e082d278b9/obj/build/9e082d278b9/src/amd64.amd64/sys/GENERIC-NODEBUG
>  amd64
> # ls -l /usr/include/sys/*smr*
> -r--r--r--  1 root  wheel  1988 Nov 30 14:04 /usr/include/sys/_smr.h
> -r--r--r--  1 root  wheel  7822 Nov 30 14:04 /usr/include/sys/smr.h
> 
> So it appears the file is missing. Any ideas?

How old is your world?  I have /usr/include/sys/smr_types.h on my
systems.  It's present on freefall as well.

From chuck at freebsd.org  Thu Dec  3 23:42:53 2020
From: chuck at freebsd.org (Chuck Tuffli)
Date: Thu, 3 Dec 2020 15:42:40 -0800
Subject: port build fails with missing sys/smr_types.h
In-Reply-To: <X8lyNECcN3jnunKh@raichu>
References: <CAKAYmMJ0WbDXcamCHv1WL1Vpabm1ypKDOCkgf2yrGfLto=dHmw@mail.gmail.com>
 <X8lyNECcN3jnunKh@raichu>
Message-ID: <CAKAYmML2eq5cJwG4GJmLA8QAqxQ_zopM5sTEiNUKr=+7DXhAfw@mail.gmail.com>

On Thu, Dec 3, 2020 at 3:18 PM Mark Johnston <markj at freebsd.org> wrote:
>
> On Thu, Dec 03, 2020 at 01:08:52PM -0800, Chuck Tuffli wrote:
> > Hi
> >
> > I'm trying to fix the build of qemu-utils but am seeing failures on
> > CURRENT (13.0-HEAD-9e082d278b9) like:
> >
> > In file included from util/oslib-posix.c:50:
> > In file included from /usr/include/sys/user.h:51:
> > In file included from /usr/include/sys/proc.h:50:
> > /usr/include/sys/filedesc.h:47:10: fatal error: 'sys/smr_types.h' file not found
> > #include <sys/smr_types.h>
> >          ^~~~~~~~~~~~~~~~~
> >
> > # uname -a
> > FreeBSD sv0.tuffli.net 13.0-HEAD-9e082d278b9 FreeBSD
> > 13.0-HEAD-9e082d278b9 #0 9e082d278b91-c254726(HEAD)-dirty: Fri Nov 27
> > 00:09:50 PST 2020
> > root at freebsd:/build/9e082d278b9/obj/build/9e082d278b9/src/amd64.amd64/sys/GENERIC-NODEBUG
> >  amd64
> > # ls -l /usr/include/sys/*smr*
> > -r--r--r--  1 root  wheel  1988 Nov 30 14:04 /usr/include/sys/_smr.h
> > -r--r--r--  1 root  wheel  7822 Nov 30 14:04 /usr/include/sys/smr.h
> >
> > So it appears the file is missing. Any ideas?
>
> How old is your world?  I have /usr/include/sys/smr_types.h on my
> systems.  It's present on freefall as well.

It is the FreeBSD-13.0-CURRENT-amd64-20201126-9e082d278b9 snapshot. If
this is fixed in recent snapshots, I can move to one of those.

--chuck

From grahamperrin at gmail.com  Fri Dec  4 00:25:20 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Fri, 4 Dec 2020 00:25:15 +0000
Subject: Installers for FreeBSD fail to boot HP ProBook 440 G7
Message-ID: <fb0d6708-626f-e8e0-b0fc-b3e40d8594a8@gmail.com>

Where installers for FreeBSD 12.2 and 13.0-CURRENT fail to boot, the 
installer for OmniOS community edition succeeds.


Photographs and other details at 
<https://old.reddit.com/r/freebsd/comments/ir90ra/hp_probook_440_g7/gejo49g/>; 
"I'm advised that it's symptomatic of the kernel not loading.".


From waitman at waitman.net  Fri Dec  4 00:34:53 2020
From: waitman at waitman.net (Waitman Gobble)
Date: Thu, 03 Dec 2020 20:34:50 -0400
Subject: Installers for FreeBSD fail to boot HP ProBook 440 G7
In-Reply-To: <fb0d6708-626f-e8e0-b0fc-b3e40d8594a8@gmail.com>
References: <fb0d6708-626f-e8e0-b0fc-b3e40d8594a8@gmail.com>
Message-ID: <d811d17c93ba123609c55e6776880d2d@waitman.net>

On 2020-12-03 20:25, Graham Perrin wrote:
> Where installers for FreeBSD 12.2 and 13.0-CURRENT fail to boot, the
> installer for OmniOS community edition succeeds.
> 
> 
> Photographs and other details at
> <https://old.reddit.com/r/freebsd/comments/ir90ra/hp_probook_440_g7/gejo49g/>;
> "I'm advised that it's symptomatic of the kernel not loading.".
> 
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to 
> "freebsd-current-unsubscribe at freebsd.org"

Something to check out?
That machine has Intel and NVidia gpu, you should check the BIOS 
settings. I have a Lenovo laptop that won't boot if it's set in BIOS to 
'detect/auto', I think it's called Optimus? But my Dell that also has 
both boots fine although there's no selectable option in BIOS.

-- 
Waitman Gobble

From markj at freebsd.org  Fri Dec  4 00:43:34 2020
From: markj at freebsd.org (Mark Johnston)
Date: Thu, 3 Dec 2020 19:43:28 -0500
Subject: port build fails with missing sys/smr_types.h
In-Reply-To: <CAKAYmML2eq5cJwG4GJmLA8QAqxQ_zopM5sTEiNUKr=+7DXhAfw@mail.gmail.com>
References: <CAKAYmMJ0WbDXcamCHv1WL1Vpabm1ypKDOCkgf2yrGfLto=dHmw@mail.gmail.com>
 <X8lyNECcN3jnunKh@raichu>
 <CAKAYmML2eq5cJwG4GJmLA8QAqxQ_zopM5sTEiNUKr=+7DXhAfw@mail.gmail.com>
Message-ID: <X8mGML3ibLsa/r0Q@raichu>

On Thu, Dec 03, 2020 at 03:42:40PM -0800, Chuck Tuffli wrote:
> On Thu, Dec 3, 2020 at 3:18 PM Mark Johnston <markj at freebsd.org> wrote:
> >
> > On Thu, Dec 03, 2020 at 01:08:52PM -0800, Chuck Tuffli wrote:
> > > Hi
> > >
> > > I'm trying to fix the build of qemu-utils but am seeing failures on
> > > CURRENT (13.0-HEAD-9e082d278b9) like:
> > >
> > > In file included from util/oslib-posix.c:50:
> > > In file included from /usr/include/sys/user.h:51:
> > > In file included from /usr/include/sys/proc.h:50:
> > > /usr/include/sys/filedesc.h:47:10: fatal error: 'sys/smr_types.h' file not found
> > > #include <sys/smr_types.h>
> > >          ^~~~~~~~~~~~~~~~~
> > >
> > > # uname -a
> > > FreeBSD sv0.tuffli.net 13.0-HEAD-9e082d278b9 FreeBSD
> > > 13.0-HEAD-9e082d278b9 #0 9e082d278b91-c254726(HEAD)-dirty: Fri Nov 27
> > > 00:09:50 PST 2020
> > > root at freebsd:/build/9e082d278b9/obj/build/9e082d278b9/src/amd64.amd64/sys/GENERIC-NODEBUG
> > >  amd64
> > > # ls -l /usr/include/sys/*smr*
> > > -r--r--r--  1 root  wheel  1988 Nov 30 14:04 /usr/include/sys/_smr.h
> > > -r--r--r--  1 root  wheel  7822 Nov 30 14:04 /usr/include/sys/smr.h
> > >
> > > So it appears the file is missing. Any ideas?
> >
> > How old is your world?  I have /usr/include/sys/smr_types.h on my
> > systems.  It's present on freefall as well.
> 
> It is the FreeBSD-13.0-CURRENT-amd64-20201126-9e082d278b9 snapshot. If
> this is fixed in recent snapshots, I can move to one of those.

$ fetch http://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/13.0-CURRENT/amd64/20201126/FreeBSD-13.0-CURRENT-amd64-20201126-9e082d278b9.raw.xz
$ unxz FreeBSD-13.0-CURRENT-amd64-20201126-9e082d278b9.raw.xz
$ sudo mdconfig -a -f FreeBSD-13.0-CURRENT-amd64-20201126-9e082d278b9.raw
md0
$ sudo mount /dev/md0p4 /mnt
$ stat /mnt/usr/include/sys/smr_types.h
544 241404 -r--r--r-- 1 root wheel 554933 4985 "Nov 26 03:57:51 2020" "Nov 26 03:51:14 2020" "Nov 26 03:58:26 2020" "Nov 26 03:51:14 2020" 32768 16 0 /mnt/usr/include/sys/smr_types.h
$

So I'm not sure what's going on in your case.  smr_types.h was added a
number of months ago.

From grahamperrin at gmail.com  Fri Dec  4 06:47:31 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Fri, 4 Dec 2020 06:47:26 +0000
Subject: Installers for FreeBSD fail to boot HP ProBook 440 G7: discrete
 graphics
In-Reply-To: <d811d17c93ba123609c55e6776880d2d@waitman.net>
References: <fb0d6708-626f-e8e0-b0fc-b3e40d8594a8@gmail.com>
 <d811d17c93ba123609c55e6776880d2d@waitman.net>
Message-ID: <338b0e19-9220-1d21-a105-5408ce1afdc1@gmail.com>

On 04/12/2020 00:34, Waitman Gobble wrote:
> On 2020-12-03 20:25, Graham Perrin wrote:
>> Where installers for FreeBSD 12.2 and 13.0-CURRENT fail to boot, the
>> installer for OmniOS community edition succeeds.
>>
>>
>> Photographs and other details at
>> <https://old.reddit.com/r/freebsd/comments/ir90ra/hp_probook_440_g7/gejo49g/>; 
>>
>> "I'm advised that it's symptomatic of the kernel not loading.". ?
>
> Something to check out?
> That machine has Intel and NVidia gpu, you should check the BIOS 
> settings. I have a Lenovo laptop that won't boot if it's set in BIOS 
> to 'detect/auto', I think it's called Optimus? But my Dell that also 
> has both boots fine although there's no selectable option in BIOS.
>

Thanks, the BIOS on this machine allows me to set an amount of video 
memory, and so on, but I see nothing relating to the discrete GPU.


(I see HP support articles on how to disable discrete graphics on some 
other models, but not the ProBook 440 G7.)

From grahamperrin at gmail.com  Fri Dec  4 08:44:29 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Fri, 4 Dec 2020 08:44:25 +0000
Subject: (244906) installers for FreeBSD fail to boot HP ProBook 440 G7
In-Reply-To: <fb0d6708-626f-e8e0-b0fc-b3e40d8594a8@gmail.com>
References: <fb0d6708-626f-e8e0-b0fc-b3e40d8594a8@gmail.com>
Message-ID: <bb82aa4b-986b-f560-538a-a11e197abddd@gmail.com>

This is now identified as FreeBSD bug 244906:


kernel booted by loader.efi on VMware Fusion crashes in EFI firmware


From tsoome at me.com  Fri Dec  4 09:24:39 2020
From: tsoome at me.com (Toomas Soome)
Date: Fri, 4 Dec 2020 11:24:25 +0200
Subject: review request: loader: implement framebuffer console
Message-ID: <EAD2C1D7-8D64-43D4-A2EC-E21FE3CC733B@me.com>

hi!

I have been working on proper framebuffer support on FreeBSD loader and there is the current state: https://reviews.freebsd.org/D27420 <https://reviews.freebsd.org/D27420>

All feedback is welcome, and especially if you can spare some time for testing:)

thanks,
toomas

From chuck at freebsd.org  Fri Dec  4 18:50:15 2020
From: chuck at freebsd.org (Chuck Tuffli)
Date: Fri, 4 Dec 2020 10:50:03 -0800
Subject: port build fails with missing sys/smr_types.h
In-Reply-To: <X8mGML3ibLsa/r0Q@raichu>
References: <CAKAYmMJ0WbDXcamCHv1WL1Vpabm1ypKDOCkgf2yrGfLto=dHmw@mail.gmail.com>
 <X8lyNECcN3jnunKh@raichu>
 <CAKAYmML2eq5cJwG4GJmLA8QAqxQ_zopM5sTEiNUKr=+7DXhAfw@mail.gmail.com>
 <X8mGML3ibLsa/r0Q@raichu>
Message-ID: <CAKAYmM+kdzm-pNyEQjci5rSE0p50BenaXUEuLxi3YYM9gFAWtg@mail.gmail.com>

On Thu, Dec 3, 2020 at 4:43 PM Mark Johnston <markj at freebsd.org> wrote:
...
> $ fetch http://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/13.0-CURRENT/amd64/20201126/FreeBSD-13.0-CURRENT-amd64-20201126-9e082d278b9.raw.xz
> $ unxz FreeBSD-13.0-CURRENT-amd64-20201126-9e082d278b9.raw.xz
> $ sudo mdconfig -a -f FreeBSD-13.0-CURRENT-amd64-20201126-9e082d278b9.raw
> md0
> $ sudo mount /dev/md0p4 /mnt
> $ stat /mnt/usr/include/sys/smr_types.h
> 544 241404 -r--r--r-- 1 root wheel 554933 4985 "Nov 26 03:57:51 2020" "Nov 26 03:51:14 2020" "Nov 26 03:58:26 2020" "Nov 26 03:51:14 2020" 32768 16 0 /mnt/usr/include/sys/smr_types.h
> $
>
> So I'm not sure what's going on in your case.  smr_types.h was added a
> number of months ago.

Weird, it looks like I borked my system somehow. But thank you, that
helped immensely!

--chuck

From emaste at freebsd.org  Fri Dec  4 19:28:58 2020
From: emaste at freebsd.org (Ed Maste)
Date: Fri, 4 Dec 2020 14:28:44 -0500
Subject: Removing obsolete GDB 6.1.1 for FreeBSD 13
In-Reply-To: <CAPyFy2AxAycToQxTgGq+WMfED1UiRGgPzox6c8A49P6gErgwJw@mail.gmail.com>
References: <CAPyFy2AxAycToQxTgGq+WMfED1UiRGgPzox6c8A49P6gErgwJw@mail.gmail.com>
Message-ID: <CAPyFy2Dp-+iYbmYV+ybvozZgweb7rT=WjEPgzg_51NXcXvBzuQ@mail.gmail.com>

Adding the FreeBSD-stable list to CC for more visibility.

On Wed, 2 Dec 2020 at 12:43, Ed Maste <emaste at freebsd.org> wrote:
>
> I would like to remove GDB 6.1.1 before FreeBSD 13, and propose to
> switch the GDB knob to default to NO in the near future. If the
> crashinfo utility and related man pages do not already include
> references to installing the gdb port/package I will add those before
> making the change.

The crashinfo man page now references the gdb port/package, and
crashinfo itself emits a message that the port/package should be
installed if kgdb is not found.

GDB's proposed retirement has now been added to
https://wiki.freebsd.org/DeprecationPlan.

I expect to make GDB default to NO next week, and then remove it from
the tree a week or two later, if there is no compelling objection.

From gbe at freebsd.org  Fri Dec  4 19:59:44 2020
From: gbe at freebsd.org (Gordon Bergling)
Date: Fri, 4 Dec 2020 20:59:43 +0100
Subject: review request: loader: implement framebuffer console
In-Reply-To: <EAD2C1D7-8D64-43D4-A2EC-E21FE3CC733B@me.com>
References: <EAD2C1D7-8D64-43D4-A2EC-E21FE3CC733B@me.com>
Message-ID: <X8qVL5yPQ5J3mb+T@lion.0xfce3.net>

Hi Toomas,

thanks for working on this. I have a build running and report back
the results from Hyper-V FreeBSD instance.

--Gordon

PS: A few months ago I had a look at all the OpenSolaris incarnations and this
feature was something I had on my TODO list for FreeBSD for a very long time. :)

On Fri, Dec 04, 2020 at 11:24:25AM +0200, Toomas Soome wrote:
> hi!
> 
> I have been working on proper framebuffer support on FreeBSD loader and there is the current state: https://reviews.freebsd.org/D27420 <https://reviews.freebsd.org/D27420>
> 
> All feedback is welcome, and especially if you can spare some time for testing:)
> 
> thanks,
> toomas
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"

-- 

From gbe at freebsd.org  Fri Dec  4 21:03:53 2020
From: gbe at freebsd.org (Gordon Bergling)
Date: Fri, 4 Dec 2020 22:03:52 +0100
Subject: review request: loader: implement framebuffer console
In-Reply-To: <EAD2C1D7-8D64-43D4-A2EC-E21FE3CC733B@me.com>
References: <EAD2C1D7-8D64-43D4-A2EC-E21FE3CC733B@me.com>
Message-ID: <X8qkOA5lOYagLagV@lion.0xfce3.net>

Tested on a recent -CURRENT, no problems seen so far.

Is there a special src.conf setting that is necessary for a
complete build / test sequence.

--Gordon

On Fri, Dec 04, 2020 at 11:24:25AM +0200, Toomas Soome wrote:
> I have been working on proper framebuffer support on FreeBSD loader and there is the current state: https://reviews.freebsd.org/D27420 <https://reviews.freebsd.org/D27420>
> 
> All feedback is welcome, and especially if you can spare some time for testing:)
> 
> thanks,
> toomas
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"

From tsoome at me.com  Fri Dec  4 21:23:53 2020
From: tsoome at me.com (Toomas Soome)
Date: Fri, 4 Dec 2020 23:23:41 +0200
Subject: review request: loader: implement framebuffer console
In-Reply-To: <X8qkOA5lOYagLagV@lion.0xfce3.net>
References: <EAD2C1D7-8D64-43D4-A2EC-E21FE3CC733B@me.com>
 <X8qkOA5lOYagLagV@lion.0xfce3.net>
Message-ID: <9906496E-E477-4AD9-8ADB-7B78E691B230@me.com>


> On 4. Dec 2020, at 23:03, Gordon Bergling <gbe at freebsd.org> wrote:
> 
> Tested on a recent -CURRENT, no problems seen so far.
> 
> Is there a special src.conf setting that is necessary for a
> complete build / test sequence.
> 
> --Gordon

No, except that the last update did change default for bios loader to text and did add the knob to change that to gfx mode.

For test, the default mode should be readable and logo/brand images ok and the console after boot usable as well. The resolution switch (gop or vbe) should end up with usable screen as well, and when you enter menu, the boot menu should be ok.

gop get/vbe get will list current mode, show screen.font will tell font size.

Currently it is known the 8-bit depth may have issues in some systems (bios, UEFI only does have 32-bit depth).

thanks,
toomas

> 
> On Fri, Dec 04, 2020 at 11:24:25AM +0200, Toomas Soome wrote:
>> I have been working on proper framebuffer support on FreeBSD loader and there is the current state: https://reviews.freebsd.org/D27420 <https://reviews.freebsd.org/D27420>
>> 
>> All feedback is welcome, and especially if you can spare some time for testing:)
>> 
>> thanks,
>> toomas
>> _______________________________________________
>> freebsd-current at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"


From emaste at freebsd.org  Fri Dec  4 22:18:59 2020
From: emaste at freebsd.org (Ed Maste)
Date: Fri, 4 Dec 2020 17:18:45 -0500
Subject: Deprecating userland a.out support
Message-ID: <CAPyFy2D9Eog6iscH=Dzi1UAh=72hH1BsaomyaA10Hu+n+r9Bfw@mail.gmail.com>

FreeBSD has used ELF binaries/libraries for decades, but still has
support for legacy a.out binaries. Portions of this have been retired
over time, and I propose removing the remaining pieces before FreeBSD
13. I'm not proposing making any change to kernel a.out support, but
users needing userland a.out tools would have to install them from old
FreeBSD releases.

I have opened the following reviews for three tools that still support a.out:

D27478 ldd: Retire a.out support
D27480 gprof: Retire a.out support
D27481 ldconfig: Retire a.out support

If there are no objections I plan to commit these changes before the
end of the month, along with small changes to the mtree file (removing
aout directories) etc.

From dmarquess at gmail.com  Sat Dec  5 06:07:17 2020
From: dmarquess at gmail.com (Dustin Marquess)
Date: Sat, 5 Dec 2020 00:07:02 -0600
Subject: How to clear the 'remove:' line from 'zpool status'
Message-ID: <CAJpsHY63gZdLnUF+Z2w0ENvyJGqokGOj8EVOF3EU9m-B7Sxyqg@mail.gmail.com>

So I stupidly did a 'zpool add' instead of a 'zpool attach'.  Luckily
I was able to 'zpool remove' the device thanks to the remove work done
a while back.

However, now I can't for the life of me get this part of the 'zpool
status' output to go away:

  pool: zroot
 state: ONLINE
  scan: scrub repaired 0B in 00:01:06 with 0 errors on Fri Dec  4 18:18:31 2020
remove: Removal of vdev 1 copied 104K in 0h0m, completed on Fri Dec  4
18:10:08 2020
    72 memory used for removed device mappings
config:

I've tried 'zppol clear', 'zpool scrub', and rebooted.  Is there some
way to clear that 'remove' line? It's irritating my OCD :(.

Thanks!
-Dustin

From gbe at freebsd.org  Sat Dec  5 10:32:49 2020
From: gbe at freebsd.org (Gordon Bergling)
Date: Sat, 5 Dec 2020 11:32:48 +0100
Subject: review request: loader: implement framebuffer console
In-Reply-To: <9906496E-E477-4AD9-8ADB-7B78E691B230@me.com>
References: <EAD2C1D7-8D64-43D4-A2EC-E21FE3CC733B@me.com>
 <X8qkOA5lOYagLagV@lion.0xfce3.net>
 <9906496E-E477-4AD9-8ADB-7B78E691B230@me.com>
Message-ID: <X8th0NgTNm2/5GrV@lion.0xfce3.net>

On Fri, Dec 04, 2020 at 11:23:41PM +0200, Toomas Soome wrote:
> > On 4. Dec 2020, at 23:03, Gordon Bergling <gbe at freebsd.org> wrote:
> > Tested on a recent -CURRENT, no problems seen so far.
> > 
> > Is there a special src.conf setting that is necessary for a
> > complete build / test sequence.
> 
> No, except that the last update did change default for bios loader to text and did add the knob to change that to gfx mode.
> 
> For test, the default mode should be readable and logo/brand images ok and the console after boot usable as well. The resolution switch (gop or vbe) should end up with usable screen as well, and when you enter menu, the boot menu should be ok.
> 
> gop get/vbe get will list current mode, show screen.font will tell font size.
> 
> Currently it is known the 8-bit depth may have issues in some systems (bios, UEFI only does have 32-bit depth).
> 
> thanks,
> toomas

I have set hw.vga.textmode="0" in the /boot/loader.conf and dmesg
reports "VT(efifb): resolution 1024x768" with the patch applied.
A kyua testrun was successfull.

Hope that helps.

--Gordon

> > On Fri, Dec 04, 2020 at 11:24:25AM +0200, Toomas Soome wrote:
> >> I have been working on proper framebuffer support on FreeBSD loader and there is the current state: https://reviews.freebsd.org/D27420 <https://reviews.freebsd.org/D27420>
> >> 
> >> All feedback is welcome, and especially if you can spare some time for testing:)
> >> 
> >> thanks,
> >> toomas

From freebsd at omnilan.de  Sat Dec  5 17:46:35 2020
From: freebsd at omnilan.de (Harry Schmalzbauer)
Date: Sat, 5 Dec 2020 18:46:22 +0100
Subject: rc.d/zpool runs before ada(4) attaches
In-Reply-To: <786faeee90e79aa0175b298ec859265ff57a3129.camel@freebsd.org>
References: <b55604d6-5c23-a590-859c-a52f36386d44@omnilan.de>
 <1439301337.11.1606815206810@localhost>
 <08815f92-742c-2934-e746-fd04ca9b4e16@omnilan.de>
 <286917313.21.1606836130991@localhost>
 <786faeee90e79aa0175b298ec859265ff57a3129.camel@freebsd.org>
Message-ID: <a43531d6-8828-89aa-4d6d-6bcb9fb75cfe@omnilan.de>

Am 01.12.2020 um 16:34 schrieb Ian Lepore::
:
:
:
>> You can define these in /boot/loader.conf:
>> #kern.cam.boot_delay="10000" # Delay (in ms) of root mount for CAM
>> bus
>> #kern.cam.scsi_delay="2000" # Delay (in ms) before probing SCSI
>>
>> Maybe that helps.
>>
>> Ronald.
>>
> Those settings control waiting before mounting root.  Harry's problem
> is that root is mounted quickly, before other drives are ready for zfs.
>   
> The zpool script waits for 'disks'.  It would be nice if the cam
> subsystem had something like a sysctl it set to indicate when initial
> probing for disks was done, then there could be an rc.d/camprobe script
> with 'PROVIDE: disks' which waits for the probing to complete.
>
> -- Ian

Until something described above is available, or anybody is aware of any 
other trick,
here's a tested workaround: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251610

It turned out that also swapon and dumpon suffer from early 
root_hold_wait() release.
For dumpon, cam(4) doesn't even start probing.? Luckily all target:LUNs 
are visible at that earliest stage in rc.d/dumpon.
So that's the point where I check if any real target is in state 
unattached (()) or probing ((aprobe)).
I don't know details of the involved vfs.root_mount_hold sysctl, but 
assume this is dead end currently...

Best regards,
-harry

From trasz at freebsd.org  Sat Dec  5 21:15:18 2020
From: trasz at freebsd.org (Edward Tomasz =?utf-8?Q?Napiera=C5=82a?=)
Date: Sat, 5 Dec 2020 21:15:13 +0000
Subject: rc.d/zpool runs before ada(4) attaches
In-Reply-To: <786faeee90e79aa0175b298ec859265ff57a3129.camel@freebsd.org>
References: <b55604d6-5c23-a590-859c-a52f36386d44@omnilan.de>
 <1439301337.11.1606815206810@localhost>
 <08815f92-742c-2934-e746-fd04ca9b4e16@omnilan.de>
 <286917313.21.1606836130991@localhost>
 <786faeee90e79aa0175b298ec859265ff57a3129.camel@freebsd.org>
Message-ID: <X8v4YcVF+YkEwzcd@brick>

On 1201T0834, Ian Lepore wrote:
> On Tue, 2020-12-01 at 16:22 +0100, Ronald Klop wrote:

[..]

> > You can define these in /boot/loader.conf:
> > #kern.cam.boot_delay="10000" # Delay (in ms) of root mount for CAM
> > bus
> > #kern.cam.scsi_delay="2000" # Delay (in ms) before probing SCSI
> > 
> > Maybe that helps.
> > 
> > Ronald.
> > 
> 
> Those settings control waiting before mounting root.  Harry's problem
> is that root is mounted quickly, before other drives are ready for zfs.
>  
> The zpool script waits for 'disks'.  It would be nice if the cam
> subsystem had something like a sysctl it set to indicate when initial
> probing for disks was done, then there could be an rc.d/camprobe script
> with 'PROVIDE: disks' which waits for the probing to complete.

I believe such a mechanism already exists, although it might be somewhat
misnamed: the vfs.root_mount_hold sysctl.  Some rc scripts use the
root_hold_wait() function, which uses the sysctl.  Perhaps the ZFS
scripts should do the same?

Note that this is somewhat more involved than just CAM - you also need
to wait for GEOM to settle.


From grahamperrin at gmail.com  Sun Dec  6 17:29:18 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Sun, 6 Dec 2020 17:29:12 +0000
Subject: How to clear the 'remove:' line from 'zpool status'
In-Reply-To: <CAJpsHY63gZdLnUF+Z2w0ENvyJGqokGOj8EVOF3EU9m-B7Sxyqg@mail.gmail.com>
References: <CAJpsHY63gZdLnUF+Z2w0ENvyJGqokGOj8EVOF3EU9m-B7Sxyqg@mail.gmail.com>
Message-ID: <e9836eb7-8588-869b-ec4e-9e6ec148c6f7@gmail.com>

On 05/12/2020 06:07, Dustin Marquess wrote:

> So I stupidly did a 'zpool add' instead of a 'zpool attach'.  Luckily
> I was able to 'zpool remove' the device thanks to the remove work done
> a while back.
>
> However, now I can't for the life of me get this part of the 'zpool
> status' output to go away:
>
>    pool: zroot
>   state: ONLINE
>    scan: scrub repaired 0B in 00:01:06 with 0 errors on Fri Dec  4 18:18:31 2020
> remove: Removal of vdev 1 copied 104K in 0h0m, completed on Fri Dec  4
> 18:10:08 2020
>      72 memory used for removed device mappings
> config:
>
> I've tried 'zppol clear', 'zpool scrub', and rebooted.  Is there some
> way to clear that 'remove' line? It's irritating my OCD :(.
>
> Thanks!
> -Dustin


Maybe:


man zpool-labelclear


From ronald-lists at klop.ws  Sun Dec  6 20:51:47 2020
From: ronald-lists at klop.ws (Ronald Klop)
Date: Sun, 06 Dec 2020 21:51:44 +0100
Subject: How to clear the 'remove:' line from 'zpool status'
In-Reply-To: <CAJpsHY63gZdLnUF+Z2w0ENvyJGqokGOj8EVOF3EU9m-B7Sxyqg@mail.gmail.com>
References: <CAJpsHY63gZdLnUF+Z2w0ENvyJGqokGOj8EVOF3EU9m-B7Sxyqg@mail.gmail.com>
Message-ID: <op.0u71kikbkndu52@sjakie>

On Sat, 05 Dec 2020 07:07:02 +0100, Dustin Marquess <dmarquess at gmail.com>  
wrote:

> So I stupidly did a 'zpool add' instead of a 'zpool attach'.  Luckily
> I was able to 'zpool remove' the device thanks to the remove work done
> a while back.
>
> However, now I can't for the life of me get this part of the 'zpool
> status' output to go away:
>
>   pool: zroot
>  state: ONLINE
>   scan: scrub repaired 0B in 00:01:06 with 0 errors on Fri Dec  4  
> 18:18:31 2020
> remove: Removal of vdev 1 copied 104K in 0h0m, completed on Fri Dec  4
> 18:10:08 2020
>     72 memory used for removed device mappings
> config:
>
> I've tried 'zppol clear', 'zpool scrub', and rebooted.  Is there some
> way to clear that 'remove' line? It's irritating my OCD :(.
>
> Thanks!
> -Dustin


Apply attached diff and rebuild world, Untested. Might have unwanted  
effects.

Regards,
Ronald.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zpool_main.c.diff
Type: application/octet-stream
Size: 618 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20201206/bf3decb6/attachment.obj>

From ronald-lists at klop.ws  Sun Dec  6 21:01:31 2020
From: ronald-lists at klop.ws (Ronald Klop)
Date: Sun, 06 Dec 2020 22:01:29 +0100
Subject: How to clear the 'remove:' line from 'zpool status'
Message-ID: <op.0u710raikndu52@sjakie>



From ronald-lists at klop.ws  Sun Dec  6 21:11:31 2020
From: ronald-lists at klop.ws (Ronald Klop)
Date: Sun, 06 Dec 2020 22:11:29 +0100
Subject: How to clear the 'remove:' line from 'zpool status'
Message-ID: <op.0u72hfyqkndu52@sjakie>



From ronald-lists at klop.ws  Sun Dec  6 21:21:30 2020
From: ronald-lists at klop.ws (Ronald Klop)
Date: Sun, 06 Dec 2020 22:21:29 +0100
Subject: How to clear the 'remove:' line from 'zpool status'
Message-ID: <op.0u72x3uikndu52@sjakie>



From ronald-lists at klop.ws  Sun Dec  6 21:31:30 2020
From: ronald-lists at klop.ws (Ronald Klop)
Date: Sun, 06 Dec 2020 22:31:29 +0100
Subject: How to clear the 'remove:' line from 'zpool status'
Message-ID: <op.0u73erqakndu52@sjakie>



From ronald-lists at klop.ws  Sun Dec  6 21:41:30 2020
From: ronald-lists at klop.ws (Ronald Klop)
Date: Sun, 06 Dec 2020 22:41:29 +0100
Subject: How to clear the 'remove:' line from 'zpool status'
Message-ID: <op.0u73vfl2kndu52@sjakie>



From ronald-lists at klop.ws  Sun Dec  6 21:51:30 2020
From: ronald-lists at klop.ws (Ronald Klop)
Date: Sun, 06 Dec 2020 22:51:29 +0100
Subject: How to clear the 'remove:' line from 'zpool status'
Message-ID: <op.0u74b3hukndu52@sjakie>



From ronald-lists at klop.ws  Sun Dec  6 22:01:33 2020
From: ronald-lists at klop.ws (Ronald Klop)
Date: Sun, 06 Dec 2020 23:01:29 +0100
Subject: How to clear the 'remove:' line from 'zpool status'
Message-ID: <op.0u74srdmkndu52@sjakie>



From ronald-lists at klop.ws  Sun Dec  6 22:11:30 2020
From: ronald-lists at klop.ws (Ronald Klop)
Date: Sun, 06 Dec 2020 23:11:29 +0100
Subject: How to clear the 'remove:' line from 'zpool status'
Message-ID: <op.0u749f1ukndu52@sjakie>



From ronald-lists at klop.ws  Sun Dec  6 22:21:29 2020
From: ronald-lists at klop.ws (Ronald Klop)
Date: Sun, 06 Dec 2020 23:21:29 +0100
Subject: How to clear the 'remove:' line from 'zpool status'
Message-ID: <op.0u75p3xmkndu52@sjakie>



From editor at callfortesting.org  Mon Dec  7 20:54:04 2020
From: editor at callfortesting.org (Michael Dexter)
Date: Mon, 7 Dec 2020 12:54:00 -0800
Subject: RISC-V root device question
Message-ID: <4fcf5f35-481b-a321-cb52-7264fc10d1d4@callfortesting.org>

All,

The FreeBSD wiki page on RISC-V reads:

If you get mountroot prompt, then indicate to the kernel the location of 
rootfs:

mountroot> ufs:/dev/vtbd0

This indeed appears to be remain the case on CURRENT as of last week.

Specifying a device and partition, or disklabel at the mountroot> prompt 
works every time but none of these do not help in loader.conf (tested 
individually):

cam.boot_delay="100000"
vfs.root.mountfrom="ufs:/dev/vtbd0p3"
vfs.root.mountfrom="ufs:/dev/gpt/rootfs"
rootdev="/dev/vtbd0p3"
rootdev="vtbd0p3"
currdev="vtbd0p3"

Or these in the fstab:

/dev/gpt/rootfs /       ufs     rw,noatime      1       1
/dev/vtbd0p3   /       ufs     rw,noatime      1       1

Are there any other options? Perhaps building the device name into the 
kernel?

Thank you!

Michael

From mhorne at freebsd.org  Mon Dec  7 21:56:52 2020
From: mhorne at freebsd.org (Mitchell Horne)
Date: Mon, 7 Dec 2020 17:56:40 -0400
Subject: RISC-V root device question
In-Reply-To: <4fcf5f35-481b-a321-cb52-7264fc10d1d4@callfortesting.org>
References: <4fcf5f35-481b-a321-cb52-7264fc10d1d4@callfortesting.org>
Message-ID: <CADeAsy0jyHx10pQ5NRYzuk2gjMGOf4Of5jGOL-0BmoN5PVJd5A@mail.gmail.com>

On Mon, Dec 7, 2020 at 4:54 PM Michael Dexter <editor at callfortesting.org> wrote:
>
> All,
>
> The FreeBSD wiki page on RISC-V reads:
>
> If you get mountroot prompt, then indicate to the kernel the location of
> rootfs:
>
> mountroot> ufs:/dev/vtbd0
>
> This indeed appears to be remain the case on CURRENT as of last week.
>
> Specifying a device and partition, or disklabel at the mountroot> prompt
> works every time but none of these do not help in loader.conf (tested
> individually):
>
> cam.boot_delay="100000"
> vfs.root.mountfrom="ufs:/dev/vtbd0p3"
> vfs.root.mountfrom="ufs:/dev/gpt/rootfs"
> rootdev="/dev/vtbd0p3"
> rootdev="vtbd0p3"
> currdev="vtbd0p3"
>
> Or these in the fstab:
>
> /dev/gpt/rootfs /       ufs     rw,noatime      1       1
> /dev/vtbd0p3   /       ufs     rw,noatime      1       1
>
> Are there any other options? Perhaps building the device name into the
> kernel?
>
> Thank you!
>
> Michael

Hi Michael,

If you have followed the directions on that wiki page exactly, then
you have booted without FreeBSD's loader(8), and that is why your
loader.conf variables are not taking effect. There are a couple
solutions to this.

As you suggest, it is possible to overwrite the default root device in
the kernel config, by adding a line such as:
  options ROOTDEVNAME=\"ufs:/dev/vtbd0p3\"

You can also override it using the QEMU commandline, which is simpler
since you won't need to recompile anything. Adding the following
argument should suffice:
  -append="vfs.root.mountfrom=ufs:/dev/vtbd0p3"
Note that you can set arbitrary kernel environment variables this way ^^

Finally, we do have support for loader.efi on RISC-V, although I have
not yet documented how to use it on the wiki page. If you would like
to try this method, please follow up with me and I can provide
instructions.

Otherwise, you can expect to see weekly RISC-V snapshots appear in the
next week or two, and I will ensure that the wiki page is up to date
with how to run them.

Cheers,
Mitchell

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

From editor at callfortesting.org  Mon Dec  7 22:28:40 2020
From: editor at callfortesting.org (Michael Dexter)
Date: Mon, 7 Dec 2020 14:28:34 -0800
Subject: RISC-V root device question
In-Reply-To: <CADeAsy0jyHx10pQ5NRYzuk2gjMGOf4Of5jGOL-0BmoN5PVJd5A@mail.gmail.com>
References: <4fcf5f35-481b-a321-cb52-7264fc10d1d4@callfortesting.org>
 <CADeAsy0jyHx10pQ5NRYzuk2gjMGOf4Of5jGOL-0BmoN5PVJd5A@mail.gmail.com>
Message-ID: <b9d65c65-7783-ea3d-867f-096c43635876@callfortesting.org>

On 12/7/20 1:56 PM, Mitchell Horne wrote:
> As you suggest, it is possible to overwrite the default root device in
> the kernel config, by adding a line such as:
>    options ROOTDEVNAME=\"ufs:/dev/vtbd0p3\"

Thank you for the syntax!

> You can also override it using the QEMU commandline, which is simpler
> since you won't need to recompile anything. Adding the following
> argument should suffice:
>    -append="vfs.root.mountfrom=ufs:/dev/vtbd0p3"
> Note that you can set arbitrary kernel environment variables this way ^^

My string:

qemu-system-riscv64 -machine virt -m 2048M -smp 2 -nographic -kernel 
/vms/riscv/kernel -bios 
/usr/local/share/opensbi/lp64/generic/firmware/fw_jump.elf 
-append="vfs.root.mountfrom=ufs:/dev/vtbd0p3" -drive 
file=$1,format=raw,id=hd0 -device virtio-blk-device,drive=hd0 -netdev 
tap,ifname=tap0,script=no,id=net0

Reports:  -append=vfs.root.mountfrom=ufs:/dev/vtbd0p3: invalid option

I have tried it both there after ...elf and at the end of the string. Is 
this perhaps the wrong position?

> Finally, we do have support for loader.efi on RISC-V, although I have
> not yet documented how to use it on the wiki page. If you would like
> to try this method, please follow up with me and I can provide
> instructions.

I am happy to if it is ready for public consumption.

> Otherwise, you can expect to see weekly RISC-V snapshots appear in the
> next week or two, and I will ensure that the wiki page is up to date
> with how to run them.

Thank you and keep up the good work!

Michael

From mhorne at freebsd.org  Mon Dec  7 22:40:58 2020
From: mhorne at freebsd.org (Mitchell Horne)
Date: Mon, 7 Dec 2020 18:40:45 -0400
Subject: RISC-V root device question
In-Reply-To: <b9d65c65-7783-ea3d-867f-096c43635876@callfortesting.org>
References: <4fcf5f35-481b-a321-cb52-7264fc10d1d4@callfortesting.org>
 <CADeAsy0jyHx10pQ5NRYzuk2gjMGOf4Of5jGOL-0BmoN5PVJd5A@mail.gmail.com>
 <b9d65c65-7783-ea3d-867f-096c43635876@callfortesting.org>
Message-ID: <CADeAsy2iSp+Ae70Ziar6OLuBoUMPzsZoC+BQx4W3mdBTZMCnHw@mail.gmail.com>

On Mon, Dec 7, 2020 at 6:28 PM Michael Dexter <editor at callfortesting.org> wrote:
>
> On 12/7/20 1:56 PM, Mitchell Horne wrote:
> > As you suggest, it is possible to overwrite the default root device in
> > the kernel config, by adding a line such as:
> >    options ROOTDEVNAME=\"ufs:/dev/vtbd0p3\"
>
> Thank you for the syntax!
>
> > You can also override it using the QEMU commandline, which is simpler
> > since you won't need to recompile anything. Adding the following
> > argument should suffice:
> >    -append="vfs.root.mountfrom=ufs:/dev/vtbd0p3"
> > Note that you can set arbitrary kernel environment variables this way ^^
>
> My string:
>
> qemu-system-riscv64 -machine virt -m 2048M -smp 2 -nographic -kernel
> /vms/riscv/kernel -bios
> /usr/local/share/opensbi/lp64/generic/firmware/fw_jump.elf
> -append="vfs.root.mountfrom=ufs:/dev/vtbd0p3" -drive
> file=$1,format=raw,id=hd0 -device virtio-blk-device,drive=hd0 -netdev
> tap,ifname=tap0,script=no,id=net0
>
> Reports:  -append=vfs.root.mountfrom=ufs:/dev/vtbd0p3: invalid option
>

My bad, the extra '=' is a typo. It should be:
  -append "vfs.root.mountfrom=ufs:/dev/vtbd0p3"

> I have tried it both there after ...elf and at the end of the string. Is
> this perhaps the wrong position?
>
> > Finally, we do have support for loader.efi on RISC-V, although I have
> > not yet documented how to use it on the wiki page. If you would like
> > to try this method, please follow up with me and I can provide
> > instructions.
>
> I am happy to if it is ready for public consumption.
>

Great, I will write that up soon.

> > Otherwise, you can expect to see weekly RISC-V snapshots appear in the
> > next week or two, and I will ensure that the wiki page is up to date
> > with how to run them.
>
> Thank you and keep up the good work!
>
> Michael

From editor at callfortesting.org  Mon Dec  7 23:25:25 2020
From: editor at callfortesting.org (Michael Dexter)
Date: Mon, 7 Dec 2020 15:25:21 -0800
Subject: RISC-V root device question
In-Reply-To: <CADeAsy2iSp+Ae70Ziar6OLuBoUMPzsZoC+BQx4W3mdBTZMCnHw@mail.gmail.com>
References: <4fcf5f35-481b-a321-cb52-7264fc10d1d4@callfortesting.org>
 <CADeAsy0jyHx10pQ5NRYzuk2gjMGOf4Of5jGOL-0BmoN5PVJd5A@mail.gmail.com>
 <b9d65c65-7783-ea3d-867f-096c43635876@callfortesting.org>
 <CADeAsy2iSp+Ae70Ziar6OLuBoUMPzsZoC+BQx4W3mdBTZMCnHw@mail.gmail.com>
Message-ID: <d853ad0d-023b-15eb-67a4-e5fe8575cdce@callfortesting.org>

On 12/7/20 2:40 PM, Mitchell Horne wrote:
> My bad, the extra '=' is a typo. It should be:
>    -append "vfs.root.mountfrom=ufs:/dev/vtbd0p3"

That worked perfectly and I added it to the wiki page:

https://wiki.freebsd.org/riscv

All the best,

Michael

From haramrae at gmail.com  Tue Dec  8 07:56:31 2020
From: haramrae at gmail.com (Alban Hertroys)
Date: Tue, 8 Dec 2020 08:56:25 +0100
Subject: KLD zfs.ko: depends on kernel - not available or version mismatch
Message-ID: <42AC7323-5AD6-401D-9A7D-F1D962EE5717@gmail.com>

This seems to have gotten lost in the moderate queue, but after a week I am no closer to a solution, so here?s a resend:

I?ve been trying to get a fresh world running (for the eventual purpose of running amdgpu against my recent graphics adapter), but I run into trouble with core loadable kernel modules, such as zfs.ko from the subject. It also happens with other modules that I tried randomly, for example, geom_mirror.ko.

I updated to the latest current using svn up in /usr/src, then:
	make clean
	make buildworld kernel -j12
	shutdown -r now

boot to single user mode

	kldload zfs

Which results in dmesg messages:

KLD zfs.ko: depends on kernel - not available or version mismatch
linker_load_file: /boot/kernel/zfs.ko - unsupported file type
KLD zfs.ko: depends on kernel - not available or version mismatch
linker_load_file: /boot/kernel/zfs.ko - unsupported file type
KLD zfs.ko: depends on kernel - not available or version mismatch
linker_load_file: /boot/kernel/zfs.ko - unsupported file type
KLD zfs.ko: depends on kernel - not available or version mismatch
linker_load_file: /boot/kernel/zfs.ko - unsupported file type


I can load the zfs kernel module from kernel.old just fine:

ZFS filesystem version: 5
ZFS storage pool version: features support (5000)


This happens with any kernel module I?ve tried, such as geom_mirror and amdgpu (from ports/graphics/drm-current-kmod - the latter causes a kernel panic with kernel.old BTW).

I?ve gone back as far as Oct 7 (before changes to kern/elf_load_obj.c off the top of my head), looked at mailing list archives and forums etc, all to no avail.

I have / on UFS+J and /usr on ZFS and nothing in /etc/src.conf. I had /etc/malloc.conf with the recommended symlink from UPDATING, but the same happens with that moved out of the way. Nothing seems to help.

Do I need to go back further to get into a usable state or is there something else I should be doing?

Regards,
Alban Hertroys
--
There is always an exception to always.





From pho at freebsd.org  Tue Dec  8 11:47:22 2020
From: pho at freebsd.org (Peter Holm)
Date: Tue, 8 Dec 2020 12:47:18 +0100
Subject: panic: general protection fault from uipc_sockaddr+0x4c
Message-ID: <20201208114718.GA33199@x8.osted.lan>

I just got this panic:

Fatal trap 9: general protection fault while in kernel mode
cpuid = 9; apic id = 09
instruction pointer = 0x20:0xffffffff80bc6e22
stack pointer         = 0x28:0xfffffe0698887630
frame pointer         = 0x28:0xfffffe06988876b0
code segment  = base 0x0, limit 0xfffff, type 0x1b
   = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process  = 45966 (fstat)
trap number  = 9
panic: general protection fault
cpuid = 9
time = 1607416693
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0698887340
vpanic() at vpanic+0x181/frame 0xfffffe0698887390
panic() at panic+0x43/frame 0xfffffe06988873f0
trap_fatal() at trap_fatal+0x387/frame 0xfffffe0698887450
trap() at trap+0xa4/frame 0xfffffe0698887560
calltrap() at calltrap+0x8/frame 0xfffffe0698887560
--- trap 0x9, rip = 0xffffffff80bc6e22, rsp = 0xfffffe0698887630, rbp = 0xfffffe06988876b0 ---
__mtx_lock_sleep() at __mtx_lock_sleep+0xd2/frame 0xfffffe06988876b0
__mtx_lock_flags() at __mtx_lock_flags+0xe5/frame 0xfffffe0698887700
uipc_sockaddr() at uipc_sockaddr+0x4c/frame 0xfffffe0698887730
soo_fill_kinfo() at soo_fill_kinfo+0x11e/frame 0xfffffe0698887770
kern_proc_filedesc_out() at kern_proc_filedesc_out+0xb57/frame 0xfffffe0698887810
sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x7d/frame 0xfffffe0698887890
sysctl_root_handler_locked() at sysctl_root_handler_locked+0x9c/frame 0xfffffe06988878e0
sysctl_root() at sysctl_root+0x20d/frame 0xfffffe0698887960
userland_sysctl() at userland_sysctl+0x180/frame 0xfffffe0698887a10
sys___sysctl() at sys___sysctl+0x5f/frame 0xfffffe0698887ac0
amd64_syscall() at amd64_syscall+0x147/frame 0xfffffe0698887bf0
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0698887bf0
--- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x8003948ea, rsp = 0x7fffffffc138, rbp = 0x7fffffffc170 ---

https://people.freebsd.org/~pho/stress/log/log0004.txt

- Peter

From markj at freebsd.org  Tue Dec  8 15:30:48 2020
From: markj at freebsd.org (Mark Johnston)
Date: Tue, 8 Dec 2020 10:30:41 -0500
Subject: panic: general protection fault from uipc_sockaddr+0x4c
In-Reply-To: <20201208114718.GA33199@x8.osted.lan>
References: <20201208114718.GA33199@x8.osted.lan>
Message-ID: <X8+cIUFKzzOSnl4L@raichu>

On Tue, Dec 08, 2020 at 12:47:18PM +0100, Peter Holm wrote:
> I just got this panic:
> 
> Fatal trap 9: general protection fault while in kernel mode
> cpuid = 9; apic id = 09
> instruction pointer = 0x20:0xffffffff80bc6e22
> stack pointer         = 0x28:0xfffffe0698887630
> frame pointer         = 0x28:0xfffffe06988876b0
> code segment  = base 0x0, limit 0xfffff, type 0x1b
>    = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process  = 45966 (fstat)
> trap number  = 9
> panic: general protection fault
> cpuid = 9
> time = 1607416693
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0698887340
> vpanic() at vpanic+0x181/frame 0xfffffe0698887390
> panic() at panic+0x43/frame 0xfffffe06988873f0
> trap_fatal() at trap_fatal+0x387/frame 0xfffffe0698887450
> trap() at trap+0xa4/frame 0xfffffe0698887560
> calltrap() at calltrap+0x8/frame 0xfffffe0698887560
> --- trap 0x9, rip = 0xffffffff80bc6e22, rsp = 0xfffffe0698887630, rbp = 0xfffffe06988876b0 ---
> __mtx_lock_sleep() at __mtx_lock_sleep+0xd2/frame 0xfffffe06988876b0
> __mtx_lock_flags() at __mtx_lock_flags+0xe5/frame 0xfffffe0698887700
> uipc_sockaddr() at uipc_sockaddr+0x4c/frame 0xfffffe0698887730
> soo_fill_kinfo() at soo_fill_kinfo+0x11e/frame 0xfffffe0698887770
> kern_proc_filedesc_out() at kern_proc_filedesc_out+0xb57/frame 0xfffffe0698887810
> sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x7d/frame 0xfffffe0698887890
> sysctl_root_handler_locked() at sysctl_root_handler_locked+0x9c/frame 0xfffffe06988878e0
> sysctl_root() at sysctl_root+0x20d/frame 0xfffffe0698887960
> userland_sysctl() at userland_sysctl+0x180/frame 0xfffffe0698887a10
> sys___sysctl() at sys___sysctl+0x5f/frame 0xfffffe0698887ac0
> amd64_syscall() at amd64_syscall+0x147/frame 0xfffffe0698887bf0
> fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0698887bf0
> --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x8003948ea, rsp = 0x7fffffffc138, rbp = 0x7fffffffc170 ---
> 
> https://people.freebsd.org/~pho/stress/log/log0004.txt

So here the unpcb is freed, and indeed the file itself has been closed:

$3 = {f_flag = 0x3, f_count = 0x0, f_data = 0x0, f_ops = 0xffffffff81901f50 <badfileops>,
      f_vnode = 0x0, f_cred = 0xfffff80248beb600, f_type = 0x2, 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}

However, it must have happened very recently because soo_fill_kinfo()
dereferences fp->f_data and yet we did not panic due to a null
dereference.

kern_proc_filedesc_out() holds the fdtable shared lock thoughout all of
this, which is supposed to prevent the table entry from being freed
since that requires the exclusive lock.

Could you show fdp->fd_ofiles[3] and fdp->fd_map[0] from frame 26?

From kevans at freebsd.org  Tue Dec  8 15:39:19 2020
From: kevans at freebsd.org (Kyle Evans)
Date: Tue, 8 Dec 2020 09:39:05 -0600
Subject: panic: general protection fault from uipc_sockaddr+0x4c
In-Reply-To: <X8+cIUFKzzOSnl4L@raichu>
References: <20201208114718.GA33199@x8.osted.lan> <X8+cIUFKzzOSnl4L@raichu>
Message-ID: <CACNAnaG_8iSUqc3pnmV-DMFQ_+Q+bSDbYA8X3pz743rRGUtT9A@mail.gmail.com>

On Tue, Dec 8, 2020 at 9:30 AM Mark Johnston <markj at freebsd.org> wrote:
>
> On Tue, Dec 08, 2020 at 12:47:18PM +0100, Peter Holm wrote:
> > I just got this panic:
> >
> > Fatal trap 9: general protection fault while in kernel mode
> > cpuid = 9; apic id = 09
> > instruction pointer = 0x20:0xffffffff80bc6e22
> > stack pointer         = 0x28:0xfffffe0698887630
> > frame pointer         = 0x28:0xfffffe06988876b0
> > code segment  = base 0x0, limit 0xfffff, type 0x1b
> >    = DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags = interrupt enabled, resume, IOPL = 0
> > current process  = 45966 (fstat)
> > trap number  = 9
> > panic: general protection fault
> > cpuid = 9
> > time = 1607416693
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0698887340
> > vpanic() at vpanic+0x181/frame 0xfffffe0698887390
> > panic() at panic+0x43/frame 0xfffffe06988873f0
> > trap_fatal() at trap_fatal+0x387/frame 0xfffffe0698887450
> > trap() at trap+0xa4/frame 0xfffffe0698887560
> > calltrap() at calltrap+0x8/frame 0xfffffe0698887560
> > --- trap 0x9, rip = 0xffffffff80bc6e22, rsp = 0xfffffe0698887630, rbp = 0xfffffe06988876b0 ---
> > __mtx_lock_sleep() at __mtx_lock_sleep+0xd2/frame 0xfffffe06988876b0
> > __mtx_lock_flags() at __mtx_lock_flags+0xe5/frame 0xfffffe0698887700
> > uipc_sockaddr() at uipc_sockaddr+0x4c/frame 0xfffffe0698887730
> > soo_fill_kinfo() at soo_fill_kinfo+0x11e/frame 0xfffffe0698887770
> > kern_proc_filedesc_out() at kern_proc_filedesc_out+0xb57/frame 0xfffffe0698887810
> > sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x7d/frame 0xfffffe0698887890
> > sysctl_root_handler_locked() at sysctl_root_handler_locked+0x9c/frame 0xfffffe06988878e0
> > sysctl_root() at sysctl_root+0x20d/frame 0xfffffe0698887960
> > userland_sysctl() at userland_sysctl+0x180/frame 0xfffffe0698887a10
> > sys___sysctl() at sys___sysctl+0x5f/frame 0xfffffe0698887ac0
> > amd64_syscall() at amd64_syscall+0x147/frame 0xfffffe0698887bf0
> > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0698887bf0
> > --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x8003948ea, rsp = 0x7fffffffc138, rbp = 0x7fffffffc170 ---
> >
> > https://people.freebsd.org/~pho/stress/log/log0004.txt
>
> So here the unpcb is freed, and indeed the file itself has been closed:
>
> $3 = {f_flag = 0x3, f_count = 0x0, f_data = 0x0, f_ops = 0xffffffff81901f50 <badfileops>,
>       f_vnode = 0x0, f_cred = 0xfffff80248beb600, f_type = 0x2, 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}
>
> However, it must have happened very recently because soo_fill_kinfo()
> dereferences fp->f_data and yet we did not panic due to a null
> dereference.
>
> kern_proc_filedesc_out() holds the fdtable shared lock thoughout all of
> this, which is supposed to prevent the table entry from being freed
> since that requires the exclusive lock.
>

export_file_to_sb drops the lock without it or kern_proc_filedesc_out
holding the file it's about to look at, though.

From mjguzik at gmail.com  Tue Dec  8 15:40:21 2020
From: mjguzik at gmail.com (Mateusz Guzik)
Date: Tue, 8 Dec 2020 16:40:16 +0100
Subject: panic: general protection fault from uipc_sockaddr+0x4c
In-Reply-To: <X8+cIUFKzzOSnl4L@raichu>
References: <20201208114718.GA33199@x8.osted.lan> <X8+cIUFKzzOSnl4L@raichu>
Message-ID: <CAGudoHEdFaaYb9QjZBad+VzFjyvzB1cxXGsv8kB0rNqSfFzY3A@mail.gmail.com>

I think this is a long standing bug against exiting processes.

filedesc_out only increments *hold* count, but that does not prevent
fdescfree_fds from progressing and freeing everything without any
locks held.

A hotfix (for mfc) would add locking around it, but a long term fix
should wait for hold count to drain. By that point there can't be any
new arrivals due to:

        PROC_LOCK(p);
        p->p_fd = NULL;
        PROC_UNLOCK(p);

I'll code both later today.

On 12/8/20, Mark Johnston <markj at freebsd.org> wrote:
> On Tue, Dec 08, 2020 at 12:47:18PM +0100, Peter Holm wrote:
>> I just got this panic:
>>
>> Fatal trap 9: general protection fault while in kernel mode
>> cpuid = 9; apic id = 09
>> instruction pointer = 0x20:0xffffffff80bc6e22
>> stack pointer         = 0x28:0xfffffe0698887630
>> frame pointer         = 0x28:0xfffffe06988876b0
>> code segment  = base 0x0, limit 0xfffff, type 0x1b
>>    = DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags = interrupt enabled, resume, IOPL = 0
>> current process  = 45966 (fstat)
>> trap number  = 9
>> panic: general protection fault
>> cpuid = 9
>> time = 1607416693
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>> 0xfffffe0698887340
>> vpanic() at vpanic+0x181/frame 0xfffffe0698887390
>> panic() at panic+0x43/frame 0xfffffe06988873f0
>> trap_fatal() at trap_fatal+0x387/frame 0xfffffe0698887450
>> trap() at trap+0xa4/frame 0xfffffe0698887560
>> calltrap() at calltrap+0x8/frame 0xfffffe0698887560
>> --- trap 0x9, rip = 0xffffffff80bc6e22, rsp = 0xfffffe0698887630, rbp =
>> 0xfffffe06988876b0 ---
>> __mtx_lock_sleep() at __mtx_lock_sleep+0xd2/frame 0xfffffe06988876b0
>> __mtx_lock_flags() at __mtx_lock_flags+0xe5/frame 0xfffffe0698887700
>> uipc_sockaddr() at uipc_sockaddr+0x4c/frame 0xfffffe0698887730
>> soo_fill_kinfo() at soo_fill_kinfo+0x11e/frame 0xfffffe0698887770
>> kern_proc_filedesc_out() at kern_proc_filedesc_out+0xb57/frame
>> 0xfffffe0698887810
>> sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x7d/frame
>> 0xfffffe0698887890
>> sysctl_root_handler_locked() at sysctl_root_handler_locked+0x9c/frame
>> 0xfffffe06988878e0
>> sysctl_root() at sysctl_root+0x20d/frame 0xfffffe0698887960
>> userland_sysctl() at userland_sysctl+0x180/frame 0xfffffe0698887a10
>> sys___sysctl() at sys___sysctl+0x5f/frame 0xfffffe0698887ac0
>> amd64_syscall() at amd64_syscall+0x147/frame 0xfffffe0698887bf0
>> fast_syscall_common() at fast_syscall_common+0xf8/frame
>> 0xfffffe0698887bf0
>> --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x8003948ea, rsp =
>> 0x7fffffffc138, rbp = 0x7fffffffc170 ---
>>
>> https://people.freebsd.org/~pho/stress/log/log0004.txt
>
> So here the unpcb is freed, and indeed the file itself has been closed:
>
> $3 = {f_flag = 0x3, f_count = 0x0, f_data = 0x0, f_ops = 0xffffffff81901f50
> <badfileops>,
>       f_vnode = 0x0, f_cred = 0xfffff80248beb600, f_type = 0x2,
> 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}
>
> However, it must have happened very recently because soo_fill_kinfo()
> dereferences fp->f_data and yet we did not panic due to a null
> dereference.
>
> kern_proc_filedesc_out() holds the fdtable shared lock thoughout all of
> this, which is supposed to prevent the table entry from being freed
> since that requires the exclusive lock.
>
> Could you show fdp->fd_ofiles[3] and fdp->fd_map[0] from frame 26?
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>


-- 
Mateusz Guzik <mjguzik gmail.com>

From warlock at phouka.net  Tue Dec  8 15:41:55 2020
From: warlock at phouka.net (John Kennedy)
Date: Tue, 8 Dec 2020 07:40:30 -0800
Subject: KLD zfs.ko: depends on kernel - not available or version mismatch
In-Reply-To: <42AC7323-5AD6-401D-9A7D-F1D962EE5717@gmail.com>
References: <42AC7323-5AD6-401D-9A7D-F1D962EE5717@gmail.com>
Message-ID: <X8+ebiETBdNpbRXt@phouka1.phouka.net>

On Tue, Dec 08, 2020 at 08:56:25AM +0100, Alban Hertroys wrote:
> This seems to have gotten lost in the moderate queue, but after a week I am no closer to a solution, so here???s a resend:
> 
> I???ve been trying to get a fresh world running (for the eventual purpose of running amdgpu against my recent graphics adapter), but I run into trouble with core loadable kernel modules, such as zfs.ko from the subject. It also happens with other modules that I tried randomly, for example, geom_mirror.ko.
> 
> I updated to the latest current using svn up in /usr/src, then:
> 	make clean
> 	make buildworld kernel -j12
> 	shutdown -r now
> 
> boot to single user mode
> 
> 	kldload zfs

I'm not sure you've provided enough information for a one-shot armchair
diagnosis, but some things seem factually wrong.  For example, my normal
rebuild procedure is:

	cd /usr/src && make buildworld && make buildkernel
	make installkernel
	shutdown -r now

	cd /usr/src && mergemaster -pi
	make installworld
	mergemaster -Fi
	make -DBATCH_DELETE_OLD_FILES delete-old
	shutdown -r now

	cd /usr/src && make -DBATCH_DELETE_OLD_FILES delete-old-libs

(I'm on a desktop system here.  You haven't described your setup.)

You didn't say that you've installed the new kernel, which at least starts
you down the road towards a driver/kernel mismatch.  You presumably have a
non-ZFS boot+root.  Did you mess around with the ZFS from ports (ZoL -> ZoF)
at some point so you're not using the kernel's ZFS drivers?  What ZFS
entries do you have in /etc/loader.conf, /etc/rc.conf, and some of the
varients that may get dragged in?  (see rc.conf(5) for possibilities)

At the bottom of your email, you say / is UFS and /usr is ZFS, but I guess we
have the extra fun of wondering what is under /usr on your /?  If you have a
pre-ZFS /usr that is populated by something now presumably very old (because
all the new, current stuff went onto ZFS /usr, now unavailable).

> Which results in dmesg messages:
> 
> KLD zfs.ko: depends on kernel - not available or version mismatch
> linker_load_file: /boot/kernel/zfs.ko - unsupported file type
> KLD zfs.ko: depends on kernel - not available or version mismatch
> linker_load_file: /boot/kernel/zfs.ko - unsupported file type
> KLD zfs.ko: depends on kernel - not available or version mismatch
> linker_load_file: /boot/kernel/zfs.ko - unsupported file type
> KLD zfs.ko: depends on kernel - not available or version mismatch
> linker_load_file: /boot/kernel/zfs.ko - unsupported file type

Be sure to check out /var/log/messages for extra issues.  For example, with
the bug I mentioned below, I couldn't load my nvidia driver and that manifested
as one driver having issues because it depended on another, which had the root
of the problem.

> I can load the zfs kernel module from kernel.old just fine:
> 
> ZFS filesystem version: 5
> ZFS storage pool version: features support (5000)

I kicked my more bleeding-edge system over from 12.2-rel (r366954) up into
13.0-current (r367044, 1300123) on 2020/10/26.  OpenZFS kicked in 2020/8/24?
I think the CFT was ~2018/8/21, not sure when we had the OpenZFS ports.
Current bumps the ABI version pretty frequently so I'd think you'd have
tripped across versioning issues a long time ago if you had some drivers not
being rebuilt.

> This happens with any kernel module I???ve tried, such as geom_mirror and amdgpu (from ports/graphics/drm-current-kmod - the latter causes a kernel panic with kernel.old BTW).
> 
> I???ve gone back as far as Oct 7 (before changes to kern/elf_load_obj.c off the top of my head), looked at mailing list archives and forums etc, all to no avail.
> 
> I have / on UFS+J and /usr on ZFS and nothing in /etc/src.conf. I had /etc/malloc.conf with the recommended symlink from UPDATING, but the same happens with that moved out of the way. Nothing seems to help.
> 
> Do I need to go back further to get into a usable state or is there something else I should be doing?

With very few exceptions (bug 250897, 2020/11/6), I've found 13-current
bootable since 10/26 (up through my current system, 13.0 r368388 (2020/12/6).
You obviously need to make sure that an extra drivers you add in are compiled
against the kernel, but ZFS is typically one of those.


From markj at freebsd.org  Tue Dec  8 15:48:43 2020
From: markj at freebsd.org (Mark Johnston)
Date: Tue, 8 Dec 2020 10:48:29 -0500
Subject: panic: general protection fault from uipc_sockaddr+0x4c
In-Reply-To: <CACNAnaG_8iSUqc3pnmV-DMFQ_+Q+bSDbYA8X3pz743rRGUtT9A@mail.gmail.com>
References: <20201208114718.GA33199@x8.osted.lan> <X8+cIUFKzzOSnl4L@raichu>
 <CACNAnaG_8iSUqc3pnmV-DMFQ_+Q+bSDbYA8X3pz743rRGUtT9A@mail.gmail.com>
Message-ID: <X8+gTfsqOCxld3yl@raichu>

On Tue, Dec 08, 2020 at 09:39:05AM -0600, Kyle Evans wrote:
> On Tue, Dec 8, 2020 at 9:30 AM Mark Johnston <markj at freebsd.org> wrote:
> > kern_proc_filedesc_out() holds the fdtable shared lock thoughout all of
> > this, which is supposed to prevent the table entry from being freed
> > since that requires the exclusive lock.
> >
> 
> export_file_to_sb drops the lock without it or kern_proc_filedesc_out
> holding the file it's about to look at, though.

Yes, but that's after it calls fo_fill_kinfo().  At that point it has
already collected the to-be-exported info in an sbuf.

From kevans at freebsd.org  Tue Dec  8 15:50:50 2020
From: kevans at freebsd.org (Kyle Evans)
Date: Tue, 8 Dec 2020 09:50:35 -0600
Subject: panic: general protection fault from uipc_sockaddr+0x4c
In-Reply-To: <X8+gTfsqOCxld3yl@raichu>
References: <20201208114718.GA33199@x8.osted.lan> <X8+cIUFKzzOSnl4L@raichu>
 <CACNAnaG_8iSUqc3pnmV-DMFQ_+Q+bSDbYA8X3pz743rRGUtT9A@mail.gmail.com>
 <X8+gTfsqOCxld3yl@raichu>
Message-ID: <CACNAnaEYaUX_XVFQ1MKn9nD5UBwNeLViAXZVRMZHsXcLDFxoRQ@mail.gmail.com>

On Tue, Dec 8, 2020 at 9:48 AM Mark Johnston <markj at freebsd.org> wrote:
>
> On Tue, Dec 08, 2020 at 09:39:05AM -0600, Kyle Evans wrote:
> > On Tue, Dec 8, 2020 at 9:30 AM Mark Johnston <markj at freebsd.org> wrote:
> > > kern_proc_filedesc_out() holds the fdtable shared lock thoughout all of
> > > this, which is supposed to prevent the table entry from being freed
> > > since that requires the exclusive lock.
> > >
> >
> > export_file_to_sb drops the lock without it or kern_proc_filedesc_out
> > holding the file it's about to look at, though.
>
> Yes, but that's after it calls fo_fill_kinfo().  At that point it has
> already collected the to-be-exported info in an sbuf.

Whoops, indeed- sorry.

From pho at freebsd.org  Tue Dec  8 16:02:18 2020
From: pho at freebsd.org (Peter Holm)
Date: Tue, 8 Dec 2020 17:02:12 +0100
Subject: panic: general protection fault from uipc_sockaddr+0x4c
In-Reply-To: <X8+cIUFKzzOSnl4L@raichu>
References: <20201208114718.GA33199@x8.osted.lan>
 <X8+cIUFKzzOSnl4L@raichu>
Message-ID: <20201208160212.GA35933@x8.osted.lan>

On Tue, Dec 08, 2020 at 10:30:41AM -0500, Mark Johnston wrote:
> On Tue, Dec 08, 2020 at 12:47:18PM +0100, Peter Holm wrote:
> > I just got this panic:
> > 
> > Fatal trap 9: general protection fault while in kernel mode
> > cpuid = 9; apic id = 09
> > instruction pointer = 0x20:0xffffffff80bc6e22
> > stack pointer         = 0x28:0xfffffe0698887630
> > frame pointer         = 0x28:0xfffffe06988876b0
> > code segment  = base 0x0, limit 0xfffff, type 0x1b
> >    = DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags = interrupt enabled, resume, IOPL = 0
> > current process  = 45966 (fstat)
> > trap number  = 9
> > panic: general protection fault
> > cpuid = 9
> > time = 1607416693
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0698887340
> > vpanic() at vpanic+0x181/frame 0xfffffe0698887390
> > panic() at panic+0x43/frame 0xfffffe06988873f0
> > trap_fatal() at trap_fatal+0x387/frame 0xfffffe0698887450
> > trap() at trap+0xa4/frame 0xfffffe0698887560
> > calltrap() at calltrap+0x8/frame 0xfffffe0698887560
> > --- trap 0x9, rip = 0xffffffff80bc6e22, rsp = 0xfffffe0698887630, rbp = 0xfffffe06988876b0 ---
> > __mtx_lock_sleep() at __mtx_lock_sleep+0xd2/frame 0xfffffe06988876b0
> > __mtx_lock_flags() at __mtx_lock_flags+0xe5/frame 0xfffffe0698887700
> > uipc_sockaddr() at uipc_sockaddr+0x4c/frame 0xfffffe0698887730
> > soo_fill_kinfo() at soo_fill_kinfo+0x11e/frame 0xfffffe0698887770
> > kern_proc_filedesc_out() at kern_proc_filedesc_out+0xb57/frame 0xfffffe0698887810
> > sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x7d/frame 0xfffffe0698887890
> > sysctl_root_handler_locked() at sysctl_root_handler_locked+0x9c/frame 0xfffffe06988878e0
> > sysctl_root() at sysctl_root+0x20d/frame 0xfffffe0698887960
> > userland_sysctl() at userland_sysctl+0x180/frame 0xfffffe0698887a10
> > sys___sysctl() at sys___sysctl+0x5f/frame 0xfffffe0698887ac0
> > amd64_syscall() at amd64_syscall+0x147/frame 0xfffffe0698887bf0
> > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0698887bf0
> > --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x8003948ea, rsp = 0x7fffffffc138, rbp = 0x7fffffffc170 ---
> > 
> > https://people.freebsd.org/~pho/stress/log/log0004.txt
> 
> So here the unpcb is freed, and indeed the file itself has been closed:
> 
> $3 = {f_flag = 0x3, f_count = 0x0, f_data = 0x0, f_ops = 0xffffffff81901f50 <badfileops>,
>       f_vnode = 0x0, f_cred = 0xfffff80248beb600, f_type = 0x2, 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}
> 
> However, it must have happened very recently because soo_fill_kinfo()
> dereferences fp->f_data and yet we did not panic due to a null
> dereference.
> 
> kern_proc_filedesc_out() holds the fdtable shared lock thoughout all of
> this, which is supposed to prevent the table entry from being freed
> since that requires the exclusive lock.
> 
> Could you show fdp->fd_ofiles[3] and fdp->fd_map[0] from frame 26?

Sure:

(kgdb) p fdp->fd_files->fdt_ofiles[3]
$1 = {fde_file = 0xfffff807306fd0f0, fde_caps = {fc_rights = {cr_rights = {0x0, 0x0}}, fc_ioctls = 0x0, fc_nioctls = 0x0, fc_fcntls = 0x0}, fde_flags = 0x0, fde_seqc = 0x2}
(kgdb) p fdp->fd_map[0]
$2 = 0x1f
(kgdb) 

- Peter

From markj at freebsd.org  Tue Dec  8 16:05:38 2020
From: markj at freebsd.org (Mark Johnston)
Date: Tue, 8 Dec 2020 11:05:33 -0500
Subject: panic: general protection fault from uipc_sockaddr+0x4c
In-Reply-To: <CAGudoHEdFaaYb9QjZBad+VzFjyvzB1cxXGsv8kB0rNqSfFzY3A@mail.gmail.com>
References: <20201208114718.GA33199@x8.osted.lan> <X8+cIUFKzzOSnl4L@raichu>
 <CAGudoHEdFaaYb9QjZBad+VzFjyvzB1cxXGsv8kB0rNqSfFzY3A@mail.gmail.com>
Message-ID: <X8+kTeiw7tBeRKOv@raichu>

On Tue, Dec 08, 2020 at 04:40:16PM +0100, Mateusz Guzik wrote:
> I think this is a long standing bug against exiting processes.
> 
> filedesc_out only increments *hold* count, but that does not prevent
> fdescfree_fds from progressing and freeing everything without any
> locks held.

I think it is fallout from r367777: before that, fdescfree() acquired
and released the exclusive fd table lock between decrementing
fdp->fd_refcount and calling fdescfree_fds().  This would serialize with
the loop in kern_proc_fildesc_out(), which checks fdp->fd_refcount > 0
at the beginning of each iteration.  Now there is no serialization and
they can race.

> A hotfix (for mfc) would add locking around it, but a long term fix
> should wait for hold count to drain. By that point there can't be any
> new arrivals due to:
> 
>         PROC_LOCK(p);
>         p->p_fd = NULL;
>         PROC_UNLOCK(p);
> 
> I'll code both later today.

From mjguzik at gmail.com  Tue Dec  8 16:12:39 2020
From: mjguzik at gmail.com (Mateusz Guzik)
Date: Tue, 8 Dec 2020 17:12:35 +0100
Subject: panic: general protection fault from uipc_sockaddr+0x4c
In-Reply-To: <X8+kTeiw7tBeRKOv@raichu>
References: <20201208114718.GA33199@x8.osted.lan> <X8+cIUFKzzOSnl4L@raichu>
 <CAGudoHEdFaaYb9QjZBad+VzFjyvzB1cxXGsv8kB0rNqSfFzY3A@mail.gmail.com>
 <X8+kTeiw7tBeRKOv@raichu>
Message-ID: <CAGudoHEczkVKQnQ---2YcXEZi0YB_=B+efmTBemNJk7JukxOVg@mail.gmail.com>

On 12/8/20, Mark Johnston <markj at freebsd.org> wrote:
> On Tue, Dec 08, 2020 at 04:40:16PM +0100, Mateusz Guzik wrote:
>> I think this is a long standing bug against exiting processes.
>>
>> filedesc_out only increments *hold* count, but that does not prevent
>> fdescfree_fds from progressing and freeing everything without any
>> locks held.
>
> I think it is fallout from r367777: before that, fdescfree() acquired
> and released the exclusive fd table lock between decrementing
> fdp->fd_refcount and calling fdescfree_fds().  This would serialize with
> the loop in kern_proc_fildesc_out(), which checks fdp->fd_refcount > 0
> at the beginning of each iteration.  Now there is no serialization and
> they can race.
>

Oh I forgot consumers keep checking for fd_refcount. In that case
probably would be best to add sx_wait_unlocked.

>> A hotfix (for mfc) would add locking around it, but a long term fix
>> should wait for hold count to drain. By that point there can't be any
>> new arrivals due to:
>>
>>         PROC_LOCK(p);
>>         p->p_fd = NULL;
>>         PROC_UNLOCK(p);
>>
>> I'll code both later today.
>


-- 
Mateusz Guzik <mjguzik gmail.com>

From haramrae at gmail.com  Tue Dec  8 18:10:32 2020
From: haramrae at gmail.com (Alban Hertroys)
Date: Tue, 8 Dec 2020 19:10:26 +0100
Subject: KLD zfs.ko: depends on kernel - not available or version mismatch
In-Reply-To: <X8+ebiETBdNpbRXt@phouka1.phouka.net>
References: <42AC7323-5AD6-401D-9A7D-F1D962EE5717@gmail.com>
 <X8+ebiETBdNpbRXt@phouka1.phouka.net>
Message-ID: <2B044A92-500F-4121-85DB-D486865C75B5@gmail.com>


> On 8 Dec 2020, at 16:40, John Kennedy <warlock at phouka.net> wrote:
> 
> On Tue, Dec 08, 2020 at 08:56:25AM +0100, Alban Hertroys wrote:
>> This seems to have gotten lost in the moderate queue, but after a week I am no closer to a solution, so here???s a resend:
>> 
>> I???ve been trying to get a fresh world running (for the eventual purpose of running amdgpu against my recent graphics adapter), but I run into trouble with core loadable kernel modules, such as zfs.ko from the subject. It also happens with other modules that I tried randomly, for example, geom_mirror.ko.
>> 
>> I updated to the latest current using svn up in /usr/src, then:
>> 	make clean
>> 	make buildworld kernel -j12
>> 	shutdown -r now
>> 
>> boot to single user mode
>> 
>> 	kldload zfs
> 
> I'm not sure you've provided enough information for a one-shot armchair
> diagnosis, but some things seem factually wrong.  For example, my normal
> rebuild procedure is:
> 
> 	cd /usr/src && make buildworld && make buildkernel
> 	make installkernel
> 	shutdown -r now
> 
> 	cd /usr/src && mergemaster -pi
> 	make installworld
> 	mergemaster -Fi
> 	make -DBATCH_DELETE_OLD_FILES delete-old

Aha! So that?s how to prevent having to press ?y? for every deprecated file!

> 	shutdown -r now
> 
> 	cd /usr/src && make -DBATCH_DELETE_OLD_FILES delete-old-libs
> 
> (I'm on a desktop system here.  You haven't described your setup.)

This is also a desktop system.

> You didn't say that you've installed the new kernel, which at least starts
> you down the road towards a driver/kernel mismatch.  You presumably have a
> non-ZFS boot+root.

I?m fairly sure I did, actually.

Last time I checked, "make buildworld buildkernel" was equivalent to "make buildworld && make buildkernel", while "make kernel? is a shorthand for ?make buildkernel && make installkernel?

So, unless I?m mistaken, ?make buildworld kernel? should be equivalent to your first two lines.

Nevertheless, I retried without these assumptions, the result was the same. I forgot to ?make delete-old? though, I rarely remember to do that?

>  Did you mess around with the ZFS from ports (ZoL -> ZoF)
> at some point so you're not using the kernel's ZFS drivers?  What ZFS
> entries do you have in /etc/loader.conf, /etc/rc.conf, and some of the
> varients that may get dragged in?  (see rc.conf(5) for possibilities)

Nope, stock modules here.

> At the bottom of your email, you say / is UFS and /usr is ZFS, but I guess we
> have the extra fun of wondering what is under /usr on your /?  If you have a
> pre-ZFS /usr that is populated by something now presumably very old (because
> all the new, current stuff went onto ZFS /usr, now unavailable).

There is no populated directory /usr on the UFS file-system. This install was created on a fresh NVME disk based on an existing install on a spinning platter. The install happened with /usr mounted at the ZFS file-system.

I had to copy over several files from /etc and /usr/local/etc and re-installed the most important packages. This was admittedly a bit messy, it is possible that I forgot to copy something over.
(Originally my intention was to dd the contents of the spinning disk over, but apparently that disk has a few wonky sectors, dd failed after a few device timeouts)


I did sort-of manage to fix things, but recent kernels keep causing the same issue:

I noticed that uname -a said I was at revision 366335, while I had the source tree up-to-date. For a test, I reverted back to that revision and went through:
	make buildworld
	make buildkernel

Which broke on /usr/local/sys/drm-current-kmod, which I turned out to have installed through pkg. There have been changes to the linux_kpi shortly after above revision - probably what broke compatibility between HEAD and r366335.

After removing that pkg, the kernel built and installed, world installed fine too and I have a working system again, with kernel and world in sync.

So I tried again to move to HEAD:

	cd /usr/src
	svn up
	make buildworld -j12
	make buildkernel -j12
	make installkernel
	shutdown -r now
	<single user mode>
	mount -u /
	zpool import -Nf system (my /usr FS)

KLD zfs.ko: depends on kernel - not available or version mismatch
linker_load_file: /boot/kernel/zfs.ko - unsupported file type


>> Which results in dmesg messages:
>> 
>> KLD zfs.ko: depends on kernel - not available or version mismatch
>> linker_load_file: /boot/kernel/zfs.ko - unsupported file type
>> KLD zfs.ko: depends on kernel - not available or version mismatch
>> linker_load_file: /boot/kernel/zfs.ko - unsupported file type
>> KLD zfs.ko: depends on kernel - not available or version mismatch
>> linker_load_file: /boot/kernel/zfs.ko - unsupported file type
>> KLD zfs.ko: depends on kernel - not available or version mismatch
>> linker_load_file: /boot/kernel/zfs.ko - unsupported file type
> 
> Be sure to check out /var/log/messages for extra issues.  For example, with
> the bug I mentioned below, I couldn't load my nvidia driver and that manifested
> as one driver having issues because it depended on another, which had the root
> of the problem.

I forgot to look there. If I find anything suspicious there, I?ll let you know. That system doesn?t have a convenient mail client yet, so for now its copying output to files and scp-ing that to the Mac.

>> I can load the zfs kernel module from kernel.old just fine:
>> 
>> ZFS filesystem version: 5
>> ZFS storage pool version: features support (5000)
> 
> I kicked my more bleeding-edge system over from 12.2-rel (r366954) up into
> 13.0-current (r367044, 1300123) on 2020/10/26.  OpenZFS kicked in 2020/8/24?
> I think the CFT was ~2018/8/21, not sure when we had the OpenZFS ports.
> Current bumps the ABI version pretty frequently so I'd think you'd have
> tripped across versioning issues a long time ago if you had some drivers not
> being rebuilt.

Having a conflict between kernel and world was what I was expecting too, but I can?t figure out what got me into that situation. For all I know, they should be in sync now, especially after I reverted the tree back to rev 366335 and making world again (acc. to above method).

> 
>> This happens with any kernel module I???ve tried, such as geom_mirror and amdgpu (from ports/graphics/drm-current-kmod - the latter causes a kernel panic with kernel.old BTW).
>> 
>> I???ve gone back as far as Oct 7 (before changes to kern/elf_load_obj.c off the top of my head), looked at mailing list archives and forums etc, all to no avail.
>> 
>> I have / on UFS+J and /usr on ZFS and nothing in /etc/src.conf. I had /etc/malloc.conf with the recommended symlink from UPDATING, but the same happens with that moved out of the way. Nothing seems to help.
>> 
>> Do I need to go back further to get into a usable state or is there something else I should be doing?
> 
> With very few exceptions (bug 250897, 2020/11/6), I've found 13-current
> bootable since 10/26 (up through my current system, 13.0 r368388 (2020/12/6).
> You obviously need to make sure that an extra drivers you add in are compiled
> against the kernel, but ZFS is typically one of those.

I think we covered that.

Thanks for the help and the pointers, but unfortunately the mystery remains.

Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll find there is no forest.


From freebsd at grem.de  Tue Dec  8 18:19:35 2020
From: freebsd at grem.de (Michael Gmelin)
Date: Tue, 8 Dec 2020 19:18:54 +0100
Subject: KLD zfs.ko: depends on kernel - not available or version mismatch
In-Reply-To: <2B044A92-500F-4121-85DB-D486865C75B5@gmail.com>
References: <42AC7323-5AD6-401D-9A7D-F1D962EE5717@gmail.com>
 <X8+ebiETBdNpbRXt@phouka1.phouka.net>
 <2B044A92-500F-4121-85DB-D486865C75B5@gmail.com>
Message-ID: <20201208191854.33fbb929@bsd64.grem.de>



On Tue, 8 Dec 2020 19:10:26 +0100
Alban Hertroys <haramrae at gmail.com> wrote:

> > On 8 Dec 2020, at 16:40, John Kennedy <warlock at phouka.net> wrote:
> > 
> > On Tue, Dec 08, 2020 at 08:56:25AM +0100, Alban Hertroys wrote:  
> >> This seems to have gotten lost in the moderate queue, but after a
> >> week I am no closer to a solution, so here???s a resend:
> >> 
> >> I???ve been trying to get a fresh world running (for the eventual
> >> purpose of running amdgpu against my recent graphics adapter), but
> >> I run into trouble with core loadable kernel modules, such as
> >> zfs.ko from the subject. It also happens with other modules that I
> >> tried randomly, for example, geom_mirror.ko.
> >> 
> >> I updated to the latest current using svn up in /usr/src, then:
> >> 	make clean
> >> 	make buildworld kernel -j12
> >> 	shutdown -r now
> >> 
> >> boot to single user mode
> >> 
> >> 	kldload zfs  
> > 
> > I'm not sure you've provided enough information for a one-shot
> > armchair diagnosis, but some things seem factually wrong.  For
> > example, my normal rebuild procedure is:
> > 
> > 	cd /usr/src && make buildworld && make buildkernel
> > 	make installkernel
> > 	shutdown -r now
> > 
> > 	cd /usr/src && mergemaster -pi
> > 	make installworld
> > 	mergemaster -Fi
> > 	make -DBATCH_DELETE_OLD_FILES delete-old  
> 
> Aha! So that?s how to prevent having to press ?y? for every
> deprecated file!
> 
> > 	shutdown -r now
> > 
> > 	cd /usr/src && make -DBATCH_DELETE_OLD_FILES delete-old-libs
> > 
> > (I'm on a desktop system here.  You haven't described your setup.)  
> 
> This is also a desktop system.
> 
> > You didn't say that you've installed the new kernel, which at least
> > starts you down the road towards a driver/kernel mismatch.  You
> > presumably have a non-ZFS boot+root.  
> 
> I?m fairly sure I did, actually.
> 
> Last time I checked, "make buildworld buildkernel" was equivalent to
> "make buildworld && make buildkernel", while "make kernel? is a
> shorthand for ?make buildkernel && make installkernel?
> 
> So, unless I?m mistaken, ?make buildworld kernel? should be
> equivalent to your first two lines.
> 
> Nevertheless, I retried without these assumptions, the result was the
> same. I forgot to ?make delete-old? though, I rarely remember to do
> that?
> 
> >  Did you mess around with the ZFS from ports (ZoL -> ZoF)
> > at some point so you're not using the kernel's ZFS drivers?  What
> > ZFS entries do you have in /etc/loader.conf, /etc/rc.conf, and some
> > of the varients that may get dragged in?  (see rc.conf(5) for
> > possibilities)  
> 
> Nope, stock modules here.
> 
> > At the bottom of your email, you say / is UFS and /usr is ZFS, but
> > I guess we have the extra fun of wondering what is under /usr on
> > your /?  If you have a pre-ZFS /usr that is populated by something
> > now presumably very old (because all the new, current stuff went
> > onto ZFS /usr, now unavailable).  
> 
> There is no populated directory /usr on the UFS file-system. This
> install was created on a fresh NVME disk based on an existing install
> on a spinning platter. The install happened with /usr mounted at the
> ZFS file-system.
> 
> I had to copy over several files from /etc and /usr/local/etc and
> re-installed the most important packages. This was admittedly a bit
> messy, it is possible that I forgot to copy something over.
> (Originally my intention was to dd the contents of the spinning disk
> over, but apparently that disk has a few wonky sectors, dd failed
> after a few device timeouts)
> 
> 
> I did sort-of manage to fix things, but recent kernels keep causing
> the same issue:
> 
> I noticed that uname -a said I was at revision 366335, while I had
> the source tree up-to-date. For a test, I reverted back to that
> revision and went through: make buildworld make buildkernel
> 
> Which broke on /usr/local/sys/drm-current-kmod, which I turned out to
> have installed through pkg. There have been changes to the linux_kpi
> shortly after above revision - probably what broke compatibility
> between HEAD and r366335.
> 
> After removing that pkg, the kernel built and installed, world
> installed fine too and I have a working system again, with kernel and
> world in sync.
> 
> So I tried again to move to HEAD:
> 
> 	cd /usr/src
> 	svn up
> 	make buildworld -j12
> 	make buildkernel -j12
> 	make installkernel
> 	shutdown -r now
> 	<single user mode>
> 	mount -u /
> 	zpool import -Nf system (my /usr FS)
> 
> KLD zfs.ko: depends on kernel - not available or version mismatch
> linker_load_file: /boot/kernel/zfs.ko - unsupported file type
> 
> 
> >> Which results in dmesg messages:
> >> 
> >> KLD zfs.ko: depends on kernel - not available or version mismatch
> >> linker_load_file: /boot/kernel/zfs.ko - unsupported file type
> >> KLD zfs.ko: depends on kernel - not available or version mismatch
> >> linker_load_file: /boot/kernel/zfs.ko - unsupported file type
> >> KLD zfs.ko: depends on kernel - not available or version mismatch
> >> linker_load_file: /boot/kernel/zfs.ko - unsupported file type
> >> KLD zfs.ko: depends on kernel - not available or version mismatch
> >> linker_load_file: /boot/kernel/zfs.ko - unsupported file type  
> > 
> > Be sure to check out /var/log/messages for extra issues.  For
> > example, with the bug I mentioned below, I couldn't load my nvidia
> > driver and that manifested as one driver having issues because it
> > depended on another, which had the root of the problem.  
> 
> I forgot to look there. If I find anything suspicious there, I?ll let
> you know. That system doesn?t have a convenient mail client yet, so
> for now its copying output to files and scp-ing that to the Mac.
> 
> >> I can load the zfs kernel module from kernel.old just fine:
> >> 
> >> ZFS filesystem version: 5
> >> ZFS storage pool version: features support (5000)  
> > 
> > I kicked my more bleeding-edge system over from 12.2-rel (r366954)
> > up into 13.0-current (r367044, 1300123) on 2020/10/26.  OpenZFS
> > kicked in 2020/8/24? I think the CFT was ~2018/8/21, not sure when
> > we had the OpenZFS ports. Current bumps the ABI version pretty
> > frequently so I'd think you'd have tripped across versioning issues
> > a long time ago if you had some drivers not being rebuilt.  
> 
> Having a conflict between kernel and world was what I was expecting
> too, but I can?t figure out what got me into that situation. For all
> I know, they should be in sync now, especially after I reverted the
> tree back to rev 366335 and making world again (acc. to above method).
> 
> >   
> >> This happens with any kernel module I???ve tried, such as
> >> geom_mirror and amdgpu (from ports/graphics/drm-current-kmod - the
> >> latter causes a kernel panic with kernel.old BTW).
> >> 
> >> I???ve gone back as far as Oct 7 (before changes to
> >> kern/elf_load_obj.c off the top of my head), looked at mailing
> >> list archives and forums etc, all to no avail.
> >> 
> >> I have / on UFS+J and /usr on ZFS and nothing in /etc/src.conf. I
> >> had /etc/malloc.conf with the recommended symlink from UPDATING,
> >> but the same happens with that moved out of the way. Nothing seems
> >> to help.
> >> 
> >> Do I need to go back further to get into a usable state or is
> >> there something else I should be doing?  
> > 
> > With very few exceptions (bug 250897, 2020/11/6), I've found
> > 13-current bootable since 10/26 (up through my current system, 13.0
> > r368388 (2020/12/6). You obviously need to make sure that an extra
> > drivers you add in are compiled against the kernel, but ZFS is
> > typically one of those.  
> 
> I think we covered that.
> 
> Thanks for the help and the pointers, but unfortunately the mystery
> remains.
> 

Do you have anything in /boot/modules?
(wild shot)

-m


-- 
Michael Gmelin

From bakul at iitbombay.org  Tue Dec  8 21:03:24 2020
From: bakul at iitbombay.org (Bakul Shah)
Date: Tue, 8 Dec 2020 13:03:19 -0800
Subject: KLD zfs.ko: depends on kernel - not available or version mismatch
In-Reply-To: <2B044A92-500F-4121-85DB-D486865C75B5@gmail.com>
References: <42AC7323-5AD6-401D-9A7D-F1D962EE5717@gmail.com>
 <X8+ebiETBdNpbRXt@phouka1.phouka.net>
 <2B044A92-500F-4121-85DB-D486865C75B5@gmail.com>
Message-ID: <A7686883-343E-4F4C-B6CE-6F64385B727C@iitbombay.org>

On Dec 8, 2020, at 10:10 AM, Alban Hertroys <haramrae at gmail.com> wrote:
> 
> So I tried again to move to HEAD:
> 
> 	cd /usr/src
> 	svn up
> 	make buildworld -j12
> 	make buildkernel -j12
> 	make installkernel
> 	shutdown -r now
> 	<single user mode>
> 	mount -u /
> 	zpool import -Nf system (my /usr FS)
> 
> KLD zfs.ko: depends on kernel - not available or version mismatch
> linker_load_file: /boot/kernel/zfs.ko - unsupported file type
> 

cd /usr/obj/usr/src/amd64.amd64/sys/GENERIC
ls -l kernel /boot/kernel/kernel
ls -l modules/usr/src/sys/modules/zfs/zfs.ko /boot/kernel/zfs.ko
cmp modules/usr/src/sys/modules/zfs/zfs.ko /boot/kernel/zfs.ko

The kernel should be *older* than zfs.ko and both instances of zfs.ko
should be identical.

One other thought is to manually do

kldload opensolaris.ko zfs.ko

In single user mode before using zpool. I have

opensolaris_load="YES"
zfs_load="YES"

in /boot/loader.conf but you may not want to add those until you know
zfs works.

From warlock at phouka.net  Wed Dec  9 02:50:14 2020
From: warlock at phouka.net (John Kennedy)
Date: Tue, 8 Dec 2020 18:48:56 -0800
Subject: KLD zfs.ko: depends on kernel - not available or version mismatch
In-Reply-To: <2B044A92-500F-4121-85DB-D486865C75B5@gmail.com>
References: <42AC7323-5AD6-401D-9A7D-F1D962EE5717@gmail.com>
 <X8+ebiETBdNpbRXt@phouka1.phouka.net>
 <2B044A92-500F-4121-85DB-D486865C75B5@gmail.com>
Message-ID: <X9A7GHdxrVlf4Jj7@phouka1.phouka.net>

On Tue, Dec 08, 2020 at 07:10:26PM +0100, Alban Hertroys wrote:
> > You didn't say that you've installed the new kernel, which at least starts
> > you down the road towards a driver/kernel mismatch.  You presumably have a
> > non-ZFS boot+root.
> 
> I???m fairly sure I did, actually.
> 
> Last time I checked, "make buildworld buildkernel" was equivalent to "make buildworld && make buildkernel", while "make kernel??? is a shorthand for ???make buildkernel && make installkernel???
> 
> So, unless I???m mistaken, ???make buildworld kernel??? should be equivalent to your first two lines.
> 
> Nevertheless, I retried without these assumptions, the result was the same. I forgot to ???make delete-old??? though, I rarely remember to do that???

Ah, the dangers of command syntax being close to human syntax.  You're trying
to do the right thing, so maybe we can sanity check that.

> I had to copy over several files from /etc and /usr/local/etc and re-installed the most important packages. This was admittedly a bit messy, it is possible that I forgot to copy something over.
> (Originally my intention was to dd the contents of the spinning disk over, but apparently that disk has a few wonky sectors, dd failed after a few device timeouts)

  ... so, no guarantee that things are totally sane.

The "sane" we're looking for is how you can presumably be booting a kernel
located at /boot/kernel/kernel and not have it match the kernel modules
found under /boot/kernel.

The fact that it is happy with the old kernel modules (presumably under found
in /boot/kernel.old) may be a red herring if they're just compatible enough.


I can see what I'm expecting to boot here:

	# grep -E 'boot\/kernel|f7b0aedd1c50' /var/log/messages | tail -2
	Dec  6 08:59:04 ouroboros syslogd: kernel boot file is /boot/kernel/kernel
	Dec  6 08:59:04 ouroboros kernel: FreeBSD 13.0-CURRENT #237 r368388+f7b0aedd1c50-c273383(master): Sun Dec  6 08:27:47 PST 2020


So, I build my system with WITHOUT_REPRODUCIBLE_BUILD=YES in /etc/src.conf,
so I can easily see my build version with uname -v:

	FreeBSD 13.0-CURRENT #237 r368388+f7b0aedd1c50-c273383(master): ...

That matches my source tree:

	# git log -n1 /usr/src | grep revision
	    svn path=/head/; revision=368388

(I've always used git for my sources, but I'm sure there is a svn equivalent.)

The version I'm running is what and where I'd expect it to be:

	# strings -a < /boot/kernel/kernel | grep 'FreeBSD 13' | tail -1
	FreeBSD 13.0-CURRENT #237 r368388+f7b0aedd1c50-c273383(master): Sun Dec  6 08:27:47 PST 2020

It certainly isn't the previous kernel:

	# strings -a < /boot/kernel.old/kernel | grep 'FreeBSD 13' | tail -1
	FreeBSD 13.0-CURRENT #236 r368353+0252bfaea893-c273359(master): Fri Dec  4 16:55:41 PST 2020

Not sure what that'll look like with reproducible builds.  The hash-check below
is a decent stamp, in case the timestamps in /boot/kernel are misleading.

What I have built in my source tree is the kernel/zfs module I'd expect:

	# md5 -r /usr/obj/usr/src/amd64.amd64/sys/GENERIC/kernel /usr/obj/usr/src/amd64.amd64/sys/GENERIC/modules/usr/src/sys/modules/zfs/zfs.ko /boot/kernel/kernel /boot/kernel/zfs.ko | sort
	941ab52d075e444da6eea7fb56213e10 /boot/kernel/kernel
	941ab52d075e444da6eea7fb56213e10 /usr/obj/usr/src/amd64.amd64/sys/GENERIC/kernel
	97d4e0c8ffed1f75e924bf8768a95ff1 /boot/kernel/zfs.ko
	97d4e0c8ffed1f75e924bf8768a95ff1 /usr/obj/usr/src/amd64.amd64/sys/GENERIC/modules/usr/src/sys/modules/zfs/zfs.ko

What are you seeing after your installkernel equivalent?

Your hashes won't match mine due to non-reproducible build.

I'd make sure you don't have anything in /boot/modules or otherwise load any
extra modules until sanity is restored (just to reduce random variables).


From ohartmann at walstatt.org  Wed Dec  9 05:58:59 2020
From: ohartmann at walstatt.org (Hartmann, O.)
Date: Wed, 9 Dec 2020 06:58:49 +0100
Subject: AMNESIA:33 and FreeBSD TCP/IP stack involvement
Message-ID: <20201209065849.47a51561@hermann.fritz.box>

Hello,
I've got a question about recently discovered serious vulnerabilities
in certain TCP stack implementations, designated as AMNESIA:33 (as far
as I could follow the recently made announcements and statements,
please see, for instance,
https://www.zdnet.com/article/amnesia33-vulnerabilities-impact-millions-of-smart-and-industrial-devices/).

All mentioned open-source TCP stacks seem not to be related in any way
with freeBSD or any derivative of the FreeBSD project, but I do not
dare to make a statement about that.

My question is very simple and aimes towards calming down my employees
requests: is FreeBSD potentially vulnerable to this newly discovered
flaw (we use mainly 12.1-RELENG, 12.2-RELENG, 12-STABLE and 13-CURRENT,
latest incarnations, of course, should be least vulnerable ...).

Thanks in advance,

O. Hartmann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20201209/1c095167/attachment.sig>

From guru at unixarea.de  Wed Dec  9 09:44:42 2020
From: guru at unixarea.de (Matthias Apitz)
Date: Wed, 9 Dec 2020 10:44:37 +0100
Subject: after update to r368166: no sound recording
Message-ID: <X9CchZFla3RMFd/3@c720-r368166.fritz.box>


Hello,

I've updated a laptop Acer C720 from r342378 to r368166 and do not have
any sound incoming anymore. I rebooted r342378 from an USB stick and the
old kernel produces already noise in the speakers when I touch the
micro hole in the keyboard, the new kernel does not produce any noise
there. Both system have the same /boot/device.hints values:

#
hint.hdaa.1.nid20.config="as=3 seq=0"
hint.hdaa.1.nid25.config="as=2 seq=15"
hint.hdaa.1.nid26.config="as=2 seq=14"
hint.hdaa.1.nid33.config="as=3 seq=15"

I booted both in verbose mode and the messages about 'pcm1' are
identically (after removing the time stamps and system name from the
lines in /var/log/messages). See below. Any idea what I could check?

Thanks

	matthias


# diff pcm1.342378 pcm1.368166

# cat pcm1.368166

kernel: pcm1: <Realtek ALC283 (Analog 2.0+HP/2.0)> at nid 20,33 and 26,25 on hdaa1
kernel: pcm1: Playback:
kernel: pcm1:      Stream cap: 0x00000001 PCM
kernel: pcm1:         PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz
kernel: pcm1:             DAC: 2
kernel: pcm1: 
kernel: pcm1:     nid=20 [pin: Speaker (Fixed)]
kernel: pcm1:       + <- nid=12 [audio mixer] [src: pcm, mix]
kernel: pcm1:              + <- nid=2 [audio output] [src: pcm]
kernel: pcm1:              + <- nid=11 [audio mixer] [src: mix]
kernel: pcm1: 
kernel: pcm1:     nid=33 [pin: Headphones (Black Jack)]
kernel: pcm1:       + <- nid=12 [audio mixer] [src: pcm, mix]
kernel: pcm1:              + <- nid=2 [audio output] [src: pcm]
kernel: pcm1:              + <- nid=11 [audio mixer] [src: mix]
kernel: pcm1: 
kernel: pcm1: Record:
kernel: pcm1:      Stream cap: 0x00000001 PCM
kernel: pcm1:         PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz
kernel: pcm1:             ADC: 8
kernel: pcm1:             ADC: 9
kernel: pcm1: 
kernel: pcm1:     nid=8 [audio input]
kernel: pcm1:       + <- nid=35 [audio mixer] [src: speaker, mic, mix, monitor]
kernel: pcm1:              + <- nid=25 [pin: Mic (Black Jack)] [src: mic]
kernel: pcm1:              + <- nid=26 [pin: Mic (Fixed)] [src: monitor]
kernel: pcm1:              + <- nid=29 [beep widget] [src: speaker]
kernel: pcm1:              + <- nid=11 [audio mixer] [src: mix]
kernel: pcm1: 
kernel: pcm1:     nid=9 [audio input]
kernel: pcm1:       + <- nid=34 [audio mixer] [src: speaker, mic, mix, monitor]
kernel: pcm1:              + <- nid=25 [pin: Mic (Black Jack)] [src: mic]
kernel: pcm1:              + <- nid=26 [pin: Mic (Fixed)] [src: monitor]
kernel: pcm1:              + <- nid=29 [beep widget] [src: speaker]
kernel: pcm1:              + <- nid=11 [audio mixer] [src: mix]
kernel: pcm1: 
kernel: pcm1: Input Mix:
kernel: pcm1: 
kernel: pcm1:     nid=11 [audio mixer]
kernel: pcm1:       + <- nid=25 [pin: Mic (Black Jack)] [src: mic]
kernel: pcm1:       + <- nid=26 [pin: Mic (Fixed)] [src: monitor]
kernel: pcm1:       + <- nid=29 [beep widget] [src: speaker]
kernel: pcm1: 
kernel: pcm1: Master Volume (OSS: vol): -65/0dB
kernel: pcm1:    +- ctl  1 (nid   2 out):    -65/0dB (88 steps)
kernel: pcm1:    +- ctl 10 (nid  12 in   0): mute
kernel: pcm1:    +- ctl 11 (nid  12 in   1): mute
kernel: pcm1:    +- ctl 17 (nid  20 in ):    mute
kernel: pcm1:    +- ctl 24 (nid  33 in ):    mute
kernel: pcm1: 
kernel: pcm1: PCM Volume (OSS: pcm): -65/0dB
kernel: pcm1:    +- ctl  1 (nid   2 out):    -65/0dB (88 steps)
kernel: pcm1:    +- ctl 10 (nid  12 in   0): mute
kernel: pcm1: 
kernel: pcm1: Microphone Volume (OSS: mic): 0/36dB
kernel: pcm1:    +- ctl  6 (nid  11 in   1): -34/12dB (32 steps) + mute
kernel: pcm1:    +- ctl 20 (nid  25 out):    0/36dB (4 steps)
kernel: pcm1:    +- ctl 26 (nid  34 in   1): mute
kernel: pcm1:    +- ctl 32 (nid  35 in   1): mute
kernel: pcm1: 
kernel: pcm1: Microphone2 Volume (OSS: monitor): 0/36dB
kernel: pcm1:    +- ctl  7 (nid  11 in   2): -34/12dB (32 steps) + mute
kernel: pcm1:    +- ctl 21 (nid  26 out):    0/36dB (4 steps)
kernel: pcm1:    +- ctl 27 (nid  34 in   2): mute
kernel: pcm1:    +- ctl 33 (nid  35 in   2): mute
kernel: pcm1: 
kernel: pcm1: Speaker/Beep Volume (OSS: speaker): -34/12dB
kernel: pcm1:    +- ctl  9 (nid  11 in   4): -34/12dB (32 steps) + mute
kernel: pcm1:    +- ctl 29 (nid  34 in   4): mute
kernel: pcm1:    +- ctl 35 (nid  35 in   4): mute
kernel: pcm1: 
kernel: pcm1: Recording Level (OSS: rec): -17/30dB
kernel: pcm1:    +- ctl  3 (nid   8 in   0): -17/30dB (64 steps) + mute
kernel: pcm1:    +- ctl  4 (nid   9 in   0): -17/30dB (64 steps) + mute
kernel: pcm1:    +- ctl 26 (nid  34 in   1): mute
kernel: pcm1:    +- ctl 27 (nid  34 in   2): mute
kernel: pcm1:    +- ctl 29 (nid  34 in   4): mute
kernel: pcm1:    +- ctl 30 (nid  34 in   5): mute
kernel: pcm1:    +- ctl 32 (nid  35 in   1): mute
kernel: pcm1:    +- ctl 33 (nid  35 in   2): mute
kernel: pcm1:    +- ctl 35 (nid  35 in   4): mute
kernel: pcm1:    +- ctl 36 (nid  35 in   5): mute
kernel: pcm1: 
kernel: pcm1: Input Mix Level (OSS: mix): -34/12dB
kernel: pcm1:    +- ctl  6 (nid  11 in   1): -34/12dB (32 steps) + mute
kernel: pcm1:    +- ctl  7 (nid  11 in   2): -34/12dB (32 steps) + mute
kernel: pcm1:    +- ctl  9 (nid  11 in   4): -34/12dB (32 steps) + mute
kernel: pcm1:    +- ctl 11 (nid  12 in   1): mute
kernel: pcm1:    +- ctl 30 (nid  34 in   5): mute
kernel: pcm1:    +- ctl 36 (nid  35 in   5): mute
kernel: pcm1: 
kernel: pcm1: Input Monitoring Level (OSS: igain): 0/0dB
kernel: pcm1:    +- ctl 11 (nid  12 in   1): mute
kernel: pcm1: 
kernel: pcm1: Mixer "vol":
kernel: pcm1: Mixer "pcm":
kernel: pcm1: Mixer "speaker":
kernel: pcm1: Mixer "mic":
kernel: pcm1: Mixer "mix":
kernel: pcm1: Mixer "rec":
kernel: pcm1: Mixer "igain":
kernel: pcm1: Mixer "ogain":
kernel: pcm1: Mixer "monitor":
kernel: pcm1: Playback channel set is: Front Left, Front Right, 
kernel: pcm1: Playback channel matrix is: 2.0 (unknown)
kernel: pcm1: Automatically set rec source to: monitor
kernel: pcm1: Recording channel set is: Front Left, Front Right, 
kernel: pcm1: Recording channel matrix is: 2.0 (unknown)
-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

From hps at selasky.org  Wed Dec  9 10:05:31 2020
From: hps at selasky.org (Hans Petter Selasky)
Date: Wed, 9 Dec 2020 11:05:09 +0100
Subject: after update to r368166: no sound recording
In-Reply-To: <X9CchZFla3RMFd/3@c720-r368166.fritz.box>
References: <X9CchZFla3RMFd/3@c720-r368166.fritz.box>
Message-ID: <72bd5240-3092-bf7b-51aa-2ad12a576efb@selasky.org>

On 12/9/20 10:44 AM, Matthias Apitz wrote:
> 
> Hello,
> 
> I've updated a laptop Acer C720 from r342378 to r368166 and do not have
> any sound incoming anymore. I rebooted r342378 from an USB stick and the
> old kernel produces already noise in the speakers when I touch the
> micro hole in the keyboard, the new kernel does not produce any noise
> there. Both system have the same /boot/device.hints values:
> 
> #
> hint.hdaa.1.nid20.config="as=3 seq=0"
> hint.hdaa.1.nid25.config="as=2 seq=15"
> hint.hdaa.1.nid26.config="as=2 seq=14"
> hint.hdaa.1.nid33.config="as=3 seq=15"
> 
> I booted both in verbose mode and the messages about 'pcm1' are
> identically (after removing the time stamps and system name from the
> lines in /var/log/messages). See below. Any idea what I could check?
> 
> Thanks
> 
> 	matthias
> 
> 
> # diff pcm1.342378 pcm1.368166
> 
> # cat pcm1.368166
> 
> kernel: pcm1: <Realtek ALC283 (Analog 2.0+HP/2.0)> at nid 20,33 and 26,25 on hdaa1
> kernel: pcm1: Playback:
> kernel: pcm1:      Stream cap: 0x00000001 PCM
> kernel: pcm1:         PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz
> kernel: pcm1:             DAC: 2
> kernel: pcm1:
> kernel: pcm1:     nid=20 [pin: Speaker (Fixed)]
> kernel: pcm1:       + <- nid=12 [audio mixer] [src: pcm, mix]
> kernel: pcm1:              + <- nid=2 [audio output] [src: pcm]
> kernel: pcm1:              + <- nid=11 [audio mixer] [src: mix]
> kernel: pcm1:
> kernel: pcm1:     nid=33 [pin: Headphones (Black Jack)]
> kernel: pcm1:       + <- nid=12 [audio mixer] [src: pcm, mix]
> kernel: pcm1:              + <- nid=2 [audio output] [src: pcm]
> kernel: pcm1:              + <- nid=11 [audio mixer] [src: mix]
> kernel: pcm1:
> kernel: pcm1: Record:
> kernel: pcm1:      Stream cap: 0x00000001 PCM
> kernel: pcm1:         PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz
> kernel: pcm1:             ADC: 8
> kernel: pcm1:             ADC: 9
> kernel: pcm1:
> kernel: pcm1:     nid=8 [audio input]
> kernel: pcm1:       + <- nid=35 [audio mixer] [src: speaker, mic, mix, monitor]
> kernel: pcm1:              + <- nid=25 [pin: Mic (Black Jack)] [src: mic]
> kernel: pcm1:              + <- nid=26 [pin: Mic (Fixed)] [src: monitor]
> kernel: pcm1:              + <- nid=29 [beep widget] [src: speaker]
> kernel: pcm1:              + <- nid=11 [audio mixer] [src: mix]
> kernel: pcm1:
> kernel: pcm1:     nid=9 [audio input]
> kernel: pcm1:       + <- nid=34 [audio mixer] [src: speaker, mic, mix, monitor]
> kernel: pcm1:              + <- nid=25 [pin: Mic (Black Jack)] [src: mic]
> kernel: pcm1:              + <- nid=26 [pin: Mic (Fixed)] [src: monitor]
> kernel: pcm1:              + <- nid=29 [beep widget] [src: speaker]
> kernel: pcm1:              + <- nid=11 [audio mixer] [src: mix]
> kernel: pcm1:
> kernel: pcm1: Input Mix:
> kernel: pcm1:
> kernel: pcm1:     nid=11 [audio mixer]
> kernel: pcm1:       + <- nid=25 [pin: Mic (Black Jack)] [src: mic]
> kernel: pcm1:       + <- nid=26 [pin: Mic (Fixed)] [src: monitor]
> kernel: pcm1:       + <- nid=29 [beep widget] [src: speaker]
> kernel: pcm1:
> kernel: pcm1: Master Volume (OSS: vol): -65/0dB
> kernel: pcm1:    +- ctl  1 (nid   2 out):    -65/0dB (88 steps)
> kernel: pcm1:    +- ctl 10 (nid  12 in   0): mute
> kernel: pcm1:    +- ctl 11 (nid  12 in   1): mute
> kernel: pcm1:    +- ctl 17 (nid  20 in ):    mute
> kernel: pcm1:    +- ctl 24 (nid  33 in ):    mute
> kernel: pcm1:
> kernel: pcm1: PCM Volume (OSS: pcm): -65/0dB
> kernel: pcm1:    +- ctl  1 (nid   2 out):    -65/0dB (88 steps)
> kernel: pcm1:    +- ctl 10 (nid  12 in   0): mute
> kernel: pcm1:
> kernel: pcm1: Microphone Volume (OSS: mic): 0/36dB
> kernel: pcm1:    +- ctl  6 (nid  11 in   1): -34/12dB (32 steps) + mute
> kernel: pcm1:    +- ctl 20 (nid  25 out):    0/36dB (4 steps)
> kernel: pcm1:    +- ctl 26 (nid  34 in   1): mute
> kernel: pcm1:    +- ctl 32 (nid  35 in   1): mute
> kernel: pcm1:
> kernel: pcm1: Microphone2 Volume (OSS: monitor): 0/36dB
> kernel: pcm1:    +- ctl  7 (nid  11 in   2): -34/12dB (32 steps) + mute
> kernel: pcm1:    +- ctl 21 (nid  26 out):    0/36dB (4 steps)
> kernel: pcm1:    +- ctl 27 (nid  34 in   2): mute
> kernel: pcm1:    +- ctl 33 (nid  35 in   2): mute
> kernel: pcm1:
> kernel: pcm1: Speaker/Beep Volume (OSS: speaker): -34/12dB
> kernel: pcm1:    +- ctl  9 (nid  11 in   4): -34/12dB (32 steps) + mute
> kernel: pcm1:    +- ctl 29 (nid  34 in   4): mute
> kernel: pcm1:    +- ctl 35 (nid  35 in   4): mute
> kernel: pcm1:
> kernel: pcm1: Recording Level (OSS: rec): -17/30dB
> kernel: pcm1:    +- ctl  3 (nid   8 in   0): -17/30dB (64 steps) + mute
> kernel: pcm1:    +- ctl  4 (nid   9 in   0): -17/30dB (64 steps) + mute
> kernel: pcm1:    +- ctl 26 (nid  34 in   1): mute
> kernel: pcm1:    +- ctl 27 (nid  34 in   2): mute
> kernel: pcm1:    +- ctl 29 (nid  34 in   4): mute
> kernel: pcm1:    +- ctl 30 (nid  34 in   5): mute
> kernel: pcm1:    +- ctl 32 (nid  35 in   1): mute
> kernel: pcm1:    +- ctl 33 (nid  35 in   2): mute
> kernel: pcm1:    +- ctl 35 (nid  35 in   4): mute
> kernel: pcm1:    +- ctl 36 (nid  35 in   5): mute
> kernel: pcm1:
> kernel: pcm1: Input Mix Level (OSS: mix): -34/12dB
> kernel: pcm1:    +- ctl  6 (nid  11 in   1): -34/12dB (32 steps) + mute
> kernel: pcm1:    +- ctl  7 (nid  11 in   2): -34/12dB (32 steps) + mute
> kernel: pcm1:    +- ctl  9 (nid  11 in   4): -34/12dB (32 steps) + mute
> kernel: pcm1:    +- ctl 11 (nid  12 in   1): mute
> kernel: pcm1:    +- ctl 30 (nid  34 in   5): mute
> kernel: pcm1:    +- ctl 36 (nid  35 in   5): mute
> kernel: pcm1:
> kernel: pcm1: Input Monitoring Level (OSS: igain): 0/0dB
> kernel: pcm1:    +- ctl 11 (nid  12 in   1): mute
> kernel: pcm1:
> kernel: pcm1: Mixer "vol":
> kernel: pcm1: Mixer "pcm":
> kernel: pcm1: Mixer "speaker":
> kernel: pcm1: Mixer "mic":
> kernel: pcm1: Mixer "mix":
> kernel: pcm1: Mixer "rec":
> kernel: pcm1: Mixer "igain":
> kernel: pcm1: Mixer "ogain":
> kernel: pcm1: Mixer "monitor":
> kernel: pcm1: Playback channel set is: Front Left, Front Right,
> kernel: pcm1: Playback channel matrix is: 2.0 (unknown)
> kernel: pcm1: Automatically set rec source to: monitor
> kernel: pcm1: Recording channel set is: Front Left, Front Right,
> kernel: pcm1: Recording channel matrix is: 2.0 (unknown)
> 

Hi,

Check output from:

mixer -f /dev/mixer<N>

--HPS

From guru at unixarea.de  Wed Dec  9 10:49:02 2020
From: guru at unixarea.de (Matthias Apitz)
Date: Wed, 9 Dec 2020 11:48:57 +0100
Subject: after update to r368166: no sound recording
In-Reply-To: <72bd5240-3092-bf7b-51aa-2ad12a576efb@selasky.org>
References: <X9CchZFla3RMFd/3@c720-r368166.fritz.box>
 <72bd5240-3092-bf7b-51aa-2ad12a576efb@selasky.org>
Message-ID: <X9Crmcsce57g0PER@c720-r368166.fritz.box>

El d?a mi?rcoles, diciembre 09, 2020 a las 11:05:09a. m. +0100, Hans Petter Selasky escribi?:

> On 12/9/20 10:44 AM, Matthias Apitz wrote:
> > 
> > Hello,
> > 
> > I've updated a laptop Acer C720 from r342378 to r368166 and do not have
> > any sound incoming anymore. I rebooted r342378 from an USB stick and the
> > old kernel produces already noise in the speakers when I touch the
> > micro hole in the keyboard, the new kernel does not produce any noise
> > there. Both system have the same /boot/device.hints values:
> > 
> > ....

> Hi,
> 
> Check output from:
> 
> mixer -f /dev/mixer<N>


Hi,

Here are the values (as on the older system):

# cat /dev/sndstat
Installed devices:
pcm0: <Intel Haswell (HDMI/DP 8ch)> (play)
pcm1: <Realtek ALC283 (Analog 2.0+HP/2.0)> (play/rec) default
No devices installed from userspace.

# ls -l /dev/mixer*
crw-rw-rw-  1 root  wheel  0x4b  9 dic.  10:52 /dev/mixer0
crw-rw-rw-  1 root  wheel  0x4e  9 dic.  10:52 /dev/mixer1

# mixer -f /dev/mixer0
Mixer vol      is currently set to 100:100
Mixer pcm      is currently set to 100:100

# mixer -f /dev/mixer1
Mixer vol      is currently set to 100:100
Mixer pcm      is currently set to 100:100
Mixer speaker  is currently set to 100:100
Mixer mic      is currently set to 100:100
Mixer mix      is currently set to 100:100
Mixer rec      is currently set to 100:100
Mixer igain    is currently set to 100:100
Mixer ogain    is currently set to 100:100
Mixer monitor  is currently set to 100:100
Recording source: mix

(I also tested the other rec devices: speaker, mic, mix, monitor).

And recording does not get any input:

$ rec -c 2 /tmp/out.wav

Input File     : 'default' (ossdsp)
Channels       : 2
Sample Rate    : 48000
Precision      : 16-bit
Sample Encoding: 16-bit Signed Integer PCM

In:0.00% 00:00:07.34 [00:00:00.00] Out:348k  [XXXXXX|XXXXXX]        Clip:0    ^C
Aborted.

Where I put the XXXXXX normally indicators are moving according the level
of the recorded noise. Nothing is there, only blanks.

Thanks

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

From hps at selasky.org  Wed Dec  9 10:55:39 2020
From: hps at selasky.org (Hans Petter Selasky)
Date: Wed, 9 Dec 2020 11:55:18 +0100
Subject: after update to r368166: no sound recording
In-Reply-To: <X9Crmcsce57g0PER@c720-r368166.fritz.box>
References: <X9CchZFla3RMFd/3@c720-r368166.fritz.box>
 <72bd5240-3092-bf7b-51aa-2ad12a576efb@selasky.org>
 <X9Crmcsce57g0PER@c720-r368166.fritz.box>
Message-ID: <4d83e630-7bed-16bd-3422-267813d3e842@selasky.org>

On 12/9/20 11:48 AM, Matthias Apitz wrote:
> El d?a mi?rcoles, diciembre 09, 2020 a las 11:05:09a. m. +0100, Hans Petter Selasky escribi?:
> 
>> On 12/9/20 10:44 AM, Matthias Apitz wrote:
>>>
>>> Hello,
>>>
>>> I've updated a laptop Acer C720 from r342378 to r368166 and do not have
>>> any sound incoming anymore. I rebooted r342378 from an USB stick and the
>>> old kernel produces already noise in the speakers when I touch the
>>> micro hole in the keyboard, the new kernel does not produce any noise
>>> there. Both system have the same /boot/device.hints values:
>>>
>>> ....
> 
>> Hi,
>>
>> Check output from:
>>
>> mixer -f /dev/mixer<N>
> 
> 
> Hi,
> 
> Here are the values (as on the older system):
> 
> # cat /dev/sndstat
> Installed devices:
> pcm0: <Intel Haswell (HDMI/DP 8ch)> (play)
> pcm1: <Realtek ALC283 (Analog 2.0+HP/2.0)> (play/rec) default
> No devices installed from userspace.
> 
> # ls -l /dev/mixer*
> crw-rw-rw-  1 root  wheel  0x4b  9 dic.  10:52 /dev/mixer0
> crw-rw-rw-  1 root  wheel  0x4e  9 dic.  10:52 /dev/mixer1
> 
> # mixer -f /dev/mixer0
> Mixer vol      is currently set to 100:100
> Mixer pcm      is currently set to 100:100
> 
> # mixer -f /dev/mixer1
> Mixer vol      is currently set to 100:100
> Mixer pcm      is currently set to 100:100
> Mixer speaker  is currently set to 100:100
> Mixer mic      is currently set to 100:100
> Mixer mix      is currently set to 100:100
> Mixer rec      is currently set to 100:100
> Mixer igain    is currently set to 100:100
> Mixer ogain    is currently set to 100:100
> Mixer monitor  is currently set to 100:100
> Recording source: mix
> 
> (I also tested the other rec devices: speaker, mic, mix, monitor).
> 
> And recording does not get any input:
> 
> $ rec -c 2 /tmp/out.wav
> 
> Input File     : 'default' (ossdsp)
> Channels       : 2
> Sample Rate    : 48000
> Precision      : 16-bit
> Sample Encoding: 16-bit Signed Integer PCM
> 
> In:0.00% 00:00:07.34 [00:00:00.00] Out:348k  [XXXXXX|XXXXXX]        Clip:0    ^C
> Aborted.
> 
> Where I put the XXXXXX normally indicators are moving according the level
> of the recorded noise. Nothing is there, only blanks.
> 

And also:

mixer =rec

Is set correctly?

--HPS

From guru at unixarea.de  Wed Dec  9 11:09:18 2020
From: guru at unixarea.de (Matthias Apitz)
Date: Wed, 9 Dec 2020 12:09:15 +0100
Subject: after update to r368166: no sound recording
In-Reply-To: <4d83e630-7bed-16bd-3422-267813d3e842@selasky.org>
References: <X9CchZFla3RMFd/3@c720-r368166.fritz.box>
 <72bd5240-3092-bf7b-51aa-2ad12a576efb@selasky.org>
 <X9Crmcsce57g0PER@c720-r368166.fritz.box>
 <4d83e630-7bed-16bd-3422-267813d3e842@selasky.org>
Message-ID: <X9CwWzSUrnWId1Jc@c720-r368166.fritz.box>

El d?a mi?rcoles, diciembre 09, 2020 a las 11:55:18a. m. +0100, Hans Petter Selasky escribi?:

> > Here are the values (as on the older system):
> > 
> > # cat /dev/sndstat
> > Installed devices:
> > pcm0: <Intel Haswell (HDMI/DP 8ch)> (play)
> > pcm1: <Realtek ALC283 (Analog 2.0+HP/2.0)> (play/rec) default
> > No devices installed from userspace.
> > 
> > # ls -l /dev/mixer*
> > crw-rw-rw-  1 root  wheel  0x4b  9 dic.  10:52 /dev/mixer0
> > crw-rw-rw-  1 root  wheel  0x4e  9 dic.  10:52 /dev/mixer1
> > 
> > # mixer -f /dev/mixer0
> > Mixer vol      is currently set to 100:100
> > Mixer pcm      is currently set to 100:100
> > 
> > # mixer -f /dev/mixer1
> > Mixer vol      is currently set to 100:100
> > Mixer pcm      is currently set to 100:100
> > Mixer speaker  is currently set to 100:100
> > Mixer mic      is currently set to 100:100
> > Mixer mix      is currently set to 100:100
> > Mixer rec      is currently set to 100:100
> > Mixer igain    is currently set to 100:100
> > Mixer ogain    is currently set to 100:100
> > Mixer monitor  is currently set to 100:100
> > Recording source: mix
> > 
> > (I also tested the other rec devices: speaker, mic, mix, monitor).
> > 
> > And recording does not get any input:
> > 
> > $ rec -c 2 /tmp/out.wav
> > 
> > Input File     : 'default' (ossdsp)
> > Channels       : 2
> > Sample Rate    : 48000
> > Precision      : 16-bit
> > Sample Encoding: 16-bit Signed Integer PCM
> > 
> > In:0.00% 00:00:07.34 [00:00:00.00] Out:348k  [XXXXXX|XXXXXX]        Clip:0    ^C
> > Aborted.
> > 
> > Where I put the XXXXXX normally indicators are moving according the level
> > of the recorded noise. Nothing is there, only blanks.
> > 
> 
> And also:
> 
> mixer =rec
> 
> Is set correctly?

This here is from the older r342378 system:

[guru at c720-r342378 ~]$ mixer
Mixer vol      is currently set to 100:100
Mixer pcm      is currently set to 100:100
Mixer speaker  is currently set to 100:100
Mixer mic      is currently set to 100:100
Mixer mix      is currently set to 100:100
Mixer rec      is currently set to 100:100
Mixer igain    is currently set to 100:100
Mixer ogain    is currently set to 100:100
Mixer monitor  is currently set to 100:100
Recording source: mix


[guru at c720-r342378 ~]$ rec -c 2 /tmp/out.wav

which is recording just fine. As I said, I tested all other values for
'=rec' too, i.e. the devices: speaker, mic, mix, monitor

	matthias

-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

From guru at unixarea.de  Wed Dec  9 11:20:54 2020
From: guru at unixarea.de (Matthias Apitz)
Date: Wed, 9 Dec 2020 12:20:51 +0100
Subject: after update to r368166: no sound recording
In-Reply-To: <X9CwWzSUrnWId1Jc@c720-r368166.fritz.box>
References: <X9CchZFla3RMFd/3@c720-r368166.fritz.box>
 <72bd5240-3092-bf7b-51aa-2ad12a576efb@selasky.org>
 <X9Crmcsce57g0PER@c720-r368166.fritz.box>
 <4d83e630-7bed-16bd-3422-267813d3e842@selasky.org>
 <X9CwWzSUrnWId1Jc@c720-r368166.fritz.box>
Message-ID: <X9CzE45PrpEOB4s8@c720-r368166.fritz.box>


When I attach an USB micro, I have one more audio devices:

[guru at c720-r368166 ~]$ cat /dev/sndstat
Installed devices:
pcm0: <Intel Haswell (HDMI/DP 8ch)> (play)
pcm1: <Realtek ALC283 (Analog 2.0+HP/2.0)> (play/rec)
pcm2: <USB audio> (play/rec) default
No devices installed from userspace.

and can do recording and play back fine with this:

[guru at c720-r368166 ~]$ mixer -f /dev/mixer2
Mixer vol      is currently set to 100:100
Mixer pcm      is currently set to 100:100
Mixer mic      is currently set to 100:100
Recording source: mic


[guru at c720-r368166 ~]$ AUDIODEV=/dev/dsp2.0 rec -c 2 /tmp/out.wav
[guru at c720-r368166 ~]$ AUDIODEV=/dev/dsp1.0 play /tmp/out.wav

-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

From zbeeble at gmail.com  Wed Dec  9 20:51:38 2020
From: zbeeble at gmail.com (Zaphod Beeblebrox)
Date: Wed, 9 Dec 2020 15:51:22 -0500
Subject: AMNESIA:33 and FreeBSD TCP/IP stack involvement
In-Reply-To: <20201209065849.47a51561@hermann.fritz.box>
References: <20201209065849.47a51561@hermann.fritz.box>
Message-ID: <CACpH0MfNW3THiO53og1Aqbb--fsgNCizAP6-+mvJQTLs0=kxbQ@mail.gmail.com>

I'm not posting as someone in-the-know about the state of the FreeBSD stack
--- I trust the security team to divulge things as required,

BUT ...

... the examples of vulnerable things in that article to reference lead me
to conclude that the stacks in question are "libraries" ... likely, but not
necessarily, written in C for systems running in an operating system-less
environment.  The easiest way to think about this is to look at the "at
mega" line (also known as arduino).  This is an 8-bit processor and the C
development kit allows you to link in all kinds of stuff --- from
filesystems and micro-sd card support to wifi and IP/IPv6 support.  The
same libraries are used when the target is a more powerful ARM chip --- but
one similarly running without something as full-fledged as an OS --- or
even when a very small vestige of an OS includes these libraries.

You could think of these libraries like "what if someone wrote an IP stack
for the commodore 64 and then also ported it to the Amiga" ... as a
computer without an operating system and then a port to a computer with an
operating system with no concept of networking.

At any rate, these, in general, do not even resemble the network stack in
FreeBSD... or indeed any other full fledged operating system.

Hopfully this tidbit helps in some small way.


On Wed, Dec 9, 2020 at 12:59 AM Hartmann, O. <ohartmann at walstatt.org> wrote:

> Hello,
> I've got a question about recently discovered serious vulnerabilities
> in certain TCP stack implementations, designated as AMNESIA:33 (as far
> as I could follow the recently made announcements and statements,
> please see, for instance,
>
> https://www.zdnet.com/article/amnesia33-vulnerabilities-impact-millions-of-smart-and-industrial-devices/
> ).
>
> All mentioned open-source TCP stacks seem not to be related in any way
> with freeBSD or any derivative of the FreeBSD project, but I do not
> dare to make a statement about that.
>
> My question is very simple and aimes towards calming down my employees
> requests: is FreeBSD potentially vulnerable to this newly discovered
> flaw (we use mainly 12.1-RELENG, 12.2-RELENG, 12-STABLE and 13-CURRENT,
> latest incarnations, of course, should be least vulnerable ...).
>
> Thanks in advance,
>
> O. Hartmann
>

From haramrae at gmail.com  Wed Dec  9 22:45:12 2020
From: haramrae at gmail.com (Alban Hertroys)
Date: Wed, 9 Dec 2020 23:45:06 +0100
Subject: KLD zfs.ko: depends on kernel - not available or version mismatch
In-Reply-To: <X9A7GHdxrVlf4Jj7@phouka1.phouka.net>
References: <42AC7323-5AD6-401D-9A7D-F1D962EE5717@gmail.com>
 <X8+ebiETBdNpbRXt@phouka1.phouka.net>
 <2B044A92-500F-4121-85DB-D486865C75B5@gmail.com>
 <X9A7GHdxrVlf4Jj7@phouka1.phouka.net>
Message-ID: <3027159B-1851-4005-A569-059A1CAACFCC@gmail.com>


> On 9 Dec 2020, at 3:48, John Kennedy <warlock at phouka.net> wrote:
> 
>> I had to copy over several files from /etc and /usr/local/etc and re-installed the most important packages. This was admittedly a bit messy, it is possible that I forgot to copy something over.
>> (Originally my intention was to dd the contents of the spinning disk over, but apparently that disk has a few wonky sectors, dd failed after a few device timeouts)
> 
>  ... so, no guarantee that things are totally sane.
> 
> The "sane" we're looking for is how you can presumably be booting a kernel
> located at /boot/kernel/kernel and not have it match the kernel modules
> found under /boot/kernel.

(...)

> What I have built in my source tree is the kernel/zfs module I'd expect:
> 
> 	# md5 -r /usr/obj/usr/src/amd64.amd64/sys/GENERIC/kernel /usr/obj/usr/src/amd64.amd64/sys/GENERIC/modules/usr/src/sys/modules/zfs/zfs.ko /boot/kernel/kernel /boot/kernel/zfs.ko | sort
> 	941ab52d075e444da6eea7fb56213e10 /boot/kernel/kernel
> 	941ab52d075e444da6eea7fb56213e10 /usr/obj/usr/src/amd64.amd64/sys/GENERIC/kernel
> 	97d4e0c8ffed1f75e924bf8768a95ff1 /boot/kernel/zfs.ko
> 	97d4e0c8ffed1f75e924bf8768a95ff1 /usr/obj/usr/src/amd64.amd64/sys/GENERIC/modules/usr/src/sys/modules/zfs/zfs.ko
> 
> What are you seeing after your installkernel equivalent?

It turns out that I was being fooled by the BIOS. Even though I selected the device that this kernel and modules were on as the device to boot from, the actual kernel was still coming from the old spinning disk!

It would probably have taken me significantly longer to figure that out without your hints, as I was trying to solve the wrong problem. So thanks a lot for that. Having things to verify was a tremendous help.

I used the opportunity to switch to EFI booting, which took me the better part of the evening, but that's working now and booting the correct kernel. It?s even booting into a 1280x720 resolution with the help of the drm-devel-kmod.

The next challenge is getting Xorg to run on this Navi-10 GPU; so far I get stuck with "[KMS] drm report modesetting isn't supported?.

> Your hashes won't match mine due to non-reproducible build.
> 
> I'd make sure you don't have anything in /boot/modules or otherwise load any
> extra modules until sanity is restored (just to reduce random variables).

Ah yes, I wasn?t aware of /boot/modules. Last time I used CURRENT, modules were still in the kernel directory. Hence, that was also where I pointed kldload to to test my modules, which explains part of the confusion (and there?s no modules.old?).


Alban Hertroys
--
There is always an exception to always.





From guru at unixarea.de  Thu Dec 10 14:16:23 2020
From: guru at unixarea.de (Matthias Apitz)
Date: Thu, 10 Dec 2020 15:16:17 +0100
Subject: Fwd: after update to r368166: no sound recording
Message-ID: <X9ItsQP5dnEvszoR@c720-r368166.fritz.box>


After spending a lot of hours and boots, I filed now an bug issue:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251727

Thanks

	matthias

----- Forwarded message from Matthias Apitz <guru at unixarea.de> -----

Date: Wed, 9 Dec 2020 10:44:37 +0100
From: Matthias Apitz <guru at unixarea.de>
To: freebsd-current at freebsd.org
Subject: after update to r368166: no sound recording


Hello,

I've updated a laptop Acer C720 from r342378 to r368166 and do not have
any sound incoming anymore. I rebooted r342378 from an USB stick and the
old kernel produces already noise in the speakers when I touch the
micro hole in the keyboard, the new kernel does not produce any noise
there. Both system have the same /boot/device.hints values:

#
hint.hdaa.1.nid20.config="as=3 seq=0"
hint.hdaa.1.nid25.config="as=2 seq=15"
hint.hdaa.1.nid26.config="as=2 seq=14"
hint.hdaa.1.nid33.config="as=3 seq=15"

I booted both in verbose mode and the messages about 'pcm1' are
identically (after removing the time stamps and system name from the
lines in /var/log/messages). See below. Any idea what I could check?

Thanks

	matthias


# diff pcm1.342378 pcm1.368166

# cat pcm1.368166

kernel: pcm1: <Realtek ALC283 (Analog 2.0+HP/2.0)> at nid 20,33 and 26,25 on hdaa1
kernel: pcm1: Playback:
kernel: pcm1:      Stream cap: 0x00000001 PCM
kernel: pcm1:         PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz
kernel: pcm1:             DAC: 2
kernel: pcm1: 
kernel: pcm1:     nid=20 [pin: Speaker (Fixed)]
kernel: pcm1:       + <- nid=12 [audio mixer] [src: pcm, mix]
kernel: pcm1:              + <- nid=2 [audio output] [src: pcm]
kernel: pcm1:              + <- nid=11 [audio mixer] [src: mix]
kernel: pcm1: 
kernel: pcm1:     nid=33 [pin: Headphones (Black Jack)]
kernel: pcm1:       + <- nid=12 [audio mixer] [src: pcm, mix]
kernel: pcm1:              + <- nid=2 [audio output] [src: pcm]
kernel: pcm1:              + <- nid=11 [audio mixer] [src: mix]
kernel: pcm1: 
kernel: pcm1: Record:
kernel: pcm1:      Stream cap: 0x00000001 PCM
kernel: pcm1:         PCM cap: 0x000e0560 16 20 24 bits, 44 48 96 192 KHz
kernel: pcm1:             ADC: 8
kernel: pcm1:             ADC: 9
kernel: pcm1: 
kernel: pcm1:     nid=8 [audio input]
kernel: pcm1:       + <- nid=35 [audio mixer] [src: speaker, mic, mix, monitor]
kernel: pcm1:              + <- nid=25 [pin: Mic (Black Jack)] [src: mic]
kernel: pcm1:              + <- nid=26 [pin: Mic (Fixed)] [src: monitor]
kernel: pcm1:              + <- nid=29 [beep widget] [src: speaker]
kernel: pcm1:              + <- nid=11 [audio mixer] [src: mix]
kernel: pcm1: 
kernel: pcm1:     nid=9 [audio input]
kernel: pcm1:       + <- nid=34 [audio mixer] [src: speaker, mic, mix, monitor]
kernel: pcm1:              + <- nid=25 [pin: Mic (Black Jack)] [src: mic]
kernel: pcm1:              + <- nid=26 [pin: Mic (Fixed)] [src: monitor]
kernel: pcm1:              + <- nid=29 [beep widget] [src: speaker]
kernel: pcm1:              + <- nid=11 [audio mixer] [src: mix]
kernel: pcm1: 
kernel: pcm1: Input Mix:
kernel: pcm1: 
kernel: pcm1:     nid=11 [audio mixer]
kernel: pcm1:       + <- nid=25 [pin: Mic (Black Jack)] [src: mic]
kernel: pcm1:       + <- nid=26 [pin: Mic (Fixed)] [src: monitor]
kernel: pcm1:       + <- nid=29 [beep widget] [src: speaker]
kernel: pcm1: 
kernel: pcm1: Master Volume (OSS: vol): -65/0dB
kernel: pcm1:    +- ctl  1 (nid   2 out):    -65/0dB (88 steps)
kernel: pcm1:    +- ctl 10 (nid  12 in   0): mute
kernel: pcm1:    +- ctl 11 (nid  12 in   1): mute
kernel: pcm1:    +- ctl 17 (nid  20 in ):    mute
kernel: pcm1:    +- ctl 24 (nid  33 in ):    mute
kernel: pcm1: 
kernel: pcm1: PCM Volume (OSS: pcm): -65/0dB
kernel: pcm1:    +- ctl  1 (nid   2 out):    -65/0dB (88 steps)
kernel: pcm1:    +- ctl 10 (nid  12 in   0): mute
kernel: pcm1: 
kernel: pcm1: Microphone Volume (OSS: mic): 0/36dB
kernel: pcm1:    +- ctl  6 (nid  11 in   1): -34/12dB (32 steps) + mute
kernel: pcm1:    +- ctl 20 (nid  25 out):    0/36dB (4 steps)
kernel: pcm1:    +- ctl 26 (nid  34 in   1): mute
kernel: pcm1:    +- ctl 32 (nid  35 in   1): mute
kernel: pcm1: 
kernel: pcm1: Microphone2 Volume (OSS: monitor): 0/36dB
kernel: pcm1:    +- ctl  7 (nid  11 in   2): -34/12dB (32 steps) + mute
kernel: pcm1:    +- ctl 21 (nid  26 out):    0/36dB (4 steps)
kernel: pcm1:    +- ctl 27 (nid  34 in   2): mute
kernel: pcm1:    +- ctl 33 (nid  35 in   2): mute
kernel: pcm1: 
kernel: pcm1: Speaker/Beep Volume (OSS: speaker): -34/12dB
kernel: pcm1:    +- ctl  9 (nid  11 in   4): -34/12dB (32 steps) + mute
kernel: pcm1:    +- ctl 29 (nid  34 in   4): mute
kernel: pcm1:    +- ctl 35 (nid  35 in   4): mute
kernel: pcm1: 
kernel: pcm1: Recording Level (OSS: rec): -17/30dB
kernel: pcm1:    +- ctl  3 (nid   8 in   0): -17/30dB (64 steps) + mute
kernel: pcm1:    +- ctl  4 (nid   9 in   0): -17/30dB (64 steps) + mute
kernel: pcm1:    +- ctl 26 (nid  34 in   1): mute
kernel: pcm1:    +- ctl 27 (nid  34 in   2): mute
kernel: pcm1:    +- ctl 29 (nid  34 in   4): mute
kernel: pcm1:    +- ctl 30 (nid  34 in   5): mute
kernel: pcm1:    +- ctl 32 (nid  35 in   1): mute
kernel: pcm1:    +- ctl 33 (nid  35 in   2): mute
kernel: pcm1:    +- ctl 35 (nid  35 in   4): mute
kernel: pcm1:    +- ctl 36 (nid  35 in   5): mute
kernel: pcm1: 
kernel: pcm1: Input Mix Level (OSS: mix): -34/12dB
kernel: pcm1:    +- ctl  6 (nid  11 in   1): -34/12dB (32 steps) + mute
kernel: pcm1:    +- ctl  7 (nid  11 in   2): -34/12dB (32 steps) + mute
kernel: pcm1:    +- ctl  9 (nid  11 in   4): -34/12dB (32 steps) + mute
kernel: pcm1:    +- ctl 11 (nid  12 in   1): mute
kernel: pcm1:    +- ctl 30 (nid  34 in   5): mute
kernel: pcm1:    +- ctl 36 (nid  35 in   5): mute
kernel: pcm1: 
kernel: pcm1: Input Monitoring Level (OSS: igain): 0/0dB
kernel: pcm1:    +- ctl 11 (nid  12 in   1): mute
kernel: pcm1: 
kernel: pcm1: Mixer "vol":
kernel: pcm1: Mixer "pcm":
kernel: pcm1: Mixer "speaker":
kernel: pcm1: Mixer "mic":
kernel: pcm1: Mixer "mix":
kernel: pcm1: Mixer "rec":
kernel: pcm1: Mixer "igain":
kernel: pcm1: Mixer "ogain":
kernel: pcm1: Mixer "monitor":
kernel: pcm1: Playback channel set is: Front Left, Front Right, 
kernel: pcm1: Playback channel matrix is: 2.0 (unknown)
kernel: pcm1: Automatically set rec source to: monitor
kernel: pcm1: Recording channel set is: Front Left, Front Right, 
kernel: pcm1: Recording channel matrix is: 2.0 (unknown)
-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
_______________________________________________
freebsd-current at freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"

----- End forwarded message -----

-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
??? ????? ??? ??????, ??? ?????? ??? ?????????? (??a????? ????? ?????)
Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) 
Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin)

From jmg at funkthat.com  Thu Dec 10 20:02:53 2020
From: jmg at funkthat.com (John-Mark Gurney)
Date: Thu, 10 Dec 2020 12:02:50 -0800
Subject: AMNESIA:33 and FreeBSD TCP/IP stack involvement
In-Reply-To: <20201209065849.47a51561@hermann.fritz.box>
References: <20201209065849.47a51561@hermann.fritz.box>
Message-ID: <20201210200250.GJ31099@funkthat.com>

Hartmann, O. wrote this message on Wed, Dec 09, 2020 at 06:58 +0100:
> I've got a question about recently discovered serious vulnerabilities
> in certain TCP stack implementations, designated as AMNESIA:33 (as far
> as I could follow the recently made announcements and statements,
> please see, for instance,
> https://www.zdnet.com/article/amnesia33-vulnerabilities-impact-millions-of-smart-and-industrial-devices/).
> 
> All mentioned open-source TCP stacks seem not to be related in any way
> with freeBSD or any derivative of the FreeBSD project, but I do not
> dare to make a statement about that.
> 
> My question is very simple and aimes towards calming down my employees
> requests: is FreeBSD potentially vulnerable to this newly discovered
> flaw (we use mainly 12.1-RELENG, 12.2-RELENG, 12-STABLE and 13-CURRENT,
> latest incarnations, of course, should be least vulnerable ...).

I'd be surprised if FreeBSD is vulnerable to those flaws, but I cannot
make any official statement as there are too many to even start to
investigate them.

Also of note is that there were three other IP stacks that were NOT
vulnerable to ANY new security issues in that report as well, so it
isn't like the report found security vulnerability in every TCP/IP
stack they tested.

The best way to have confidence is to pay people to analyize and
verify that the FreeBSD TCP/IP stack is secure, just as it is w/
any critical code that a company runs.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20201210/4ee392db/attachment.sig>

From clay.daniels.jr at gmail.com  Fri Dec 11 06:36:11 2020
From: clay.daniels.jr at gmail.com (Clay Daniels)
Date: Fri, 11 Dec 2020 00:35:57 -0600
Subject: Weekly 13.0 snapshot works Great!
Message-ID: <CAGLDxTUNiqX4=0gSY4ve72h=04DoSG+eM+d7mAZLgvkDoWFeQg@mail.gmail.com>

Weekly snapshot works Great!

clay at fbsd:~ $ uname -a
FreeBSD fbsd 13.0-CURRENT FreeBSD 13.0-CURRENT #0
7578a4862f0-c255032(main): Thu Dec 10 11:40:27 UTC 2020
root at releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64

Dmesg attached
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Dmesg
Type: application/octet-stream
Size: 82584 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20201211/9b170f02/attachment-0001.obj>

From guru at unixarea.de  Fri Dec 11 07:06:33 2020
From: guru at unixarea.de (Matthias Apitz)
Date: Fri, 11 Dec 2020 08:06:27 +0100
Subject: after update to r368166: no sound recording
In-Reply-To: <4d83e630-7bed-16bd-3422-267813d3e842@selasky.org>
References: <X9CchZFla3RMFd/3@c720-r368166.fritz.box>
 <72bd5240-3092-bf7b-51aa-2ad12a576efb@selasky.org>
 <X9Crmcsce57g0PER@c720-r368166.fritz.box>
 <4d83e630-7bed-16bd-3422-267813d3e842@selasky.org>
Message-ID: <X9Mac12Z3u2ZpMOy@c720-r368166.fritz.box>

El d?a mi?rcoles, diciembre 09, 2020 a las 11:55:18a. m. +0100, Hans Petter Selasky escribi?:

> On 12/9/20 11:48 AM, Matthias Apitz wrote:
> > El d?a mi?rcoles, diciembre 09, 2020 a las 11:05:09a. m. +0100, Hans Petter Selasky escribi?:
> > 
> > > On 12/9/20 10:44 AM, Matthias Apitz wrote:
> > > > 
> > > > Hello,
> > > > 
> > > > I've updated a laptop Acer C720 from r342378 to r368166 and do not have
> > > > any sound incoming anymore. I rebooted r342378 from an USB stick and the
> > > > old kernel produces already noise in the speakers when I touch the
> > > > micro hole in the keyboard, the new kernel does not produce any noise
> > > > there. Both system have the same /boot/device.hints values:
> > > > 
> > > > ....

Hello,

I reverted the kernel source in the directory sys/dev/sound/pci/hda to r342378:

$ cd /usr/src/sys/dev/sound/pci
$ svn info hda
Path: hda
Working Copy Root Path: /usr/src
URL: svn://svn.freebsd.org/base/head/sys/dev/sound/pci/hda
Relative URL: ^/head/sys/dev/sound/pci/hda
Repository Root: svn://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 342378
Node Kind: directory
Schedule: normal
Last Changed Author: mav
Last Changed Rev: 340071
Last Changed Date: 2018-11-02 18:02:10 +0100 (Fri, 02 Nov 2018)

compiled and installed the kernel:

$ uname -a
FreeBSD c720-r368166 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r342378:368166M: Fri Dec 11 07:46:32 CET 2020     guru at c720-r368166:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64

and all is fine again as it was before. Someone with more knowledge should
have a look into a 'svn diff -r342378:368166 sys/dev/sound/pci/hda' and
see which of the changes might break the things. 

Thanks

	matthias


-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
??? ????? ??? ??????, ??? ?????? ??? ?????????? (??a????? ????? ?????)
Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) 
Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin)

From jbtakk at iherebuywisely.com  Fri Dec 11 14:12:46 2020
From: jbtakk at iherebuywisely.com (Jeffrey Bouquet)
Date: Fri, 11 Dec 2020 06:12:42 -0800 (PST)
Subject: Updating current i386 broke wlan0...
Message-ID: <E1knjA2-0005Hn-5u@rmmprod07.runbox>

Longtime BSD current user, due to several constraints I had to update from a recent dec 10 image in
a quasi-piecemeal fashion.  Fixed all issues  [ I think ] From 11-Current to 13-Current except 
  service netif onestart wlan0 up
no longer completes. 
....................................
/etc/rc.d/netif set_rcvar_obsolete: not found
eval: wlan_up: not found
starting wpa_supplicant
/etc/rc.d/wpa_supplicant: WARNING:  failed to start...
starting dhclient
eval: wlan0: not found
/etc/rc.d/dhclient: WARNING: failed to start dhclient
/etc/rc.d/netif:  WARNING: $ipv6_enable is not set properly, see rc.conf(5)
starting network wlan0
eval: check_startmsgs: not found
eval: afexits: not found
..........................................................................................
Piecemeal update was needed because make toolchain and make buildworld
failed each early on.
.............................................................................................
I have the freebsd-manifest base.* etc files but am hesitant to overwrite system files
rendering the i386 system less usable than now, as well as unschooled in the
syntax for same.
...............................................................................................
Hoping that just a few files into /etc I may not have thought of can fix
wpa_supplicant...
...................................................................................................
other dmesg errors:  [rc.d...] 
list_vars: not found
sort_list: not found
check_kern_features: not found
set_rcvar_obsolete: not found
.....................................................................................................
Any insights appreciated. 


Jeff 

From jakob at alvermark.net  Fri Dec 11 14:50:48 2020
From: jakob at alvermark.net (Jakob Alvermark)
Date: Fri, 11 Dec 2020 15:50:37 +0100
Subject: after update to r368166: no sound recording
In-Reply-To: <X9Mac12Z3u2ZpMOy@c720-r368166.fritz.box>
References: <X9CchZFla3RMFd/3@c720-r368166.fritz.box>
 <72bd5240-3092-bf7b-51aa-2ad12a576efb@selasky.org>
 <X9Crmcsce57g0PER@c720-r368166.fritz.box>
 <4d83e630-7bed-16bd-3422-267813d3e842@selasky.org>
 <X9Mac12Z3u2ZpMOy@c720-r368166.fritz.box>
Message-ID: <888e9843-46e5-cfbe-6e85-1243e0f6181b@alvermark.net>


On 12/11/20 8:06 AM, Matthias Apitz wrote:
> El d?a mi?rcoles, diciembre 09, 2020 a las 11:55:18a. m. +0100, Hans Petter Selasky escribi?:
>
>> On 12/9/20 11:48 AM, Matthias Apitz wrote:
>>> El d?a mi?rcoles, diciembre 09, 2020 a las 11:05:09a. m. +0100, Hans Petter Selasky escribi?:
>>>
>>>> On 12/9/20 10:44 AM, Matthias Apitz wrote:
>>>>> Hello,
>>>>>
>>>>> I've updated a laptop Acer C720 from r342378 to r368166 and do not have
>>>>> any sound incoming anymore. I rebooted r342378 from an USB stick and the
>>>>> old kernel produces already noise in the speakers when I touch the
>>>>> micro hole in the keyboard, the new kernel does not produce any noise
>>>>> there. Both system have the same /boot/device.hints values:
>>>>>
>>>>> ....
> Hello,
>
> I reverted the kernel source in the directory sys/dev/sound/pci/hda to r342378:
>
> $ cd /usr/src/sys/dev/sound/pci
> $ svn info hda
> Path: hda
> Working Copy Root Path: /usr/src
> URL: svn://svn.freebsd.org/base/head/sys/dev/sound/pci/hda
> Relative URL: ^/head/sys/dev/sound/pci/hda
> Repository Root: svn://svn.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 342378
> Node Kind: directory
> Schedule: normal
> Last Changed Author: mav
> Last Changed Rev: 340071
> Last Changed Date: 2018-11-02 18:02:10 +0100 (Fri, 02 Nov 2018)
>
> compiled and installed the kernel:
>
> $ uname -a
> FreeBSD c720-r368166 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r342378:368166M: Fri Dec 11 07:46:32 CET 2020     guru at c720-r368166:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
>
> and all is fine again as it was before. Someone with more knowledge should
> have a look into a 'svn diff -r342378:368166 sys/dev/sound/pci/hda' and
> see which of the changes might break the things.
>
> Thanks
>
> 	matthias
>
>

Have you tried "hint.hdaa.1.init_clear=0" in /boot/loader.conf


Jakob


From freebsd at grem.de  Fri Dec 11 15:27:05 2020
From: freebsd at grem.de (Michael Gmelin)
Date: Fri, 11 Dec 2020 16:26:51 +0100
Subject: after update to r368166: no sound recording
In-Reply-To: <888e9843-46e5-cfbe-6e85-1243e0f6181b@alvermark.net>
References: <888e9843-46e5-cfbe-6e85-1243e0f6181b@alvermark.net>
Message-ID: <4A633A6F-6D34-4BCB-BE91-0769350225FB@grem.de>



> On 11. Dec 2020, at 15:51, Jakob Alvermark <jakob at alvermark.net> wrote:
> 
> ?
>> On 12/11/20 8:06 AM, Matthias Apitz wrote:
>>> El d?a mi?rcoles, diciembre 09, 2020 a las 11:55:18a. m. +0100, Hans Petter Selasky escribi?:
>>> 
>>> On 12/9/20 11:48 AM, Matthias Apitz wrote:
>>>> El d?a mi?rcoles, diciembre 09, 2020 a las 11:05:09a. m. +0100, Hans Petter Selasky escribi?:
>>>> 
>>>>> On 12/9/20 10:44 AM, Matthias Apitz wrote:
>>>>>> Hello,
>>>>>> 
>>>>>> I've updated a laptop Acer C720 from r342378 to r368166 and do not have
>>>>>> any sound incoming anymore. I rebooted r342378 from an USB stick and the
>>>>>> old kernel produces already noise in the speakers when I touch the
>>>>>> micro hole in the keyboard, the new kernel does not produce any noise
>>>>>> there. Both system have the same /boot/device.hints values:
>>>>>> 
>>>>>> ....
>> Hello,
>> 
>> I reverted the kernel source in the directory sys/dev/sound/pci/hda to r342378:
>> 
>> $ cd /usr/src/sys/dev/sound/pci
>> $ svn info hda
>> Path: hda
>> Working Copy Root Path: /usr/src
>> URL: svn://svn.freebsd.org/base/head/sys/dev/sound/pci/hda
>> Relative URL: ^/head/sys/dev/sound/pci/hda
>> Repository Root: svn://svn.freebsd.org/base
>> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
>> Revision: 342378
>> Node Kind: directory
>> Schedule: normal
>> Last Changed Author: mav
>> Last Changed Rev: 340071
>> Last Changed Date: 2018-11-02 18:02:10 +0100 (Fri, 02 Nov 2018)
>> 
>> compiled and installed the kernel:
>> 
>> $ uname -a
>> FreeBSD c720-r368166 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r342378:368166M: Fri Dec 11 07:46:32 CET 2020     guru at c720-r368166:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
>> 
>> and all is fine again as it was before. Someone with more knowledge should
>> have a look into a 'svn diff -r342378:368166 sys/dev/sound/pci/hda' and
>> see which of the changes might break the things.
>> 
>> Thanks
>> 
>>    matthias
>> 
>> 
> 
> Have you tried "hint.hdaa.1.init_clear=0" in /boot/loader.conf
> 

I updated my c720 to the same revision and could reproduce the problem. I didn?t have much time to look into it though. I played with a couple of settings (including this one), but it didn?t make a difference.

-m

> 
> Jakob
> 
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"


From sgk at troutmask.apl.washington.edu  Fri Dec 11 16:10:45 2020
From: sgk at troutmask.apl.washington.edu (Steve Kargl)
Date: Fri, 11 Dec 2020 08:10:37 -0800
Subject: Updating current i386 broke wlan0...
In-Reply-To: <E1knjA2-0005Hn-5u@rmmprod07.runbox>
References: <E1knjA2-0005Hn-5u@rmmprod07.runbox>
Message-ID: <20201211161037.GA57823@troutmask.apl.washington.edu>

On Fri, Dec 11, 2020 at 06:12:42AM -0800, Jeffrey Bouquet wrote:
> Longtime BSD current user, due to several constraints I had to update from a recent dec 10 image in
> a quasi-piecemeal fashion.  Fixed all issues  [ I think ] From 11-Current to 13-Current except 
>   service netif onestart wlan0 up
> no longer completes. 
> ....................................
> /etc/rc.d/netif set_rcvar_obsolete: not found
> eval: wlan_up: not found
> starting wpa_supplicant
> /etc/rc.d/wpa_supplicant: WARNING:  failed to start...
> starting dhclient
> eval: wlan0: not found
> /etc/rc.d/dhclient: WARNING: failed to start dhclient
> /etc/rc.d/netif:  WARNING: $ipv6_enable is not set properly, see rc.conf(5)
> starting network wlan0
> eval: check_startmsgs: not found
> eval: afexits: not found
> ..........................................................................................
> Piecemeal update was needed because make toolchain and make buildworld
> failed each early on.

I have a Dec 2 i386-*-freebsd (typing on it now), which uses wlan0
over a lowly D-Link DWL-G630.  Works fine.  The change causing
you problems appears to have occurred after Dec 2.

-- 
Steve

From warlock at phouka.net  Fri Dec 11 16:14:16 2020
From: warlock at phouka.net (John Kennedy)
Date: Fri, 11 Dec 2020 08:12:51 -0800
Subject: AMNESIA:33 and FreeBSD TCP/IP stack involvement
In-Reply-To: <20201209065849.47a51561@hermann.fritz.box>
References: <20201209065849.47a51561@hermann.fritz.box>
Message-ID: <X9Oag/m2phpmnf/1@phouka1.phouka.net>

On Wed, Dec 09, 2020 at 06:58:49AM +0100, Hartmann, O. wrote:
> Hello,
> I've got a question about recently discovered serious vulnerabilities
> in certain TCP stack implementations, designated as AMNESIA:33 (as far
> as I could follow the recently made announcements and statements,
> please see, for instance,
> https://www.zdnet.com/article/amnesia33-vulnerabilities-impact-millions-of-smart-and-industrial-devices/).
> 
> All mentioned open-source TCP stacks seem not to be related in any way
> with freeBSD or any derivative of the FreeBSD project, but I do not
> dare to make a statement about that.
> 
> My question is very simple and aimes towards calming down my employees
> requests: is FreeBSD potentially vulnerable to this newly discovered
> flaw (we use mainly 12.1-RELENG, 12.2-RELENG, 12-STABLE and 13-CURRENT,
> latest incarnations, of course, should be least vulnerable ...).

Look at it this way:  If it is/was, what are you going to do about it?

[Please don't take this as a personal attack.  I get the same kind of
questions you are by my bosses and auditors, who live in their own little
world where they think there is a guarantee for everything and the only
real-world cost is an appropriately asked question.]

If you've got an upgrade policy that rolls out patches when FreeBSD publishes
them (or tracking -STABLE or -CURRENT in such a way that they're going to be
incorporated with some parity with the security and errata notifications) and
you're keeping your packages up to date, you're doing pretty good.  If there
is a problem, you'll roll out the fixes when they're available.  You may
not even know they're in there yet.

If you've got a menagerie of FreeBSD-based IoT-style devices that aren't
getting regular updates and this bug has shown you the tip of the iceberg
to all the other potential problems, then you probably have issues.  Now
an attack against the kernel TCP/IP stack is universally bad (possibly
bypassing any firewall, probably not requiring authentication, probably
gaining the kernel privileges, etc), plenty of other problems are a subset
of just as bad.

Assuming that the Amnesia:33 reported responsibly disclosed, if FreeBSD was
affected we'd probably have fixes out (pre-publication).  On 12/8, you just
got patch released for FreeBSD-SA-20:33.openssl, and that is burned into a
lot of OS pieces.  Have you pushed those changes out yet?  Two paragraphs up,
I basically asked a policy question.  This paragraph, I'm basically asking
you an implementation question:  You had a policy, did it work?  Did
anything get missed?  Can someone audit that?

-CURRENT and -STABLE tend to get patches (and, potentially, problems) before
-RELENG does, but sometime that's a natural process of the patches discovering
the problems that need put into -RELENG.  It's always nice to see a bug report
for -RELENG and then tracking down the revision and finding out you've been
patched for a while now.  On the other hand, -STABLE gets daily patches and
you probably wouldn't want to have a production patch cycles with that kind
of frequently.

[Personally, I tend to update -STABLE/-CURRENT when I see a "Security:" tag
with a CVE reference, semi-weekly, or when I see something that looks
alarming or interesting and -RELENG when it gets a patch.]


From jbtakk at iherebuywisely.com  Fri Dec 11 16:38:23 2020
From: jbtakk at iherebuywisely.com (Jeffrey Bouquet)
Date: Fri, 11 Dec 2020 08:38:12 -0800 (PST)
Subject: Updating current i386 broke wlan0...
In-Reply-To: <20201211161037.GA57823@troutmask.apl.washington.edu>
Message-ID: <E1knlQq-0002kk-LS@rmmprod07.runbox>



On Fri, 11 Dec 2020 08:10:37 -0800, Steve Kargl <sgk at troutmask.apl.washington.edu> wrote:

> On Fri, Dec 11, 2020 at 06:12:42AM -0800, Jeffrey Bouquet wrote:
> > Longtime BSD current user, due to several constraints I had to update from a recent dec 10 image in
> > a quasi-piecemeal fashion.  Fixed all issues  [ I think ] From 11-Current to 13-Current except 
> >   service netif onestart wlan0 up
> > no longer completes. 
> > ....................................
> > /etc/rc.d/netif set_rcvar_obsolete: not found
> > eval: wlan_up: not found
> > starting wpa_supplicant
> > /etc/rc.d/wpa_supplicant: WARNING:  failed to start...
> > starting dhclient
> > eval: wlan0: not found
> > /etc/rc.d/dhclient: WARNING: failed to start dhclient
> > /etc/rc.d/netif:  WARNING: $ipv6_enable is not set properly, see rc.conf(5)
> > starting network wlan0
> > eval: check_startmsgs: not found
> > eval: afexits: not found
> > ..........................................................................................
> > Piecemeal update was needed because make toolchain and make buildworld
> > failed each early on.
> 
> I have a Dec 2 i386-*-freebsd (typing on it now), which uses wlan0
> over a lowly D-Link DWL-G630.  Works fine.  The change causing
> you problems appears to have occurred after Dec 2.
> 
> -- 
> Steve


Maybe, if new code was in wlan0 or *rc* 
or wpa_supplicant or /etc or run0, but I suspect it is some problem I
caused by not doing a proper upgrade. 

From bzeeb-lists at lists.zabbadoz.net  Fri Dec 11 16:46:34 2020
From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb)
Date: Fri, 11 Dec 2020 16:46:20 +0000
Subject: Updating current i386 broke rc* [not wlan0]...
In-Reply-To: <E1knjA2-0005Hn-5u@rmmprod07.runbox>
References: <E1knjA2-0005Hn-5u@rmmprod07.runbox>
Message-ID: <E3BC7BE2-1AA5-43CA-B72B-15DE5D1C30FD@lists.zabbadoz.net>

On 11 Dec 2020, at 14:12, Jeffrey Bouquet wrote:

> Longtime BSD current user, due to several constraints I had to update 
> from a recent dec 10 image in
> a quasi-piecemeal fashion.  Fixed all issues  [ I think ] From 
> 11-Current to 13-Current except

It seems you didn?t prorperly merge /etc;  are you using source 
updates or how did you do that?
If you did use src, then an etcupdate or mergemaster run might fix 
things.

It seems at least /etc/network.subr isn?t there/updated? There is 
probably more...


>   service netif onestart wlan0 up
> no longer completes.
> ....................................
> /etc/rc.d/netif set_rcvar_obsolete: not found
> eval: wlan_up: not found
> starting wpa_supplicant
> /etc/rc.d/wpa_supplicant: WARNING:  failed to start...
> starting dhclient
> eval: wlan0: not found
> /etc/rc.d/dhclient: WARNING: failed to start dhclient
> /etc/rc.d/netif:  WARNING: $ipv6_enable is not set properly, see 
> rc.conf(5)
> starting network wlan0
> eval: check_startmsgs: not found
> eval: afexits: not found
> ..........................................................................................
> Piecemeal update was needed because make toolchain and make buildworld
> failed each early on.
> .............................................................................................
> I have the freebsd-manifest base.* etc files but am hesitant to 
> overwrite system files
> rendering the i386 system less usable than now, as well as unschooled 
> in the
> syntax for same.
> ...............................................................................................
> Hoping that just a few files into /etc I may not have thought of can 
> fix
> wpa_supplicant...
> ...................................................................................................
> other dmesg errors:  [rc.d...]
> list_vars: not found
> sort_list: not found
> check_kern_features: not found
> set_rcvar_obsolete: not found
> .....................................................................................................
> Any insights appreciated.
>
>
> Jeff
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to 
> "freebsd-current-unsubscribe at freebsd.org"

From imp at bsdimp.com  Fri Dec 11 16:51:15 2020
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 11 Dec 2020 09:51:03 -0700
Subject: Updating current i386 broke rc* [not wlan0]...
In-Reply-To: <E3BC7BE2-1AA5-43CA-B72B-15DE5D1C30FD@lists.zabbadoz.net>
References: <E1knjA2-0005Hn-5u@rmmprod07.runbox>
 <E3BC7BE2-1AA5-43CA-B72B-15DE5D1C30FD@lists.zabbadoz.net>
Message-ID: <CANCZdfpMcn7thVu=rKUfCtBQgqKmySMCcSzNXHeec2D1yute-Q@mail.gmail.com>

On Fri, Dec 11, 2020 at 9:46 AM Bjoern A. Zeeb <
bzeeb-lists at lists.zabbadoz.net> wrote:

> On 11 Dec 2020, at 14:12, Jeffrey Bouquet wrote:
>
> > Longtime BSD current user, due to several constraints I had to update
> > from a recent dec 10 image in
> > a quasi-piecemeal fashion.  Fixed all issues  [ I think ] From
> > 11-Current to 13-Current except
>
> It seems you didn?t prorperly merge /etc;  are you using source
> updates or how did you do that?
> If you did use src, then an etcupdate or mergemaster run might fix
> things.
>
> It seems at least /etc/network.subr isn?t there/updated? There is
> probably more...
>

I'm not saying there's not a kernel issue, but I'm with bjoern here. The
last maybe half dozen times that wifi broke for me, dating back a decade,
every single one of them has been failure to update /etc/rc files properly
and/or failure to update both userland and kernel and/or corrupting
wpa_supplicant.conf... Given the errors reported, I'd make sure there's a
complete update of /etc files before looking elsewhere.

Warner


> >   service netif onestart wlan0 up
> > no longer completes.
> > ....................................
> > /etc/rc.d/netif set_rcvar_obsolete: not found
> > eval: wlan_up: not found
> > starting wpa_supplicant
> > /etc/rc.d/wpa_supplicant: WARNING:  failed to start...
> > starting dhclient
> > eval: wlan0: not found
> > /etc/rc.d/dhclient: WARNING: failed to start dhclient
> > /etc/rc.d/netif:  WARNING: $ipv6_enable is not set properly, see
> > rc.conf(5)
> > starting network wlan0
> > eval: check_startmsgs: not found
> > eval: afexits: not found
> >
> ..........................................................................................
> > Piecemeal update was needed because make toolchain and make buildworld
> > failed each early on.
> >
> .............................................................................................
> > I have the freebsd-manifest base.* etc files but am hesitant to
> > overwrite system files
> > rendering the i386 system less usable than now, as well as unschooled
> > in the
> > syntax for same.
> >
> ...............................................................................................
> > Hoping that just a few files into /etc I may not have thought of can
> > fix
> > wpa_supplicant...
> >
> ...................................................................................................
> > other dmesg errors:  [rc.d...]
> > list_vars: not found
> > sort_list: not found
> > check_kern_features: not found
> > set_rcvar_obsolete: not found
> >
> .....................................................................................................
> > Any insights appreciated.
> >
> >
> > Jeff
> > _______________________________________________
> > freebsd-current at freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to
> > "freebsd-current-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>

From ludovit.koren at gmail.com  Fri Dec 11 18:26:29 2020
From: ludovit.koren at gmail.com (Ludovit Koren)
Date: Fri, 11 Dec 2020 19:26:22 +0100
Subject: HP Elitebook 830 G7
Message-ID: <86360c9p2p.fsf@gmail.com>


Hi,

I am trying to install FreeBSD-12.2-RELEASE,
FreeBSD-13.0-CURRENT-amd64-20201203-f659bf1d31c

The image starts booting and it hangs in:

....
Loading kernel...
/boot/kernel/kernel text=0x16bdcc4 data 0x140 data 0x75fe80 ....
Loading configured modules...
can't find '/etc/hostid'
can't find '/boot/entropy'
Start @ 0xffffffff80373000 ...
EFI framebuffer information:
addr, size      0xa0000000, 0x7e9000
dimensions      1920 x 1080
stride          1920
masks           0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
_



Any hints greatly appreciated.

Regards,

lk

From bsd-lists at bsdforge.com  Fri Dec 11 18:32:46 2020
From: bsd-lists at bsdforge.com (Chris)
Date: Fri, 11 Dec 2020 10:32:39 -0800
Subject: Updating current i386 broke wlan0...
In-Reply-To: <20201211161037.GA57823@troutmask.apl.washington.edu>
References: <E1knjA2-0005Hn-5u@rmmprod07.runbox>
 <20201211161037.GA57823@troutmask.apl.washington.edu>
Message-ID: <2038a586d1e6da5ce895df48f98f2427@bsdforge.com>

On 2020-12-11 08:10, Steve Kargl wrote:
> On Fri, Dec 11, 2020 at 06:12:42AM -0800, Jeffrey Bouquet wrote:
>> Longtime BSD current user, due to several constraints I had to update from 
>> a recent dec 10 image in
>> a quasi-piecemeal fashion.  Fixed all issues  [ I think ] From 11-Current 
>> to 13-Current except
>>   service netif onestart wlan0 up
>> no longer completes.
>> ....................................
>> /etc/rc.d/netif set_rcvar_obsolete: not found
>> eval: wlan_up: not found
>> starting wpa_supplicant
>> /etc/rc.d/wpa_supplicant: WARNING:  failed to start...
>> starting dhclient
>> eval: wlan0: not found
>> /etc/rc.d/dhclient: WARNING: failed to start dhclient
>> /etc/rc.d/netif:  WARNING: $ipv6_enable is not set properly, see rc.conf(5)
>> starting network wlan0
>> eval: check_startmsgs: not found
>> eval: afexits: not found
>> ..........................................................................................
>> Piecemeal update was needed because make toolchain and make buildworld
>> failed each early on.
> 
> I have a Dec 2 i386-*-freebsd (typing on it now), which uses wlan0
> over a lowly D-Link DWL-G630.  Works fine.  The change causing
> you problems appears to have occurred after Dec 2.

mergemaster appears to have not been done (I know. You said quasi-piecemeal). 
Fair
enough. Assuming you have both your /etc && (proposed 13) /etc;
perhaps a diff -ruN /your-etc /13-etc >./new-stuff.diff
will help you discover what function names were changed/moved/deleted. As 
well
as what services were altered/added/deleted

--Chris

From bsd-lists at bsdforge.com  Fri Dec 11 18:54:01 2020
From: bsd-lists at bsdforge.com (Chris)
Date: Fri, 11 Dec 2020 10:53:55 -0800
Subject: Updating current i386 broke wlan0...
In-Reply-To: <2038a586d1e6da5ce895df48f98f2427@bsdforge.com>
References: <E1knjA2-0005Hn-5u@rmmprod07.runbox>
 <20201211161037.GA57823@troutmask.apl.washington.edu>
 <2038a586d1e6da5ce895df48f98f2427@bsdforge.com>
Message-ID: <f2d77e03c6d73547eeaa32509cfe1d71@bsdforge.com>

On 2020-12-11 10:32, Chris wrote:
> On 2020-12-11 08:10, Steve Kargl wrote:
>> On Fri, Dec 11, 2020 at 06:12:42AM -0800, Jeffrey Bouquet wrote:
>>> Longtime BSD current user, due to several constraints I had to update from 
>>> a recent dec 10 image in
>>> a quasi-piecemeal fashion.  Fixed all issues  [ I think ] From 11-Current 
>>> to 13-Current except
>>>   service netif onestart wlan0 up
>>> no longer completes.
>>> ....................................
>>> /etc/rc.d/netif set_rcvar_obsolete: not found
>>> eval: wlan_up: not found
>>> starting wpa_supplicant
>>> /etc/rc.d/wpa_supplicant: WARNING:  failed to start...
>>> starting dhclient
>>> eval: wlan0: not found
>>> /etc/rc.d/dhclient: WARNING: failed to start dhclient
>>> /etc/rc.d/netif:  WARNING: $ipv6_enable is not set properly, see 
>>> rc.conf(5)
>>> starting network wlan0
>>> eval: check_startmsgs: not found
>>> eval: afexits: not found
>>> ..........................................................................................
>>> Piecemeal update was needed because make toolchain and make buildworld
>>> failed each early on.
>> 
>> I have a Dec 2 i386-*-freebsd (typing on it now), which uses wlan0
>> over a lowly D-Link DWL-G630.  Works fine.  The change causing
>> you problems appears to have occurred after Dec 2.
> 
> mergemaster appears to have not been done (I know. You said 
> quasi-piecemeal). Fair
> enough. Assuming you have both your /etc && (proposed 13) /etc;
> perhaps a diff -ruN /your-etc /13-etc >./new-stuff.diff
> will help you discover what function names were changed/moved/deleted. As 
> well
> as what services were altered/added/deleted
Actually. As I think about it. Adding a p to the diff(1) line above may make 
it
easier to visually determine the differences eg;

$ diff -rupN orig-etc/ 13-etc/

> 
> --Chris

From jbtakk at iherebuywisely.com  Fri Dec 11 21:07:28 2020
From: jbtakk at iherebuywisely.com (Jeffrey Bouquet)
Date: Fri, 11 Dec 2020 13:07:23 -0800 (PST)
Subject: Updating current i386 broke wlan0...
In-Reply-To: <f2d77e03c6d73547eeaa32509cfe1d71@bsdforge.com>
Message-ID: <E1knpdL-0002BC-PW@rmmprod07.runbox>



On Fri, 11 Dec 2020 10:53:55 -0800, Chris <bsd-lists at bsdforge.com> wrote:

> On 2020-12-11 10:32, Chris wrote:
> > On 2020-12-11 08:10, Steve Kargl wrote:
> >> On Fri, Dec 11, 2020 at 06:12:42AM -0800, Jeffrey Bouquet wrote:
> >>> Longtime BSD current user, due to several constraints I had to update from 
> >>> a recent dec 10 image in
> >>> a quasi-piecemeal fashion.  Fixed all issues  [ I think ] From 11-Current 
> >>> to 13-Current except
> >>>   service netif onestart wlan0 up
> >>> no longer completes.
> >>> ....................................
> >>> /etc/rc.d/netif set_rcvar_obsolete: not found
> >>> eval: wlan_up: not found
> >>> starting wpa_supplicant
> >>> /etc/rc.d/wpa_supplicant: WARNING:  failed to start...
> >>> starting dhclient
> >>> eval: wlan0: not found
> >>> /etc/rc.d/dhclient: WARNING: failed to start dhclient
> >>> /etc/rc.d/netif:  WARNING: $ipv6_enable is not set properly, see 
> >>> rc.conf(5)
> >>> starting network wlan0
> >>> eval: check_startmsgs: not found
> >>> eval: afexits: not found
> >>> ..........................................................................................
> >>> Piecemeal update was needed because make toolchain and make buildworld
> >>> failed each early on.
> >> 
> >> I have a Dec 2 i386-*-freebsd (typing on it now), which uses wlan0
> >> over a lowly D-Link DWL-G630.  Works fine.  The change causing
> >> you problems appears to have occurred after Dec 2.
> > 
> > mergemaster appears to have not been done (I know. You said 
> > quasi-piecemeal). Fair
> > enough. Assuming you have both your /etc && (proposed 13) /etc;
> > perhaps a diff -ruN /your-etc /13-etc >./new-stuff.diff
> > will help you discover what function names were changed/moved/deleted. As 
> > well
> > as what services were altered/added/deleted
> Actually. As I think about it. Adding a p to the diff(1) line above may make 
> it
> easier to visually determine the differences eg;
> 
> $ diff -rupN orig-etc/ 13-etc/
> 
> > 
> > --Chris
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"

I had done a full mergemaster previously... 
It gets stranger. 
I tried etcmerge, it could not do any useful work [ no conflicts found iirc ] 
I tried etcupdate, it could neither  [ no /usr/src on the .img file filesytem  iirc ]
I found a wpa_supplicant line that creates wlan0 but run0 never gets beyond
'no carrier'
.....................................
then I started Xorg and it worked... so maybe I just forgot to copy the new kernel over, 
but then why would the newer binaries and  .ko files be working? 
....................................
Also, when trying the install of the dec 10 .img again, it failed in a second or so
.....................................
When copying several files I missed in /etc over, I accidently converted the
system to a 'live cd'... in other words, the system boots normally [ except the
run0 not starting and other error messages ] but after login I am presented
with the install menu even thought the thumbdrive is not present.  And get
a real boot completed by choosing 'live CD '
.... which is also off topic though...
...................................
So I got further along,  [ fixed Xorg ... ] but it maybe shouldn't be.   
...................................
Thanks for the suggestions.   I don't wish anyone to spend any more time on this, eventually
I may revert to  a wired interface [ if only I was certain how to connect
[ type of ethernet cable, ifconfig, route add paramaters... ] 
 to the wifi 
modem ethernet 
router ports] ... I have more research to do. 
...........................

From bsd-lists at bsdforge.com  Fri Dec 11 21:55:21 2020
From: bsd-lists at bsdforge.com (Chris)
Date: Fri, 11 Dec 2020 13:55:14 -0800
Subject: Updating current i386 broke wlan0...
In-Reply-To: <E1knpdL-0002BC-PW@rmmprod07.runbox>
References: <E1knpdL-0002BC-PW@rmmprod07.runbox>
Message-ID: <6859ff6366b746196953e3b7ab26b459@bsdforge.com>

On 2020-12-11 13:07, Jeffrey Bouquet wrote:
> On Fri, 11 Dec 2020 10:53:55 -0800, Chris <bsd-lists at bsdforge.com> wrote:
> 
>> On 2020-12-11 10:32, Chris wrote:
>> > On 2020-12-11 08:10, Steve Kargl wrote:
>> >> On Fri, Dec 11, 2020 at 06:12:42AM -0800, Jeffrey Bouquet wrote:
>> >>> Longtime BSD current user, due to several constraints I had to update from
>> >>> a recent dec 10 image in
>> >>> a quasi-piecemeal fashion.  Fixed all issues  [ I think ] From 11-Current
>> >>> to 13-Current except
>> >>>   service netif onestart wlan0 up
>> >>> no longer completes.
>> >>> ....................................
>> >>> /etc/rc.d/netif set_rcvar_obsolete: not found
>> >>> eval: wlan_up: not found
>> >>> starting wpa_supplicant
>> >>> /etc/rc.d/wpa_supplicant: WARNING:  failed to start...
>> >>> starting dhclient
>> >>> eval: wlan0: not found
>> >>> /etc/rc.d/dhclient: WARNING: failed to start dhclient
>> >>> /etc/rc.d/netif:  WARNING: $ipv6_enable is not set properly, see
>> >>> rc.conf(5)
>> >>> starting network wlan0
>> >>> eval: check_startmsgs: not found
>> >>> eval: afexits: not found
>> >>> ..........................................................................................
>> >>> Piecemeal update was needed because make toolchain and make buildworld
>> >>> failed each early on.
>> >>
>> >> I have a Dec 2 i386-*-freebsd (typing on it now), which uses wlan0
>> >> over a lowly D-Link DWL-G630.  Works fine.  The change causing
>> >> you problems appears to have occurred after Dec 2.
>> >
>> > mergemaster appears to have not been done (I know. You said
>> > quasi-piecemeal). Fair
>> > enough. Assuming you have both your /etc && (proposed 13) /etc;
>> > perhaps a diff -ruN /your-etc /13-etc >./new-stuff.diff
>> > will help you discover what function names were changed/moved/deleted. As
>> > well
>> > as what services were altered/added/deleted
>> Actually. As I think about it. Adding a p to the diff(1) line above may 
>> make
>> it
>> easier to visually determine the differences eg;
>> 
>> $ diff -rupN orig-etc/ 13-etc/
>> 
>> >
>> > --Chris
>> _______________________________________________
>> freebsd-current at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
> 
> I had done a full mergemaster previously...
> It gets stranger.
> I tried etcmerge, it could not do any useful work [ no conflicts found iirc 
> ]
> I tried etcupdate, it could neither  [ no /usr/src on the .img file 
> filesytem  iirc ]
> I found a wpa_supplicant line that creates wlan0 but run0 never gets beyond
> 'no carrier'
> .....................................
> then I started Xorg and it worked... so maybe I just forgot to copy the new 
> kernel over,
> but then why would the newer binaries and  .ko files be working?
> ....................................
> Also, when trying the install of the dec 10 .img again, it failed in a 
> second or so
> .....................................
> When copying several files I missed in /etc over, I accidently converted the
> system to a 'live cd'... in other words, the system boots normally [ except 
> the
> run0 not starting and other error messages ] but after login I am presented
> with the install menu even thought the thumbdrive is not present.  And get
> a real boot completed by choosing 'live CD '
> .... which is also off topic though...
> ...................................
> So I got further along,  [ fixed Xorg ... ] but it maybe shouldn't be.
> ...................................
> Thanks for the suggestions.   I don't wish anyone to spend any more time on 
> this, eventually
> I may revert to  a wired interface [ if only I was certain how to connect
> [ type of ethernet cable, ifconfig, route add paramaters... ]
>  to the wifi
> modem ethernet
> router ports] ... I have more research to do.
> ...........................
Well FWIW when I've been confronted with the need to perform an "unorthodox" 
upgrade
path. I always perform a
cd / && cp -rp /etc /eetc
*prior* to a mergemaster(8)
because you never know. ;-)

Sorry for your grief, and best wishes for a quick & easy resolve. :-)

--Chris

From bakul at iitbombay.org  Fri Dec 11 22:03:49 2020
From: bakul at iitbombay.org (Bakul Shah)
Date: Fri, 11 Dec 2020 14:03:44 -0800
Subject: Updating current i386 broke wlan0...
In-Reply-To: <6859ff6366b746196953e3b7ab26b459@bsdforge.com>
References: <E1knpdL-0002BC-PW@rmmprod07.runbox>
 <6859ff6366b746196953e3b7ab26b459@bsdforge.com>
Message-ID: <82C6E9BC-84B6-4CED-B4F0-A687E19702E3@iitbombay.org>

On Dec 11, 2020, at 1:55 PM, Chris <bsd-lists at BSDforge.com> wrote:
> 
> Well FWIW when I've been confronted with the need to perform an "unorthodox" upgrade
> path. I always perform a
> cd / && cp -rp /etc /eetc
> *prior* to a mergemaster(8)
> because you never know. ;-)

Just commit every *working* set of files in /etc & /usr/local/etc
to git or something :-) 


From jbtakk at iherebuywisely.com  Fri Dec 11 22:40:26 2020
From: jbtakk at iherebuywisely.com (Jeffrey Bouquet)
Date: Fri, 11 Dec 2020 14:40:22 -0800 (PST)
Subject: Updating current i386 broke wlan0...
In-Reply-To: <6859ff6366b746196953e3b7ab26b459@bsdforge.com>
Message-ID: <E1knr5K-0001P0-FP@rmmprod07.runbox>



On Fri, 11 Dec 2020 13:55:14 -0800, Chris <bsd-lists at bsdforge.com> wrote:

> On 2020-12-11 13:07, Jeffrey Bouquet wrote:
> > On Fri, 11 Dec 2020 10:53:55 -0800, Chris <bsd-lists at bsdforge.com> wrote:
> > 
> >> On 2020-12-11 10:32, Chris wrote:
> >> > On 2020-12-11 08:10, Steve Kargl wrote:
> >> >> On Fri, Dec 11, 2020 at 06:12:42AM -0800, Jeffrey Bouquet wrote:
> >> >>> Longtime BSD current user, due to several constraints I had to update from
> >> >>> a recent dec 10 image in
> >> >>> a quasi-piecemeal fashion.  Fixed all issues  [ I think ] From 11-Current
> >> >>> to 13-Current except
> >> >>>   service netif onestart wlan0 up
> >> >>> no longer completes.
> >> >>> ....................................
> >> >>> /etc/rc.d/netif set_rcvar_obsolete: not found
> >> >>> eval: wlan_up: not found
> >> >>> starting wpa_supplicant
> >> >>> /etc/rc.d/wpa_supplicant: WARNING:  failed to start...
> >> >>> starting dhclient
> >> >>> eval: wlan0: not found
> >> >>> /etc/rc.d/dhclient: WARNING: failed to start dhclient
> >> >>> /etc/rc.d/netif:  WARNING: $ipv6_enable is not set properly, see
> >> >>> rc.conf(5)
> >> >>> starting network wlan0
> >> >>> eval: check_startmsgs: not found
> >> >>> eval: afexits: not found
> >> >>> ..........................................................................................
> >> >>> Piecemeal update was needed because make toolchain and make buildworld
> >> >>> failed each early on.
> >> >>
> >> >> I have a Dec 2 i386-*-freebsd (typing on it now), which uses wlan0
> >> >> over a lowly D-Link DWL-G630.  Works fine.  The change causing
> >> >> you problems appears to have occurred after Dec 2.
> >> >
> >> > mergemaster appears to have not been done (I know. You said
> >> > quasi-piecemeal). Fair
> >> > enough. Assuming you have both your /etc && (proposed 13) /etc;
> >> > perhaps a diff -ruN /your-etc /13-etc >./new-stuff.diff
> >> > will help you discover what function names were changed/moved/deleted. As
> >> > well
> >> > as what services were altered/added/deleted
> >> Actually. As I think about it. Adding a p to the diff(1) line above may 
> >> make
> >> it
> >> easier to visually determine the differences eg;
> >> 
> >> $ diff -rupN orig-etc/ 13-etc/
> >> 
> >> >
> >> > --Chris
> >> _______________________________________________
> >> freebsd-current at freebsd.org mailing list
> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> >> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
> > 
> > I had done a full mergemaster previously...
> > It gets stranger.
> > I tried etcmerge, it could not do any useful work [ no conflicts found iirc 
> > ]
> > I tried etcupdate, it could neither  [ no /usr/src on the .img file 
> > filesytem  iirc ]
> > I found a wpa_supplicant line that creates wlan0 but run0 never gets beyond
> > 'no carrier'
> > .....................................
> > then I started Xorg and it worked... so maybe I just forgot to copy the new 
> > kernel over,
> > but then why would the newer binaries and  .ko files be working?
> > ....................................
> > Also, when trying the install of the dec 10 .img again, it failed in a 
> > second or so
> > .....................................
> > When copying several files I missed in /etc over, I accidently converted the
> > system to a 'live cd'... in other words, the system boots normally [ except 
> > the
> > run0 not starting and other error messages ] but after login I am presented
> > with the install menu even thought the thumbdrive is not present.  And get
> > a real boot completed by choosing 'live CD '
> > .... which is also off topic though...
> > ...................................
> > So I got further along,  [ fixed Xorg ... ] but it maybe shouldn't be.
> > ...................................
> > Thanks for the suggestions.   I don't wish anyone to spend any more time on 
> > this, eventually
> > I may revert to  a wired interface [ if only I was certain how to connect
> > [ type of ethernet cable, ifconfig, route add paramaters... ]
> >  to the wifi
> > modem ethernet
> > router ports] ... I have more research to do.
> > ...........................
> Well FWIW when I've been confronted with the need to perform an "unorthodox" 
> upgrade
> path. I always perform a
> cd / && cp -rp /etc /eetc
> *prior* to a mergemaster(8)
> because you never know. ;-)
> 
> Sorry for your grief, and best wishes for a quick & easy resolve. :-)
> 
> --Chris
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"


I don't know if to laugh or cry.
I copied base.* and kernel.* from /usr/freebsd-dist on the thumbdrive to /
then using a ten minute forum search results, I succeeded in
from /
gtar -xpJf base.txz
gtar -xpJf kernel.txz   [  tar failed with an error ]
and presto chango 
all I had to do was change v11 to v13 in /usr/local/etc/pkg/repos/FreeBSD.conf
and what works:
   run0 at boot
   xorg !!!  which means also the drivers.
and all the dmesg errors are gone, as well as not having to
'service netif onestart' !!!
......
For those using this as a guide, I made a backup of /etc from which
I had to, or chose to,
 restore master.password, and the three others, [ and come
to think of it have not checked  'shells' 'group' files yet. 
as well as rc.conf and wpa_supplicant.conf . and others I will remember
......................
Thanks for all the replies, they were very encouraging.  As is this end result... 
.....................

From grahamperrin at gmail.com  Sat Dec 12 03:03:10 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Sat, 12 Dec 2020 03:03:05 +0000
Subject: (244906) installers for FreeBSD fail to boot HP Elitebook 830 G7
In-Reply-To: <86360c9p2p.fsf@gmail.com>
References: <86360c9p2p.fsf@gmail.com>
Message-ID: <8cd298fa-5b16-d58b-b63b-201905f83438@gmail.com>

On 11/12/2020 18:26, Ludovit Koren wrote:

> Hi,
>
> I am trying to install FreeBSD-12.2-RELEASE,
> FreeBSD-13.0-CURRENT-amd64-20201203-f659bf1d31c
>
> The image starts booting and it hangs in:
>
> ....
> Loading kernel...
> /boot/kernel/kernel text=0x16bdcc4 data 0x140 data 0x75fe80 ....
> Loading configured modules...
> can't find '/etc/hostid'
> can't find '/boot/entropy'
> Start @ 0xffffffff80373000 ...
> EFI framebuffer information:
> addr, size      0xa0000000, 0x7e9000
> dimensions      1920 x 1080
> stride          1920
> masks           0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
> _
>
> ?
Probably 
<https://lists.freebsd.org/pipermail/freebsd-current/2020-December/077759.html>

From grahamperrin at gmail.com  Sat Dec 12 07:15:31 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Sat, 12 Dec 2020 07:15:25 +0000
Subject: usr.bin/xinstall r366697 versus: buildworld: lib/libc: install:
 short write to libc.so.7.debug: [_libinstall] Error code 71
In-Reply-To: <9b6bbf0b-93d2-123e-ee5c-f8de660b150a@gmail.com>
References: <746a3af4-3daf-9029-bf48-23efa3f5da8e@gmail.com>
 <37d2a873-8cb9-b858-fa06-4bbfcf006835@gmail.com>
 <1e9e8649-0fe7-4b83-078d-f67908e2f430@gmail.com>
 <40C5DB30-4B7C-4A51-8069-B4E67298C558@FreeBSD.org>
 <9b6bbf0b-93d2-123e-ee5c-f8de660b150a@gmail.com>
Message-ID: <b08bf10e-50f9-79c8-58e3-f46eac1307bd@gmail.com>

On 23/11/2020 12:18, Graham Perrin wrote:

> On 22/11/2020 12:00, Dimitry Andric wrote:
>> ?
>> I'd guess it's an unintended side-effect of
>> https://svnweb.freebsd.org/base?view=revision&revision=366697
>> ("install(1): Avoid unncessary fstatfs() calls and use mmap() based on
>> size").
>>
>> If you only revert usr.bin/xinstall to r366696, and then rebuild it,
>> does it still occur?
>>
>> -Dimitry
>
> Thank you!
>
> Success with r366696:
>
> ----
>
> ?


Re: 
<https://lists.freebsd.org/pipermail/freebsd-current/2020-November/077634.html> 
please, should I open a bug for this?


Is the issue exposed by my choice of gzip-9 for e.g. /usr/ and if so, 
can I avoid it by (now) reverting to lz4 for that part, and/or any other 
part, of the file system?


----


root at mowa219-gjp4-8570p:~ # zfs get mountpoint,compression
NAME PROPERTY???? VALUE????????????????????????????????????????? SOURCE
Transcend mountpoint?? /Volumes/t500????????????????????????????????? local
Transcend compression? zstd?????????????????????????????????????????? local
Transcend/VirtualBox mountpoint?? /Volumes/t500/VirtualBox inherited 
from Transcend
Transcend/VirtualBox compression? zstd inherited from Transcend
copperbowl mountpoint?? /copperbowl??????????????????????????????????? local
copperbowl compression? lz4??????????????????????????????????????????? local
copperbowl/ROOT mountpoint?? 
none?????????????????????????????????????????? local
copperbowl/ROOT compression? lz4 inherited from copperbowl
copperbowl/ROOT/Waterfox mountpoint?? 
/????????????????????????????????????????????? local
copperbowl/ROOT/Waterfox compression? lz4 inherited from copperbowl
copperbowl/ROOT/r367081f mountpoint?? 
/????????????????????????????????????????????? local
copperbowl/ROOT/r367081f compression? lz4 inherited from copperbowl
copperbowl/ROOT/r367936e mountpoint?? 
/????????????????????????????????????????????? local
copperbowl/ROOT/r367936e compression? lz4 inherited from copperbowl
copperbowl/ROOT/r367936f mountpoint?? 
/????????????????????????????????????????????? local
copperbowl/ROOT/r367936f compression? lz4 inherited from copperbowl
copperbowl/ROOT/r367936f at 2020-03-20-06:19:45 mountpoint?? 
-????????????????????????????????????????????? -
copperbowl/ROOT/r367936f at 2020-03-20-06:19:45 compression? 
-????????????????????????????????????????????? -
copperbowl/ROOT/r367936f at 2020-11-22-23:18:47 mountpoint?? 
-????????????????????????????????????????????? -
copperbowl/ROOT/r367936f at 2020-11-22-23:18:47 compression? 
-????????????????????????????????????????????? -
copperbowl/ROOT/r367936f at 2020-12-06-16:23:14 mountpoint?? 
-????????????????????????????????????????????? -
copperbowl/ROOT/r367936f at 2020-12-06-16:23:14 compression? 
-????????????????????????????????????????????? -
copperbowl/VirtualBox mountpoint?? 
/usr/local/VirtualBox????????????????????????? local
copperbowl/VirtualBox compression? 
gzip-9???????????????????????????????????????? local
copperbowl/iocage mountpoint?? /copperbowl/iocage inherited from copperbowl
copperbowl/iocage compression? 
gzip-9???????????????????????????????????????? local
copperbowl/iocage/download mountpoint?? /copperbowl/iocage/download 
inherited from copperbowl
copperbowl/iocage/download compression? 
lz4??????????????????????????????????????????? local
copperbowl/iocage/download/12.0-RELEASE mountpoint?? 
/copperbowl/iocage/download/12.0-RELEASE inherited from copperbowl
copperbowl/iocage/download/12.0-RELEASE compression? 
lz4??????????????????????????????????????????? local
copperbowl/iocage/images mountpoint?? /copperbowl/iocage/images 
inherited from copperbowl
copperbowl/iocage/images compression? 
lz4??????????????????????????????????????????? local
copperbowl/iocage/jails mountpoint?? /copperbowl/iocage/jails inherited 
from copperbowl
copperbowl/iocage/jails compression? 
lz4??????????????????????????????????????????? local
copperbowl/iocage/jails/jbrowsers mountpoint?? 
/copperbowl/iocage/jails/jbrowsers inherited from copperbowl
copperbowl/iocage/jails/jbrowsers compression? lz4 inherited from 
copperbowl/iocage/jails
copperbowl/iocage/jails/jbrowsers/root mountpoint?? 
/copperbowl/iocage/jails/jbrowsers/root inherited from copperbowl
copperbowl/iocage/jails/jbrowsers/root compression? lz4 inherited from 
copperbowl/iocage/jails
copperbowl/iocage/log mountpoint?? /copperbowl/iocage/log inherited from 
copperbowl
copperbowl/iocage/log compression? 
lz4??????????????????????????????????????????? local
copperbowl/iocage/releases mountpoint?? /copperbowl/iocage/releases 
inherited from copperbowl
copperbowl/iocage/releases compression? 
lz4??????????????????????????????????????????? local
copperbowl/iocage/releases/12.0-RELEASE mountpoint?? 
/copperbowl/iocage/releases/12.0-RELEASE inherited from copperbowl
copperbowl/iocage/releases/12.0-RELEASE compression? lz4 inherited from 
copperbowl/iocage/releases
copperbowl/iocage/releases/12.0-RELEASE/root mountpoint?? 
/copperbowl/iocage/releases/12.0-RELEASE/root inherited from copperbowl
copperbowl/iocage/releases/12.0-RELEASE/root compression? 
lz4??????????????????????????????????????????? local
copperbowl/iocage/releases/12.0-RELEASE/root at jbrowsers mountpoint?? 
-????????????????????????????????????????????? -
copperbowl/iocage/releases/12.0-RELEASE/root at jbrowsers compression? 
-????????????????????????????????????????????? -
copperbowl/iocage/templates mountpoint?? /copperbowl/iocage/templates 
inherited from copperbowl
copperbowl/iocage/templates compression? 
lz4??????????????????????????????????????????? local
copperbowl/poudriere mountpoint?? /copperbowl/poudriere inherited from 
copperbowl
copperbowl/poudriere compression? 
gzip-9???????????????????????????????????????? local
copperbowl/poudriere/data mountpoint?? 
/usr/local/poudriere/data????????????????????? local
copperbowl/poudriere/data compression? 
gzip-9???????????????????????????????????????? local
copperbowl/poudriere/data/.m mountpoint?? /usr/local/poudriere/data/.m 
inherited from copperbowl/poudriere/data
copperbowl/poudriere/data/.m compression? gzip-9 inherited from 
copperbowl/poudriere/data
copperbowl/poudriere/data/cache mountpoint?? 
/usr/local/poudriere/data/cache inherited from copperbowl/poudriere/data
copperbowl/poudriere/data/cache compression? 
off??????????????????????????????????????????? local
copperbowl/poudriere/data/logs mountpoint?? 
/usr/local/poudriere/data/logs inherited from copperbowl/poudriere/data
copperbowl/poudriere/data/logs compression? 
gzip-9???????????????????????????????????????? local
copperbowl/poudriere/data/packages mountpoint?? 
/usr/local/poudriere/data/packages inherited from copperbowl/poudriere/data
copperbowl/poudriere/data/packages compression? 
off??????????????????????????????????????????? local
copperbowl/poudriere/data/wrkdirs mountpoint?? 
/usr/local/poudriere/data/wrkdirs inherited from copperbowl/poudriere/data
copperbowl/poudriere/data/wrkdirs compression? 
off??????????????????????????????????????????? local
copperbowl/poudriere/jails mountpoint?? /copperbowl/poudriere/jails 
inherited from copperbowl
copperbowl/poudriere/jails compression? 
gzip-9???????????????????????????????????????? local
copperbowl/poudriere/jails/head mountpoint?? 
/usr/local/poudriere/jails/head??????????????? local
copperbowl/poudriere/jails/head compression? 
gzip-9???????????????????????????????????????? local
copperbowl/poudriere/jails/head at clean mountpoint?? 
-????????????????????????????????????????????? -
copperbowl/poudriere/jails/head at clean compression? 
-????????????????????????????????????????????? -
copperbowl/poudriere/ports mountpoint?? /copperbowl/poudriere/ports 
inherited from copperbowl
copperbowl/poudriere/ports compression? gzip-9 inherited from 
copperbowl/poudriere
copperbowl/poudriere/ports/default mountpoint?? 
/usr/local/poudriere/ports/default???????????? local
copperbowl/poudriere/ports/default compression? 
gzip-9???????????????????????????????????????? local
copperbowl/poudriere/ports/freebsd-ports-kde mountpoint?? 
/usr/local/poudriere/ports/freebsd-ports-kde?? local
copperbowl/poudriere/ports/freebsd-ports-kde compression? 
gzip-9???????????????????????????????????????? local
copperbowl/tmp mountpoint?? 
/tmp?????????????????????????????????????????? local
copperbowl/tmp compression? 
off??????????????????????????????????????????? local
copperbowl/usr mountpoint?? 
/usr?????????????????????????????????????????? local
copperbowl/usr compression? 
gzip-9???????????????????????????????????????? local
copperbowl/usr/home mountpoint?? /usr/home inherited from copperbowl/usr
copperbowl/usr/home compression? 
lz4??????????????????????????????????????????? local
copperbowl/usr/home at 2020-09-19-20:29-r365364 mountpoint?? 
-????????????????????????????????????????????? -
copperbowl/usr/home at 2020-09-19-20:29-r365364 compression? 
-????????????????????????????????????????????? -
copperbowl/usr/ports mountpoint?? /usr/ports inherited from copperbowl/usr
copperbowl/usr/ports compression? gzip-9 inherited from copperbowl/usr
copperbowl/usr/src mountpoint?? /usr/src inherited from copperbowl/usr
copperbowl/usr/src compression? gzip-9 inherited from copperbowl/usr
copperbowl/var mountpoint?? 
/var?????????????????????????????????????????? local
copperbowl/var compression? lz4 inherited from copperbowl
copperbowl/var/audit mountpoint?? /var/audit inherited from copperbowl/var
copperbowl/var/audit compression? lz4 inherited from copperbowl
copperbowl/var/crash mountpoint?? /var/crash inherited from copperbowl/var
copperbowl/var/crash compression? lz4 inherited from copperbowl
copperbowl/var/log mountpoint?? /var/log inherited from copperbowl/var
copperbowl/var/log compression? lz4 inherited from copperbowl
copperbowl/var/mail mountpoint?? /var/mail inherited from copperbowl/var
copperbowl/var/mail compression? lz4 inherited from copperbowl
copperbowl/var/tmp mountpoint?? /var/tmp inherited from copperbowl/var
copperbowl/var/tmp compression? lz4 inherited from copperbowl
copperbowl/vm-bhyve mountpoint?? /copperbowl/vm-bhyve inherited from 
copperbowl
copperbowl/vm-bhyve compression? gzip-9


From rebecca at bsdio.com  Sat Dec 12 19:18:13 2020
From: rebecca at bsdio.com (Rebecca Cran)
Date: Sat, 12 Dec 2020 12:18:08 -0700
Subject: (244906) installers for FreeBSD fail to boot HP Elitebook 830 G7
In-Reply-To: <8cd298fa-5b16-d58b-b63b-201905f83438@gmail.com>
References: <86360c9p2p.fsf@gmail.com>
 <8cd298fa-5b16-d58b-b63b-201905f83438@gmail.com>
Message-ID: <8aa45f8c-7b14-a264-a8b7-9dd0b6b36f59@bsdio.com>

On 12/11/2020 8:03 PM, Graham Perrin wrote:
> On 11/12/2020 18:26, Ludovit Koren wrote:
>
>>
>> I am trying to install FreeBSD-12.2-RELEASE,
>> FreeBSD-13.0-CURRENT-amd64-20201203-f659bf1d31c
>>
>> The image starts booting and it hangs in:
>>
>> ....
>> Loading kernel...
>> /boot/kernel/kernel text=0x16bdcc4 data 0x140 data 0x75fe80 ....
>> Loading configured modules...
>> can't find '/etc/hostid'
>> can't find '/boot/entropy'
>> Start @ 0xffffffff80373000 ...
>> EFI framebuffer information:
>> addr, size????? 0xa0000000, 0x7e9000
>> dimensions????? 1920 x 1080
>> stride????????? 1920
>> masks?????????? 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000
> Probably 
> <https://lists.freebsd.org/pipermail/freebsd-current/2020-December/077759.html>

This crash also happens on VMware Workstation 16 Pro with 13-CURRENT. 
I'm hoping to find some time to debug it.


-- 
Rebecca Cran



From grahamperrin at gmail.com  Sun Dec 13 08:19:34 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Sun, 13 Dec 2020 08:19:30 +0000
Subject: (239489) buildkernel fails if PORTS_MODULES= includes openzfs-kmod
Message-ID: <7fe2fe36-a342-e863-a63e-47f6890f8220@gmail.com>

Please: is there some way to include openzfs-kmod at buildkernel time?

To work around 
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239489> I habitually 
remove openzfs-kmod from /etc/src.conf _and_ modify /boot/loader.conf 
before performing the build:

zfs_load="YES"
openzfs_load="NO"


From grahamperrin at gmail.com  Sun Dec 13 10:18:16 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Sun, 13 Dec 2020 10:18:11 +0000
Subject: =?UTF-8?Q?kern=2ecam=e2=80=a6delay=2c_suspend_and_ZFS_pools_on_USB_?=
 =?UTF-8?Q?=28was=3a_rc=2ed/zpool_runs_before_ada=284=29_attaches=29?=
In-Reply-To: <X8amXv2L66HQC8mS@rpi4.local>
References: <b55604d6-5c23-a590-859c-a52f36386d44@omnilan.de>
 <1439301337.11.1606815206810@localhost>
 <08815f92-742c-2934-e746-fd04ca9b4e16@omnilan.de>
 <286917313.21.1606836130991@localhost>
 <786faeee90e79aa0175b298ec859265ff57a3129.camel@freebsd.org>
 <X8amXv2L66HQC8mS@rpi4.local>
Message-ID: <d88e09df-a8f6-6b4a-bd49-eaaeeae53a68@gmail.com>

On 01/12/2020 20:23, tech-lists wrote:
> On Tue, Dec 01, 2020 at 08:34:33AM -0700, Ian Lepore wrote:
>> On Tue, 2020-12-01 at 16:22 +0100, Ronald Klop wrote:
>>>
>>> You can define these in /boot/loader.conf:
>>> #kern.cam.boot_delay="10000" # Delay (in ms) of root mount for CAM
>>> bus
>>> #kern.cam.scsi_delay="2000" # Delay (in ms) before probing SCSI
>>>
>>> Maybe that helps.
>>>
>>> Ronald.
>>>
>>
>> Those settings control waiting before mounting root.? Harry's problem
>> is that root is mounted quickly, before other drives are ready for zfs.
>>
>> The zpool script waits for 'disks'.? It would be nice if the cam
>> subsystem had something like a sysctl it set to indicate when initial
>> probing for disks was done, then there could be an rc.d/camprobe script
>> with 'PROVIDE: disks' which waits for the probing to complete.
>>
>> -- Ian
>
> kern.cam.boot_delay should still fix it because what is required is a 
> delay
> while the devices (all of the disks, zfs or not) get ready. Because 
> root has to happen before disks/zfs. 


Where a pool is on a USB 2.0 device: might kern.cam.boot_delay, or some 
other delay, negate the need to export the pool before suspending the 
computer?

Related: 
<https://lists.freebsd.org/pipermail/freebsd-current/2020-November/077681.html>


From warlock at phouka.net  Sun Dec 13 17:26:34 2020
From: warlock at phouka.net (John Kennedy)
Date: Sun, 13 Dec 2020 09:25:09 -0800
Subject: (239489) buildkernel fails if PORTS_MODULES= includes openzfs-kmod
In-Reply-To: <7fe2fe36-a342-e863-a63e-47f6890f8220@gmail.com>
References: <7fe2fe36-a342-e863-a63e-47f6890f8220@gmail.com>
Message-ID: <X9ZOdSDF7uuGRizQ@phouka1.phouka.net>

On Sun, Dec 13, 2020 at 08:19:30AM +0000, Graham Perrin wrote:
> Please: is there some way to include openzfs-kmod at buildkernel time?
> 
> To work around 
> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239489> I habitually 
> remove openzfs-kmod from /etc/src.conf _and_ modify /boot/loader.conf 
> before performing the build:
> 
> zfs_load="YES"
> openzfs_load="NO"

Isn't openzfs-kmod on 13-CURRENT more or less moot since r36474, the OpenZFS
merge, ~2020/8/25?  That ticket was opened on 2019/7/28, pre-merge.

Now, I still see recent updates on openzfs-kmod port so the question might
still be relevant for non-13 or if you're just using the port for reasons or
anywhere older than 13 (12.2, etc).

From grahamperrin at gmail.com  Sun Dec 13 18:49:13 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Sun, 13 Dec 2020 18:49:07 +0000
Subject: (239489) buildkernel fails if PORTS_MODULES= includes openzfs-kmod
In-Reply-To: <X9ZOdSDF7uuGRizQ@phouka1.phouka.net>
References: <7fe2fe36-a342-e863-a63e-47f6890f8220@gmail.com>
 <X9ZOdSDF7uuGRizQ@phouka1.phouka.net>
Message-ID: <aa3cadda-5c04-3977-d6cf-406f6cb78383@gmail.com>

On 13/12/2020 17:25, John Kennedy wrote:
> On Sun, Dec 13, 2020 at 08:19:30AM +0000, Graham Perrin wrote:
>> Please: is there some way to include openzfs-kmod at buildkernel time?
>>
>> To work around
>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239489> I habitually
>> remove openzfs-kmod from /etc/src.conf _and_ modify /boot/loader.conf
>> before performing the build:
>>
>> zfs_load="YES"
>> openzfs_load="NO"
> Isn't openzfs-kmod on 13-CURRENT more or less moot since r36474, the OpenZFS
> merge, ~2020/8/25? ?

Not entirely moot; for 
<https://www.freshports.org/sysutils/openzfs-kmod/> the description for 
the most recent commit refers to building on 13-CURRENT


From guru at unixarea.de  Sun Dec 13 19:06:07 2020
From: guru at unixarea.de (Matthias Apitz)
Date: Sun, 13 Dec 2020 20:06:02 +0100
Subject: after update to r368166: no sound recording
In-Reply-To: <X9Mac12Z3u2ZpMOy@c720-r368166.fritz.box>
References: <X9CchZFla3RMFd/3@c720-r368166.fritz.box>
 <72bd5240-3092-bf7b-51aa-2ad12a576efb@selasky.org>
 <X9Crmcsce57g0PER@c720-r368166.fritz.box>
 <4d83e630-7bed-16bd-3422-267813d3e842@selasky.org>
 <X9Mac12Z3u2ZpMOy@c720-r368166.fritz.box>
Message-ID: <X9ZmGrWrFEqWbhr5@c720-r368166.fritz.box>

El d?a viernes, diciembre 11, 2020 a las 08:06:27a. m. +0100, Matthias Apitz escribi?:

> FreeBSD c720-r368166 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r342378:368166M: Fri Dec 11 07:46:32 CET 2020     guru at c720-r368166:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
> 
> and all is fine again as it was before. Someone with more knowledge should
> have a look into a 'svn diff -r342378:368166 sys/dev/sound/pci/hda' and
> see which of the changes might break the things. 
> 

I did an analyzing of the files changed in sys/dev/sound/pci/hda between
r342378 (2018-11-02) and r368166 (2020-11-30)

I copied over all files from hda/* to a new dir hda.r368166/* and
updated (i.e. reverted) hda/* to r342378; only the 7 files below (of 10)
have changed between r342378 and r368166:

The kernel built with hda of r342378 works fine;

The work plan was now to change one file after the other to r368166
and see if the kernel still works fine, i.e. which of the 7 file(s)
is causing the regression...

i.e. I did: 

# svn up -r342378 sys/dev/sound/pci/hda
# cp sys/dev/sound/pci/hda.r368166/hdac.c sys/dev/sound/pci/hda/
# touch sys/dev/sound/pci/hda/hdac.c 
# make buildkernel -DNO_CLEAN
# make installkernel
...

 v----------------------------an 'x' means: was copied from hda.r368166;
[x] Index: hda/hdac.c
[x] Index: hda/hdac.h

recording with the kernel still works

[x] Index: hda/hdaa_patches.c     

recording with the kernel still works

[x] Index: hda/hdacc.c
[x] Index: hda/hda_reg.h          only cleanups of empty lines

recording with the kernel still works

[x] Index: hda/hdaa.h
[x] Index: hda/hdaa.c             

recording with the kernel stoped working

Which means the few changes in hda/hdaa.c are causing the regression:

# svn diff -r342378 hdaa.c
Index: hdaa.c
===================================================================
--- hdaa.c	(revisi?n: 342378)
+++ hdaa.c	(copia de trabajo)
@@ -52,7 +52,6 @@
 #define hdaa_lock(devinfo)	snd_mtxlock((devinfo)->lock)
 #define hdaa_unlock(devinfo)	snd_mtxunlock((devinfo)->lock)
 #define hdaa_lockassert(devinfo) snd_mtxassert((devinfo)->lock)
-#define hdaa_lockowned(devinfo)	mtx_owned((devinfo)->lock)
 
 static const struct {
 	const char *key;
@@ -1129,7 +1128,6 @@
 	    ((step - offset) * (size + 1)) / 4);
 }
 
-
 static int
 hdaa_sysctl_caps(SYSCTL_HANDLER_ARGS)
 {
@@ -5034,11 +5032,13 @@
 		pincap = w->wclass.pin.cap;
 
 		/* Disable everything. */
-		w->wclass.pin.ctrl &= ~(
-		    HDA_CMD_SET_PIN_WIDGET_CTRL_HPHN_ENABLE |
-		    HDA_CMD_SET_PIN_WIDGET_CTRL_OUT_ENABLE |
-		    HDA_CMD_SET_PIN_WIDGET_CTRL_IN_ENABLE |
-		    HDA_CMD_SET_PIN_WIDGET_CTRL_VREF_ENABLE_MASK);
+		if (devinfo->init_clear) {
+			w->wclass.pin.ctrl &= ~(
+		    	HDA_CMD_SET_PIN_WIDGET_CTRL_HPHN_ENABLE |
+		    	HDA_CMD_SET_PIN_WIDGET_CTRL_OUT_ENABLE |
+		    	HDA_CMD_SET_PIN_WIDGET_CTRL_IN_ENABLE |
+		    	HDA_CMD_SET_PIN_WIDGET_CTRL_VREF_ENABLE_MASK);
+		}
 
 		if (w->enable == 0) {
 			/* Pin is unused so left it disabled. */
@@ -6669,8 +6669,12 @@
 	    devinfo, 0, hdaa_sysctl_gpo_config, "A", "GPO configuration");
 	SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev),
 	    SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO,
-	    "reconfig", CTLTYPE_INT | CTLFLAG_RW,
+	    "reconfig", CTLTYPE_INT | CTLFLAG_RW | CTLFLAG_NEEDGIANT,
 	    dev, 0, hdaa_sysctl_reconfig, "I", "Reprocess configuration");
+	SYSCTL_ADD_INT(device_get_sysctl_ctx(dev),
+	    SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO,
+	    "init_clear", CTLFLAG_RW,
+	    &devinfo->init_clear, 1,"Clear initial pin widget configuration");
 	bus_generic_attach(dev);
 	return (0);
 }

# svn diff -r342378 hdaa.h
Index: hdaa.h
===================================================================
--- hdaa.h	(revisi?n: 342378)
+++ hdaa.h	(copia de trabajo)
@@ -214,6 +214,7 @@
 	struct hdaa_chan	*chans;
 	struct callout		poll_jack;
 	int			poll_ival;
+	uint32_t		init_clear;
 };
 
 #define HDAA_CHN_RUNNING	0x00000001


If one looks into a svn log of the file hdaa.c it seems that one of the two changes 
r358333 or r350078 must have caused the problem:

# svn log hdaa.c

------------------------------------------------------------------------
r365085 | mjg | 2020-09-01 23:27:34 +0200 (mar. 01 de sept. de 2020) | 2 l?neas

sound: clean up empty lines in .c and .h files

------------------------------------------------------------------------
r360076 | emaste | 2020-04-18 20:25:30 +0200 (s?b. 18 de abr. de 2020) | 4 l?neas

hda: remove hda*_lockowned macros

These are not used anywhere.

------------------------------------------------------------------------
r358333 | kaktus | 2020-02-26 15:26:36 +0100 (mi?. 26 de feb. de 2020) | 16 l?neas

Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (17 of many)

r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
still not MPSAFE (or already are but aren?t properly marked).
Use it in preparation for a general review of all nodes.

This is non-functional change that adds annotations to SYSCTL_NODE and
SYSCTL_PROC nodes using one of the soon-to-be-required flags.

Mark all obvious cases as MPSAFE.  All entries that haven't been marked
as MPSAFE before are by default marked as NEEDGIANT

Approved by:	kib (mentor, blanket)
Commented by:	kib, gallatin, melifaro
Differential Revision:	https://reviews.freebsd.org/D23718

------------------------------------------------------------------------
r350078 | sbruno | 2019-07-17 06:13:46 +0200 (mi?. 17 de jul. de 2019) | 8 l?neas

I add the ability to accept the default pin widget configuration to help
with various laptops using hdaa(4) sound devices.  We don't seem to know
the "correct" configurations for these devices and the defaults are far
superiour, e.g. they work if you don't nuke the default configs.

PR:	200526
Differential Revision:	https://reviews.freebsd.org/D17772

------------------------------------------------------------------------
r337043 | jhibbits | 2018-08-01 16:50:41 +0200 (mi?. 01 de ago. de 2018) | 13 l?neas

snd_hda: Synchronize DMA buffers for the control path

Make sure both sides of the DMA buffer memory accesses for the CORB and RIRB
(control buffers) in snd_hda (device and CPU) can see coherent memory.  This
is needed on weakly ordered architectures including PowerPC and ARM.  Patch
originally by mmel, with small changes.

This does not cover the data path of snd_hda.  We don't have sync operations
for in-progress DMA buffers, to sync ranges of a map.

Reviewed By: mmel
Differential Revision: https://reviews.freebsd.org/D16517

...

-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub
??? ????? ??? ??????, ??? ?????? ??? ?????????? (??a????? ????? ?????)
Without books no knowledge - without knowledge no communism (Vladimir Ilyich Lenin) 
Sin libros no hay saber - sin saber no hay comunismo. (Vladimir Ilich Lenin)

From warlock at phouka.net  Sun Dec 13 19:47:55 2020
From: warlock at phouka.net (John Kennedy)
Date: Sun, 13 Dec 2020 11:46:36 -0800
Subject: (239489) buildkernel fails if PORTS_MODULES= includes openzfs-kmod
In-Reply-To: <aa3cadda-5c04-3977-d6cf-406f6cb78383@gmail.com>
References: <7fe2fe36-a342-e863-a63e-47f6890f8220@gmail.com>
 <X9ZOdSDF7uuGRizQ@phouka1.phouka.net>
 <aa3cadda-5c04-3977-d6cf-406f6cb78383@gmail.com>
Message-ID: <X9ZvnA6ztDQi6KYI@phouka1.phouka.net>

On Sun, Dec 13, 2020 at 06:49:07PM +0000, Graham Perrin wrote:
> Not entirely moot; for 
> <https://www.freshports.org/sysutils/openzfs-kmod/> the description for 
> the most recent commit refers to building on 13-CURRENT

Well, it's a port, so they'll want it to compile if nothing else.  It just
necessarily needed on 13, since it should be nearly par (if slightly behind in
some MFC-ish interval) the kernel.  Of course, when we get into 14 and 13
becomes more stable, 13-releng might be where 12 is now.

This was just a comment on a old ticket (with "latest" OS) in the -current
mailing list which is the potential edge case (13) of an edge case (need
to match kmod with kernel) where you might not need it.  I'm not saying
that it couldn't use some fixing in the medium/long term.


From grahamperrin at gmail.com  Mon Dec 14 07:41:50 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Mon, 14 Dec 2020 07:41:45 +0000
Subject: Identifying broken applications following careless use of make
 -DBATCH_DELETE_OLD_FILES delete-old-libs
Message-ID: <d1a20064-300d-e5e1-8582-57b4a5ee645a@gmail.com>

Re: 
<https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html#updating-src-completing-check-old> 
I made careless use of:

cd /usr/src && make -DBATCH_DELETE_OLD_FILES delete-old-libs

? then found applications such as LibreOffice no longer working as 
expected. Resolved (I believe):

pkg remove inkscape libreoffice && pkg autoremove && pkg install 
inkscape libreoffice

Please: how can I positively identify other applications that I might 
have broken through careless deletion of old libraries?

From Alexander at leidinger.net  Mon Dec 14 08:39:07 2020
From: Alexander at leidinger.net (Alexander Leidinger)
Date: Mon, 14 Dec 2020 09:38:38 +0100
Subject: Identifying broken applications following careless use of make
 -DBATCH_DELETE_OLD_FILES delete-old-libs
In-Reply-To: <d1a20064-300d-e5e1-8582-57b4a5ee645a@gmail.com>
Message-ID: <20201214093838.Horde.7MCNPdaO93VFac3VZjMk0BW@webmail.leidinger.net>

Quoting Graham Perrin <grahamperrin at gmail.com> (from Mon, 14 Dec 2020  
07:41:45 +0000):

> Re:  
> <https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html#updating-src-completing-check-old> I made careless use  
> of:
>
> cd /usr/src && make -DBATCH_DELETE_OLD_FILES delete-old-libs
[...]
> Please: how can I positively identify other applications that I  
> might have broken through careless deletion of old libraries?

% cat remove_old_libs_with_unresolved_libs.sh
#!/bin/sh

find /usr/local/*bin* /usr/local/lib* -type f \
| xargs ldd -f '%p|%A\n' 2>/dev/null \
| grep '^not found' | grep compat/pkg | cut -d '|' -f2 \
| sort -u | xargs rm -v

% cat list_ports_using_nonexisting_lib.sh
#!/bin/sh

find /usr/local/*bin* /usr/local/lib* -type f \
| xargs ldd -f '%p|%A\n' 2>/dev/null \
| grep '^not found' | cut -d '|' -f2 \
| xargs pkg which -q | sort -u


Bye,
Alexander.

-- 
http://www.Leidinger.net Alexander at Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild at FreeBSD.org  : PGP 0x8F31830F9F2772BF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digitale PGP-Signatur
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20201214/4b444cea/attachment.sig>

From guru at unixarea.de  Mon Dec 14 09:16:29 2020
From: guru at unixarea.de (Matthias Apitz)
Date: Mon, 14 Dec 2020 10:16:21 +0100
Subject: after update to r368166: no sound recording
In-Reply-To: <X9ZmGrWrFEqWbhr5@c720-r368166.fritz.box>
References: <X9CchZFla3RMFd/3@c720-r368166.fritz.box>
 <72bd5240-3092-bf7b-51aa-2ad12a576efb@selasky.org>
 <X9Crmcsce57g0PER@c720-r368166.fritz.box>
 <4d83e630-7bed-16bd-3422-267813d3e842@selasky.org>
 <X9Mac12Z3u2ZpMOy@c720-r368166.fritz.box>
 <X9ZmGrWrFEqWbhr5@c720-r368166.fritz.box>
Message-ID: <X9ctZT+0W15EKQFM@c720-r368166.fritz.box>


I did a step by step down grading with 'svn up -r..... hdaa.c hdaa.h'
(only these two files), starting from r368166 down to the following revisions:

r368166: no recording from pcm1

r358333: no recording from pcm1

r350078: no recording from pcm1

r337043: recording is fine

I've cc'ed now the commiters of the r358333 and r350078. kaktus@ and sbruno@
please check the issue https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251727
and this mail thread in current@

Thanks

	mattias

El d?a domingo, diciembre 13, 2020 a las 08:06:02p. m. +0100, Matthias Apitz escribi?:

> El d?a viernes, diciembre 11, 2020 a las 08:06:27a. m. +0100, Matthias Apitz escribi?:
> 
> > FreeBSD c720-r368166 13.0-CURRENT FreeBSD 13.0-CURRENT #1 r342378:368166M: Fri Dec 11 07:46:32 CET 2020     guru at c720-r368166:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
> > 
> > and all is fine again as it was before. Someone with more knowledge should
> > have a look into a 'svn diff -r342378:368166 sys/dev/sound/pci/hda' and
> > see which of the changes might break the things. 
> > 
> 
> I did an analyzing of the files changed in sys/dev/sound/pci/hda between
> r342378 (2018-11-02) and r368166 (2020-11-30)
> 
> I copied over all files from hda/* to a new dir hda.r368166/* and
> updated (i.e. reverted) hda/* to r342378; only the 7 files below (of 10)
> have changed between r342378 and r368166:
> 
> The kernel built with hda of r342378 works fine;
> 
> The work plan was now to change one file after the other to r368166
> and see if the kernel still works fine, i.e. which of the 7 file(s)
> is causing the regression...
> 
> i.e. I did: 
> 
> # svn up -r342378 sys/dev/sound/pci/hda
> # cp sys/dev/sound/pci/hda.r368166/hdac.c sys/dev/sound/pci/hda/
> # touch sys/dev/sound/pci/hda/hdac.c 
> # make buildkernel -DNO_CLEAN
> # make installkernel
> ...
> 
>  v----------------------------an 'x' means: was copied from hda.r368166;
> [x] Index: hda/hdac.c
> [x] Index: hda/hdac.h
> 
> recording with the kernel still works
> 
> [x] Index: hda/hdaa_patches.c     
> 
> recording with the kernel still works
> 
> [x] Index: hda/hdacc.c
> [x] Index: hda/hda_reg.h          only cleanups of empty lines
> 
> recording with the kernel still works
> 
> [x] Index: hda/hdaa.h
> [x] Index: hda/hdaa.c             
> 
> recording with the kernel stoped working
> 
> Which means the few changes in hda/hdaa.c are causing the regression:
> 
> # svn diff -r342378 hdaa.c
> Index: hdaa.c
> ===================================================================
> --- hdaa.c	(revisi?n: 342378)
> +++ hdaa.c	(copia de trabajo)
> @@ -52,7 +52,6 @@
>  #define hdaa_lock(devinfo)	snd_mtxlock((devinfo)->lock)
>  #define hdaa_unlock(devinfo)	snd_mtxunlock((devinfo)->lock)
>  #define hdaa_lockassert(devinfo) snd_mtxassert((devinfo)->lock)
> -#define hdaa_lockowned(devinfo)	mtx_owned((devinfo)->lock)
>  
>  static const struct {
>  	const char *key;
> @@ -1129,7 +1128,6 @@
>  	    ((step - offset) * (size + 1)) / 4);
>  }
>  
> -
>  static int
>  hdaa_sysctl_caps(SYSCTL_HANDLER_ARGS)
>  {
> @@ -5034,11 +5032,13 @@
>  		pincap = w->wclass.pin.cap;
>  
>  		/* Disable everything. */
> -		w->wclass.pin.ctrl &= ~(
> -		    HDA_CMD_SET_PIN_WIDGET_CTRL_HPHN_ENABLE |
> -		    HDA_CMD_SET_PIN_WIDGET_CTRL_OUT_ENABLE |
> -		    HDA_CMD_SET_PIN_WIDGET_CTRL_IN_ENABLE |
> -		    HDA_CMD_SET_PIN_WIDGET_CTRL_VREF_ENABLE_MASK);
> +		if (devinfo->init_clear) {
> +			w->wclass.pin.ctrl &= ~(
> +		    	HDA_CMD_SET_PIN_WIDGET_CTRL_HPHN_ENABLE |
> +		    	HDA_CMD_SET_PIN_WIDGET_CTRL_OUT_ENABLE |
> +		    	HDA_CMD_SET_PIN_WIDGET_CTRL_IN_ENABLE |
> +		    	HDA_CMD_SET_PIN_WIDGET_CTRL_VREF_ENABLE_MASK);
> +		}
>  
>  		if (w->enable == 0) {
>  			/* Pin is unused so left it disabled. */
> @@ -6669,8 +6669,12 @@
>  	    devinfo, 0, hdaa_sysctl_gpo_config, "A", "GPO configuration");
>  	SYSCTL_ADD_PROC(device_get_sysctl_ctx(dev),
>  	    SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO,
> -	    "reconfig", CTLTYPE_INT | CTLFLAG_RW,
> +	    "reconfig", CTLTYPE_INT | CTLFLAG_RW | CTLFLAG_NEEDGIANT,
>  	    dev, 0, hdaa_sysctl_reconfig, "I", "Reprocess configuration");
> +	SYSCTL_ADD_INT(device_get_sysctl_ctx(dev),
> +	    SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO,
> +	    "init_clear", CTLFLAG_RW,
> +	    &devinfo->init_clear, 1,"Clear initial pin widget configuration");
>  	bus_generic_attach(dev);
>  	return (0);
>  }
> 
> # svn diff -r342378 hdaa.h
> Index: hdaa.h
> ===================================================================
> --- hdaa.h	(revisi?n: 342378)
> +++ hdaa.h	(copia de trabajo)
> @@ -214,6 +214,7 @@
>  	struct hdaa_chan	*chans;
>  	struct callout		poll_jack;
>  	int			poll_ival;
> +	uint32_t		init_clear;
>  };
>  
>  #define HDAA_CHN_RUNNING	0x00000001
> 
> 
> If one looks into a svn log of the file hdaa.c it seems that one of the two changes 
> r358333 or r350078 must have caused the problem:
> 
> # svn log hdaa.c
> 
> ------------------------------------------------------------------------
> r365085 | mjg | 2020-09-01 23:27:34 +0200 (mar. 01 de sept. de 2020) | 2 l?neas
> 
> sound: clean up empty lines in .c and .h files
> 
> ------------------------------------------------------------------------
> r360076 | emaste | 2020-04-18 20:25:30 +0200 (s?b. 18 de abr. de 2020) | 4 l?neas
> 
> hda: remove hda*_lockowned macros
> 
> These are not used anywhere.
> 
> ------------------------------------------------------------------------
> r358333 | kaktus | 2020-02-26 15:26:36 +0100 (mi?. 26 de feb. de 2020) | 16 l?neas
> 
> Mark more nodes as CTLFLAG_MPSAFE or CTLFLAG_NEEDGIANT (17 of many)
> 
> r357614 added CTLFLAG_NEEDGIANT to make it easier to find nodes that are
> still not MPSAFE (or already are but aren?t properly marked).
> Use it in preparation for a general review of all nodes.
> 
> This is non-functional change that adds annotations to SYSCTL_NODE and
> SYSCTL_PROC nodes using one of the soon-to-be-required flags.
> 
> Mark all obvious cases as MPSAFE.  All entries that haven't been marked
> as MPSAFE before are by default marked as NEEDGIANT
> 
> Approved by:	kib (mentor, blanket)
> Commented by:	kib, gallatin, melifaro
> Differential Revision:	https://reviews.freebsd.org/D23718
> 
> ------------------------------------------------------------------------
> r350078 | sbruno | 2019-07-17 06:13:46 +0200 (mi?. 17 de jul. de 2019) | 8 l?neas
> 
> I add the ability to accept the default pin widget configuration to help
> with various laptops using hdaa(4) sound devices.  We don't seem to know
> the "correct" configurations for these devices and the defaults are far
> superiour, e.g. they work if you don't nuke the default configs.
> 
> PR:	200526
> Differential Revision:	https://reviews.freebsd.org/D17772
> 
> ------------------------------------------------------------------------
> r337043 | jhibbits | 2018-08-01 16:50:41 +0200 (mi?. 01 de ago. de 2018) | 13 l?neas
> 
> snd_hda: Synchronize DMA buffers for the control path
> 
> Make sure both sides of the DMA buffer memory accesses for the CORB and RIRB
> (control buffers) in snd_hda (device and CPU) can see coherent memory.  This
> is needed on weakly ordered architectures including PowerPC and ARM.  Patch
> originally by mmel, with small changes.
> 
> This does not cover the data path of snd_hda.  We don't have sync operations
> for in-progress DMA buffers, to sync ranges of a map.
> 
> Reviewed By: mmel
> Differential Revision: https://reviews.freebsd.org/D16517
> 
> ...
> 

-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

From schweikh at schweikhardt.net  Mon Dec 14 13:15:09 2020
From: schweikh at schweikhardt.net (Jens Schweikhardt)
Date: Mon, 14 Dec 2020 14:15:05 +0100 (CET)
Subject: Identifying broken applications following careless use of make
 -DBATCH_DELETE_OLD_FILES delete-old-libs
In-Reply-To: <20201214093838.Horde.7MCNPdaO93VFac3VZjMk0BW@webmail.leidinger.net>
References: <20201214093838.Horde.7MCNPdaO93VFac3VZjMk0BW@webmail.leidinger.net>
Message-ID: <2059585148.3686937.1607951705519.JavaMail.zimbra@schweikhardt.net>

Alexander,

it would seem that

find /usr/local/*bin* /usr/local/lib* -type f \
| xargs ldd -f '%p|%A\n' 2>/dev/null \
| grep '^not found' | cut -d '|' -f2 \
| xargs pkg which -q | sort -u

is prone to false positives, since ldd is sensitive to LD_LIBRARY_PATH, viz.:

$ find /usr/local/*bin* /usr/local/lib* -type f \
| xargs ldd -f '%p|%A\n' 2>/dev/null \
| grep '^not found' | cut -d '|' -f2 \
| xargs pkg which -q | sort -u
firefox-84.0_2,2

$ export LD_LIBRARY_PATH=/usr/local/lib/firefox
$ find /usr/local/*bin* /usr/local/lib* -type f \
| xargs ldd -f '%p|%A\n' 2>/dev/null \
| grep '^not found' | cut -d '|' -f2 \
| xargs pkg which -q | sort -u
$

So make sure you look into what exact library is missing and if
it's actually somewhere "non-standard",
that directory should be in LD_LIBRARY_PATH.

Jens

From david at catwhisker.org  Mon Dec 14 13:20:58 2020
From: david at catwhisker.org (David Wolfskill)
Date: Mon, 14 Dec 2020 05:20:55 -0800
Subject: Identifying broken applications following careless use of make
 -DBATCH_DELETE_OLD_FILES delete-old-libs
In-Reply-To: <2059585148.3686937.1607951705519.JavaMail.zimbra@schweikhardt.net>
References: <20201214093838.Horde.7MCNPdaO93VFac3VZjMk0BW@webmail.leidinger.net>
 <2059585148.3686937.1607951705519.JavaMail.zimbra@schweikhardt.net>
Message-ID: <X9dmt5AnTW1cWOr/@albert.catwhisker.org>

I find that "pkg_libchk" (from ports-mgmt/bsdadminscripts2) is helpful
for such cases.

Peace,
david
-- 
David H. Wolfskill                              david at catwhisker.org
As if Trump's lies weren't obvious already, Palin has joined in to prove it.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20201214/8696d12b/attachment.sig>

From jbeich at FreeBSD.org  Mon Dec 14 13:39:45 2020
From: jbeich at FreeBSD.org (Jan Beich)
Date: Mon, 14 Dec 2020 14:39:42 +0100
Subject: review request: loader: implement framebuffer console
In-Reply-To: <EAD2C1D7-8D64-43D4-A2EC-E21FE3CC733B@me.com> (Toomas Soome's
 message of "Fri, 4 Dec 2020 11:24:25 +0200")
References: <EAD2C1D7-8D64-43D4-A2EC-E21FE3CC733B@me.com>
Message-ID: <eejs-ld5t-wny@FreeBSD.org>

Toomas Soome <tsoome at me.com> writes:

> hi!
>
> I have been working on proper framebuffer support on FreeBSD loader
> and there is the current state: https://reviews.freebsd.org/D27420
> <https://reviews.freebsd.org/D27420>
>
> All feedback is welcome, and especially if you can spare some time for testing:)

Do you have another source? Phabricator excludes some files e.g.,

  $ fetch 'https://reviews.freebsd.org/D27420?download=true' | patch -Efsp0
  $ make -sj8 buildworld
  [...]
  ===> stand/images (all)
  make[4]: make[4]: don't know how to make freebsd-brand-rev.png. Stop

From jbeich at FreeBSD.org  Mon Dec 14 14:03:31 2020
From: jbeich at FreeBSD.org (Jan Beich)
Date: Mon, 14 Dec 2020 15:03:28 +0100
Subject: review request: loader: implement framebuffer console
In-Reply-To: <eejs-ld5t-wny@FreeBSD.org> (Jan Beich's message of "Mon, 14 Dec
 2020 14:39:42 +0100")
References: <EAD2C1D7-8D64-43D4-A2EC-E21FE3CC733B@me.com>
 <eejs-ld5t-wny@FreeBSD.org>
Message-ID: <eejs-jxhr-wny@FreeBSD.org>

Jan Beich <jbeich at FreeBSD.org> writes:

> Toomas Soome <tsoome at me.com> writes:
>
>> hi!
>>
>> I have been working on proper framebuffer support on FreeBSD loader
>> and there is the current state: https://reviews.freebsd.org/D27420
>> <https://reviews.freebsd.org/D27420>
>>
>> All feedback is welcome, and especially if you can spare some time for testing:)
>
> Do you have another source? Phabricator excludes some files e.g.,
>
>   $ fetch 'https://reviews.freebsd.org/D27420?download=true' | patch -Efsp0
>   $ make -sj8 buildworld
>   [...]
>   ===> stand/images (all)
>   make[4]: make[4]: don't know how to make freebsd-brand-rev.png. Stop

FWIW, I've tried CLI but no joy:

  $ svn status
  $ pkg install arcanist-php80
  $ arc patch D27420
  PHP Deprecated:  Function libxml_disable_entity_loader() is deprecated in /usr/local/lib/php/arcanist/support/init/init-script.php on line 92

  Deprecated: Function libxml_disable_entity_loader() is deprecated in /usr/local/lib/php/arcanist/support/init/init-script.php on line 92
  [2020-12-14 13:42:12] EXCEPTION: (Exception) Error while loading file "/usr/local/lib/php/arcanist/src/workflow/ArcanistWorkflow.php": Private methods cannot be final as they are never overridden by other classes at [<arcanist>/src/init/lib/PhutilBootloader.php:275]
  arcanist()
    #0 PhutilBootloader::executeInclude(string) called at [<arcanist>/src/init/lib/PhutilBootloader.php:207]
    #1 PhutilBootloader::loadLibrarySource(string, string) called at [<arcanist>/src/symbols/PhutilSymbolLoader.php:422]
    #2 PhutilSymbolLoader::loadSymbol(array) called at [<arcanist>/src/symbols/PhutilSymbolLoader.php:277]
    #3 PhutilSymbolLoader::selectAndLoadSymbols() called at [<arcanist>/src/init/init-library.php:23]
    #4 __phutil_autoload(string)
    #5 class_exists(string) called at [<arcanist>/src/symbols/PhutilClassMapQuery.php:216]
    #6 PhutilClassMapQuery::loadMap() called at [<arcanist>/src/symbols/PhutilClassMapQuery.php:184]
    #7 PhutilClassMapQuery::execute() called at [<arcanist>/src/runtime/ArcanistRuntime.php:535]
    #8 ArcanistRuntime::newWorkflows(ArcanistArcToolset) called at [<arcanist>/src/runtime/ArcanistRuntime.php:115]
    #9 ArcanistRuntime::executeCore(array) called at [<arcanist>/src/runtime/ArcanistRuntime.php:37]
    #10 ArcanistRuntime::execute(array) called at [<arcanist>/support/init/init-arcanist.php:6]
    #11 require_once(string) called at [<arcanist>/bin/arc:10]

  $ svn status
  $ pkg install arcanist-php74
  $ arc patch D27420
  [...]
  A  (bin)  stand/images/freebsd-logo-rev.png
  A  (bin)  stand/images/freebsd-brand.png
  A  (bin)  stand/images/freebsd-brand-rev.png
  A         stand/images/Makefile
  svn: warning: W150002: 'stand/images' is already under version control
  svn: E200009: Could not add all targets because some targets are already versioned
  svn: E200009: Illegal target for the requested operation
  A         stand/i386/libi386/vbe.h
  A         stand/i386/libi386/vbe.c
  A         stand/fonts/Makefile
  A         stand/fonts/INDEX.fonts
  svn: warning: W150002: 'stand/fonts' is already under version control
  svn: E200009: Could not add all targets because some targets are already versioned
  svn: E200009: Illegal target for the requested operation
  A         stand/common/gfx_fb.h
  A         stand/common/gfx_fb.c
  A         contrib/terminus/ter-u32n.bdf
  A         contrib/terminus/ter-u32b.bdf
  A         contrib/terminus/ter-u28n.bdf
  A         contrib/terminus/ter-u28b.bdf
  A         contrib/terminus/ter-u24n.bdf
  A         contrib/terminus/ter-u24b.bdf
  A         contrib/terminus/ter-u22n.bdf
  A         contrib/terminus/ter-u22b.bdf
  A         contrib/terminus/ter-u20n.bdf
  A         contrib/terminus/ter-u20b.bdf
  A         contrib/terminus/ter-u18n.bdf
  A         contrib/terminus/ter-u18b.bdf
  A         contrib/terminus/ter-u16v.bdf
  A         contrib/terminus/ter-u16n.bdf
  A         contrib/terminus/ter-u16b.bdf
  A         contrib/terminus/ter-u14v.bdf
  A         contrib/terminus/ter-u14n.bdf
  A         contrib/terminus/ter-u14b.bdf
  A         contrib/terminus/ter-u12n.bdf
  A         contrib/terminus/ter-u12b.bdf
  svn: warning: W150002: 'contrib/terminus' is already under version control
  svn: E200009: Could not add all targets because some targets are already versioned
  svn: E200009: Illegal target for the requested operation
  A         contrib/pnglite/pnglite.h
  A         contrib/pnglite/pnglite.c
  A         contrib/pnglite/README.md
  A         contrib/pnglite/LICENSE
  svn: warning: W150002: 'contrib/pnglite' is already under version control
  svn: E200009: Could not add all targets because some targets are already versioned
  svn: E200009: Illegal target for the requested operation
  svn: E125004: MIME type 'application/octet-stream
  \ No newline at end of property' contains invalid character '
  ' in media type
  svn: E125004: MIME type 'application/octet-stream
  \ No newline at end of property' contains invalid character '
  ' in media type
  svn: E125004: MIME type 'application/octet-stream
  \ No newline at end of property' contains invalid character '
  ' in media type
  svn: E135001: Unrecognized line ending style 'native
  \ No newline at end of property' for 'stand/images/Makefile'
  property 'svn:keywords' set on 'stand/images/Makefile'
  svn: E125004: MIME type 'text/plain
  \ No newline at end of property' contains invalid character '
  ' in media type
  svn: E135001: Unrecognized line ending style 'native
  \ No newline at end of property' for 'stand/i386/libi386/vbe.h'
  property 'svn:keywords' set on 'stand/i386/libi386/vbe.h'
  svn: E125004: MIME type 'text/plain
  \ No newline at end of property' contains invalid character '
  ' in media type
  svn: E135001: Unrecognized line ending style 'native
  \ No newline at end of property' for 'stand/i386/libi386/vbe.c'
  property 'svn:keywords' set on 'stand/i386/libi386/vbe.c'
  svn: E125004: MIME type 'text/plain
  \ No newline at end of property' contains invalid character '
  ' in media type
  svn: E135001: Unrecognized line ending style 'native
  \ No newline at end of property' for 'stand/fonts/Makefile'
  property 'svn:keywords' set on 'stand/fonts/Makefile'
  svn: E125004: MIME type 'text/plain
  \ No newline at end of property' contains invalid character '
  ' in media type
  svn: E135001: Unrecognized line ending style 'native
  \ No newline at end of property' for 'stand/common/gfx_fb.h'
  property 'svn:keywords' set on 'stand/common/gfx_fb.h'
  svn: E125004: MIME type 'text/plain
  \ No newline at end of property' contains invalid character '
  ' in media type
  svn: E135001: Unrecognized line ending style 'native
  \ No newline at end of property' for 'stand/common/gfx_fb.c'
  property 'svn:keywords' set on 'stand/common/gfx_fb.c'
  svn: E125004: MIME type 'text/plain
  \ No newline at end of property' contains invalid character '
  ' in media type
  svn: E135001: Unrecognized line ending style 'native
  \ No newline at end of property' for 'contrib/pnglite/pnglite.h'
  property 'svn:keywords' set on 'contrib/pnglite/pnglite.h'
  svn: E125004: MIME type 'text/plain
  \ No newline at end of property' contains invalid character '
  ' in media type
  svn: E135001: Unrecognized line ending style 'native
  \ No newline at end of property' for 'contrib/pnglite/pnglite.c'
  property 'svn:keywords' set on 'contrib/pnglite/pnglite.c'
  svn: E125004: MIME type 'text/plain
  \ No newline at end of property' contains invalid character '
  ' in media type
   OKAY  Successfully applied patch to the working copy.

  $ ls -l stand/images/*.png
  -rw-r--r--  1 foo  foo  0 14 Dec 13:46 stand/images/freebsd-brand-rev.png
  -rw-r--r--  1 foo  foo  0 14 Dec 13:46 stand/images/freebsd-brand.png
  -rw-r--r--  1 foo  foo  0 14 Dec 13:46 stand/images/freebsd-logo-rev.png

From editor at callfortesting.org  Mon Dec 14 22:03:45 2020
From: editor at callfortesting.org (Michael Dexter)
Date: Mon, 14 Dec 2020 14:03:39 -0800
Subject: RISC-V root device question -> Panic
In-Reply-To: <CADeAsy0jyHx10pQ5NRYzuk2gjMGOf4Of5jGOL-0BmoN5PVJd5A@mail.gmail.com>
References: <4fcf5f35-481b-a321-cb52-7264fc10d1d4@callfortesting.org>
 <CADeAsy0jyHx10pQ5NRYzuk2gjMGOf4Of5jGOL-0BmoN5PVJd5A@mail.gmail.com>
Message-ID: <e9ff294d-620e-0466-4ccd-4acf1eb340ff@callfortesting.org>

Mitchell,

On 12/7/20 1:56 PM, Mitchell Horne wrote:
> You can also override it using the QEMU commandline, which is simpler
> since you won't need to recompile anything. Adding the following
> argument should suffice:

This works great but riscv 12-STABLE using last week's snapshot revision 
throws the panic output included below under QEMU and leaves nothing in 
/var/crash

What expectations should I set for RISC-V STABLE and CURRENT?

All the best,

Michael

t[0] == 0xffffffc0006c9d98
t[1] == 0x0000000040c50000
t[2] == 0x0000000040c65000
t[3] == 0x0000000000000001
t[4] == 0x0000000000000000
t[5] == 0x0000000000000001
t[6] == 0x0000000000000001
s[0] == 0xffffffd0b1600248
s[1] == 0x0000000040e49000
s[2] == 0xfffffffffffff000
s[3] == 0x00000000000000ff
s[4] == 0x0000000041000000
s[5] == 0x0000000000000001
s[6] == 0xffffffc000aff988
s[7] == 0x00000000410a1000
s[8] == 0x0000000000000280
s[9] == 0x0000000000000000
s[10] == 0x0000000000001000
s[11] == 0xffffffffffffff73
a[0] == 0x0000000000000000
a[1] == 0xffffffd00297d560
a[2] == 0x0000000000000000
a[3] == 0x0000000000000021
a[4] == 0x0000000000000000
a[5] == 0x0000000000000021
a[6] == 0x000000000000003f
a[7] == 0xffffffc000aff900
sepc == 0xffffffc0004ce414
sstatus == 0x0000000000000120
panic: Fatal page fault at 0xffffffc0004ce414: 0x00000000000065
cpuid = 1
time = 1607915275
KDB: stack backtrace:
#0 0xffffffc00023f2d4 at kdb_backtrace+0x50
Uptime: 2d1h40m41s
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...

From guru at unixarea.de  Tue Dec 15 07:44:15 2020
From: guru at unixarea.de (Matthias Apitz)
Date: Tue, 15 Dec 2020 08:44:11 +0100
Subject: after update to r368166: no sound recording
In-Reply-To: <X9ctZT+0W15EKQFM@c720-r368166.fritz.box>
References: <X9CchZFla3RMFd/3@c720-r368166.fritz.box>
 <72bd5240-3092-bf7b-51aa-2ad12a576efb@selasky.org>
 <X9Crmcsce57g0PER@c720-r368166.fritz.box>
 <4d83e630-7bed-16bd-3422-267813d3e842@selasky.org>
 <X9Mac12Z3u2ZpMOy@c720-r368166.fritz.box>
 <X9ZmGrWrFEqWbhr5@c720-r368166.fritz.box>
 <X9ctZT+0W15EKQFM@c720-r368166.fritz.box>
Message-ID: <X9hpS7fAuuwm990i@c720-r368166.fritz.box>

El d?a lunes, diciembre 14, 2020 a las 10:16:21a. m. +0100, Matthias Apitz escribi?:

> I did a step by step down grading with 'svn up -r..... hdaa.c hdaa.h'
> (only these two files), starting from r368166 down to the following revisions:
> 
> r368166: no recording from pcm1
> 
> r358333: no recording from pcm1
> 
> r350078: no recording from pcm1
> 
> r337043: recording is fine
> 
> I've cc'ed now the commiters of the r358333 and r350078. kaktus@ and sbruno@
> please check the issue https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251727
> and this mail thread in current@

I have nailed down the problem and locally fixed it with this:

# svn diff sys/dev/sound/pci/hda/hdaa.c
Index: sys/dev/sound/pci/hda/hdaa.c
===================================================================
--- sys/dev/sound/pci/hda/hdaa.c	(revisi?n: 368166)
+++ sys/dev/sound/pci/hda/hdaa.c	(copia de trabajo)
@@ -6598,6 +6598,7 @@
 	devinfo->newgpo = -1;
 	callout_init(&devinfo->poll_jack, 1);
 	devinfo->poll_ival = hz;
+	devinfo->init_clear = 1;    /* added by guru at unixarea.de */

 	hdaa_lock(devinfo);
 	res = hda_command(dev,

because there seems to be no code to set devinfo->init_clear from
loader.conf; there is in hdaa.c:

       SYSCTL_ADD_INT(device_get_sysctl_ctx(dev),
            SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO,
            "init_clear", CTLFLAG_RW,
            &devinfo->init_clear, 1,"Clear initial pin widget configuration");

but I don't see any function like hdaa_init_clear_handler() which writes
the value to devinfo->init_clear; 

Am I mistaken?

	matthias


-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

From freebsd at grem.de  Tue Dec 15 08:40:33 2020
From: freebsd at grem.de (Michael Gmelin)
Date: Tue, 15 Dec 2020 09:40:16 +0100
Subject: after update to r368166: no sound recording
In-Reply-To: <X9hpS7fAuuwm990i@c720-r368166.fritz.box>
References: <X9hpS7fAuuwm990i@c720-r368166.fritz.box>
Message-ID: <D7E2EA58-01FF-4E9C-A909-261E5D73E09B@grem.de>



> On 15. Dec 2020, at 08:44, Matthias Apitz <guru at unixarea.de> wrote:
> 
> ?El d?a lunes, diciembre 14, 2020 a las 10:16:21a. m. +0100, Matthias Apitz escribi?:
> 
>> I did a step by step down grading with 'svn up -r..... hdaa.c hdaa.h'
>> (only these two files), starting from r368166 down to the following revisions:
>> 
>> r368166: no recording from pcm1
>> 
>> r358333: no recording from pcm1
>> 
>> r350078: no recording from pcm1
>> 
>> r337043: recording is fine
>> 
>> I've cc'ed now the commiters of the r358333 and r350078. kaktus@ and sbruno@
>> please check the issue https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251727
>> and this mail thread in current@
> 
> I have nailed down the problem and locally fixed it with this:
> 
> # svn diff sys/dev/sound/pci/hda/hdaa.c
> Index: sys/dev/sound/pci/hda/hdaa.c
> ===================================================================
> --- sys/dev/sound/pci/hda/hdaa.c    (revisi?n: 368166)
> +++ sys/dev/sound/pci/hda/hdaa.c    (copia de trabajo)
> @@ -6598,6 +6598,7 @@
>    devinfo->newgpo = -1;
>    callout_init(&devinfo->poll_jack, 1);
>    devinfo->poll_ival = hz;
> +    devinfo->init_clear = 1;    /* added by guru at unixarea.de */
> 
>    hdaa_lock(devinfo);
>    res = hda_command(dev,
> 
> because there seems to be no code to set devinfo->init_clear from
> loader.conf; there is in hdaa.c:
> 
>       SYSCTL_ADD_INT(device_get_sysctl_ctx(dev),
>            SYSCTL_CHILDREN(device_get_sysctl_tree(dev)), OID_AUTO,
>            "init_clear", CTLFLAG_RW,
>            &devinfo->init_clear, 1,"Clear initial pin widget configuration");
> 
> but I don't see any function like hdaa_init_clear_handler() which writes
> the value to devinfo->init_clear; 
> 
> Am I mistaken?
> 
>    matthias
> 
> 

Good catch, I played with the sysctl as well as device.hints, both which didn?t (seem to) make a difference.

-m




> -- 
> Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
> Public GnuPG key: http://www.unixarea.de/key.pub


From Alexander at leidinger.net  Tue Dec 15 10:33:51 2020
From: Alexander at leidinger.net (Alexander Leidinger)
Date: Tue, 15 Dec 2020 11:33:37 +0100
Subject: Identifying broken applications following careless use of make
 -DBATCH_DELETE_OLD_FILES delete-old-libs
In-Reply-To: <2059585148.3686937.1607951705519.JavaMail.zimbra@schweikhardt.net>
References: <20201214093838.Horde.7MCNPdaO93VFac3VZjMk0BW@webmail.leidinger.net>
 <2059585148.3686937.1607951705519.JavaMail.zimbra@schweikhardt.net>
Message-ID: <20201215113337.Horde.l4wQz3q2aWv3qxrbkMGpQOe@webmail.leidinger.net>

Quoting Jens Schweikhardt <schweikh at schweikhardt.net> (from Mon, 14  
Dec 2020 14:15:05 +0100 (CET)):

> Alexander,
>
> it would seem that
>
> find /usr/local/*bin* /usr/local/lib* -type f \
> | xargs ldd -f '%p|%A\n' 2>/dev/null \
> | grep '^not found' | cut -d '|' -f2 \
> | xargs pkg which -q | sort -u
>
> is prone to false positives, since ldd is sensitive to LD_LIBRARY_PATH, viz.:

Yes. Firefox, LibreOffice/OpenOffice come to my mind directly. There  
may be others. I expect those to be rare (compared to the size of the  
ports collection), but if you encounter some false positives, it's  
probably a big package. Either way, "locate $missing_lib" is a good  
idea here.

[...]
> So make sure you look into what exact library is missing and if
> it's actually somewhere "non-standard",
> that directory should be in LD_LIBRARY_PATH.

Temporary for the run of this check, yes.

Bye,
Alexander.

-- 
http://www.Leidinger.net Alexander at Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild at FreeBSD.org  : PGP 0x8F31830F9F2772BF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digitale PGP-Signatur
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20201215/3c5ee31f/attachment.sig>

From oleg at theweb.org.ua  Tue Dec 15 15:16:40 2020
From: oleg at theweb.org.ua (Oleg V. Nauman)
Date: Tue, 15 Dec 2020 17:16:29 +0200
Subject: linker_load_file: /boot/kernel/ipfw.ko - unsupported file type
Message-ID: <2837876.hHqAuc6tWs@sigill.theweb.org.ua>

 

 Hello,


kernel: link_elf_obj: symbol fib6_lookup_rt undefined
kernel: linker_load_file: /boot/kernel/ipfw.ko - unsupported file type

It seems ipf.ko unconditionally perform IPV6 lookup even on system built with  
WITHOUT_INET6=YES defined


FreeBSD 13.0-CURRENT r368604 amd64

Thank you

From debdrup at freebsd.org  Tue Dec 15 00:00:03 2020
From: debdrup at freebsd.org (Daniel Ebdrup Jensen)
Date: Tue, 15 Dec 2020 00:00:00 +0000 (UTC)
Subject: [2 WEEKS LEFT REMINDER] Call for 2020Q4 quarterly status reports
Message-ID: <20201215000001.0789B8266@freefall.freebsd.org>

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is
December, 31st 2021 for work done since the last round of Quarterly Reports:
October 2020 - December 2020.
I would like to remind you that reports are collected during the last
month of every quarter.

Status report submissions do not need to be very long.  They may be
about anything happening in the FreeBSD project and community, and
they provide a great way to inform FreeBSD users and developers about
work that is underway or has been completed. Report submissions are
not limited to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The preferred method is to follow the guidelines at the Quarterly
GitHub repository:

https://github.com/freebsd/freebsd-quarterly

Alternatively you can fetch the Markdown template, fill it in, and
email it to quarterly-submissions at FreeBSD.org.
The template can be found at:

https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.md

We look forward to seeing your 2020Q4 reports!

Thanks,

Daniel Ebdrup Jensen (on behalf of quarterly@)
_______________________________________________
freebsd-quarterly-calls at freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-quarterly-calls
To unsubscribe, send any mail to "freebsd-quarterly-calls-unsubscribe at freebsd.org"

From freqlabs at FreeBSD.org  Tue Dec 15 17:22:35 2020
From: freqlabs at FreeBSD.org (Ryan Moeller)
Date: Tue, 15 Dec 2020 12:22:33 -0500
Subject: usr.bin/xinstall r366697 versus: buildworld: lib/libc: install:
 short write to libc.so.7.debug: [_libinstall] Error code 71
In-Reply-To: <b08bf10e-50f9-79c8-58e3-f46eac1307bd@gmail.com>
References: <746a3af4-3daf-9029-bf48-23efa3f5da8e@gmail.com>
 <37d2a873-8cb9-b858-fa06-4bbfcf006835@gmail.com>
 <1e9e8649-0fe7-4b83-078d-f67908e2f430@gmail.com>
 <40C5DB30-4B7C-4A51-8069-B4E67298C558@FreeBSD.org>
 <9b6bbf0b-93d2-123e-ee5c-f8de660b150a@gmail.com>
 <b08bf10e-50f9-79c8-58e3-f46eac1307bd@gmail.com>
Message-ID: <cb81af02-00cb-a6f8-7ad6-555f5220f468@FreeBSD.org>


On 12/12/20 2:15 AM, Graham Perrin wrote:
> On 23/11/2020 12:18, Graham Perrin wrote:
>
>> On 22/11/2020 12:00, Dimitry Andric wrote:
>>> ?
>>> I'd guess it's an unintended side-effect of
>>> https://svnweb.freebsd.org/base?view=revision&revision=366697
>>> ("install(1): Avoid unncessary fstatfs() calls and use mmap() based on
>>> size").
>>>
>>> If you only revert usr.bin/xinstall to r366696, and then rebuild it,
>>> does it still occur?
>>>
>>> -Dimitry
>>
>> Thank you!
>>
>> Success with r366696:
>>
>> ----
>>
>> ?
>
>
> Re: 
> <https://lists.freebsd.org/pipermail/freebsd-current/2020-November/077634.html> 
> please, should I open a bug for this?
>
>
> Is the issue exposed by my choice of gzip-9 for e.g. /usr/ and if so, 
> can I avoid it by (now) reverting to lz4 for that part, and/or any 
> other part, of the file system?
>
>

Unfortunately I don't have an answer for you at this time, but ACK.


-Ryan


> ----
>
>
> root at mowa219-gjp4-8570p:~ # zfs get mountpoint,compression
> NAME PROPERTY???? VALUE SOURCE
> Transcend mountpoint /Volumes/t500????????????????????????????????? local
> Transcend compression zstd?????????????????????????????????????????? 
> local
> Transcend/VirtualBox mountpoint?? /Volumes/t500/VirtualBox inherited 
> from Transcend
> Transcend/VirtualBox compression? zstd inherited from Transcend
> copperbowl mountpoint /copperbowl??????????????????????????????????? 
> local
> copperbowl compression lz4??????????????????????????????????????????? 
> local
> copperbowl/ROOT mountpoint 
> none?????????????????????????????????????????? local
> copperbowl/ROOT compression? lz4 inherited from copperbowl
> copperbowl/ROOT/Waterfox mountpoint 
> /????????????????????????????????????????????? local
> copperbowl/ROOT/Waterfox compression? lz4 inherited from copperbowl
> copperbowl/ROOT/r367081f mountpoint 
> /????????????????????????????????????????????? local
> copperbowl/ROOT/r367081f compression? lz4 inherited from copperbowl
> copperbowl/ROOT/r367936e mountpoint 
> /????????????????????????????????????????????? local
> copperbowl/ROOT/r367936e compression? lz4 inherited from copperbowl
> copperbowl/ROOT/r367936f mountpoint 
> /????????????????????????????????????????????? local
> copperbowl/ROOT/r367936f compression? lz4 inherited from copperbowl
> copperbowl/ROOT/r367936f at 2020-03-20-06:19:45 mountpoint 
> -????????????????????????????????????????????? -
> copperbowl/ROOT/r367936f at 2020-03-20-06:19:45 compression 
> -????????????????????????????????????????????? -
> copperbowl/ROOT/r367936f at 2020-11-22-23:18:47 mountpoint 
> -????????????????????????????????????????????? -
> copperbowl/ROOT/r367936f at 2020-11-22-23:18:47 compression 
> -????????????????????????????????????????????? -
> copperbowl/ROOT/r367936f at 2020-12-06-16:23:14 mountpoint 
> -????????????????????????????????????????????? -
> copperbowl/ROOT/r367936f at 2020-12-06-16:23:14 compression 
> -????????????????????????????????????????????? -
> copperbowl/VirtualBox mountpoint 
> /usr/local/VirtualBox????????????????????????? local
> copperbowl/VirtualBox compression 
> gzip-9???????????????????????????????????????? local
> copperbowl/iocage mountpoint?? /copperbowl/iocage inherited from 
> copperbowl
> copperbowl/iocage compression 
> gzip-9???????????????????????????????????????? local
> copperbowl/iocage/download mountpoint /copperbowl/iocage/download 
> inherited from copperbowl
> copperbowl/iocage/download compression 
> lz4??????????????????????????????????????????? local
> copperbowl/iocage/download/12.0-RELEASE mountpoint 
> /copperbowl/iocage/download/12.0-RELEASE inherited from copperbowl
> copperbowl/iocage/download/12.0-RELEASE compression 
> lz4??????????????????????????????????????????? local
> copperbowl/iocage/images mountpoint?? /copperbowl/iocage/images 
> inherited from copperbowl
> copperbowl/iocage/images compression 
> lz4??????????????????????????????????????????? local
> copperbowl/iocage/jails mountpoint?? /copperbowl/iocage/jails 
> inherited from copperbowl
> copperbowl/iocage/jails compression 
> lz4??????????????????????????????????????????? local
> copperbowl/iocage/jails/jbrowsers mountpoint 
> /copperbowl/iocage/jails/jbrowsers inherited from copperbowl
> copperbowl/iocage/jails/jbrowsers compression? lz4 inherited from 
> copperbowl/iocage/jails
> copperbowl/iocage/jails/jbrowsers/root mountpoint 
> /copperbowl/iocage/jails/jbrowsers/root inherited from copperbowl
> copperbowl/iocage/jails/jbrowsers/root compression? lz4 inherited from 
> copperbowl/iocage/jails
> copperbowl/iocage/log mountpoint?? /copperbowl/iocage/log inherited 
> from copperbowl
> copperbowl/iocage/log compression 
> lz4??????????????????????????????????????????? local
> copperbowl/iocage/releases mountpoint /copperbowl/iocage/releases 
> inherited from copperbowl
> copperbowl/iocage/releases compression 
> lz4??????????????????????????????????????????? local
> copperbowl/iocage/releases/12.0-RELEASE mountpoint 
> /copperbowl/iocage/releases/12.0-RELEASE inherited from copperbowl
> copperbowl/iocage/releases/12.0-RELEASE compression? lz4 inherited 
> from copperbowl/iocage/releases
> copperbowl/iocage/releases/12.0-RELEASE/root mountpoint 
> /copperbowl/iocage/releases/12.0-RELEASE/root inherited from copperbowl
> copperbowl/iocage/releases/12.0-RELEASE/root compression 
> lz4??????????????????????????????????????????? local
> copperbowl/iocage/releases/12.0-RELEASE/root at jbrowsers mountpoint?? 
> -????????????????????????????????????????????? -
> copperbowl/iocage/releases/12.0-RELEASE/root at jbrowsers compression? 
> -????????????????????????????????????????????? -
> copperbowl/iocage/templates mountpoint /copperbowl/iocage/templates 
> inherited from copperbowl
> copperbowl/iocage/templates compression 
> lz4??????????????????????????????????????????? local
> copperbowl/poudriere mountpoint?? /copperbowl/poudriere inherited from 
> copperbowl
> copperbowl/poudriere compression 
> gzip-9???????????????????????????????????????? local
> copperbowl/poudriere/data mountpoint 
> /usr/local/poudriere/data????????????????????? local
> copperbowl/poudriere/data compression 
> gzip-9???????????????????????????????????????? local
> copperbowl/poudriere/data/.m mountpoint /usr/local/poudriere/data/.m 
> inherited from copperbowl/poudriere/data
> copperbowl/poudriere/data/.m compression? gzip-9 inherited from 
> copperbowl/poudriere/data
> copperbowl/poudriere/data/cache mountpoint 
> /usr/local/poudriere/data/cache inherited from copperbowl/poudriere/data
> copperbowl/poudriere/data/cache compression 
> off??????????????????????????????????????????? local
> copperbowl/poudriere/data/logs mountpoint 
> /usr/local/poudriere/data/logs inherited from copperbowl/poudriere/data
> copperbowl/poudriere/data/logs compression 
> gzip-9???????????????????????????????????????? local
> copperbowl/poudriere/data/packages mountpoint 
> /usr/local/poudriere/data/packages inherited from 
> copperbowl/poudriere/data
> copperbowl/poudriere/data/packages compression 
> off??????????????????????????????????????????? local
> copperbowl/poudriere/data/wrkdirs mountpoint 
> /usr/local/poudriere/data/wrkdirs inherited from 
> copperbowl/poudriere/data
> copperbowl/poudriere/data/wrkdirs compression 
> off??????????????????????????????????????????? local
> copperbowl/poudriere/jails mountpoint /copperbowl/poudriere/jails 
> inherited from copperbowl
> copperbowl/poudriere/jails compression 
> gzip-9???????????????????????????????????????? local
> copperbowl/poudriere/jails/head mountpoint 
> /usr/local/poudriere/jails/head??????????????? local
> copperbowl/poudriere/jails/head compression 
> gzip-9???????????????????????????????????????? local
> copperbowl/poudriere/jails/head at clean mountpoint 
> -????????????????????????????????????????????? -
> copperbowl/poudriere/jails/head at clean compression 
> -????????????????????????????????????????????? -
> copperbowl/poudriere/ports mountpoint /copperbowl/poudriere/ports 
> inherited from copperbowl
> copperbowl/poudriere/ports compression? gzip-9 inherited from 
> copperbowl/poudriere
> copperbowl/poudriere/ports/default mountpoint 
> /usr/local/poudriere/ports/default???????????? local
> copperbowl/poudriere/ports/default compression 
> gzip-9???????????????????????????????????????? local
> copperbowl/poudriere/ports/freebsd-ports-kde mountpoint 
> /usr/local/poudriere/ports/freebsd-ports-kde?? local
> copperbowl/poudriere/ports/freebsd-ports-kde compression 
> gzip-9???????????????????????????????????????? local
> copperbowl/tmp mountpoint 
> /tmp?????????????????????????????????????????? local
> copperbowl/tmp compression 
> off??????????????????????????????????????????? local
> copperbowl/usr mountpoint 
> /usr?????????????????????????????????????????? local
> copperbowl/usr compression 
> gzip-9???????????????????????????????????????? local
> copperbowl/usr/home mountpoint?? /usr/home inherited from copperbowl/usr
> copperbowl/usr/home compression 
> lz4??????????????????????????????????????????? local
> copperbowl/usr/home at 2020-09-19-20:29-r365364 mountpoint 
> -????????????????????????????????????????????? -
> copperbowl/usr/home at 2020-09-19-20:29-r365364 compression 
> -????????????????????????????????????????????? -
> copperbowl/usr/ports mountpoint?? /usr/ports inherited from 
> copperbowl/usr
> copperbowl/usr/ports compression? gzip-9 inherited from copperbowl/usr
> copperbowl/usr/src mountpoint?? /usr/src inherited from copperbowl/usr
> copperbowl/usr/src compression? gzip-9 inherited from copperbowl/usr
> copperbowl/var mountpoint 
> /var?????????????????????????????????????????? local
> copperbowl/var compression? lz4 inherited from copperbowl
> copperbowl/var/audit mountpoint?? /var/audit inherited from 
> copperbowl/var
> copperbowl/var/audit compression? lz4 inherited from copperbowl
> copperbowl/var/crash mountpoint?? /var/crash inherited from 
> copperbowl/var
> copperbowl/var/crash compression? lz4 inherited from copperbowl
> copperbowl/var/log mountpoint?? /var/log inherited from copperbowl/var
> copperbowl/var/log compression? lz4 inherited from copperbowl
> copperbowl/var/mail mountpoint?? /var/mail inherited from copperbowl/var
> copperbowl/var/mail compression? lz4 inherited from copperbowl
> copperbowl/var/tmp mountpoint?? /var/tmp inherited from copperbowl/var
> copperbowl/var/tmp compression? lz4 inherited from copperbowl
> copperbowl/vm-bhyve mountpoint?? /copperbowl/vm-bhyve inherited from 
> copperbowl
> copperbowl/vm-bhyve compression? gzip-9
>
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to 
> "freebsd-current-unsubscribe at freebsd.org"

From melifaro at ipfw.ru  Tue Dec 15 20:42:16 2020
From: melifaro at ipfw.ru (Alexander V. Chernikov)
Date: Tue, 15 Dec 2020 20:42:10 +0000
Subject: linker_load_file: /boot/kernel/ipfw.ko - unsupported file type
In-Reply-To: <2837876.hHqAuc6tWs@sigill.theweb.org.ua>
References: <2837876.hHqAuc6tWs@sigill.theweb.org.ua>
Message-ID: <113391608064889@mail.yandex.ru>

15.12.2020, 15:17, "Oleg V. Nauman" <oleg at theweb.org.ua>:
> ?Hello,
>
> kernel: link_elf_obj: symbol fib6_lookup_rt undefined
> kernel: linker_load_file: /boot/kernel/ipfw.ko - unsupported file type
>
> It seems ipf.ko unconditionally perform IPV6 lookup even on system built with
> WITHOUT_INET6=YES defined
Should be fixed in r368651.
> FreeBSD 13.0-CURRENT r368604 amd64
>
> Thank you
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"

From grahamperrin at gmail.com  Wed Dec 16 03:18:46 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Wed, 16 Dec 2020 03:18:41 +0000
Subject: Identifying broken applications following careless use of make
 -DBATCH_DELETE_OLD_FILES delete-old-libs
In-Reply-To: <X9dmt5AnTW1cWOr/@albert.catwhisker.org>
References: <20201214093838.Horde.7MCNPdaO93VFac3VZjMk0BW@webmail.leidinger.net>
 <2059585148.3686937.1607951705519.JavaMail.zimbra@schweikhardt.net>
 <X9dmt5AnTW1cWOr/@albert.catwhisker.org>
Message-ID: <618dadb1-43d1-ed39-cac9-66c8ea8b7455@gmail.com>

On 14/12/2020 13:20, David Wolfskill wrote:
> I find that "pkg_libchk" (from ports-mgmt/bsdadminscripts2) is helpful
> for such cases.
>
> Peace,
> david

Thanks for this, and for the answers from other users.

Ultimately I chose to:

pkg upgrade -f

pkg upgrade -f -r poudriere

The second command was probably to broad. In retrospect I could have 
forced just three from my poudriere repo:

drm-kmod
gpu-firmware-kmod
openzfs-kmod

As far as I can tell, just one casualty: SimpleScreenRecorder, which 
does record and save, but fails to cancel (before beginning a recording) 
or close (after saving a recording); it stops responding.

I'm now building multimedia/simplescreenrecorder with poudriere, if 
installation from this repo does not resolve the issue then I might 
repeat 'pkg upgrade -f' alone plus just the three kmods from poudriere.

(Afterthought, note to self: maybe SimpleScreenRecorder is a casualty of 
a routine upgrade that I performed a few hours earlier; there was much 
KDE stuff at the time.)


From grahamperrin at gmail.com  Wed Dec 16 03:33:58 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Wed, 16 Dec 2020 03:33:54 +0000
Subject: sysutils/openzfs-kmod installed from poudriere repo but not
 recognised as a non-automatic package
Message-ID: <3f9072e5-df01-6ebc-efb6-e0fbc6600084@gmail.com>

Do I misunderstand something below?

root at mowa219-gjp4-8570p:~ # pkg query '%o %R' | grep poudriere | grep 
zfs | sort
sysutils/openzfs-kmod poudriere
root at mowa219-gjp4-8570p:~ # pkg query -e '%a = 0' '%o %R' | grep 
poudriere | sort
archivers/zip poudriere
devel/autoconf poudriere
devel/ccache poudriere
devel/cmake poudriere
devel/gmake poudriere
graphics/drm-kmod poudriere
graphics/gpu-firmware-kmod poudriere
ports-mgmt/pkg poudriere
ports-mgmt/poudriere-devel FreeBSD
textproc/groff poudriere
root at mowa219-gjp4-8570p:~ # pkg info openzfs-kmod
openzfs-kmod-2020120100
Name?????????? : openzfs-kmod
Version??????? : 2020120100
Installed on?? : Tue Dec 15 19:59:00 2020 GMT
Origin???????? : sysutils/openzfs-kmod
Architecture?? : FreeBSD:13:amd64
Prefix???????? : /usr/local
Categories???? : sysutils kld
Licenses?????? : CDDL
Maintainer???? : freqlabs at FreeBSD.org
WWW??????????? : https://github.com/zfsonfreebsd/ZoF
Comment??????? : OpenZFS kernel module for FreeBSD
Options??????? :
 ??????? DEBUG????????? : off
 ??????? GCOV?????????? : off
 ??????? INVARIANTS???? : off
Annotations??? :
 ??????? FreeBSD_version: 1300131
 ??????? repo_type????? : binary
 ??????? repository???? : poudriere
Flat size????? : 4.99MiB
Description??? :
Kernel module for OpenZFS on FreeBSD

WWW: https://github.com/zfsonfreebsd/ZoF
root at mowa219-gjp4-8570p:~ #


From grahamperrin at gmail.com  Wed Dec 16 06:22:11 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Wed, 16 Dec 2020 06:22:07 +0000
Subject: sysutils/openzfs-kmod installed from poudriere repo but not
 recognised as a non-automatic package
In-Reply-To: <3f9072e5-df01-6ebc-efb6-e0fbc6600084@gmail.com>
References: <3f9072e5-df01-6ebc-efb6-e0fbc6600084@gmail.com>
Message-ID: <3da67c33-c62d-5dca-8fcf-f2e00436f237@gmail.com>

On 16/12/2020 03:33, Graham Perrin wrote:
> Do I misunderstand something below?
>
> root at mowa219-gjp4-8570p:~ # pkg query '%o %R' | grep poudriere | grep 
> zfs | sort
> sysutils/openzfs-kmod poudriere
> root at mowa219-gjp4-8570p:~ # pkg query -e '%a = 0' '%o %R' | grep 
> poudriere | sort
> archivers/zip poudriere
> devel/autoconf poudriere
> devel/ccache poudriere
> devel/cmake poudriere
> devel/gmake poudriere
> graphics/drm-kmod poudriere
> graphics/gpu-firmware-kmod poudriere
> ports-mgmt/pkg poudriere
> ports-mgmt/poudriere-devel FreeBSD
> textproc/groff poudriere
> root at mowa219-gjp4-8570p:~ # pkg info openzfs-kmod
> openzfs-kmod-2020120100
> Name?????????? : openzfs-kmod
> Version??????? : 2020120100
> Installed on?? : Tue Dec 15 19:59:00 2020 GMT
> Origin???????? : sysutils/openzfs-kmod
> Architecture?? : FreeBSD:13:amd64
> Prefix???????? : /usr/local
> Categories???? : sysutils kld
> Licenses?????? : CDDL
> Maintainer???? : freqlabs at FreeBSD.org
> WWW??????????? : https://github.com/zfsonfreebsd/ZoF
> Comment??????? : OpenZFS kernel module for FreeBSD
> Options??????? :
> ??????? DEBUG????????? : off
> ??????? GCOV?????????? : off
> ??????? INVARIANTS???? : off
> Annotations??? :
> ??????? FreeBSD_version: 1300131
> ??????? repo_type????? : binary
> ??????? repository???? : poudriere
> Flat size????? : 4.99MiB
> Description??? :
> Kernel module for OpenZFS on FreeBSD
>
> WWW: https://github.com/zfsonfreebsd/ZoF
> root at mowa219-gjp4-8570p:~ #
>

I realise my mistake, hopefully:

root at mowa219-gjp4-8570p:~ # pkg query -e '%a = 0' '%o %R' | grep zfs | sort
sysutils/openzfs FreeBSD
sysutils/zfs-snap-diff FreeBSD
sysutils/zfs-stats FreeBSD
root at mowa219-gjp4-8570p:~ # pkg query -e '%a = 1' '%o %R' | grep zfs | sort
sysutils/openzfs-kmod poudriere
root at mowa219-gjp4-8570p:~ #

Originally, openzfs-kmod was automated through my _installation_ of 
openzfs from the FreeBSD repo.

I subsequently chose to _upgrade_ (not install) openzfs-kmod from my 
poudriere repo, i.e.

pkg upgrade -f -r poudriere sysutils/openzfs-kmod


From freqlabs at FreeBSD.org  Wed Dec 16 15:31:02 2020
From: freqlabs at FreeBSD.org (Ryan Moeller)
Date: Wed, 16 Dec 2020 10:31:01 -0500
Subject: (239489) buildkernel fails if PORTS_MODULES= includes openzfs-kmod
In-Reply-To: <X9ZOdSDF7uuGRizQ@phouka1.phouka.net>
References: <7fe2fe36-a342-e863-a63e-47f6890f8220@gmail.com>
 <X9ZOdSDF7uuGRizQ@phouka1.phouka.net>
Message-ID: <f35a527c-2cd0-b2cc-1df5-424aa3ac28a4@FreeBSD.org>


On 12/13/20 12:25 PM, John Kennedy wrote:
> On Sun, Dec 13, 2020 at 08:19:30AM +0000, Graham Perrin wrote:
>> Please: is there some way to include openzfs-kmod at buildkernel time?


Not that I'm aware of, but you can write a script to build your system 
the way you like it and then build the kmod, clone a BE, etc, so you 
don't forget anything.


>> To work around
>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239489> I habitually
>> remove openzfs-kmod from /etc/src.conf _and_ modify /boot/loader.conf
>> before performing the build:
>>
>> zfs_load="YES"
>> openzfs_load="NO"
> Isn't openzfs-kmod on 13-CURRENT more or less moot since r36474, the OpenZFS
> merge, ~2020/8/25?  That ticket was opened on 2019/7/28, pre-merge.


The port tracks the openzfs/zfs master branch while the base system 
tracks the zfs-2.0-release branch. However, that is planned to switch to 
master once base makes the transition to git.


> Now, I still see recent updates on openzfs-kmod port so the question might
> still be relevant for non-13 or if you're just using the port for reasons or
> anywhere older than 13 (12.2, etc).


If the newer features in master (eg draid) aren't needed, the base zfs 
is at least less likely to break from kernel changes that haven't been 
coordinated well with the openzfs upstream and the port, which does 
happen from time to time.


-Ryan


From imp at bsdimp.com  Thu Dec 17 00:46:48 2020
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 16 Dec 2020 17:46:35 -0700
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
Message-ID: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>

Greetings,

The FreeBSD project will be moving it's source repo from subversion to git
starting this this weekend. The docs repo was moved 2 weeks ago. The ports
repo will move at the end of March, 2021 due to timing issues.

The short version is that we're switching the version control we're using.
This switch will preserve much of the current FreeBSD development workflow.
After the switch, the subversion repo will become almost read-only. All
future work will be done in git, however as a transition aide we'll be
replaying the MFCs to stable/11, stable/12 and the related releng branches
for the life of those branches.

For more detailed information, please see
https://github.com/bsdimp/freebsd-git-docs/ for the current documentation.

Please see https://wiki.freebsd.org/git for the latest detailed schedule
(please note that this schedule is subject to change).

Warner

From yuripv at yuripv.dev  Thu Dec 17 05:11:09 2020
From: yuripv at yuripv.dev (Yuri Pankov)
Date: Thu, 17 Dec 2020 08:02:44 +0300
Subject: installation on pvscsi fails with "The request was too large for this
 host"
Message-ID: <fc910f87-ba02-9e20-213e-40828da72670@yuripv.dev>

Trying to install latest snapshot (20201210) on a VMware 
ESXi/Workstation VMs with pvscsi fails on bootloader step, and the 
following is in dmesg:

pvscsi0: pvscsi_execute_ccb error 27
pvscsi0: pvscsi_execute_ccb error 27
(da0:pvscsi0:0:0:0): WRITE(10). CDB: 2a 00 00 00 00 28 00 04 00
(da0:pvscsi0:0:0:0): CAM status: The request was too large for this host
(da0:pvscsi0:0:0:0): Error 22, Unretryable error
(da0:pvscsi0:0:0:0): WRITE(10). CDB: 2a 00 00 00 00 28 00 04 00
(da0:pvscsi0:0:0:0): CAM status: The request was too large for this host
(da0:pvscsi0:0:0:0): Error 22, Unretryable error

That is the first I'm trying installing on pvscsi since it was 
integrated, so no idea if it worked previously.  If yes, I have not 
tried to bisect this yet hoping that it could be identified as related 
to any of the recent changes.

The VMs in question are set with 8-64 GB RAM, and 100 GB boot disks.

From yuripv at yuripv.dev  Thu Dec 17 08:24:42 2020
From: yuripv at yuripv.dev (Yuri Pankov)
Date: Thu, 17 Dec 2020 11:24:38 +0300
Subject: acpi_wmi noisy without EC
In-Reply-To: <dcf1cdb9-e79a-469a-99bc-cdb336352c17@www.fastmail.com>
References: <7dc142d3-1e0b-41d4-bdb4-7217bd09bbef@www.fastmail.com>
 <7b80877ae59fdd90f2f3b5dbf3db2113@kondratyev.su>
 <fb0874b1cf4510a2d797a83a01d55935@kondratyev.su>
 <5bb9ac64-ebab-4d22-8a43-1305b16f28cd@www.fastmail.com>
 <274d456e15ce621889bfe9e7eda190da@kondratyev.su>
 <dcf1cdb9-e79a-469a-99bc-cdb336352c17@www.fastmail.com>
Message-ID: <b68cc59a-5d15-9952-b631-e366b9c05648@yuripv.dev>

Yuri Pankov wrote:
> On Tue, Nov 17, 2020, at 4:00 PM, Vladimir Kondratyev wrote:
>> On 2020-11-17 15:29, Yuri Pankov wrote:
>>> On Tue, Nov 17, 2020, at 11:07 AM, Vladimir Kondratyev wrote:
>>>> On 2020-11-17 10:57, Vladimir Kondratyev wrote:
>>>>> On 2020-11-17 03:00, Yuri Pankov wrote:
>>>>>> I have started seeing the following on boot since some time:
>>>>>>
>>>>>> acpi_wmi0: <ACPI-WMI mapping> on acpi0
>>>>>> acpi_wmi0: cannot find EC device
>>>>>> device_attach: acpi_wmi0 attach returned 6
>>>>>> acpi_wmi0: <ACPI-WMI mapping> on acpi0
>>>>>> acpi_wmi0: cannot find EC device
>>>>>> device_attach: acpi_wmi0 attach returned 6
>>>>>> acpi_wmi0: <ACPI-WMI mapping> on acpi0
>>>>>> acpi_wmi0: cannot find EC device
>>>>>> device_attach: acpi_wmi0 attach returned 6
>>>>>> acpi_wmi0: <ACPI-WMI mapping> on acpi0
>>>>>> acpi_wmi0: cannot find EC device
>>>>>> device_attach: acpi_wmi0 attach returned 6
>>>>>>
>>>>>> Likely following this commit:
>>>>>>
>>>>>> commit 708d048ccfdacf6199cc08a56aa05a9c899441fd
>>>>>> Author: Vladimir Kondratyev <wulf at FreeBSD.org>
>>>>>> Date:   Sat Oct 31 22:19:39 2020 +0000
>>>>>>
>>>>>>      acpi_wmi(4): Add ACPI_PNP_INFO
>>>>>>
>>>>>> While the reason is obvious -- there's no EC in this system (Gigabyte
>>>>>> X299X AORUS MASTER desktop motherboard), at least searching the
>>>>>> `acpidump -dt` output doesn't show any PNP0C09 entries -- it certainly
>>>>>> looks like "something is broken" when first noticed.  I wonder if we
>>>>>> could/should handle this gracefully -- no EC, do nothing, simply exit?
>>>>>
>>>>> Following patch should ignore missing EC like Linux does. Could you
>>>>> test it?
>>>>>
>>>>> diff --git a/sys/dev/acpi_support/acpi_wmi.c
>>>>> b/sys/dev/acpi_support/acpi_wmi.c
>>>>> index 379cfd1705f1..efae96cdcc9a 100644
>>>>> --- a/sys/dev/acpi_support/acpi_wmi.c
>>>>> +++ b/sys/dev/acpi_support/acpi_wmi.c
>>>>> @@ -246,7 +246,7 @@ acpi_wmi_attach(device_t dev)
>>>>>   if ((sc->ec_dev = devclass_get_device(devclass_find("acpi_ec"), 0))
>>>>>       == NULL)
>>>>>   device_printf(dev, "cannot find EC device\n");
>>>>> - else if (ACPI_FAILURE((status =
>>>>> AcpiInstallNotifyHandler(sc->wmi_handle,
>>>>> + if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
>>>>>       ACPI_DEVICE_NOTIFY, acpi_wmi_notify_handler, sc))))
>>>>>   device_printf(sc->wmi_dev, "couldn't install notify handler - %s\n",
>>>>>       AcpiFormatException(status));
>>>>> @@ -701,6 +701,8 @@ acpi_wmi_ec_handler(UINT32 function,
>>>>> ACPI_PHYSICAL_ADDRESS address,
>>>>>   return (AE_BAD_PARAMETER);
>>>>>   if (address + (width / 8) - 1 > 0xFF)
>>>>>   return (AE_BAD_ADDRESS);
>>>>> + if (sc->ec_dev == NULL)
>>>>> + return (AE_NOT_FOUND);
>>>>>   if (function == ACPI_READ)
>>>>>   *value = 0;
>>>>>   ec_addr = address;
>>>>
>>>> @#@##! Web client ate all the tabs.
>>>>
>>>> Patch is in attachment.
>>>
>>> Output changed, though it's still somewhat noisy -- I guess there
>>> isn't a way to NOT report the device that we are not going to attach
>>> to, or do that e.g. only for verbose boot?
>>>
>>> acpi_wmi0: <ACPI-WMI mapping> on acpi0
>>> acpi_wmi0: cannot find EC device
>>> acpi_wmi0: Embedded MOF found
>>> ACPI: \134GSA1.WQCC: 1 arguments were passed to a non-method ACPI
>>> object (Buffer) (20201113/nsarguments-361)
>>> acpi_wmi1: <ACPI-WMI mapping> on acpi0
>>> acpi_wmi1: cannot find EC device
>>> acpi_wmi2: <ACPI-WMI mapping> on acpi0
>>> acpi_wmi2: cannot find EC device
>>> acpi_wmi3: <ACPI-WMI mapping> on acpi0
>>> acpi_wmi3: cannot find EC device
>>
>> acpi_wmi does not try to attach to EC node (PNP0C09). It only queries it
>> in OpRegion handler.
>> WMI's _HID/_CID is PNP0C14. According to your output, acpi_wmi has
>> successfully attached to 4 nodes.
> 
> Oh great, I misunderstood then.  And indeed, sysctl -b dev.acpi_wmi.0.bmof | bmf2mof provides some interesting information.  All other 3 instances do not though.  In any case, it seems to work now.
> 
>> Verbosity can be reduced with attached patch if current level is too
>> high for you.
> 
> Works for me both ways, I simply had the wrong impression that if we don't have EC, we can't attach at all.

Could you commit this, or is it incomplete fix?

From avg at FreeBSD.org  Thu Dec 17 09:20:10 2020
From: avg at FreeBSD.org (Andriy Gapon)
Date: Thu, 17 Dec 2020 11:20:05 +0200
Subject: installation on pvscsi fails with "The request was too large for
 this host"
In-Reply-To: <fc910f87-ba02-9e20-213e-40828da72670@yuripv.dev>
References: <fc910f87-ba02-9e20-213e-40828da72670@yuripv.dev>
Message-ID: <bca69f61-f7a6-2817-c7cd-13b248496d37@FreeBSD.org>

On 17/12/2020 07:02, Yuri Pankov wrote:
> Trying to install latest snapshot (20201210) on a VMware ESXi/Workstation VMs
> with pvscsi fails on bootloader step, and the following is in dmesg:
> 
> pvscsi0: pvscsi_execute_ccb error 27
> pvscsi0: pvscsi_execute_ccb error 27
> (da0:pvscsi0:0:0:0): WRITE(10). CDB: 2a 00 00 00 00 28 00 04 00
> (da0:pvscsi0:0:0:0): CAM status: The request was too large for this host
> (da0:pvscsi0:0:0:0): Error 22, Unretryable error
> (da0:pvscsi0:0:0:0): WRITE(10). CDB: 2a 00 00 00 00 28 00 04 00
> (da0:pvscsi0:0:0:0): CAM status: The request was too large for this host
> (da0:pvscsi0:0:0:0): Error 22, Unretryable error
> 
> That is the first I'm trying installing on pvscsi since it was integrated, so no
> idea if it worked previously.? If yes, I have not tried to bisect this yet
> hoping that it could be identified as related to any of the recent changes.
> 
> The VMs in question are set with 8-64 GB RAM, and 100 GB boot disks.

Not an expert in this areas, but that command tried to transfer 0x400 / 1024
blocks, which is 512KB of data.
Could it be that the problem is revealed by the MAXPHYS increase?
There might be a bug in pvscsi where it does not respect or correctly advertise
some limit.  There could be a similar issue with VMware itself (its emulation of
a disk / target).


-- 
Andriy Gapon

From vladimir at kondratyev.su  Thu Dec 17 09:42:08 2020
From: vladimir at kondratyev.su (Vladimir Kondratyev)
Date: Thu, 17 Dec 2020 12:41:19 +0300
Subject: acpi_wmi noisy without EC
In-Reply-To: <b68cc59a-5d15-9952-b631-e366b9c05648@yuripv.dev>
References: <7dc142d3-1e0b-41d4-bdb4-7217bd09bbef@www.fastmail.com>
 <7b80877ae59fdd90f2f3b5dbf3db2113@kondratyev.su>
 <fb0874b1cf4510a2d797a83a01d55935@kondratyev.su>
 <5bb9ac64-ebab-4d22-8a43-1305b16f28cd@www.fastmail.com>
 <274d456e15ce621889bfe9e7eda190da@kondratyev.su>
 <dcf1cdb9-e79a-469a-99bc-cdb336352c17@www.fastmail.com>
 <b68cc59a-5d15-9952-b631-e366b9c05648@yuripv.dev>
Message-ID: <b1faa960-a5e4-12e5-4d51-458092ee2d70@kondratyev.su>

On 17.12.2020 11:24, Yuri Pankov wrote:
> Yuri Pankov wrote:
>> On Tue, Nov 17, 2020, at 4:00 PM, Vladimir Kondratyev wrote:
>>> On 2020-11-17 15:29, Yuri Pankov wrote:
>>>> On Tue, Nov 17, 2020, at 11:07 AM, Vladimir Kondratyev wrote:
>>>>> On 2020-11-17 10:57, Vladimir Kondratyev wrote:
>>>>>> On 2020-11-17 03:00, Yuri Pankov wrote:
>>>>>>> I have started seeing the following on boot since some time:
>>>>>>>
>>>>>>> acpi_wmi0: <ACPI-WMI mapping> on acpi0
>>>>>>> acpi_wmi0: cannot find EC device
>>>>>>> device_attach: acpi_wmi0 attach returned 6
>>>>>>> acpi_wmi0: <ACPI-WMI mapping> on acpi0
>>>>>>> acpi_wmi0: cannot find EC device
>>>>>>> device_attach: acpi_wmi0 attach returned 6
>>>>>>> acpi_wmi0: <ACPI-WMI mapping> on acpi0
>>>>>>> acpi_wmi0: cannot find EC device
>>>>>>> device_attach: acpi_wmi0 attach returned 6
>>>>>>> acpi_wmi0: <ACPI-WMI mapping> on acpi0
>>>>>>> acpi_wmi0: cannot find EC device
>>>>>>> device_attach: acpi_wmi0 attach returned 6
>>>>>>>
>>>>>>> Likely following this commit:
>>>>>>>
>>>>>>> commit 708d048ccfdacf6199cc08a56aa05a9c899441fd
>>>>>>> Author: Vladimir Kondratyev <wulf at FreeBSD.org>
>>>>>>> Date:?? Sat Oct 31 22:19:39 2020 +0000
>>>>>>>
>>>>>>> ???? acpi_wmi(4): Add ACPI_PNP_INFO
>>>>>>>
>>>>>>> While the reason is obvious -- there's no EC in this system
>>>>>>> (Gigabyte
>>>>>>> X299X AORUS MASTER desktop motherboard), at least searching the
>>>>>>> `acpidump -dt` output doesn't show any PNP0C09 entries -- it
>>>>>>> certainly
>>>>>>> looks like "something is broken" when first noticed.? I wonder if we
>>>>>>> could/should handle this gracefully -- no EC, do nothing, simply
>>>>>>> exit?
>>>>>>
>>>>>> Following patch should ignore missing EC like Linux does. Could you
>>>>>> test it?
>>>>>>
>>>>>> diff --git a/sys/dev/acpi_support/acpi_wmi.c
>>>>>> b/sys/dev/acpi_support/acpi_wmi.c
>>>>>> index 379cfd1705f1..efae96cdcc9a 100644
>>>>>> --- a/sys/dev/acpi_support/acpi_wmi.c
>>>>>> +++ b/sys/dev/acpi_support/acpi_wmi.c
>>>>>> @@ -246,7 +246,7 @@ acpi_wmi_attach(device_t dev)
>>>>>> ? if ((sc->ec_dev = devclass_get_device(devclass_find("acpi_ec"), 0))
>>>>>> ????? == NULL)
>>>>>> ? device_printf(dev, "cannot find EC device\n");
>>>>>> - else if (ACPI_FAILURE((status =
>>>>>> AcpiInstallNotifyHandler(sc->wmi_handle,
>>>>>> + if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
>>>>>> ????? ACPI_DEVICE_NOTIFY, acpi_wmi_notify_handler, sc))))
>>>>>> ? device_printf(sc->wmi_dev, "couldn't install notify handler -
>>>>>> %s\n",
>>>>>> ????? AcpiFormatException(status));
>>>>>> @@ -701,6 +701,8 @@ acpi_wmi_ec_handler(UINT32 function,
>>>>>> ACPI_PHYSICAL_ADDRESS address,
>>>>>> ? return (AE_BAD_PARAMETER);
>>>>>> ? if (address + (width / 8) - 1 > 0xFF)
>>>>>> ? return (AE_BAD_ADDRESS);
>>>>>> + if (sc->ec_dev == NULL)
>>>>>> + return (AE_NOT_FOUND);
>>>>>> ? if (function == ACPI_READ)
>>>>>> ? *value = 0;
>>>>>> ? ec_addr = address;
>>>>>
>>>>> @#@##! Web client ate all the tabs.
>>>>>
>>>>> Patch is in attachment.
>>>>
>>>> Output changed, though it's still somewhat noisy -- I guess there
>>>> isn't a way to NOT report the device that we are not going to attach
>>>> to, or do that e.g. only for verbose boot?
>>>>
>>>> acpi_wmi0: <ACPI-WMI mapping> on acpi0
>>>> acpi_wmi0: cannot find EC device
>>>> acpi_wmi0: Embedded MOF found
>>>> ACPI: \134GSA1.WQCC: 1 arguments were passed to a non-method ACPI
>>>> object (Buffer) (20201113/nsarguments-361)
>>>> acpi_wmi1: <ACPI-WMI mapping> on acpi0
>>>> acpi_wmi1: cannot find EC device
>>>> acpi_wmi2: <ACPI-WMI mapping> on acpi0
>>>> acpi_wmi2: cannot find EC device
>>>> acpi_wmi3: <ACPI-WMI mapping> on acpi0
>>>> acpi_wmi3: cannot find EC device
>>>
>>> acpi_wmi does not try to attach to EC node (PNP0C09). It only queries it
>>> in OpRegion handler.
>>> WMI's _HID/_CID is PNP0C14. According to your output, acpi_wmi has
>>> successfully attached to 4 nodes.
>>
>> Oh great, I misunderstood then.? And indeed, sysctl -b
>> dev.acpi_wmi.0.bmof | bmf2mof provides some interesting information.?
>> All other 3 instances do not though.? In any case, it seems to work now.
>>
>>> Verbosity can be reduced with attached patch if current level is too
>>> high for you.
>>
>> Works for me both ways, I simply had the wrong impression that if we
>> don't have EC, we can't attach at all.
> 
> Could you commit this, or is it incomplete fix?

I did some tests with ACER ACPI extras which left functional after
OPregion handler had been disabled, so I think, fix is complete.

I have created a phabricator review: https://reviews.freebsd.org/D27653

From yuripv at yuripv.dev  Thu Dec 17 14:40:22 2020
From: yuripv at yuripv.dev (Yuri Pankov)
Date: Thu, 17 Dec 2020 17:40:16 +0300
Subject: installation on pvscsi fails with "The request was too large for
 this host"
In-Reply-To: <bca69f61-f7a6-2817-c7cd-13b248496d37@FreeBSD.org>
References: <fc910f87-ba02-9e20-213e-40828da72670@yuripv.dev>
 <bca69f61-f7a6-2817-c7cd-13b248496d37@FreeBSD.org>
Message-ID: <e7372eda-4b23-e4e1-c912-584d63b75888@yuripv.dev>

Andriy Gapon wrote:
> On 17/12/2020 07:02, Yuri Pankov wrote:
>> Trying to install latest snapshot (20201210) on a VMware ESXi/Workstation VMs
>> with pvscsi fails on bootloader step, and the following is in dmesg:
>>
>> pvscsi0: pvscsi_execute_ccb error 27
>> pvscsi0: pvscsi_execute_ccb error 27
>> (da0:pvscsi0:0:0:0): WRITE(10). CDB: 2a 00 00 00 00 28 00 04 00
>> (da0:pvscsi0:0:0:0): CAM status: The request was too large for this host
>> (da0:pvscsi0:0:0:0): Error 22, Unretryable error
>> (da0:pvscsi0:0:0:0): WRITE(10). CDB: 2a 00 00 00 00 28 00 04 00
>> (da0:pvscsi0:0:0:0): CAM status: The request was too large for this host
>> (da0:pvscsi0:0:0:0): Error 22, Unretryable error
>>
>> That is the first I'm trying installing on pvscsi since it was integrated, so no
>> idea if it worked previously.? If yes, I have not tried to bisect this yet
>> hoping that it could be identified as related to any of the recent changes.
>>
>> The VMs in question are set with 8-64 GB RAM, and 100 GB boot disks.
> 
> Not an expert in this areas, but that command tried to transfer 0x400 / 1024
> blocks, which is 512KB of data.
> Could it be that the problem is revealed by the MAXPHYS increase?
> There might be a bug in pvscsi where it does not respect or correctly advertise
> some limit.  There could be a similar issue with VMware itself (its emulation of
> a disk / target).

Yes, it looks like reverting MAXPHYS back to 128K made the problem 
disappear, successfully installed VM from resulting cdrom image.

From ohartmann at walstatt.org  Thu Dec 17 18:20:58 2020
From: ohartmann at walstatt.org (Hartmann, O.)
Date: Thu, 17 Dec 2020 19:20:29 +0100
Subject: AMNESIA:33 and FreeBSD TCP/IP stack involvement
In-Reply-To: <20201210200250.GJ31099@funkthat.com>
References: <20201209065849.47a51561@hermann.fritz.box>
 <20201210200250.GJ31099@funkthat.com>
Message-ID: <20201217192029.56f3d262@hermann.fritz.box>



> Hartmann, O. wrote this message on Wed, Dec 09, 2020 at 06:58 +0100:
> > I've got a question about recently discovered serious
> > vulnerabilities in certain TCP stack implementations, designated as
> > AMNESIA:33 (as far as I could follow the recently made
> > announcements and statements, please see, for instance,
> > https://www.zdnet.com/article/amnesia33-vulnerabilities-impact-millions-of-smart-and-industrial-devices/).
> > 
> > All mentioned open-source TCP stacks seem not to be related in any
> > way with freeBSD or any derivative of the FreeBSD project, but I do
> > not dare to make a statement about that.
> > 
> > My question is very simple and aimes towards calming down my
> > employees requests: is FreeBSD potentially vulnerable to this newly
> > discovered flaw (we use mainly 12.1-RELENG, 12.2-RELENG, 12-STABLE
> > and 13-CURRENT, latest incarnations, of course, should be least
> > vulnerable ...).  
> 
> I'd be surprised if FreeBSD is vulnerable to those flaws, but I cannot
> make any official statement as there are too many to even start to
> investigate them.
> 
> Also of note is that there were three other IP stacks that were NOT
> vulnerable to ANY new security issues in that report as well, so it
> isn't like the report found security vulnerability in every TCP/IP
> stack they tested.
> 
> The best way to have confidence is to pay people to analyize and
> verify that the FreeBSD TCP/IP stack is secure, just as it is w/
> any critical code that a company runs.
> 

Thank you very much for responding.

I'll take all comments into consideration; I think one thing is clear,
that even if I'd had to report that freeBSD is vulnerable, I'd have to
wait for a pacth. Since my personal patch policy on RELENG for FreeBSD
is to patch/update as fast as possible after a SA has been published,
I'd have to wait for the patches. CURRENT and STABLE systems are
updated  frequently - on a weekly basis, if necessary.

Kind regards,

O. Hartmann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20201217/0101b0a2/attachment.sig>

From andreas at naund.org  Thu Dec 17 18:33:36 2020
From: andreas at naund.org (Andreas Ott)
Date: Thu, 17 Dec 2020 10:33:27 -0800
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>;
 from imp@bsdimp.com on Wed, Dec 16, 2020 at 05:46:35PM -0700
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
Message-ID: <20201217103327.A13944@naund.org>

Hi,

On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote:
> This switch will preserve much of the current FreeBSD development workflow.
> After the switch, the subversion repo will become almost read-only.

Will there be an update to the build from source instructions in
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html ?

I am also interested in a (one-time) migration procedure from svn or
svnlite to git, primarily for my servers that are tracking -CURRENT.

Thanks, andreas
--
Andreas Ott   K6OTT   +1.408.431.8727   andreas at naund.org

From imp at bsdimp.com  Thu Dec 17 18:47:59 2020
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 17 Dec 2020 11:47:48 -0700
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <20201217103327.A13944@naund.org>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <20201217103327.A13944@naund.org>
Message-ID: <CANCZdfrrCd9gTyCke4EzfFyEngbiaJ+ASCeRyT_U8AtDRAg8kQ@mail.gmail.com>

On Thu, Dec 17, 2020 at 11:33 AM Andreas Ott <andreas at naund.org> wrote:

> Hi,
>
> On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote:
> > This switch will preserve much of the current FreeBSD development
> workflow.
> > After the switch, the subversion repo will become almost read-only.
>
> Will there be an update to the build from source instructions in
> https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html
> ?
>

Yes, eventually. There's also a transition to asciidoc going on in doc
land, and I didn't want to make it harder by churning things for them while
that was in progress.


> I am also interested in a (one-time) migration procedure from svn or
> svnlite to git, primarily for my servers that are tracking -CURRENT.
>

I've put together some docs on this.
https://github.com/bsdimp/freebsd-git-docs/ has them all.

https://github.com/bsdimp/freebsd-git-docs/blob/main/src-cvt.md has the
specifics, but I'm still polishing it. It has the basics, but the examples
still need work.

The tl;dr version, though, is that you'll have to pull a fresh tree from
the git repo once we make the cutover and then use git to update that tree.
Other than that, the rest of the instructions are the same. If you have
local changes, then

https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md

also has some details beyond the basics.

Warner

From nwhitehorn at freebsd.org  Thu Dec 17 19:01:12 2020
From: nwhitehorn at freebsd.org (Nathan Whitehorn)
Date: Thu, 17 Dec 2020 14:01:11 -0500
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
Message-ID: <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org>



On 12/16/20 7:46 PM, Warner Losh wrote:
> Greetings,
>
> The FreeBSD project will be moving it's source repo from subversion to git
> starting this this weekend. The docs repo was moved 2 weeks ago. The ports
> repo will move at the end of March, 2021 due to timing issues.
>
> The short version is that we're switching the version control we're using.
> This switch will preserve much of the current FreeBSD development workflow.
> After the switch, the subversion repo will become almost read-only. All
> future work will be done in git, however as a transition aide we'll be
> replaying the MFCs to stable/11, stable/12 and the related releng branches
> for the life of those branches.
>
> For more detailed information, please see
> https://github.com/bsdimp/freebsd-git-docs/ for the current documentation.
>
> Please see https://wiki.freebsd.org/git for the latest detailed schedule
> (please note that this schedule is subject to change).
>
> Warner
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>

One question I didn't see in the (excellent!) docs is whether we should 
be PGP-signing commits or not. Is that encouraged?
-Nathan

From imp at bsdimp.com  Thu Dec 17 19:05:50 2020
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 17 Dec 2020 12:05:28 -0700
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org>
Message-ID: <CANCZdfrF0B7uux_neg-4XGn2UCDd4noUm7zP_icHnrpZUgmzzA@mail.gmail.com>

On Thu, Dec 17, 2020 at 12:01 PM Nathan Whitehorn <nwhitehorn at freebsd.org>
wrote:

>
>
> On 12/16/20 7:46 PM, Warner Losh wrote:
> > Greetings,
> >
> > The FreeBSD project will be moving it's source repo from subversion to
> git
> > starting this this weekend. The docs repo was moved 2 weeks ago. The
> ports
> > repo will move at the end of March, 2021 due to timing issues.
> >
> > The short version is that we're switching the version control we're
> using.
> > This switch will preserve much of the current FreeBSD development
> workflow.
> > After the switch, the subversion repo will become almost read-only. All
> > future work will be done in git, however as a transition aide we'll be
> > replaying the MFCs to stable/11, stable/12 and the related releng
> branches
> > for the life of those branches.
> >
> > For more detailed information, please see
> > https://github.com/bsdimp/freebsd-git-docs/ for the current
> documentation.
> >
> > Please see https://wiki.freebsd.org/git for the latest detailed schedule
> > (please note that this schedule is subject to change).
> >
> > Warner
> > _______________________________________________
> > freebsd-current at freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "
> freebsd-current-unsubscribe at freebsd.org"
> >
>
> One question I didn't see in the (excellent!) docs is whether we should
> be PGP-signing commits or not. Is that encouraged?
>

We've not started doing that in general. I don't think signing would cause
issues, but since it is a bit of an unknown, we've not taken a position on
this.

Warner (on behalf of the git working group)

From asomers at freebsd.org  Thu Dec 17 19:53:03 2020
From: asomers at freebsd.org (Alan Somers)
Date: Thu, 17 Dec 2020 12:52:50 -0700
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <CANCZdfrF0B7uux_neg-4XGn2UCDd4noUm7zP_icHnrpZUgmzzA@mail.gmail.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org>
 <CANCZdfrF0B7uux_neg-4XGn2UCDd4noUm7zP_icHnrpZUgmzzA@mail.gmail.com>
Message-ID: <CAOtMX2gV2dmyG4b1hZG24sUnqDVk=1pch4xgQmyUdtLrh48kYg@mail.gmail.com>

On Thu, Dec 17, 2020 at 12:06 PM Warner Losh <imp at bsdimp.com> wrote:

> On Thu, Dec 17, 2020 at 12:01 PM Nathan Whitehorn <nwhitehorn at freebsd.org>
> wrote:
>
> >
> >
> > On 12/16/20 7:46 PM, Warner Losh wrote:
> > > Greetings,
> > >
> > > The FreeBSD project will be moving it's source repo from subversion to
> > git
> > > starting this this weekend. The docs repo was moved 2 weeks ago. The
> > ports
> > > repo will move at the end of March, 2021 due to timing issues.
> > >
> > > The short version is that we're switching the version control we're
> > using.
> > > This switch will preserve much of the current FreeBSD development
> > workflow.
> > > After the switch, the subversion repo will become almost read-only. All
> > > future work will be done in git, however as a transition aide we'll be
> > > replaying the MFCs to stable/11, stable/12 and the related releng
> > branches
> > > for the life of those branches.
> > >
> > > For more detailed information, please see
> > > https://github.com/bsdimp/freebsd-git-docs/ for the current
> > documentation.
> > >
> > > Please see https://wiki.freebsd.org/git for the latest detailed
> schedule
> > > (please note that this schedule is subject to change).
> > >
> > > Warner
> > > _______________________________________________
> > > freebsd-current at freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to "
> > freebsd-current-unsubscribe at freebsd.org"
> > >
> >
> > One question I didn't see in the (excellent!) docs is whether we should
> > be PGP-signing commits or not. Is that encouraged?
> >
>
> We've not started doing that in general. I don't think signing would cause
> issues, but since it is a bit of an unknown, we've not taken a position on
> this.
>
> Warner (on behalf of the git working group)
>

I hope we don't have to start signing all commits.  saltstack/salt has that
policy, and it's extremely annoying.
-Alan

From filippomore at yahoo.com  Thu Dec 17 20:11:32 2020
From: filippomore at yahoo.com (Filippo Moretti)
Date: Thu, 17 Dec 2020 20:11:25 +0000 (UTC)
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <CAOtMX2gV2dmyG4b1hZG24sUnqDVk=1pch4xgQmyUdtLrh48kYg@mail.gmail.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org>
 <CANCZdfrF0B7uux_neg-4XGn2UCDd4noUm7zP_icHnrpZUgmzzA@mail.gmail.com>
 <CAOtMX2gV2dmyG4b1hZG24sUnqDVk=1pch4xgQmyUdtLrh48kYg@mail.gmail.com>
Message-ID: <1061124731.1927937.1608235885208@mail.yahoo.com>

 
I tried cloning with the following result:
[root at STING /home/filippo]# git clone -o freebsd -b main https://git.freebsd.org/src.git /usr/src
Cloning into '/usr/src'...
fatal: repository 'https://git.freebsd.org/src.git/' not found

Should I wait past the weekend to clone?Filippo
    On Thursday, December 17, 2020, 8:53:22 PM GMT+1, Alan Somers <asomers at freebsd.org> wrote:  
 
 On Thu, Dec 17, 2020 at 12:06 PM Warner Losh <imp at bsdimp.com> wrote:

> On Thu, Dec 17, 2020 at 12:01 PM Nathan Whitehorn <nwhitehorn at freebsd.org>
> wrote:
>
> >
> >
> > On 12/16/20 7:46 PM, Warner Losh wrote:
> > > Greetings,
> > >
> > > The FreeBSD project will be moving it's source repo from subversion to
> > git
> > > starting this this weekend. The docs repo was moved 2 weeks ago. The
> > ports
> > > repo will move at the end of March, 2021 due to timing issues.
> > >
> > > The short version is that we're switching the version control we're
> > using.
> > > This switch will preserve much of the current FreeBSD development
> > workflow.
> > > After the switch, the subversion repo will become almost read-only. All
> > > future work will be done in git, however as a transition aide we'll be
> > > replaying the MFCs to stable/11, stable/12 and the related releng
> > branches
> > > for the life of those branches.
> > >
> > > For more detailed information, please see
> > > https://github.com/bsdimp/freebsd-git-docs/ for the current
> > documentation.
> > >
> > > Please see https://wiki.freebsd.org/git for the latest detailed
> schedule
> > > (please note that this schedule is subject to change).
> > >
> > > Warner
> > > _______________________________________________
> > > freebsd-current at freebsd.org mailing list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > To unsubscribe, send any mail to "
> > freebsd-current-unsubscribe at freebsd.org"
> > >
> >
> > One question I didn't see in the (excellent!) docs is whether we should
> > be PGP-signing commits or not. Is that encouraged?
> >
>
> We've not started doing that in general. I don't think signing would cause
> issues, but since it is a bit of an unknown, we've not taken a position on
> this.
>
> Warner (on behalf of the git working group)
>

I hope we don't have to start signing all commits.? saltstack/salt has that
policy, and it's extremely annoying.
-Alan
_______________________________________________
freebsd-current at freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
  

From imp at bsdimp.com  Thu Dec 17 20:39:20 2020
From: imp at bsdimp.com (Warner Losh)
Date: Thu, 17 Dec 2020 13:39:09 -0700
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <CAOtMX2gV2dmyG4b1hZG24sUnqDVk=1pch4xgQmyUdtLrh48kYg@mail.gmail.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org>
 <CANCZdfrF0B7uux_neg-4XGn2UCDd4noUm7zP_icHnrpZUgmzzA@mail.gmail.com>
 <CAOtMX2gV2dmyG4b1hZG24sUnqDVk=1pch4xgQmyUdtLrh48kYg@mail.gmail.com>
Message-ID: <CANCZdfpb0MF+uoW=K3cQpL+3vNQjSBDeVMab5d4JJhUO4sy-2Q@mail.gmail.com>

On Thu, Dec 17, 2020 at 12:53 PM Alan Somers <asomers at freebsd.org> wrote:

> On Thu, Dec 17, 2020 at 12:06 PM Warner Losh <imp at bsdimp.com> wrote:
>
>> On Thu, Dec 17, 2020 at 12:01 PM Nathan Whitehorn <nwhitehorn at freebsd.org
>> >
>> wrote:
>>
>> >
>> >
>> > On 12/16/20 7:46 PM, Warner Losh wrote:
>> > > Greetings,
>> > >
>> > > The FreeBSD project will be moving it's source repo from subversion to
>> > git
>> > > starting this this weekend. The docs repo was moved 2 weeks ago. The
>> > ports
>> > > repo will move at the end of March, 2021 due to timing issues.
>> > >
>> > > The short version is that we're switching the version control we're
>> > using.
>> > > This switch will preserve much of the current FreeBSD development
>> > workflow.
>> > > After the switch, the subversion repo will become almost read-only.
>> All
>> > > future work will be done in git, however as a transition aide we'll be
>> > > replaying the MFCs to stable/11, stable/12 and the related releng
>> > branches
>> > > for the life of those branches.
>> > >
>> > > For more detailed information, please see
>> > > https://github.com/bsdimp/freebsd-git-docs/ for the current
>> > documentation.
>> > >
>> > > Please see https://wiki.freebsd.org/git for the latest detailed
>> schedule
>> > > (please note that this schedule is subject to change).
>> > >
>> > > Warner
>> > > _______________________________________________
>> > > freebsd-current at freebsd.org mailing list
>> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> > > To unsubscribe, send any mail to "
>> > freebsd-current-unsubscribe at freebsd.org"
>> > >
>> >
>> > One question I didn't see in the (excellent!) docs is whether we should
>> > be PGP-signing commits or not. Is that encouraged?
>> >
>>
>> We've not started doing that in general. I don't think signing would cause
>> issues, but since it is a bit of an unknown, we've not taken a position on
>> this.
>>
>> Warner (on behalf of the git working group)
>>
>
> I hope we don't have to start signing all commits.  saltstack/salt has
> that policy, and it's extremely annoying.
>

Have to? Not currently. As with all process changes, there will be
community discussion around the different points.

Warner

From uqs at freebsd.org  Thu Dec 17 21:21:24 2020
From: uqs at freebsd.org (Ulrich =?utf-8?B?U3DDtnJsZWlu?=)
Date: Thu, 17 Dec 2020 22:21:21 +0100
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <CANCZdfpb0MF+uoW=K3cQpL+3vNQjSBDeVMab5d4JJhUO4sy-2Q@mail.gmail.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org>
 <CANCZdfrF0B7uux_neg-4XGn2UCDd4noUm7zP_icHnrpZUgmzzA@mail.gmail.com>
 <CAOtMX2gV2dmyG4b1hZG24sUnqDVk=1pch4xgQmyUdtLrh48kYg@mail.gmail.com>
 <CANCZdfpb0MF+uoW=K3cQpL+3vNQjSBDeVMab5d4JJhUO4sy-2Q@mail.gmail.com>
Message-ID: <X9vL0UPiVcTPLF4A@acme.spoerlein.net>

On Thu, 2020-12-17 at 13:39:09 -0700, Warner Losh wrote:
>On Thu, Dec 17, 2020 at 12:53 PM Alan Somers <asomers at freebsd.org> wrote:
>> On Thu, Dec 17, 2020 at 12:06 PM Warner Losh <imp at bsdimp.com> wrote:
>>> On Thu, Dec 17, 2020 at 12:01 PM Nathan Whitehorn <nwhitehorn at freebsd.org wrote:
>>> > One question I didn't see in the (excellent!) docs is whether we should
>>> > be PGP-signing commits or not. Is that encouraged?
>>> >
>>>
>>> We've not started doing that in general. I don't think signing would cause
>>> issues, but since it is a bit of an unknown, we've not taken a position on
>>> this.
>>>
>>> Warner (on behalf of the git working group)
>>>
>>
>> I hope we don't have to start signing all commits.  saltstack/salt has
>> that policy, and it's extremely annoying.
>>
>
>Have to? Not currently. As with all process changes, there will be
>community discussion around the different points.

If you've successfully pushed your commit into FreeBSD.org infra, you've 
essentially signed it with a working SSH key. Isn't that enough?

Cheers
Uli

From uqs at freebsd.org  Thu Dec 17 21:25:52 2020
From: uqs at freebsd.org (Ulrich =?utf-8?B?U3DDtnJsZWlu?=)
Date: Thu, 17 Dec 2020 22:25:42 +0100
Subject: git tools for building in base?
In-Reply-To: <20201125150548.vkqgtlqnawgwujbn@mutt-hbsd>
References: <X714z7pMgNOFaTIc@rpi4.local>
 <CANCZdfrjSkrgx6B+_At7uBZN_eWQWa--1pky65nZueAr0F-zxQ@mail.gmail.com>
 <20201125150050.bz62hatil6sbhdwn@ivaldir.net>
 <20201125150548.vkqgtlqnawgwujbn@mutt-hbsd>
Message-ID: <X9vM1ijN3MWIMeBm@acme.spoerlein.net>

On Wed, 2020-11-25 at 10:05:48 -0500, Shawn Webb wrote:
>On Wed, Nov 25, 2020 at 04:00:50PM +0100, Baptiste Daroussin wrote:
>> On Tue, Nov 24, 2020 at 09:59:15PM -0700, Warner Losh wrote:
>> > On Tue, Nov 24, 2020 at 2:19 PM tech-lists <tech-lists at zyxst.net> wrote:
>> >
>> > > As subject - what will there be in base to interact with the new git repo?
>> > > I mean, right now, for svn there is svnlite. What for git?
>> > >
>> >
>> > 'pkg add git' is your choice now.
>>
>> pkg install not pkg add
>
>There's also fetch for a one-time download of the ports tree
>(bootstrapping ports, for example). A HardenedBSD user would do this:
>
>fetch -o ports.tar.gz \
>    https://git-01.md.hardenedbsd.org/HardenedBSD/hardenedbsd-ports/archive/master.tar.gz
>
>mkdir -p /usr/ports
>
>tar -xf ports.tar.gz --strip-components 1 -C /usr/ports
>
>Something similar could be done in FreeBSDlandia.
>

cgit supports this of course, so the troglodytes can download 
src/ports/doc from cgit, using only FreeBSD-provided tools like so:

fetch -o- https://cgit.freebsd.org/doc/snapshot/doc-main.tar.gz | tar -C /usr/doc -xf -

hth
Uli

From mueller6722 at twc.com  Fri Dec 18 01:53:10 2020
From: mueller6722 at twc.com (Thomas Mueller)
Date: Fri, 18 Dec 2020 01:53:10 -0000
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org>
 <CANCZdfrF0B7uux_neg-4XGn2UCDd4noUm7zP_icHnrpZUgmzzA@mail.gmail.com>
 <CAOtMX2gV2dmyG4b1hZG24sUnqDVk=1pch4xgQmyUdtLrh48kYg@mail.gmail.com>
 <CANCZdfpb0MF+uoW=K3cQpL+3vNQjSBDeVMab5d4JJhUO4sy-2Q@mail.gmail.com>
Message-ID: <mailman.4.1608256390.98900.freebsd-current@freebsd.org>

> > I hope we don't have to start signing all commits.  saltstack/salt has
> > that policy, and it's extremely annoying.

> Have to? Not currently. As with all process changes, there will be
> community discussion around the different points.

> Warner

I hope not!

Signatures, at least in email messages, are just an annoyance as I see them.

I don't even know how do sign an email message or make use of a signature in a message I receive.

I have never made a commit to a repository, so would not be familiar with signatures there; imagine it would be a barrier.

Tom


From waitman at waitman.net  Fri Dec 18 02:02:19 2020
From: waitman at waitman.net (Waitman Gobble)
Date: Thu, 17 Dec 2020 22:02:16 -0400
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: mid:846
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org>
 <CANCZdfrF0B7uux_neg-4XGn2UCDd4noUm7zP_icHnrpZUgmzzA@mail.gmail.com>
 <CAOtMX2gV2dmyG4b1hZG24sUnqDVk=1pch4xgQmyUdtLrh48kYg@mail.gmail.com>
 <CANCZdfpb0MF+uoW=K3cQpL+3vNQjSBDeVMab5d4JJhUO4sy-2Q@mail.gmail.com> mid:846
Message-ID: <d951d7d30418bbc6b79e5757e960151f@waitman.net>

On 2020-12-17 21:53, Thomas Mueller wrote:
>> > I hope we don't have to start signing all commits.  saltstack/salt has
>> > that policy, and it's extremely annoying.
> 
>> Have to? Not currently. As with all process changes, there will be
>> community discussion around the different points.
> 
>> Warner
> 
> I hope not!
> 
> Signatures, at least in email messages, are just an annoyance as I see 
> them.
> 
> I don't even know how do sign an email message or make use of a
> signature in a message I receive.
> 
> I have never made a commit to a repository, so would not be familiar
> with signatures there; imagine it would be a barrier.
> 
> Tom
> 
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to 
> "freebsd-current-unsubscribe at freebsd.org"

I'm not a FreeBSD committer, but on other git projects I sign my 
commits. AFAIK it's a good idea.

I'm curious what is annoying about it? It's just adding the 'sign' tag. 
If you want a portable GPG key check out something like a yubikey. I'm 
sure there's other portable hardware options.

# git commit -S -m "message"

You can also set to always sign automatically,

# git config --global commit.gpgsign true


-- 
Waitman Gobble

From 000.fbsd at quip.cz  Fri Dec 18 13:02:18 2020
From: 000.fbsd at quip.cz (Miroslav Lachman)
Date: Fri, 18 Dec 2020 14:02:08 +0100
Subject: git tools for building in base?
In-Reply-To: <20201125055425.01AA628417@elsa.codelab.cz>
References: <X714z7pMgNOFaTIc@rpi4.local>
 <20201125055425.01AA628417@elsa.codelab.cz>
Message-ID: <10f7b800-b015-2a80-b741-4f7db03bf6eb@quip.cz>

On 25/11/2020 06:54, Thomas Mueller wrote:

> NetBSD users face a similar problem with their upcoming switch from cvs to hg (Mercurial).

Do anybody have a link to some documents stating why FreeBSD chose Git 
and why NetBSD chose Mercurial? I am using both tools at $WORK, I am 
just curious what leads to these decisions.

Kind regards
Miroslav Lachman

From otis at FreeBSD.org  Fri Dec 18 13:16:07 2020
From: otis at FreeBSD.org (Juraj Lutter)
Date: Fri, 18 Dec 2020 14:15:56 +0100
Subject: git tools for building in base?
In-Reply-To: <10f7b800-b015-2a80-b741-4f7db03bf6eb@quip.cz>
References: <X714z7pMgNOFaTIc@rpi4.local>
 <20201125055425.01AA628417@elsa.codelab.cz>
 <10f7b800-b015-2a80-b741-4f7db03bf6eb@quip.cz>
Message-ID: <1FD6AC93-8BDA-4242-9D8C-74425612D3CC@FreeBSD.org>



> On 18 Dec 2020, at 14:02, Miroslav Lachman <000.fbsd at quip.cz> wrote:
> 
> On 25/11/2020 06:54, Thomas Mueller wrote:
> 
>> NetBSD users face a similar problem with their upcoming switch from cvs to hg (Mercurial).
> 
> Do anybody have a link to some documents stating why FreeBSD chose Git and why NetBSD chose Mercurial? I am using both tools at $WORK, I am just curious what leads to these decisions.

Joerg Sonnenberger had a talk about it:

https://archive.fosdem.org/2018/schedule/event/netbsd_and_mercurial/

At NetBSD it is not that straightforward:
  - git is used for pkgsrc-wip
  - src, xsrc and pkgsrc are in CVS and there are *plans* to move to hg,
    but there are no fixed deadlines when this will be done.

otis

From mad at madpilot.net  Fri Dec 18 14:26:52 2020
From: mad at madpilot.net (Guido Falsi)
Date: Fri, 18 Dec 2020 15:26:41 +0100
Subject: git tools for building in base?
In-Reply-To: <10f7b800-b015-2a80-b741-4f7db03bf6eb@quip.cz>
References: <X714z7pMgNOFaTIc@rpi4.local>
 <20201125055425.01AA628417@elsa.codelab.cz>
 <10f7b800-b015-2a80-b741-4f7db03bf6eb@quip.cz>
Message-ID: <e3dce606-1a28-886f-b481-7f1d224d82cc@madpilot.net>

On 18/12/20 14:02, Miroslav Lachman wrote:
> On 25/11/2020 06:54, Thomas Mueller wrote:
> 
>> NetBSD users face a similar problem with their upcoming switch from 
>> cvs to hg (Mercurial).
> 
> Do anybody have a link to some documents stating why FreeBSD chose Git 
> and why NetBSD chose Mercurial? I am using both tools at $WORK, I am 
> just curious what leads to these decisions.
> 

This is a draft document discussing exactly this (I'm not the author, 
imp was)

https://github.com/bsdimp/freebsd-git-docs/blob/main/git-why.md

-- 
Guido Falsi <mad at madpilot.net>

From imp at bsdimp.com  Fri Dec 18 15:50:04 2020
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 18 Dec 2020 08:49:50 -0700
Subject: git tools for building in base?
In-Reply-To: <e3dce606-1a28-886f-b481-7f1d224d82cc@madpilot.net>
References: <X714z7pMgNOFaTIc@rpi4.local>
 <20201125055425.01AA628417@elsa.codelab.cz>
 <10f7b800-b015-2a80-b741-4f7db03bf6eb@quip.cz>
 <e3dce606-1a28-886f-b481-7f1d224d82cc@madpilot.net>
Message-ID: <CANCZdfq0XOuJ--2jXVY42Nkxpu4YnuoCpoy4vVDo9o4hUp6ATw@mail.gmail.com>

On Fri, Dec 18, 2020, 7:27 AM Guido Falsi <mad at madpilot.net> wrote:

> On 18/12/20 14:02, Miroslav Lachman wrote:
> > On 25/11/2020 06:54, Thomas Mueller wrote:
> >
> >> NetBSD users face a similar problem with their upcoming switch from
> >> cvs to hg (Mercurial).
> >
> > Do anybody have a link to some documents stating why FreeBSD chose Git
> > and why NetBSD chose Mercurial? I am using both tools at $WORK, I am
> > just curious what leads to these decisions.
> >
>
> This is a draft document discussing exactly this (I'm not the author,
> imp was)
>
> https://github.com/bsdimp/freebsd-git-docs/blob/main/git-why.md


My blog
http://bsdimp.blogspot.com/2020/09/freebsd-subversion-to-git-migration.html

And this video I did
https://youtu.be/uj1Ricrq0bs that starts with an old in joke...

Warner

>
> --
> Guido Falsi <mad at madpilot.net>
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>

From arrowd at freebsd.org  Fri Dec 18 16:24:38 2020
From: arrowd at freebsd.org (Gleb Popov)
Date: Fri, 18 Dec 2020 20:24:05 +0400
Subject: git tools for building in base?
In-Reply-To: <CANCZdfq0XOuJ--2jXVY42Nkxpu4YnuoCpoy4vVDo9o4hUp6ATw@mail.gmail.com>
References: <X714z7pMgNOFaTIc@rpi4.local>
 <20201125055425.01AA628417@elsa.codelab.cz>
 <10f7b800-b015-2a80-b741-4f7db03bf6eb@quip.cz>
 <e3dce606-1a28-886f-b481-7f1d224d82cc@madpilot.net>
 <CANCZdfq0XOuJ--2jXVY42Nkxpu4YnuoCpoy4vVDo9o4hUp6ATw@mail.gmail.com>
Message-ID: <CALH631nJ_cnfLhG+SDX5Mchk2+RrfFn=38rXYrFwVxV+tG_QkQ@mail.gmail.com>

On Fri, Dec 18, 2020 at 7:50 PM Warner Losh <imp at bsdimp.com> wrote:

> On Fri, Dec 18, 2020, 7:27 AM Guido Falsi <mad at madpilot.net> wrote:
>
> > On 18/12/20 14:02, Miroslav Lachman wrote:
> > > On 25/11/2020 06:54, Thomas Mueller wrote:
> > >
> > >> NetBSD users face a similar problem with their upcoming switch from
> > >> cvs to hg (Mercurial).
> > >
> > > Do anybody have a link to some documents stating why FreeBSD chose Git
> > > and why NetBSD chose Mercurial? I am using both tools at $WORK, I am
> > > just curious what leads to these decisions.
> > >
> >
> > This is a draft document discussing exactly this (I'm not the author,
> > imp was)
> >
> > https://github.com/bsdimp/freebsd-git-docs/blob/main/git-why.md
>
>
> My blog
> http://bsdimp.blogspot.com/2020/09/freebsd-subversion-to-git-migration.html
>
> And this video I did
> https://youtu.be/uj1Ricrq0bs that starts with an old in joke...
>
> Warner
>

I can't find anything about Mercurial in all three links.

From imp at bsdimp.com  Fri Dec 18 16:31:51 2020
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 18 Dec 2020 09:31:40 -0700
Subject: git tools for building in base?
In-Reply-To: <CALH631nJ_cnfLhG+SDX5Mchk2+RrfFn=38rXYrFwVxV+tG_QkQ@mail.gmail.com>
References: <X714z7pMgNOFaTIc@rpi4.local>
 <20201125055425.01AA628417@elsa.codelab.cz>
 <10f7b800-b015-2a80-b741-4f7db03bf6eb@quip.cz>
 <e3dce606-1a28-886f-b481-7f1d224d82cc@madpilot.net>
 <CANCZdfq0XOuJ--2jXVY42Nkxpu4YnuoCpoy4vVDo9o4hUp6ATw@mail.gmail.com>
 <CALH631nJ_cnfLhG+SDX5Mchk2+RrfFn=38rXYrFwVxV+tG_QkQ@mail.gmail.com>
Message-ID: <CANCZdfqwpm+9v5yutsa6_mHdPC8CSKZTCtHMuSEUjpQFcEfDKQ@mail.gmail.com>

On Fri, Dec 18, 2020 at 9:24 AM Gleb Popov <arrowd at freebsd.org> wrote:

>
>
> On Fri, Dec 18, 2020 at 7:50 PM Warner Losh <imp at bsdimp.com> wrote:
>
>> On Fri, Dec 18, 2020, 7:27 AM Guido Falsi <mad at madpilot.net> wrote:
>>
>> > On 18/12/20 14:02, Miroslav Lachman wrote:
>> > > On 25/11/2020 06:54, Thomas Mueller wrote:
>> > >
>> > >> NetBSD users face a similar problem with their upcoming switch from
>> > >> cvs to hg (Mercurial).
>> > >
>> > > Do anybody have a link to some documents stating why FreeBSD chose Git
>> > > and why NetBSD chose Mercurial? I am using both tools at $WORK, I am
>> > > just curious what leads to these decisions.
>> > >
>> >
>> > This is a draft document discussing exactly this (I'm not the author,
>> > imp was)
>> >
>> > https://github.com/bsdimp/freebsd-git-docs/blob/main/git-why.md
>>
>>
>> My blog
>>
>> http://bsdimp.blogspot.com/2020/09/freebsd-subversion-to-git-migration.html
>>
>> And this video I did
>> https://youtu.be/uj1Ricrq0bs that starts with an old in joke...
>>
>> Warner
>>
>
> I can't find anything about Mercurial in all three links.
>

Yes. I was answering the first question asked about FreeBSD and git...

The clincher for me was that git is better supported by third party tools
and has gotten quite good at 'recovery from oops' which mercurial is still
lacking in both areas. I too have used both, and I had to re clone my hg
tree several times, but so far have never screwed up a git repo so bad I
had to reclone... The history rewriting of git is more integrated and more
polished than the equivalent in hg, as are the rebase workflows which
really help have a cleaner history...

Warner

From brooks at freebsd.org  Fri Dec 18 17:52:49 2020
From: brooks at freebsd.org (Brooks Davis)
Date: Fri, 18 Dec 2020 17:52:41 +0000
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org>
 <CANCZdfrF0B7uux_neg-4XGn2UCDd4noUm7zP_icHnrpZUgmzzA@mail.gmail.com>
 <CAOtMX2gV2dmyG4b1hZG24sUnqDVk=1pch4xgQmyUdtLrh48kYg@mail.gmail.com>
 <CANCZdfpb0MF+uoW=K3cQpL+3vNQjSBDeVMab5d4JJhUO4sy-2Q@mail.gmail.com>
 <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com>
Message-ID: <20201218175241.GA72552@spindle.one-eyed-alien.net>

On Thu, Dec 17, 2020 at 05:53:20PM -0800, Thomas Mueller wrote:
> > > I hope we don't have to start signing all commits.  saltstack/salt has
> > > that policy, and it's extremely annoying.
> 
> > Have to? Not currently. As with all process changes, there will be
> > community discussion around the different points.
> 
> > Warner
> 
> I hope not!
> 
> Signatures, at least in email messages, are just an annoyance as I see them.
> 
> I don't even know how do sign an email message or make use of a signature in a message I receive.
> 
> I have never made a commit to a repository, so would not be familiar with signatures there; imagine it would be a barrier.

Signed commits have no practicl effect on users of a repo.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20201218/b40a7dde/attachment.sig>

From steffen at sdaoden.eu  Fri Dec 18 18:28:30 2020
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 18 Dec 2020 19:28:20 +0100
Subject: HEADS UP: FreeBSD src repo transitioning to git this
 weekend
In-Reply-To: <20201218175241.GA72552@spindle.one-eyed-alien.net>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org>
 <CANCZdfrF0B7uux_neg-4XGn2UCDd4noUm7zP_icHnrpZUgmzzA@mail.gmail.com>
 <CAOtMX2gV2dmyG4b1hZG24sUnqDVk=1pch4xgQmyUdtLrh48kYg@mail.gmail.com>
 <CANCZdfpb0MF+uoW=K3cQpL+3vNQjSBDeVMab5d4JJhUO4sy-2Q@mail.gmail.com>
 <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com>
 <20201218175241.GA72552@spindle.one-eyed-alien.net>
Message-ID: <20201218182820.1P0tK%steffen@sdaoden.eu>

Brooks Davis wrote in
 <20201218175241.GA72552 at spindle.one-eyed-alien.net>:
 |On Thu, Dec 17, 2020 at 05:53:20PM -0800, Thomas Mueller wrote:
 |>>> I hope we don't have to start signing all commits.  saltstack/salt has
 |>>> that policy, and it's extremely annoying.
 |> 
 |>> Have to? Not currently. As with all process changes, there will be
 |>> community discussion around the different points.
 |> 
 |>> Warner
 |> 
 |> I hope not!
 |> 
 |> Signatures, at least in email messages, are just an annoyance as \
 |> I see them.
 |> 
 |> I don't even know how do sign an email message or make use of a signatur\
 |> e in a message I receive.
 |> 
 |> I have never made a commit to a repository, so would not be familiar \
 |> with signatures there; imagine it would be a barrier.
 |
 |Signed commits have no practicl effect on users of a repo.

Well you can verify integrity of a repository regardless of how it
was distributed, this is why it is done, right.

  #?0$ git log --oneline --show-signature -1 v14.9.20.ar
  16a21755 (...)
  gpg: Signature made Sun 13 Dec 2020 12:43:44 AM CET
  gpg:                using RSA key DF082F6AEEC8C2FF
  gpg: Good signature from "Steffen Nurpmeso <steffen at sdaoden.eu>"
  Bump S-nail v14.9.20.ar ("Sombre Tit (Trauermeise)"), 2020-12-12

  #?0$ git tag -v v14.9.20.ar; echo $?
  object 16a21755fd1fade2b15fdb78a592f12169c3453f
  type commit
  tag v14.9.20.ar
  tagger Steffen Nurpmeso <steffen at sdaoden.eu> 1607816624 +0100
  
  Bump S-nail v14.9.20.ar ("Sombre Tit (Trauermeise)"), 2020-12-12
  gpg: Signature made Sun 13 Dec 2020 12:43:44 AM CET
  gpg:                using RSA key DF082F6AEEC8C2FF
  gpg: Good signature from "Steffen Nurpmeso <steffen at sdaoden.eu>"
  0

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From marklmi at yahoo.com  Sat Dec 19 06:27:40 2020
From: marklmi at yahoo.com (Mark Millard)
Date: Fri, 18 Dec 2020 22:27:28 -0800
Subject: debug head -r368500 kernel (for example) : "lock order reversal:
 (sleepable after non-sleepable)" involving ure0 and a sysctl lock; more
References: <E58350E3-EB33-410C-AC20-E25A9A78D5C2.ref@yahoo.com>
Message-ID: <E58350E3-EB33-410C-AC20-E25A9A78D5C2@yahoo.com>


The following is from head -r368500's artifact kernel from:

https://artifact.ci.freebsd.org/snapshot/13.0-CURRENT/r368500/arm64/aarch64/kernel.txz

but the same sort of material showed for -r368000 .
(I was attempting a bisect for a different issue but
the debug kernels did not fail for what I was looking
for and all the debug versions that I tried reported
similarly to the below.)

Note also the mixing in of "uma_zalloc_debug" activity
after the initial LOR backtrace, ure0 still involved.

Autoloading module: if_ure.ko
ure0 on uhub0
ure0: <Realtek USB 10/100/1000 LAN, class 0/0, rev 3.00/30.00, addr 2> on usbus0
add host 127.0.0.1: gatelock order reversal: (sleepable after non-sleepable)
 1st 0xffffa00002b2cea0 ure0 (ure0, sleep mutex) @ /usr/src/sys/dev/usb/usb_request.c:714
 2nd 0xffff000000dd6858 sysctl lock (sysctl lock, sleepable rm) @ /usway lo0 fib 0: route alrr/src/sys/kern/kern_sysctl.c:836
lock order ure0 -> sysctl lock attempted at:
#0 0xffff00000056d068 at witness_checkorder+0xc54
#1 0xffff0000004f8f08 at _rm_wlock_debug+0x88
#2 0xffff00000050ee2c at sysctl_add_oid+0x60
#3 0xffff00009e415780 at ure_attach_post+0x1a78
#4 0xffff000000391d6c at ue_attach_post_task+0x3c
#5 0xffff0000003826e0 at usb_process+0x10c
#6 0xffff0000004baa1c at fork_exit+0x7c
#7 0xffff000000816544 at fork_trampoline+0x10
uma_zalloc_debug: zone "malloc-128eady in table
" with the following non-sleepable locks held:
exclusive sleep mutex ure0 (ure0) r = 0 (0xffffa00002b2cea0) locked @ /usr/src/sys/dev/usb/usb_request.c:714
stack backtrace:
#0 0xffff00000056d388 at witness_debugger+0x64
#1 0xffff00000056e518 at witness_warn+0x3ec
#2 0xffff000000778f9c at uma_zalloc_debug+0x2c
#3 0xffff000000778998 at uma_zalloc_arg+0x2c
#4 0xffff0000004d534c at malloc+0xa0
#5 0xffff00000050ee80 at sysctl_add_oid+0xb4
#6 0xffff00009e415780 at ure_attach_post+0x1a78
#7 0xffff000000391d6c at ue_attach_post_task+0x3c
#8 0xffff0000003826e0 at usb_process+0x10c
#9 0xffff0000004baa1c at fork_exit+0x7c
#10 0xffff000000816544 at fork_trampoline+0x10
uma_zalloc_debug: zone "malloc-16" with the following non-sleepable locks held:
exclusive sleep mutex ure0 (ure0) r = 0 (0xffffa00002b2cea0) locked @ /usr/src/sys/dev/usb/usb_request.c:714
stack backtrace:
#0 0xffff00000056d388 at witness_debugger+0x64
#1 0xffff00000056e518 at witness_warn+0x3ec
#2 0xffff000000778f9c at uma_zalloc_debug+0x2c
#3 0xffff000000778998 at uma_zalloc_arg+0x2c
#4 0xffff0000004d534c at malloc+0xa0
#5 0xffff0000005f8c80 at strdup+0x2c
#6 0xffff00000050eeb8 at sysctl_add_oid+0xec
#7 0xffff00009e415780 at ure_attach_post+0x1a78
#8 0xffff000000391d6c at ue_attach_post_task+0x3c
#9 0xffff0000003826e0 at usb_process+0x10c
#10 0xffff0000004baa1c at fork_exit+0x7c
#11 0xffff000000816544 at fork_trampoline+0x10
uma_zalloc_debug: zone "malloc-64" with the following non-sleepable locks held:
exclusive sleep mutex ure0 (ure0) r = 0 (0xffffa00002b2cea0) locked @ /usr/src/sys/dev/usb/usb_request.c:714
stack backtrace:
#0 0xffff00000056d388 at witness_debugger+0x64
#1 0xffff00000056e518 at witness_warn+0x3ec
#2 0xffff000000778f9c at uma_zalloc_debug+0x2c
#3 0xffff000000778998 at uma_zalloc_arg+0x2c
#4 0xffff0000004d534c at malloc+0xa0
#5 0xffff0000005f8c80 at strdup+0x2c
#6 0xffff00000050eee4 at sysctl_add_oid+0x118
#7 0xffff00009e415780 at ure_attach_post+0x1a78
#8 0xffff000000391d6c at ue_attach_post_task+0x3c
#9 0xffff0000003826e0 at usb_process+0x10c
#10 0xffff0000004baa1c at fork_exit+0x7c
#11 0xffff000000816544 at fork_trampoline+0x10
uma_zalloc_debug: zone "malloc-32" with the following non-sleepable locks held:
exclusive sleep mutex ure0 (ure0) r = 0 (0xffffa00002b2cea0) locked @ /usr/src/sys/dev/usb/usb_request.c:714
stack backtrace:
#0 0xffff00000056d388 at witness_debugger+0x64
#1 0xffff00000056e518 at witness_warn+0x3ec
#2 0xffff000000778f9c at uma_zalloc_debug+0x2c
#3 0xffff000000778998 at uma_zalloc_arg+0x2c
#4 0xffff0000004d534c at malloc+0xa0
#5 0xffff00000050ef3c at sysctl_add_oid+0x170
#6 0xffff00009e415780 at ure_attach_post+0x1a78
#7 0xffff000000391d6c at ue_attach_post_task+0x3c
#8 0xffff0000003826e0 at usb_process+0x10c
#9 0xffff0000004baa1c at fork_exit+0x7c
#10 0xffff000000816544 at fork_trampoline+0x10
miibus0: <MII bus> on ure0
rgephy0: <RTL8251/8153 1000BASE-T media interface> PHY 0 on miibus0
add hrgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto
0 fib 0: route already iue0: <USB Ethernet> on ure0



The context here is an RPi4 (aarch64 cortex-a72) with:

# uname -apKU
FreeBSD RPi4B 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r368500: Thu Dec 10 07:52:39 UTC 2020     root at FreeBSD-head-aarch64-build.jail.ci.FreeBSD.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC  arm64 aarch64 1300131 1300131

The boot attempts were via uefi/ACPI using https://github.com/pftf/RPi4
v1.21 materials, directly booting from the USB3 SSD, no microsd card
involved.


Some context in case it contributes something for the above
(probably not) . . .

The reason for the bisect was: such boot attempts fail to mount
route with my non-debug head -r368500 kernel build. (Previously
the RPi4 was back at head -r365932 or so.) But my non-debug
builds use -mcpu=cortex-a72 . (This combination has caught
missing synchronization activity before.)

In the failing case the following never shows up:

da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0: <OWC Envoy Pro mini 0> Fixed Direct Access SPC-4 SCSI device
da0: Serial Number REPLACED
da0: 400.000MB/s transfers
da0: 228936MB (468862128 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>

and the message:

Root mount waiting for: usbus0

repeats indefinitely, unlike historically for my configuration.

With the artifact debug kernel instead of the non-debug
kernel, the RPi4 boots fine, other things held constant.

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


From marklmi at yahoo.com  Sat Dec 19 06:44:31 2020
From: marklmi at yahoo.com (Mark Millard)
Date: Fri, 18 Dec 2020 22:44:24 -0800
Subject: debug head -r368500 kernel (for example) : "lock order reversal:
 (sleepable after non-sleepable)" involving ure0 and a sysctl lock;
 more
In-Reply-To: <E58350E3-EB33-410C-AC20-E25A9A78D5C2@yahoo.com>
References: <E58350E3-EB33-410C-AC20-E25A9A78D5C2@yahoo.com>
Message-ID: <3392879C-F0DC-4F14-9C48-1ADD94214D49@yahoo.com>

[I managed to not cc the primary person that I intended but to cc the secondary person.
So this resend just adds jmg and removes hps.]

On 2020-Dec-18, at 22:27, Mark Millard <marklmi at yahoo.com> wrote:


> The following is from head -r368500's artifact kernel from:
> 
> https://artifact.ci.freebsd.org/snapshot/13.0-CURRENT/r368500/arm64/aarch64/kernel.txz
> 
> but the same sort of material showed for -r368000 .
> (I was attempting a bisect for a different issue but
> the debug kernels did not fail for what I was looking
> for and all the debug versions that I tried reported
> similarly to the below.)
> 
> Note also the mixing in of "uma_zalloc_debug" activity
> after the initial LOR backtrace, ure0 still involved.
> 
> Autoloading module: if_ure.ko
> ure0 on uhub0
> ure0: <Realtek USB 10/100/1000 LAN, class 0/0, rev 3.00/30.00, addr 2> on usbus0
> add host 127.0.0.1: gatelock order reversal: (sleepable after non-sleepable)
> 1st 0xffffa00002b2cea0 ure0 (ure0, sleep mutex) @ /usr/src/sys/dev/usb/usb_request.c:714
> 2nd 0xffff000000dd6858 sysctl lock (sysctl lock, sleepable rm) @ /usway lo0 fib 0: route alrr/src/sys/kern/kern_sysctl.c:836
> lock order ure0 -> sysctl lock attempted at:
> #0 0xffff00000056d068 at witness_checkorder+0xc54
> #1 0xffff0000004f8f08 at _rm_wlock_debug+0x88
> #2 0xffff00000050ee2c at sysctl_add_oid+0x60
> #3 0xffff00009e415780 at ure_attach_post+0x1a78
> #4 0xffff000000391d6c at ue_attach_post_task+0x3c
> #5 0xffff0000003826e0 at usb_process+0x10c
> #6 0xffff0000004baa1c at fork_exit+0x7c
> #7 0xffff000000816544 at fork_trampoline+0x10
> uma_zalloc_debug: zone "malloc-128eady in table
> " with the following non-sleepable locks held:
> exclusive sleep mutex ure0 (ure0) r = 0 (0xffffa00002b2cea0) locked @ /usr/src/sys/dev/usb/usb_request.c:714
> stack backtrace:
> #0 0xffff00000056d388 at witness_debugger+0x64
> #1 0xffff00000056e518 at witness_warn+0x3ec
> #2 0xffff000000778f9c at uma_zalloc_debug+0x2c
> #3 0xffff000000778998 at uma_zalloc_arg+0x2c
> #4 0xffff0000004d534c at malloc+0xa0
> #5 0xffff00000050ee80 at sysctl_add_oid+0xb4
> #6 0xffff00009e415780 at ure_attach_post+0x1a78
> #7 0xffff000000391d6c at ue_attach_post_task+0x3c
> #8 0xffff0000003826e0 at usb_process+0x10c
> #9 0xffff0000004baa1c at fork_exit+0x7c
> #10 0xffff000000816544 at fork_trampoline+0x10
> uma_zalloc_debug: zone "malloc-16" with the following non-sleepable locks held:
> exclusive sleep mutex ure0 (ure0) r = 0 (0xffffa00002b2cea0) locked @ /usr/src/sys/dev/usb/usb_request.c:714
> stack backtrace:
> #0 0xffff00000056d388 at witness_debugger+0x64
> #1 0xffff00000056e518 at witness_warn+0x3ec
> #2 0xffff000000778f9c at uma_zalloc_debug+0x2c
> #3 0xffff000000778998 at uma_zalloc_arg+0x2c
> #4 0xffff0000004d534c at malloc+0xa0
> #5 0xffff0000005f8c80 at strdup+0x2c
> #6 0xffff00000050eeb8 at sysctl_add_oid+0xec
> #7 0xffff00009e415780 at ure_attach_post+0x1a78
> #8 0xffff000000391d6c at ue_attach_post_task+0x3c
> #9 0xffff0000003826e0 at usb_process+0x10c
> #10 0xffff0000004baa1c at fork_exit+0x7c
> #11 0xffff000000816544 at fork_trampoline+0x10
> uma_zalloc_debug: zone "malloc-64" with the following non-sleepable locks held:
> exclusive sleep mutex ure0 (ure0) r = 0 (0xffffa00002b2cea0) locked @ /usr/src/sys/dev/usb/usb_request.c:714
> stack backtrace:
> #0 0xffff00000056d388 at witness_debugger+0x64
> #1 0xffff00000056e518 at witness_warn+0x3ec
> #2 0xffff000000778f9c at uma_zalloc_debug+0x2c
> #3 0xffff000000778998 at uma_zalloc_arg+0x2c
> #4 0xffff0000004d534c at malloc+0xa0
> #5 0xffff0000005f8c80 at strdup+0x2c
> #6 0xffff00000050eee4 at sysctl_add_oid+0x118
> #7 0xffff00009e415780 at ure_attach_post+0x1a78
> #8 0xffff000000391d6c at ue_attach_post_task+0x3c
> #9 0xffff0000003826e0 at usb_process+0x10c
> #10 0xffff0000004baa1c at fork_exit+0x7c
> #11 0xffff000000816544 at fork_trampoline+0x10
> uma_zalloc_debug: zone "malloc-32" with the following non-sleepable locks held:
> exclusive sleep mutex ure0 (ure0) r = 0 (0xffffa00002b2cea0) locked @ /usr/src/sys/dev/usb/usb_request.c:714
> stack backtrace:
> #0 0xffff00000056d388 at witness_debugger+0x64
> #1 0xffff00000056e518 at witness_warn+0x3ec
> #2 0xffff000000778f9c at uma_zalloc_debug+0x2c
> #3 0xffff000000778998 at uma_zalloc_arg+0x2c
> #4 0xffff0000004d534c at malloc+0xa0
> #5 0xffff00000050ef3c at sysctl_add_oid+0x170
> #6 0xffff00009e415780 at ure_attach_post+0x1a78
> #7 0xffff000000391d6c at ue_attach_post_task+0x3c
> #8 0xffff0000003826e0 at usb_process+0x10c
> #9 0xffff0000004baa1c at fork_exit+0x7c
> #10 0xffff000000816544 at fork_trampoline+0x10
> miibus0: <MII bus> on ure0
> rgephy0: <RTL8251/8153 1000BASE-T media interface> PHY 0 on miibus0
> add hrgephy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto
> 0 fib 0: route already iue0: <USB Ethernet> on ure0
> 
> 
> 
> The context here is an RPi4 (aarch64 cortex-a72) with:
> 
> # uname -apKU
> FreeBSD RPi4B 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r368500: Thu Dec 10 07:52:39 UTC 2020     root at FreeBSD-head-aarch64-build.jail.ci.FreeBSD.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC  arm64 aarch64 1300131 1300131
> 
> The boot attempts were via uefi/ACPI using https://github.com/pftf/RPi4
> v1.21 materials, directly booting from the USB3 SSD, no microsd card
> involved.
> 
> 
> Some context in case it contributes something for the above
> (probably not) . . .
> 
> The reason for the bisect was: such boot attempts fail to mount
> route with my non-debug head -r368500 kernel build. (Previously
> the RPi4 was back at head -r365932 or so.) But my non-debug
> builds use -mcpu=cortex-a72 . (This combination has caught
> missing synchronization activity before.)
> 
> In the failing case the following never shows up:
> 
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0: <OWC Envoy Pro mini 0> Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number REPLACED
> da0: 400.000MB/s transfers
> da0: 228936MB (468862128 512 byte sectors)
> da0: quirks=0x2<NO_6_BYTE>
> 
> and the message:
> 
> Root mount waiting for: usbus0
> 
> repeats indefinitely, unlike historically for my configuration.
> 
> With the artifact debug kernel instead of the non-debug
> kernel, the RPi4 boots fine, other things held constant.


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


From marklmi at yahoo.com  Sat Dec 19 08:13:17 2020
From: marklmi at yahoo.com (Mark Millard)
Date: Sat, 19 Dec 2020 00:13:06 -0800
Subject: RPi4 (8 GiByte) example: non-debug head -r368500 kernel fails to
 mount root where artifact debug kernel works fine (uefi/ACPI boot)
References: <4D39055C-A0B8-4E2C-AA2C-F703D5061771.ref@yahoo.com>
Message-ID: <4D39055C-A0B8-4E2C-AA2C-F703D5061771@yahoo.com>

The boot attempts were via uefi/ACPI using https://github.com/pftf/RPi4
v1.21 materials, directly booting from the USB3 SSD, no microsd card
involved.

Non-debug kernels built for cortex-A72 and for cortex-A53 both got the
behavior that leads mount root failure. (This tends to eliminate some types
of missing synchronization as a potential issue: in the past the cortex-a72
style of build caught a problem that cortex-a53 builds did not show. So my
original thought to cc hps may have been a waste.) Still, the below is
based on my usual cortex-a72 based kernel being used as the non-debug kernel
example.

The artifact debug kernel from:

https://artifact.ci.freebsd.org/snapshot/13.0-CURRENT/r368500/arm64/aarch64/kernel.txz

does not get the problem.

The prior RPi4 context was back at head -r365932 or so and back then
the combination worked. The FreeBSD upgrade is recent.

In the failing contexts (i.e., non-debug contexts), the following
never shows up:

da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0: <OWC Envoy Pro mini 0> Fixed Direct Access SPC-4 SCSI device
da0: Serial Number REPLACED
da0: 400.000MB/s transfers
da0: 228936MB (468862128 512 byte sectors)
da0: quirks=0x2<NO_6_BYTE>

and the message:

Root mount waiting for: usbus0

repeats indefinitely, unlike historically for my configuration.


Capturing and diffing boot -v output did not show much interesting
but here is the range with usbusN and the like (+: for artifact debug
kernel, -: for non-debug -mcpu=cortex-a72 kernel):

@@ -197,18 +198,18 @@
 vlan: initialized, using hash tables with chaining
 IPsec: Initialized Security Association Processing.
 tcp_init: net.inet.tcp.tcbhashsize auto tuned to 32768
-AcpiOsExecute: enqueue 1 pending tasks
 usbus0: 5.0Gbps Super Speed USB v3.0
 usbus1: 480Mbps High Speed USB v2.0
-Release APs...Trying to mount root from ufs:/dev/gpt/RPi4Broot []...
-done
-Root mount waiting for: usbus0CPU  0: ARM Cortex-A72 r0p3 affinity:  0
- usbus1                   Cache Type = <64 byte D-cacheline,64 byte I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG>
- CAM
- Instruction Set Attributes 0 = <CRC32>
- Instruction Set Attributes 1 = <>
-         Processor Features 0 = <AdvSIMD,FP,EL3 32,EL2 32,EL1 32,EL0 32>
-         Processor Features 1 = <>
+AcpiOsExecute: enqueue 1 pending tasks
+Release APs...done
+CPU  0: ARM Cortex-A72 r0p3 affinity:  0
+Trying to mount root from ufs:/dev/gpt/RPi4Broot []...
+                   Cache Type = <64 byte D-cacheline,64 byte I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG>
+Root mount waiting for: Instruction Set Attributes 0 = <CRC32>
+ usbus0 Instruction Set Attributes 1 = <>
+ usbus1         Processor Features 0 = <AdvSIMD,FP,EL3 32,EL2 32,EL1 32,EL0 32>
+ CAM         Processor Features 1 = <>
+
       Memory Model Features 0 = <TGran4,TGran64,SNSMem,BigEnd,16bit ASID,16TB PA>
       Memory Model Features 1 = <8bit VMID>
       Memory Model Features 2 = <32bit CCIDX,48bit VA>
@@ -219,12 +220,13 @@
 CPU  1: ARM Cortex-A72 r0p3 affinity:  1
 CPU  2: ARM Cortex-A72 r0p3 affinity:  2
 CPU  3: ARM Cortex-A72 r0p3 affinity:  3
+WARNING: WITNESS option enabled, expect reduced performance.
 regulator: shutting down unused regulators
 ugen1.1: <DWCOTG OTG Root HUB> at usbus1
 ugen0.1: <Generic XHCI root HUB> at usbus0
 uhub0 on usbus1
-uhub0: <DWCOTG OTG Root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
 uhub1 on usbus0
+uhub0: <DWCOTG OTG Root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
 uhub1: <Generic XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
 uhub0: 1 port with 1 removable, self powered
 uhub1: 5 ports with 4 removable, self powered
@@ -233,15 +235,28 @@
 uhub2: <vendor 0x2109 USB2.0 Hub, class 9/0, rev 2.10/4.21, addr 1> on usbus0
 Root mount waiting for: usbus0 CAM
 uhub2: 4 ports with 4 removable, self powered
-Root mount waiting for: usbus0 CAM
 ugen0.3: <Realtek USB 10/100/1000 LAN> at usbus0
 Root mount waiting for: usbus0 CAM
 Root mount waiting for: usbus0 CAM
-Root mount waiting for: usbus0 CAM
-Root mount waiting for: usbus0 CAM
-Root mount waiting for: usbus0 CAM
-Root mount waiting for: usbus0 CAM
-Root mount waiting for: usbus0 CAM
-Root mount waiting for: usbus0
-Root mount waiting for: usbus0
-Root mount waiting for: usbus0
+ugen0.4: <OWC Envoy Pro mini> at usbus0
+umass0 on uhub1
+umass0: <OWC Envoy Pro mini, class 0/0, rev 3.00/1.00, addr 3> on usbus0
+umass0:  SCSI over Bulk-Only; quirks = 0x0100
+umass0:0:0: Attached to scbus0
+Root mount waiting for: CAM
+Root mount waiting for: CAM
+Root mount waiting for: CAM
+Root mount waiting for: CAM
+Root mount waiting for: CAM
+GEOM: new disk da0
+pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0
+pass0: <OWC Envoy Pro mini 0> Fixed Direct Access SPC-4 SCSI device
+pass0: Serial Number REPLACED
+pass0: 400.000MB/s transfers
+da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
+da0: <OWC Envoy Pro mini 0> Fixed Direct Access SPC-4 SCSI device
+da0: Serial Number REPLACED
+da0: 400.000MB/s transfers
+da0: 228936MB (468862128 512 byte sectors)
+da0: quirks=0x2<NO_6_BYTE>
+da0: Delete methods: <NONE(*),ZERO>

(I did not include more of the waiting-for messages for the
non-debug kernel ("-"). I see no reason to have later text
from the debug kernel case ("+").)

I do have a working u-boot 2020.10 based, microsd card first-stages
boot for the same USB3 SSD that mounts the same root file system
just fine. The kernel is a copy of the same non-debug kernel that
the the above used, but the used copy is on the microsd card for
this type of booting. (The u-boot is not ready to deal with
USB-based booting of 8 GiByte RPi4's.)

So it seems that having both ACPI-boot-style and non-debug kernel
use combined are somehow involved to get the problem.

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


From hps at selasky.org  Sat Dec 19 11:09:59 2020
From: hps at selasky.org (Hans Petter Selasky)
Date: Sat, 19 Dec 2020 12:09:48 +0100
Subject: debug head -r368500 kernel (for example) : "lock order reversal:
 (sleepable after non-sleepable)" involving ure0 and a sysctl lock;
 more
In-Reply-To: <3392879C-F0DC-4F14-9C48-1ADD94214D49@yahoo.com>
References: <E58350E3-EB33-410C-AC20-E25A9A78D5C2@yahoo.com>
 <3392879C-F0DC-4F14-9C48-1ADD94214D49@yahoo.com>
Message-ID: <9373329c-42ad-14c3-c236-b340b865d05e@selasky.org>

Please test:

https://svnweb.freebsd.org/changeset/base/368799
https://svnweb.freebsd.org/changeset/base/368801

--HPS

From mueller6722 at twc.com  Sat Dec 19 12:35:13 2020
From: mueller6722 at twc.com (Thomas Mueller)
Date: Sat, 19 Dec 2020 12:35:13 -0000
Subject: git tools for building in base?
References: <X714z7pMgNOFaTIc@rpi4.local>
 <20201125055425.01AA628417@elsa.codelab.cz>
 <10f7b800-b015-2a80-b741-4f7db03bf6eb@quip.cz>
 <e3dce606-1a28-886f-b481-7f1d224d82cc@madpilot.net>
 <CANCZdfq0XOuJ--2jXVY42Nkxpu4YnuoCpoy4vVDo9o4hUp6ATw@mail.gmail.com>
 <CALH631nJ_cnfLhG+SDX5Mchk2+RrfFn=38rXYrFwVxV+tG_QkQ@mail.gmail.com>
 <CANCZdfqwpm+9v5yutsa6_mHdPC8CSKZTCtHMuSEUjpQFcEfDKQ@mail.gmail.com>
Message-ID: <mailman.5.1608381314.98902.freebsd-current@freebsd.org>

> Yes. I was answering the first question asked about FreeBSD and git...

> The clincher for me was that git is better supported by third party tools
> and has gotten quite good at 'recovery from oops' which mercurial is still
> lacking in both areas. I too have used both, and I had to re clone my hg
> tree several times, but so far have never screwed up a git repo so bad I
> had to reclone... The history rewriting of git is more integrated and more
> polished than the equivalent in hg, as are the rebase workflows which
> really help have a cleaner history...

> Warner (Losh)

I have messed up a git repo and had to reclone, but can't compare to mercurial because I have not yet used mercurial.

Maybe I was inept with git.

I notice many more open-source projects use git than mercurial, maybe because of the reasons explained in your post.

I still see no timeline on when NetBSD will switch to mercurial, or if they could possibly change their mind in favor of git or otherwise.

OpenBSD looks to be still using CVS, while DragonFlyBSD uses git.

It looks like T2 project (t2sde.org) still uses subversion.

Tom


From grahamperrin at gmail.com  Sat Dec 19 14:35:15 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Sat, 19 Dec 2020 14:35:11 +0000
Subject: =?UTF-8?Q?=28251866=29_installers_for_FreeBSD_fail_to_boot_HP_Elite?=
 =?UTF-8?Q?Book_830_G7=2c_440_G7_=e2=80=a6?=
In-Reply-To: <8aa45f8c-7b14-a264-a8b7-9dd0b6b36f59@bsdio.com>
References: <86360c9p2p.fsf@gmail.com>
 <8cd298fa-5b16-d58b-b63b-201905f83438@gmail.com>
 <8aa45f8c-7b14-a264-a8b7-9dd0b6b36f59@bsdio.com>
Message-ID: <36c65b46-58d9-9f03-9e31-d27cfb7a6dba@gmail.com>

On 12/12/2020 19:18, Rebecca Cran wrote:
> On 12/11/2020 8:03 PM, Graham Perrin wrote:
>> On 11/12/2020 18:26, Ludovit Koren wrote:
>>
>>> ?
>> Probably 
>> <https://lists.freebsd.org/pipermail/freebsd-current/2020-December/077759.html>
>
> This crash also happens on VMware Workstation 16 Pro with 13-CURRENT. 
> I'm hoping to find some time to debug it.

Via <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251866>:

<https://svnweb.freebsd.org/base?view=revision&revision=368721>

 > Drop EFI_STAGING_SIZE back down to 64M ?


From mhorne at freebsd.org  Sat Dec 19 18:17:24 2020
From: mhorne at freebsd.org (Mitchell Horne)
Date: Sat, 19 Dec 2020 14:17:14 -0400
Subject: RISC-V root device question -> Panic
In-Reply-To: <e9ff294d-620e-0466-4ccd-4acf1eb340ff@callfortesting.org>
References: <4fcf5f35-481b-a321-cb52-7264fc10d1d4@callfortesting.org>
 <CADeAsy0jyHx10pQ5NRYzuk2gjMGOf4Of5jGOL-0BmoN5PVJd5A@mail.gmail.com>
 <e9ff294d-620e-0466-4ccd-4acf1eb340ff@callfortesting.org>
Message-ID: <CADeAsy07h2s58TxoO48zVMf8mXBm7tSMEbC6Co-2pKmvgs0kNw@mail.gmail.com>

On Mon, Dec 14, 2020 at 6:03 PM Michael Dexter
<editor at callfortesting.org> wrote:
>
> Mitchell,
>
> On 12/7/20 1:56 PM, Mitchell Horne wrote:
> > You can also override it using the QEMU commandline, which is simpler
> > since you won't need to recompile anything. Adding the following
> > argument should suffice:
>
> This works great but riscv 12-STABLE using last week's snapshot revision
> throws the panic output included below under QEMU and leaves nothing in
> /var/crash
>
> What expectations should I set for RISC-V STABLE and CURRENT?
>

Hi Michael, sorry for my delayed reply.

Development and testing has been almost entirely focused on CURRENT. I
believe riscv64 may have been functional on stable/12 at some point
(and we even made an effort to MFC changes there), but it is not used
anymore as far as I know. The expectations I would set going forward
are that 13.0 will be the first functional release for the
architecture (including stable/13 when it is branched), and stable/12
will remain unsupported.

Also, to follow up on earlier items in this thread, I have documented
how to generate a bootable RISC-V image containing an EFI partition
with loader.efi. If you encounter any issues with the instructions,
please let me know.
https://wiki.freebsd.org/riscv/QEMU#Generate_a_root_filesystem

Cheers,
Mitchell

> All the best,
>
> Michael
>
> t[0] == 0xffffffc0006c9d98
> t[1] == 0x0000000040c50000
> t[2] == 0x0000000040c65000
> t[3] == 0x0000000000000001
> t[4] == 0x0000000000000000
> t[5] == 0x0000000000000001
> t[6] == 0x0000000000000001
> s[0] == 0xffffffd0b1600248
> s[1] == 0x0000000040e49000
> s[2] == 0xfffffffffffff000
> s[3] == 0x00000000000000ff
> s[4] == 0x0000000041000000
> s[5] == 0x0000000000000001
> s[6] == 0xffffffc000aff988
> s[7] == 0x00000000410a1000
> s[8] == 0x0000000000000280
> s[9] == 0x0000000000000000
> s[10] == 0x0000000000001000
> s[11] == 0xffffffffffffff73
> a[0] == 0x0000000000000000
> a[1] == 0xffffffd00297d560
> a[2] == 0x0000000000000000
> a[3] == 0x0000000000000021
> a[4] == 0x0000000000000000
> a[5] == 0x0000000000000021
> a[6] == 0x000000000000003f
> a[7] == 0xffffffc000aff900
> sepc == 0xffffffc0004ce414
> sstatus == 0x0000000000000120
> panic: Fatal page fault at 0xffffffc0004ce414: 0x00000000000065
> cpuid = 1
> time = 1607915275
> KDB: stack backtrace:
> #0 0xffffffc00023f2d4 at kdb_backtrace+0x50
> Uptime: 2d1h40m41s
> Automatic reboot in 15 seconds - press a key on the console to abort
> Rebooting...

From grahamperrin at gmail.com  Sat Dec 19 21:21:21 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Sat, 19 Dec 2020 21:21:17 +0000
Subject: FreeBSD-CURRENT VirtualBox guest: EFI: lost the ability to boot
Message-ID: <e0a39b2f-df6a-cc67-b302-00c0f35e1fbc@gmail.com>

With VirtualBox on an r368589 host I installed the latest (17th 
December) snapshot of 13.0-CURRENT in a guest machine. I set the guest 
to EFI before installation, and chose GPT (UEFI) during installation.

After installing KDE Plasma etc., the guest worked for a short while but 
then failed to boot. Screenshots at <https://imgur.com/a/xoYHwbT>; 
scroll down to 17:49:06 for a shot of a failure.

Is this maybe another case of bug 251866? 
<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251866>


From tsoome at me.com  Sat Dec 19 21:30:04 2020
From: tsoome at me.com (Toomas Soome)
Date: Sat, 19 Dec 2020 23:29:52 +0200
Subject: FreeBSD-CURRENT VirtualBox guest: EFI: lost the ability to boot
In-Reply-To: <e0a39b2f-df6a-cc67-b302-00c0f35e1fbc@gmail.com>
References: <e0a39b2f-df6a-cc67-b302-00c0f35e1fbc@gmail.com>
Message-ID: <34449A43-79AD-4644-8A9A-ACA693E01287@me.com>



> On 19. Dec 2020, at 23:21, Graham Perrin <grahamperrin at gmail.com> wrote:
> 
> With VirtualBox on an r368589 host I installed the latest (17th December) snapshot of 13.0-CURRENT in a guest machine. I set the guest to EFI before installation, and chose GPT (UEFI) during installation.
> 
> After installing KDE Plasma etc., the guest worked for a short while but then failed to boot. Screenshots at <https://imgur.com/a/xoYHwbT>; scroll down to 17:49:06 for a shot of a failure.
> 
> Is this maybe another case of bug 251866? <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251866>
> 
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org?


Do You mean the screenshot with UEFI shell? You usually do drop to UEFI shell when firmware did decide it can not start your efi application. Other option is, we got failure and did exit loader.efi.

it may help if you attempt to start loader.efi manually from ESP, by entering: FS0:/efi/boot/bootx64.efi  ? there may appear some messages...

rgds,
toomas

From marklmi at yahoo.com  Sat Dec 19 22:47:43 2020
From: marklmi at yahoo.com (Mark Millard)
Date: Sat, 19 Dec 2020 14:47:36 -0800
Subject: debug head -r368500 kernel (for example) : "lock order reversal:
 (sleepable after non-sleepable)" involving ure0 and a sysctl lock;
 more
In-Reply-To: <9373329c-42ad-14c3-c236-b340b865d05e@selasky.org>
References: <E58350E3-EB33-410C-AC20-E25A9A78D5C2@yahoo.com>
 <3392879C-F0DC-4F14-9C48-1ADD94214D49@yahoo.com>
 <9373329c-42ad-14c3-c236-b340b865d05e@selasky.org>
Message-ID: <F5ADB94A-401E-4134-BDD1-2AD0F9B102B2@yahoo.com>



On 2020-Dec-19, at 03:09, Hans Petter Selasky <hps at selasky.org> wrote:

> Please test:
> 
> https://svnweb.freebsd.org/changeset/base/368799
> https://svnweb.freebsd.org/changeset/base/368801
> 
> --HPS

I grabbed a debug -r368803 kernel from artifacts (first arm64
snapshot available containing the above 2 updates):

https://artifact.ci.freebsd.org/snapshot/13.0-CURRENT/r368803/arm64/aarch64/kernel.txz

I used it to substitute in the updated debug kernel and booted
the same configuration.

It booted fine with no LOR or uma_zalloc_debug related console
output.

I've not tried my own non-debug build yet but that kind of
context had never given me a clue of these issues anyway. (I
am not expecting the above to change the non-debug "Root mount
waiting for: usbus0" for the uefi/ACPI USB3 SSD based boot
sequence.)


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


From imp at bsdimp.com  Sat Dec 19 23:20:10 2020
From: imp at bsdimp.com (Warner Losh)
Date: Sat, 19 Dec 2020 16:20:01 -0700
Subject: FreeBSD-CURRENT VirtualBox guest: EFI: lost the ability to boot
In-Reply-To: <e0a39b2f-df6a-cc67-b302-00c0f35e1fbc@gmail.com>
References: <e0a39b2f-df6a-cc67-b302-00c0f35e1fbc@gmail.com>
Message-ID: <CANCZdfo7-R96zEAObjr+PNTFVYFp_H-d31XGEtWT11udy1iPkw@mail.gmail.com>

On Sat, Dec 19, 2020 at 2:21 PM Graham Perrin <grahamperrin at gmail.com>
wrote:

> With VirtualBox on an r368589 host I installed the latest (17th
> December) snapshot of 13.0-CURRENT in a guest machine. I set the guest
> to EFI before installation, and chose GPT (UEFI) during installation.
>
> After installing KDE Plasma etc., the guest worked for a short while but
> then failed to boot. Screenshots at <https://imgur.com/a/xoYHwbT>;
> scroll down to 17:49:06 for a shot of a failure.
>
> Is this maybe another case of bug 251866?
> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251866>
>

Try the next snapshot... I just fixed this in -current... or so I claim.
Please validate my claim. :)

Though unless there's a bunch of stuff where the boot loader fails and then
loads the shell, maybe not...

You need to check you ESP to make sure there's a bootx64.efi in \efi\boot\
as well... that would also kick you into the shell...

Warner

From grahamperrin at gmail.com  Sun Dec 20 00:31:13 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Sun, 20 Dec 2020 00:31:08 +0000
Subject: FreeBSD-CURRENT VirtualBox guest: EFI: lost the ability to boot
In-Reply-To: <CANCZdfo7-R96zEAObjr+PNTFVYFp_H-d31XGEtWT11udy1iPkw@mail.gmail.com>
References: <e0a39b2f-df6a-cc67-b302-00c0f35e1fbc@gmail.com>
 <CANCZdfo7-R96zEAObjr+PNTFVYFp_H-d31XGEtWT11udy1iPkw@mail.gmail.com>
Message-ID: <874b669a-9b8f-a457-653b-05b888419aae@gmail.com>

On 19/12/2020 23:20, Warner Losh wrote:
>
>
> On Sat, Dec 19, 2020 at 2:21 PM Graham Perrin <grahamperrin at gmail.com 
> <mailto:grahamperrin at gmail.com>> wrote:
>
>     With VirtualBox on an r368589 host I installed the latest (17th
>     December) snapshot of 13.0-CURRENT in a guest machine. I set the
>     guest
>     to EFI before installation, and chose GPT (UEFI) during installation.
>
>     After installing KDE Plasma etc., the guest worked for a short
>     while but
>     then failed to boot. Screenshots at <https://imgur.com/a/xoYHwbT
>     <https://imgur.com/a/xoYHwbT>>;
>     scroll down to 17:49:06 for a shot of a failure.
>
>     Is this maybe another case of bug 251866?
>     <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251866
>     <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251866>>
>
>
> Try the next snapshot... I just fixed this in -current... or so I 
> claim. Please validate my claim. :)
>
> Though unless there's a bunch of stuff where the boot loader fails?and 
> then loads the shell, maybe not...
>
> You need to check you ESP to make sure there's a bootx64.efi in 
> \efi\boot\ as well... that would also kick you into the shell...
>
> Warner


Thanks, will the next snapshot be on/around 24th December? Or later, 
with the festive season?

In the meantime I added four shots to the album. With the boot 
maintenance manager of VirtualBox, I <https://imgur.com/BTsj4zS> 
navigated to loader.efi, added it as a boot option (I lazily named it 
'loader.efi') then set it as primary <https://imgur.com/FYnHynr> after 
which:

* normal resets or restarts of the VM do successfully boot

? and if I change the boot order to make 'EFI Hard Drive' primary and 
'loader.efi' last, boots fail (drop outs to the EFI shell).

<https://imgur.com/MYLowDt> and <https://imgur.com/G3SKMZh> it appears 
that 'EFI Hard Drive' and 'EFI DVD/CDROM' have the same path. Surely 
wrong, I can think of nothing that might have caused this.

Graham


From grahamperrin at gmail.com  Sun Dec 20 23:10:28 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Sun, 20 Dec 2020 23:10:22 +0000
Subject: FreeBSD-CURRENT VirtualBox guest: EFI: lost the ability to boot
In-Reply-To: <874b669a-9b8f-a457-653b-05b888419aae@gmail.com>
References: <e0a39b2f-df6a-cc67-b302-00c0f35e1fbc@gmail.com>
 <CANCZdfo7-R96zEAObjr+PNTFVYFp_H-d31XGEtWT11udy1iPkw@mail.gmail.com>
 <874b669a-9b8f-a457-653b-05b888419aae@gmail.com>
Message-ID: <82854cb2-086c-f27d-d2e3-0681099b3bfe@gmail.com>

On 20/12/2020 00:31, Graham Perrin wrote:
>
> ? With the boot maintenance manager of VirtualBox, I 
> <https://imgur.com/BTsj4zS> navigated to loader.efi, added it as a 
> boot option (I lazily named it 'loader.efi') then set it as primary 
> <https://imgur.com/FYnHynr> after which:
>
> * normal resets or restarts of the VM do successfully boot
>
> ? and if I change the boot order to make 'EFI Hard Drive' primary and 
> 'loader.efi' last, boots fail (drop outs to the EFI shell).
>
> <https://imgur.com/MYLowDt> and <https://imgur.com/G3SKMZh> it appears 
> that 'EFI Hard Drive' and 'EFI DVD/CDROM' have the same path. Surely 
> wrong, I can think of nothing that might have caused this.
>
The boot manager of VirtualBox repeatedly lost the working boot option 
that I repeatedly added, leaving a non-working 'EFI Hard drive' option.

I tried releasing the virtual disk, creating a new hard disk-less 
virtual machine with EFI enabled, then added the disk. First boot 
failed, dropped to EFI. It worked after I manually added a boot option 
to the boot manager but then again the working option was lost.

Is this symptomatic of a bug with VirtualBox?

This weekend I sort of lost the ability to think straight :-)


From guru at unixarea.de  Mon Dec 21 11:05:12 2020
From: guru at unixarea.de (Matthias Apitz)
Date: Mon, 21 Dec 2020 12:05:08 +0100
Subject: [Bug 251727] [sound] [snd_hda] After update to r368166 no sound
 recording with internal microphone
In-Reply-To: <bug-251727-24505-gRqUZFqrzk@https.bugs.freebsd.org/bugzilla/>
References: <bug-251727-24505@https.bugs.freebsd.org/bugzilla/>
 <bug-251727-24505-gRqUZFqrzk@https.bugs.freebsd.org/bugzilla/>
Message-ID: <X+CBZJgUTCKCH4rq@c720-r368166.fritz.box>

El d?a viernes, diciembre 18, 2020 a las 09:20:17a. m. +0000, bugzilla-noreply at freebsd.org escribi?:

> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251727
> 
> --- Comment #11 from Andriy Gapon <avg at FreeBSD.org> ---
> (In reply to Matthias Apitz from comment #10)
> This looks good to me.
> 

Thanks. What is the procedure now to get the patch ci'ed?

	matthias


-- 
Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045
Public GnuPG key: http://www.unixarea.de/key.pub

From warlock at phouka.net  Mon Dec 21 20:50:19 2020
From: warlock at phouka.net (John Kennedy)
Date: Mon, 21 Dec 2020 12:47:38 -0800
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
Message-ID: <X+EJ6rvSLoEx7ksp@phouka1.phouka.net>

On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote:
> The FreeBSD project will be moving it's source repo from subversion to git
> starting this this weekend. The docs repo was moved 2 weeks ago. The ports
> repo will move at the end of March, 2021 due to timing issues. ...

  I filed Bug 252028 (sys/conf/newvers.sh: git "-dirty" even when clean),
but that's just a trivial issue with my source tree being marked -dirty
when it isn't, and that would have been part of r368709 anyway.  All my
other git nits have been my own (refs/notes and origin name).


From tsoome at me.com  Mon Dec 21 21:04:26 2020
From: tsoome at me.com (Toomas Soome)
Date: Mon, 21 Dec 2020 23:04:12 +0200
Subject: review request: loader: implement framebuffer console
In-Reply-To: <eejs-jxhr-wny@FreeBSD.org>
References: <EAD2C1D7-8D64-43D4-A2EC-E21FE3CC733B@me.com>
 <eejs-ld5t-wny@FreeBSD.org> <eejs-jxhr-wny@FreeBSD.org>
Message-ID: <E897FF1F-04EB-4E60-9DA2-607705685281@me.com>


Hi!

I?m sorry, the reponse too a bit:) I had to find and fix few issues first and then we got git:D

Anyhow, with git you can use git am to apply this diff: http://148-52-235-80.sta.estpak.ee/0001-loader-implement-framebuffer-console.patch <http://148-52-235-80.sta.estpak.ee/0001-loader-implement-framebuffer-console.patch>

(phab is also updated).

thanks,
toomas


> On 14. Dec 2020, at 16:03, Jan Beich <jbeich at FreeBSD.org> wrote:
> 
> Jan Beich <jbeich at FreeBSD.org> writes:
> 
>> Toomas Soome <tsoome at me.com> writes:
>> 
>>> hi!
>>> 
>>> I have been working on proper framebuffer support on FreeBSD loader
>>> and there is the current state: https://reviews.freebsd.org/D27420
>>> <https://reviews.freebsd.org/D27420>
>>> 
>>> All feedback is welcome, and especially if you can spare some time for testing:)
>> 
>> Do you have another source? Phabricator excludes some files e.g.,
>> 
>>  $ fetch 'https://reviews.freebsd.org/D27420?download=true' | patch -Efsp0
>>  $ make -sj8 buildworld
>>  [...]
>>  ===> stand/images (all)
>>  make[4]: make[4]: don't know how to make freebsd-brand-rev.png. Stop
> 
> FWIW, I've tried CLI but no joy:
> 
>  $ svn status
>  $ pkg install arcanist-php80
>  $ arc patch D27420
>  PHP Deprecated:  Function libxml_disable_entity_loader() is deprecated in /usr/local/lib/php/arcanist/support/init/init-script.php on line 92
> 
>  Deprecated: Function libxml_disable_entity_loader() is deprecated in /usr/local/lib/php/arcanist/support/init/init-script.php on line 92
>  [2020-12-14 13:42:12] EXCEPTION: (Exception) Error while loading file "/usr/local/lib/php/arcanist/src/workflow/ArcanistWorkflow.php": Private methods cannot be final as they are never overridden by other classes at [<arcanist>/src/init/lib/PhutilBootloader.php:275]
>  arcanist()
>    #0 PhutilBootloader::executeInclude(string) called at [<arcanist>/src/init/lib/PhutilBootloader.php:207]
>    #1 PhutilBootloader::loadLibrarySource(string, string) called at [<arcanist>/src/symbols/PhutilSymbolLoader.php:422]
>    #2 PhutilSymbolLoader::loadSymbol(array) called at [<arcanist>/src/symbols/PhutilSymbolLoader.php:277]
>    #3 PhutilSymbolLoader::selectAndLoadSymbols() called at [<arcanist>/src/init/init-library.php:23]
>    #4 __phutil_autoload(string)
>    #5 class_exists(string) called at [<arcanist>/src/symbols/PhutilClassMapQuery.php:216]
>    #6 PhutilClassMapQuery::loadMap() called at [<arcanist>/src/symbols/PhutilClassMapQuery.php:184]
>    #7 PhutilClassMapQuery::execute() called at [<arcanist>/src/runtime/ArcanistRuntime.php:535]
>    #8 ArcanistRuntime::newWorkflows(ArcanistArcToolset) called at [<arcanist>/src/runtime/ArcanistRuntime.php:115]
>    #9 ArcanistRuntime::executeCore(array) called at [<arcanist>/src/runtime/ArcanistRuntime.php:37]
>    #10 ArcanistRuntime::execute(array) called at [<arcanist>/support/init/init-arcanist.php:6]
>    #11 require_once(string) called at [<arcanist>/bin/arc:10]
> 
>  $ svn status
>  $ pkg install arcanist-php74
>  $ arc patch D27420
>  [...]
>  A  (bin)  stand/images/freebsd-logo-rev.png
>  A  (bin)  stand/images/freebsd-brand.png
>  A  (bin)  stand/images/freebsd-brand-rev.png
>  A         stand/images/Makefile
>  svn: warning: W150002: 'stand/images' is already under version control
>  svn: E200009: Could not add all targets because some targets are already versioned
>  svn: E200009: Illegal target for the requested operation
>  A         stand/i386/libi386/vbe.h
>  A         stand/i386/libi386/vbe.c
>  A         stand/fonts/Makefile
>  A         stand/fonts/INDEX.fonts
>  svn: warning: W150002: 'stand/fonts' is already under version control
>  svn: E200009: Could not add all targets because some targets are already versioned
>  svn: E200009: Illegal target for the requested operation
>  A         stand/common/gfx_fb.h
>  A         stand/common/gfx_fb.c
>  A         contrib/terminus/ter-u32n.bdf
>  A         contrib/terminus/ter-u32b.bdf
>  A         contrib/terminus/ter-u28n.bdf
>  A         contrib/terminus/ter-u28b.bdf
>  A         contrib/terminus/ter-u24n.bdf
>  A         contrib/terminus/ter-u24b.bdf
>  A         contrib/terminus/ter-u22n.bdf
>  A         contrib/terminus/ter-u22b.bdf
>  A         contrib/terminus/ter-u20n.bdf
>  A         contrib/terminus/ter-u20b.bdf
>  A         contrib/terminus/ter-u18n.bdf
>  A         contrib/terminus/ter-u18b.bdf
>  A         contrib/terminus/ter-u16v.bdf
>  A         contrib/terminus/ter-u16n.bdf
>  A         contrib/terminus/ter-u16b.bdf
>  A         contrib/terminus/ter-u14v.bdf
>  A         contrib/terminus/ter-u14n.bdf
>  A         contrib/terminus/ter-u14b.bdf
>  A         contrib/terminus/ter-u12n.bdf
>  A         contrib/terminus/ter-u12b.bdf
>  svn: warning: W150002: 'contrib/terminus' is already under version control
>  svn: E200009: Could not add all targets because some targets are already versioned
>  svn: E200009: Illegal target for the requested operation
>  A         contrib/pnglite/pnglite.h
>  A         contrib/pnglite/pnglite.c
>  A         contrib/pnglite/README.md
>  A         contrib/pnglite/LICENSE
>  svn: warning: W150002: 'contrib/pnglite' is already under version control
>  svn: E200009: Could not add all targets because some targets are already versioned
>  svn: E200009: Illegal target for the requested operation
>  svn: E125004: MIME type 'application/octet-stream
>  \ No newline at end of property' contains invalid character '
>  ' in media type
>  svn: E125004: MIME type 'application/octet-stream
>  \ No newline at end of property' contains invalid character '
>  ' in media type
>  svn: E125004: MIME type 'application/octet-stream
>  \ No newline at end of property' contains invalid character '
>  ' in media type
>  svn: E135001: Unrecognized line ending style 'native
>  \ No newline at end of property' for 'stand/images/Makefile'
>  property 'svn:keywords' set on 'stand/images/Makefile'
>  svn: E125004: MIME type 'text/plain
>  \ No newline at end of property' contains invalid character '
>  ' in media type
>  svn: E135001: Unrecognized line ending style 'native
>  \ No newline at end of property' for 'stand/i386/libi386/vbe.h'
>  property 'svn:keywords' set on 'stand/i386/libi386/vbe.h'
>  svn: E125004: MIME type 'text/plain
>  \ No newline at end of property' contains invalid character '
>  ' in media type
>  svn: E135001: Unrecognized line ending style 'native
>  \ No newline at end of property' for 'stand/i386/libi386/vbe.c'
>  property 'svn:keywords' set on 'stand/i386/libi386/vbe.c'
>  svn: E125004: MIME type 'text/plain
>  \ No newline at end of property' contains invalid character '
>  ' in media type
>  svn: E135001: Unrecognized line ending style 'native
>  \ No newline at end of property' for 'stand/fonts/Makefile'
>  property 'svn:keywords' set on 'stand/fonts/Makefile'
>  svn: E125004: MIME type 'text/plain
>  \ No newline at end of property' contains invalid character '
>  ' in media type
>  svn: E135001: Unrecognized line ending style 'native
>  \ No newline at end of property' for 'stand/common/gfx_fb.h'
>  property 'svn:keywords' set on 'stand/common/gfx_fb.h'
>  svn: E125004: MIME type 'text/plain
>  \ No newline at end of property' contains invalid character '
>  ' in media type
>  svn: E135001: Unrecognized line ending style 'native
>  \ No newline at end of property' for 'stand/common/gfx_fb.c'
>  property 'svn:keywords' set on 'stand/common/gfx_fb.c'
>  svn: E125004: MIME type 'text/plain
>  \ No newline at end of property' contains invalid character '
>  ' in media type
>  svn: E135001: Unrecognized line ending style 'native
>  \ No newline at end of property' for 'contrib/pnglite/pnglite.h'
>  property 'svn:keywords' set on 'contrib/pnglite/pnglite.h'
>  svn: E125004: MIME type 'text/plain
>  \ No newline at end of property' contains invalid character '
>  ' in media type
>  svn: E135001: Unrecognized line ending style 'native
>  \ No newline at end of property' for 'contrib/pnglite/pnglite.c'
>  property 'svn:keywords' set on 'contrib/pnglite/pnglite.c'
>  svn: E125004: MIME type 'text/plain
>  \ No newline at end of property' contains invalid character '
>  ' in media type
>   OKAY  Successfully applied patch to the working copy.
> 
>  $ ls -l stand/images/*.png
>  -rw-r--r--  1 foo  foo  0 14 Dec 13:46 stand/images/freebsd-brand-rev.png
>  -rw-r--r--  1 foo  foo  0 14 Dec 13:46 stand/images/freebsd-brand.png
>  -rw-r--r--  1 foo  foo  0 14 Dec 13:46 stand/images/freebsd-logo-rev.png


From fbsd at www.zefox.net  Tue Dec 22 18:38:43 2020
From: fbsd at www.zefox.net (bob prohaska)
Date: Tue, 22 Dec 2020 10:39:00 -0800
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
Message-ID: <20201222183900.GA22353@www.zefox.net>

On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote:
> 
> The FreeBSD project will be moving it's source repo from subversion to git
> starting this this weekend. The docs repo was moved 2 weeks ago. The ports
> repo will move at the end of March, 2021 due to timing issues.
> 

Is there some way to obtain git on a Pi2B running 
13.0-CURRENT FreeBSD 13.0-CURRENT #2 r365692
without installing the ports tree? I expected 
to find git in base, but it isn't there. 

Can it be found  under another package name?

Thanks for reading, and any guidance!

bob prohaska


From marklmi at yahoo.com  Tue Dec 22 20:19:12 2020
From: marklmi at yahoo.com (Mark Millard)
Date: Tue, 22 Dec 2020 12:19:03 -0800
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <20201222183900.GA22353@www.zefox.net>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <20201222183900.GA22353@www.zefox.net>
Message-ID: <15E3F8E7-017C-4668-A7FE-EA5F24031EF3@yahoo.com>



On 2020-Dec-22, at 10:39, bob prohaska <fbsd at www.zefox.net> wrote:

> On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote:
>> 
>> The FreeBSD project will be moving it's source repo from subversion to git
>> starting this this weekend. The docs repo was moved 2 weeks ago. The ports
>> repo will move at the end of March, 2021 due to timing issues.
>> 
> 
> Is there some way to obtain git on a Pi2B running 
> 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r365692
> without installing the ports tree? I expected 
> to find git in base, but it isn't there. 
> 
> Can it be found  under another package name?
> 

git in base would have licensing issues.

Pi2B: v1.1 (armv7 only)? v1.2 running armv7 FreeBSD?
v1.2 running arm64 FreeBSD?


It does appear that arm64 ports builds have started again, or are at
least being experimented with . . .

Filling the Built search field with "/git" at:

http://ampere2.nyi.freebsd.org/build.html?mastername=head-arm64-default&build=p557699_s368500

shows that devel/git built. The context looks to be:

FreeBSD head -r368500 was used to as the context the builds were for.
Ports head   -r557699 was the vintage of the ports tree build.
This is for head-arm64-default, not a quarterly build.

It also shows devel/git at lite as having been built --and
devel/git at gui and devel/git at tiny and devel/git-lfs and
so on.

The page also reports:

Queued	Built	Failed	Skipped	Ignored	Remaining
32987	28781	304	3106	796	0
Load Averages	Swapinfo	Elapsed	Pkg/Hour	Impulse
( 4%) 1.31 1.40 1.66	4.41%	142:17:22	205	--

It is the only modern arm64 build that I found with anywhere near 28781
ports built.

Looks like this is for well after head -r365692 .

Unfortunately, https://pkg-status.freebsd.org/builds?type=package does
not yet seem to include ampere2.nyi.freebsd.org based builds.

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


From ronald-lists at klop.ws  Tue Dec 22 20:34:30 2020
From: ronald-lists at klop.ws (Ronald Klop)
Date: Tue, 22 Dec 2020 21:34:25 +0100 (CET)
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <20201222183900.GA22353@www.zefox.net>
Message-ID: <1249102000.16891.1608669265488@localhost>

Van: bob prohaska <fbsd at www.zefox.net>
Datum: 22 december 2020 19:38
Aan: freebsd-arm at freebsd.org
CC: FreeBSD Current <freebsd-current at freebsd.org>
Onderwerp: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

> 
> On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote:
> > 
> > The FreeBSD project will be moving it's source repo from subversion to git
> > starting this this weekend. The docs repo was moved 2 weeks ago. The ports
> > repo will move at the end of March, 2021 due to timing issues.
> > 
> 
> Is there some way to obtain git on a Pi2B running 
> 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r365692
> without installing the ports tree? I expected 
> to find git in base, but it isn't there. 
> 
> Can it be found  under another package name?
> 
> Thanks for reading, and any guidance!
> 
> bob prohaska
> 
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
> 
> 
> 

what does "pkg install git" do for you? 
NB: I use "pkg install git-lite". Prevents about 1000 dependencies.


Regards,
Ronald

From fbsd at www.zefox.net  Tue Dec 22 21:06:06 2020
From: fbsd at www.zefox.net (bob prohaska)
Date: Tue, 22 Dec 2020 13:06:28 -0800
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <1249102000.16891.1608669265488@localhost>
References: <20201222183900.GA22353@www.zefox.net>
 <1249102000.16891.1608669265488@localhost>
Message-ID: <20201222210628.GA34436@www.zefox.net>

On Tue, Dec 22, 2020 at 09:34:25PM +0100, Ronald Klop wrote:
> 
> what does "pkg install git" do for you? NB: I use "pkg install git-lite".
> Prevents about 1000 dependencies.
> 

That seems to have worked. It reported something about package management
not being installed, but after a prompt installed pkg-static and set
up a version of git which seems to run. Svnlite had been working without
this step..... 

This is for a Pi2B v 1.1, arm v7 only.

Using the "mini git primer" at https://hackmd.io/hJgnfzd5TMK-VHgUzshA2g
I tried to clone stable/12 expecting that the -beta would be gone.

It looks as if I'm still jumping the gun. Although 
cgit.freegbsd.org replies to ping, using

bob at www:/usr % git clone cgit.freebsd.org -b stable/12 freebsd-src

reports:

fatal: repository 'cgit.freebsd.org' does not exist

This is just a rehearsal, so I can wait, but if I've 
made other mistakes please point them out.

Thanks for your help!

bob prohaska


From kp at FreeBSD.org  Tue Dec 22 21:10:09 2020
From: kp at FreeBSD.org (Kristof Provost)
Date: Tue, 22 Dec 2020 22:10:06 +0100
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <20201222210628.GA34436@www.zefox.net>
References: <20201222183900.GA22353@www.zefox.net>
 <1249102000.16891.1608669265488@localhost>
 <20201222210628.GA34436@www.zefox.net>
Message-ID: <C6C4C6A8-E663-4425-8FAF-F5C346059A4C@FreeBSD.org>

On 22 Dec 2020, at 22:06, bob prohaska wrote:
> On Tue, Dec 22, 2020 at 09:34:25PM +0100, Ronald Klop wrote:
>>
>> what does "pkg install git" do for you? NB: I use "pkg install git-lite".
>> Prevents about 1000 dependencies.
>>
>
> That seems to have worked. It reported something about package management
> not being installed, but after a prompt installed pkg-static and set
> up a version of git which seems to run. Svnlite had been working without
> this step.....
>
> This is for a Pi2B v 1.1, arm v7 only.
>
> Using the "mini git primer" at https://hackmd.io/hJgnfzd5TMK-VHgUzshA2g
> I tried to clone stable/12 expecting that the -beta would be gone.
>
> It looks as if I'm still jumping the gun. Although
> cgit.freegbsd.org replies to ping, using
>
> bob at www:/usr % git clone cgit.freebsd.org -b stable/12 freebsd-src
>
> reports:
>
> fatal: repository 'cgit.freebsd.org' does not exist
>
That?s because you have the wrong URL for the src repo.
Try `git clone https://git.FreeBSD.org/src.git  -b stable/12 freebsd-src`

Best regards,
Kristof

From marklmi at yahoo.com  Tue Dec 22 21:31:34 2020
From: marklmi at yahoo.com (Mark Millard)
Date: Tue, 22 Dec 2020 13:31:23 -0800
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <20201222210628.GA34436@www.zefox.net>
References: <20201222183900.GA22353@www.zefox.net>
 <1249102000.16891.1608669265488@localhost>
 <20201222210628.GA34436@www.zefox.net>
Message-ID: <19860CB5-716C-47A9-BB96-0EA16051DD9D@yahoo.com>



On 2020-Dec-22, at 13:06, bob prohaska <fbsd at www.zefox.net> wrote:

> On Tue, Dec 22, 2020 at 09:34:25PM +0100, Ronald Klop wrote:
>> 
>> what does "pkg install git" do for you? NB: I use "pkg install git-lite".
>> Prevents about 1000 dependencies.
>> 
> 
> That seems to have worked. It reported something about package management
> not being installed, but after a prompt installed pkg-static and set
> up a version of git which seems to run. Svnlite had been working without
> this step..... 
> 
> This is for a Pi2B v 1.1, arm v7 only.

Ahh. As far as I know armv7 ports have been building right along. It was
arm64 that had the old build system fail as I understand.

> Using the "mini git primer" at https://hackmd.io/hJgnfzd5TMK-VHgUzshA2g
> I tried to clone stable/12 expecting that the -beta would be gone.
> 
> It looks as if I'm still jumping the gun. Although 
> cgit.freegbsd.org replies to ping, using
> 
> bob at www:/usr % git clone cgit.freebsd.org -b stable/12 freebsd-src
> 
> reports:
> 
> fatal: repository 'cgit.freebsd.org' does not exist
> 
> This is just a rehearsal, so I can wait, but if I've 
> made other mistakes please point them out.

cgit.freebsd.org is not for getting clones from, just like svnweb.freebsd.org
was not for getting svn from.

Using main as an example, not stable/12 . . .

The bottom of the page https://cgit.freebsd.org/src/ shows 3 URL's for
use in cloning src:

Clone
https://git.FreeBSD.org/src.git
anongit at git.FreeBSD.org:src.git
git at gitrepo.FreeBSD.org:src.git

The last two are not explicit about notation like ssh: prefixes.

I cloned FreeBSD's src.git via:

git clone -o freebsd --config remote.freebsd.fetch='+refs/notes/*:refs/notes/*' ssh://anongit at git.freebsd.org/src.git freebsd-src

Other than using the ssh: style, I got the command notation from
part of:

https://github.com/bsdimp/freebsd-git-docs/blob/main/src-cvt.md

The remote.freebsd.fetch related material allows for finding the svn version
numbers for the older content.

Checking out stable/12 from the clone should be possible after the above, but
that is not what I've been doing.

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


From fbsd at www.zefox.net  Tue Dec 22 21:50:45 2020
From: fbsd at www.zefox.net (bob prohaska)
Date: Tue, 22 Dec 2020 13:51:10 -0800
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <15E3F8E7-017C-4668-A7FE-EA5F24031EF3@yahoo.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <20201222183900.GA22353@www.zefox.net>
 <15E3F8E7-017C-4668-A7FE-EA5F24031EF3@yahoo.com>
Message-ID: <20201222215110.GA36029@www.zefox.net>

On Tue, Dec 22, 2020 at 12:19:03PM -0800, Mark Millard wrote:
> 
> git in base would have licensing issues.
> 
I gather you're referring to GPLv2. A sticky wicket.

The trouble with ports is the tree is getting awfully big.
The host in question has a 32 GB disk and is over half full
with just a base source installation. Adding a "dormant"
ports tree will take nearly 2 GB, most of which is not used.

Might there be some way to clone a "sparse tree" including 
only one port, which then leafs out just enough to build that
port and dependencies? 

When the ports system was introduced it seemed a marvel of
compactness and efficiency. Time marches on.

> Pi2B: v1.1 (armv7 only)? v1.2 running armv7 FreeBSD?
> v1.2 running arm64 FreeBSD?
>
Sorry for the ambiguity... It's v1.1, armv7 only. That's
why I want to test git on this particular machine. Git
seems to work fine on the Pi3.

Thanks for replying!

bob prohaska


From marklmi at yahoo.com  Tue Dec 22 21:51:03 2020
From: marklmi at yahoo.com (Mark Millard)
Date: Tue, 22 Dec 2020 13:50:53 -0800
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <19860CB5-716C-47A9-BB96-0EA16051DD9D@yahoo.com>
References: <20201222183900.GA22353@www.zefox.net>
 <1249102000.16891.1608669265488@localhost>
 <20201222210628.GA34436@www.zefox.net>
 <19860CB5-716C-47A9-BB96-0EA16051DD9D@yahoo.com>
Message-ID: <28028C56-7E5A-4961-8F09-36351CDDFF20@yahoo.com>



On 2020-Dec-22, at 13:31, Mark Millard <marklmi at yahoo.com> wrote:



> On 2020-Dec-22, at 13:06, bob prohaska <fbsd at www.zefox.net> wrote:
> 
>> On Tue, Dec 22, 2020 at 09:34:25PM +0100, Ronald Klop wrote:
>>> 
>>> what does "pkg install git" do for you? NB: I use "pkg install git-lite".
>>> Prevents about 1000 dependencies.
>>> 
>> 
>> That seems to have worked. It reported something about package management
>> not being installed, but after a prompt installed pkg-static and set
>> up a version of git which seems to run. Svnlite had been working without
>> this step..... 
>> 
>> This is for a Pi2B v 1.1, arm v7 only.
> 
> Ahh. As far as I know armv7 ports have been building right along. It was
> arm64 that had the old build system fail as I understand.
> 
>> Using the "mini git primer" at https://hackmd.io/hJgnfzd5TMK-VHgUzshA2g
>> I tried to clone stable/12 expecting that the -beta would be gone.
>> 
>> It looks as if I'm still jumping the gun. Although 
>> cgit.freegbsd.org replies to ping, using
>> 
>> bob at www:/usr % git clone cgit.freebsd.org -b stable/12 freebsd-src
>> 
>> reports:
>> 
>> fatal: repository 'cgit.freebsd.org' does not exist
>> 
>> This is just a rehearsal, so I can wait, but if I've 
>> made other mistakes please point them out.
> 
> cgit.freebsd.org is not for getting clones from, just like svnweb.freebsd.org
> was not for getting svn from.
> 
> Using main as an example, not stable/12 . . .
> 
> The bottom of the page https://cgit.freebsd.org/src/ shows 3 URL's for
> use in cloning src:
> 
> Clone
> https://git.FreeBSD.org/src.git
> anongit at git.FreeBSD.org:src.git
> git at gitrepo.FreeBSD.org:src.git

Hmm. It turns out that the last 2 are links on that page and the
links expand out to:

https://cgit.freebsd.org/src/anongit at git.FreeBSD.org:src.git
and:
https://cgit.freebsd.org/src/git at gitrepo.FreeBSD.org:src.git

So it seems that there are ways to clone that involve referencing
cgit.freebsd.org .

> The last two are not explicit about notation like ssh: prefixes.
> 
> I cloned FreeBSD's src.git via:
> 
> git clone -o freebsd --config remote.freebsd.fetch='+refs/notes/*:refs/notes/*' ssh://anongit at git.freebsd.org/src.git freebsd-src
> 
> Other than using the ssh: style, I got the command notation from
> part of:
> 
> https://github.com/bsdimp/freebsd-git-docs/blob/main/src-cvt.md
> 
> The remote.freebsd.fetch related material allows for finding the svn version
> numbers for the older content.
> 
> Checking out stable/12 from the clone should be possible after the above, but
> that is not what I've been doing.
> 


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


From kp at FreeBSD.org  Tue Dec 22 21:57:34 2020
From: kp at FreeBSD.org (Kristof Provost)
Date: Tue, 22 Dec 2020 22:57:32 +0100
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <28028C56-7E5A-4961-8F09-36351CDDFF20@yahoo.com>
References: <20201222183900.GA22353@www.zefox.net>
 <1249102000.16891.1608669265488@localhost>
 <20201222210628.GA34436@www.zefox.net>
 <19860CB5-716C-47A9-BB96-0EA16051DD9D@yahoo.com>
 <28028C56-7E5A-4961-8F09-36351CDDFF20@yahoo.com>
Message-ID: <0019AD39-8A37-4C73-84BA-E6B482A02F68@FreeBSD.org>


On 22 Dec 2020, at 22:50, Mark Millard wrote:
> On 2020-Dec-22, at 13:31, Mark Millard <marklmi at yahoo.com> wrote:
>> Clone
>> https://git.FreeBSD.org/src.git
>> anongit at git.FreeBSD.org:src.git
>> git at gitrepo.FreeBSD.org:src.git
>
> Hmm. It turns out that the last 2 are links on that page and the
> links expand out to:
>
> https://cgit.freebsd.org/src/anongit at git.FreeBSD.org:src.git
> and:
> https://cgit.freebsd.org/src/git at gitrepo.FreeBSD.org:src.git
>
> So it seems that there are ways to clone that involve referencing
> cgit.freebsd.org .
>
No, that?s just a configuration bug in cgit. I?m sure it?ll get 
fixed in due course.

The text version of the links is the correct version.

Best regards,
Kristof

From warlock at phouka.net  Tue Dec 22 22:27:41 2020
From: warlock at phouka.net (John Kennedy)
Date: Tue, 22 Dec 2020 14:26:15 -0800
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <28028C56-7E5A-4961-8F09-36351CDDFF20@yahoo.com>
References: <20201222183900.GA22353@www.zefox.net>
 <1249102000.16891.1608669265488@localhost>
 <20201222210628.GA34436@www.zefox.net>
 <19860CB5-716C-47A9-BB96-0EA16051DD9D@yahoo.com>
 <28028C56-7E5A-4961-8F09-36351CDDFF20@yahoo.com>
Message-ID: <X+Jyh8NOQ53pNHPi@phouka1.phouka.net>

Attributions are really confusing at this point...

On 2020-Dec-22, at 13:06, bob prohaska <fbsd at www.zefox.net> wrote:
> bob at www:/usr % git clone cgit.freebsd.org -b stable/12 freebsd-src

On 2020-Dec-22, at 13:31, Mark Millard <marklmi at yahoo.com> wrote:
> I cloned FreeBSD's src.git via:
> git clone -o freebsd --config remote.freebsd.fetch='+refs/notes/*:refs/notes/*' ssh://anongit at git.freebsd.org/src.git freebsd-src

  Bob, like mark, I replicated -CURRENT from git by:

	cd /usr/src
	git clone -o freebsd --config remote.freebsd.fetch='+refs/notes/*:refs/notes/*' \
		anongit at git.FreeBSD.org:src.git .
	git config pull.ff only
	git pull -v

  Special callout...  that "-o freebsd" and the "--config remote.freebsd.fetch"
are related (changing the origin label), and if you don't have them in sync you
won't pull down the refs/notes, so you git logs won't have all the details and
some of the detailed info (rev, commit Id, total refs) won't show up normally.

  I don't think https was working when I initially tried, but this worked.


From paul at gromit.dlib.vt.edu  Wed Dec 23 00:11:06 2020
From: paul at gromit.dlib.vt.edu (Paul Mather)
Date: Tue, 22 Dec 2020 19:10:57 -0500
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <20201222183900.GA22353@www.zefox.net>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <20201222183900.GA22353@www.zefox.net>
Message-ID: <81C07616-434E-4DF4-91AC-518AECF4F16F@gromit.dlib.vt.edu>

On Dec 22, 2020, at 1:39 PM, bob prohaska <fbsd at www.zefox.net> wrote:

> On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote:
>> 
>> The FreeBSD project will be moving it's source repo from subversion to git
>> starting this this weekend. The docs repo was moved 2 weeks ago. The ports
>> repo will move at the end of March, 2021 due to timing issues.
>> 
> 
> Is there some way to obtain git on a Pi2B running 
> 13.0-CURRENT FreeBSD 13.0-CURRENT #2 r365692
> without installing the ports tree? I expected 
> to find git in base, but it isn't there. 
> 
> Can it be found  under another package name?
> 
> Thanks for reading, and any guidance!


Git (and git-lite) are available only in ports/packages at the moment.  For those wanting to track src via git, you need to install it from there.  I believe any plans for a git-compatible tool in base would be derived from Got (devel/got) due to licensing.

But, unless I'm mistaken, there is no need to install git to be able to continue to get copies of src.  It's only developers who need to commit changes to src that need to switch over to git in the near future.  Just as FreeBSD's src has been made available as a Git repository from the canonical Subversion repo (e.g., on GitHub), I'm sure the reverse will be true for some time and you'll be able to continue to get src updates via Subversion.  That would surely be the case for existing releases (otherwise it would be a huge POLA violation).

I track NetBSD src via Git, even though that project currently officially uses CVS.

Cheers,

Paul.


From jmg at funkthat.com  Wed Dec 23 02:32:53 2020
From: jmg at funkthat.com (John-Mark Gurney)
Date: Tue, 22 Dec 2020 18:32:43 -0800
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <20201218182820.1P0tK%steffen@sdaoden.eu>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org>
 <CANCZdfrF0B7uux_neg-4XGn2UCDd4noUm7zP_icHnrpZUgmzzA@mail.gmail.com>
 <CAOtMX2gV2dmyG4b1hZG24sUnqDVk=1pch4xgQmyUdtLrh48kYg@mail.gmail.com>
 <CANCZdfpb0MF+uoW=K3cQpL+3vNQjSBDeVMab5d4JJhUO4sy-2Q@mail.gmail.com>
 <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com>
 <20201218175241.GA72552@spindle.one-eyed-alien.net>
 <20201218182820.1P0tK%steffen@sdaoden.eu>
Message-ID: <20201223023242.GG31099@funkthat.com>

Steffen Nurpmeso wrote this message on Fri, Dec 18, 2020 at 19:28 +0100:
> Brooks Davis wrote in
>  <20201218175241.GA72552 at spindle.one-eyed-alien.net>:
>  |On Thu, Dec 17, 2020 at 05:53:20PM -0800, Thomas Mueller wrote:
>  |>>> I hope we don't have to start signing all commits.  saltstack/salt has
>  |>>> that policy, and it's extremely annoying.
>  |> 
>  |>> Have to? Not currently. As with all process changes, there will be
>  |>> community discussion around the different points.
>  |> 
>  |>> Warner
>  |> 
>  |> I hope not!
>  |> 
>  |> Signatures, at least in email messages, are just an annoyance as \
>  |> I see them.
>  |> 
>  |> I don't even know how do sign an email message or make use of a signatur\
>  |> e in a message I receive.
>  |> 
>  |> I have never made a commit to a repository, so would not be familiar \
>  |> with signatures there; imagine it would be a barrier.
>  |
>  |Signed commits have no practicl effect on users of a repo.
> 
> Well you can verify integrity of a repository regardless of how it
> was distributed, this is why it is done, right.
> 
>   #?0$ git log --oneline --show-signature -1 v14.9.20.ar
>   16a21755 (...)
>   gpg: Signature made Sun 13 Dec 2020 12:43:44 AM CET
>   gpg:                using RSA key DF082F6AEEC8C2FF
>   gpg: Good signature from "Steffen Nurpmeso <steffen at sdaoden.eu>"
>   Bump S-nail v14.9.20.ar ("Sombre Tit (Trauermeise)"), 2020-12-12
> 
>   #?0$ git tag -v v14.9.20.ar; echo $?
>   object 16a21755fd1fade2b15fdb78a592f12169c3453f
>   type commit
>   tag v14.9.20.ar
>   tagger Steffen Nurpmeso <steffen at sdaoden.eu> 1607816624 +0100
>   
>   Bump S-nail v14.9.20.ar ("Sombre Tit (Trauermeise)"), 2020-12-12
>   gpg: Signature made Sun 13 Dec 2020 12:43:44 AM CET
>   gpg:                using RSA key DF082F6AEEC8C2FF
>   gpg: Good signature from "Steffen Nurpmeso <steffen at sdaoden.eu>"
>   0

TL;DR I don't see any reason for devs to sign commits.

I could see use for RE (or another entity) to occasionally (weekly?)
sign the repo (say COPYRIGHT or UPDATING), and it would be nice for
them to sign all the tags used for releases, but having every dev
would both make the dev's life difficult...

It's also hard to collect ALL the keys of the devs at any point in
time to decide if that key is authorized to sign a commit in the
repo...  Like if a dev starts in 2021, any commits made by that
dev prior to 2021 should not be "valid"..  Then there's also the
issue that people's keys change over time, and now you need to know
what time period each key was valid for, otherwise a compromised key
could be used to insert malicious changes into your/the tree...

Then there's also the point that the repo is (looks like it) using
SHA-1 hashes, which are effectively broken, so depending upon them
to validate the tree is questionable anyways.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

From grahamperrin at gmail.com  Wed Dec 23 06:47:14 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Wed, 23 Dec 2020 06:47:09 +0000
Subject: src: continued use of Subversion for getting updates
In-Reply-To: <81C07616-434E-4DF4-91AC-518AECF4F16F@gromit.dlib.vt.edu>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <20201222183900.GA22353@www.zefox.net>
 <81C07616-434E-4DF4-91AC-518AECF4F16F@gromit.dlib.vt.edu>
Message-ID: <01b07b90-e206-aa56-aa5b-91c764ef36a4@gmail.com>

On 23/12/2020 00:10, Paul Mather wrote:
> ? continue to get src updates via Subversion. ?

As far as I can tell:

* for stable/12 alone

* for a limited period.

<https://github.com/bsdimp/freebsd-git-docs/blob/4833066feda51cc3a907cf7bff1c4344b3edd5c6/big-picture.md#L103>

In context: 
<https://github.com/bsdimp/freebsd-git-docs/blob/main/big-picture.md>


From imp at bsdimp.com  Wed Dec 23 07:01:47 2020
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 23 Dec 2020 00:01:33 -0700
Subject: src: continued use of Subversion for getting updates
In-Reply-To: <01b07b90-e206-aa56-aa5b-91c764ef36a4@gmail.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <20201222183900.GA22353@www.zefox.net>
 <81C07616-434E-4DF4-91AC-518AECF4F16F@gromit.dlib.vt.edu>
 <01b07b90-e206-aa56-aa5b-91c764ef36a4@gmail.com>
Message-ID: <CANCZdfpJC4jA0ZUfP90FkeY-EWpLJo+ZcRctV6GUKt=tyUG2kA@mail.gmail.com>

On Tue, Dec 22, 2020, 11:47 PM Graham Perrin <grahamperrin at gmail.com> wrote:

> On 23/12/2020 00:10, Paul Mather wrote:
> > ? continue to get src updates via Subversion. ?
>
> As far as I can tell:
>
> * for stable/12 alone
>

stable/11 as well as the releng branches for as long as the project has
them under support. I wrote the code to replay commits into subversion for
the convenience of our users on those branches. The 12.x releases will be
built out of Subversion to preserve $FreeBSD$ expansion and other obscure
subversion details that may matter or be disruptive to people using those
branches.

Current has moved entirely to git. New commits have started up again.
Stable/11 and stable/12 are there as well, but there are a couple of last
minute snags that are being sorted out so it will be an additional day,
maybe two before those start. FreeBSD 13 will be entirely from git and will
be branching late winter or early spring if all goes well. Other issues
with git are being sorted our as they arise.

For those using github, migration instructions will be in place once the
changes there are complete. What I've written up is enough for the seasoned
traveler, but lacks a few details that were hosted worked out in the past
days I've not had time to fold in. We hope to have that all sorted out by
Christmas.

This has been a big job with way more moving parts than I'd ever thought
possible. We've attended to most of them, and are fixing the stragglers as
the team becomes aware of them.

Warner

* for a limited period.
>
> <
> https://github.com/bsdimp/freebsd-git-docs/blob/4833066feda51cc3a907cf7bff1c4344b3edd5c6/big-picture.md#L103
> >
>
> In context:
> <https://github.com/bsdimp/freebsd-git-docs/blob/main/big-picture.md>
>
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>

From grahamperrin at gmail.com  Wed Dec 23 08:48:26 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Wed, 23 Dec 2020 08:48:20 +0000
Subject: src: continued use of Subversion for getting updates
In-Reply-To: <CANCZdfpJC4jA0ZUfP90FkeY-EWpLJo+ZcRctV6GUKt=tyUG2kA@mail.gmail.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <20201222183900.GA22353@www.zefox.net>
 <81C07616-434E-4DF4-91AC-518AECF4F16F@gromit.dlib.vt.edu>
 <01b07b90-e206-aa56-aa5b-91c764ef36a4@gmail.com>
 <CANCZdfpJC4jA0ZUfP90FkeY-EWpLJo+ZcRctV6GUKt=tyUG2kA@mail.gmail.com>
Message-ID: <4a78a724-08d8-b9bd-1353-598b5c596078@gmail.com>

Warner, thanks for the clarification.

Apologies for me taking the (rough draft/work in progress) documentation 
too literally.

On 23/12/2020 07:01, Warner Losh wrote:
> ? This has been a big job with way more moving parts than I'd ever 
> thought possible. We've attended to most of them, and are fixing the 
> stragglers as the team becomes aware of them. ?

 From the outside looking in: for so complex a project, progress seems 
remarkably smooth. Thanks to all involved.


From imp at bsdimp.com  Wed Dec 23 08:49:37 2020
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 23 Dec 2020 01:49:24 -0700
Subject: src: continued use of Subversion for getting updates
In-Reply-To: <4a78a724-08d8-b9bd-1353-598b5c596078@gmail.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <20201222183900.GA22353@www.zefox.net>
 <81C07616-434E-4DF4-91AC-518AECF4F16F@gromit.dlib.vt.edu>
 <01b07b90-e206-aa56-aa5b-91c764ef36a4@gmail.com>
 <CANCZdfpJC4jA0ZUfP90FkeY-EWpLJo+ZcRctV6GUKt=tyUG2kA@mail.gmail.com>
 <4a78a724-08d8-b9bd-1353-598b5c596078@gmail.com>
Message-ID: <CANCZdfqJPo7bOmzcXz2a-fJzk8H6Qmym7eLy7DQzABjsS64tjQ@mail.gmail.com>

On Wed, Dec 23, 2020, 1:48 AM Graham Perrin <grahamperrin at gmail.com> wrote:

> Warner, thanks for the clarification.
>
> Apologies for me taking the (rough draft/work in progress) documentation
> too literally.
>

I'm all ears on ways to make the docs better

Warner

On 23/12/2020 07:01, Warner Losh wrote:
> > ? This has been a big job with way more moving parts than I'd ever
> > thought possible. We've attended to most of them, and are fixing the
> > stragglers as the team becomes aware of them. ?
>
>  From the outside looking in: for so complex a project, progress seems
> remarkably smooth. Thanks to all involved.
>
>

From joh.hendriks at gmail.com  Wed Dec 23 10:13:11 2020
From: joh.hendriks at gmail.com (Johan Hendriks)
Date: Wed, 23 Dec 2020 11:13:07 +0100
Subject: src: continued use of Subversion for getting updates
In-Reply-To: <CANCZdfqJPo7bOmzcXz2a-fJzk8H6Qmym7eLy7DQzABjsS64tjQ@mail.gmail.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <20201222183900.GA22353@www.zefox.net>
 <81C07616-434E-4DF4-91AC-518AECF4F16F@gromit.dlib.vt.edu>
 <01b07b90-e206-aa56-aa5b-91c764ef36a4@gmail.com>
 <CANCZdfpJC4jA0ZUfP90FkeY-EWpLJo+ZcRctV6GUKt=tyUG2kA@mail.gmail.com>
 <4a78a724-08d8-b9bd-1353-598b5c596078@gmail.com>
 <CANCZdfqJPo7bOmzcXz2a-fJzk8H6Qmym7eLy7DQzABjsS64tjQ@mail.gmail.com>
Message-ID: <50240461-2c49-42b2-5df6-98041efc8419@gmail.com>


On 23/12/2020 09:49, Warner Losh wrote:
> On Wed, Dec 23, 2020, 1:48 AM Graham Perrin <grahamperrin at gmail.com> wrote:
>
>> Warner, thanks for the clarification.
>>
>> Apologies for me taking the (rough draft/work in progress) documentation
>> too literally.
>>
> I'm all ears on ways to make the docs better
>
> Warner
>
> On 23/12/2020 07:01, Warner Losh wrote:
>>> ? This has been a big job with way more moving parts than I'd ever
>>> thought possible. We've attended to most of them, and are fixing the
>>> stragglers as the team becomes aware of them. ?
>>   From the outside looking in: for so complex a project, progress seems
>> remarkably smooth. Thanks to all involved.
>>
>>
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>
First of all a big thank you for all your time and effort you and all 
the other people put in this tremendous task.

For me and i think a lot of regular users that do not push just pull, a 
simple page with the exact commands to track stable or head is very 
appreciated.

Like svnlite update /usr/src replace with git pull .... and so on and an 
example for head, stable or release will push most people in the right 
direction.

I for one (i did not search that hard) can not find these steps very 
easily.

regards






From zarychtam at plan-b.pwste.edu.pl  Wed Dec 23 10:35:35 2020
From: zarychtam at plan-b.pwste.edu.pl (Marek Zarychta)
Date: Wed, 23 Dec 2020 11:35:20 +0100
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
Message-ID: <e1e5af32-f8cf-ab07-c959-57db87c159d0@plan-b.pwste.edu.pl>

W dniu 17.12.2020 o?01:46, Warner Losh pisze:
> Greetings,
> 
> The FreeBSD project will be moving it's source repo from subversion to git
> starting this this weekend. The docs repo was moved 2 weeks ago. The ports
> repo will move at the end of March, 2021 due to timing issues.
> 
> The short version is that we're switching the version control we're using.
> This switch will preserve much of the current FreeBSD development workflow.
> After the switch, the subversion repo will become almost read-only. All
> future work will be done in git, however as a transition aide we'll be
> replaying the MFCs to stable/11, stable/12 and the related releng branches
> for the life of those branches.
> 
> For more detailed information, please see
> https://github.com/bsdimp/freebsd-git-docs/ for the current documentation.
> 
> Please see https://wiki.freebsd.org/git for the latest detailed schedule
> (please note that this schedule is subject to change).
> 
> Warner
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
> 

Will the project utilize gitatributes(5) to support ident as $Id:$ in
git repository?

In file header, we have now only $FreeBSD$ since svn tags disappeared
after the transition. Adding ident tags to certain files which are
updated by mergemaster(8) or etcupdated(8) would be appreciated.

Best regards,
-- 
Marek Zarychta

From mueller6722 at twc.com  Wed Dec 23 11:10:09 2020
From: mueller6722 at twc.com (Thomas Mueller)
Date: Wed, 23 Dec 2020 11:10:09 -0000
Subject: src: continued use of Subversion for getting updates
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <20201222183900.GA22353@www.zefox.net>
 <81C07616-434E-4DF4-91AC-518AECF4F16F@gromit.dlib.vt.edu>
 <01b07b90-e206-aa56-aa5b-91c764ef36a4@gmail.com>
 <CANCZdfpJC4jA0ZUfP90FkeY-EWpLJo+ZcRctV6GUKt=tyUG2kA@mail.gmail.com>
Message-ID: <mailman.6.1608721810.98902.freebsd-current@freebsd.org>

> stable/11 as well as the releng branches for as long as the project has
> them under support. I wrote the code to replay commits into subversion for
> the convenience of our users on those branches. The 12.x releases will be
> built out of Subversion to preserve $FreeBSD$ expansion and other obscure
> subversion details that may matter or be disruptive to people using those
> branches.
 
> Current has moved entirely to git. New commits have started up again.
> Stable/11 and stable/12 are there as well, but there are a couple of last
> minute snags that are being sorted out so it will be an additional day,
> maybe two before those start. FreeBSD 13 will be entirely from git and will
> be branching late winter or early spring if all goes well. Other issues
> with git are being sorted our as they arise.
 
> For those using github, migration instructions will be in place once the
> changes there are complete. What I've written up is enough for the seasoned
> traveler, but lacks a few details that were hosted worked out in the past
> days I've not had time to fold in. We hope to have that all sorted out by
> Christmas.
 
> This has been a big job with way more moving parts than I'd ever thought
> possible. We've attended to most of them, and are fixing the stragglers as
> the team becomes aware of them.
 
> Warner

Congratulations on moving doc and current src trees to git.

I made the transition and ran "rm -Rf" on doc svn tree, src svn tree and also src12 tree.

I am abandoning releng-12 because of problems with internet connectivity, which even appeared in NomadBSD live USB based on FreeBSD 12.1.

Will stable/11 and stable/12 be available by both git and svn?  This is just idle curiosity in my case.

Tom


From jbtakk at iherebuywisely.com  Wed Dec 23 11:26:55 2020
From: jbtakk at iherebuywisely.com (Jeffrey Bouquet)
Date: Wed, 23 Dec 2020 03:26:50 -0800 (PST)
Subject: src: continued use of Subversion for getting updates
In-Reply-To: <50240461-2c49-42b2-5df6-98041efc8419@gmail.com>
Message-ID: <E1ks2I6-0005nh-BQ@rmmprod05.runbox>



On Wed, 23 Dec 2020 11:13:07 +0100, Johan Hendriks <joh.hendriks at gmail.com> wrote:

> 
> On 23/12/2020 09:49, Warner Losh wrote:
> > On Wed, Dec 23, 2020, 1:48 AM Graham Perrin <grahamperrin at gmail.com> wrote:
> >
> >> Warner, thanks for the clarification.
> >>
> >> Apologies for me taking the (rough draft/work in progress) documentation
> >> too literally.
> >>
> > I'm all ears on ways to make the docs better
> >
> > Warner
> >
> > On 23/12/2020 07:01, Warner Losh wrote:
> >>> ? This has been a big job with way more moving parts than I'd ever
> >>> thought possible. We've attended to most of them, and are fixing the
> >>> stragglers as the team becomes aware of them. ?
> >>   From the outside looking in: for so complex a project, progress seems
> >> remarkably smooth. Thanks to all involved.
> >>
> >>
> > _______________________________________________
> > freebsd-current at freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
> >
> First of all a big thank you for all your time and effort you and all 
> the other people put in this tremendous task.
> 
> For me and i think a lot of regular users that do not push just pull, a 
> simple page with the exact commands to track stable or head is very 
> appreciated.
> 
> Like svnlite update /usr/src replace with git pull .... and so on and an 
> example for head, stable or release will push most people in the right 
> direction.
> 
> I for one (i did not search that hard) can not find these steps very 
> easily.
> 
> regards
> 
> 
> 
> 
> 
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"


Seconded.
This and the other ongoing today subversion > git threads IMHO need four or more 
new paragraphs in /usr/src/UPDATING and eventually /usr/ports/UPDATING so
persons who for lack of time won't ever get upto speed entirely on how to run git
can have  a copy-paste template command to run for most use cases, here,
equivalents of

ports
cd /usr/ports/Mk
svn up .
 
and 

src

cd /usr/src/sbin
svn up
[[... denotes by default the branch checked out, addl parameters probably ]
as well as 'swn switch' equivalents
and another-destination equivalents

for example

git clone https://git.FreeBSD.org/src.git -b stable/12 /usr/freebsd-src

appeared to start checking out 12-stable to the latter directory
but I had to halt it for lack of time and being new. 


From pi at freebsd.org  Wed Dec 23 12:15:14 2020
From: pi at freebsd.org (Kurt Jaeger)
Date: Wed, 23 Dec 2020 13:15:04 +0100
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <20201223023242.GG31099@funkthat.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org>
 <CANCZdfrF0B7uux_neg-4XGn2UCDd4noUm7zP_icHnrpZUgmzzA@mail.gmail.com>
 <CAOtMX2gV2dmyG4b1hZG24sUnqDVk=1pch4xgQmyUdtLrh48kYg@mail.gmail.com>
 <CANCZdfpb0MF+uoW=K3cQpL+3vNQjSBDeVMab5d4JJhUO4sy-2Q@mail.gmail.com>
 <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com>
 <20201218175241.GA72552@spindle.one-eyed-alien.net>
 <20201218182820.1P0tK%steffen@sdaoden.eu>
 <20201223023242.GG31099@funkthat.com>
Message-ID: <X+M0yPrCJ5Rz/V85@home.opsec.eu>

Hi!

> It's also hard to collect ALL the keys of the devs at any point in
> time to decide if that key is authorized to sign a commit in the
> repo...

We do have most of the keys in docs/share/pgpkeys/ plus history.

> Like if a dev starts in 2021, any commits made by that
> dev prior to 2021 should not be "valid"..  Then there's also the
> issue that people's keys change over time, and now you need to know
> what time period each key was valid for, otherwise a compromised key
> could be used to insert malicious changes into your/the tree...

If we manage keys plus their history in the doc repo, this seems
to be solved.

-- 
pi at opsec.eu            +49 171 3101372                    Now what ?

From uqs at freebsd.org  Wed Dec 23 12:54:03 2020
From: uqs at freebsd.org (Ulrich =?utf-8?B?U3DDtnJsZWlu?=)
Date: Wed, 23 Dec 2020 13:54:00 +0100
Subject: git tools for building in base?
In-Reply-To: <10f7b800-b015-2a80-b741-4f7db03bf6eb@quip.cz>
References: <X714z7pMgNOFaTIc@rpi4.local>
 <20201125055425.01AA628417@elsa.codelab.cz>
 <10f7b800-b015-2a80-b741-4f7db03bf6eb@quip.cz>
Message-ID: <X+M96JQwp+QCIIWH@acme.spoerlein.net>

On Fri, 2020-12-18 at 14:02:08 +0100, Miroslav Lachman wrote:
>On 25/11/2020 06:54, Thomas Mueller wrote:
>
>> NetBSD users face a similar problem with their upcoming switch from cvs to hg (Mercurial).
>
>Do anybody have a link to some documents stating why FreeBSD chose Git
>and why NetBSD chose Mercurial? I am using both tools at $WORK, I am
>just curious what leads to these decisions.

No documents, but git was simply more mature back when I started this 
effort a decade ago and it is and was more popular (with all the added 
side effects that has). I was (and am) only an occasional user of hg and 
even git, so familiarity wasn't quite an argument back then, though the 
git storage model is much nicer for the required history re-writing.

In the early days I pushed to googlecode and bitbucket as well, you can 
see that here 
https://svnweb.freebsd.org/base/user/uqs/git_conv/git_conv?r1=251786&r2=251785&pathrev=251786

Not visible are the trials I ran with git-svn and hg, both of which only 
could handle the single head branch, but not all the other branching 
craziness that was and is going on in the repo.

I don't fully recall, but I think that the hg conversion was slow and 
the disk space needed was quite a bit more than git.

So in summary, I guess it can be summed up as:
- there was no svn-all-fast-export for hg back then
- even bitbucket switched from hg to git
- history rewriting is easier in git, see e.g. this file for the stuff 
   that's required to make the cvs2svn things a bit nicer: 
   https://github.com/freebsd/git_conv/blob/master/fix_bogus_tags.sh

Granted, now that the heavy lifting is done, one could probably do a 
git2hg transition, as the history is now pretty sane and should be 
compatible to the hg model.

But lack of anyone (to my knowledge?) providing a hg copy of FreeBSD all 
these years tells me that there's simply no demand for it.

There's https://wiki.freebsd.org/LocalMercurial from 2008 but that skips 
converting from r1. Of interest is also 
https://www.mercurial-scm.org/pipermail/mercurial/2019-May/051240.html 
which looks like the size issues with hg haven't been fixed yet. It also 
seems that http://hg-beta.freebsd.org/base/branches has the 
user-servicable branches only, but not vendor. So it's not usable as a 
source-of-truth for the project.

I would encourage everyone *not* to base their hg work off of SVN but 
take the soon-official git repo instead. If you wanted to do this right 
off of SVN, here's just one of dozens of quirks: 
https://github.com/freebsd/git_conv/blob/master/revisions.md

You've been warned ;]

Cheers
Uli

From trashcan at ellael.org  Wed Dec 23 14:32:26 2020
From: trashcan at ellael.org (Michael Grimm)
Date: Wed, 23 Dec 2020 15:32:13 +0100
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
Message-ID: <C47EED5D-2997-49FE-8D17-AD64E1317033@ellael.org>

Hi,

Warner Losh <imp at bsdimp.com> wrote:

> The FreeBSD project will be moving it's source repo from subversion to git
> starting this this weekend. 

First of all I'd like to thank all those involved in this for their efforts.

Following https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md form your other mail I was able to migrate from svn to git without running into any issues.

Right now I am learning how to use git the way I sed svn before. I am just following 12-STABLE in order to build world and kernel. I am not developing, neither am I committing.

I wonder how one would switch from a currently used branch (OLD) to another branch (NEW).

With svn I used:
	svn switch svn://svn.freebsd.org/base/stable/NEW /usr/src

For git I found:
	git branch -m stable/OLD stable/NEW
	or
	git branch -M stable/OLD stable/NEW

git-branch(1):
       With a -m or -M option, <oldbranch> will	be renamed to <newbranch>. If
       <oldbranch> had a corresponding reflog, it is renamed to	match
       <newbranch>, and	a reflog entry is created to remember the branch
       renaming. If <newbranch>	exists,	-M must	be used	to force the rename to
       happen.

I don't understand that text completely, because I don't know what a reflog is, yet ;-)

Thus: Should I use "-m" or "-M" in my scenario when switching from stable/12 to stable/13 in the near future?

Thanks and regards,
Michael


From steffen at sdaoden.eu  Wed Dec 23 14:35:54 2020
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 23 Dec 2020 15:35:45 +0100
Subject: src: continued use of Subversion for getting updates
In-Reply-To: <E1ks2I6-0005nh-BQ@rmmprod05.runbox>
References: <E1ks2I6-0005nh-BQ@rmmprod05.runbox>
Message-ID: <20201223143545.Wf_Ww%steffen@sdaoden.eu>

Jeffrey Bouquet wrote in
 <E1ks2I6-0005nh-BQ at rmmprod05.runbox>:
 |On Wed, 23 Dec 2020 11:13:07 +0100, Johan Hendriks <joh.hendriks at gmail.c\
 |om> wrote:
 |> On 23/12/2020 09:49, Warner Losh wrote:
 |>> On Wed, Dec 23, 2020, 1:48 AM Graham Perrin <grahamperrin at gmail.com> \
 |>> wrote:
 ...
 |> First of all a big thank you for all your time and effort you and all 
 |> the other people put in this tremendous task.

Yes, it is great to have FreeBSD as a stable git repository now,
not only due to "gc --aggressive --prune=all" and the possibility
to use (pseudo) bare repositories without checkouts, but also
because of this.  Downloaded it today (from fresh), currently
doing the mentioned command, but it may be it does not reduce that
much :)

I really dislike that vendor imports have been tagged.  Because
there is only one tag namespace you cannot avoid getting all this
cruft.  I mean, it is too late now, but one could have used
per-vendor import branches and step them via "git rm -rf '*' &&
tar -xf newball && git add . && git commit bla" or whatever, and
then join them in.  It does not matter for those who have all the
repository, but you decided to loose one of the strengts of git,
selective tracking.  Also i think it causes updates to require
more network traffic, i see this with the repos i have at
repo.or.cz, the one with few heads/tags is minimal, the other
requires hundreds of kilobytes just for the check that happens
many times a day.  All these references have to be compared each
and every time.  I think.  On the other hand, a few years back
i accidentally "heard" a discussion about improving the network
protocol and that "head" reference matching, iirc, so it may
change in the future.

Ciao,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From garga at FreeBSD.org  Wed Dec 23 14:58:41 2020
From: garga at FreeBSD.org (Renato Botelho)
Date: Wed, 23 Dec 2020 11:58:35 -0300
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <C47EED5D-2997-49FE-8D17-AD64E1317033@ellael.org>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <C47EED5D-2997-49FE-8D17-AD64E1317033@ellael.org>
Message-ID: <0bce6fd0-7a54-b90a-ac6b-24226d77a87f@FreeBSD.org>

On 23/12/20 11:32, Michael Grimm wrote:
> Hi,
> 
> Warner Losh <imp at bsdimp.com> wrote:
> 
>> The FreeBSD project will be moving it's source repo from subversion to git
>> starting this this weekend.
> 
> First of all I'd like to thank all those involved in this for their efforts.
> 
> Following https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md form your other mail I was able to migrate from svn to git without running into any issues.
> 
> Right now I am learning how to use git the way I sed svn before. I am just following 12-STABLE in order to build world and kernel. I am not developing, neither am I committing.
> 
> I wonder how one would switch from a currently used branch (OLD) to another branch (NEW).
> 
> With svn I used:
> 	svn switch svn://svn.freebsd.org/base/stable/NEW /usr/src
> 
> For git I found:
> 	git branch -m stable/OLD stable/NEW
> 	or
> 	git branch -M stable/OLD stable/NEW
> 
> git-branch(1):
>         With a -m or -M option, <oldbranch> will	be renamed to <newbranch>. If
>         <oldbranch> had a corresponding reflog, it is renamed to	match
>         <newbranch>, and	a reflog entry is created to remember the branch
>         renaming. If <newbranch>	exists,	-M must	be used	to force the rename to
>         happen.
> 
> I don't understand that text completely, because I don't know what a reflog is, yet ;-)
> 
> Thus: Should I use "-m" or "-M" in my scenario when switching from stable/12 to stable/13 in the near future?

git-branch is used to create/delete/rename branches.  If you want to 
switch to a different already existing branch, as svn switch does, you 
should look at git-checkout.

It can be a bit expensive due to the size of src repository so if you do 
work on multiple branches too often you can improve it using git-worktree.

-- 
Renato Botelho

From lev at FreeBSD.org  Wed Dec 23 15:04:44 2020
From: lev at FreeBSD.org (Lev Serebryakov)
Date: Wed, 23 Dec 2020 18:04:40 +0300
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <C47EED5D-2997-49FE-8D17-AD64E1317033@ellael.org>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <C47EED5D-2997-49FE-8D17-AD64E1317033@ellael.org>
Message-ID: <996b191c-635e-3248-c8f9-ea1b5f70507e@FreeBSD.org>

On 23.12.2020 17:32, Michael Grimm wrote:

> git-branch(1):
>         With a -m or -M option, <oldbranch> will	be renamed to <newbranch>. If
==============================================^^^^^^^^^^^^^^^^^^^^
>         <oldbranch> had a corresponding reflog, it is renamed to	match
>         <newbranch>, and	a reflog entry is created to remember the branch
>         renaming. If <newbranch>	exists,	-M must	be used	to force the rename to
>         happen.
> 
> I don't understand that text completely, because I don't know what a reflog is, yet ;-)
> 
> Thus: Should I use "-m" or "-M" in my scenario when switching from stable/12 to stable/13 in the near future?
You should not use any options if you want to switch your working copy to new branch. `-m` and `-M` *renames* branch!

-- 
// Lev Serebryakov

From lev at FreeBSD.org  Wed Dec 23 15:09:08 2020
From: lev at FreeBSD.org (Lev Serebryakov)
Date: Wed, 23 Dec 2020 18:09:05 +0300
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <996b191c-635e-3248-c8f9-ea1b5f70507e@FreeBSD.org>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <C47EED5D-2997-49FE-8D17-AD64E1317033@ellael.org>
 <996b191c-635e-3248-c8f9-ea1b5f70507e@FreeBSD.org>
Message-ID: <e4f52e88-56da-31f9-e192-5d5ae971844f@FreeBSD.org>

On 23.12.2020 18:04, Lev Serebryakov wrote:
> On 23.12.2020 17:32, Michael Grimm wrote:
> 
>> git-branch(1):
>> ??????? With a -m or -M option, <oldbranch> will??? be renamed to <newbranch>. If
> ==============================================^^^^^^^^^^^^^^^^^^^^
>> ??????? <oldbranch> had a corresponding reflog, it is renamed to??? match
>> ??????? <newbranch>, and??? a reflog entry is created to remember the branch
>> ??????? renaming. If <newbranch>??? exists,??? -M must??? be used??? to force the rename to
>> ??????? happen.
>>
>> I don't understand that text completely, because I don't know what a reflog is, yet ;-)
>>
>> Thus: Should I use "-m" or "-M" in my scenario when switching from stable/12 to stable/13 in the near future?
> You should not use any options if you want to switch your working copy to new branch. `-m` and `-M` *renames* branch!
  I'm idiot today, it is `git checkout <exisitng-branch>` of course.

-- 
// Lev Serebryakov

From grahamperrin at gmail.com  Wed Dec 23 15:31:31 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Wed, 23 Dec 2020 15:31:26 +0000
Subject: FreeBSD-CURRENT src: pulling without pushing: example Git commands to
 clone then update
In-Reply-To: <50240461-2c49-42b2-5df6-98041efc8419@gmail.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <20201222183900.GA22353@www.zefox.net>
 <81C07616-434E-4DF4-91AC-518AECF4F16F@gromit.dlib.vt.edu>
 <01b07b90-e206-aa56-aa5b-91c764ef36a4@gmail.com>
 <CANCZdfpJC4jA0ZUfP90FkeY-EWpLJo+ZcRctV6GUKt=tyUG2kA@mail.gmail.com>
 <4a78a724-08d8-b9bd-1353-598b5c596078@gmail.com>
 <CANCZdfqJPo7bOmzcXz2a-fJzk8H6Qmym7eLy7DQzABjsS64tjQ@mail.gmail.com>
 <50240461-2c49-42b2-5df6-98041efc8419@gmail.com>
Message-ID: <53c66d2a-293c-9c42-acd9-ad1c280be7c7@gmail.com>

On 23/12/2020 10:13, Johan Hendriks wrote:

> ? For me and i think a lot of regular users that do not push just 
> pull, a simple page with the exact commands to track stable or head is 
> very appreciated.
>
> Like svnlite update /usr/src replace with git pull .... and so on and 
> an example for head, stable or release will push most people in the 
> right direction. ? 


-CURRENT
========

Guided mostly by the documentation:

1. with /usr/src as an empty working directory
2. the command below, just once

git clone -o freebsd -b main --depth 1 https://git.freebsd.org/src.git 
freebsd-current

(I do not foresee me committing, and I had no immediate interest in 
history.)

Subsequent updates
------------------

portsnap auto && git -C /usr/src/freebsd-current pull --ff-only && echo 
"FreeBSD-CURRENT Git revision: " && git -C /usr/src/freebsd-current 
rev-list --count HEAD

? take what you like from that. Not intended to be an exact command for 
other users, but it suits me.

Context: <https://old.reddit.com/comments/keme3b/-/ggs61in/?context=1>

HTH
Graham


From bsd-lists at bsdforge.com  Wed Dec 23 15:36:25 2020
From: bsd-lists at bsdforge.com (Chris)
Date: Wed, 23 Dec 2020 07:36:41 -0800
Subject: src: continued use of Subversion for getting updates
In-Reply-To: <CANCZdfpJC4jA0ZUfP90FkeY-EWpLJo+ZcRctV6GUKt=tyUG2kA@mail.gmail.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <20201222183900.GA22353@www.zefox.net>
 <81C07616-434E-4DF4-91AC-518AECF4F16F@gromit.dlib.vt.edu>
 <01b07b90-e206-aa56-aa5b-91c764ef36a4@gmail.com>
 <CANCZdfpJC4jA0ZUfP90FkeY-EWpLJo+ZcRctV6GUKt=tyUG2kA@mail.gmail.com>
Message-ID: <f52741305ad7d4eb3643c99320fa5b92@bsdforge.com>

On 2020-12-22 23:01, Warner Losh wrote:
> On Tue, Dec 22, 2020, 11:47 PM Graham Perrin <grahamperrin at gmail.com> wrote:
> 
>> On 23/12/2020 00:10, Paul Mather wrote:
>> > ? continue to get src updates via Subversion. ?
>> 
>> As far as I can tell:
>> 
>> * for stable/12 alone
>> 
> 
> stable/11 as well as the releng branches for as long as the project has
> them under support. I wrote the code to replay commits into subversion for
> the convenience of our users on those branches. The 12.x releases will be
> built out of Subversion to preserve $FreeBSD$ expansion and other obscure
> subversion details that may matter or be disruptive to people using those
> branches.
> 
> Current has moved entirely to git. New commits have started up again.
> Stable/11 and stable/12 are there as well, but there are a couple of last
> minute snags that are being sorted out so it will be an additional day,
> maybe two before those start. FreeBSD 13 will be entirely from git and will
> be branching late winter or early spring if all goes well. Other issues
> with git are being sorted our as they arise.
> 
> For those using github, migration instructions will be in place once the
> changes there are complete. What I've written up is enough for the seasoned
> traveler, but lacks a few details that were hosted worked out in the past
> days I've not had time to fold in. We hope to have that all sorted out by
> Christmas.
> 
> This has been a big job with way more moving parts than I'd ever thought
> possible. We've attended to most of them, and are fixing the stragglers as
> the team becomes aware of them.
On a slight aside;
Any plans to incorporate GitLab into any of this?

--Chris
> 
> Warner
> 
> * for a limited period.
>> 
>> <
>> https://github.com/bsdimp/freebsd-git-docs/blob/4833066feda51cc3a907cf7bff1c4344b3edd5c6/big-picture.md#L103
>> >
>> 
>> In context:
>> <https://github.com/bsdimp/freebsd-git-docs/blob/main/big-picture.md>
>> 
>> _______________________________________________
>> freebsd-current at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>> 
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"

From grahamperrin at gmail.com  Wed Dec 23 15:41:24 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Wed, 23 Dec 2020 15:41:20 +0000
Subject: FreeBSD: GitLab
In-Reply-To: <f52741305ad7d4eb3643c99320fa5b92@bsdforge.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <20201222183900.GA22353@www.zefox.net>
 <81C07616-434E-4DF4-91AC-518AECF4F16F@gromit.dlib.vt.edu>
 <01b07b90-e206-aa56-aa5b-91c764ef36a4@gmail.com>
 <CANCZdfpJC4jA0ZUfP90FkeY-EWpLJo+ZcRctV6GUKt=tyUG2kA@mail.gmail.com>
 <f52741305ad7d4eb3643c99320fa5b92@bsdforge.com>
Message-ID: <7b82f25b-9f0a-32c1-0f05-3a92474051b4@gmail.com>

On 23/12/2020 15:36, Chris wrote:

> ? Any plans to incorporate GitLab into any of this? 


<https://github.com/bsdimp/freebsd-git-docs/search?q=GitLab> ? 
big-picture.md is probably the best starting point.


From 000.fbsd at quip.cz  Wed Dec 23 15:56:11 2020
From: 000.fbsd at quip.cz (Miroslav Lachman)
Date: Wed, 23 Dec 2020 16:55:58 +0100
Subject: git tools for building in base?
In-Reply-To: <X+M96JQwp+QCIIWH@acme.spoerlein.net>
References: <X714z7pMgNOFaTIc@rpi4.local>
 <20201125055425.01AA628417@elsa.codelab.cz>
 <10f7b800-b015-2a80-b741-4f7db03bf6eb@quip.cz>
 <X+M96JQwp+QCIIWH@acme.spoerlein.net>
Message-ID: <49d6a212-f266-5a71-4982-9c368887494c@quip.cz>

On 23/12/2020 13:54, Ulrich Sp?rlein wrote:
> On Fri, 2020-12-18 at 14:02:08 +0100, Miroslav Lachman wrote:
>> On 25/11/2020 06:54, Thomas Mueller wrote:
>>
>>> NetBSD users face a similar problem with their upcoming switch from 
>>> cvs to hg (Mercurial).
>>
>> Do anybody have a link to some documents stating why FreeBSD chose Git
>> and why NetBSD chose Mercurial? I am using both tools at $WORK, I am
>> just curious what leads to these decisions.
> 
> No documents, but git was simply more mature back when I started this 
> effort a decade ago and it is and was more popular (with all the added 
> side effects that has). I was (and am) only an occasional user of hg and 
> even git, so familiarity wasn't quite an argument back then, though the 
> git storage model is much nicer for the required history re-writing.
> 
> In the early days I pushed to googlecode and bitbucket as well, you can 
> see that here 
> https://svnweb.freebsd.org/base/user/uqs/git_conv/git_conv?r1=251786&r2=251785&pathrev=251786 
> 
> 
> Not visible are the trials I ran with git-svn and hg, both of which only 
> could handle the single head branch, but not all the other branching 
> craziness that was and is going on in the repo.
> 
> I don't fully recall, but I think that the hg conversion was slow and 
> the disk space needed was quite a bit more than git.
> 
> So in summary, I guess it can be summed up as:
> - there was no svn-all-fast-export for hg back then
> - even bitbucket switched from hg to git
> - history rewriting is easier in git, see e.g. this file for the stuff   
> that's required to make the cvs2svn things a bit nicer:   
> https://github.com/freebsd/git_conv/blob/master/fix_bogus_tags.sh
> 
> Granted, now that the heavy lifting is done, one could probably do a 
> git2hg transition, as the history is now pretty sane and should be 
> compatible to the hg model.
> 
> But lack of anyone (to my knowledge?) providing a hg copy of FreeBSD all 
> these years tells me that there's simply no demand for it.
> 
> There's https://wiki.freebsd.org/LocalMercurial from 2008 but that skips 
> converting from r1. Of interest is also 
> https://www.mercurial-scm.org/pipermail/mercurial/2019-May/051240.html 
> which looks like the size issues with hg haven't been fixed yet. It also 
> seems that http://hg-beta.freebsd.org/base/branches has the 
> user-servicable branches only, but not vendor. So it's not usable as a 
> source-of-truth for the project.
> 
> I would encourage everyone *not* to base their hg work off of SVN but 
> take the soon-official git repo instead. If you wanted to do this right 
> off of SVN, here's just one of dozens of quirks: 
> https://github.com/freebsd/git_conv/blob/master/revisions.md
> 
> You've been warned ;]

Thank you so much. This is very valuable post. I didn't expect such 
detailed information.
As I am using hg for my local projects and git for public / $WORK maybe 
one day I will try to setup hg repo from official git repo - just for 
"the fun".
I am completely fine with svn, or git or anything else was / is / will 
be the official source even if there is no tool in base. Installing 
package is so simple in these days.

Thank you again!

Kind regards
Miroslav Lachman

From steffen at sdaoden.eu  Wed Dec 23 16:24:21 2020
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 23 Dec 2020 17:24:17 +0100
Subject: HEADS UP: FreeBSD src repo transitioning to git this
 weekend
In-Reply-To: <20201223023242.GG31099@funkthat.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org>
 <CANCZdfrF0B7uux_neg-4XGn2UCDd4noUm7zP_icHnrpZUgmzzA@mail.gmail.com>
 <CAOtMX2gV2dmyG4b1hZG24sUnqDVk=1pch4xgQmyUdtLrh48kYg@mail.gmail.com>
 <CANCZdfpb0MF+uoW=K3cQpL+3vNQjSBDeVMab5d4JJhUO4sy-2Q@mail.gmail.com>
 <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com>
 <20201218175241.GA72552@spindle.one-eyed-alien.net>
 <20201218182820.1P0tK%steffen@sdaoden.eu>
 <20201223023242.GG31099@funkthat.com>
Message-ID: <20201223162417.v7Ce6%steffen@sdaoden.eu>

John-Mark Gurney wrote in
 <20201223023242.GG31099 at funkthat.com>:
 |Steffen Nurpmeso wrote this message on Fri, Dec 18, 2020 at 19:28 +0100:
 |> Brooks Davis wrote in
 |>  <20201218175241.GA72552 at spindle.one-eyed-alien.net>:
 |>|On Thu, Dec 17, 2020 at 05:53:20PM -0800, Thomas Mueller wrote:
 ...
 |>|Signed commits have no practicl effect on users of a repo.
 |> 
 |> Well you can verify integrity of a repository regardless of how it
 |> was distributed, this is why it is done, right.
 ...

 |TL;DR I don't see any reason for devs to sign commits.
 |
 |I could see use for RE (or another entity) to occasionally (weekly?)
 |sign the repo (say COPYRIGHT or UPDATING), and it would be nice for
 |them to sign all the tags used for releases, but having every dev
 |would both make the dev's life difficult...

Sure.  Signing at least releases makes a lot of sense.
Your idea of periodically sealing the tree is interesting, because
it can even be automatized (dependent on the key).
stable/ patch pumpkins could sign at least the last commit they
cherry pick back to stable, aren't ehy in distress already :)

 |It's also hard to collect ALL the keys of the devs at any point in
 |time to decide if that key is authorized to sign a commit in the
 |repo...  Like if a dev starts in 2021, any commits made by that
 |dev prior to 2021 should not be "valid"..  Then there's also the
 |issue that people's keys change over time, and now you need to know
 |what time period each key was valid for, otherwise a compromised key
 |could be used to insert malicious changes into your/the tree...
 |
 |Then there's also the point that the repo is (looks like it) using
 |SHA-1 hashes, which are effectively broken, so depending upon them
 |to validate the tree is questionable anyways.

git uses the hardened SHA-1 for sure, which is, as far as i know,
at least safe against the known attack.
I .. have not tracked this, but i think upgrading to SHA-256 is
possible, once this will become standard.  Just even more
metadata, then.  I have not looked into this, still in progress.

Imho: devs should show "muchos cojones".
I am sure you appreciate a daunting post, i think it is ok to
quote this post from openssl-dev at openssl.org ("Re: Attribution of
pull requests in git"):

  Theodore Ts'o wrote in
   <20140426145907.GA1278 at thunk.org>:
   |On Sat, Apr 26, 2014 at 11:29:39AM +0100, Ben Laurie wrote:
   |> I just noticed that if I merge a pull request, then both author and
   |> committer are set to whoever made the pull request.
   |
   |Are you using github, or git using its standard pull request workflow?
   |
   |In the standard git workflow, the author and committer is set to the
   |person who merged the pull.  The person who requested the pull request
   |is recorded in the signed git tag.  For example, I recently signed a
   |git tag:
   |
   |% git tag -s ext4_for_linus_stable
   |
   | <Insert smart card, type the pin to create the GPG signed tag>

Wonderful.

   |% git push ssh://gitolite at ra.kernel.org/pub/scm/linux/kernel/git/tytso/e\
   |xt4.git tags/ext4_for_linus_stable
   |
   | <Type pin to unlock the ssh key, which is also on the smart card>  

Ah yes.
Correct enough for German public law television at its best!

   |% git request-pull origin git://git.kernel.org/pub/scm/linux/kernel/git/\
   |tytso/ext4.git tags/ext4_for_linus_stable > /tmp/pull
   |
   |(I have aliases and shell scripts for most of this, but I've expanded
   |all of this out for clarity.)
   |
   |Then I e-mailed the following to Linus, and then after he merged the
   |pull request, when I pulled down his tree, tou can see the following:
   |
   |% git show --pretty=fuller --show-signature  origin
   |commit 9ac03675010a69507c0a9d832d6a722e07d35cc6
   |merged tag 'ext4_for_linus_stable'
   |gpg: Signature made Sun 20 Apr 2014 10:23:16 PM EDT using RSA key ID \
   |C11804F0
   |gpg: Good signature from "Theodore Ts'o <tytso at mit.edu>"
   |gpg:                 aka "Theodore Ts'o <tytso at debian.org>"
   |gpg:                 aka "Theodore Ts'o <tytso at google.com>"
   |Merge: a798c10 0a04b24
   |Author:     Linus Torvalds <torvalds at linux-foundation.org>
   |AuthorDate: Sun Apr 20 20:43:47 2014 -0700
   |Commit:     Linus Torvalds <torvalds at linux-foundation.org>
   |CommitDate: Sun Apr 20 20:43:47 2014 -0700

   ...

   |The advantage of doing this way is that git will detach the signature
   |from the tag, and save it in the merge conflict, so years later, the
   |cryptographic accountability chain is preserved in the git tree.
   |
   |Cheers,

Hope that helps.
I personally sign releases and (at least the head of a bunch of)
commits to [master] and [stable] (it is a git alias which does
it).  Looser that i am i have a setup-privacy script on an
encrypted partition that loads keys, unfortunately not even root
can kill -SOMESIG to cause all ssh-agents etc to unload and clear
the loaded keys, therefore i hook acpi and do something like

   if command -v ssh-add >/dev/null 2>&1; then
      for a in /tmp/ssh-*/agent.*; do
         [ -e "$a" ] || continue
         act '( SSH_AUTH_SOCK="$a" ssh-add -D ) </dev/null >/dev/null 2>&1 &'
      done
   fi

Luckily i do not yet use per-user private temporary directories.
All in all it is terrible mess.

A good afternoon from Germany i wish.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From bsd-lists at bsdforge.com  Wed Dec 23 16:43:50 2020
From: bsd-lists at bsdforge.com (Chris)
Date: Wed, 23 Dec 2020 08:44:09 -0800
Subject: FreeBSD: GitLab
In-Reply-To: <7b82f25b-9f0a-32c1-0f05-3a92474051b4@gmail.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <20201222183900.GA22353@www.zefox.net>
 <81C07616-434E-4DF4-91AC-518AECF4F16F@gromit.dlib.vt.edu>
 <01b07b90-e206-aa56-aa5b-91c764ef36a4@gmail.com>
 <CANCZdfpJC4jA0ZUfP90FkeY-EWpLJo+ZcRctV6GUKt=tyUG2kA@mail.gmail.com>
 <f52741305ad7d4eb3643c99320fa5b92@bsdforge.com>
 <7b82f25b-9f0a-32c1-0f05-3a92474051b4@gmail.com>
Message-ID: <83c34f774c1f8a3c164086883882ba7f@bsdforge.com>

On 2020-12-23 07:41, Graham Perrin wrote:
> On 23/12/2020 15:36, Chris wrote:
> 
>> ? Any plans to incorporate GitLab into any of this?
> 
> 
> <https://github.com/bsdimp/freebsd-git-docs/search?q=GitLab> ? 
> big-picture.md is
> probably the best starting point.
Brilliant! :)

I mainly asked because GitLab seems to offer a richer toolset IMHO.

Thanks, Graham!

--Chris
> 

From imp at bsdimp.com  Wed Dec 23 16:52:32 2020
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 23 Dec 2020 09:52:19 -0700
Subject: FreeBSD: GitLab
In-Reply-To: <83c34f774c1f8a3c164086883882ba7f@bsdforge.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <20201222183900.GA22353@www.zefox.net>
 <81C07616-434E-4DF4-91AC-518AECF4F16F@gromit.dlib.vt.edu>
 <01b07b90-e206-aa56-aa5b-91c764ef36a4@gmail.com>
 <CANCZdfpJC4jA0ZUfP90FkeY-EWpLJo+ZcRctV6GUKt=tyUG2kA@mail.gmail.com>
 <f52741305ad7d4eb3643c99320fa5b92@bsdforge.com>
 <7b82f25b-9f0a-32c1-0f05-3a92474051b4@gmail.com>
 <83c34f774c1f8a3c164086883882ba7f@bsdforge.com>
Message-ID: <CANCZdfr-gYYd5updHq2jG4nOqkOmPdKeYd1H98AmTKo0R35ong@mail.gmail.com>

On Wed, Dec 23, 2020 at 9:44 AM Chris <bsd-lists at bsdforge.com> wrote:

> On 2020-12-23 07:41, Graham Perrin wrote:
> > On 23/12/2020 15:36, Chris wrote:
> >
> >> ? Any plans to incorporate GitLab into any of this?
> >
> >
> > <https://github.com/bsdimp/freebsd-git-docs/search?q=GitLab> ?
> > big-picture.md is
> > probably the best starting point.
> Brilliant! :)
>
> I mainly asked because GitLab seems to offer a richer toolset IMHO.
>

The project is publishing many places, and will use features of the places
it publishes as it refines the future workflow. The different
mirroring/hosting services offer different features and it's not yet clear
how we can best utilize them or if even one size fits all.

Warner

From imp at bsdimp.com  Wed Dec 23 16:58:23 2020
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 23 Dec 2020 09:58:10 -0700
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <e1e5af32-f8cf-ab07-c959-57db87c159d0@plan-b.pwste.edu.pl>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <e1e5af32-f8cf-ab07-c959-57db87c159d0@plan-b.pwste.edu.pl>
Message-ID: <CANCZdfr0z9bfmdNSDkCb23ToHQx2reH+JSEw21UBqyGUZ_tgiA@mail.gmail.com>

On Wed, Dec 23, 2020 at 3:35 AM Marek Zarychta <
zarychtam at plan-b.pwste.edu.pl> wrote:

> W dniu 17.12.2020 o 01:46, Warner Losh pisze:
> > Greetings,
> >
> > The FreeBSD project will be moving it's source repo from subversion to
> git
> > starting this this weekend. The docs repo was moved 2 weeks ago. The
> ports
> > repo will move at the end of March, 2021 due to timing issues.
> >
> > The short version is that we're switching the version control we're
> using.
> > This switch will preserve much of the current FreeBSD development
> workflow.
> > After the switch, the subversion repo will become almost read-only. All
> > future work will be done in git, however as a transition aide we'll be
> > replaying the MFCs to stable/11, stable/12 and the related releng
> branches
> > for the life of those branches.
> >
> > For more detailed information, please see
> > https://github.com/bsdimp/freebsd-git-docs/ for the current
> documentation.
> >
> > Please see https://wiki.freebsd.org/git for the latest detailed schedule
> > (please note that this schedule is subject to change).
> >
> > Warner
> > _______________________________________________
> > freebsd-current at freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "
> freebsd-current-unsubscribe at freebsd.org"
> >
>
> Will the project utilize gitatributes(5) to support ident as $Id:$ in
> git repository?
>

There are no plans. $Id$, as implemented in git, records the wrong
information. Rather than a commit hash, it's the blob object hash which can
be hard to puzzle out. It would cause way more confusion were we to use it.
Plus, when I did experiments with it, it was slow and difficult to work
with. Given these issues, we've opted to not use it. Plus there's no
documented way to change $Id$ to $FreeBSD$ in an easy way, and the
filtering stuff looked extra fragile.


> In file header, we have now only $FreeBSD$ since svn tags disappeared
> after the transition. Adding ident tags to certain files which are
> updated by mergemaster(8) or etcupdated(8) would be appreciated.
>

mergemaster and etcupdate can cope without them.

Warner

From bsd-lists at bsdforge.com  Wed Dec 23 17:01:30 2020
From: bsd-lists at bsdforge.com (Chris)
Date: Wed, 23 Dec 2020 09:01:47 -0800
Subject: FreeBSD: GitLab
In-Reply-To: <CANCZdfr-gYYd5updHq2jG4nOqkOmPdKeYd1H98AmTKo0R35ong@mail.gmail.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <20201222183900.GA22353@www.zefox.net>
 <81C07616-434E-4DF4-91AC-518AECF4F16F@gromit.dlib.vt.edu>
 <01b07b90-e206-aa56-aa5b-91c764ef36a4@gmail.com>
 <CANCZdfpJC4jA0ZUfP90FkeY-EWpLJo+ZcRctV6GUKt=tyUG2kA@mail.gmail.com>
 <f52741305ad7d4eb3643c99320fa5b92@bsdforge.com>
 <7b82f25b-9f0a-32c1-0f05-3a92474051b4@gmail.com>
 <83c34f774c1f8a3c164086883882ba7f@bsdforge.com>
 <CANCZdfr-gYYd5updHq2jG4nOqkOmPdKeYd1H98AmTKo0R35ong@mail.gmail.com>
Message-ID: <a5490a8ff71874b005654b82c417f804@bsdforge.com>

On 2020-12-23 08:52, Warner Losh wrote:
> On Wed, Dec 23, 2020 at 9:44 AM Chris <bsd-lists at bsdforge.com> wrote:
> 
>> On 2020-12-23 07:41, Graham Perrin wrote:
>> > On 23/12/2020 15:36, Chris wrote:
>> >
>> >> ? Any plans to incorporate GitLab into any of this?
>> >
>> >
>> > <https://github.com/bsdimp/freebsd-git-docs/search?q=GitLab> ?
>> > big-picture.md is
>> > probably the best starting point.
>> Brilliant! :)
>> 
>> I mainly asked because GitLab seems to offer a richer toolset IMHO.
>> 
> 
> The project is publishing many places, and will use features of the places
> it publishes as it refines the future workflow. The different
> mirroring/hosting services offer different features and it's not yet clear
> how we can best utilize them or if even one size fits all.
Sure. I got that following the notes from the search listed above.
Just to be clear; I was *not* suggesting anyone was making any *wrong*
choices here. Just a humble inquiry. :-)

Thanks for taking the time to respond, Warner.
> 
> Warner

--Chris

From brooks at freebsd.org  Wed Dec 23 17:01:35 2020
From: brooks at freebsd.org (Brooks Davis)
Date: Wed, 23 Dec 2020 17:01:32 +0000
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <20201223023242.GG31099@funkthat.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org>
 <CANCZdfrF0B7uux_neg-4XGn2UCDd4noUm7zP_icHnrpZUgmzzA@mail.gmail.com>
 <CAOtMX2gV2dmyG4b1hZG24sUnqDVk=1pch4xgQmyUdtLrh48kYg@mail.gmail.com>
 <CANCZdfpb0MF+uoW=K3cQpL+3vNQjSBDeVMab5d4JJhUO4sy-2Q@mail.gmail.com>
 <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com>
 <20201218175241.GA72552@spindle.one-eyed-alien.net>
 <20201218182820.1P0tK%steffen@sdaoden.eu>
 <20201223023242.GG31099@funkthat.com>
Message-ID: <20201223170132.GB94898@spindle.one-eyed-alien.net>

On Tue, Dec 22, 2020 at 06:32:43PM -0800, John-Mark Gurney wrote:
> Steffen Nurpmeso wrote this message on Fri, Dec 18, 2020 at 19:28 +0100:
> > Brooks Davis wrote in
> >  <20201218175241.GA72552 at spindle.one-eyed-alien.net>:
> >  |On Thu, Dec 17, 2020 at 05:53:20PM -0800, Thomas Mueller wrote:
> >  |>>> I hope we don't have to start signing all commits.  saltstack/salt has
> >  |>>> that policy, and it's extremely annoying.
> >  |> 
> >  |>> Have to? Not currently. As with all process changes, there will be
> >  |>> community discussion around the different points.
> >  |> 
> >  |>> Warner
> >  |> 
> >  |> I hope not!
> >  |> 
> >  |> Signatures, at least in email messages, are just an annoyance as \
> >  |> I see them.
> >  |> 
> >  |> I don't even know how do sign an email message or make use of a signatur\
> >  |> e in a message I receive.
> >  |> 
> >  |> I have never made a commit to a repository, so would not be familiar \
> >  |> with signatures there; imagine it would be a barrier.
> >  |
> >  |Signed commits have no practicl effect on users of a repo.
> > 
> > Well you can verify integrity of a repository regardless of how it
> > was distributed, this is why it is done, right.
> > 
> >   #?0$ git log --oneline --show-signature -1 v14.9.20.ar
> >   16a21755 (...)
> >   gpg: Signature made Sun 13 Dec 2020 12:43:44 AM CET
> >   gpg:                using RSA key DF082F6AEEC8C2FF
> >   gpg: Good signature from "Steffen Nurpmeso <steffen at sdaoden.eu>"
> >   Bump S-nail v14.9.20.ar ("Sombre Tit (Trauermeise)"), 2020-12-12
> > 
> >   #?0$ git tag -v v14.9.20.ar; echo $?
> >   object 16a21755fd1fade2b15fdb78a592f12169c3453f
> >   type commit
> >   tag v14.9.20.ar
> >   tagger Steffen Nurpmeso <steffen at sdaoden.eu> 1607816624 +0100
> >   
> >   Bump S-nail v14.9.20.ar ("Sombre Tit (Trauermeise)"), 2020-12-12
> >   gpg: Signature made Sun 13 Dec 2020 12:43:44 AM CET
> >   gpg:                using RSA key DF082F6AEEC8C2FF
> >   gpg: Good signature from "Steffen Nurpmeso <steffen at sdaoden.eu>"
> >   0
> 
> TL;DR I don't see any reason for devs to sign commits.
> 
> I could see use for RE (or another entity) to occasionally (weekly?)
> sign the repo (say COPYRIGHT or UPDATING), and it would be nice for
> them to sign all the tags used for releases, but having every dev
> would both make the dev's life difficult...

I think RE signing releases makes some sense.  Routine signing of commits
eliminates lots of potentially useful workflows if you also want linear
history.  In particular it makes it impractical to implement any form of
commit-automatically-after-CI type workflows because rebase looses the
signature.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20201223/714b963d/attachment.sig>

From imp at bsdimp.com  Wed Dec 23 17:02:04 2020
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 23 Dec 2020 10:01:51 -0700
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <C47EED5D-2997-49FE-8D17-AD64E1317033@ellael.org>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <C47EED5D-2997-49FE-8D17-AD64E1317033@ellael.org>
Message-ID: <CANCZdfrX-4ZbJ1EougMghzkiMJea=kyWmSutwBPMqXydPTTULA@mail.gmail.com>

On Wed, Dec 23, 2020 at 7:32 AM Michael Grimm <trashcan at ellael.org> wrote:

> Hi,
>
> Warner Losh <imp at bsdimp.com> wrote:
>
> > The FreeBSD project will be moving it's source repo from subversion to
> git
> > starting this this weekend.
>
> First of all I'd like to thank all those involved in this for their
> efforts.
>
> Following
> https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md form
> your other mail I was able to migrate from svn to git without running into
> any issues.
>
> Right now I am learning how to use git the way I sed svn before. I am just
> following 12-STABLE in order to build world and kernel. I am not
> developing, neither am I committing.
>
> I wonder how one would switch from a currently used branch (OLD) to
> another branch (NEW).
>
> With svn I used:
>         svn switch svn://svn.freebsd.org/base/stable/NEW /usr/src
>
> For git I found:
>         git branch -m stable/OLD stable/NEW
>         or
>         git branch -M stable/OLD stable/NEW
>
> git-branch(1):
>        With a -m or -M option, <oldbranch> will be renamed to <newbranch>.
> If
>        <oldbranch> had a corresponding reflog, it is renamed to match
>        <newbranch>, and a reflog entry is created to remember the branch
>        renaming. If <newbranch> exists, -M must be used to force the
> rename to
>        happen.
>
> I don't understand that text completely, because I don't know what a
> reflog is, yet ;-)
>
> Thus: Should I use "-m" or "-M" in my scenario when switching from
> stable/12 to stable/13 in the near future?
>

I think the answer is a simple "git checkout NEW". This will replace the
current tree at branch OLD with the contents of branch NEW.

git branch -m is different and changes what the branch means. If you did
what you suggested then you'd be renaming the OLD brnach to NEW, which
isn't what I think you're asking about.

Warner

From trashcan at ellael.org  Wed Dec 23 18:15:19 2020
From: trashcan at ellael.org (Michael Grimm)
Date: Wed, 23 Dec 2020 19:15:01 +0100
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <CANCZdfrX-4ZbJ1EougMghzkiMJea=kyWmSutwBPMqXydPTTULA@mail.gmail.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <C47EED5D-2997-49FE-8D17-AD64E1317033@ellael.org>
 <CANCZdfrX-4ZbJ1EougMghzkiMJea=kyWmSutwBPMqXydPTTULA@mail.gmail.com>
Message-ID: <8E062816-5CC1-42A4-ACE2-E0382960AC07@ellael.org>

Warner Losh <imp at bsdimp.com> wrote:
> On Wed, Dec 23, 2020 at 7:32 AM Michael Grimm <trashcan at ellael.org> wrote:

>> With svn I used:
>>        svn switch svn://svn.freebsd.org/base/stable/NEW /usr/src
>> 
>> For git I found:
>>        git branch -m stable/OLD stable/NEW
>>        or
>>        git branch -M stable/OLD stable/NEW
> 
> I think the answer is a simple "git checkout NEW". This will replace the
> current tree at branch OLD with the contents of branch NEW.


Thanks to all of you pointing me away from renaming a branch instead of simply checking out the branch of interest.


> git branch -m is different and changes what the branch means. If you did
> what you suggested then you'd be renaming the OLD brnach to NEW, which
> isn't what I think you're asking about.

No, I will not apply anything before having it understood. In this case I looked into git-branch(1) because I believed this the command to be. Haven't found git-checkout(1) :-( Sorry for the noise.

Now, stable/13 may come, I am ready to switch ;-)

Thanks again and regards,
Michael

From trashcan at ellael.org  Wed Dec 23 18:20:07 2020
From: trashcan at ellael.org (Michael Grimm)
Date: Wed, 23 Dec 2020 19:20:00 +0100
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <0bce6fd0-7a54-b90a-ac6b-24226d77a87f@FreeBSD.org>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <C47EED5D-2997-49FE-8D17-AD64E1317033@ellael.org>
 <0bce6fd0-7a54-b90a-ac6b-24226d77a87f@FreeBSD.org>
Message-ID: <E5394E7E-9F1D-4BAC-A6F2-EB03537274E3@ellael.org>

Renato Botelho <garga at FreeBSD.org> wrote:

> If you want to switch to a different already existing branch, as svn switch does, you should look at git-checkout.
> 
> It can be a bit expensive due to the size of src repository so if you do work on multiple branches too often you can improve it using git-worktree.

If I understand git-worktree(1) correctly I will most probably not need it, because I will only follow one single branch stable/12, and soon stable/13. Or do I miss something important?

Thanks and regards,
Michael
 

From garga at FreeBSD.org  Wed Dec 23 18:51:20 2020
From: garga at FreeBSD.org (Renato Botelho)
Date: Wed, 23 Dec 2020 15:51:15 -0300
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <E5394E7E-9F1D-4BAC-A6F2-EB03537274E3@ellael.org>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <C47EED5D-2997-49FE-8D17-AD64E1317033@ellael.org>
 <0bce6fd0-7a54-b90a-ac6b-24226d77a87f@FreeBSD.org>
 <E5394E7E-9F1D-4BAC-A6F2-EB03537274E3@ellael.org>
Message-ID: <eac0e80c-d5a0-cac3-a537-ec84d26586ef@FreeBSD.org>

On 23/12/20 15:20, Michael Grimm wrote:
> Renato Botelho <garga at FreeBSD.org> wrote:
> 
>> If you want to switch to a different already existing branch, as svn switch does, you should look at git-checkout.
>>
>> It can be a bit expensive due to the size of src repository so if you do work on multiple branches too often you can improve it using git-worktree.
> 
> If I understand git-worktree(1) correctly I will most probably not need it, because I will only follow one single branch stable/12, and soon stable/13. Or do I miss something important?

You are correct.  You can clone stable/12 now and when it's time just do

# git checkout stable/13

-- 
Renato Botelho

From warlock at phouka.net  Wed Dec 23 20:22:22 2020
From: warlock at phouka.net (John Kennedy)
Date: Wed, 23 Dec 2020 12:19:47 -0800
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <X+EJ6rvSLoEx7ksp@phouka1.phouka.net>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <X+EJ6rvSLoEx7ksp@phouka1.phouka.net>
Message-ID: <X+OmY5myoo1MWmmW@phouka1.phouka.net>

On Mon, Dec 21, 2020 at 12:47:38PM -0800, John Kennedy wrote:
> On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote:
> > The FreeBSD project will be moving it's source repo from subversion to git
> > starting this this weekend. The docs repo was moved 2 weeks ago. The ports
> > repo will move at the end of March, 2021 due to timing issues. ...
> 
>   I filed Bug 252028 (sys/conf/newvers.sh: git "-dirty" even when clean),
> but that's just a trivial issue with my source tree being marked -dirty
> when it isn't, and that would have been part of r368709 anyway.  All my
> other git nits have been my own (refs/notes and origin name).

  Warner/others, up to r368820, we had log entries that looked like this:

	commit 3cc0c0d66a065554459bd2f9b4f80cc07426464a
	Author: Li-Wen Hsu <lwhsu at FreeBSD.org>
	Date:   Sun Dec 20 02:59:44 2020 +0000
	
	    Mark the repository as being converted to Git.
	
	    This is the last Subversion commit to src.
	
	    Sponsored by:   The FreeBSD Foundation
	
	Notes:
	    svn path=/head/; revision=368820

  Now, our git logs look like this:

	commit 17eba5e32a2cf7a217bb9f1e5dcca351f2b71cfc
	Author: Ed Maste <emaste at FreeBSD.org>
	Date:   Tue Dec 22 23:31:15 2020 -0500
	
	    newvers.sh: fix sense of git dirty check
	
	    Previously we reported -dirty for an unmodified tree, and no -dirty if
	    there were changes.
	
	    PR:             252028
	    Reported by:    John Kennedy

  (Specifically, no Notes: with revision= value)

  For the kernel I compiled today, the uname output dumps out:

	FreeBSD 13.0-CURRENT #245 r368820+878d53410f75-c255274(main): ...

  Last kernel was (-dirty since fixed):

	FreeBSD 13.0-CURRENT #244 r368820+3cc0c0d66a06-c255241(main)-dirty: ...

  So, the r368820-value isn't being updated for it to find anymore.  The middle
value corresponds to the git commit and does have value (878d53410f75 is your
"UPDATING: Announce git transition", 3cc0c0d66a06 was the "Mark the repository
as being converted to Git" r368820 commit).

  How do you plan on referencing distinct patches now?  If the revision number
is going away, we might as well yank it out since it'll be r368820 forever.

  For my git projects, I often use a "git tag -a" (annotated) commit at useful
milestones, but I'm not sure what you're using it for:

    [git describe]
	vendor/bc/3.2.3-255270-g3f3cc995a35a


From uqs at freebsd.org  Wed Dec 23 20:55:06 2020
From: uqs at freebsd.org (Ulrich =?utf-8?B?U3DDtnJsZWlu?=)
Date: Wed, 23 Dec 2020 21:55:01 +0100
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <X+OmY5myoo1MWmmW@phouka1.phouka.net>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <X+EJ6rvSLoEx7ksp@phouka1.phouka.net>
 <X+OmY5myoo1MWmmW@phouka1.phouka.net>
Message-ID: <X+OupQ7KWwZzMSlt@acme.spoerlein.net>

On Wed, 2020-12-23 at 12:19:47 -0800, John Kennedy wrote:
>On Mon, Dec 21, 2020 at 12:47:38PM -0800, John Kennedy wrote:
>> On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote:
>> > The FreeBSD project will be moving it's source repo from subversion to git
>> > starting this this weekend. The docs repo was moved 2 weeks ago. The ports
>> > repo will move at the end of March, 2021 due to timing issues. ...
>>
>>   I filed Bug 252028 (sys/conf/newvers.sh: git "-dirty" even when clean),
>> but that's just a trivial issue with my source tree being marked -dirty
>> when it isn't, and that would have been part of r368709 anyway.  All my
>> other git nits have been my own (refs/notes and origin name).
>
>  Warner/others, up to r368820, we had log entries that looked like this:
>
>	commit 3cc0c0d66a065554459bd2f9b4f80cc07426464a
>	Author: Li-Wen Hsu <lwhsu at FreeBSD.org>
>	Date:   Sun Dec 20 02:59:44 2020 +0000
>	
>	    Mark the repository as being converted to Git.
>	
>	    This is the last Subversion commit to src.
>	
>	    Sponsored by:   The FreeBSD Foundation
>	
>	Notes:
>	    svn path=/head/; revision=368820
>
>  Now, our git logs look like this:
>
>	commit 17eba5e32a2cf7a217bb9f1e5dcca351f2b71cfc
>	Author: Ed Maste <emaste at FreeBSD.org>
>	Date:   Tue Dec 22 23:31:15 2020 -0500
>	
>	    newvers.sh: fix sense of git dirty check
>	
>	    Previously we reported -dirty for an unmodified tree, and no -dirty if
>	    there were changes.
>	
>	    PR:             252028
>	    Reported by:    John Kennedy
>
>  (Specifically, no Notes: with revision= value)

Yes, these notes are merely pointers to the SVN revisions. Without SVN, 
we will of course not get any new notes.

>  For the kernel I compiled today, the uname output dumps out:
>
>	FreeBSD 13.0-CURRENT #245 r368820+878d53410f75-c255274(main): ...
>
>  Last kernel was (-dirty since fixed):
>
>	FreeBSD 13.0-CURRENT #244 r368820+3cc0c0d66a06-c255241(main)-dirty: ...
>
>  So, the r368820-value isn't being updated for it to find anymore.  The middle
>value corresponds to the git commit and does have value (878d53410f75 is your
>"UPDATING: Announce git transition", 3cc0c0d66a06 was the "Mark the repository
>as being converted to Git" r368820 commit).

Yeah, that's a bug in newvers.sh, thanks for pointing that out. It finds 
"some" note in the last 10k revs and then uses that, instead of properly 
falling back to counting from HEAD, which would result in -c255126 or 
something around that.

We'll fix it ...

Cheers
Uli

From rhurlin at gwdg.de  Wed Dec 23 21:12:27 2020
From: rhurlin at gwdg.de (Rainer Hurling)
Date: Wed, 23 Dec 2020 22:12:19 +0100
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <X+OupQ7KWwZzMSlt@acme.spoerlein.net>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <X+EJ6rvSLoEx7ksp@phouka1.phouka.net> <X+OmY5myoo1MWmmW@phouka1.phouka.net>
 <X+OupQ7KWwZzMSlt@acme.spoerlein.net>
Message-ID: <bb64208b-ce0d-65a0-8ac4-906c1dd6ef7f@gwdg.de>

Am 23.12.20 um 21:55 schrieb Ulrich Sp?rlein:
> On Wed, 2020-12-23 at 12:19:47 -0800, John Kennedy wrote:
>> On Mon, Dec 21, 2020 at 12:47:38PM -0800, John Kennedy wrote:
>>> On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote:
>>> > The FreeBSD project will be moving it's source repo from subversion
>>> to git
>>> > starting this this weekend. The docs repo was moved 2 weeks ago.
>>> The ports
>>> > repo will move at the end of March, 2021 due to timing issues. ...
>>>
>>> ? I filed Bug 252028 (sys/conf/newvers.sh: git "-dirty" even when
>>> clean),
>>> but that's just a trivial issue with my source tree being marked -dirty
>>> when it isn't, and that would have been part of r368709 anyway.? All my
>>> other git nits have been my own (refs/notes and origin name).
>>
>> ?Warner/others, up to r368820, we had log entries that looked like this:
>>
>> ????commit 3cc0c0d66a065554459bd2f9b4f80cc07426464a
>> ????Author: Li-Wen Hsu <lwhsu at FreeBSD.org>
>> ????Date:?? Sun Dec 20 02:59:44 2020 +0000
>> ????
>> ??????? Mark the repository as being converted to Git.
>> ????
>> ??????? This is the last Subversion commit to src.
>> ????
>> ??????? Sponsored by:?? The FreeBSD Foundation
>> ????
>> ????Notes:
>> ??????? svn path=/head/; revision=368820
>>
>> ?Now, our git logs look like this:
>>
>> ????commit 17eba5e32a2cf7a217bb9f1e5dcca351f2b71cfc
>> ????Author: Ed Maste <emaste at FreeBSD.org>
>> ????Date:?? Tue Dec 22 23:31:15 2020 -0500
>> ????
>> ??????? newvers.sh: fix sense of git dirty check
>> ????
>> ??????? Previously we reported -dirty for an unmodified tree, and no
>> -dirty if
>> ??????? there were changes.
>> ????
>> ??????? PR:???????????? 252028
>> ??????? Reported by:??? John Kennedy
>>
>> ?(Specifically, no Notes: with revision= value)
> 
> Yes, these notes are merely pointers to the SVN revisions. Without SVN,
> we will of course not get any new notes.
> 
>> ?For the kernel I compiled today, the uname output dumps out:
>>
>> ????FreeBSD 13.0-CURRENT #245 r368820+878d53410f75-c255274(main): ...
>>
>> ?Last kernel was (-dirty since fixed):
>>
>> ????FreeBSD 13.0-CURRENT #244
>> r368820+3cc0c0d66a06-c255241(main)-dirty: ...
>>
>> ?So, the r368820-value isn't being updated for it to find anymore.?
>> The middle
>> value corresponds to the git commit and does have value (878d53410f75
>> is your
>> "UPDATING: Announce git transition", 3cc0c0d66a06 was the "Mark the
>> repository
>> as being converted to Git" r368820 commit).
> 
> Yeah, that's a bug in newvers.sh, thanks for pointing that out. It finds
> "some" note in the last 10k revs and then uses that, instead of properly
> falling back to counting from HEAD, which would result in -c255126 or
> something around that.

I built HEAD this afternoon and got 'FreeBSD 13.0-CURRENT #0
92be2847e84-c255272(main): Wed Dec 23 17:39:31 CET 2020'. The counting
seems more correct here?

> We'll fix it ...
> 
> Cheers
> Uli

From ml+freebsd at vishwin.info  Wed Dec 23 22:06:04 2020
From: ml+freebsd at vishwin.info (Charlie Li)
Date: Wed, 23 Dec 2020 17:05:49 -0500
Subject: git tools for building in base?
In-Reply-To: <X+M96JQwp+QCIIWH@acme.spoerlein.net>
References: <X714z7pMgNOFaTIc@rpi4.local>
 <20201125055425.01AA628417@elsa.codelab.cz>
 <10f7b800-b015-2a80-b741-4f7db03bf6eb@quip.cz>
 <X+M96JQwp+QCIIWH@acme.spoerlein.net>
Message-ID: <59893166-d05a-89b5-798b-c89e3392756b@vishwin.info>

Ulrich Sp?rlein wrote:
> I don't fully recall, but I think that the hg conversion was slow and
> the disk space needed was quite a bit more than git.
> 
One of Mercurial's biggest design principles is immutable history (with
history rewriting disabled by default), so increased disk space compared
to git is reasonable.
> So in summary, I guess it can be summed up as:
> - there was no svn-all-fast-export for hg back then
> - even bitbucket switched from hg to git
Bitbucket dropping Mercurial support was more a business decision,
although more ancillary tooling for git existing and developer appetite
certainly played factors there.
> - history rewriting is easier in git, see e.g. this file for the stuff ?
> that's required to make the cvs2svn things a bit nicer: ?
> https://github.com/freebsd/git_conv/blob/master/fix_bogus_tags.sh
> 
> Granted, now that the heavy lifting is done, one could probably do a
> git2hg transition, as the history is now pretty sane and should be
> compatible to the hg model.
> 
Mercurial's branches are more similar to subversion than git. The hg
analogue to git's branches are bookmarks, for which even they are
optional since hg has its heads concept.
> But lack of anyone (to my knowledge?) providing a hg copy of FreeBSD all
> these years tells me that there's simply no demand for it.
> 
I use hg-beta for ports. Also used it for src up until git-beta came
online. Not sure what I will do once ports is converted to git, however.

My mercurial use stems from two sources: committers' need to preserve
copy/move history (though this will probably go away with git) and
horrendous performance with the ports tree in git. Horrendous as in, for
example, takes about five minutes just to run git-status(1) on a ports
tree stored on a hard drive with UFS (-uno doesn't help) whilst locking
up the entire system I/O for the duration. The I/O lockups have since
subsided but as of six months ago the slow enumeration has persisted.
For some reason, mercurial is far more efficient in this regard.

-- 
Charlie Li
?nope, still don't have an exit line.

(This email address is for mailing list use; replace local-part with
vishwin for off-list communication if possible)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20201223/645b5f32/attachment.sig>

From rmacklem at uoguelph.ca  Wed Dec 23 22:16:31 2020
From: rmacklem at uoguelph.ca (Rick Macklem)
Date: Wed, 23 Dec 2020 22:16:17 +0000
Subject: referencing one commit in another for git
Message-ID: <YQXPR0101MB0968535A875FF1D2C32352E8DDDE0@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>

Hi,

So I just did my first git commit. Pretty scary, but it looks ok.

Now, how do I reference one commit in another related
commit's log?

By the long winded hash or ??

I'm not sure if I should ask here or on the git mailing list,
but I figured this isn't a technical git question...

Thanks for any help with this, rick

From asomers at freebsd.org  Wed Dec 23 22:21:08 2020
From: asomers at freebsd.org (Alan Somers)
Date: Wed, 23 Dec 2020 15:20:55 -0700
Subject: referencing one commit in another for git
In-Reply-To: <YQXPR0101MB0968535A875FF1D2C32352E8DDDE0@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
References: <YQXPR0101MB0968535A875FF1D2C32352E8DDDE0@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
Message-ID: <CAOtMX2gsYVeN1NZVjtGX7EDNFnL2qKV+g3GtSS-YFyn1A6_wLg@mail.gmail.com>

On Wed, Dec 23, 2020 at 3:16 PM Rick Macklem <rmacklem at uoguelph.ca> wrote:

> Hi,
>
> So I just did my first git commit. Pretty scary, but it looks ok.
>
> Now, how do I reference one commit in another related
> commit's log?
>
> By the long winded hash or ??
>
> I'm not sure if I should ask here or on the git mailing list,
> but I figured this isn't a technical git question...
>
> Thanks for any help with this, rick
>

Yeah, you should use the full hash.  For temporary references, like during
a code review, you can use the first "several" digits of the hash.   For a
project of FreeBSD's size, "several" is probably 11-13.  But in permanent
contexts, like commit logs, you should use the full hash.  When somebody
views the commit on a platform like Github, Github will automatically turn
it into a hyperlink, and display only the first "several" digits.
-Alan

From imp at bsdimp.com  Wed Dec 23 23:02:13 2020
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 23 Dec 2020 16:01:59 -0700
Subject: referencing one commit in another for git
In-Reply-To: <CAOtMX2gsYVeN1NZVjtGX7EDNFnL2qKV+g3GtSS-YFyn1A6_wLg@mail.gmail.com>
References: <YQXPR0101MB0968535A875FF1D2C32352E8DDDE0@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
 <CAOtMX2gsYVeN1NZVjtGX7EDNFnL2qKV+g3GtSS-YFyn1A6_wLg@mail.gmail.com>
Message-ID: <CANCZdfp0WDqM_f01JZgScyeDh_tBgYSrWSzk4ruQb526B9y2vw@mail.gmail.com>

On Wed, Dec 23, 2020, 3:21 PM Alan Somers <asomers at freebsd.org> wrote:

> On Wed, Dec 23, 2020 at 3:16 PM Rick Macklem <rmacklem at uoguelph.ca> wrote:
>
> > Hi,
> >
> > So I just did my first git commit. Pretty scary, but it looks ok.
> >
> > Now, how do I reference one commit in another related
> > commit's log?
> >
> > By the long winded hash or ??
> >
> > I'm not sure if I should ask here or on the git mailing list,
> > but I figured this isn't a technical git question...
> >
> > Thanks for any help with this, rick
> >
>
> Yeah, you should use the full hash.  For temporary references, like during
> a code review, you can use the first "several" digits of the hash.   For a
> project of FreeBSD's size, "several" is probably 11-13.  But in permanent
> contexts, like commit logs, you should use the full hash.  When somebody
> views the commit on a platform like Github, Github will automatically turn
> it into a hyperlink, and display only the first "several" digits.
>


For MFCs we are recommending the first 11. I think this will likely suffice
and matches the git client behavior.

Warner

-Alan
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>

From jbeich at FreeBSD.org  Thu Dec 24 01:22:15 2020
From: jbeich at FreeBSD.org (Jan Beich)
Date: Thu, 24 Dec 2020 02:22:11 +0100
Subject: referencing one commit in another for git
In-Reply-To: <CANCZdfp0WDqM_f01JZgScyeDh_tBgYSrWSzk4ruQb526B9y2vw@mail.gmail.com>
 (Warner Losh's message of "Wed, 23 Dec 2020 16:01:59 -0700")
References: <YQXPR0101MB0968535A875FF1D2C32352E8DDDE0@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
 <CAOtMX2gsYVeN1NZVjtGX7EDNFnL2qKV+g3GtSS-YFyn1A6_wLg@mail.gmail.com>
 <CANCZdfp0WDqM_f01JZgScyeDh_tBgYSrWSzk4ruQb526B9y2vw@mail.gmail.com>
Message-ID: <k0t8-q9q4-wny@FreeBSD.org>

Warner Losh <imp at bsdimp.com> writes:

> On Wed, Dec 23, 2020, 3:21 PM Alan Somers <asomers at freebsd.org> wrote:
>
>> On Wed, Dec 23, 2020 at 3:16 PM Rick Macklem <rmacklem at uoguelph.ca> wrote:
>>
>> > Hi,
>> >
>> > So I just did my first git commit. Pretty scary, but it looks ok.
>> >
>> > Now, how do I reference one commit in another related
>> > commit's log?
>> >
>> > By the long winded hash or ??
>> >
>> > I'm not sure if I should ask here or on the git mailing list,
>> > but I figured this isn't a technical git question...
>> >
>> > Thanks for any help with this, rick
>> >
>>
>> Yeah, you should use the full hash.  For temporary references, like during
>> a code review, you can use the first "several" digits of the hash.   For a
>> project of FreeBSD's size, "several" is probably 11-13.  But in permanent
>> contexts, like commit logs, you should use the full hash.  When somebody
>> views the commit on a platform like Github, Github will automatically turn
>> it into a hyperlink, and display only the first "several" digits.
>>
>
>
> For MFCs we are recommending the first 11. I think this will likely suffice
> and matches the git client behavior.

Mercurial defaults to 12 digit abbreviation. Git abbreviates linux,
freebsd-legacy, freebsd-ports repos on GitHub to 12 digit.

From imp at bsdimp.com  Thu Dec 24 04:06:33 2020
From: imp at bsdimp.com (Warner Losh)
Date: Wed, 23 Dec 2020 21:06:19 -0700
Subject: referencing one commit in another for git
In-Reply-To: <k0t8-q9q4-wny@FreeBSD.org>
References: <YQXPR0101MB0968535A875FF1D2C32352E8DDDE0@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
 <CAOtMX2gsYVeN1NZVjtGX7EDNFnL2qKV+g3GtSS-YFyn1A6_wLg@mail.gmail.com>
 <CANCZdfp0WDqM_f01JZgScyeDh_tBgYSrWSzk4ruQb526B9y2vw@mail.gmail.com>
 <k0t8-q9q4-wny@FreeBSD.org>
Message-ID: <CANCZdfq4PLMPku0g11gK5O9KJi+wqu6M3SJixCcDh3hLo_KkLA@mail.gmail.com>

On Wed, Dec 23, 2020 at 6:22 PM Jan Beich <jbeich at freebsd.org> wrote:

> Warner Losh <imp at bsdimp.com> writes:
>
> > On Wed, Dec 23, 2020, 3:21 PM Alan Somers <asomers at freebsd.org> wrote:
> >
> >> On Wed, Dec 23, 2020 at 3:16 PM Rick Macklem <rmacklem at uoguelph.ca>
> wrote:
> >>
> >> > Hi,
> >> >
> >> > So I just did my first git commit. Pretty scary, but it looks ok.
> >> >
> >> > Now, how do I reference one commit in another related
> >> > commit's log?
> >> >
> >> > By the long winded hash or ??
> >> >
> >> > I'm not sure if I should ask here or on the git mailing list,
> >> > but I figured this isn't a technical git question...
> >> >
> >> > Thanks for any help with this, rick
> >> >
> >>
> >> Yeah, you should use the full hash.  For temporary references, like
> during
> >> a code review, you can use the first "several" digits of the hash.
>  For a
> >> project of FreeBSD's size, "several" is probably 11-13.  But in
> permanent
> >> contexts, like commit logs, you should use the full hash.  When somebody
> >> views the commit on a platform like Github, Github will automatically
> turn
> >> it into a hyperlink, and display only the first "several" digits.
> >>
> >
> >
> > For MFCs we are recommending the first 11. I think this will likely
> suffice
> > and matches the git client behavior.
>
> Mercurial defaults to 12 digit abbreviation. Git abbreviates linux,
> freebsd-legacy, freebsd-ports repos on GitHub to 12 digit.
>

I've updated to 12. That sounds like a good number of digits...Thanks.

Warner

From grarpamp at gmail.com  Thu Dec 24 07:51:04 2020
From: grarpamp at gmail.com (grarpamp)
Date: Thu, 24 Dec 2020 02:51:00 -0500
Subject: FreeBSD: GitLab
In-Reply-To: <CANCZdfr-gYYd5updHq2jG4nOqkOmPdKeYd1H98AmTKo0R35ong@mail.gmail.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <20201222183900.GA22353@www.zefox.net>
 <81C07616-434E-4DF4-91AC-518AECF4F16F@gromit.dlib.vt.edu>
 <01b07b90-e206-aa56-aa5b-91c764ef36a4@gmail.com>
 <CANCZdfpJC4jA0ZUfP90FkeY-EWpLJo+ZcRctV6GUKt=tyUG2kA@mail.gmail.com>
 <f52741305ad7d4eb3643c99320fa5b92@bsdforge.com>
 <7b82f25b-9f0a-32c1-0f05-3a92474051b4@gmail.com>
 <83c34f774c1f8a3c164086883882ba7f@bsdforge.com>
 <CANCZdfr-gYYd5updHq2jG4nOqkOmPdKeYd1H98AmTKo0R35ong@mail.gmail.com>
Message-ID: <CAD2Ti2_R-dSUJ431d1mawM45u67cMxy=hbEgiEuo0vZr68xJsw@mail.gmail.com>

>> I mainly asked because GitLab seems to offer a richer toolset IMHO.
>
> The project is publishing many places, and will use features of the places
> it publishes as it refines the future workflow. The different
> mirroring/hosting services offer different features and it's not yet clear
> how we can best utilize them or if even one size fits all.

As with the move to git, readonly mirrors is fine thing.
Yet more general attempt to open up bug work issue trackers flow
read-write services etc for some things beyond say central freebsd.org,
can massively raise overhead, needlessly partition knowledge
base, raise peoples search and participation time by 2^n,
complexity alienate new dev and user influx, be harder for
donors to big picture, etc...

'A: hey here's my bug report on site H'
'L: H redundant, already filed over on service X'
'Z: but we're working it on J, see the mail list at U'
'W: well J blocks devs using tor with cloudflare so we can't read or
contribute there'
'X: did you see telegram message G you can add it to site R's wiki'
'Q: nope not bothering to set up yet another account for that'
'I: ddg search gave results to U, but V which was not indexed that I
found on F had my answer'
'E: i clicked your link but N already 404 expired sold out or shutdown'
'N: <crickets>, sorry for your loss'
'M: but the forum C said github clone A was it'
'O: they wanted my phone picture id and utility bill for an account, fuck that'
'B: i tried to integrate sites G and Y in my scripts to do miracle T
but they kept changing API's and it required plugins which were were
broken in pkg all month.'

Also consider before canonizing/depending elements to
third party services, especially ones without good export for
backup, mirror, and local use... people think corp services
will last forever, history shows they don't.

From marc at bumblingdork.com  Thu Dec 24 09:34:54 2020
From: marc at bumblingdork.com (Marc Veldman)
Date: Thu, 24 Dec 2020 10:34:49 +0100
Subject: Boot panic on Lenovo P50s since r367998
Message-ID: <89112D93-739D-45B5-B21A-3396C098A89B@bumblingdork.com>

Hello,

since r367998 my Lenovo P50s panics on boot:

mmc0: detached
panic: Bad link elm 0xfffff80003a73300 next->prep != elm
cupid=3
time=2
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff8299a9c0
vpanic() at vpanic+0x181/frame 0xffffffff8299aa10
panic() at panic+0x43/frame 0xffffffff8299aa70
config_intrhook_disestablish() at config_intrhook_disestablish+0xf3/frame 0xffffffff8299aa90
config_intrhook_oneshot_func() at config_intrhook_oneshot_func+0x18/frame 0xffffffff8299aab0
run_interrupt_driven_config_hooks() at run_interrupt_driven_config_hooks+0x77/frame 0xffffffff8299aad0
boot_run_interrupt_driven_config_hooks() at boot_run_interrupt_driven_config_hooks+0x1f/frame 0xffffffff8299ab60
mi_startup() at mi_startup+0xec/frame 0xffffffff8299abb0
btext() at btext+0x2c
KDB: enter: panic
[thread pid 0 tid 100000]
Stopped at     kdb_enter+0x37: movq     $0,0x10ada46(%rip)

If needed, I can test patches

Dmesg (with r367977 kernel)

---<<BOOT>>---
Copyright (c) 1992-2020 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 13.0-CURRENT #0 r367997: Tue Dec 22 16:47:30 CET 2020
    root at devnovo:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
FreeBSD clang version 11.0.0 (git at github.com:llvm/llvm-project.git llvmorg-11.0.0-0-g176249bd673)
WARNING: WITNESS option enabled, expect reduced performance.
VT(efifb): resolution 1920x1080
CPU: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz (2592.10-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x406e3  Family=0x6  Model=0x4e  Stepping=3
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x7ffafbbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
  AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
  AMD Features2=0x121<LAHF,ABM,Prefetch>
  Structured Extended Features=0x29c67af<FSGSBASE,TSCADJ,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,NFPUSG,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PROCTRACE>
  Structured Extended Features3=0x9c000000<IBPB,STIBP,L1DFL,SSBD>
  XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 17179869184 (16384 MB)
avail memory = 16421109760 (15660 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: <LENOVO TP-N1K  >
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
random: unblocking device.
ioapic0 <Version 2.0> irqs 0-119
Launching APs: 1 3 2
Timecounter "TSC-low" frequency 1296050980 Hz quality 1000
random: entropy device external interface
WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0.
kbd1 at kbdmux0
000.000045 [4346] netmap_init               netmap: loaded module
[ath_hal] loaded
nexus0
efirtc0: <EFI Realtime Clock>
efirtc0: registered as a time-of-day clock, resolution 1.000000s
cryptosoft0: <software crypto>
aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS>
acpi0: <LENOVO TP-N1K>
acpi_ec0: <Embedded Controller: GPE 0x16, ECDT> port 0x62,0x66 on acpi0
acpi0: Power Button (fixed)
cpu0: <ACPI CPU> on acpi0
attimer0: <AT timer> port 0x40-0x43 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
Timecounter "HPET" frequency 24000000 Hz quality 950
Event timer "HPET" frequency 24000000 Hz quality 550
Event timer "HPET1" frequency 24000000 Hz quality 440
Event timer "HPET2" frequency 24000000 Hz quality 440
Event timer "HPET3" frequency 24000000 Hz quality 440
Event timer "HPET4" frequency 24000000 Hz quality 440
atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
atrtc0: registered as a time-of-day clock, resolution 1.000000s
Event timer "RTC" frequency 32768 Hz quality 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0
acpi_lid0: <Control Method Lid Switch> on acpi0
acpi_button0: <Sleep Button> on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
vgapci0: <VGA-compatible display> port 0xe000-0xe03f mem 0xf2000000-0xf2ffffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0
vgapci0: Boot video device
xhci0: <Intel Sunrise Point-LP USB 3.0 controller> mem 0xf4220000-0xf422ffff at device 20.0 on pci0
xhci0: 32 bytes context size, 64-bit DMA
usbus0 on xhci0
usbus0: 5.0Gbps Super Speed USB v3.0
pci0: <simple comms> at device 22.0 (no driver attached)
ahci0: <Intel Sunrise Point-LP AHCI SATA controller> port 0xe080-0xe087,0xe088-0xe08b,0xe060-0xe07f mem 0xf4248000-0xf4249fff,0xf424f000-0xf424f0ff,0xf424d000-0xf424d7ff at device 23.0 on pci0
ahci0: AHCI v1.31 with 1 6Gbps ports, Port Multiplier not supported
ahcich1: <AHCI channel> at channel 1 on ahci0
pcib1: <ACPI PCI-PCI bridge> at device 28.0 on pci0
pci1: <ACPI PCI bus> on pcib1
pci1: <unknown> at device 0.0 (no driver attached)
pcib2: <ACPI PCI-PCI bridge> at device 28.2 on pci0
pci2: <ACPI PCI bus> on pcib2
pci2: <network> at device 0.0 (no driver attached)
pcib3: <ACPI PCI-PCI bridge> at device 29.0 on pci0
pci3: <ACPI PCI bus> on pcib3
vgapci1: <VGA-compatible display> port 0xd000-0xd07f mem 0xf3000000-0xf3ffffff,0xe0000000-0xefffffff,0xf0000000-0xf1ffffff at device 0.0 on pci3
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
pci0: <memory> at device 31.2 (no driver attached)
hdac0: <Intel Sunrise Point-LP HDA Controller> mem 0xf4240000-0xf4243fff,0xf4230000-0xf423ffff at device 31.3 on pci0
em0: <Intel(R) PRO/1000 Network Connection> mem 0xf4200000-0xf421ffff at device 31.6 on pci0
em0: Using 1024 TX descriptors and 1024 RX descriptors
em0: Using an MSI interrupt
em0: Ethernet address: 54:ee:75:cb:0d:e3
em0: netmap queues/slots: TX 1/1024, RX 1/1024
acpi_tz0: <Thermal Zone> on acpi0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD 13.0.
psm0: model Synaptics Touchpad, device ID 0
battery0: <ACPI Control Method Battery> on acpi0
battery1: <ACPI Control Method Battery> on acpi0
acpi_acad0: <AC Adapter> on acpi0
orm0: <ISA Option ROM> at iomem 0xc0000-0xcffff pnpid ORM0000 on isa0
hwpstate_intel0: <Intel Speed Shift> on cpu0
hwpstate_intel1: <Intel Speed Shift> on cpu1
hwpstate_intel2: <Intel Speed Shift> on cpu2
hwpstate_intel3: <Intel Speed Shift> on cpu3
Timecounters tick every 1.000 msec
ZFS filesystem version: 5
ZFS storage pool version: features support (5000)
hdacc0: <Realtek ALC293 HDA CODEC> at cad 0 on hdac0
ugen0.1: <0x8086 XHCI root HUB> at usbus0
hdaa0: <Realtek ALC293 Audio Function Group> at nid 1 on hdacc0
pcm0: <Realtek ALC293 (Analog)> at nid 20 and 26 on hdaa0
pcm1: <Realtek ALC293 (Analog)> at nid 21 and 18 on hdaa0
hdacc1: <Intel Skylake HDA CODEC> at cad 2 on hdac0
hdaa1: <Intel Skylake Audio Function Group> at nid 1 on hdacc1
pcm2: <Intel Skylake (HDMI/DP 8ch)> at nid 3 on hdaa1
Trying to mount root from zfs:zroot/ROOT/default []...
Root mount waiting for: usbus0 CAM
WARNING: WITNESS option enabled, expect reduced performance.
uhub0 on usbus0
uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
ada0 at ahcich1 bus 0 scbus0 target 0 lun 0
ada0: <Samsung SSD 850 PRO 512GB EXM04B6Q> ACS-2 ATA SATA 3.x device
ada0: Serial Number S39FNX0J625463T
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)
ada0: Command Queueing enabled
ada0: 488386MB (1000215216 512 byte sectors)
ada0: quirks=0x3<4K,NCQ_TRIM_BROKEN>
GEOM_ELI: Device ada0p4.eli created.
GEOM_ELI: Encryption: AES-XTS 256
GEOM_ELI:     Crypto: accelerated software
uhub0: 18 ports with 18 removable, self powered
Root mount waiting for: usbus0
ugen0.2: <Prolific Technology Inc. USB-Serial Controller> at usbus0
Root mount waiting for: usbus0
ugen0.3: <vendor 0x8087 product 0x0a2b> at usbus0
ugen0.4: <SunplusIT Inc Integrated Camera> at usbus0
Root mount waiting for: usbus0
ugen0.5: <vendor 0x138a product 0x0017> at usbus0
lo0: link state changed to UP
pchtherm0: <Skylake PCH Thermal Subsystem> mem 0xf424b000-0xf424bfff at device 20.2 on pci0
iwm0: <Intel(R) Dual Band Wireless AC 8260> mem 0xf4000000-0xf4001fff at device 0.0 on pci2
iwm0: hw rev 0x200, fw ver 22.361476.0, address f4:8c:50:50:22:83
ichsmb0: <Intel Sunrise Point-LP SMBus controller> port 0xefa0-0xefbf mem 0xf424e000-0xf424e0ff at device 31.4 on pci0
smbus0: <System Management Bus> on ichsmb0
acpi_wmi0: <ACPI-WMI mapping> on acpi0
acpi_wmi0: Embedded MOF found
ACPI: \134_SB.WMI1.WQBA: 1 arguments were passed to a non-method ACPI object (Buffer) (20201113/nsarguments-361)
acpi_wmi1: <ACPI-WMI mapping> on acpi0
acpi_wmi1: Embedded MOF found
ACPI: \134_SB.WMI2.WQBB: 1 arguments were passed to a non-method ACPI object (Buffer) (20201113/nsarguments-361)
acpi_wmi2: <ACPI-WMI mapping> on acpi0
acpi_wmi2: Embedded MOF found
ACPI: \134_SB.WMI3.WQBC: 1 arguments were passed to a non-method ACPI object (Buffer) (20201113/nsarguments-361)
uplcom0 on uhub0
uplcom0: <Prolific Technology Inc. USB-Serial Controller, class 0/0, rev 1.10/3.00, addr 1> on usbus0
wlan0: Ethernet address: f4:8c:50:50:22:83
ng_ubt: HCI command 0xfc05 timed out
ubt0 on uhub0
ubt0: <vendor 0x8087 product 0x0a2b, class 224/1, rev 2.00/0.01, addr 2> on usbus0
wlan0: link state changed to UP
WARNING: attempt to domain_add(bluetooth) after domainfinalize()
WARNING: attempt to domain_add(netgraph) after domainfinalize()
iwm0: code ce, frame 2/216 b800002c unhandled
Security policy loaded: MAC/ntpd (mac_ntpd)


From trashcan at ellael.org  Thu Dec 24 14:11:25 2020
From: trashcan at ellael.org (Michael Grimm)
Date: Thu, 24 Dec 2020 15:11:15 +0100
Subject: git and the loss of revision numbers
Message-ID: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>

Hi

Disclaimer: I just started to learn git, never used it before.

If I do understand it correctly, the switch from svn to git comes with a loss of continuously increasing revision numbers. Correct? If so I wonder how future security advisories and errata notices will be composed. Will there be a date of the commit besides its hash being reported? 

In the past I could easily judge if there was a need to buildworld or buildkernel: If uname shows a larger revision number than those in advisories or notices.

Question: How may one find out whether to recompile or not in the future?

Thanks and regards,
Michael


From trashcan at ellael.org  Thu Dec 24 14:15:09 2020
From: trashcan at ellael.org (Michael Grimm)
Date: Thu, 24 Dec 2020 15:15:07 +0100
Subject: git and the loss of revision numbers
In-Reply-To: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
Message-ID: <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org>

Correction:

> On 24. Dec 2020, at 15:11, Michael Grimm <trashcan at ellael.org> wrote:
> 
> In the past I could easily judge if there was a need to buildworld or buildkernel: If uname shows a larger revision number than those in advisories or notices.

In the past I could easily judge if there was a need to buildworld or buildkernel: If uname shows a smaller revision number than those in advisories or notices.

Michael

From grarpamp at gmail.com  Thu Dec 24 15:28:10 2020
From: grarpamp at gmail.com (grarpamp)
Date: Thu, 24 Dec 2020 10:28:06 -0500
Subject: git and the loss of revision numbers
In-Reply-To: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
Message-ID: <CAD2Ti28WcausXAtnxAcCpkfz8qqNLoQn_RLWDkiYBZMFTU8BHA@mail.gmail.com>

> loss of continuously increasing revision numbers

git rev-list --count HEAD
git describe --tags / parent

Plus a bunch of similar ways to do it,
from different points, in different formats,
search internet for them all... git revision version numbering...

Some deploy structured metadata in tag schemes,
use hooks, files, etc but gets messy and is not just a
simple proper read-only query.

> date of the commit besides its hash being reported
> whether to recompile

Recompilation means users have the source cloned.
Source means users can use ways like
git log <hash>
git show
etc
Which means users have date, and a <hash> in
log subsequent to their last compiled hash etc.
So it's not a problem beyond a few trivial steps
or shell parsing function to query and compare on
whatever particular metadata a person may like,
to what they already know they have.
The handbook will have docs on some ways.

From grahamperrin at gmail.com  Thu Dec 24 15:41:15 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Thu, 24 Dec 2020 15:41:11 +0000
Subject: Git commits/revisions: sequential numbering: git-rev-list(1) --count
In-Reply-To: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
Message-ID: <f3bd0a8b-6e05-2b01-a673-9e62f32996bd@gmail.com>

On 24/12/2020 14:11, Michael Grimm wrote:

> ? Disclaimer: I just started to learn git, never used it before.
>
> If I do understand it correctly, the switch from svn to git comes with a loss of continuously increasing revision numbers. Correct? ?


Yes and no.

<https://old.reddit.com/comments/keme3b/-/ggs61in/?context=1> there's an 
example command that shows a FreeBSD-CURRENT Git revision number of 11 
following an update.

The phrase 'revision number' might be not technically accurate, but the 
numbers _are_ sequential.

The command uses the '--count' option of
git-rev-list(1) 
<https://www.freebsd.org/cgi/man.cgi?query=git-rev-list&sektion=1&manpath=FreeBSD+12.2-RELEASE+and+Ports>

Re: uname(1), I'll respond to your second e-mail.

Kind regards
Graham


From grahamperrin at gmail.com  Thu Dec 24 15:53:40 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Thu, 24 Dec 2020 15:53:35 +0000
Subject: Git and uname(1)
In-Reply-To: <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org>
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
 <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org>
Message-ID: <becd82de-2722-1ff7-b287-e625da83ee39@gmail.com>

On 24/12/2020 14:15, Michael Grimm wrote:

> ? In the past I could easily judge if there was a need to buildworld or buildkernel: If uname shows a smaller revision number than those in advisories or notices. ?


I see Rainer Hurling's response to John Kennedy at 
<https://lists.freebsd.org/pipermail/freebsd-current/2020-December/thread.html#77941> 


I have yet to see things for myself, to ease my mind and get the big 
picture :-)


From naddy at mips.inka.de  Thu Dec 24 16:25:12 2020
From: naddy at mips.inka.de (Christian Weisgerber)
Date: Thu, 24 Dec 2020 17:20:42 +0100
Subject: git and the loss of revision numbers
In-Reply-To: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
Message-ID: <X+S/2j1483wb+MgB@lorvorc.mips.inka.de>

Michael Grimm:

> If I do understand it correctly, the switch from svn to git comes with a loss of continuously increasing revision numbers.

Correct.

> Correct? If so I wonder how future security advisories and errata notices will be composed. Will there be a date of the commit besides its hash being reported? 

For over TWENTY YEARS, FreeBSD advisories have already contained
the date when the problem was corrected, e.g.:

  Topic:          Several vulnerabilities in procfs [REVISED]
  Category:       core
  Module:         procfs
  Announced:      2000-12-18
  Reissued:       2000-12-29
  Affects:        FreeBSD 4.x and 3.x prior to the correction date.
  Corrected:      2000-12-16 (FreeBSD 4.2-STABLE)
                  2000-12-18 (FreeBSD 3.5.1-STABLE)

I think it is safe to assume that this practice will continue after
the switch to Git.

-- 
Christian "naddy" Weisgerber                          naddy at mips.inka.de

From yuripv at yuripv.dev  Thu Dec 24 21:52:33 2020
From: yuripv at yuripv.dev (Yuri Pankov)
Date: Fri, 25 Dec 2020 00:52:28 +0300
Subject: referencing one commit in another for git
In-Reply-To: <CANCZdfq4PLMPku0g11gK5O9KJi+wqu6M3SJixCcDh3hLo_KkLA@mail.gmail.com>
References: <YQXPR0101MB0968535A875FF1D2C32352E8DDDE0@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
 <CAOtMX2gsYVeN1NZVjtGX7EDNFnL2qKV+g3GtSS-YFyn1A6_wLg@mail.gmail.com>
 <CANCZdfp0WDqM_f01JZgScyeDh_tBgYSrWSzk4ruQb526B9y2vw@mail.gmail.com>
 <k0t8-q9q4-wny@FreeBSD.org>
 <CANCZdfq4PLMPku0g11gK5O9KJi+wqu6M3SJixCcDh3hLo_KkLA@mail.gmail.com>
Message-ID: <fa0e46ab-dc85-b975-3d33-3581049afb4b@yuripv.dev>

Warner Losh wrote:
> On Wed, Dec 23, 2020 at 6:22 PM Jan Beich <jbeich at freebsd.org> wrote:
> 
>> Warner Losh <imp at bsdimp.com> writes:
>>
>>> On Wed, Dec 23, 2020, 3:21 PM Alan Somers <asomers at freebsd.org> wrote:
>>>
>>>> On Wed, Dec 23, 2020 at 3:16 PM Rick Macklem <rmacklem at uoguelph.ca>
>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> So I just did my first git commit. Pretty scary, but it looks ok.
>>>>>
>>>>> Now, how do I reference one commit in another related
>>>>> commit's log?
>>>>>
>>>>> By the long winded hash or ??
>>>>>
>>>>> I'm not sure if I should ask here or on the git mailing list,
>>>>> but I figured this isn't a technical git question...
>>>>>
>>>>> Thanks for any help with this, rick
>>>>>
>>>>
>>>> Yeah, you should use the full hash.  For temporary references, like
>> during
>>>> a code review, you can use the first "several" digits of the hash.
>>   For a
>>>> project of FreeBSD's size, "several" is probably 11-13.  But in
>> permanent
>>>> contexts, like commit logs, you should use the full hash.  When somebody
>>>> views the commit on a platform like Github, Github will automatically
>> turn
>>>> it into a hyperlink, and display only the first "several" digits.
>>>>
>>>
>>>
>>> For MFCs we are recommending the first 11. I think this will likely
>> suffice
>>> and matches the git client behavior.
>>
>> Mercurial defaults to 12 digit abbreviation. Git abbreviates linux,
>> freebsd-legacy, freebsd-ports repos on GitHub to 12 digit.
>>
> 
> I've updated to 12. That sounds like a good number of digits...Thanks.

I think the common way is to use `git rev-parse --short <fullhash>`, 
though we are likely to recommend increasing the core.abbrev value which 
sets the minimum length of unique prefix (default is 4).

From debdrup at freebsd.org  Thu Dec 24 00:00:02 2020
From: debdrup at freebsd.org (Daniel Ebdrup Jensen)
Date: Thu, 24 Dec 2020 00:00:01 +0000 (UTC)
Subject: [LAST OFFICIAL REMINDER] Call for 2020Q4 quarterly status reports
Message-ID: <20201224000001.2AAD35D8C@freefall.freebsd.org>

Dear FreeBSD Community,

The deadline for the next FreeBSD Quarterly Status update is
December, 31st 2021 for work done since the last round of Quarterly Reports:
October 2020 - December 2020.
I would like to remind you that reports are collected during the last
month of every quarter.

Status report submissions do not need to be very long.  They may be
about anything happening in the FreeBSD project and community, and
they provide a great way to inform FreeBSD users and developers about
work that is underway or has been completed. Report submissions are
not limited to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The preferred method is to follow the guidelines at the Quarterly
GitHub repository:

https://github.com/freebsd/freebsd-quarterly

Alternatively you can fetch the Markdown template, fill it in, and
email it to quarterly-submissions at FreeBSD.org.
The template can be found at:

https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.md

We look forward to seeing your 2020Q4 reports!

Thanks,

Daniel Ebdrup Jensen (on behalf of quarterly@)
_______________________________________________
freebsd-quarterly-calls at freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-quarterly-calls
To unsubscribe, send any mail to "freebsd-quarterly-calls-unsubscribe at freebsd.org"

From yuripv at yuripv.dev  Thu Dec 24 23:04:22 2020
From: yuripv at yuripv.dev (Yuri Pankov)
Date: Fri, 25 Dec 2020 02:04:18 +0300
Subject: Boot panic on Lenovo P50s since r367998
In-Reply-To: <89112D93-739D-45B5-B21A-3396C098A89B@bumblingdork.com>
References: <89112D93-739D-45B5-B21A-3396C098A89B@bumblingdork.com>
Message-ID: <6d42bbaa-7c88-db53-c441-40513c043847@yuripv.dev>

Marc Veldman wrote:
> Hello,
> 
> since r367998 my Lenovo P50s panics on boot:
> 
> mmc0: detached
> panic: Bad link elm 0xfffff80003a73300 next->prep != elm
> cupid=3
> time=2
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff8299a9c0
> vpanic() at vpanic+0x181/frame 0xffffffff8299aa10
> panic() at panic+0x43/frame 0xffffffff8299aa70
> config_intrhook_disestablish() at config_intrhook_disestablish+0xf3/frame 0xffffffff8299aa90
> config_intrhook_oneshot_func() at config_intrhook_oneshot_func+0x18/frame 0xffffffff8299aab0
> run_interrupt_driven_config_hooks() at run_interrupt_driven_config_hooks+0x77/frame 0xffffffff8299aad0
> boot_run_interrupt_driven_config_hooks() at boot_run_interrupt_driven_config_hooks+0x1f/frame 0xffffffff8299ab60
> mi_startup() at mi_startup+0xec/frame 0xffffffff8299abb0
> btext() at btext+0x2c
> KDB: enter: panic
> [thread pid 0 tid 100000]
> Stopped at     kdb_enter+0x37: movq     $0,0x10ada46(%rip)

r367998 adds rtsx driver for card reader, seems to work for me on P51 
(as in "detected and does not panic", I don't have any cards around to 
really test it):

rtsx0 at pci0:63:0:0:	class=0xff0000 rev=0x01 hdr=0x00 vendor=0x10ec 
device=0x525a subvendor=0x17aa subdevice=0x224d
     vendor	= 'Realtek Semiconductor Co., Ltd.'
     device	= 'RTS525A PCI Express Card Reader'

To confirm the issue is indeed in rtsx, does disabling the card reader 
in bios help?  If it does, what is the device exactly (`pciconf -lv` 
when booted on pre-r367998)?

From junchoon at dec.sakura.ne.jp  Fri Dec 25 00:02:35 2020
From: junchoon at dec.sakura.ne.jp (Tomoaki AOKI)
Date: Fri, 25 Dec 2020 09:02:19 +0900
Subject: Boot panic on Lenovo P50s since r367998
In-Reply-To: <89112D93-739D-45B5-B21A-3396C098A89B@bumblingdork.com>
References: <89112D93-739D-45B5-B21A-3396C098A89B@bumblingdork.com>
Message-ID: <20201225090219.d98fa1ce21d600f0da606e29@dec.sakura.ne.jp>

On Thu, 24 Dec 2020 10:34:49 +0100
Marc Veldman <marc at bumblingdork.com> wrote:

> Hello,
> 
> since r367998 my Lenovo P50s panics on boot:
> 
> mmc0: detached
> panic: Bad link elm 0xfffff80003a73300 next->prep != elm
> cupid=3
> time=2
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff8299a9c0
> vpanic() at vpanic+0x181/frame 0xffffffff8299aa10
> panic() at panic+0x43/frame 0xffffffff8299aa70
> config_intrhook_disestablish() at config_intrhook_disestablish+0xf3/frame 0xffffffff8299aa90
> config_intrhook_oneshot_func() at config_intrhook_oneshot_func+0x18/frame 0xffffffff8299aab0
> run_interrupt_driven_config_hooks() at run_interrupt_driven_config_hooks+0x77/frame 0xffffffff8299aad0
> boot_run_interrupt_driven_config_hooks() at boot_run_interrupt_driven_config_hooks+0x1f/frame 0xffffffff8299ab60
> mi_startup() at mi_startup+0xec/frame 0xffffffff8299abb0
> btext() at btext+0x2c
> KDB: enter: panic
> [thread pid 0 tid 100000]
> Stopped at     kdb_enter+0x37: movq     $0,0x10ada46(%rip)
> 
> If needed, I can test patches
> 
> Dmesg (with r367977 kernel)
> 
> ---<<BOOT>>---
> Copyright (c) 1992-2020 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> 	The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 13.0-CURRENT #0 r367997: Tue Dec 22 16:47:30 CET 2020
>     root at devnovo:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
> FreeBSD clang version 11.0.0 (git at github.com:llvm/llvm-project.git llvmorg-11.0.0-0-g176249bd673)
> WARNING: WITNESS option enabled, expect reduced performance.
> VT(efifb): resolution 1920x1080
> CPU: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz (2592.10-MHz K8-class CPU)
>   Origin="GenuineIntel"  Id=0x406e3  Family=0x6  Model=0x4e  Stepping=3
>   Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>   Features2=0x7ffafbbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
>   AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
>   AMD Features2=0x121<LAHF,ABM,Prefetch>
>   Structured Extended Features=0x29c67af<FSGSBASE,TSCADJ,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,NFPUSG,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PROCTRACE>
>   Structured Extended Features3=0x9c000000<IBPB,STIBP,L1DFL,SSBD>
>   XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
>   VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>   TSC: P-state invariant, performance statistics
> real memory  = 17179869184 (16384 MB)
> avail memory = 16421109760 (15660 MB)
> Event timer "LAPIC" quality 600
> ACPI APIC Table: <LENOVO TP-N1K  >
> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
> FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads
> random: registering fast source Intel Secure Key RNG
> random: fast provider: "Intel Secure Key RNG"
> random: unblocking device.
> ioapic0 <Version 2.0> irqs 0-119
> Launching APs: 1 3 2
> Timecounter "TSC-low" frequency 1296050980 Hz quality 1000
> random: entropy device external interface
> WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0.
> kbd1 at kbdmux0
> 000.000045 [4346] netmap_init               netmap: loaded module
> [ath_hal] loaded
> nexus0
> efirtc0: <EFI Realtime Clock>
> efirtc0: registered as a time-of-day clock, resolution 1.000000s
> cryptosoft0: <software crypto>
> aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS>
> acpi0: <LENOVO TP-N1K>
> acpi_ec0: <Embedded Controller: GPE 0x16, ECDT> port 0x62,0x66 on acpi0
> acpi0: Power Button (fixed)
> cpu0: <ACPI CPU> on acpi0
> attimer0: <AT timer> port 0x40-0x43 irq 0 on acpi0
> Timecounter "i8254" frequency 1193182 Hz quality 0
> Event timer "i8254" frequency 1193182 Hz quality 100
> hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
> Timecounter "HPET" frequency 24000000 Hz quality 950
> Event timer "HPET" frequency 24000000 Hz quality 550
> Event timer "HPET1" frequency 24000000 Hz quality 440
> Event timer "HPET2" frequency 24000000 Hz quality 440
> Event timer "HPET3" frequency 24000000 Hz quality 440
> Event timer "HPET4" frequency 24000000 Hz quality 440
> atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
> atrtc0: registered as a time-of-day clock, resolution 1.000000s
> Event timer "RTC" frequency 32768 Hz quality 0
> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0
> acpi_lid0: <Control Method Lid Switch> on acpi0
> acpi_button0: <Sleep Button> on acpi0
> pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
> pci0: <ACPI PCI bus> on pcib0
> vgapci0: <VGA-compatible display> port 0xe000-0xe03f mem 0xf2000000-0xf2ffffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0
> vgapci0: Boot video device
> xhci0: <Intel Sunrise Point-LP USB 3.0 controller> mem 0xf4220000-0xf422ffff at device 20.0 on pci0
> xhci0: 32 bytes context size, 64-bit DMA
> usbus0 on xhci0
> usbus0: 5.0Gbps Super Speed USB v3.0
> pci0: <simple comms> at device 22.0 (no driver attached)
> ahci0: <Intel Sunrise Point-LP AHCI SATA controller> port 0xe080-0xe087,0xe088-0xe08b,0xe060-0xe07f mem 0xf4248000-0xf4249fff,0xf424f000-0xf424f0ff,0xf424d000-0xf424d7ff at device 23.0 on pci0
> ahci0: AHCI v1.31 with 1 6Gbps ports, Port Multiplier not supported
> ahcich1: <AHCI channel> at channel 1 on ahci0
> pcib1: <ACPI PCI-PCI bridge> at device 28.0 on pci0
> pci1: <ACPI PCI bus> on pcib1
> pci1: <unknown> at device 0.0 (no driver attached)
> pcib2: <ACPI PCI-PCI bridge> at device 28.2 on pci0
> pci2: <ACPI PCI bus> on pcib2
> pci2: <network> at device 0.0 (no driver attached)
> pcib3: <ACPI PCI-PCI bridge> at device 29.0 on pci0
> pci3: <ACPI PCI bus> on pcib3
> vgapci1: <VGA-compatible display> port 0xd000-0xd07f mem 0xf3000000-0xf3ffffff,0xe0000000-0xefffffff,0xf0000000-0xf1ffffff at device 0.0 on pci3
> isab0: <PCI-ISA bridge> at device 31.0 on pci0
> isa0: <ISA bus> on isab0
> pci0: <memory> at device 31.2 (no driver attached)
> hdac0: <Intel Sunrise Point-LP HDA Controller> mem 0xf4240000-0xf4243fff,0xf4230000-0xf423ffff at device 31.3 on pci0
> em0: <Intel(R) PRO/1000 Network Connection> mem 0xf4200000-0xf421ffff at device 31.6 on pci0
> em0: Using 1024 TX descriptors and 1024 RX descriptors
> em0: Using an MSI interrupt
> em0: Ethernet address: 54:ee:75:cb:0d:e3
> em0: netmap queues/slots: TX 1/1024, RX 1/1024
> acpi_tz0: <Thermal Zone> on acpi0
> atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
> atkbd0: <AT Keyboard> irq 1 on atkbdc0
> kbd0 at atkbd0
> atkbd0: [GIANT-LOCKED]
> psm0: <PS/2 Mouse> irq 12 on atkbdc0
> psm0: [GIANT-LOCKED]
> WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD 13.0.
> psm0: model Synaptics Touchpad, device ID 0
> battery0: <ACPI Control Method Battery> on acpi0
> battery1: <ACPI Control Method Battery> on acpi0
> acpi_acad0: <AC Adapter> on acpi0
> orm0: <ISA Option ROM> at iomem 0xc0000-0xcffff pnpid ORM0000 on isa0
> hwpstate_intel0: <Intel Speed Shift> on cpu0
> hwpstate_intel1: <Intel Speed Shift> on cpu1
> hwpstate_intel2: <Intel Speed Shift> on cpu2
> hwpstate_intel3: <Intel Speed Shift> on cpu3
> Timecounters tick every 1.000 msec
> ZFS filesystem version: 5
> ZFS storage pool version: features support (5000)
> hdacc0: <Realtek ALC293 HDA CODEC> at cad 0 on hdac0
> ugen0.1: <0x8086 XHCI root HUB> at usbus0
> hdaa0: <Realtek ALC293 Audio Function Group> at nid 1 on hdacc0
> pcm0: <Realtek ALC293 (Analog)> at nid 20 and 26 on hdaa0
> pcm1: <Realtek ALC293 (Analog)> at nid 21 and 18 on hdaa0
> hdacc1: <Intel Skylake HDA CODEC> at cad 2 on hdac0
> hdaa1: <Intel Skylake Audio Function Group> at nid 1 on hdacc1
> pcm2: <Intel Skylake (HDMI/DP 8ch)> at nid 3 on hdaa1
> Trying to mount root from zfs:zroot/ROOT/default []...
> Root mount waiting for: usbus0 CAM
> WARNING: WITNESS option enabled, expect reduced performance.
> uhub0 on usbus0
> uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
> ada0 at ahcich1 bus 0 scbus0 target 0 lun 0
> ada0: <Samsung SSD 850 PRO 512GB EXM04B6Q> ACS-2 ATA SATA 3.x device
> ada0: Serial Number S39FNX0J625463T
> ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)
> ada0: Command Queueing enabled
> ada0: 488386MB (1000215216 512 byte sectors)
> ada0: quirks=0x3<4K,NCQ_TRIM_BROKEN>
> GEOM_ELI: Device ada0p4.eli created.
> GEOM_ELI: Encryption: AES-XTS 256
> GEOM_ELI:     Crypto: accelerated software
> uhub0: 18 ports with 18 removable, self powered
> Root mount waiting for: usbus0
> ugen0.2: <Prolific Technology Inc. USB-Serial Controller> at usbus0
> Root mount waiting for: usbus0
> ugen0.3: <vendor 0x8087 product 0x0a2b> at usbus0
> ugen0.4: <SunplusIT Inc Integrated Camera> at usbus0
> Root mount waiting for: usbus0
> ugen0.5: <vendor 0x138a product 0x0017> at usbus0
> lo0: link state changed to UP
> pchtherm0: <Skylake PCH Thermal Subsystem> mem 0xf424b000-0xf424bfff at device 20.2 on pci0
> iwm0: <Intel(R) Dual Band Wireless AC 8260> mem 0xf4000000-0xf4001fff at device 0.0 on pci2
> iwm0: hw rev 0x200, fw ver 22.361476.0, address f4:8c:50:50:22:83
> ichsmb0: <Intel Sunrise Point-LP SMBus controller> port 0xefa0-0xefbf mem 0xf424e000-0xf424e0ff at device 31.4 on pci0
> smbus0: <System Management Bus> on ichsmb0
> acpi_wmi0: <ACPI-WMI mapping> on acpi0
> acpi_wmi0: Embedded MOF found
> ACPI: \134_SB.WMI1.WQBA: 1 arguments were passed to a non-method ACPI object (Buffer) (20201113/nsarguments-361)
> acpi_wmi1: <ACPI-WMI mapping> on acpi0
> acpi_wmi1: Embedded MOF found
> ACPI: \134_SB.WMI2.WQBB: 1 arguments were passed to a non-method ACPI object (Buffer) (20201113/nsarguments-361)
> acpi_wmi2: <ACPI-WMI mapping> on acpi0
> acpi_wmi2: Embedded MOF found
> ACPI: \134_SB.WMI3.WQBC: 1 arguments were passed to a non-method ACPI object (Buffer) (20201113/nsarguments-361)
> uplcom0 on uhub0
> uplcom0: <Prolific Technology Inc. USB-Serial Controller, class 0/0, rev 1.10/3.00, addr 1> on usbus0
> wlan0: Ethernet address: f4:8c:50:50:22:83
> ng_ubt: HCI command 0xfc05 timed out
> ubt0 on uhub0
> ubt0: <vendor 0x8087 product 0x0a2b, class 224/1, rev 2.00/0.01, addr 2> on usbus0
> wlan0: link state changed to UP
> WARNING: attempt to domain_add(bluetooth) after domainfinalize()
> WARNING: attempt to domain_add(netgraph) after domainfinalize()
> iwm0: code ce, frame 2/216 b800002c unhandled
> Security policy loaded: MAC/ntpd (mac_ntpd)
> 
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"

Hi.
You would be bitten by a known issue with ThinkPad P50s described in
rtsx (4) man page.

Try adding dev.rtsx.0.inversion=1 in /boot/loader.conf.

Unfortunately, man pages for head cannot read via FreeBSD project top
page. So read raw manpage data with svn commit mail archive below.

 https://lists.freebsd.org/pipermail/svn-src-head/2020-November/141972.html

In addition, write attempts to write-protected card causes 100% panic.
For example, sysutils/automount trys fsck on mount.
This causes 100% panic (not only rtsx, but every adapters), avoidable
by write-protect off.


-- 
Tomoaki AOKI    <junchoon at dec.sakura.ne.jp>

From mueller6722 at twc.com  Fri Dec 25 00:22:24 2020
From: mueller6722 at twc.com (Thomas Mueller)
Date: Fri, 25 Dec 2020 00:22:24 -0000
Subject: git and the loss of revision numbers
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
Message-ID: <mailman.7.1608855745.98902.freebsd-current@freebsd.org>

> Disclaimer: I just started to learn git, never used it before.

> If I do understand it correctly, the switch from svn to git comes with a loss of continuously increasing revision numbers. Correct? If so I wonder how future security advisories and errata notices will be composed. Will there be a date of the commit besides its hash being reported? 

> In the past I could easily judge if there was a need to buildworld or buildkernel: If uname shows a larger revision number than those in advisories or notices.

> Question: How may one find out whether to recompile or not in the future?

> Thanks and regards,
> Michael

It is good to have a revision number available through uname -a or otherwise.

Not sure about how Haiku does that, but Haiku uses tags that are noticeable when downloading (git clone or pull).  I believe tags show the revision number.

I haven't run Haiku in several years; all I have is USB-stick image from November 2012, downloaded 2014 (?), too old to be able to compile newer versions, and trying to cross-compile from FreeBSD or NetBSD has never been successful.

Tom


From yuripv at yuripv.dev  Fri Dec 25 00:24:25 2020
From: yuripv at yuripv.dev (Yuri Pankov)
Date: Fri, 25 Dec 2020 03:24:19 +0300
Subject: Boot panic on Lenovo P50s since r367998
In-Reply-To: <20201225090219.d98fa1ce21d600f0da606e29@dec.sakura.ne.jp>
References: <89112D93-739D-45B5-B21A-3396C098A89B@bumblingdork.com>
 <20201225090219.d98fa1ce21d600f0da606e29@dec.sakura.ne.jp>
Message-ID: <10a15dcd-aad7-736c-63f4-a7bf06c2fa3f@yuripv.dev>

Tomoaki AOKI wrote:
> On Thu, 24 Dec 2020 10:34:49 +0100
> Marc Veldman <marc at bumblingdork.com> wrote:
> 
>> Hello,
>>
>> since r367998 my Lenovo P50s panics on boot:
>>
>> mmc0: detached
>> panic: Bad link elm 0xfffff80003a73300 next->prep != elm
>> cupid=3
>> time=2
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff8299a9c0
>> vpanic() at vpanic+0x181/frame 0xffffffff8299aa10
>> panic() at panic+0x43/frame 0xffffffff8299aa70
>> config_intrhook_disestablish() at config_intrhook_disestablish+0xf3/frame 0xffffffff8299aa90
>> config_intrhook_oneshot_func() at config_intrhook_oneshot_func+0x18/frame 0xffffffff8299aab0
>> run_interrupt_driven_config_hooks() at run_interrupt_driven_config_hooks+0x77/frame 0xffffffff8299aad0
>> boot_run_interrupt_driven_config_hooks() at boot_run_interrupt_driven_config_hooks+0x1f/frame 0xffffffff8299ab60
>> mi_startup() at mi_startup+0xec/frame 0xffffffff8299abb0
>> btext() at btext+0x2c
>> KDB: enter: panic
>> [thread pid 0 tid 100000]
>> Stopped at     kdb_enter+0x37: movq     $0,0x10ada46(%rip)
>>
>> If needed, I can test patches
>>
>> Dmesg (with r367977 kernel)
>>
>> ---<<BOOT>>---
>> Copyright (c) 1992-2020 The FreeBSD Project.
>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>> 	The Regents of the University of California. All rights reserved.
>> FreeBSD is a registered trademark of The FreeBSD Foundation.
>> FreeBSD 13.0-CURRENT #0 r367997: Tue Dec 22 16:47:30 CET 2020
>>      root at devnovo:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
>> FreeBSD clang version 11.0.0 (git at github.com:llvm/llvm-project.git llvmorg-11.0.0-0-g176249bd673)
>> WARNING: WITNESS option enabled, expect reduced performance.
>> VT(efifb): resolution 1920x1080
>> CPU: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz (2592.10-MHz K8-class CPU)
>>    Origin="GenuineIntel"  Id=0x406e3  Family=0x6  Model=0x4e  Stepping=3
>>    Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>>    Features2=0x7ffafbbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
>>    AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
>>    AMD Features2=0x121<LAHF,ABM,Prefetch>
>>    Structured Extended Features=0x29c67af<FSGSBASE,TSCADJ,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,NFPUSG,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PROCTRACE>
>>    Structured Extended Features3=0x9c000000<IBPB,STIBP,L1DFL,SSBD>
>>    XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
>>    VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>>    TSC: P-state invariant, performance statistics
>> real memory  = 17179869184 (16384 MB)
>> avail memory = 16421109760 (15660 MB)
>> Event timer "LAPIC" quality 600
>> ACPI APIC Table: <LENOVO TP-N1K  >
>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
>> FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads
>> random: registering fast source Intel Secure Key RNG
>> random: fast provider: "Intel Secure Key RNG"
>> random: unblocking device.
>> ioapic0 <Version 2.0> irqs 0-119
>> Launching APs: 1 3 2
>> Timecounter "TSC-low" frequency 1296050980 Hz quality 1000
>> random: entropy device external interface
>> WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0.
>> kbd1 at kbdmux0
>> 000.000045 [4346] netmap_init               netmap: loaded module
>> [ath_hal] loaded
>> nexus0
>> efirtc0: <EFI Realtime Clock>
>> efirtc0: registered as a time-of-day clock, resolution 1.000000s
>> cryptosoft0: <software crypto>
>> aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS>
>> acpi0: <LENOVO TP-N1K>
>> acpi_ec0: <Embedded Controller: GPE 0x16, ECDT> port 0x62,0x66 on acpi0
>> acpi0: Power Button (fixed)
>> cpu0: <ACPI CPU> on acpi0
>> attimer0: <AT timer> port 0x40-0x43 irq 0 on acpi0
>> Timecounter "i8254" frequency 1193182 Hz quality 0
>> Event timer "i8254" frequency 1193182 Hz quality 100
>> hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
>> Timecounter "HPET" frequency 24000000 Hz quality 950
>> Event timer "HPET" frequency 24000000 Hz quality 550
>> Event timer "HPET1" frequency 24000000 Hz quality 440
>> Event timer "HPET2" frequency 24000000 Hz quality 440
>> Event timer "HPET3" frequency 24000000 Hz quality 440
>> Event timer "HPET4" frequency 24000000 Hz quality 440
>> atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
>> atrtc0: registered as a time-of-day clock, resolution 1.000000s
>> Event timer "RTC" frequency 32768 Hz quality 0
>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
>> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0
>> acpi_lid0: <Control Method Lid Switch> on acpi0
>> acpi_button0: <Sleep Button> on acpi0
>> pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
>> pci0: <ACPI PCI bus> on pcib0
>> vgapci0: <VGA-compatible display> port 0xe000-0xe03f mem 0xf2000000-0xf2ffffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0
>> vgapci0: Boot video device
>> xhci0: <Intel Sunrise Point-LP USB 3.0 controller> mem 0xf4220000-0xf422ffff at device 20.0 on pci0
>> xhci0: 32 bytes context size, 64-bit DMA
>> usbus0 on xhci0
>> usbus0: 5.0Gbps Super Speed USB v3.0
>> pci0: <simple comms> at device 22.0 (no driver attached)
>> ahci0: <Intel Sunrise Point-LP AHCI SATA controller> port 0xe080-0xe087,0xe088-0xe08b,0xe060-0xe07f mem 0xf4248000-0xf4249fff,0xf424f000-0xf424f0ff,0xf424d000-0xf424d7ff at device 23.0 on pci0
>> ahci0: AHCI v1.31 with 1 6Gbps ports, Port Multiplier not supported
>> ahcich1: <AHCI channel> at channel 1 on ahci0
>> pcib1: <ACPI PCI-PCI bridge> at device 28.0 on pci0
>> pci1: <ACPI PCI bus> on pcib1
>> pci1: <unknown> at device 0.0 (no driver attached)
>> pcib2: <ACPI PCI-PCI bridge> at device 28.2 on pci0
>> pci2: <ACPI PCI bus> on pcib2
>> pci2: <network> at device 0.0 (no driver attached)
>> pcib3: <ACPI PCI-PCI bridge> at device 29.0 on pci0
>> pci3: <ACPI PCI bus> on pcib3
>> vgapci1: <VGA-compatible display> port 0xd000-0xd07f mem 0xf3000000-0xf3ffffff,0xe0000000-0xefffffff,0xf0000000-0xf1ffffff at device 0.0 on pci3
>> isab0: <PCI-ISA bridge> at device 31.0 on pci0
>> isa0: <ISA bus> on isab0
>> pci0: <memory> at device 31.2 (no driver attached)
>> hdac0: <Intel Sunrise Point-LP HDA Controller> mem 0xf4240000-0xf4243fff,0xf4230000-0xf423ffff at device 31.3 on pci0
>> em0: <Intel(R) PRO/1000 Network Connection> mem 0xf4200000-0xf421ffff at device 31.6 on pci0
>> em0: Using 1024 TX descriptors and 1024 RX descriptors
>> em0: Using an MSI interrupt
>> em0: Ethernet address: 54:ee:75:cb:0d:e3
>> em0: netmap queues/slots: TX 1/1024, RX 1/1024
>> acpi_tz0: <Thermal Zone> on acpi0
>> atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
>> atkbd0: <AT Keyboard> irq 1 on atkbdc0
>> kbd0 at atkbd0
>> atkbd0: [GIANT-LOCKED]
>> psm0: <PS/2 Mouse> irq 12 on atkbdc0
>> psm0: [GIANT-LOCKED]
>> WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD 13.0.
>> psm0: model Synaptics Touchpad, device ID 0
>> battery0: <ACPI Control Method Battery> on acpi0
>> battery1: <ACPI Control Method Battery> on acpi0
>> acpi_acad0: <AC Adapter> on acpi0
>> orm0: <ISA Option ROM> at iomem 0xc0000-0xcffff pnpid ORM0000 on isa0
>> hwpstate_intel0: <Intel Speed Shift> on cpu0
>> hwpstate_intel1: <Intel Speed Shift> on cpu1
>> hwpstate_intel2: <Intel Speed Shift> on cpu2
>> hwpstate_intel3: <Intel Speed Shift> on cpu3
>> Timecounters tick every 1.000 msec
>> ZFS filesystem version: 5
>> ZFS storage pool version: features support (5000)
>> hdacc0: <Realtek ALC293 HDA CODEC> at cad 0 on hdac0
>> ugen0.1: <0x8086 XHCI root HUB> at usbus0
>> hdaa0: <Realtek ALC293 Audio Function Group> at nid 1 on hdacc0
>> pcm0: <Realtek ALC293 (Analog)> at nid 20 and 26 on hdaa0
>> pcm1: <Realtek ALC293 (Analog)> at nid 21 and 18 on hdaa0
>> hdacc1: <Intel Skylake HDA CODEC> at cad 2 on hdac0
>> hdaa1: <Intel Skylake Audio Function Group> at nid 1 on hdacc1
>> pcm2: <Intel Skylake (HDMI/DP 8ch)> at nid 3 on hdaa1
>> Trying to mount root from zfs:zroot/ROOT/default []...
>> Root mount waiting for: usbus0 CAM
>> WARNING: WITNESS option enabled, expect reduced performance.
>> uhub0 on usbus0
>> uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
>> ada0 at ahcich1 bus 0 scbus0 target 0 lun 0
>> ada0: <Samsung SSD 850 PRO 512GB EXM04B6Q> ACS-2 ATA SATA 3.x device
>> ada0: Serial Number S39FNX0J625463T
>> ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)
>> ada0: Command Queueing enabled
>> ada0: 488386MB (1000215216 512 byte sectors)
>> ada0: quirks=0x3<4K,NCQ_TRIM_BROKEN>
>> GEOM_ELI: Device ada0p4.eli created.
>> GEOM_ELI: Encryption: AES-XTS 256
>> GEOM_ELI:     Crypto: accelerated software
>> uhub0: 18 ports with 18 removable, self powered
>> Root mount waiting for: usbus0
>> ugen0.2: <Prolific Technology Inc. USB-Serial Controller> at usbus0
>> Root mount waiting for: usbus0
>> ugen0.3: <vendor 0x8087 product 0x0a2b> at usbus0
>> ugen0.4: <SunplusIT Inc Integrated Camera> at usbus0
>> Root mount waiting for: usbus0
>> ugen0.5: <vendor 0x138a product 0x0017> at usbus0
>> lo0: link state changed to UP
>> pchtherm0: <Skylake PCH Thermal Subsystem> mem 0xf424b000-0xf424bfff at device 20.2 on pci0
>> iwm0: <Intel(R) Dual Band Wireless AC 8260> mem 0xf4000000-0xf4001fff at device 0.0 on pci2
>> iwm0: hw rev 0x200, fw ver 22.361476.0, address f4:8c:50:50:22:83
>> ichsmb0: <Intel Sunrise Point-LP SMBus controller> port 0xefa0-0xefbf mem 0xf424e000-0xf424e0ff at device 31.4 on pci0
>> smbus0: <System Management Bus> on ichsmb0
>> acpi_wmi0: <ACPI-WMI mapping> on acpi0
>> acpi_wmi0: Embedded MOF found
>> ACPI: \134_SB.WMI1.WQBA: 1 arguments were passed to a non-method ACPI object (Buffer) (20201113/nsarguments-361)
>> acpi_wmi1: <ACPI-WMI mapping> on acpi0
>> acpi_wmi1: Embedded MOF found
>> ACPI: \134_SB.WMI2.WQBB: 1 arguments were passed to a non-method ACPI object (Buffer) (20201113/nsarguments-361)
>> acpi_wmi2: <ACPI-WMI mapping> on acpi0
>> acpi_wmi2: Embedded MOF found
>> ACPI: \134_SB.WMI3.WQBC: 1 arguments were passed to a non-method ACPI object (Buffer) (20201113/nsarguments-361)
>> uplcom0 on uhub0
>> uplcom0: <Prolific Technology Inc. USB-Serial Controller, class 0/0, rev 1.10/3.00, addr 1> on usbus0
>> wlan0: Ethernet address: f4:8c:50:50:22:83
>> ng_ubt: HCI command 0xfc05 timed out
>> ubt0 on uhub0
>> ubt0: <vendor 0x8087 product 0x0a2b, class 224/1, rev 2.00/0.01, addr 2> on usbus0
>> wlan0: link state changed to UP
>> WARNING: attempt to domain_add(bluetooth) after domainfinalize()
>> WARNING: attempt to domain_add(netgraph) after domainfinalize()
>> iwm0: code ce, frame 2/216 b800002c unhandled
>> Security policy loaded: MAC/ntpd (mac_ntpd)
>>
>> _______________________________________________
>> freebsd-current at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
> 
> Hi.
> You would be bitten by a known issue with ThinkPad P50s described in
> rtsx (4) man page.
> 
> Try adding dev.rtsx.0.inversion=1 in /boot/loader.conf.

I wonder if it's possible to add the workarounds to the driver itself 
based on "smbios.system.product" or "smbios.system.version" values 
returned by kern_getenv() as done in some other places 
(sys/dev/mii/brgphy.c, sys/dev/nfe/if_nfe.c)?  For me, 
"family"/"product" is "ThinkPad P51", and "product" is specific model, 
"20HH001RRT"; there are different ones under the same family.

> Unfortunately, man pages for head cannot read via FreeBSD project top
> page. So read raw manpage data with svn commit mail archive below.
> 
>   https://lists.freebsd.org/pipermail/svn-src-head/2020-November/141972.html

There's a "13.0-current" selection in drop-down menu, wonder how often 
is the man page list regenerated.

> In addition, write attempts to write-protected card causes 100% panic.
> For example, sysutils/automount trys fsck on mount.
> This causes 100% panic (not only rtsx, but every adapters), avoidable
> by write-protect off.


From yuripv at yuripv.dev  Fri Dec 25 00:27:04 2020
From: yuripv at yuripv.dev (Yuri Pankov)
Date: Fri, 25 Dec 2020 03:27:00 +0300
Subject: Boot panic on Lenovo P50s since r367998
In-Reply-To: <10a15dcd-aad7-736c-63f4-a7bf06c2fa3f@yuripv.dev>
References: <89112D93-739D-45B5-B21A-3396C098A89B@bumblingdork.com>
 <20201225090219.d98fa1ce21d600f0da606e29@dec.sakura.ne.jp>
 <10a15dcd-aad7-736c-63f4-a7bf06c2fa3f@yuripv.dev>
Message-ID: <9535ee6d-6daa-0964-5de1-f3851efbd9cd@yuripv.dev>

Yuri Pankov wrote:
> Tomoaki AOKI wrote:
>> On Thu, 24 Dec 2020 10:34:49 +0100
>> Marc Veldman <marc at bumblingdork.com> wrote:
>>
>>> Hello,
>>>
>>> since r367998 my Lenovo P50s panics on boot:
>>>
>>> mmc0: detached
>>> panic: Bad link elm 0xfffff80003a73300 next->prep != elm
>>> cupid=3
>>> time=2
>>> KDB: stack backtrace:
>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 
>>> 0xffffffff8299a9c0
>>> vpanic() at vpanic+0x181/frame 0xffffffff8299aa10
>>> panic() at panic+0x43/frame 0xffffffff8299aa70
>>> config_intrhook_disestablish() at 
>>> config_intrhook_disestablish+0xf3/frame 0xffffffff8299aa90
>>> config_intrhook_oneshot_func() at 
>>> config_intrhook_oneshot_func+0x18/frame 0xffffffff8299aab0
>>> run_interrupt_driven_config_hooks() at 
>>> run_interrupt_driven_config_hooks+0x77/frame 0xffffffff8299aad0
>>> boot_run_interrupt_driven_config_hooks() at 
>>> boot_run_interrupt_driven_config_hooks+0x1f/frame 0xffffffff8299ab60
>>> mi_startup() at mi_startup+0xec/frame 0xffffffff8299abb0
>>> btext() at btext+0x2c
>>> KDB: enter: panic
>>> [thread pid 0 tid 100000]
>>> Stopped at???? kdb_enter+0x37: movq???? $0,0x10ada46(%rip)
>>>
>>> If needed, I can test patches
>>>
>>> Dmesg (with r367977 kernel)
>>>
>>> ---<<BOOT>>---
>>> Copyright (c) 1992-2020 The FreeBSD Project.
>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>>> ????The Regents of the University of California. All rights reserved.
>>> FreeBSD is a registered trademark of The FreeBSD Foundation.
>>> FreeBSD 13.0-CURRENT #0 r367997: Tue Dec 22 16:47:30 CET 2020
>>> ???? root at devnovo:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
>>> FreeBSD clang version 11.0.0 (git at github.com:llvm/llvm-project.git 
>>> llvmorg-11.0.0-0-g176249bd673)
>>> WARNING: WITNESS option enabled, expect reduced performance.
>>> VT(efifb): resolution 1920x1080
>>> CPU: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz (2592.10-MHz K8-class CPU)
>>> ?? Origin="GenuineIntel"? Id=0x406e3? Family=0x6? Model=0x4e? Stepping=3
>>>    
>>> Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> 
>>>
>>>    
>>> Features2=0x7ffafbbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> 
>>>
>>> ?? AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
>>> ?? AMD Features2=0x121<LAHF,ABM,Prefetch>
>>> ?? Structured Extended 
>>> Features=0x29c67af<FSGSBASE,TSCADJ,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,NFPUSG,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PROCTRACE> 
>>>
>>> ?? Structured Extended Features3=0x9c000000<IBPB,STIBP,L1DFL,SSBD>
>>> ?? XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
>>> ?? VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>>> ?? TSC: P-state invariant, performance statistics
>>> real memory? = 17179869184 (16384 MB)
>>> avail memory = 16421109760 (15660 MB)
>>> Event timer "LAPIC" quality 600
>>> ACPI APIC Table: <LENOVO TP-N1K? >
>>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
>>> FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads
>>> random: registering fast source Intel Secure Key RNG
>>> random: fast provider: "Intel Secure Key RNG"
>>> random: unblocking device.
>>> ioapic0 <Version 2.0> irqs 0-119
>>> Launching APs: 1 3 2
>>> Timecounter "TSC-low" frequency 1296050980 Hz quality 1000
>>> random: entropy device external interface
>>> WARNING: Device "kbd" is Giant locked and may be deleted before 
>>> FreeBSD 13.0.
>>> kbd1 at kbdmux0
>>> 000.000045 [4346] netmap_init?????????????? netmap: loaded module
>>> [ath_hal] loaded
>>> nexus0
>>> efirtc0: <EFI Realtime Clock>
>>> efirtc0: registered as a time-of-day clock, resolution 1.000000s
>>> cryptosoft0: <software crypto>
>>> aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS>
>>> acpi0: <LENOVO TP-N1K>
>>> acpi_ec0: <Embedded Controller: GPE 0x16, ECDT> port 0x62,0x66 on acpi0
>>> acpi0: Power Button (fixed)
>>> cpu0: <ACPI CPU> on acpi0
>>> attimer0: <AT timer> port 0x40-0x43 irq 0 on acpi0
>>> Timecounter "i8254" frequency 1193182 Hz quality 0
>>> Event timer "i8254" frequency 1193182 Hz quality 100
>>> hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
>>> Timecounter "HPET" frequency 24000000 Hz quality 950
>>> Event timer "HPET" frequency 24000000 Hz quality 550
>>> Event timer "HPET1" frequency 24000000 Hz quality 440
>>> Event timer "HPET2" frequency 24000000 Hz quality 440
>>> Event timer "HPET3" frequency 24000000 Hz quality 440
>>> Event timer "HPET4" frequency 24000000 Hz quality 440
>>> atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
>>> atrtc0: registered as a time-of-day clock, resolution 1.000000s
>>> Event timer "RTC" frequency 32768 Hz quality 0
>>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
>>> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0
>>> acpi_lid0: <Control Method Lid Switch> on acpi0
>>> acpi_button0: <Sleep Button> on acpi0
>>> pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
>>> pci0: <ACPI PCI bus> on pcib0
>>> vgapci0: <VGA-compatible display> port 0xe000-0xe03f mem 
>>> 0xf2000000-0xf2ffffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0
>>> vgapci0: Boot video device
>>> xhci0: <Intel Sunrise Point-LP USB 3.0 controller> mem 
>>> 0xf4220000-0xf422ffff at device 20.0 on pci0
>>> xhci0: 32 bytes context size, 64-bit DMA
>>> usbus0 on xhci0
>>> usbus0: 5.0Gbps Super Speed USB v3.0
>>> pci0: <simple comms> at device 22.0 (no driver attached)
>>> ahci0: <Intel Sunrise Point-LP AHCI SATA controller> port 
>>> 0xe080-0xe087,0xe088-0xe08b,0xe060-0xe07f mem 
>>> 0xf4248000-0xf4249fff,0xf424f000-0xf424f0ff,0xf424d000-0xf424d7ff at 
>>> device 23.0 on pci0
>>> ahci0: AHCI v1.31 with 1 6Gbps ports, Port Multiplier not supported
>>> ahcich1: <AHCI channel> at channel 1 on ahci0
>>> pcib1: <ACPI PCI-PCI bridge> at device 28.0 on pci0
>>> pci1: <ACPI PCI bus> on pcib1
>>> pci1: <unknown> at device 0.0 (no driver attached)
>>> pcib2: <ACPI PCI-PCI bridge> at device 28.2 on pci0
>>> pci2: <ACPI PCI bus> on pcib2
>>> pci2: <network> at device 0.0 (no driver attached)
>>> pcib3: <ACPI PCI-PCI bridge> at device 29.0 on pci0
>>> pci3: <ACPI PCI bus> on pcib3
>>> vgapci1: <VGA-compatible display> port 0xd000-0xd07f mem 
>>> 0xf3000000-0xf3ffffff,0xe0000000-0xefffffff,0xf0000000-0xf1ffffff at 
>>> device 0.0 on pci3
>>> isab0: <PCI-ISA bridge> at device 31.0 on pci0
>>> isa0: <ISA bus> on isab0
>>> pci0: <memory> at device 31.2 (no driver attached)
>>> hdac0: <Intel Sunrise Point-LP HDA Controller> mem 
>>> 0xf4240000-0xf4243fff,0xf4230000-0xf423ffff at device 31.3 on pci0
>>> em0: <Intel(R) PRO/1000 Network Connection> mem 0xf4200000-0xf421ffff 
>>> at device 31.6 on pci0
>>> em0: Using 1024 TX descriptors and 1024 RX descriptors
>>> em0: Using an MSI interrupt
>>> em0: Ethernet address: 54:ee:75:cb:0d:e3
>>> em0: netmap queues/slots: TX 1/1024, RX 1/1024
>>> acpi_tz0: <Thermal Zone> on acpi0
>>> atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
>>> atkbd0: <AT Keyboard> irq 1 on atkbdc0
>>> kbd0 at atkbd0
>>> atkbd0: [GIANT-LOCKED]
>>> psm0: <PS/2 Mouse> irq 12 on atkbdc0
>>> psm0: [GIANT-LOCKED]
>>> WARNING: Device "psm" is Giant locked and may be deleted before 
>>> FreeBSD 13.0.
>>> psm0: model Synaptics Touchpad, device ID 0
>>> battery0: <ACPI Control Method Battery> on acpi0
>>> battery1: <ACPI Control Method Battery> on acpi0
>>> acpi_acad0: <AC Adapter> on acpi0
>>> orm0: <ISA Option ROM> at iomem 0xc0000-0xcffff pnpid ORM0000 on isa0
>>> hwpstate_intel0: <Intel Speed Shift> on cpu0
>>> hwpstate_intel1: <Intel Speed Shift> on cpu1
>>> hwpstate_intel2: <Intel Speed Shift> on cpu2
>>> hwpstate_intel3: <Intel Speed Shift> on cpu3
>>> Timecounters tick every 1.000 msec
>>> ZFS filesystem version: 5
>>> ZFS storage pool version: features support (5000)
>>> hdacc0: <Realtek ALC293 HDA CODEC> at cad 0 on hdac0
>>> ugen0.1: <0x8086 XHCI root HUB> at usbus0
>>> hdaa0: <Realtek ALC293 Audio Function Group> at nid 1 on hdacc0
>>> pcm0: <Realtek ALC293 (Analog)> at nid 20 and 26 on hdaa0
>>> pcm1: <Realtek ALC293 (Analog)> at nid 21 and 18 on hdaa0
>>> hdacc1: <Intel Skylake HDA CODEC> at cad 2 on hdac0
>>> hdaa1: <Intel Skylake Audio Function Group> at nid 1 on hdacc1
>>> pcm2: <Intel Skylake (HDMI/DP 8ch)> at nid 3 on hdaa1
>>> Trying to mount root from zfs:zroot/ROOT/default []...
>>> Root mount waiting for: usbus0 CAM
>>> WARNING: WITNESS option enabled, expect reduced performance.
>>> uhub0 on usbus0
>>> uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on 
>>> usbus0
>>> ada0 at ahcich1 bus 0 scbus0 target 0 lun 0
>>> ada0: <Samsung SSD 850 PRO 512GB EXM04B6Q> ACS-2 ATA SATA 3.x device
>>> ada0: Serial Number S39FNX0J625463T
>>> ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)
>>> ada0: Command Queueing enabled
>>> ada0: 488386MB (1000215216 512 byte sectors)
>>> ada0: quirks=0x3<4K,NCQ_TRIM_BROKEN>
>>> GEOM_ELI: Device ada0p4.eli created.
>>> GEOM_ELI: Encryption: AES-XTS 256
>>> GEOM_ELI:???? Crypto: accelerated software
>>> uhub0: 18 ports with 18 removable, self powered
>>> Root mount waiting for: usbus0
>>> ugen0.2: <Prolific Technology Inc. USB-Serial Controller> at usbus0
>>> Root mount waiting for: usbus0
>>> ugen0.3: <vendor 0x8087 product 0x0a2b> at usbus0
>>> ugen0.4: <SunplusIT Inc Integrated Camera> at usbus0
>>> Root mount waiting for: usbus0
>>> ugen0.5: <vendor 0x138a product 0x0017> at usbus0
>>> lo0: link state changed to UP
>>> pchtherm0: <Skylake PCH Thermal Subsystem> mem 0xf424b000-0xf424bfff 
>>> at device 20.2 on pci0
>>> iwm0: <Intel(R) Dual Band Wireless AC 8260> mem 0xf4000000-0xf4001fff 
>>> at device 0.0 on pci2
>>> iwm0: hw rev 0x200, fw ver 22.361476.0, address f4:8c:50:50:22:83
>>> ichsmb0: <Intel Sunrise Point-LP SMBus controller> port 0xefa0-0xefbf 
>>> mem 0xf424e000-0xf424e0ff at device 31.4 on pci0
>>> smbus0: <System Management Bus> on ichsmb0
>>> acpi_wmi0: <ACPI-WMI mapping> on acpi0
>>> acpi_wmi0: Embedded MOF found
>>> ACPI: \134_SB.WMI1.WQBA: 1 arguments were passed to a non-method ACPI 
>>> object (Buffer) (20201113/nsarguments-361)
>>> acpi_wmi1: <ACPI-WMI mapping> on acpi0
>>> acpi_wmi1: Embedded MOF found
>>> ACPI: \134_SB.WMI2.WQBB: 1 arguments were passed to a non-method ACPI 
>>> object (Buffer) (20201113/nsarguments-361)
>>> acpi_wmi2: <ACPI-WMI mapping> on acpi0
>>> acpi_wmi2: Embedded MOF found
>>> ACPI: \134_SB.WMI3.WQBC: 1 arguments were passed to a non-method ACPI 
>>> object (Buffer) (20201113/nsarguments-361)
>>> uplcom0 on uhub0
>>> uplcom0: <Prolific Technology Inc. USB-Serial Controller, class 0/0, 
>>> rev 1.10/3.00, addr 1> on usbus0
>>> wlan0: Ethernet address: f4:8c:50:50:22:83
>>> ng_ubt: HCI command 0xfc05 timed out
>>> ubt0 on uhub0
>>> ubt0: <vendor 0x8087 product 0x0a2b, class 224/1, rev 2.00/0.01, addr 
>>> 2> on usbus0
>>> wlan0: link state changed to UP
>>> WARNING: attempt to domain_add(bluetooth) after domainfinalize()
>>> WARNING: attempt to domain_add(netgraph) after domainfinalize()
>>> iwm0: code ce, frame 2/216 b800002c unhandled
>>> Security policy loaded: MAC/ntpd (mac_ntpd)
>>>
>>> _______________________________________________
>>> freebsd-current at freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to 
>>> "freebsd-current-unsubscribe at freebsd.org"
>>
>> Hi.
>> You would be bitten by a known issue with ThinkPad P50s described in
>> rtsx (4) man page.
>>
>> Try adding dev.rtsx.0.inversion=1 in /boot/loader.conf.
> 
> I wonder if it's possible to add the workarounds to the driver itself 
> based on "smbios.system.product" or "smbios.system.version" values 
> returned by kern_getenv() as done in some other places 
> (sys/dev/mii/brgphy.c, sys/dev/nfe/if_nfe.c)?? For me, 
> "family"/"product" is "ThinkPad P51", and "product" is specific model,
            ^^^^^^^^^
            "version"

> "20HH001RRT"; there are different ones under the same family.
> 
>> Unfortunately, man pages for head cannot read via FreeBSD project top
>> page. So read raw manpage data with svn commit mail archive below.
>>
>>   
>> https://lists.freebsd.org/pipermail/svn-src-head/2020-November/141972.html 
>>
> 
> There's a "13.0-current" selection in drop-down menu, wonder how often 
> is the man page list regenerated.
> 
>> In addition, write attempts to write-protected card causes 100% panic.
>> For example, sysutils/automount trys fsck on mount.
>> This causes 100% panic (not only rtsx, but every adapters), avoidable
>> by write-protect off.

From kiri at truefc.org  Fri Dec 25 00:43:28 2020
From: kiri at truefc.org (KIRIYAMA Kazuhiko)
Date: Fri, 25 Dec 2020 09:43:17 +0900
Subject: Is there any machine RISC-V implemented ?
Message-ID: <202012250043.0BP0hHUM017340@kx.truefc.org>

Hi, all

I've found RISC-V images in snapshots/ISO-IMAGES. Is there
any machine RISC-V implemented so far ?

From marc at bumblingdork.com  Fri Dec 25 00:46:16 2020
From: marc at bumblingdork.com (Marc Veldman)
Date: Fri, 25 Dec 2020 01:46:12 +0100
Subject: Boot panic on Lenovo P50s since r367998
In-Reply-To: <6d42bbaa-7c88-db53-c441-40513c043847@yuripv.dev>
References: <89112D93-739D-45B5-B21A-3396C098A89B@bumblingdork.com>
 <6d42bbaa-7c88-db53-c441-40513c043847@yuripv.dev>
Message-ID: <7DDC11C4-41D2-440E-9C14-C37894325903@bumblingdork.com>



> On 25 Dec 2020, at 00:04, Yuri Pankov <yuripv at yuripv.dev> wrote:
> 
> Marc Veldman wrote:
>> Hello,
>> since r367998 my Lenovo P50s panics on boot:
>> mmc0: detached
>> panic: Bad link elm 0xfffff80003a73300 next->prep != elm
>> cupid=3
>> time=2
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff8299a9c0
>> vpanic() at vpanic+0x181/frame 0xffffffff8299aa10
>> panic() at panic+0x43/frame 0xffffffff8299aa70
>> config_intrhook_disestablish() at config_intrhook_disestablish+0xf3/frame 0xffffffff8299aa90
>> config_intrhook_oneshot_func() at config_intrhook_oneshot_func+0x18/frame 0xffffffff8299aab0
>> run_interrupt_driven_config_hooks() at run_interrupt_driven_config_hooks+0x77/frame 0xffffffff8299aad0
>> boot_run_interrupt_driven_config_hooks() at boot_run_interrupt_driven_config_hooks+0x1f/frame 0xffffffff8299ab60
>> mi_startup() at mi_startup+0xec/frame 0xffffffff8299abb0
>> btext() at btext+0x2c
>> KDB: enter: panic
>> [thread pid 0 tid 100000]
>> Stopped at     kdb_enter+0x37: movq     $0,0x10ada46(%rip)
> 
> r367998 adds rtsx driver for card reader, seems to work for me on P51 (as in "detected and does not panic", I don't have any cards around to really test it):
> 
> rtsx0 at pci0:63:0:0:	class=0xff0000 rev=0x01 hdr=0x00 vendor=0x10ec device=0x525a subvendor=0x17aa subdevice=0x224d
>    vendor	= 'Realtek Semiconductor Co., Ltd.'
>    device	= 'RTS525A PCI Express Card Reader'
> 
> To confirm the issue is indeed in rtsx, does disabling the card reader in bios help?  If it does, what is the device exactly (`pciconf -lv` when booted on pre-r367998)?

The laptop does boot with the card reader disabled in BIOS, pciconf -lv output:.

hostb0 at pci0:0:0:0:      class=0x060000 rev=0x08 hdr=0x00 vendor=0x8086 device=0x1904 subvendor=0x17aa subdevice=0x2231
    vendor     = 'Intel Corporation'
    device     = 'Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers'
    class      = bridge
    subclass   = HOST-PCI
vgapci0 at pci0:0:2:0:     class=0x030000 rev=0x07 hdr=0x00 vendor=0x8086 device=0x1916 subvendor=0x17aa subdevice=0x2232
    vendor     = 'Intel Corporation'
    device     = 'Skylake GT2 [HD Graphics 520]'
    class      = display
    subclass   = VGA
none0 at pci0:0:8:0:       class=0x088000 rev=0x00 hdr=0x00 vendor=0x8086 device=0x1911 subvendor=0x17aa subdevice=0x2231
    vendor     = 'Intel Corporation'
    device     = 'Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model'
    class      = base peripheral
xhci0 at pci0:0:20:0:      class=0x0c0330 rev=0x21 hdr=0x00 vendor=0x8086 device=0x9d2f subvendor=0x17aa subdevice=0x2231
    vendor     = 'Intel Corporation'
    device     = 'Sunrise Point-LP USB 3.0 xHCI Controller'
    class      = serial bus
    subclass   = USB
pchtherm0 at pci0:0:20:2:  class=0x118000 rev=0x21 hdr=0x00 vendor=0x8086 device=0x9d31 subvendor=0x17aa subdevice=0x2231
    vendor     = 'Intel Corporation'
    device     = 'Sunrise Point-LP Thermal subsystem'
    class      = dasp
none1 at pci0:0:22:0:      class=0x078000 rev=0x21 hdr=0x00 vendor=0x8086 device=0x9d3a subvendor=0x17aa subdevice=0x2231
    vendor     = 'Intel Corporation'
    device     = 'Sunrise Point-LP CSME HECI'
    class      = simple comms
ahci0 at pci0:0:23:0:      class=0x010601 rev=0x21 hdr=0x00 vendor=0x8086 device=0x9d03 subvendor=0x17aa subdevice=0x2231
    vendor     = 'Intel Corporation'
    device     = 'Sunrise Point-LP SATA Controller [AHCI mode]'
    class      = mass storage
    subclass   = SATA
pcib1 at pci0:0:28:0:      class=0x060400 rev=0xf1 hdr=0x01 vendor=0x8086 device=0x9d10 subvendor=0x17aa subdevice=0x2231
    vendor     = 'Intel Corporation'
    device     = 'Sunrise Point-LP PCI Express Root Port'
    class      = bridge
    subclass   = PCI-PCI
pcib2 at pci0:0:28:2:      class=0x060400 rev=0xf1 hdr=0x01 vendor=0x8086 device=0x9d12 subvendor=0x17aa subdevice=0x2231
    vendor     = 'Intel Corporation'
    device     = 'Sunrise Point-LP PCI Express Root Port'
    class      = bridge
    subclass   = PCI-PCI
pcib3 at pci0:0:29:0:      class=0x060400 rev=0xf1 hdr=0x01 vendor=0x8086 device=0x9d18 subvendor=0x17aa subdevice=0x2231
    vendor     = 'Intel Corporation'
    device     = 'Sunrise Point-LP PCI Express Root Port'
    class      = bridge
    subclass   = PCI-PCI
isab0 at pci0:0:31:0:      class=0x060100 rev=0x21 hdr=0x00 vendor=0x8086 device=0x9d48 subvendor=0x17aa subdevice=0x2231
    vendor     = 'Intel Corporation'
    device     = 'Sunrise Point-LP LPC Controller'
    class      = bridge
    subclass   = PCI-ISA
none2 at pci0:0:31:2:      class=0x058000 rev=0x21 hdr=0x00 vendor=0x8086 device=0x9d21 subvendor=0x17aa subdevice=0x2231
    vendor     = 'Intel Corporation'
    device     = 'Sunrise Point-LP PMC'
    class      = memory
hdac0 at pci0:0:31:3:      class=0x040300 rev=0x21 hdr=0x00 vendor=0x8086 device=0x9d70 subvendor=0x17aa subdevice=0x2231
    vendor     = 'Intel Corporation'
    device     = 'Sunrise Point-LP HD Audio'
    class      = multimedia
    subclass   = HDA
ichsmb0 at pci0:0:31:4:    class=0x0c0500 rev=0x21 hdr=0x00 vendor=0x8086 device=0x9d23 subvendor=0x17aa subdevice=0x2231
    vendor     = 'Intel Corporation'
    device     = 'Sunrise Point-LP SMBus'
    class      = serial bus
    subclass   = SMBus
em0 at pci0:0:31:6:        class=0x020000 rev=0x21 hdr=0x00 vendor=0x8086 device=0x1570 subvendor=0x17aa subdevice=0x2233
    vendor     = 'Intel Corporation'
    device     = 'Ethernet Connection I219-V'
    class      = network
    subclass   = ethernet
none3 at pci0:2:0:0:       class=0xff0000 rev=0x01 hdr=0x00 vendor=0x10ec device=0x522a subvendor=0x17aa subdevice=0x2233
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTS522A PCI Express Card Reader'
iwm0 at pci0:4:0:0:        class=0x028000 rev=0x3a hdr=0x00 vendor=0x8086 device=0x24f3 subvendor=0x8086 subdevice=0x1130
    vendor     = 'Intel Corporation'
    device     = 'Wireless 8260'
    class      = network
vgapci1 at pci0:6:0:0:     class=0x030200 rev=0xa2 hdr=0x00 vendor=0x10de device=0x137a subvendor=0x17aa subdevice=0x2232
    vendor     = 'NVIDIA Corporation'
    device     = 'GM108GLM [Quadro K620M / Quadro M500M]'
    class      = display
    subclass   = 3D





From marc at bumblingdork.com  Fri Dec 25 01:06:03 2020
From: marc at bumblingdork.com (Marc Veldman)
Date: Fri, 25 Dec 2020 02:05:59 +0100
Subject: Boot panic on Lenovo P50s since r367998
In-Reply-To: <20201225090219.d98fa1ce21d600f0da606e29@dec.sakura.ne.jp>
References: <89112D93-739D-45B5-B21A-3396C098A89B@bumblingdork.com>
 <20201225090219.d98fa1ce21d600f0da606e29@dec.sakura.ne.jp>
Message-ID: <846CC065-613F-41FA-B7CF-B88D4DFEEAE0@bumblingdork.com>



> On 25 Dec 2020, at 01:02, Tomoaki AOKI <junchoon at dec.sakura.ne.jp> wrote:
> 
> On Thu, 24 Dec 2020 10:34:49 +0100
> Marc Veldman <marc at bumblingdork.com> wrote:
> 
>> Hello,
>> 
>> since r367998 my Lenovo P50s panics on boot:
>> 
>> mmc0: detached
>> panic: Bad link elm 0xfffff80003a73300 next->prep != elm
>> cupid=3
>> time=2
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff8299a9c0
>> vpanic() at vpanic+0x181/frame 0xffffffff8299aa10
>> panic() at panic+0x43/frame 0xffffffff8299aa70
>> config_intrhook_disestablish() at config_intrhook_disestablish+0xf3/frame 0xffffffff8299aa90
>> config_intrhook_oneshot_func() at config_intrhook_oneshot_func+0x18/frame 0xffffffff8299aab0
>> run_interrupt_driven_config_hooks() at run_interrupt_driven_config_hooks+0x77/frame 0xffffffff8299aad0
>> boot_run_interrupt_driven_config_hooks() at boot_run_interrupt_driven_config_hooks+0x1f/frame 0xffffffff8299ab60
>> mi_startup() at mi_startup+0xec/frame 0xffffffff8299abb0
>> btext() at btext+0x2c
>> KDB: enter: panic
>> [thread pid 0 tid 100000]
>> Stopped at     kdb_enter+0x37: movq     $0,0x10ada46(%rip)
>> 
>> If needed, I can test patches
>> 
>> Dmesg (with r367977 kernel)
>> 
>> ---<<BOOT>>---
>> Copyright (c) 1992-2020 The FreeBSD Project.
>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>> 	The Regents of the University of California. All rights reserved.
>> FreeBSD is a registered trademark of The FreeBSD Foundation.
>> FreeBSD 13.0-CURRENT #0 r367997: Tue Dec 22 16:47:30 CET 2020
>>    root at devnovo:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64
>> FreeBSD clang version 11.0.0 (git at github.com:llvm/llvm-project.git llvmorg-11.0.0-0-g176249bd673)
>> WARNING: WITNESS option enabled, expect reduced performance.
>> VT(efifb): resolution 1920x1080
>> CPU: Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz (2592.10-MHz K8-class CPU)
>>  Origin="GenuineIntel"  Id=0x406e3  Family=0x6  Model=0x4e  Stepping=3
>>  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
>>  Features2=0x7ffafbbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
>>  AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
>>  AMD Features2=0x121<LAHF,ABM,Prefetch>
>>  Structured Extended Features=0x29c67af<FSGSBASE,TSCADJ,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,NFPUSG,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PROCTRACE>
>>  Structured Extended Features3=0x9c000000<IBPB,STIBP,L1DFL,SSBD>
>>  XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
>>  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>>  TSC: P-state invariant, performance statistics
>> real memory  = 17179869184 (16384 MB)
>> avail memory = 16421109760 (15660 MB)
>> Event timer "LAPIC" quality 600
>> ACPI APIC Table: <LENOVO TP-N1K  >
>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
>> FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads
>> random: registering fast source Intel Secure Key RNG
>> random: fast provider: "Intel Secure Key RNG"
>> random: unblocking device.
>> ioapic0 <Version 2.0> irqs 0-119
>> Launching APs: 1 3 2
>> Timecounter "TSC-low" frequency 1296050980 Hz quality 1000
>> random: entropy device external interface
>> WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0.
>> kbd1 at kbdmux0
>> 000.000045 [4346] netmap_init               netmap: loaded module
>> [ath_hal] loaded
>> nexus0
>> efirtc0: <EFI Realtime Clock>
>> efirtc0: registered as a time-of-day clock, resolution 1.000000s
>> cryptosoft0: <software crypto>
>> aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS>
>> acpi0: <LENOVO TP-N1K>
>> acpi_ec0: <Embedded Controller: GPE 0x16, ECDT> port 0x62,0x66 on acpi0
>> acpi0: Power Button (fixed)
>> cpu0: <ACPI CPU> on acpi0
>> attimer0: <AT timer> port 0x40-0x43 irq 0 on acpi0
>> Timecounter "i8254" frequency 1193182 Hz quality 0
>> Event timer "i8254" frequency 1193182 Hz quality 100
>> hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
>> Timecounter "HPET" frequency 24000000 Hz quality 950
>> Event timer "HPET" frequency 24000000 Hz quality 550
>> Event timer "HPET1" frequency 24000000 Hz quality 440
>> Event timer "HPET2" frequency 24000000 Hz quality 440
>> Event timer "HPET3" frequency 24000000 Hz quality 440
>> Event timer "HPET4" frequency 24000000 Hz quality 440
>> atrtc0: <AT realtime clock> port 0x70-0x71 irq 8 on acpi0
>> atrtc0: registered as a time-of-day clock, resolution 1.000000s
>> Event timer "RTC" frequency 32768 Hz quality 0
>> Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
>> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0
>> acpi_lid0: <Control Method Lid Switch> on acpi0
>> acpi_button0: <Sleep Button> on acpi0
>> pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
>> pci0: <ACPI PCI bus> on pcib0
>> vgapci0: <VGA-compatible display> port 0xe000-0xe03f mem 0xf2000000-0xf2ffffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0
>> vgapci0: Boot video device
>> xhci0: <Intel Sunrise Point-LP USB 3.0 controller> mem 0xf4220000-0xf422ffff at device 20.0 on pci0
>> xhci0: 32 bytes context size, 64-bit DMA
>> usbus0 on xhci0
>> usbus0: 5.0Gbps Super Speed USB v3.0
>> pci0: <simple comms> at device 22.0 (no driver attached)
>> ahci0: <Intel Sunrise Point-LP AHCI SATA controller> port 0xe080-0xe087,0xe088-0xe08b,0xe060-0xe07f mem 0xf4248000-0xf4249fff,0xf424f000-0xf424f0ff,0xf424d000-0xf424d7ff at device 23.0 on pci0
>> ahci0: AHCI v1.31 with 1 6Gbps ports, Port Multiplier not supported
>> ahcich1: <AHCI channel> at channel 1 on ahci0
>> pcib1: <ACPI PCI-PCI bridge> at device 28.0 on pci0
>> pci1: <ACPI PCI bus> on pcib1
>> pci1: <unknown> at device 0.0 (no driver attached)
>> pcib2: <ACPI PCI-PCI bridge> at device 28.2 on pci0
>> pci2: <ACPI PCI bus> on pcib2
>> pci2: <network> at device 0.0 (no driver attached)
>> pcib3: <ACPI PCI-PCI bridge> at device 29.0 on pci0
>> pci3: <ACPI PCI bus> on pcib3
>> vgapci1: <VGA-compatible display> port 0xd000-0xd07f mem 0xf3000000-0xf3ffffff,0xe0000000-0xefffffff,0xf0000000-0xf1ffffff at device 0.0 on pci3
>> isab0: <PCI-ISA bridge> at device 31.0 on pci0
>> isa0: <ISA bus> on isab0
>> pci0: <memory> at device 31.2 (no driver attached)
>> hdac0: <Intel Sunrise Point-LP HDA Controller> mem 0xf4240000-0xf4243fff,0xf4230000-0xf423ffff at device 31.3 on pci0
>> em0: <Intel(R) PRO/1000 Network Connection> mem 0xf4200000-0xf421ffff at device 31.6 on pci0
>> em0: Using 1024 TX descriptors and 1024 RX descriptors
>> em0: Using an MSI interrupt
>> em0: Ethernet address: 54:ee:75:cb:0d:e3
>> em0: netmap queues/slots: TX 1/1024, RX 1/1024
>> acpi_tz0: <Thermal Zone> on acpi0
>> atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
>> atkbd0: <AT Keyboard> irq 1 on atkbdc0
>> kbd0 at atkbd0
>> atkbd0: [GIANT-LOCKED]
>> psm0: <PS/2 Mouse> irq 12 on atkbdc0
>> psm0: [GIANT-LOCKED]
>> WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD 13.0.
>> psm0: model Synaptics Touchpad, device ID 0
>> battery0: <ACPI Control Method Battery> on acpi0
>> battery1: <ACPI Control Method Battery> on acpi0
>> acpi_acad0: <AC Adapter> on acpi0
>> orm0: <ISA Option ROM> at iomem 0xc0000-0xcffff pnpid ORM0000 on isa0
>> hwpstate_intel0: <Intel Speed Shift> on cpu0
>> hwpstate_intel1: <Intel Speed Shift> on cpu1
>> hwpstate_intel2: <Intel Speed Shift> on cpu2
>> hwpstate_intel3: <Intel Speed Shift> on cpu3
>> Timecounters tick every 1.000 msec
>> ZFS filesystem version: 5
>> ZFS storage pool version: features support (5000)
>> hdacc0: <Realtek ALC293 HDA CODEC> at cad 0 on hdac0
>> ugen0.1: <0x8086 XHCI root HUB> at usbus0
>> hdaa0: <Realtek ALC293 Audio Function Group> at nid 1 on hdacc0
>> pcm0: <Realtek ALC293 (Analog)> at nid 20 and 26 on hdaa0
>> pcm1: <Realtek ALC293 (Analog)> at nid 21 and 18 on hdaa0
>> hdacc1: <Intel Skylake HDA CODEC> at cad 2 on hdac0
>> hdaa1: <Intel Skylake Audio Function Group> at nid 1 on hdacc1
>> pcm2: <Intel Skylake (HDMI/DP 8ch)> at nid 3 on hdaa1
>> Trying to mount root from zfs:zroot/ROOT/default []...
>> Root mount waiting for: usbus0 CAM
>> WARNING: WITNESS option enabled, expect reduced performance.
>> uhub0 on usbus0
>> uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
>> ada0 at ahcich1 bus 0 scbus0 target 0 lun 0
>> ada0: <Samsung SSD 850 PRO 512GB EXM04B6Q> ACS-2 ATA SATA 3.x device
>> ada0: Serial Number S39FNX0J625463T
>> ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)
>> ada0: Command Queueing enabled
>> ada0: 488386MB (1000215216 512 byte sectors)
>> ada0: quirks=0x3<4K,NCQ_TRIM_BROKEN>
>> GEOM_ELI: Device ada0p4.eli created.
>> GEOM_ELI: Encryption: AES-XTS 256
>> GEOM_ELI:     Crypto: accelerated software
>> uhub0: 18 ports with 18 removable, self powered
>> Root mount waiting for: usbus0
>> ugen0.2: <Prolific Technology Inc. USB-Serial Controller> at usbus0
>> Root mount waiting for: usbus0
>> ugen0.3: <vendor 0x8087 product 0x0a2b> at usbus0
>> ugen0.4: <SunplusIT Inc Integrated Camera> at usbus0
>> Root mount waiting for: usbus0
>> ugen0.5: <vendor 0x138a product 0x0017> at usbus0
>> lo0: link state changed to UP
>> pchtherm0: <Skylake PCH Thermal Subsystem> mem 0xf424b000-0xf424bfff at device 20.2 on pci0
>> iwm0: <Intel(R) Dual Band Wireless AC 8260> mem 0xf4000000-0xf4001fff at device 0.0 on pci2
>> iwm0: hw rev 0x200, fw ver 22.361476.0, address f4:8c:50:50:22:83
>> ichsmb0: <Intel Sunrise Point-LP SMBus controller> port 0xefa0-0xefbf mem 0xf424e000-0xf424e0ff at device 31.4 on pci0
>> smbus0: <System Management Bus> on ichsmb0
>> acpi_wmi0: <ACPI-WMI mapping> on acpi0
>> acpi_wmi0: Embedded MOF found
>> ACPI: \134_SB.WMI1.WQBA: 1 arguments were passed to a non-method ACPI object (Buffer) (20201113/nsarguments-361)
>> acpi_wmi1: <ACPI-WMI mapping> on acpi0
>> acpi_wmi1: Embedded MOF found
>> ACPI: \134_SB.WMI2.WQBB: 1 arguments were passed to a non-method ACPI object (Buffer) (20201113/nsarguments-361)
>> acpi_wmi2: <ACPI-WMI mapping> on acpi0
>> acpi_wmi2: Embedded MOF found
>> ACPI: \134_SB.WMI3.WQBC: 1 arguments were passed to a non-method ACPI object (Buffer) (20201113/nsarguments-361)
>> uplcom0 on uhub0
>> uplcom0: <Prolific Technology Inc. USB-Serial Controller, class 0/0, rev 1.10/3.00, addr 1> on usbus0
>> wlan0: Ethernet address: f4:8c:50:50:22:83
>> ng_ubt: HCI command 0xfc05 timed out
>> ubt0 on uhub0
>> ubt0: <vendor 0x8087 product 0x0a2b, class 224/1, rev 2.00/0.01, addr 2> on usbus0
>> wlan0: link state changed to UP
>> WARNING: attempt to domain_add(bluetooth) after domainfinalize()
>> WARNING: attempt to domain_add(netgraph) after domainfinalize()
>> iwm0: code ce, frame 2/216 b800002c unhandled
>> Security policy loaded: MAC/ntpd (mac_ntpd)
>> 
>> _______________________________________________
>> freebsd-current at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
> 
> Hi.
> You would be bitten by a known issue with ThinkPad P50s described in
> rtsx (4) man page.
> 
> Try adding dev.rtsx.0.inversion=1 in /boot/loader.conf.

Thanks! I should have seen that?

I have added dev.rtsx.0.inversion=1 to /boot/loader.conf, and the machine does boot now.
However, It seems to hang a bit on boot with these messages:

rtsx0: Controller timeout for CMD8
rtsx0: Controller timeout for CMD8
rtsx0: Controller timeout for CMD8
rtsx0: Controller timeout for CMD8
rtsx0: Controller timeout for CMD8
rtsx0: Controller timeout for CMD55
rtsx0: Controller timeout for CMD55
rtsx0: Controller timeout for CMD55
rtsx0: Controller timeout for CMD55
rtsx0: Controller timeout for CMD1
rtsx0: Controller timeout for CMD1
rtsx0: Controller timeout for CMD1

And inserting and removing a card does give ?inverted? messages:

[insert cart]
rtsx0: Interrupt card inserted/removed
rtsx0: Card absent
mmc0: detached

[remove card]
rtsx0: Interrupt card inserted/removed
rtsx0: Card present
mmc0: <MMC/SD bus> on rtsx0
rtsx0: Controller timeout for CMD8

[insert card]
rtsx0: Interrupt card inserted/removed
rtsx0: Card absent
rtsx0: Controller timeout for CMD8
mmcsd0: 16GB <SDHC SD16G 3.0 SN 7C15F82F MFG 11/2015 by 39 PH> (read-only) at mmc0 50.0MHz/4bit/2048-block
mmcsd0: Error indicated: 4 Failed
mmc0: detached
g_dev_taste: g_dev_taste(mmcsd0) failed to g_attach, error=6

[remove card]
rtsx0: Interrupt card inserted/removed
rtsx0: Card present
mmc0: <MMC/SD bus> on rtsx0

rtsx0: Controller timeout for CMD8
rtsx0: Controller timeout for CMD8
rtsx0: Controller timeout for CMD8
rtsx0: Controller timeout for CMD8
rtsx0: Controller timeout for CMD8
rtsx0: Controller timeout for CMD55
rtsx0: Controller timeout for CMD55
rtsx0: Controller timeout for CMD55
rtsx0: Controller timeout for CMD55
rtsx0: Controller timeout for CMD1
rtsx0: Controller timeout for CMD1
rtsx0: Controller timeout for CMD1


> 
> Unfortunately, man pages for head cannot read via FreeBSD project top
> page. So read raw manpage data with svn commit mail archive below.
> 
> https://lists.freebsd.org/pipermail/svn-src-head/2020-November/141972.html
> 
> In addition, write attempts to write-protected card causes 100% panic.
> For example, sysutils/automount trys fsck on mount.
> This causes 100% panic (not only rtsx, but every adapters), avoidable
> by write-protect off.
> 
> 
> -- 
> Tomoaki AOKI    <junchoon at dec.sakura.ne.jp>


From m.e.sanliturk at gmail.com  Fri Dec 25 05:00:20 2020
From: m.e.sanliturk at gmail.com (Mehmet Erol Sanliturk)
Date: Fri, 25 Dec 2020 07:59:41 +0300
Subject: Is there any machine RISC-V implemented ?
In-Reply-To: <202012250043.0BP0hHUM017340@kx.truefc.org>
References: <202012250043.0BP0hHUM017340@kx.truefc.org>
Message-ID: <CAOgwaMtT0gy10hn64Gj0tmmixYxZNC1D2HGzwwYHqzRVKs093Q@mail.gmail.com>

On Fri, Dec 25, 2020 at 3:43 AM KIRIYAMA Kazuhiko <kiri at truefc.org> wrote:

> Hi, all
>
> I've found RISC-V images in snapshots/ISO-IMAGES. Is there
> any machine RISC-V implemented so far ?
> _______________________________________________
>
>



Please , search the following phrase in Google :


Is there any machine RISC-V implemented so far ?


 and , see

https://en.wikipedia.org/wiki/RISC-V
RISC-V




Mehmet Erol Sanliturk

From tuexen at freebsd.org  Fri Dec 25 10:38:04 2020
From: tuexen at freebsd.org (Michael Tuexen)
Date: Fri, 25 Dec 2020 11:37:57 +0100
Subject: Is there any machine RISC-V implemented ?
In-Reply-To: <202012250043.0BP0hHUM017340@kx.truefc.org>
References: <202012250043.0BP0hHUM017340@kx.truefc.org>
Message-ID: <5F83FABF-E6D4-46B4-8FC2-69558D757CB7@freebsd.org>

> On 25. Dec 2020, at 01:43, KIRIYAMA Kazuhiko <kiri at truefc.org> wrote:
> 
> Hi, all
> 
> I've found RISC-V images in snapshots/ISO-IMAGES. Is there
> any machine RISC-V implemented so far ?
You mind find some information you need at:
https://wiki.freebsd.org/riscv
Best regards
Michael
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"


From ludovit.koren at gmail.com  Fri Dec 25 13:40:18 2020
From: ludovit.koren at gmail.com (Ludovit Koren)
Date: Fri, 25 Dec 2020 14:40:13 +0100
Subject: (251866) installers for FreeBSD fail to boot HP EliteBook 830
 G7, 440 G7 =?utf-8?Q?=E2=80=A6?=
In-Reply-To: <36c65b46-58d9-9f03-9e31-d27cfb7a6dba@gmail.com> (Graham Perrin's
 message of "Sat, 19 Dec 2020 14:35:11 +0000")
References: <86360c9p2p.fsf@gmail.com>
 <8cd298fa-5b16-d58b-b63b-201905f83438@gmail.com>
 <8aa45f8c-7b14-a264-a8b7-9dd0b6b36f59@bsdio.com>
 <36c65b46-58d9-9f03-9e31-d27cfb7a6dba@gmail.com>
Message-ID: <86sg7u3sxu.fsf@gmail.com>

>>>>> Graham Perrin <grahamperrin at gmail.com> writes:

    > On 12/12/2020 19:18, Rebecca Cran wrote:
    >> On 12/11/2020 8:03 PM, Graham Perrin wrote:
    >>> On 11/12/2020 18:26, Ludovit Koren wrote:
    >>> 
    >>>> ?
    >>> Probably
    >>> <https://lists.freebsd.org/pipermail/freebsd-current/2020-December/077759.html>
    >> 
    >> This crash also happens on VMware Workstation 16 Pro with
    >> 13-CURRENT. I'm hoping to find some time to debug it.

    > Via <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251866>:

    > <https://svnweb.freebsd.org/base?view=revision&revision=368721>

    >> Drop EFI_STAGING_SIZE back down to 64M ?

FYI

FreeBSD-13.0-CURRENT-amd64-20201224-3cc0c0d66a0-255241-memstick.img
still not working on HP EliteBook 830 G7.

Regards,
lk

From grahamperrin at gmail.com  Fri Dec 25 14:53:46 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Fri, 25 Dec 2020 14:53:31 +0000
Subject: =?UTF-8?Q?=28251866=29_installers_for_FreeBSD_fail_to_boot_HP_Elite?=
 =?UTF-8?Q?Book_830_G7=2c_ProBook_440_G7_=e2=80=a6?=
In-Reply-To: <86sg7u3sxu.fsf@gmail.com>
References: <86360c9p2p.fsf@gmail.com>
 <8cd298fa-5b16-d58b-b63b-201905f83438@gmail.com>
 <8aa45f8c-7b14-a264-a8b7-9dd0b6b36f59@bsdio.com>
 <36c65b46-58d9-9f03-9e31-d27cfb7a6dba@gmail.com> <86sg7u3sxu.fsf@gmail.com>
Message-ID: <b1799898-44f8-67ee-ff61-b2d4c0f2fcb7@gmail.com>

On 25/12/2020 13:40, Ludovit Koren wrote:

> FreeBSD-13.0-CURRENT-amd64-20201224-3cc0c0d66a0-255241-memstick.img
> still not working on HP EliteBook 830 G7.


Thank you, is it still exactly as shown in the photograph below?

<https://i.imgur.com/RnocF9g.png>


From imp at bsdimp.com  Fri Dec 25 16:06:53 2020
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 25 Dec 2020 09:06:39 -0700
Subject: =?UTF-8?Q?Re=3A_=28251866=29_installers_for_FreeBSD_fail_to_boot_HP_?=
 =?UTF-8?Q?EliteBook_830_G7=2C_440_G7_=E2=80=A6?=
In-Reply-To: <86sg7u3sxu.fsf@gmail.com>
References: <86360c9p2p.fsf@gmail.com>
 <8cd298fa-5b16-d58b-b63b-201905f83438@gmail.com>
 <8aa45f8c-7b14-a264-a8b7-9dd0b6b36f59@bsdio.com>
 <36c65b46-58d9-9f03-9e31-d27cfb7a6dba@gmail.com>
 <86sg7u3sxu.fsf@gmail.com>
Message-ID: <CANCZdfrFOLza-+HAWGaq-KvY6rnxOYbc8oeE-sWEKkSp+Qn=Eg@mail.gmail.com>

On Fri, Dec 25, 2020, 6:40 AM Ludovit Koren <ludovit.koren at gmail.com> wrote:

> >>>>> Graham Perrin <grahamperrin at gmail.com> writes:
>
>     > On 12/12/2020 19:18, Rebecca Cran wrote:
>     >> On 12/11/2020 8:03 PM, Graham Perrin wrote:
>     >>> On 11/12/2020 18:26, Ludovit Koren wrote:
>     >>>
>     >>>> ?
>     >>> Probably
>     >>> <
> https://lists.freebsd.org/pipermail/freebsd-current/2020-December/077759.html
> >
>     >>
>     >> This crash also happens on VMware Workstation 16 Pro with
>     >> 13-CURRENT. I'm hoping to find some time to debug it.
>
>     > Via <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251866>:
>
>     > <https://svnweb.freebsd.org/base?view=revision&revision=368721>
>
>     >> Drop EFI_STAGING_SIZE back down to 64M ?
>
> FYI
>
> FreeBSD-13.0-CURRENT-amd64-20201224-3cc0c0d66a0-255241-memstick.img
> still not working on HP EliteBook 830 G7.
>


Guess I'm going to have actually think...

Warner

> Regards,
> lk
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>

From trashcan at ellael.org  Fri Dec 25 16:08:32 2020
From: trashcan at ellael.org (Michael Grimm)
Date: Fri, 25 Dec 2020 17:08:09 +0100
Subject: git and the loss of revision numbers
In-Reply-To: <X+S/2j1483wb+MgB@lorvorc.mips.inka.de>
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
 <X+S/2j1483wb+MgB@lorvorc.mips.inka.de>
Message-ID: <F2B9E471-0DAD-46B9-94FF-57AD700ECBB9@ellael.org>

Christian Weisgerber <naddy at mips.inka.de> wrote:
> 
> Michael Grimm:

>> Correct? If so I wonder how future security advisories and errata notices will be composed. Will there be a date of the commit besides its hash being reported? 
> 
> For over TWENTY YEARS, FreeBSD advisories have already contained
> the date when the problem was corrected, e.g.:

Ups, sorry for my fading memory ;-) I must have concentrated solely to the revision numbers and descriptions in order to find out whether to recompile or not.

> I think it is safe to assume that this practice will continue after
> the switch to Git.


Thanks to all who responded and helped me to understand what to expect. Pointing me to git-rev-list(1) has been very helpful.

I came to the conclusion that I will name my BE by date and time of latest pull before buildworld or buildkernel, e.g. 2025_0955. That will help me to make decision as mentioned above.

With kind regards,
Michael






From grahamperrin at gmail.com  Fri Dec 25 17:39:29 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Fri, 25 Dec 2020 17:39:23 +0000
Subject: SimpleScreenRecorder and audio
In-Reply-To: <618dadb1-43d1-ed39-cac9-66c8ea8b7455@gmail.com>
References: <20201214093838.Horde.7MCNPdaO93VFac3VZjMk0BW@webmail.leidinger.net>
 <2059585148.3686937.1607951705519.JavaMail.zimbra@schweikhardt.net>
 <X9dmt5AnTW1cWOr/@albert.catwhisker.org>
 <618dadb1-43d1-ed39-cac9-66c8ea8b7455@gmail.com>
Message-ID: <12462517-13cb-2fe0-5f87-e38fba0190e9@gmail.com>

On 16/12/2020 03:18, Graham Perrin wrote:

 > Re: Identifying broken applications following careless use of make 
-DBATCH_DELETE_OLD_FILES delete-old-libs

> ? ?Ultimately I chose to:
>
> pkg upgrade -f
>
> pkg upgrade -f -r poudriere
>
> ?
>
> As far as I can tell, just one casualty: SimpleScreenRecorder, which 
> does record and save, but fails to cancel (before beginning a 
> recording) or close (after saving a recording); it stops responding. ?


For the record: the issues with SimpleScreenRecorder were 
(coincidentally) due to me experimenting with virtual_oss without 
understanding some of the basics of audio in FreeBSD ?


From uqs at freebsd.org  Fri Dec 25 21:07:03 2020
From: uqs at freebsd.org (Ulrich =?utf-8?B?U3DDtnJsZWlu?=)
Date: Fri, 25 Dec 2020 22:06:51 +0100
Subject: src: continued use of Subversion for getting updates
In-Reply-To: <20201223143545.Wf_Ww%steffen@sdaoden.eu>
References: <E1ks2I6-0005nh-BQ@rmmprod05.runbox>
 <20201223143545.Wf_Ww%steffen@sdaoden.eu>
Message-ID: <X+ZUa7NyatH2ktYI@acme.spoerlein.net>

On Wed, 2020-12-23 at 15:35:45 +0100, Steffen Nurpmeso wrote:
>Jeffrey Bouquet wrote in
> <E1ks2I6-0005nh-BQ at rmmprod05.runbox>:
> |On Wed, 23 Dec 2020 11:13:07 +0100, Johan Hendriks <joh.hendriks at gmail.c\
> |om> wrote:
> |> On 23/12/2020 09:49, Warner Losh wrote:
> |>> On Wed, Dec 23, 2020, 1:48 AM Graham Perrin <grahamperrin at gmail.com> \
> |>> wrote:
> ...
> |> First of all a big thank you for all your time and effort you and all
> |> the other people put in this tremendous task.
>
>Yes, it is great to have FreeBSD as a stable git repository now,
>not only due to "gc --aggressive --prune=all" and the possibility
>to use (pseudo) bare repositories without checkouts, but also
>because of this.  Downloaded it today (from fresh), currently
>doing the mentioned command, but it may be it does not reduce that
>much :)
>
>I really dislike that vendor imports have been tagged.  Because
>there is only one tag namespace you cannot avoid getting all this
>cruft.  I mean, it is too late now, but one could have used
>per-vendor import branches and step them via "git rm -rf '*' &&
>tar -xf newball && git add . && git commit bla" or whatever, and
>then join them in.  It does not matter for those who have all the

That's basically what was done? I don't understand what you're saying 
here ...

>repository, but you decided to loose one of the strengts of git,
>selective tracking.  Also i think it causes updates to require
>more network traffic, i see this with the repos i have at
>repo.or.cz, the one with few heads/tags is minimal, the other
>requires hundreds of kilobytes just for the check that happens
>many times a day.  All these references have to be compared each
>and every time.  I think.  On the other hand, a few years back
>i accidentally "heard" a discussion about improving the network
>protocol and that "head" reference matching, iirc, so it may
>change in the future.

That's a valid point, we debated whether to keep vendor tags and decided 
for now to replicate what we have in SVN. We can still delete all the 
vendor tags on the main repo anytime we want ...

hth
Uli

From steffen at sdaoden.eu  Fri Dec 25 21:40:52 2020
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 25 Dec 2020 22:40:41 +0100
Subject: src: continued use of Subversion for getting updates
In-Reply-To: <X+ZUa7NyatH2ktYI@acme.spoerlein.net>
References: <E1ks2I6-0005nh-BQ@rmmprod05.runbox>
 <20201223143545.Wf_Ww%steffen@sdaoden.eu>
 <X+ZUa7NyatH2ktYI@acme.spoerlein.net>
Message-ID: <20201225214041.jVKMU%steffen@sdaoden.eu>

Ulrich Sp?rlein wrote in
 <X+ZUa7NyatH2ktYI at acme.spoerlein.net>:
 |On Wed, 2020-12-23 at 15:35:45 +0100, Steffen Nurpmeso wrote:
 |>Jeffrey Bouquet wrote in
 |> <E1ks2I6-0005nh-BQ at rmmprod05.runbox>:
 |>|On Wed, 23 Dec 2020 11:13:07 +0100, Johan Hendriks <joh.hendriks at gmail.c\
 |>|om> wrote:
 |>|> On 23/12/2020 09:49, Warner Losh wrote:
 |>|>> On Wed, Dec 23, 2020, 1:48 AM Graham Perrin <grahamperrin at gmail.com> \
 |>|>> wrote:
 |> ...
 |>|> First of all a big thank you for all your time and effort you and all
 |>|> the other people put in this tremendous task.
 |>
 |>Yes, it is great to have FreeBSD as a stable git repository now,
 ...
 |>I really dislike that vendor imports have been tagged.  Because
 |>there is only one tag namespace you cannot avoid getting all this
 |>cruft.  I mean, it is too late now, but one could have used
 |>per-vendor import branches and step them via "git rm -rf '*' &&
 |>tar -xf newball && git add . && git commit bla" or whatever, and
 |>then join them in.  It does not matter for those who have all the
 |
 |That's basically what was done? I don't understand what you're saying 
 |here ...

Well, cgit-beta did not have had all these tags if i recall
correctly, did it?  I mean it has been two months or so since
i last had it because "git fetch" bailed here due to the errors
that i have reported, and fetching more than a gigabyte for
brand-new fetches devastates here.

But i _think_ all the tags below refs/tags/vendor/ like

  vendor/wpa/2.9
  vendor/wpa_supplicant/0.3.8
  vendor/wpa_supplicant/0.5.10
  vendor/wpa_supplicant/0.5.11
  vendor/x86emu/4.6
  vendor/xe/1.13

etc. did not exist in cgit-beta?  I surely would have said
something once comments have been requested, wouldn't i?
The thing is if i do

  #?0|kent:free-src.git$ git ls-remote|wc -l
  From https://git.freebsd.org/src.git
  6814

This is a tremendous amount of head references that need to be
compared.

  #?0|kent:free-src.git$ cd ../net-src.git/
  #?0|kent:net-src.git$ git ls-remote|wc -l
  From https://github.com/NetBSD/src.git
  609
  #?0|kent:net-src.git$ cd ../open-src.git/
  #?0|kent:open-src.git$ git ls-remote|wc -l
  From https://github.com/openbsd/src.git
  34
  #?0|kent:open-src.git$ cd ../dfly-src.git/
  #?0|kent:dfly-src.git$ git ls-remote|wc -l
  From git://git.dragonflybsd.org/dragonfly.git
  349

Linux is a little bit more

  #?0|kent:linux.git$ git ls-remote|wc -l
  From https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
  7019

but this specific repository tracks all release candidates and all
the update releases, which alone go into the hundreds.

Anyhow, the difference is the number of local references that
effectively have to be compared against remote heads.  For example
my local Linux repo is this:

  [remote "origin"]
  url = https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
  fetch = +refs/heads/linux-4.19.y:refs/remotes/origin/linux-4.19.y
  fetch = +refs/heads/linux-5.10.y:refs/remotes/origin/linux-5.10.y
  fetch = +refs/heads/master:refs/remotes/origin/master

And if i "sr" (show-ref) i get:

  #?0|kent:linux.git$ git sr|wc -l
  925

which is a lot due to Linux update policy, but it only relates to
the project itself, there is not one reference of what is
effectively vendor data like for example

    Merge tag 'wireless-drivers-next-2020-12-12' of
    git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next

may it be in refs/tags or anywhere else, whereas with FreeBSD and

  [remote "origin"]
  url = https://git.freebsd.org/src.git
  fetch = +refs/heads/releng/5.5:refs/remotes/origin/releng/5.5
  fetch = +refs/heads/releng/6.4:refs/remotes/origin/releng/6.4
  fetch = +refs/heads/releng/7.4:refs/remotes/origin/releng/7.4
  fetch = +refs/heads/releng/8.4:refs/remotes/origin/releng/8.4
  fetch = +refs/heads/releng/9.3:refs/remotes/origin/releng/9.3
  fetch = +refs/heads/releng/10.3:refs/remotes/origin/releng/10.4
  fetch = +refs/heads/releng/11.4:refs/remotes/origin/releng/11.4
  fetch = +refs/heads/releng/12.2:refs/remotes/origin/releng/12.2
  fetch = +refs/heads/stable/12:refs/remotes/origin/stable/12
  fetch = +refs/heads/main:refs/remotes/origin/main

there is

  #?0|kent:free-src.git$ git sr|wc -l
  2137

but if i go for "the real" FreeBSD itself it is just

  #?0|kent:free-src.git$ git sr | grep -v vendor | wc -l
  19

namely

  a62107ed19a1095158f454132a3b6ec536a4de7c refs/remotes/origin/main
  8411c9ac24aabdbbde468778b35da58dc3c15178 refs/remotes/origin/releng/10.4
  4adbf1f6686ffdc4c0555a018e14ec63b5981534 refs/remotes/origin/releng/11.4
  2120d07af09cb830873554ba5405c5d3e51b41cc refs/remotes/origin/releng/12.2
  d4c364b3dcf6dfe4e20c70d31912aad7e6219c14 refs/remotes/origin/releng/5.5
  0df48150179039ce25e09b48c85aa39bffdbb4c4 refs/remotes/origin/releng/6.4
  1c7fe7463d0204f08806b9da6d5d50fb7f75c5ad refs/remotes/origin/releng/7.4
  554a1309dbd71bb59ed4e97ea5e0bc829dad0f04 refs/remotes/origin/releng/8.4
  b06b7e647fe7b4eefbd29369cf0c24e1902bf72a refs/remotes/origin/releng/9.3
  f4d0bc6aa6b90cbb0ea6cb993d9a10e36f5f4a4c refs/remotes/origin/stable/12
  aed278eb8da79777d64e06bbc94ee0a018885477 refs/tags/release/10.3.0
  20dbcb9a99d5c4b8ceb4897f27c53ab9fb853167 refs/tags/release/11.4.0
  906434f95e83f03e0ac62d2544dad1656b5df1e9 refs/tags/release/12.2.0
  1185954e6d623ada4ef32f25687ecd5e5c003545 refs/tags/release/5.5.0
  44b4768239e96f6d6ba8a43cb2542e1bc83dec94 refs/tags/release/6.4.0
  c31c07d1a9283bd28bb00ce519dfca69e529f452 refs/tags/release/7.4.0
  174c77559c8cc317c743876f55f02bec233735f4 refs/tags/release/8.1.0
  45cf4d6a59488ea4113bde749bb61de33882cc46 refs/tags/release/8.4.0
  1fb916120b12fdc14c7f93aa5f14849db0efa166 refs/tags/release/9.3.0

and thus

  #?0|kent:free-src.git$ git sr | grep vendor | wc -l
  2118

Which is a pity since all these references will be checked during
"git fetch" unless i am mistaken.

 |>repository, but you decided to loose one of the strengts of git,
 |>selective tracking.  Also i think it causes updates to require
 |>more network traffic, i see this with the repos i have at
 |>repo.or.cz, the one with few heads/tags is minimal, the other
 |>requires hundreds of kilobytes just for the check that happens
 |>many times a day.  All these references have to be compared each
 |>and every time.  I think.  On the other hand, a few years back
 |>i accidentally "heard" a discussion about improving the network
 |>protocol and that "head" reference matching, iirc, so it may
 |>change in the future.
 |
 |That's a valid point, we debated whether to keep vendor tags and decided 
 |for now to replicate what we have in SVN. We can still delete all the 
 |vendor tags on the main repo anytime we want ...

I personally would track that in the commit message of the import
on the vendor branch that anyway exists(!), and then when merging
this into the mainline, but not create a real tag in the tag
namespace.  Also the backups/ and such, because why?

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From imp at bsdimp.com  Fri Dec 25 22:07:50 2020
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 25 Dec 2020 15:07:37 -0700
Subject: src: continued use of Subversion for getting updates
In-Reply-To: <20201225214041.jVKMU%steffen@sdaoden.eu>
References: <E1ks2I6-0005nh-BQ@rmmprod05.runbox>
 <20201223143545.Wf_Ww%steffen@sdaoden.eu>
 <X+ZUa7NyatH2ktYI@acme.spoerlein.net>
 <20201225214041.jVKMU%steffen@sdaoden.eu>
Message-ID: <CANCZdfpgFUFzW3b_c2sa1zYcuNFjrBw_mtkCzT4_D5tajXCkXA@mail.gmail.com>

On Fri, Dec 25, 2020 at 2:41 PM Steffen Nurpmeso <steffen at sdaoden.eu> wrote:

> Ulrich Sp?rlein wrote in
>  <X+ZUa7NyatH2ktYI at acme.spoerlein.net>:
>  |On Wed, 2020-12-23 at 15:35:45 +0100, Steffen Nurpmeso wrote:
>  |>Jeffrey Bouquet wrote in
>  |> <E1ks2I6-0005nh-BQ at rmmprod05.runbox>:
>  |>|On Wed, 23 Dec 2020 11:13:07 +0100, Johan Hendriks
> <joh.hendriks at gmail.c\
>  |>|om> wrote:
>  |>|> On 23/12/2020 09:49, Warner Losh wrote:
>  |>|>> On Wed, Dec 23, 2020, 1:48 AM Graham Perrin <grahamperrin at gmail.com>
> \
>  |>|>> wrote:
>  |> ...
>  |>|> First of all a big thank you for all your time and effort you and all
>  |>|> the other people put in this tremendous task.
>  |>
>  |>Yes, it is great to have FreeBSD as a stable git repository now,
>  ...
>  |>I really dislike that vendor imports have been tagged.  Because
>  |>there is only one tag namespace you cannot avoid getting all this
>  |>cruft.  I mean, it is too late now, but one could have used
>  |>per-vendor import branches and step them via "git rm -rf '*' &&
>  |>tar -xf newball && git add . && git commit bla" or whatever, and
>  |>then join them in.  It does not matter for those who have all the
>  |
>  |That's basically what was done? I don't understand what you're saying
>  |here ...
>
> Well, cgit-beta did not have had all these tags if i recall
> correctly, did it?  I mean it has been two months or so since
> i last had it because "git fetch" bailed here due to the errors
> that i have reported, and fetching more than a gigabyte for
> brand-new fetches devastates here.
>

It had them, but not under the refs/head/vendor space but under the
refs/vendor space.

The multiple gigabyte fetch is because we changed the hashes two or three
times in the last few months.

But i _think_ all the tags below refs/tags/vendor/ like
>
>   vendor/wpa/2.9
>   vendor/wpa_supplicant/0.3.8
>   vendor/wpa_supplicant/0.5.10
>   vendor/wpa_supplicant/0.5.11
>   vendor/x86emu/4.6
>   vendor/xe/1.13
>
> etc. did not exist in cgit-beta?  I surely would have said
> something once comments have been requested, wouldn't i?
>

They did exist. They were under refs/vendor rather than refs/head/vendor
though.


> The thing is if i do
>
>   #?0|kent:free-src.git$ git ls-remote|wc -l
>   From https://git.freebsd.org/src.git
>   6814
>
> This is a tremendous amount of head references that need to be
> compared.
>
>   #?0|kent:free-src.git$ cd ../net-src.git/
>   #?0|kent:net-src.git$ git ls-remote|wc -l
>   From https://github.com/NetBSD/src.git
>   609
>   #?0|kent:net-src.git$ cd ../open-src.git/
>   #?0|kent:open-src.git$ git ls-remote|wc -l
>   From https://github.com/openbsd/src.git
>

  34
>



>   #?0|kent:open-src.git$ cd ../dfly-src.git/
>   #?0|kent:dfly-src.git$ git ls-remote|wc -l
>   From git://git.dragonflybsd.org/dragonfly.git
>   349
>

You can twek


> Linux is a little bit more
>
>   #?0|kent:linux.git$ git ls-remote|wc -l
>   From https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
>   7019
>
> but this specific repository tracks all release candidates and all
> the update releases, which alone go into the hundreds.
>
> Anyhow, the difference is the number of local references that
> effectively have to be compared against remote heads.  For example
> my local Linux repo is this:
>
>   [remote "origin"]
>   url = https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
>   fetch = +refs/heads/linux-4.19.y:refs/remotes/origin/linux-4.19.y
>   fetch = +refs/heads/linux-5.10.y:refs/remotes/origin/linux-5.10.y
>   fetch = +refs/heads/master:refs/remotes/origin/master
>
> And if i "sr" (show-ref) i get:
>
>   #?0|kent:linux.git$ git sr|wc -l
>   925
>
> which is a lot due to Linux update policy, but it only relates to
> the project itself, there is not one reference of what is
> effectively vendor data like for example
>
>     Merge tag 'wireless-drivers-next-2020-12-12' of
>     git://
> git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
>
> may it be in refs/tags or anywhere else, whereas with FreeBSD and
>
>   [remote "origin"]
>   url = https://git.freebsd.org/src.git
>   fetch = +refs/heads/releng/5.5:refs/remotes/origin/releng/5.5
>   fetch = +refs/heads/releng/6.4:refs/remotes/origin/releng/6.4
>   fetch = +refs/heads/releng/7.4:refs/remotes/origin/releng/7.4
>   fetch = +refs/heads/releng/8.4:refs/remotes/origin/releng/8.4
>   fetch = +refs/heads/releng/9.3:refs/remotes/origin/releng/9.3
>   fetch = +refs/heads/releng/10.3:refs/remotes/origin/releng/10.4
>   fetch = +refs/heads/releng/11.4:refs/remotes/origin/releng/11.4
>   fetch = +refs/heads/releng/12.2:refs/remotes/origin/releng/12.2
>   fetch = +refs/heads/stable/12:refs/remotes/origin/stable/12
>   fetch = +refs/heads/main:refs/remotes/origin/main
>
> there is
>
>   #?0|kent:free-src.git$ git sr|wc -l
>   2137
>
> but if i go for "the real" FreeBSD itself it is just
>
>   #?0|kent:free-src.git$ git sr | grep -v vendor | wc -l
>   19
>
> namely
>
>   a62107ed19a1095158f454132a3b6ec536a4de7c refs/remotes/origin/main
>   8411c9ac24aabdbbde468778b35da58dc3c15178 refs/remotes/origin/releng/10.4
>   4adbf1f6686ffdc4c0555a018e14ec63b5981534 refs/remotes/origin/releng/11.4
>   2120d07af09cb830873554ba5405c5d3e51b41cc refs/remotes/origin/releng/12.2
>   d4c364b3dcf6dfe4e20c70d31912aad7e6219c14 refs/remotes/origin/releng/5.5
>   0df48150179039ce25e09b48c85aa39bffdbb4c4 refs/remotes/origin/releng/6.4
>   1c7fe7463d0204f08806b9da6d5d50fb7f75c5ad refs/remotes/origin/releng/7.4
>   554a1309dbd71bb59ed4e97ea5e0bc829dad0f04 refs/remotes/origin/releng/8.4
>   b06b7e647fe7b4eefbd29369cf0c24e1902bf72a refs/remotes/origin/releng/9.3
>   f4d0bc6aa6b90cbb0ea6cb993d9a10e36f5f4a4c refs/remotes/origin/stable/12
>   aed278eb8da79777d64e06bbc94ee0a018885477 refs/tags/release/10.3.0
>   20dbcb9a99d5c4b8ceb4897f27c53ab9fb853167 refs/tags/release/11.4.0
>   906434f95e83f03e0ac62d2544dad1656b5df1e9 refs/tags/release/12.2.0
>   1185954e6d623ada4ef32f25687ecd5e5c003545 refs/tags/release/5.5.0
>   44b4768239e96f6d6ba8a43cb2542e1bc83dec94 refs/tags/release/6.4.0
>   c31c07d1a9283bd28bb00ce519dfca69e529f452 refs/tags/release/7.4.0
>   174c77559c8cc317c743876f55f02bec233735f4 refs/tags/release/8.1.0
>   45cf4d6a59488ea4113bde749bb61de33882cc46 refs/tags/release/8.4.0
>   1fb916120b12fdc14c7f93aa5f14849db0efa166 refs/tags/release/9.3.0
>
> and thus
>
>   #?0|kent:free-src.git$ git sr | grep vendor | wc -l
>   2118
>
> Which is a pity since all these references will be checked during
> "git fetch" unless i am mistaken.
>
>  |>repository, but you decided to loose one of the strengts of git,
>  |>selective tracking.  Also i think it causes updates to require
>  |>more network traffic, i see this with the repos i have at
>  |>repo.or.cz, the one with few heads/tags is minimal, the other
>  |>requires hundreds of kilobytes just for the check that happens
>  |>many times a day.  All these references have to be compared each
>  |>and every time.  I think.  On the other hand, a few years back
>  |>i accidentally "heard" a discussion about improving the network
>  |>protocol and that "head" reference matching, iirc, so it may
>  |>change in the future.
>  |
>  |That's a valid point, we debated whether to keep vendor tags and decided
>  |for now to replicate what we have in SVN. We can still delete all the
>  |vendor tags on the main repo anytime we want ...
>
> I personally would track that in the commit message of the import
> on the vendor branch that anyway exists(!), and then when merging
> this into the mainline, but not create a real tag in the tag
> namespace.  Also the backups/ and such, because why?
>
> --steffen
> |
> |Der Kragenbaer,                The moon bear,
> |der holt sich munter           he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>

From imp at bsdimp.com  Fri Dec 25 22:11:36 2020
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 25 Dec 2020 15:11:23 -0700
Subject: src: continued use of Subversion for getting updates
In-Reply-To: <CANCZdfpgFUFzW3b_c2sa1zYcuNFjrBw_mtkCzT4_D5tajXCkXA@mail.gmail.com>
References: <E1ks2I6-0005nh-BQ@rmmprod05.runbox>
 <20201223143545.Wf_Ww%steffen@sdaoden.eu>
 <X+ZUa7NyatH2ktYI@acme.spoerlein.net>
 <20201225214041.jVKMU%steffen@sdaoden.eu>
 <CANCZdfpgFUFzW3b_c2sa1zYcuNFjrBw_mtkCzT4_D5tajXCkXA@mail.gmail.com>
Message-ID: <CANCZdfpNM19OyQtXH0OLHxzrQf4dqpBcRZzfBCuKfRyo5Wcziw@mail.gmail.com>

[[ stupid gmail sent this too fast :( ]]

On Fri, Dec 25, 2020 at 3:07 PM Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Fri, Dec 25, 2020 at 2:41 PM Steffen Nurpmeso <steffen at sdaoden.eu>
> wrote:
>
>> Ulrich Sp?rlein wrote in
>>  <X+ZUa7NyatH2ktYI at acme.spoerlein.net>:
>>  |On Wed, 2020-12-23 at 15:35:45 +0100, Steffen Nurpmeso wrote:
>>  |>Jeffrey Bouquet wrote in
>>  |> <E1ks2I6-0005nh-BQ at rmmprod05.runbox>:
>>  |>|On Wed, 23 Dec 2020 11:13:07 +0100, Johan Hendriks
>> <joh.hendriks at gmail.c\
>>  |>|om> wrote:
>>  |>|> On 23/12/2020 09:49, Warner Losh wrote:
>>  |>|>> On Wed, Dec 23, 2020, 1:48 AM Graham Perrin <
>> grahamperrin at gmail.com> \
>>  |>|>> wrote:
>>  |> ...
>>  |>|> First of all a big thank you for all your time and effort you and
>> all
>>  |>|> the other people put in this tremendous task.
>>  |>
>>  |>Yes, it is great to have FreeBSD as a stable git repository now,
>>  ...
>>  |>I really dislike that vendor imports have been tagged.  Because
>>  |>there is only one tag namespace you cannot avoid getting all this
>>  |>cruft.  I mean, it is too late now, but one could have used
>>  |>per-vendor import branches and step them via "git rm -rf '*' &&
>>  |>tar -xf newball && git add . && git commit bla" or whatever, and
>>  |>then join them in.  It does not matter for those who have all the
>>  |
>>  |That's basically what was done? I don't understand what you're saying
>>  |here ...
>>
>> Well, cgit-beta did not have had all these tags if i recall
>> correctly, did it?  I mean it has been two months or so since
>> i last had it because "git fetch" bailed here due to the errors
>> that i have reported, and fetching more than a gigabyte for
>> brand-new fetches devastates here.
>>
>
> It had them, but not under the refs/head/vendor space but under the
> refs/vendor space.
>
> The multiple gigabyte fetch is because we changed the hashes two or three
> times in the last few months.
>
> But i _think_ all the tags below refs/tags/vendor/ like
>>
>>   vendor/wpa/2.9
>>   vendor/wpa_supplicant/0.3.8
>>   vendor/wpa_supplicant/0.5.10
>>   vendor/wpa_supplicant/0.5.11
>>   vendor/x86emu/4.6
>>   vendor/xe/1.13
>>
>> etc. did not exist in cgit-beta?  I surely would have said
>> something once comments have been requested, wouldn't i?
>>
>
> They did exist. They were under refs/vendor rather than refs/head/vendor
> though.
>
>
>> The thing is if i do
>>
>>   #?0|kent:free-src.git$ git ls-remote|wc -l
>>   From https://git.freebsd.org/src.git
>>   6814
>>
>> This is a tremendous amount of head references that need to be
>> compared.
>>
>>   #?0|kent:free-src.git$ cd ../net-src.git/
>>   #?0|kent:net-src.git$ git ls-remote|wc -l
>>   From https://github.com/NetBSD/src.git
>>   609
>>   #?0|kent:net-src.git$ cd ../open-src.git/
>>   #?0|kent:open-src.git$ git ls-remote|wc -l
>>   From https://github.com/openbsd/src.git
>>
>
>   34
>
>
These are both artificial repos, that are export-only views.


>   #?0|kent:open-src.git$ cd ../dfly-src.git/
>>   #?0|kent:dfly-src.git$ git ls-remote|wc -l
>>   From git://git.dragonflybsd.org/dragonfly.git
>>   349
>>
>
> You can twek
>

You can tweak the default refs that you pull to pull less.


> Linux is a little bit more
>>
>>   #?0|kent:linux.git$ git ls-remote|wc -l
>>   From https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
>>   7019
>>
>> but this specific repository tracks all release candidates and all
>> the update releases, which alone go into the hundreds.
>>
>> Anyhow, the difference is the number of local references that
>> effectively have to be compared against remote heads.  For example
>> my local Linux repo is this:
>>
>>   [remote "origin"]
>>   url = https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
>>   fetch = +refs/heads/linux-4.19.y:refs/remotes/origin/linux-4.19.y
>>   fetch = +refs/heads/linux-5.10.y:refs/remotes/origin/linux-5.10.y
>>   fetch = +refs/heads/master:refs/remotes/origin/master
>>
>> And if i "sr" (show-ref) i get:
>>
>>   #?0|kent:linux.git$ git sr|wc -l
>>   925
>>
>> which is a lot due to Linux update policy, but it only relates to
>> the project itself, there is not one reference of what is
>> effectively vendor data like for example
>>
>>     Merge tag 'wireless-drivers-next-2020-12-12' of
>>     git://
>> git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
>>
>> may it be in refs/tags or anywhere else, whereas with FreeBSD and
>>
>>   [remote "origin"]
>>   url = https://git.freebsd.org/src.git
>>   fetch = +refs/heads/releng/5.5:refs/remotes/origin/releng/5.5
>>   fetch = +refs/heads/releng/6.4:refs/remotes/origin/releng/6.4
>>   fetch = +refs/heads/releng/7.4:refs/remotes/origin/releng/7.4
>>   fetch = +refs/heads/releng/8.4:refs/remotes/origin/releng/8.4
>>   fetch = +refs/heads/releng/9.3:refs/remotes/origin/releng/9.3
>>   fetch = +refs/heads/releng/10.3:refs/remotes/origin/releng/10.4
>>   fetch = +refs/heads/releng/11.4:refs/remotes/origin/releng/11.4
>>   fetch = +refs/heads/releng/12.2:refs/remotes/origin/releng/12.2
>>   fetch = +refs/heads/stable/12:refs/remotes/origin/stable/12
>>   fetch = +refs/heads/main:refs/remotes/origin/main
>>
>> there is
>>
>>   #?0|kent:free-src.git$ git sr|wc -l
>>   2137
>>
>> but if i go for "the real" FreeBSD itself it is just
>>
>>   #?0|kent:free-src.git$ git sr | grep -v vendor | wc -l
>>   19
>>
>
You might be happier tracking on github, once we start pushing there as the
vendor branches won't be published there.


> namely
>>
>>   a62107ed19a1095158f454132a3b6ec536a4de7c refs/remotes/origin/main
>>   8411c9ac24aabdbbde468778b35da58dc3c15178 refs/remotes/origin/releng/10.4
>>   4adbf1f6686ffdc4c0555a018e14ec63b5981534 refs/remotes/origin/releng/11.4
>>   2120d07af09cb830873554ba5405c5d3e51b41cc refs/remotes/origin/releng/12.2
>>   d4c364b3dcf6dfe4e20c70d31912aad7e6219c14 refs/remotes/origin/releng/5.5
>>   0df48150179039ce25e09b48c85aa39bffdbb4c4 refs/remotes/origin/releng/6.4
>>   1c7fe7463d0204f08806b9da6d5d50fb7f75c5ad refs/remotes/origin/releng/7.4
>>   554a1309dbd71bb59ed4e97ea5e0bc829dad0f04 refs/remotes/origin/releng/8.4
>>   b06b7e647fe7b4eefbd29369cf0c24e1902bf72a refs/remotes/origin/releng/9.3
>>   f4d0bc6aa6b90cbb0ea6cb993d9a10e36f5f4a4c refs/remotes/origin/stable/12
>>   aed278eb8da79777d64e06bbc94ee0a018885477 refs/tags/release/10.3.0
>>   20dbcb9a99d5c4b8ceb4897f27c53ab9fb853167 refs/tags/release/11.4.0
>>   906434f95e83f03e0ac62d2544dad1656b5df1e9 refs/tags/release/12.2.0
>>   1185954e6d623ada4ef32f25687ecd5e5c003545 refs/tags/release/5.5.0
>>   44b4768239e96f6d6ba8a43cb2542e1bc83dec94 refs/tags/release/6.4.0
>>   c31c07d1a9283bd28bb00ce519dfca69e529f452 refs/tags/release/7.4.0
>>   174c77559c8cc317c743876f55f02bec233735f4 refs/tags/release/8.1.0
>>   45cf4d6a59488ea4113bde749bb61de33882cc46 refs/tags/release/8.4.0
>>   1fb916120b12fdc14c7f93aa5f14849db0efa166 refs/tags/release/9.3.0
>>
>> and thus
>>
>>   #?0|kent:free-src.git$ git sr | grep vendor | wc -l
>>   2118
>>
>> Which is a pity since all these references will be checked during
>> "git fetch" unless i am mistaken.
>
>
Yes.  So far it's been doing it quite quickly for me, but I'm decently
connected...

 |>repository, but you decided to loose one of the strengts of git,
>>  |>selective tracking.  Also i think it causes updates to require
>>  |>more network traffic, i see this with the repos i have at
>>  |>repo.or.cz, the one with few heads/tags is minimal, the other
>>  |>requires hundreds of kilobytes just for the check that happens
>>  |>many times a day.  All these references have to be compared each
>>  |>and every time.  I think.  On the other hand, a few years back
>>  |>i accidentally "heard" a discussion about improving the network
>>  |>protocol and that "head" reference matching, iirc, so it may
>>  |>change in the future.
>>  |
>>  |That's a valid point, we debated whether to keep vendor tags and
>> decided
>>  |for now to replicate what we have in SVN. We can still delete all the
>>  |vendor tags on the main repo anytime we want ...
>>
>> I personally would track that in the commit message of the import
>> on the vendor branch that anyway exists(!), and then when merging
>> this into the mainline, but not create a real tag in the tag
>> namespace.  Also the backups/ and such, because why?
>>
>
We need tags to keep track of what's been done, and to revert and do other
management things with vendor imports.

Warner

From steffen at sdaoden.eu  Fri Dec 25 22:25:12 2020
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 25 Dec 2020 23:25:10 +0100
Subject: src: continued use of Subversion for getting updates
In-Reply-To: <CANCZdfpNM19OyQtXH0OLHxzrQf4dqpBcRZzfBCuKfRyo5Wcziw@mail.gmail.com>
References: <E1ks2I6-0005nh-BQ@rmmprod05.runbox>
 <20201223143545.Wf_Ww%steffen@sdaoden.eu>
 <X+ZUa7NyatH2ktYI@acme.spoerlein.net>
 <20201225214041.jVKMU%steffen@sdaoden.eu>
 <CANCZdfpgFUFzW3b_c2sa1zYcuNFjrBw_mtkCzT4_D5tajXCkXA@mail.gmail.com>
 <CANCZdfpNM19OyQtXH0OLHxzrQf4dqpBcRZzfBCuKfRyo5Wcziw@mail.gmail.com>
Message-ID: <20201225222510.JyYwH%steffen@sdaoden.eu>

Warner Losh wrote in
 <CANCZdfpNM19OyQtXH0OLHxzrQf4dqpBcRZzfBCuKfRyo5Wcziw at mail.gmail.com>:
 |> On Fri, Dec 25, 2020 at 2:41 PM Steffen Nurpmeso <steffen at sdaoden.eu>
 |> wrote:
 |>> Ulrich Sp?rlein wrote in
 |>>  <X+ZUa7NyatH2ktYI at acme.spoerlein.net>:
 |>>|On Wed, 2020-12-23 at 15:35:45 +0100, Steffen Nurpmeso wrote:
 |>>|>Jeffrey Bouquet wrote in
 |>>|> <E1ks2I6-0005nh-BQ at rmmprod05.runbox>:
 |>>|>|On Wed, 23 Dec 2020 11:13:07 +0100, Johan Hendriks
 |>> <joh.hendriks at gmail.c\
 |>>|>|om> wrote:
 |>>|>|> On 23/12/2020 09:49, Warner Losh wrote:
 |>>|>|>> On Wed, Dec 23, 2020, 1:48 AM Graham Perrin <
 |>> grahamperrin at gmail.com> \
 |>>|>|>> wrote:
 |>>|> ...
 |>>|>|> First of all a big thank you for all your time and effort you and
 |>> all
 |>>|>|> the other people put in this tremendous task.
 |>>|>
 |>>|>Yes, it is great to have FreeBSD as a stable git repository now,
 |>>  ...
 |>>|>I really dislike that vendor imports have been tagged.  Because
 |>>|>there is only one tag namespace you cannot avoid getting all this
 |>>|>cruft.  I mean, it is too late now, but one could have used
 ...
 |>>|That's basically what was done? I don't understand what you're saying
 |>>|here ...
 |>>
 |>> Well, cgit-beta did not have had all these tags if i recall
 |>> correctly, did it?  I mean it has been two months or so since
 |>> i last had it because "git fetch" bailed here due to the errors
 |>> that i have reported, and fetching more than a gigabyte for
 |>> brand-new fetches devastates here.
 |>
 |> It had them, but not under the refs/head/vendor space but under the
 |> refs/vendor space.

These are not tags but branches.  I have nothing against the
branches, of course.  Only the tags are the problem.

 |> The multiple gigabyte fetch is because we changed the hashes two or three
 |> times in the last few months.

Yes i know.  No problem (well, for me, of course), i tried it at
least once more by the end of November, but the server did not
finish my request (the simple "git fetch" in a non-clean repo).

 |> But i _think_ all the tags below refs/tags/vendor/ like
 |>>
 |>>   vendor/wpa/2.9
 |>>   vendor/wpa_supplicant/0.3.8
 |>>   vendor/wpa_supplicant/0.5.10
 |>>   vendor/wpa_supplicant/0.5.11
 |>>   vendor/x86emu/4.6
 |>>   vendor/xe/1.13
 |>>
 |>> etc. did not exist in cgit-beta?  I surely would have said
 |>> something once comments have been requested, wouldn't i?
 |>
 |> They did exist. They were under refs/vendor rather than refs/head/vendor
 |> though.

Under refs/tags/vendor?  refs/tags/ is the "special" namespace
managed by "git tag", this is different than the rest.

 |>> The thing is if i do
 |>>
 |>>   #?0|kent:free-src.git$ git ls-remote|wc -l
 |>>   From https://git.freebsd.org/src.git
 |>>   6814
 |>>
 |>> This is a tremendous amount of head references that need to be
 |>> compared.
 ...
 |>> there is
 |>>
 |>>   #?0|kent:free-src.git$ git sr|wc -l
 |>>   2137
 |>>
 |>> but if i go for "the real" FreeBSD itself it is just
 |>>
 |>>   #?0|kent:free-src.git$ git sr | grep -v vendor | wc -l
 |>>   19
 |>
 |You might be happier tracking on github, once we start pushing there as the
 |vendor branches won't be published there.

No problem with any number of branches, Warner.  Just tags under
refs/tags this is above.

  ...
 |>> and thus
 |>>
 |>>   #?0|kent:free-src.git$ git sr | grep vendor | wc -l
 |>>   2118
 |>>
 |>> Which is a pity since all these references will be checked during
 |>> "git fetch" unless i am mistaken.
 |>
 |Yes.  So far it's been doing it quite quickly for me, but I'm decently
 |connected...

Yes, terrible here, shared with many.

  ...
 |>>|That's a valid point, we debated whether to keep vendor tags and
 |>> decided
 |>>|for now to replicate what we have in SVN. We can still delete all the
 |>>|vendor tags on the main repo anytime we want ...
 |>>
 |>> I personally would track that in the commit message of the import
 |>> on the vendor branch that anyway exists(!), and then when merging
 |>> this into the mainline, but not create a real tag in the tag
 |>> namespace.  Also the backups/ and such, because why?
 |>
 |We need tags to keep track of what's been done, and to revert and do other
 |management things with vendor imports.

But why?  You have the commit on a topic/vendor branch, and you
revert nothing but the commit.  In fact doing so messes the tag,
it has to be retagged when you do re-commit an import proper,
which requires a forced push even!

Ciao,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From imp at bsdimp.com  Fri Dec 25 22:44:15 2020
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 25 Dec 2020 15:44:01 -0700
Subject: src: continued use of Subversion for getting updates
In-Reply-To: <20201225222510.JyYwH%steffen@sdaoden.eu>
References: <E1ks2I6-0005nh-BQ@rmmprod05.runbox>
 <20201223143545.Wf_Ww%steffen@sdaoden.eu>
 <X+ZUa7NyatH2ktYI@acme.spoerlein.net>
 <20201225214041.jVKMU%steffen@sdaoden.eu>
 <CANCZdfpgFUFzW3b_c2sa1zYcuNFjrBw_mtkCzT4_D5tajXCkXA@mail.gmail.com>
 <CANCZdfpNM19OyQtXH0OLHxzrQf4dqpBcRZzfBCuKfRyo5Wcziw@mail.gmail.com>
 <20201225222510.JyYwH%steffen@sdaoden.eu>
Message-ID: <CANCZdfpidSxN-3fqWC8z=9ANytzF9y9WcgmEejGTsihfa-Pr-Q@mail.gmail.com>

On Fri, Dec 25, 2020 at 3:25 PM Steffen Nurpmeso <steffen at sdaoden.eu> wrote:

> Warner Losh wrote in
>  <CANCZdfpNM19OyQtXH0OLHxzrQf4dqpBcRZzfBCuKfRyo5Wcziw at mail.gmail.com>:
>  |> On Fri, Dec 25, 2020 at 2:41 PM Steffen Nurpmeso <steffen at sdaoden.eu>
>  |> wrote:
>  |>> Ulrich Sp?rlein wrote in
>  |>>  <X+ZUa7NyatH2ktYI at acme.spoerlein.net>:
>  |>>|On Wed, 2020-12-23 at 15:35:45 +0100, Steffen Nurpmeso wrote:
>  |>>|>Jeffrey Bouquet wrote in
>  |>>|> <E1ks2I6-0005nh-BQ at rmmprod05.runbox>:
>  |>>|>|On Wed, 23 Dec 2020 11:13:07 +0100, Johan Hendriks
>  |>> <joh.hendriks at gmail.c\
>  |>>|>|om> wrote:
>  |>>|>|> On 23/12/2020 09:49, Warner Losh wrote:
>  |>>|>|>> On Wed, Dec 23, 2020, 1:48 AM Graham Perrin <
>  |>> grahamperrin at gmail.com> \
>  |>>|>|>> wrote:
>  |>>|> ...
>  |>>|>|> First of all a big thank you for all your time and effort you and
>  |>> all
>  |>>|>|> the other people put in this tremendous task.
>  |>>|>
>  |>>|>Yes, it is great to have FreeBSD as a stable git repository now,
>  |>>  ...
>  |>>|>I really dislike that vendor imports have been tagged.  Because
>  |>>|>there is only one tag namespace you cannot avoid getting all this
>  |>>|>cruft.  I mean, it is too late now, but one could have used
>  ...
>  |>>|That's basically what was done? I don't understand what you're saying
>  |>>|here ...
>  |>>
>  |>> Well, cgit-beta did not have had all these tags if i recall
>  |>> correctly, did it?  I mean it has been two months or so since
>  |>> i last had it because "git fetch" bailed here due to the errors
>  |>> that i have reported, and fetching more than a gigabyte for
>  |>> brand-new fetches devastates here.
>  |>
>  |> It had them, but not under the refs/head/vendor space but under the
>  |> refs/vendor space.
>
> These are not tags but branches.  I have nothing against the
> branches, of course.  Only the tags are the problem.
>
>  |> The multiple gigabyte fetch is because we changed the hashes two or
> three
>  |> times in the last few months.
>
> Yes i know.  No problem (well, for me, of course), i tried it at
> least once more by the end of November, but the server did not
> finish my request (the simple "git fetch" in a non-clean repo).
>
>  |> But i _think_ all the tags below refs/tags/vendor/ like
>  |>>
>  |>>   vendor/wpa/2.9
>  |>>   vendor/wpa_supplicant/0.3.8
>  |>>   vendor/wpa_supplicant/0.5.10
>  |>>   vendor/wpa_supplicant/0.5.11
>  |>>   vendor/x86emu/4.6
>  |>>   vendor/xe/1.13
>  |>>
>  |>> etc. did not exist in cgit-beta?  I surely would have said
>  |>> something once comments have been requested, wouldn't i?
>  |>
>  |> They did exist. They were under refs/vendor rather than
> refs/head/vendor
>  |> though.
>
> Under refs/tags/vendor?  refs/tags/ is the "special" namespace
> managed by "git tag", this is different than the rest.
>
>  |>> The thing is if i do
>  |>>
>  |>>   #?0|kent:free-src.git$ git ls-remote|wc -l
>  |>>   From https://git.freebsd.org/src.git
>  |>>   6814
>  |>>
>  |>> This is a tremendous amount of head references that need to be
>  |>> compared.
>  ...
>  |>> there is
>  |>>
>  |>>   #?0|kent:free-src.git$ git sr|wc -l
>  |>>   2137
>  |>>
>  |>> but if i go for "the real" FreeBSD itself it is just
>  |>>
>  |>>   #?0|kent:free-src.git$ git sr | grep -v vendor | wc -l
>  |>>   19
>  |>
>  |You might be happier tracking on github, once we start pushing there as
> the
>  |vendor branches won't be published there.
>
> No problem with any number of branches, Warner.  Just tags under
> refs/tags this is above.
>

They were tags in the cgit-beta as well (and a few branches). I don't
believe that detail changed, but my old copies of the repo are gone.


>   ...
>  |>> and thus
>  |>>
>  |>>   #?0|kent:free-src.git$ git sr | grep vendor | wc -l
>  |>>   2118
>  |>>
>  |>> Which is a pity since all these references will be checked during
>  |>> "git fetch" unless i am mistaken.
>  |>
>  |Yes.  So far it's been doing it quite quickly for me, but I'm decently
>  |connected...
>
> Yes, terrible here, shared with many.
>

You may be happier running custom refs, or grab from github. The source of
truth has a lot of stuff. We may work to prune some of the vendor branches
into their own repos in the future, but today there's a lot of stuff that's
there, some of which is for the convenience of the developer and you may
need to trim (at least in the short term).

  ...
>  |>>|That's a valid point, we debated whether to keep vendor tags and
>  |>> decided
>  |>>|for now to replicate what we have in SVN. We can still delete all the
>  |>>|vendor tags on the main repo anytime we want ...
>  |>>
>  |>> I personally would track that in the commit message of the import
>  |>> on the vendor branch that anyway exists(!), and then when merging
>  |>> this into the mainline, but not create a real tag in the tag
>  |>> namespace.  Also the backups/ and such, because why?
>  |>
>  |We need tags to keep track of what's been done, and to revert and do
> other
>  |management things with vendor imports.
>
> But why?  You have the commit on a topic/vendor branch, and yppou
> revert nothing but the commit.  In fact doing so messes the tag,p
> it has to be retagged when you do re-commit an import proper,
> which requires a forced push even!
>

I'm not sure I follow. Unless I misunderstand, you are describing a
different problem with different issues.

But the nice thing about refs is that you can always change them later if
the current scheme isn't working out... So far, it is for most people, so
we're not changing the vendor import stuff right away.  I've taken note of
your issues and will keep that in mind if there's others with the same
problems.

Warner

From steffen at sdaoden.eu  Sat Dec 26 01:55:35 2020
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Sat, 26 Dec 2020 02:55:30 +0100
Subject: src: continued use of Subversion for getting updates
In-Reply-To: <CANCZdfpidSxN-3fqWC8z=9ANytzF9y9WcgmEejGTsihfa-Pr-Q@mail.gmail.com>
References: <E1ks2I6-0005nh-BQ@rmmprod05.runbox>
 <20201223143545.Wf_Ww%steffen@sdaoden.eu>
 <X+ZUa7NyatH2ktYI@acme.spoerlein.net>
 <20201225214041.jVKMU%steffen@sdaoden.eu>
 <CANCZdfpgFUFzW3b_c2sa1zYcuNFjrBw_mtkCzT4_D5tajXCkXA@mail.gmail.com>
 <CANCZdfpNM19OyQtXH0OLHxzrQf4dqpBcRZzfBCuKfRyo5Wcziw@mail.gmail.com>
 <20201225222510.JyYwH%steffen@sdaoden.eu>
 <CANCZdfpidSxN-3fqWC8z=9ANytzF9y9WcgmEejGTsihfa-Pr-Q@mail.gmail.com>
Message-ID: <20201226015530.z2iL0%steffen@sdaoden.eu>

Warner Losh wrote in
 <CANCZdfpidSxN-3fqWC8z=9ANytzF9y9WcgmEejGTsihfa-Pr-Q at mail.gmail.com>:
 |On Fri, Dec 25, 2020 at 3:25 PM Steffen Nurpmeso <steffen at sdaoden.eu> \
 |wrote:
 |> Warner Losh wrote in
 |>  <CANCZdfpNM19OyQtXH0OLHxzrQf4dqpBcRZzfBCuKfRyo5Wcziw at mail.gmail.com>:
 |>|> On Fri, Dec 25, 2020 at 2:41 PM Steffen Nurpmeso <steffen at sdaoden.eu>
 |>|> wrote:
 |>|>> Ulrich Sp?rlein wrote in
 |>|>>  <X+ZUa7NyatH2ktYI at acme.spoerlein.net>:
 |>|>>|On Wed, 2020-12-23 at 15:35:45 +0100, Steffen Nurpmeso wrote:
 ...
 |>|>>|>I really dislike that vendor imports have been tagged.  Because
 ...
 |>|>>|That's basically what was done? I don't understand what you're saying
 |>|>>|here ...
 |>|>> Well, cgit-beta did not have had all these tags if i recall
 ...
 |>|> It had them, but not under the refs/head/vendor space but under the
 |>|> refs/vendor space.
 |>
 |> These are not tags but branches.  I have nothing against the
 ...
 |>|> They did exist. They were under refs/vendor rather than
 |> refs/head/vendor
 |>|> though.
 |>
 |> Under refs/tags/vendor?  refs/tags/ is the "special" namespace
 |> managed by "git tag", this is different than the rest.
 ...
 |>|>> there is
 |>|>>
 |>|>>   #?0|kent:free-src.git$ git sr|wc -l
 |>|>>   2137
 |>|>>
 |>|>> but if i go for "the real" FreeBSD itself it is just
 |>|>>
 |>|>>   #?0|kent:free-src.git$ git sr | grep -v vendor | wc -l
 |>|>>   19
 |>|>
 |>|You might be happier tracking on github, once we start pushing there as
 |> the
 |>|vendor branches won't be published there.
 |>
 |> No problem with any number of branches, Warner.  Just tags under
 |> refs/tags this is above.
 |
 |They were tags in the cgit-beta as well (and a few branches). I don't
 |believe that detail changed, but my old copies of the repo are gone.

Yes mine is gone, for a month.  Then i am sorry that i did not
speak out by then.

  ...
 |>|>> Which is a pity since all these references will be checked during
 |>|>> "git fetch" unless i am mistaken.
 |>|>
 |>|Yes.  So far it's been doing it quite quickly for me, but I'm decently
 |>|connected...
 |>
 |> Yes, terrible here, shared with many.
 |
 |You may be happier running custom refs, or grab from github. The source of
 |truth has a lot of stuff. We may work to prune some of the vendor branches

I am not interested in the entire repo, yes.  For almost a decade
i had only the sources as such, without history, for me this is an
improvement.  As i am not a BSD developer it is for snooping
around only.  And when i report bugs they are not fixed, but i am
not alone with this.  Nonetheless: interest in FreeBSD here, ok.

 |into their own repos in the future, but today there's a lot of stuff that's
 |there, some of which is for the convenience of the developer and you may
 |need to trim (at least in the short term).

 |  ...
 |>|>>|That's a valid point, we debated whether to keep vendor tags and
 |>|>> decided
 |>|>>|for now to replicate what we have in SVN. We can still delete all the
 |>|>>|vendor tags on the main repo anytime we want ...
 |>|>>
 |>|>> I personally would track that in the commit message of the import
 |>|>> on the vendor branch that anyway exists(!), and then when merging
 |>|>> this into the mainline, but not create a real tag in the tag
 |>|>> namespace.  Also the backups/ and such, because why?
 |>|>
 |>|We need tags to keep track of what's been done, and to revert and do
 |> other
 |>|management things with vendor imports.
 |>
 |> But why?  You have the commit on a topic/vendor branch, and yppou
 |> revert nothing but the commit.  In fact doing so messes the tag,p
 |> it has to be retagged when you do re-commit an import proper,
 |> which requires a forced push even!
 |
 |I'm not sure I follow. Unless I misunderstand, you are describing a
 |different problem with different issues.

No, maybe i was mistaken.  I never did a vendor import myself.
..But looking at the history i see lots of import disasters ;-))
Look for example at llvm 10.x this year, it consumed three _tags_!

I am luckily free to say that this is merde (without the intention
to annoy the poor one who did it) and am going to talk.  I presume
most of you can do git(1) better than i, i use it for a decade
(almost exactly in fact!), but have never stepped forward, and
have a very primitive way of daily use.

There should be a real per-vendor branch, say [vendor/sqlite].
The way FreeBSD seems to do vendor imports this should even be
easy, since vendor stuff is usually in separate directories.
Create it once it is needed first, merge into main via --no-ff so
that you get real "merge commits".  You can see the difference
below.

Then there are basically two options.  One is to simply switch to
the vendor branch, work and commit there as often as necessary,
and then merge to main when done.  The other is to instead rebase the
vendor branch to main first _before_ you start the work, any
_maybe_, _possibly_ again if the final push fails.

The former approach is perfect for vendor stuff which really
stands for itself, you can see below why this is so (the history
of the vendor branch is really only about the vendor branch, at
least after it has been created).

The latter is the only way to go if there are conflicts because
the vendor package reaches out into the base system, like i would
expect for llvm.  Then you want to rebase to main so that any
merge conflict resolving happen on the actually current state of
the art, of course, not on some old tree.

Like this the history of the vendor branch is not "clean" in that
it includes commits of the main branch that happened in the
meantime, but .. i would not care about this.
(One could also get the same vendor-branch-history-only also for
this kind, of course, easily even.  For this i would checkout the
branch, "git rm -rf '*'", do "git archive --format=tar --prefix=
main | tar -xf -", then "git add .", then "git commit -m
SYNC-WITH-MAIN", .. and then do the normal vendor branch stuff.)

Anyway it is important (i would say) to use --no-ff, so that you
get real merge commits.  This also avoids these terrible commit
messages of the actual merges one can see in FreeBSD history.
Consider this:

  #!/bin/sh

  doit() {
    mkdir y
    cd y
    git init

    touch 1 && git add 1 && git commit -m 1
    touch 2 && git add 2 && git commit -m 2

    git checkout -b vendor/x
    mkdir x
    cd x
    touch x1 && git add x1 && git commit -m x1
    cd ..

    git checkout master
    git merge --no-ff vendor/x -m MERGE-X-1

    touch 3 && git add 3 && git commit -m 3
    touch 4 && git add 4 && git commit -m 4

    git checkout vendor/x
    [ -n "$1" ] && git rebase master
    cd x
    touch x2 && git add x2 && git commit -m x2
    cd ..

    git checkout master
    git merge --no-ff vendor/x -m MERGE-X-2

    touch 5 && git add 5 && git commit -m 5

    git checkout vendor/x
    [ -n "$1" ] && git rebase master
    cd x
    touch x3 && git add x3 && git commit -m x3
    cd ..

    git checkout master
    git merge --no-ff vendor/x -m MERGE-X-3

    touch 6 && git add 6 && git commit -m 6

    echo ===VENDOR
    git log --oneline vendor/x
    echo ===MASTER
    git log --oneline master
    echo ===ALL
    git log --oneline --graph --all

    cd ..
    rm -rf y
  }

  echo ===== WITHOUT
  doit

  echo ===== WITH
  doit y

I personally would not just tag about anything.  You do not need
to, because all you need to do is to "git log
VENDOR-BRANCH-NAME", and there you see "import v1.2.3"
etc. messages.  Of course, if you always rebase the entire branch
then maybe it makes sense, but you could still use git(1) powers
via "git log --oneline --reverse --topo-order --merges [--all]",
which only gives the merge commits -- and if you give the name of
the topic/vendor branch, then you should see only merges of the
branch that is of interest, again!

 |But the nice thing about refs is that you can always change them later if
 |the current scheme isn't working out... So far, it is for most people, so

This requires forced pushes and thus special configuration.
"Normally", it is said, this should be avoided.  The fossil scm
does not even support it i think.  I for myself do that, but only
on development branch, release and stable and master branches are
immutable (but in disasters).

 |we're not changing the vendor import stuff right away.  I've taken note of
 |your issues and will keep that in mind if there's others with the same
 |problems.

Fine.

Ciao, and a nice weekend everybody,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From ludovit.koren at gmail.com  Sat Dec 26 08:37:42 2020
From: ludovit.koren at gmail.com (Ludovit Koren)
Date: Sat, 26 Dec 2020 09:37:37 +0100
Subject: (251866) installers for FreeBSD fail to boot HP EliteBook 830
 G7, ProBook 440 G7 =?utf-8?Q?=E2=80=A6?=
In-Reply-To: <b1799898-44f8-67ee-ff61-b2d4c0f2fcb7@gmail.com> (Graham Perrin's
 message of "Fri, 25 Dec 2020 14:53:31 +0000")
References: <86360c9p2p.fsf@gmail.com>
 <8cd298fa-5b16-d58b-b63b-201905f83438@gmail.com>
 <8aa45f8c-7b14-a264-a8b7-9dd0b6b36f59@bsdio.com>
 <36c65b46-58d9-9f03-9e31-d27cfb7a6dba@gmail.com>
 <86sg7u3sxu.fsf@gmail.com>
 <b1799898-44f8-67ee-ff61-b2d4c0f2fcb7@gmail.com>
Message-ID: <86o8ih3qum.fsf@gmail.com>

>>>>> Graham Perrin <grahamperrin at gmail.com> writes:

    > On 25/12/2020 13:40, Ludovit Koren wrote:
    >> FreeBSD-13.0-CURRENT-amd64-20201224-3cc0c0d66a0-255241-memstick.img
    >> still not working on HP EliteBook 830 G7.


    > Thank you, is it still exactly as shown in the photograph below?

    > <https://i.imgur.com/RnocF9g.png>

Yes, exactly.

lk

From uqs at freebsd.org  Sat Dec 26 10:44:08 2020
From: uqs at freebsd.org (Ulrich =?utf-8?B?U3DDtnJsZWlu?=)
Date: Sat, 26 Dec 2020 11:44:06 +0100
Subject: src: continued use of Subversion for getting updates
In-Reply-To: <20201226015530.z2iL0%steffen@sdaoden.eu>
References: <E1ks2I6-0005nh-BQ@rmmprod05.runbox>
 <20201223143545.Wf_Ww%steffen@sdaoden.eu>
 <X+ZUa7NyatH2ktYI@acme.spoerlein.net>
 <20201225214041.jVKMU%steffen@sdaoden.eu>
 <CANCZdfpgFUFzW3b_c2sa1zYcuNFjrBw_mtkCzT4_D5tajXCkXA@mail.gmail.com>
 <CANCZdfpNM19OyQtXH0OLHxzrQf4dqpBcRZzfBCuKfRyo5Wcziw@mail.gmail.com>
 <20201225222510.JyYwH%steffen@sdaoden.eu>
 <CANCZdfpidSxN-3fqWC8z=9ANytzF9y9WcgmEejGTsihfa-Pr-Q@mail.gmail.com>
 <20201226015530.z2iL0%steffen@sdaoden.eu>
Message-ID: <X+cT9s0pIWILiOT0@acme.spoerlein.net>

On Sat, 2020-12-26 at 02:55:30 +0100, Steffen Nurpmeso wrote:
>Warner Losh wrote in
> <CANCZdfpidSxN-3fqWC8z=9ANytzF9y9WcgmEejGTsihfa-Pr-Q at mail.gmail.com>:
> |On Fri, Dec 25, 2020 at 3:25 PM Steffen Nurpmeso <steffen at sdaoden.eu> \
> |wrote:
> |> Warner Losh wrote in
> |>  <CANCZdfpNM19OyQtXH0OLHxzrQf4dqpBcRZzfBCuKfRyo5Wcziw at mail.gmail.com>:
> |>|> On Fri, Dec 25, 2020 at 2:41 PM Steffen Nurpmeso <steffen at sdaoden.eu>
> |>|> wrote:
> |>|>> Ulrich Sp?rlein wrote in
> |>|>>  <X+ZUa7NyatH2ktYI at acme.spoerlein.net>:
> |>|>>|On Wed, 2020-12-23 at 15:35:45 +0100, Steffen Nurpmeso wrote:
> ...
> |>|>>|>I really dislike that vendor imports have been tagged.  Because
> ...
> |>|>>|That's basically what was done? I don't understand what you're saying
> |>|>>|here ...
> |>|>> Well, cgit-beta did not have had all these tags if i recall
> ...
> |>|> It had them, but not under the refs/head/vendor space but under the
> |>|> refs/vendor space.
> |>
> |> These are not tags but branches.  I have nothing against the
> ...
> |>|> They did exist. They were under refs/vendor rather than
> |> refs/head/vendor
> |>|> though.
> |>
> |> Under refs/tags/vendor?  refs/tags/ is the "special" namespace
> |> managed by "git tag", this is different than the rest.
> ...
> |>|>> there is
> |>|>>
> |>|>>   #?0|kent:free-src.git$ git sr|wc -l
> |>|>>   2137
> |>|>>
> |>|>> but if i go for "the real" FreeBSD itself it is just
> |>|>>
> |>|>>   #?0|kent:free-src.git$ git sr | grep -v vendor | wc -l
> |>|>>   19
> |>|>
> |>|You might be happier tracking on github, once we start pushing there as
> |> the
> |>|vendor branches won't be published there.
> |>
> |> No problem with any number of branches, Warner.  Just tags under
> |> refs/tags this is above.
> |
> |They were tags in the cgit-beta as well (and a few branches). I don't
> |believe that detail changed, but my old copies of the repo are gone.
>
>Yes mine is gone, for a month.  Then i am sorry that i did not
>speak out by then.

They were annotated tags, git doesn't care where you actually store 
them. Yes, refs/tags/ is special but more in terms of automatically 
pulling them down, not in whether that has commit objects or tag 
objects.

>  ...
> |>|>> Which is a pity since all these references will be checked during
> |>|>> "git fetch" unless i am mistaken.
> |>|>
> |>|Yes.  So far it's been doing it quite quickly for me, but I'm decently
> |>|connected...
> |>
> |> Yes, terrible here, shared with many.
> |
> |You may be happier running custom refs, or grab from github. The source of
> |truth has a lot of stuff. We may work to prune some of the vendor branches
>
>I am not interested in the entire repo, yes.  For almost a decade
>i had only the sources as such, without history, for me this is an
>improvement.  As i am not a BSD developer it is for snooping
>around only.  And when i report bugs they are not fixed, but i am
>not alone with this.  Nonetheless: interest in FreeBSD here, ok.

You say you're not interested in the entire repo, but as soon as you 
fetch `main` or any of the stable branches you get the entire repo 
anyway. So I don't understand what you're talking about ...

>
> |into their own repos in the future, but today there's a lot of stuff that's
> |there, some of which is for the convenience of the developer and you may
> |need to trim (at least in the short term).
>
> |  ...
> |>|>>|That's a valid point, we debated whether to keep vendor tags and
> |>|>> decided
> |>|>>|for now to replicate what we have in SVN. We can still delete all the
> |>|>>|vendor tags on the main repo anytime we want ...
> |>|>>
> |>|>> I personally would track that in the commit message of the import
> |>|>> on the vendor branch that anyway exists(!), and then when merging
> |>|>> this into the mainline, but not create a real tag in the tag
> |>|>> namespace.  Also the backups/ and such, because why?
> |>|>
> |>|We need tags to keep track of what's been done, and to revert and do
> |> other
> |>|management things with vendor imports.
> |>
> |> But why?  You have the commit on a topic/vendor branch, and yppou
> |> revert nothing but the commit.  In fact doing so messes the tag,p
> |> it has to be retagged when you do re-commit an import proper,
> |> which requires a forced push even!
> |
> |I'm not sure I follow. Unless I misunderstand, you are describing a
> |different problem with different issues.
>
>No, maybe i was mistaken.  I never did a vendor import myself.
>..But looking at the history i see lots of import disasters ;-))
>Look for example at llvm 10.x this year, it consumed three _tags_!
>
>I am luckily free to say that this is merde (without the intention
>to annoy the poor one who did it) and am going to talk.  I presume
>most of you can do git(1) better than i, i use it for a decade
>(almost exactly in fact!), but have never stepped forward, and
>have a very primitive way of daily use.
>
>There should be a real per-vendor branch, say [vendor/sqlite].
>The way FreeBSD seems to do vendor imports this should even be
>easy, since vendor stuff is usually in separate directories.
>Create it once it is needed first, merge into main via --no-ff so
>that you get real "merge commits".  You can see the difference
>below.

Umm, no offense but wtf are you talking about? I asked this earlier but 
you didn't reply to that part of the question. Of course the vendor 
branches are stand-alone vendor branches.

% git log --reverse --compact-summary -n2 origin/vendor/sqlite3
commit c80e66e8e79185b1e7c999decef3d4adfdb902de (tag: vendor/sqlite3/sqlite-3320300)
Author: Cy Schubert <cy at FreeBSD.org>
Date:   2020-07-07 13:48:26 +0000

     Import sqlite 3.32.3 (3320300).

Notes:
     svn path=/vendor/sqlite3/dist/; revision=362990
     svn path=/vendor/sqlite3/sqlite-3320300/; revision=362991; tag=vendor/sqlite3/sqlite-3320300

  configure        |  20 +++++++-------
  configure.ac     |   2 +-
  sqlite3.c        | 325 +++++++++++++++++...
  sqlite3.h        |   6 ++---
  tea/configure    |  18 ++++++-------
  tea/configure.ac |   2 +-
  6 files changed, 272 insertions(+), 101 deletions(-)

commit 2793f2eef2be94a38e38babede1b01c3c50196fe (tag: vendor/sqlite3/sqlite-3330000, origin/vendor/sqlite3, freebsd/vendor/sqlite3)
Author: Cy Schubert <cy at FreeBSD.org>
Date:   2020-08-21 22:54:38 +0000

     Import sqlite 3.32.3 (3330000).

Notes:
     svn path=/vendor/sqlite3/dist/; revision=364467
     svn path=/vendor/sqlite3/sqlite-3330000/; revision=364469; tag=vendor/sqlite3/sqlite-3330000

  Makefile.am       |     2 +-
  Makefile.in       |     2 +-
  configure         |    20 +-
  configure.ac      |     2 +-
  shell.c           |  1618 +++++++++++++++++--
  sqlite3.c         | 19228 +++++++++++++++....
  sqlite3.h         |  1378 ++++++++--------
  sqlite3rc.h (new) |     3 +
  tea/configure     |    18 +-
  tea/configure.ac  |     2 +-
  10 files changed, 12150 insertions(+), 10123 deletions(-)

% git ls-tree -r origin/vendor/sqlite3
100644 blob a1e89e18ad20c227845f2099cb9894c799265d19    INSTALL
100644 blob 694419b27dfd74741846d068c3e5a626d14b1797    Makefile.am
100644 blob 9355b147a8fd3cd10edcf89ac955bf3f9a9d56ba    Makefile.fallback
100644 blob 842fa864581de8788d5e74eab961c01bd157a778    Makefile.in
100644 blob 746162a00c04298d13bb01ac26e77ad2cca566a4    Makefile.msc
100644 blob 6e62a4e13854dc976b1f7e16caa6c0dd042ca90c    README.txt
100644 blob 3475a47e6e813a7e8c2ff0893d4ee28442bd15fb    Replace.cs
100644 blob 53c1fc39d80b85fb98daa8607ce6b6b6af8fc7f2    aclocal.m4
100755 blob a85b723c7e67d46316e85e7422bd5088e9136042    compile
100755 blob f50dcdb6de2af0a2e33f44704da3ec1286e5f291    config.guess
100755 blob 1d8e98bcee23a0421e4fafe9a6c9ac75180cff25    config.sub
100755 blob 9aed16a74091aea4ee9911922ed79ab1b72d4cd5    configure
100644 blob a83dac3ac1425d4f13d0186da67861683fb2bae1    configure.ac
100755 blob b39f98f9ae9f950391abb09f4fa03ee113a07ac6    depcomp
100755 blob 59990a10492675f2e87d5e5df17b566d145d9aee    install-sh
100755 blob a736cf994256132aefd49c1f11118ad7ba31d924    ltmain.sh
100755 blob f62bbae306c7e1bc28896aab8fe7bfb700a9a33e    missing
100644 blob a1a77e49fa5f91625ee02efc36818ffab9fe1219    shell.c
100644 blob 80353b0eecd9848204c711d6264ca116b2d1064b    sqlite3.1
100644 blob a82744931c0b7f1ed3baf079bcc75090448d00b4    sqlite3.c
100644 blob 910b687aa7df2d45ada1e7a57bd1794ae3fd4227    sqlite3.h
100644 blob 3799671e613b34a4551d1010c13e334b89123ea1    sqlite3.pc.in
100644 blob 5a856490d64a45062c5e8d648e51cc8b6d09dbdc    sqlite3.rc
100644 blob 78c19a0d10ce60b29720889c2c1d0ba746ef9169    sqlite3ext.h
100644 blob 80feb9e1cd61e4d89ff9c8a0595024430a6229f1    sqlite3rc.h
100644 blob 3e481dadfe84fb65f64c81bcb3cd08a1ddc0855c    tea/Makefile.in
100644 blob 99dc8b8f03cda56e80e8dbf594bfe1feb3f880ae    tea/README
100644 blob 0b057391d2919535a4427b09987c06287eb6e05e    tea/aclocal.m4
100755 blob 4ff25cb1ce06affe22a8b2f9efb157376e270cb2    tea/configure
100644 blob bfc4eca248c1da282960b16f45e08150e4478360    tea/configure.ac
100644 blob 13913e5583d8258ff244f945710f39dacf0adb9d    tea/doc/sqlite3.n
100644 blob 4d722eb6c3c7f32b4ad9cdb9da3d1c15e4cf528a    tea/generic/tclsqlite3.c
100644 blob 723c4cd3c6e91a9f86ee9fe667923a316ba17d03    tea/license.terms
100644 blob bc585f73b3007cf63086532cddc38bfe4a246236    tea/pkgIndex.tcl.in
100644 blob 7c34c3f926031734a8e1a4234a7ab131bdefda3e    tea/tclconfig/install-sh
100644 blob 4b4bd1e888964cc55c78a97591f40538cd5b21ec    tea/tclconfig/tcl.m4
100644 blob 88b66f173cb3d41a97023dc547d77fb0fcdafcff    tea/win/makefile.vc
100644 blob e00f1b49965d07d0ac4862354131776bdaf714eb    tea/win/nmakehlp.c
100644 blob 99471053c8c0a38e9571d8809402b032b250401c    tea/win/rules.vc


They are tagged because we tagged them in SVN and in SVN it's very 
annoying to get the history of a branch only. And yes, we talked in the 
WG about dropping the tags eventually, as they serve little purpose.

>Then there are basically two options.  One is to simply switch to
>the vendor branch, work and commit there as often as necessary,
>and then merge to main when done.  The other is to instead rebase the
>vendor branch to main first _before_ you start the work, any
>_maybe_, _possibly_ again if the final push fails.
>
>The former approach is perfect for vendor stuff which really
>stands for itself, you can see below why this is so (the history
>of the vendor branch is really only about the vendor branch, at
>least after it has been created).
>
>The latter is the only way to go if there are conflicts because
>the vendor package reaches out into the base system, like i would
>expect for llvm.  Then you want to rebase to main so that any
>merge conflict resolving happen on the actually current state of
>the art, of course, not on some old tree.
>
>Like this the history of the vendor branch is not "clean" in that
>it includes commits of the main branch that happened in the
>meantime, but .. i would not care about this.
>(One could also get the same vendor-branch-history-only also for
>this kind, of course, easily even.  For this i would checkout the
>branch, "git rm -rf '*'", do "git archive --format=tar --prefix=
>main | tar -xf -", then "git add .", then "git commit -m
>SYNC-WITH-MAIN", .. and then do the normal vendor branch stuff.)

Please explain how this is different from the above? I'm really not sure 
what you're saying here ...

>
> |But the nice thing about refs is that you can always change them 
> later if
> |the current scheme isn't working out... So far, it is for most people, so
>
>This requires forced pushes and thus special configuration.
>"Normally", it is said, this should be avoided.  The fossil scm
>does not even support it i think.  I for myself do that, but only
>on development branch, release and stable and master branches are
>immutable (but in disasters).

Adding or removing refs or tags doesn't need a force push. Please stop 
spreading this misinformation.

As for your network trouble, have you measured the bandwidth difference 
between: git fetch and git fetch --no-tags and if there's a big 
difference I'd suggest to simply use the later?

I just tried to measure the difference with trafshow and it was pretty 
much 9k up 560k down for both flags. Then I deleted all my local copies 
of the tags and it went to 8k up, 560k down. Probably a measurement 
error. Am I holding this wrong?

Cheers
Uli

From grahamperrin at gmail.com  Sat Dec 26 15:41:57 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Sat, 26 Dec 2020 15:41:53 +0000
Subject: src: continued use of Subversion for getting updates
In-Reply-To: <5fe325a7.1c69fb81.5ec11.a617SMTPIN_ADDED_MISSING@mx.google.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <20201222183900.GA22353@www.zefox.net>
 <81C07616-434E-4DF4-91AC-518AECF4F16F@gromit.dlib.vt.edu>
 <01b07b90-e206-aa56-aa5b-91c764ef36a4@gmail.com>
 <CANCZdfpJC4jA0ZUfP90FkeY-EWpLJo+ZcRctV6GUKt=tyUG2kA@mail.gmail.com>
 <5fe325a7.1c69fb81.5ec11.a617SMTPIN_ADDED_MISSING@mx.google.com>
Message-ID: <be4bdabf-b6d6-14ce-30cd-69d16bc59f0c@gmail.com>

On 23/12/2020 11:10, Thomas Mueller wrote:

> ? Will stable/11 and stable/12 be available by both git and svn? ?


Yes; 
<https://lists.freebsd.org/pipermail/freebsd-current/2020-December/077913.html> 
offers some detail.


From ali.abdallah at suse.com  Sat Dec 26 16:37:24 2020
From: ali.abdallah at suse.com (Ali Abdallah)
Date: Sat, 26 Dec 2020 17:37:20 +0100
Subject: MII media status race condition causing fictitious link down
Message-ID: <20201226163720.zok6km7b7hyze56f@frix230>

Hello,

As I've sent a couple of patches to add support for Thinkpad USB-C gen2
to if_ure(4), I came across a very strange link random state change,
causing dhclient to think the link went effectively down, which is not
the case.

First I thought that if_ure(4) doesn't play well with the new chip of the
dock, but after lot of debugging, it turns out to be a nasty race
condition in mii bus code [1].

I'm sending this mail to raise awareness about this issue. Apparently it
exists since long time (I even remember having had this issue in the
past on my older Thinkpad).

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252165

Regards,

-- 
Ali Abdallah | SUSE L3 Engineer
GPG fingerprint: 51A0 F4A0 C8CF C98F 842E  A9A8 B945 56F8 1C85 D0D5


From steffen at sdaoden.eu  Sat Dec 26 18:08:12 2020
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Sat, 26 Dec 2020 19:06:56 +0100
Subject: src: continued use of Subversion for getting updates
In-Reply-To: <X+cT9s0pIWILiOT0@acme.spoerlein.net>
References: <E1ks2I6-0005nh-BQ@rmmprod05.runbox>
 <20201223143545.Wf_Ww%steffen@sdaoden.eu>
 <X+ZUa7NyatH2ktYI@acme.spoerlein.net>
 <20201225214041.jVKMU%steffen@sdaoden.eu>
 <CANCZdfpgFUFzW3b_c2sa1zYcuNFjrBw_mtkCzT4_D5tajXCkXA@mail.gmail.com>
 <CANCZdfpNM19OyQtXH0OLHxzrQf4dqpBcRZzfBCuKfRyo5Wcziw@mail.gmail.com>
 <20201225222510.JyYwH%steffen@sdaoden.eu>
 <CANCZdfpidSxN-3fqWC8z=9ANytzF9y9WcgmEejGTsihfa-Pr-Q@mail.gmail.com>
 <20201226015530.z2iL0%steffen@sdaoden.eu>
 <X+cT9s0pIWILiOT0@acme.spoerlein.net>
Message-ID: <20201226180656.hFnNo%steffen@sdaoden.eu>

Hello.

Ulrich Sp?rlein wrote in
 <X+cT9s0pIWILiOT0 at acme.spoerlein.net>:
 |On Sat, 2020-12-26 at 02:55:30 +0100, Steffen Nurpmeso wrote:
 |>Warner Losh wrote in
 |> <CANCZdfpidSxN-3fqWC8z=9ANytzF9y9WcgmEejGTsihfa-Pr-Q at mail.gmail.com>:
 |>|On Fri, Dec 25, 2020 at 3:25 PM Steffen Nurpmeso <steffen at sdaoden.eu> \
 |>|wrote:
 |>|> Warner Losh wrote in
 |>|>  <CANCZdfpNM19OyQtXH0OLHxzrQf4dqpBcRZzfBCuKfRyo5Wcziw at mail.gmail.com>:
 |>|>|> On Fri, Dec 25, 2020 at 2:41 PM Steffen Nurpmeso <steffen at sdaoden.eu>
 |>|>|> wrote:
 |>|>|>> Ulrich Sp?rlein wrote in
 |>|>|>>  <X+ZUa7NyatH2ktYI at acme.spoerlein.net>:
 |>|>|>>|On Wed, 2020-12-23 at 15:35:45 +0100, Steffen Nurpmeso wrote:
 |> ...
 |>|>|>>|>I really dislike that vendor imports have been tagged.  Because
 |> ...
 |>|>|>>|That's basically what was done? I don't understand what you're \
 |>|>|>>|saying
 |>|>|>>|here ...
 |>|>|>> Well, cgit-beta did not have had all these tags if i recall
 |> ...
 |>|>|> It had them, but not under the refs/head/vendor space but under the
 |>|>|> refs/vendor space.
 |>|>
 |>|> These are not tags but branches.  I have nothing against the
 |> ...
 |>|>|> They did exist. They were under refs/vendor rather than
 |>|> refs/head/vendor
 |>|>|> though.
 |>|>
 |>|> Under refs/tags/vendor?  refs/tags/ is the "special" namespace
 |>|> managed by "git tag", this is different than the rest.
 |> ...
 |>|>|>> there is
 |>|>|>>
 |>|>|>>   #?0|kent:free-src.git$ git sr|wc -l
 |>|>|>>   2137
 |>|>|>>
 |>|>|>> but if i go for "the real" FreeBSD itself it is just
 |>|>|>>
 |>|>|>>   #?0|kent:free-src.git$ git sr | grep -v vendor | wc -l
 |>|>|>>   19
 |>|>|>
 |>|>|You might be happier tracking on github, once we start pushing there as
 |>|> the
 |>|>|vendor branches won't be published there.
 |>|>
 |>|> No problem with any number of branches, Warner.  Just tags under
 |>|> refs/tags this is above.
 |>|
 |>|They were tags in the cgit-beta as well (and a few branches). I don't
 |>|believe that detail changed, but my old copies of the repo are gone.
 |>
 |>Yes mine is gone, for a month.  Then i am sorry that i did not
 |>speak out by then.
 |
 |They were annotated tags, git doesn't care where you actually store 
 |them. Yes, refs/tags/ is special but more in terms of automatically 
 |pulling them down, not in whether that has commit objects or tag 
 |objects.

I know that.  The git maintainer is prowd of being able to use
neat tricks like storing the OpenPGP key in the repo like that.
_I_ was only talking about refs/tags from the beginning, was i.

  ...
 |>|You may be happier running custom refs, or grab from github. The \
 |>|source of
 |>|truth has a lot of stuff. We may work to prune some of the vendor \
 |>|branches
 |>
 |>I am not interested in the entire repo, yes.  For almost a decade
 ...
 |You say you're not interested in the entire repo, but as soon as you 
 |fetch `main` or any of the stable branches you get the entire repo 
 |anyway. So I don't understand what you're talking about ...

:)  That depends on the project does it.  Just imagine NetBSD with
all of its topic branches and all the non-starters, and the
starters, the fully fledged regression tests etc etc etc, a real
fan or project mentor etc wants to have it all, but to me this is
useless.  I would consider also tracking the doc branch.

Interesting would be how many savings can be achieved by storing
it all in one repository, source, tests, doc, etc etc.
The Plan9 people with their fossil/venti storage system did
measure that, and even though they used all that image, sound and
video media the curve of newly created storag? blocks (of unique
hashes) became flatter and flatter over time.

  ...
 |>|>|>>|That's a valid point, we debated whether to keep vendor tags and
 |>|>|>> decided
 |>|>|>>|for now to replicate what we have in SVN. We can still delete \
 |>|>|>>|all the
 |>|>|>>|vendor tags on the main repo anytime we want ...
  ...
 |>|>|We need tags to keep track of what's been done, and to revert and do
 |>|> other
 |>|>|management things with vendor imports.
 |>|>
 |>|> But why?  You have the commit on a topic/vendor branch, and yppou
  ...
 |>|I'm not sure I follow. Unless I misunderstand, you are describing a
 |>|different problem with different issues.
 |>
 |>No, maybe i was mistaken.  I never did a vendor import myself.
 |>..But looking at the history i see lots of import disasters ;-))
 |>Look for example at llvm 10.x this year, it consumed three _tags_!
 |>
 |>I am luckily free to say that this is merde (without the intention
 |>to annoy the poor one who did it) and am going to talk.  I presume
 ...
 |>There should be a real per-vendor branch, say [vendor/sqlite].
 |>The way FreeBSD seems to do vendor imports this should even be
 |>easy, since vendor stuff is usually in separate directories.
 |>Create it once it is needed first, merge into main via --no-ff so
 |>that you get real "merge commits".  You can see the difference
 |>below.
 |
 |Umm, no offense but wtf are you talking about? I asked this earlier but 
 |you didn't reply to that part of the question. Of course the vendor 
 |branches are stand-alone vendor branches.
 |
 |% git log --reverse --compact-summary -n2 origin/vendor/sqlite3

  ...
 |% git ls-tree -r origin/vendor/sqlite3

Ok fine -- great!  I cannot do _that_ locally.
(But the tags i have, there you go.)

  ...
 |They are tagged because we tagged them in SVN and in SVN it's very 
 |annoying to get the history of a branch only. And yes, we talked in the 
 |WG about dropping the tags eventually, as they serve little purpose.

Especially if you can simply log the vendor branch i'd say.

  ...
 |Please explain how this is different from the above? I'm really not sure 
 |what you're saying here ...

Not much, not much.  Maybe enforcing --no-ff when doing
git(1)-based merges in the future.

  ...
 |>|But the nice thing about refs is that you can always change them 
 |> later if
 |>|the current scheme isn't working out... So far, it is for most people, so
 |>
 |>This requires forced pushes and thus special configuration.
 |>"Normally", it is said, this should be avoided.  The fossil scm
 |>does not even support it i think.  I for myself do that, but only
 |>on development branch, release and stable and master branches are
 |>immutable (but in disasters).
 |
 |Adding or removing refs or tags doesn't need a force push. Please stop 
 |spreading this misinformation.

Everything is a reference, is it.  It depends on the refspec
specification and/or --force, as described for "<refspec>" unders
OPTIONS in git-push(1).
Whereas it may be allowed for free-standing tags, i hope i never
tried messing around with any published tags, shouldn't tags be
some fixed points on a timeline.
Also much depends upon your local configuration, i wrote mine many
years ago and am using aliases ever since mostly, so i am not
competent to talk about that.  Many, many things have been added
to git compared to when i learned it.

 |As for your network trouble, have you measured the bandwidth difference 

That is German D-Netz trouble.  That has nothing to do with
FreeBSD.  With FreeBSD there was trouble because of a server
misconfiguration i would say, i had cloned cgit-beta and then you
rewrote the history, and then it became impossible for me to
simply re-sync via "git fetch", as i have shown in my posts.

 |between: git fetch and git fetch --no-tags and if there's a big 
 |difference I'd suggest to simply use the later?

Whereas .. i could surely do that, it was more about FreeBSD and
its repository layout.

 |I just tried to measure the difference with trafshow and it was pretty 
 |much 9k up 560k down for both flags. Then I deleted all my local copies 
 |of the tags and it went to 8k up, 560k down. Probably a measurement 
 |error. Am I holding this wrong?

I have absolutely zero idea of how much this increases the
necessary network bandwidth for the FreeBSD project.  I know that
the difference goes into megabytes for my small things each day.
I know the git people were talking about improving the efficiency
of the compare-the-head-references step, it flew by one day.

Ciao,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From grarpamp at gmail.com  Sat Dec 26 22:47:40 2020
From: grarpamp at gmail.com (grarpamp)
Date: Sat, 26 Dec 2020 17:47:35 -0500
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <X+M0yPrCJ5Rz/V85@home.opsec.eu>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org>
 <CANCZdfrF0B7uux_neg-4XGn2UCDd4noUm7zP_icHnrpZUgmzzA@mail.gmail.com>
 <CAOtMX2gV2dmyG4b1hZG24sUnqDVk=1pch4xgQmyUdtLrh48kYg@mail.gmail.com>
 <CANCZdfpb0MF+uoW=K3cQpL+3vNQjSBDeVMab5d4JJhUO4sy-2Q@mail.gmail.com>
 <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com>
 <20201218175241.GA72552@spindle.one-eyed-alien.net>
 <20201218182820.1P0tK%steffen@sdaoden.eu>
 <20201223023242.GG31099@funkthat.com> <X+M0yPrCJ5Rz/V85@home.opsec.eu>
Message-ID: <CAD2Ti2-shKQ_uq3Na_+8Faqs85c4UyMTsUeg7-JqMu6dXksAOA@mail.gmail.com>

> We do have most of the keys in docs/share/pgpkeys/ plus history.

https://git.kernel.org/pub/scm/docs/kernel/ksmap
https://git.kernel.org/pub/scm/docs/kernel/pgpkeys

From me+freebsd at igalic.co  Sun Dec 27 22:30:55 2020
From: me+freebsd at igalic.co (=?utf-8?Q?Mina_Gali=C4=87?=)
Date: Sun, 27 Dec 2020 22:30:36 +0000
Subject: Unofficial PkgBase Repository
Message-ID: <cq94-pP_TvQ0Dz3WMfQgvrI2DJ-N40-3vTA8yxUWEmcrlTj-wrkPIKagvHP1ykKtqmx0XDx0ZcUmPbOYrcbtXXFmUVca0s2znxmDWE6i-SI=@igalic.co>

Hi folks,

Recently I've been working on on building a PkgBase repository
The repository is in good enough shape now that I believe it can be announced publicly!

    https://alpha.pkgbase.live/

is built with poudriere and serves -CURRENT packages for AMD64 and AARCH64.
The host itself is still updated with https://up.bsd.lv/ but the jail serving the packages is built and updated with PkgBase.
It's hosted on a vServer at Hetzner in Helsinki

There's still a number of things to do before I'd consider the repository production quality, hence the domain name.
Two of the most important ones are:

- Package Signing: https://reviews.freebsd.org/D27690
- HTTP Caching of packages: https://github.com/freebsd/poudriere/pull/751

I will add more more architectures when I hear your feedback on what you would like to see.

It would also be nice to add "production" builds `WITHOUT_LLVM_ASSERTIONS` and `WITH_MALLOC_PRODUCTION`.
it just feels? wrong until 13 STABLE is branched ?

Happy testing! Looking forward to your feedback.

p.s.: if it feels slow, blame virtio + vnet

Best regards,

Mina Gali?

Web: https://igalic.co/

From garga at FreeBSD.org  Mon Dec 28 12:08:31 2020
From: garga at FreeBSD.org (Renato Botelho)
Date: Mon, 28 Dec 2020 09:08:25 -0300
Subject: git and the loss of revision numbers
In-Reply-To: <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org>
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
 <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org>
Message-ID: <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org>

On 24/12/20 11:15, Michael Grimm wrote:
> Correction:
> 
>> On 24. Dec 2020, at 15:11, Michael Grimm <trashcan at ellael.org> wrote:
>>
>> In the past I could easily judge if there was a need to buildworld or buildkernel: If uname shows a larger revision number than those in advisories or notices.
> 
> In the past I could easily judge if there was a need to buildworld or buildkernel: If uname shows a smaller revision number than those in advisories or notices.

FreeBSD bast.garga.net.br 13.0-CURRENT FreeBSD 13.0-CURRENT #19 
3cc0c0d66a0-c255241(main)-dirty:
             ^
             This is an incremental counter of commits

-- 
Renato Botelho

From emaste at freebsd.org  Mon Dec 28 16:27:40 2020
From: emaste at freebsd.org (Ed Maste)
Date: Mon, 28 Dec 2020 11:27:24 -0500
Subject: git and the loss of revision numbers
In-Reply-To: <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org>
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
 <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org>
 <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org>
Message-ID: <CAPyFy2DW0YDUK+kir2H_e8LVT-P-kQ0PMmKQO6m+016Wb=Hd0A@mail.gmail.com>

On Mon, 28 Dec 2020 at 07:08, Renato Botelho <garga at freebsd.org> wrote:
>
> FreeBSD bast.garga.net.br 13.0-CURRENT FreeBSD 13.0-CURRENT #19
> 3cc0c0d66a0-c255241(main)-dirty:
>              ^
>              This is an incremental counter of commits

Also, uqs@ recently fixed an issue in newvers.sh (including the final,
non-updating svn revision) and reordered the information. An example
of the new format:

main-c255126-gb81783dc98e6-dirty
 \     \       \            \
  \     \       \             local modifications
   \     \        hash
    \      commit count
      branch

From jhb at FreeBSD.org  Mon Dec 28 20:24:47 2020
From: jhb at FreeBSD.org (John Baldwin)
Date: Mon, 28 Dec 2020 12:24:44 -0800
Subject: panic: Assertion pgrp->pg_jobc > 0 failed at kern_proc.c:816
Message-ID: <8f88c925-f12a-6a51-c2b3-c21c55de8dab@FreeBSD.org>

I got this panic again today in a VM when quitting a gdb
session after killing a child process via 'kill'.

panic: Assertion pgrp->pg_jobc > 0 failed at /git/bhyve/sys/kern/kern_proc.c:816
cpuid = 1
time = 1609185862
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00946547f0
vpanic() at vpanic+0x181/frame 0xfffffe0094654840
panic() at panic+0x43/frame 0xfffffe00946548a0
_refcount_update_saturated() at _refcount_update_saturated/frame 0xfffffe00946548e0
killjobc() at killjobc+0x6a6/frame 0xfffffe0094654940
exit1() at exit1+0x6af/frame 0xfffffe00946549b0
sys_sys_exit() at sys_sys_exit+0xd/frame 0xfffffe00946549c0
amd64_syscall() at amd64_syscall+0x12e/frame 0xfffffe0094654af0
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0094654af0
--- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x8024c8f0a, rsp = 0x7fffffffe358, rbp = 0x7fffffffe370 ---
KDB: enter: panic
[ thread pid 44034 tid 102484 ]
Stopped at      kdb_enter+0x37: movq    $0,0x10ab066(%rip)

>From what I can tell, the child process that was killed via 'kill' has
not yet exited and is stuck in ptracestop() from fork():

(kgdb) where
#0  sched_switch (td=0xfffffe0094001a00, flags=<optimized out>) at /git/bhyve/sys/kern/sched_ule.c:2147
#1  0xffffffff80bf4015 in mi_switch (flags=266) at /git/bhyve/sys/kern/kern_synch.c:542
#2  0xffffffff80bfeba5 in thread_suspend_switch (td=<optimized out>, p=<optimized out>)
    at /git/bhyve/sys/kern/kern_thread.c:1477
#3  0xffffffff80bef04b in ptracestop (td=0xfffffe0094001a00, sig=17, si=0x0)
    at /git/bhyve/sys/kern/kern_sig.c:2642
#4  0xffffffff80ba1a54 in fork_return (td=0xfffffe0094001a00, frame=0xfffffe0094671b00)
    at /git/bhyve/sys/kern/kern_fork.c:1106
#5  0xffffffff80ba18b0 in fork_exit (callout=0xffffffff80ba1950 <fork_return>, arg=0xfffffe0094001a00, 
    frame=0xfffffe0094671b00) at /git/bhyve/sys/kern/kern_fork.c:1069
#6  <signal handler called>
#7  0x00000008007b71aa in ?? ()

kgdb can't find the panicking process due to the zombproc removal, so I will
have to go work on kgdb to recover from that change. :(

-- 
John Baldwin

From jhb at FreeBSD.org  Mon Dec 28 20:44:21 2020
From: jhb at FreeBSD.org (John Baldwin)
Date: Mon, 28 Dec 2020 12:44:18 -0800
Subject: panic: Assertion pgrp->pg_jobc > 0 failed at kern_proc.c:816
In-Reply-To: <8f88c925-f12a-6a51-c2b3-c21c55de8dab@FreeBSD.org>
References: <8f88c925-f12a-6a51-c2b3-c21c55de8dab@FreeBSD.org>
Message-ID: <aa91221f-cfc6-6ba4-06d7-2251f52dd09c@FreeBSD.org>

On 12/28/20 12:24 PM, John Baldwin wrote:
> I got this panic again today in a VM when quitting a gdb
> session after killing a child process via 'kill'.
> 
> panic: Assertion pgrp->pg_jobc > 0 failed at /git/bhyve/sys/kern/kern_proc.c:816
> cpuid = 1
> time = 1609185862
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00946547f0
> vpanic() at vpanic+0x181/frame 0xfffffe0094654840
> panic() at panic+0x43/frame 0xfffffe00946548a0
> _refcount_update_saturated() at _refcount_update_saturated/frame 0xfffffe00946548e0
> killjobc() at killjobc+0x6a6/frame 0xfffffe0094654940
> exit1() at exit1+0x6af/frame 0xfffffe00946549b0
> sys_sys_exit() at sys_sys_exit+0xd/frame 0xfffffe00946549c0
> amd64_syscall() at amd64_syscall+0x12e/frame 0xfffffe0094654af0
> fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0094654af0
> --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x8024c8f0a, rsp = 0x7fffffffe358, rbp = 0x7fffffffe370 ---
> KDB: enter: panic
> [ thread pid 44034 tid 102484 ]
> Stopped at      kdb_enter+0x37: movq    $0,0x10ab066(%rip)
> 
> From what I can tell, the child process that was killed via 'kill' has
> not yet exited and is stuck in ptracestop() from fork():
> 
> (kgdb) where
> #0  sched_switch (td=0xfffffe0094001a00, flags=<optimized out>) at /git/bhyve/sys/kern/sched_ule.c:2147
> #1  0xffffffff80bf4015 in mi_switch (flags=266) at /git/bhyve/sys/kern/kern_synch.c:542
> #2  0xffffffff80bfeba5 in thread_suspend_switch (td=<optimized out>, p=<optimized out>)
>     at /git/bhyve/sys/kern/kern_thread.c:1477
> #3  0xffffffff80bef04b in ptracestop (td=0xfffffe0094001a00, sig=17, si=0x0)
>     at /git/bhyve/sys/kern/kern_sig.c:2642
> #4  0xffffffff80ba1a54 in fork_return (td=0xfffffe0094001a00, frame=0xfffffe0094671b00)
>     at /git/bhyve/sys/kern/kern_fork.c:1106
> #5  0xffffffff80ba18b0 in fork_exit (callout=0xffffffff80ba1950 <fork_return>, arg=0xfffffe0094001a00, 
>     frame=0xfffffe0094671b00) at /git/bhyve/sys/kern/kern_fork.c:1069
> #6  <signal handler called>
> #7  0x00000008007b71aa in ?? ()
> 
> kgdb can't find the panicking process due to the zombproc removal, so I will
> have to go work on kgdb to recover from that change. :(

I've come up with a shorter reproducer (original was trying to debug a perl script
in OpenSSL's test suite).

Compile this program:

#include <sys/types.h>
#include <sys/wait.h>
#include <err.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int
main(void)
{
	pid_t pid, wpid;

	pid = fork();
	if (pid == -1)
		err(1, "fork");
	if (pid == 0) {
		printf("I'm in the child\n");
		exit(1);
	}
	printf("I'm in the parent\n");
	wpid = waitpid(pid, NULL, 0);
	if (wpid < 0)
		err(1, "waitpid");

	return (0);
}

Then in gdb do the following:

# gdb101 ./forktest
...
(gdb) catch fork
Catchpoint 1 (fork)
(gdb) r
Starting program: /mnt/forktest/forktest 

Catchpoint 1 (forked process 830), _fork () at _fork.S:4
4       _fork.S: No such file or directory.
(gdb) kill
Kill the program being debugged? (y or n) y
[Inferior 1 (process 828) killed]
(gdb) quit
<panic>

-- 
John Baldwin

From monochrome at twcny.rr.com  Tue Dec 29 00:38:08 2020
From: monochrome at twcny.rr.com (monochrome)
Date: Mon, 28 Dec 2020 19:38:05 -0500
Subject: git and the loss of revision numbers
In-Reply-To: <CAPyFy2DW0YDUK+kir2H_e8LVT-P-kQ0PMmKQO6m+016Wb=Hd0A@mail.gmail.com>
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
 <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org>
 <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org>
 <CAPyFy2DW0YDUK+kir2H_e8LVT-P-kQ0PMmKQO6m+016Wb=Hd0A@mail.gmail.com>
Message-ID: <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com>

what would be the git command for reverting source to a previous version 
using these numbers? for example, with svn and old numbers:
svnlite update -r367627 /usr/src

this is needed often when it blows up for someone tracking current

On 12/28/20 11:27 AM, Ed Maste wrote:
> On Mon, 28 Dec 2020 at 07:08, Renato Botelho <garga at freebsd.org> wrote:
>>
>> FreeBSD bast.garga.net.br 13.0-CURRENT FreeBSD 13.0-CURRENT #19
>> 3cc0c0d66a0-c255241(main)-dirty:
>>               ^
>>               This is an incremental counter of commits
> 
> Also, uqs@ recently fixed an issue in newvers.sh (including the final,
> non-updating svn revision) and reordered the information. An example
> of the new format:
> 
> main-c255126-gb81783dc98e6-dirty
>   \     \       \            \
>    \     \       \             local modifications
>     \     \        hash
>      \      commit count
>        branch
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
> 

From pete at nomadlogic.org  Tue Dec 29 00:56:03 2020
From: pete at nomadlogic.org (Pete Wright)
Date: Mon, 28 Dec 2020 16:56:00 -0800
Subject: git and the loss of revision numbers
In-Reply-To: <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com>
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
 <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org>
 <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org>
 <CAPyFy2DW0YDUK+kir2H_e8LVT-P-kQ0PMmKQO6m+016Wb=Hd0A@mail.gmail.com>
 <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com>
Message-ID: <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org>


On 12/28/20 4:38 PM, monochrome wrote:
> what would be the git command for reverting source to a previous 
> version using these numbers? for example, with svn and old numbers:
> svnlite update -r367627 /usr/src
>
I will generally just checkout the short git hash like so in my local 
checkout:
$ git checkout gb81783dc98e6

you can quickly get the hashes by running "git log" from your checkout.

cheers,
-pete

-- 
Pete Wright
pete at nomadlogic.org
@nomadlogicLA


From jmg at funkthat.com  Tue Dec 29 00:56:41 2020
From: jmg at funkthat.com (John-Mark Gurney)
Date: Mon, 28 Dec 2020 16:56:39 -0800
Subject: git and the loss of revision numbers
In-Reply-To: <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com>
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
 <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org>
 <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org>
 <CAPyFy2DW0YDUK+kir2H_e8LVT-P-kQ0PMmKQO6m+016Wb=Hd0A@mail.gmail.com>
 <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com>
Message-ID: <20201229005639.GS31099@funkthat.com>

monochrome wrote this message on Mon, Dec 28, 2020 at 19:38 -0500:
> what would be the git command for reverting source to a previous version 
> using these numbers? for example, with svn and old numbers:
> svnlite update -r367627 /usr/src
> 
> this is needed often when it blows up for someone tracking current

Get the hash from a commit number:
$git rev-list --reverse HEAD | tail -n +255241 | head -n 1
3cc0c0d66a065554459bd2f9b4f80cc07426464a

so:
git checkout $(git rev-list --reverse HEAD | tail -n +255240 | head -n 1)

> On 12/28/20 11:27 AM, Ed Maste wrote:
> > On Mon, 28 Dec 2020 at 07:08, Renato Botelho <garga at freebsd.org> wrote:
> >>
> >> FreeBSD bast.garga.net.br 13.0-CURRENT FreeBSD 13.0-CURRENT #19
> >> 3cc0c0d66a0-c255241(main)-dirty:
> >>               ^
> >>               This is an incremental counter of commits
> > 
> > Also, uqs@ recently fixed an issue in newvers.sh (including the final,
> > non-updating svn revision) and reordered the information. An example
> > of the new format:
> > 
> > main-c255126-gb81783dc98e6-dirty
> >   \     \       \            \
> >    \     \       \             local modifications
> >     \     \        hash
> >      \      commit count
> >        branch

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

From jmg at funkthat.com  Tue Dec 29 01:03:28 2020
From: jmg at funkthat.com (John-Mark Gurney)
Date: Mon, 28 Dec 2020 17:03:25 -0800
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <X+M0yPrCJ5Rz/V85@home.opsec.eu>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org>
 <CANCZdfrF0B7uux_neg-4XGn2UCDd4noUm7zP_icHnrpZUgmzzA@mail.gmail.com>
 <CAOtMX2gV2dmyG4b1hZG24sUnqDVk=1pch4xgQmyUdtLrh48kYg@mail.gmail.com>
 <CANCZdfpb0MF+uoW=K3cQpL+3vNQjSBDeVMab5d4JJhUO4sy-2Q@mail.gmail.com>
 <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com>
 <20201218175241.GA72552@spindle.one-eyed-alien.net>
 <20201218182820.1P0tK%steffen@sdaoden.eu>
 <20201223023242.GG31099@funkthat.com>
 <X+M0yPrCJ5Rz/V85@home.opsec.eu>
Message-ID: <20201229010325.GT31099@funkthat.com>

Kurt Jaeger wrote this message on Wed, Dec 23, 2020 at 13:15 +0100:
> Hi!
> 
> > It's also hard to collect ALL the keys of the devs at any point in
> > time to decide if that key is authorized to sign a commit in the
> > repo...
> 
> We do have most of the keys in docs/share/pgpkeys/ plus history.
> 
> > Like if a dev starts in 2021, any commits made by that
> > dev prior to 2021 should not be "valid"..  Then there's also the
> > issue that people's keys change over time, and now you need to know
> > what time period each key was valid for, otherwise a compromised key
> > could be used to insert malicious changes into your/the tree...
> 
> If we manage keys plus their history in the doc repo, this seems
> to be solved.

The data is there, but are you going to write a tool such that it can
be verified?

Then you have the job of verifying the doc repo to make sure that the
keys you have is valid, where does the root of trust come from there?

Not saying it isn't possible, it's just a LOT of work to make it
useful...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

From david at catwhisker.org  Tue Dec 29 01:06:34 2020
From: david at catwhisker.org (David Wolfskill)
Date: Mon, 28 Dec 2020 17:06:26 -0800
Subject: git and the loss of revision numbers
In-Reply-To: <20201229005639.GS31099@funkthat.com>
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
 <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org>
 <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org>
 <CAPyFy2DW0YDUK+kir2H_e8LVT-P-kQ0PMmKQO6m+016Wb=Hd0A@mail.gmail.com>
 <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com>
 <20201229005639.GS31099@funkthat.com>
Message-ID: <X+qBEmvOpuUmqAew@albert.catwhisker.org>

On Mon, Dec 28, 2020 at 04:56:39PM -0800, John-Mark Gurney wrote:
> monochrome wrote this message on Mon, Dec 28, 2020 at 19:38 -0500:
> > what would be the git command for reverting source to a previous version 
> > using these numbers? for example, with svn and old numbers:
> > svnlite update -r367627 /usr/src
> > 
> > this is needed often when it blows up for someone tracking current
> 
> Get the hash from a commit number:
> $git rev-list --reverse HEAD | tail -n +255241 | head -n 1
> 3cc0c0d66a065554459bd2f9b4f80cc07426464a
> 
> so:
> git checkout $(git rev-list --reverse HEAD | tail -n +255240 | head -n 1)
> ....

Or save a process:

git rev-list --reverse HEAD | awk 'NR == 255241 {print; exit 0}'
3cc0c0d66a065554459bd2f9b4f80cc07426464a

(And thus:
git checkout $(git rev-list --reverse HEAD | awk 'NR == 255241 {print; exit 0}')

Could also pass the number to awk via the "-v var=value" command-line.)

Peace,
david
-- 
David H. Wolfskill                              david at catwhisker.org
While Trump successfully conned a lot of people for a while, in the
end he's just a failure throwing a temper tantrum because he lost.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20201228/7df45f0b/attachment.sig>

From jmg at funkthat.com  Tue Dec 29 01:19:43 2020
From: jmg at funkthat.com (John-Mark Gurney)
Date: Mon, 28 Dec 2020 17:19:39 -0800
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <20201223162417.v7Ce6%steffen@sdaoden.eu>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org>
 <CANCZdfrF0B7uux_neg-4XGn2UCDd4noUm7zP_icHnrpZUgmzzA@mail.gmail.com>
 <CAOtMX2gV2dmyG4b1hZG24sUnqDVk=1pch4xgQmyUdtLrh48kYg@mail.gmail.com>
 <CANCZdfpb0MF+uoW=K3cQpL+3vNQjSBDeVMab5d4JJhUO4sy-2Q@mail.gmail.com>
 <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com>
 <20201218175241.GA72552@spindle.one-eyed-alien.net>
 <20201218182820.1P0tK%steffen@sdaoden.eu>
 <20201223023242.GG31099@funkthat.com>
 <20201223162417.v7Ce6%steffen@sdaoden.eu>
Message-ID: <20201229011939.GU31099@funkthat.com>

Steffen Nurpmeso wrote this message on Wed, Dec 23, 2020 at 17:24 +0100:
>  |Then there's also the point that the repo is (looks like it) using
>  |SHA-1 hashes, which are effectively broken, so depending upon them
>  |to validate the tree is questionable anyways.
> 
> git uses the hardened SHA-1 for sure, which is, as far as i know,
> at least safe against the known attack.
> I .. have not tracked this, but i think upgrading to SHA-256 is
> possible, once this will become standard.  Just even more
> metadata, then.  I have not looked into this, still in progress.

A new attack came out earlier this year:
https://eprint.iacr.org/2020/014.pdf

>From the paper:
> In particular, chosen-prefix collisions can break signature schemes and
> handshake security in secure channel protocols (TLS, SSH), if generated
> extremely quickly.

The previous attack in 2017 did not break SHA-1 enough to render it's
use by git vulnerable, but the writing was on the wall for SHA-1...

I believe this new attack makes git's use a SHA-1 vulnerable...
The type/length prefix that prevented the previous attacks from
working is not effective against the new attack...

Also, the cost of the attack is not great ($45k), considering the recent
SolarWinds supply chain attack, being able to smuggle a modified file
into a git repo, say an OS's build server, such that the tools don't
know the tree is modified is a real problem...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

From imp at bsdimp.com  Tue Dec 29 01:37:23 2020
From: imp at bsdimp.com (Warner Losh)
Date: Mon, 28 Dec 2020 18:37:08 -0700
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <20201229011939.GU31099@funkthat.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org>
 <CANCZdfrF0B7uux_neg-4XGn2UCDd4noUm7zP_icHnrpZUgmzzA@mail.gmail.com>
 <CAOtMX2gV2dmyG4b1hZG24sUnqDVk=1pch4xgQmyUdtLrh48kYg@mail.gmail.com>
 <CANCZdfpb0MF+uoW=K3cQpL+3vNQjSBDeVMab5d4JJhUO4sy-2Q@mail.gmail.com>
 <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com>
 <20201218175241.GA72552@spindle.one-eyed-alien.net>
 <20201218182820.1P0tK%steffen@sdaoden.eu>
 <20201223023242.GG31099@funkthat.com>
 <20201223162417.v7Ce6%steffen@sdaoden.eu>
 <20201229011939.GU31099@funkthat.com>
Message-ID: <CANCZdfodE7ePTqN4SOOhAyep0SqqCNdbHpJspNvwGyV_upw+4A@mail.gmail.com>

On Mon, Dec 28, 2020, 6:19 PM John-Mark Gurney <jmg at funkthat.com> wrote:

> Steffen Nurpmeso wrote this message on Wed, Dec 23, 2020 at 17:24 +0100:
> >  |Then there's also the point that the repo is (looks like it) using
> >  |SHA-1 hashes, which are effectively broken, so depending upon them
> >  |to validate the tree is questionable anyways.
> >
> > git uses the hardened SHA-1 for sure, which is, as far as i know,
> > at least safe against the known attack.
> > I .. have not tracked this, but i think upgrading to SHA-256 is
> > possible, once this will become standard.  Just even more
> > metadata, then.  I have not looked into this, still in progress.
>
> A new attack came out earlier this year:
> https://eprint.iacr.org/2020/014.pdf
>
> From the paper:
> > In particular, chosen-prefix collisions can break signature schemes and
> > handshake security in secure channel protocols (TLS, SSH), if generated
> > extremely quickly.
>
> The previous attack in 2017 did not break SHA-1 enough to render it's
> use by git vulnerable, but the writing was on the wall for SHA-1...
>
> I believe this new attack makes git's use a SHA-1 vulnerable...
> The type/length prefix that prevented the previous attacks from
> working is not effective against the new attack...
>
> Also, the cost of the attack is not great ($45k), considering the recent
> SolarWinds supply chain attack, being able to smuggle a modified file
> into a git repo, say an OS's build server, such that the tools don't
> know the tree is modified is a real problem...
>

Yea. The git transition team knew about these issues (though the referenced
paper is new). Too bad git's SHA-256 stuff is too immature to use yet at
scale, coupled with requiring a super new git version to even test it out.
Plus, much of the greater git ecosystem simply doesn't support SHA-256 yet.
We should, as a project, continue to test how well it works and monitor the
ecosystem for a transition in a few years when it is robust...

Warner

-- 
>   John-Mark Gurney                              Voice: +1 415 225 5579
>
>      "All that I will do, has been done, All that I have, has not."
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>

From monochrome at twcny.rr.com  Tue Dec 29 03:12:53 2020
From: monochrome at twcny.rr.com (monochrome)
Date: Mon, 28 Dec 2020 22:12:44 -0500
Subject: git and the loss of revision numbers
In-Reply-To: <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org>
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
 <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org>
 <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org>
 <CAPyFy2DW0YDUK+kir2H_e8LVT-P-kQ0PMmKQO6m+016Wb=Hd0A@mail.gmail.com>
 <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com>
 <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org>
Message-ID: <9087b1bb-9e44-bb61-4514-72f99a36d1f5@twcny.rr.com>

this didn't seem to work, and now git is saying: You are not currently 
on a branch.
since the incremental numbers aren't in the git log does it make more 
sense to use the short hash like this? other different responses were 
focused on the incremental commit number.
Also, I saw someone mention that a 12 digit shortened hash is the 
standard to use, yet uname only spits out 9?
thanks

On 12/28/20 7:56 PM, Pete Wright wrote:
> 
> On 12/28/20 4:38 PM, monochrome wrote:
>> what would be the git command for reverting source to a previous 
>> version using these numbers? for example, with svn and old numbers:
>> svnlite update -r367627 /usr/src
>>
> I will generally just checkout the short git hash like so in my local 
> checkout:
> $ git checkout gb81783dc98e6
> 
> you can quickly get the hashes by running "git log" from your checkout.
> 
> cheers,
> -pete
> 

From monochrome at twcny.rr.com  Tue Dec 29 03:33:26 2020
From: monochrome at twcny.rr.com (monochrome)
Date: Mon, 28 Dec 2020 22:33:22 -0500
Subject: git and the loss of revision numbers
In-Reply-To: <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org>
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
 <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org>
 <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org>
 <CAPyFy2DW0YDUK+kir2H_e8LVT-P-kQ0PMmKQO6m+016Wb=Hd0A@mail.gmail.com>
 <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com>
 <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org>
Message-ID: <8fb16182-e590-6bf0-747f-bc820dea1a3e@twcny.rr.com>

sry forgot details:

source tree @ ead01bfe8

git -C /usr/src checkout gf20c0e331
error: pathspec 'gf20c0e331' did not match any file(s) known to git

what is the 'g' for?

git -C /usr/src checkout f20c0e331
M       sys/amd64/conf/GENERIC
HEAD is now at f20c0e331 caroot: drop $FreeBSD$ expansion from root bundle

yet I don't see any indication that anything changed, and now it wont 
update at all:

git -C /usr/src pull --ff-only
You are not currently on a branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.

     git pull <remote> <branch>



On 12/28/20 7:56 PM, Pete Wright wrote:
> 
> On 12/28/20 4:38 PM, monochrome wrote:
>> what would be the git command for reverting source to a previous 
>> version using these numbers? for example, with svn and old numbers:
>> svnlite update -r367627 /usr/src
>>
> I will generally just checkout the short git hash like so in my local 
> checkout:
> $ git checkout gb81783dc98e6
> 
> you can quickly get the hashes by running "git log" from your checkout.
> 
> cheers,
> -pete
> 

From blackfoxx at online.de  Tue Dec 29 09:11:31 2020
From: blackfoxx at online.de (blackfoxx)
Date: Tue, 29 Dec 2020 10:12:42 +0100
Subject: Need some help with audio/sound (to get S/PDIF Toslink to work).
Message-ID: <f715ffa6-f110-bf56-a583-959cf9bc74aa@online.de>

Hi there.

I'm using FreeBSD (13.0-CURRENT) since 09/2020 at my Raspberry Pi 4B as 
Home-and-Web-Server-OS with Apache, PHP, SQLite etc... And it works like 
a charm!

Furthermore I'm trying to switch with my main workstation from Win10 to 
FreeBSD too. Because the more I'm working with FreeBSD, the more I 
realize that it's the only sane OS out there.
Now, I really would like to remove my Win10 Installation, but 
unfortunately I still have an issue with FreeBSD 13.0-CURRENT for which 
I can't find solutions, even after reading the whole handbook and 
searching the www for weeks:

I've got an "SoundBlaster Audigy Rx" Soundcard with "Creative E-MU 
CA10300" Chipset, using the BSDs "EMU10Kx" Kernel Module.
The mixer shows all in/outputs right and volume-control of all analog 
I/Os is working fine with my "Behringer MS40" Speakers and "Alienware 
TactX" Headset.
BUT the digital output (S/PDIF, Toslink) does NOT work. Even if I set 
dig1/dig2/dig3 and all other outputs to "100:100" within the mixer - 
still no sound via Toslink.
With Devuan (ALSA) or Win10 (native Creative Driver) it is working 
properly. So it can't be a hardware issue.
I also tried OSS, ALSA and PulseAudio with FreeBSD, searched the web for 
hours, tried this and that, but still no sound via Toslink...
(Fortunately) this is the only Hardware-Issue I have. But it is 
important to me to get S/PDIF Toslink to work!

I hope that someone around here can give me some hints, advice, solutions...

Regards, blackfoxx


My Hardware-Setup:
http://www.sysprofile.de/id182580


dmesg.boot:
[1] ---<<BOOT>>---
[1] Copyright (c) 1992-2020 The FreeBSD Project.
[1] Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
[1] The Regents of the University of California. All rights reserved.
[1] FreeBSD is a registered trademark of The FreeBSD Foundation.
[1] FreeBSD 13.0-CURRENT #0 : Sat Dec 26 23:08:09 UTC 2020
[1] FreeBSD clang version 11.0.0 (git at github.com:llvm/llvm-project.git 
llvmorg-11.0.0-rc2-0-g414f32a9e86)
[1] WARNING: WITNESS option enabled, expect reduced performance.
[1] VT(efifb): resolution 1280x800
[1] FreeBSD: initialize and check features (__FreeBSD_version 1300133).
[1] CPU: Intel(R) Core(TM) i7-3820 CPU @ 3.60GHz (3200.19-MHz K8-class CPU)
[1] Origin="GenuineIntel" Id=0x206d7 Family=0x6 Model=0x2d Stepping=7
[1]Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
[1]Features2=0x1fbee3bf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX>
[1] AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
[1] AMD Features2=0x1<LAHF>
[1] XSAVE Features=0x1<XSAVEOPT>
[1] VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
[1] TSC: P-state invariant, performance statistics
[1] real memory = 17179869184 (16384 MB)
[1] avail memory = 16491573248 (15727 MB)
[1] Event timer "LAPIC" quality 600
[1] ACPI APIC Table: <INTEL DX79TO >
[1] FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
[1] FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 hardware threads
[1] FreeBSD/SMP Online: 1 package(s) x 4 core(s)
[1] random: unblocking device.
[1] Firmware Warning (ACPI): 32/64X length mismatch in 
FADT/Pm1aEventBlock: 32/16 (20201113/tbfadt-748)
[1] Firmware Warning (ACPI): 32/64X length mismatch in 
FADT/PmTimerBlock: 32/24 (20201113/tbfadt-748)
[1] Firmware Warning (ACPI): Invalid length for FADT/Pm1aEventBlock: 16, 
using default 32 (20201113/tbfadt-850)
[1] Firmware Warning (ACPI): Invalid length for FADT/PmTimerBlock: 24, 
using default 32 (20201113/tbfadt-850)
[1] ioapic1 <Version 2.0> irqs 24-47
[1] ioapic0 <Version 2.0> irqs 0-23
[1] Launching APs: 2 1 3
[1] random: entropy device external interface
[1] WARNING: Device "kbd" is Giant locked and may be deleted before 
FreeBSD 13.0.
[1] kbd1 at kbdmux0
[1] 000.000039 [4346] netmap_init netmap: loaded module
[1] [ath_hal] loaded
[1] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX 
platforms 440.100 Fri May 29 08:11:49 UTC 2020
[1] nexus0
[1] efirtc0: <EFI Realtime Clock>
[1] efirtc0: registered as a time-of-day clock, resolution 1.000000s
[1] cryptosoft0: <software crypto>
[1] aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS>
[1] acpi0: <INTEL DX79TO>
[1] acpi0: Power Button (fixed)
[1] cpu0: <ACPI CPU> on acpi0
[1] atrtc0: <AT realtime clock> port 0x70-0x71,0x74-0x77 irq 8 on acpi0
[1] atrtc0: registered as a time-of-day clock, resolution 1.000000s
[1] Event timer "RTC" frequency 32768 Hz quality 0
[1] attimer0: <AT timer> port 0x40-0x43,0x50-0x53 irq 0 on acpi0
[1] Timecounter "i8254" frequency 1193182 Hz quality 0
[1] Event timer "i8254" frequency 1193182 Hz quality 100
[1] hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed03fff on acpi0
[1] Timecounter "HPET" frequency 14318180 Hz quality 950
[1] Event timer "HPET" frequency 14318180 Hz quality 550
[1] Event timer "HPET1" frequency 14318180 Hz quality 440
[1] Event timer "HPET2" frequency 14318180 Hz quality 440
[1] Event timer "HPET3" frequency 14318180 Hz quality 440
[1] Event timer "HPET4" frequency 14318180 Hz quality 440
[1] Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
[1] acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
[1] acpi_button0: <Sleep Button> on acpi0
[1] pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
[1] pci0: <ACPI PCI bus> on pcib0
[1] pcib1: <ACPI PCI-PCI bridge> at device 1.0 on pci0
[1] pci1: <ACPI PCI bus> on pcib1
[1] pcib2: <ACPI PCI-PCI bridge> at device 1.1 on pci0
[1] pci2: <ACPI PCI bus> on pcib2
[1] xhci0: <NEC uPD720200 USB 3.0 controller> mem 0xeb300000-0xeb301fff 
irq 16 at device 0.0 on pci2
[1] xhci0: 32 bytes context size, 32-bit DMA
[1] usbus0: waiting for BIOS to give up control
[1] usbus0 on xhci0
[1] usbus0: 5.0Gbps Super Speed USB v3.0
[1] pcib3: <ACPI PCI-PCI bridge> at device 2.0 on pci0
[1] pci3: <ACPI PCI bus> on pcib3
[1] xhci1: <XHCI (generic) USB 3.0 controller> mem 0xeb200000-0xeb201fff 
irq 16 at device 0.0 on pci3
[1] xhci1: 64 bytes context size, 32-bit DMA
[1] usbus1: waiting for BIOS to give up control
[1] usbus1: timed out waiting for BIOS
[1] usbus1 on xhci1
[1] usbus1: 5.0Gbps Super Speed USB v3.0
[1] pcib4: <ACPI PCI-PCI bridge> at device 3.0 on pci0
[1] pci4: <ACPI PCI bus> on pcib4
[1] vgapci0: <VGA-compatible display> port 0x2000-0x207f mem 
0xea000000-0xeaffffff,0xe0000000-0xe7ffffff,0xe8000000-0xe9ffffff irq 16 
at device 0.0 on pci4
[1] nvidia0: <Unknown> on vgapci0
[1] vgapci0: child nvidia0 requested pci_enable_io
[1] vgapci0: child nvidia0 requested pci_enable_io
[1] vgapci0: Boot video device
[1] hdac0: <NVIDIA (0x0e0a) HDA Controller> mem 0xeb000000-0xeb003fff 
irq 17 at device 0.1 on pci4
[1] pcib5: <ACPI PCI-PCI bridge> at device 17.0 on pci0
[1] pci5: <ACPI PCI bus> on pcib5
[1] pci0: <simple comms> at device 22.0 (no driver attached)
[1] em0: <Intel(R) PRO/1000 Network Connection> port 0x3040-0x305f mem 
0xeb400000-0xeb41ffff,0xeb421000-0xeb421fff irq 20 at device 25.0 on pci0
[1] em0: Using 1024 TX descriptors and 1024 RX descriptors
[1] em0: Using an MSI interrupt
[1] em0: Ethernet address: 54:be:f7:08:d6:34
[1] em0: netmap queues/slots: TX 1/1024, RX 1/1024
[1] ehci0: <Intel Patsburg USB 2.0 controller> mem 0xeb501000-0xeb5013ff 
irq 16 at device 26.0 on pci0
[1] usbus2: EHCI version 1.0
[1] usbus2 on ehci0
[1] usbus2: 480Mbps High Speed USB v2.0
[1] pcib6: <ACPI PCI-PCI bridge> at device 28.0 on pci0
[1] pci6: <ACPI PCI bus> on pcib6
[1] pcib7: <PCI-PCI bridge> mem 0xeb100000-0xeb10ffff at device 0.0 on pci6
[1] pci7: <PCI bus> on pcib7
[1] emu10kx0: <Creative Audigy 2 Value (Unknown model) [SB????]> port 
0x1000-0x103f irq 16 at device 0.0 on pci7
[1] pcm0: <EMU10Kx DSP front PCM interface> on emu10kx0
[1] pcm0: <SigmaTel STAC9750/51 AC97 Codec>
[1] pcm1: <EMU10Kx DSP rear PCM interface> on emu10kx0
[1] pcm2: <EMU10Kx DSP center PCM interface> on emu10kx0
[1] pcm3: <EMU10Kx DSP subwoofer PCM interface> on emu10kx0
[1] ehci1: <Intel Patsburg USB 2.0 controller> mem 0xeb502000-0xeb5023ff 
irq 23 at device 29.0 on pci0
[1] usbus3: EHCI version 1.0
[1] usbus3 on ehci1
[1] usbus3: 480Mbps High Speed USB v2.0
[1] pcib8: <ACPI PCI-PCI bridge> at device 30.0 on pci0
[1] pci8: <ACPI PCI bus> on pcib8
[1] isab0: <PCI-ISA bridge> at device 31.0 on pci0
[1] isa0: <ISA bus> on isab0
[1] ahci0: <Intel Patsburg AHCI SATA controller> port 
0x3068-0x306f,0x3074-0x3077,0x3060-0x3067,0x3070-0x3073,0x3020-0x303f 
mem 0xeb423000-0xeb4237ff irq 18 at device 31.2 on pci0
[1] ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported
[1] ahcich0: <AHCI channel> at channel 0 on ahci0
[1] ahcich1: <AHCI channel> at channel 1 on ahci0
[1] ahcich2: <AHCI channel> at channel 2 on ahci0
[1] ahcich3: <AHCI channel> at channel 3 on ahci0
[1] ahcich4: <AHCI channel> at channel 4 on ahci0
[1] ahcich5: <AHCI channel> at channel 5 on ahci0
[1] ahciem0: <AHCI enclosure management bridge> on ahci0
[1] tpm0: <Trusted Platform Module> iomem 0xfed40000-0xfed44fff on acpi0
[1] tpm: WEC WPCT200 rev 0x46
[1] WARNING: Device "tpm" is Giant locked and may be deleted before 
FreeBSD 13.0.
[1] orm0: <ISA Option ROM> at iomem 0xd1800-0xd27ff pnpid ORM0000 on isa0
[1] atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
[1] atkbd0: <AT Keyboard> irq 1 on atkbdc0
[1] kbd0 at atkbd0
[1] atkbd0: [GIANT-LOCKED]
[1] coretemp0: <CPU On-Die Thermal Sensors> on cpu0
[1] est0: <Enhanced SpeedStep Frequency Control> on cpu0
[1] Timecounters tick every 1.000 msec
[1] hdacc0: <NVIDIA (0x0040) HDA CODEC> at cad 0 on hdac0
[1] hdaa0: <NVIDIA (0x0040) Audio Function Group> at nid 1 on hdacc0
[1] pcm4: <NVIDIA (0x0040) (HDMI/DP 8ch)> at nid 4 on hdaa0
[1] pcm5: <NVIDIA (0x0040) (HDMI/DP 8ch)> at nid 5 on hdaa0
[1] pcm6: <NVIDIA (0x0040) (HDMI/DP 8ch)> at nid 6 on hdaa0
[1] pcm7: <NVIDIA (0x0040) (HDMI/DP 8ch)> at nid 7 on hdaa0
[1] Trying to mount root from ufs:/dev/ada1p2 [rw]...
[1] Root mount waiting for: usbus0 usbus1 usbus2 usbus3 CAM
[1] WARNING: WITNESS option enabled, expect reduced performance.
[1] ugen0.1: <0x1033 XHCI root HUB> at usbus0
[1] ugen2.1: <Intel EHCI root HUB> at usbus2
[1] ugen1.1: <0x1912 XHCI root HUB> at usbus1
[1] uhub0 on usbus2
[1] uhub0: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus2
[1] uhub1 on usbus0
[1] uhub1: <0x1033 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on 
usbus0
[1] uhub2 on usbus1
[1] uhub2: <0x1912 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on 
usbus1
[1] ugen3.1: <Intel EHCI root HUB> at usbus3
[1] uhub3 on usbus3
[1] uhub3: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus3
[1] ses0 at ahciem0 bus 0 scbus6 target 0 lun 0
ses0: <AHCI SGPIO Enclosure 2.00 0001> SEMB S-E-S 2.00 device
ses0: SEMB SES Device
[1] ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <Samsung SSD 840 EVO 250GB EXT0DB6Q> ACS-2 ATA SATA 3.x device
ada0: Serial Number S1DBNSAD998260X
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)
ada0: Command Queueing enabled
ada0: 238475MB (488397168 512 byte sectors)
ada0: quirks=0x3<4K,NCQ_TRIM_BROKEN>
[1] ada1 at ahcich1 bus 0 scbus1 target 0 lun 0
ada1: <SanDisk SDSSDA120G Z33130RL> ACS-2 ATA SATA 3.x device
ada1: Serial Number 172910A024C1
ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)
ada1: Command Queueing enabled
ada1: 114473MB (234441648 512 byte sectors)
[1] ses0: ada0 in 'Slot 00', SATA Slot: scbus0 target 0
[1] ses0: ada1 in 'Slot 01', SATA Slot: scbus1 target 0
[1] ada2 at ahcich5 bus 0 scbus5 target 0 lun 0
ada2: <ST2000DM002-1BJ164 CS41> ACS-2 ATA SATA 3.x device
ada2: Serial Number Z4Z7YY9Z
ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 512bytes)
ada2: Command Queueing enabled
ada2: 1907729MB (3907029168 512 byte sectors)
ada2: quirks=0x1<4K>
[1] ses0: (none) in 'Slot 03', SATA Slot: scbus3 target 0
[1] ses0: ada2 in 'Slot 05', SATA Slot: scbus5 target 0
[1] cd0 at ahcich3 bus 0 scbus3 target 0 lun 0
cd0: <PIONEER BD-RW BDR-S08 1.30> Removable CD-ROM SCSI device
cd0: Serial Number MDDL002204WL
cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes)
cd0: Attempt to query device size failed: NOT READY, Medium not present 
- tray closed
[1] uhub1: 4 ports with 4 removable, self powered
[1] uhub2: 8 ports with 8 removable, self powered
[2] uhub3: 2 ports with 2 removable, self powered
[2] uhub0: 2 ports with 2 removable, self powered
[2] Root mount waiting for: usbus2 usbus3
[2] ugen3.2: <vendor 0x8087 product 0x0024> at usbus3
[2] uhub4 on uhub3
[2] uhub4: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 
2> on usbus3
[3] ugen2.2: <vendor 0x8087 product 0x0024> at usbus2
[3] uhub5 on uhub0
[3] uhub5: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 
2> on usbus2
[3] Root mount waiting for: usbus2 usbus3
[3] uhub5: 6 ports with 6 removable, self powered
[4] uhub4: 8 ports with 8 removable, self powered
[4] ugen2.3: <SteelSeries Sensei Raw Gaming Mouse> at usbus2
[4] ukbd0 on uhub5
[4] ukbd0: <SteelSeries Sensei Raw Gaming Mouse, class 0/0, rev 
1.10/1.14, addr 3> on usbus2
[4] kbd2 at ukbd0
[5] Root mount waiting for: usbus2
[5] ugen2.4: <SteelSeries SteelSeries Apex Raw Gaming Keyboard> at usbus2
[5] ukbd1 on uhub5
[5] ukbd1: <SteelSeries SteelSeries Apex Raw Gaming Keyboard, class 0/0, 
rev 1.10/1.10, addr 4> on usbus2
[5] kbd3 at ukbd1
[5] mountroot: waiting for device /dev/ada1p2...
[6] lo0: link state changed to UP
[10] em0: link state changed to UP
[10] ichsmb0: <Intel Patsburg SMBus controller> port 0x3000-0x301f mem 
0xeb424000-0xeb4240ff irq 18 at device 31.3 on pci0
[10] smbus0: <System Management Bus> on ichsmb0
[10] acpi_wmi0: <ACPI-WMI mapping> on acpi0
[10] acpi_wmi0: cannot find EC device
[10] uhid0 on uhub5
[10] uhid0: <SteelSeries Sensei Raw Gaming Mouse, class 0/0, rev 
1.10/1.14, addr 3> on usbus2
[10] uhid1 on uhub5
[10] uhid1: <SteelSeries Sensei Raw Gaming Mouse, class 0/0, rev 
1.10/1.14, addr 3> on usbus2
[10] uhid2 on uhub5
[10] uhid2: <SteelSeries SteelSeries Apex Raw Gaming Keyboard, class 
0/0, rev 1.10/1.10, addr 4> on usbus2
[10] uhid3 on uhub5
[10] uhid3: <SteelSeries SteelSeries Apex Raw Gaming Keyboard, class 
0/0, rev 1.10/1.10, addr 4> on usbus2
[10] ums0 on uhub5
[10] ums0: <SteelSeries Sensei Raw Gaming Mouse, class 0/0, rev 
1.10/1.14, addr 3> on usbus2
[10] ums0: 8 buttons and [XYZ] coordinates ID=0
[11] ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default 
to deny, logging disabled
[11] Security policy loaded: MAC/ntpd (mac_ntpd)
[12] acquiring duplicate lock of same type: "os.lock_mtx"
[12] 1st os.lock_mtx @ nvidia_os.c:900
[12] 2nd os.lock_mtx @ nvidia_os.c:900
[12] stack backtrace:
[12] #0 0xffffffff80c80ce1 at witness_debugger+0x71
[12] #1 0xffffffff80bedc04 at __mtx_lock_flags+0x94
[12] #2 0xffffffff82e9f5fb at os_acquire_spinlock+0x1b
[12] #3 0xffffffff82dad14c at _nv033412rm+0xc

From fischerking1905 at yahoo.co.jp  Tue Dec 29 10:56:03 2020
From: fischerking1905 at yahoo.co.jp (fischerking1905 at yahoo.co.jp)
Date: Tue, 29 Dec 2020 19:55:54 +0900 (JST)
Subject: Need some help with audio/sound (to get S/PDIF Toslink to work).
In-Reply-To: <f715ffa6-f110-bf56-a583-959cf9bc74aa@online.de>
References: <f715ffa6-f110-bf56-a583-959cf9bc74aa@online.de>
Message-ID: <2006214503.1056432.1609239354553.JavaMail.yahoo@mail.yahoo.co.jp>

https://forums.freebsd.org/threads/console-player-and-s-pdif-toslink.63371/


From blackfoxx at online.de  Tue Dec 29 11:44:30 2020
From: blackfoxx at online.de (blackfoxx)
Date: Tue, 29 Dec 2020 12:45:48 +0100
Subject: Need some help with audio/sound (to get S/PDIF Toslink to work).
In-Reply-To: <2006214503.1056432.1609239354553.JavaMail.yahoo@mail.yahoo.co.jp>
References: <f715ffa6-f110-bf56-a583-959cf9bc74aa@online.de>
 <2006214503.1056432.1609239354553.JavaMail.yahoo@mail.yahoo.co.jp>
Message-ID: <ef834316-536f-a001-1611-621d5d1ee2c4@online.de>

Thank you.
I already read this thread while researching.
Doesn't help me, because not a single "Digital" output/device appears in 
my FreeBSD 13.0-CURRENT System:
pcm0: <EMU10Kx DSP front PCM interface> on emu10kx0
pcm0: <SigmaTel STAC9750/51 AC97 Codec>
pcm1: <EMU10Kx DSP rear PCM interface> on emu10kx0
pcm2: <EMU10Kx DSP center PCM interface> on emu10kx0
pcm3: <EMU10Kx DSP subwoofer PCM interface> on emu10kx0
These 4 or 5 are just analog outputs/devices.
Maybe the digital (S/PDIF, Toslink) issn't recognized by the system?!
But I don't know how to "make" it recognized by FreeBSD.
With Devuan (ALSA) and Win10 (Creative Driver) everything is working 
fine there.
I also tried OSS, ALSA and PulseAudio with FreeBSD, but no chance to 
make it work.

Am 29.12.2020 um 11:55 schrieb fischerking1905 at yahoo.co.jp:
> https://forums.freebsd.org/threads/console-player-and-s-pdif-toslink.63371/
> 
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
> 

From kp at FreeBSD.org  Tue Dec 29 12:15:06 2020
From: kp at FreeBSD.org (Kristof Provost)
Date: Tue, 29 Dec 2020 13:15:03 +0100
Subject: git and the loss of revision numbers
In-Reply-To: <8fb16182-e590-6bf0-747f-bc820dea1a3e@twcny.rr.com>
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
 <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org>
 <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org>
 <CAPyFy2DW0YDUK+kir2H_e8LVT-P-kQ0PMmKQO6m+016Wb=Hd0A@mail.gmail.com>
 <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com>
 <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org>
 <8fb16182-e590-6bf0-747f-bc820dea1a3e@twcny.rr.com>
Message-ID: <84B2B085-97FD-4C63-96C5-0B65371060B7@FreeBSD.org>

On 29 Dec 2020, at 4:33, monochrome wrote:
> sry forgot details:
>
> source tree @ ead01bfe8
>
> git -C /usr/src checkout gf20c0e331
> error: pathspec 'gf20c0e331' did not match any file(s) known to git
>
> what is the 'g' for?
>
That would have been a typo, I think.

> git -C /usr/src checkout f20c0e331
> M       sys/amd64/conf/GENERIC
> HEAD is now at f20c0e331 caroot: drop $FreeBSD$ expansion from root 
> bundle
>
> yet I don't see any indication that anything changed, and now it wont 
> update at all:
>
If something went wrong there?d be error output.
Git is *fast*, which can lead you to assume it?s not done anything 
when it has in fact done exactly what you asked. You should be on that 
commit now.

> git -C /usr/src pull --ff-only
> You are not currently on a branch.
> Please specify which branch you want to merge with.
> See git-pull(1) for details.
>
>     git pull <remote> <branch>

Yes, you can?t merge to a detached head. Return to your original 
branch (presumably git checkout main) and then pull.

Regards,
Kristof

From monochrome at twcny.rr.com  Tue Dec 29 13:28:44 2020
From: monochrome at twcny.rr.com (monochrome)
Date: Tue, 29 Dec 2020 08:28:40 -0500
Subject: git and the loss of revision numbers
In-Reply-To: <84B2B085-97FD-4C63-96C5-0B65371060B7@FreeBSD.org>
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
 <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org>
 <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org>
 <CAPyFy2DW0YDUK+kir2H_e8LVT-P-kQ0PMmKQO6m+016Wb=Hd0A@mail.gmail.com>
 <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com>
 <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org>
 <8fb16182-e590-6bf0-747f-bc820dea1a3e@twcny.rr.com>
 <84B2B085-97FD-4C63-96C5-0B65371060B7@FreeBSD.org>
Message-ID: <755854ef-63bf-ad8f-f6a0-6af194e98bd6@twcny.rr.com>



On 12/29/20 7:15 AM, Kristof Provost wrote:
> On 29 Dec 2020, at 4:33, monochrome wrote:
>> sry forgot details:
>>
>> source tree @ ead01bfe8
>>
>> git -C /usr/src checkout gf20c0e331
>> error: pathspec 'gf20c0e331' did not match any file(s) known to git
>>
>> what is the 'g' for?
>>
> That would have been a typo, I think.
> 

the g is also in the uname output:

main-c421-gf20c0e331-dirty

>> git -C /usr/src checkout f20c0e331
>> M?????? sys/amd64/conf/GENERIC
>> HEAD is now at f20c0e331 caroot: drop $FreeBSD$ expansion from root 
>> bundle
>>
>> yet I don't see any indication that anything changed, and now it wont 
>> update at all:
>>
> If something went wrong there?d be error output.
> Git is *fast*, which can lead you to assume it?s not done anything when 
> it has in fact done exactly what you asked. You should be on that commit 
> now.
> 

that was the full output, and nothing showing that it changed/reverted 
any files, and the contents of /usr/src/.git/refs/heads/main is still 
ead01bfe8618e879b3b23c6cf9f026eadcc7d2b3

is there another place to find the current revision of the source? the 
point here is to revert to a previous known working state of the source 
tree exactly like svnlite update -rXXXXXX /usr/src
used to do, and svn could then update from that point again with the 
same command used to do regular update: svnlite update /usr/src

>> git -C /usr/src pull --ff-only
>> You are not currently on a branch.
>> Please specify which branch you want to merge with.
>> See git-pull(1) for details.
>>
>> ??? git pull <remote> <branch>
> 
> Yes, you can?t merge to a detached head. Return to your original branch 
> (presumably git checkout main) and then pull.
> 
> Regards,
> Kristof
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"

the point is, there are only 4 commands we need to do this entire thing 
and it should be ironed out:

1. initially download the source tree
2. get the current local source tree revision
3. update the local source tree
4. revert local source tree to previous state

thanks for your input!

From avg at FreeBSD.org  Tue Dec 29 14:37:55 2020
From: avg at FreeBSD.org (Andriy Gapon)
Date: Tue, 29 Dec 2020 16:37:49 +0200
Subject: git and the loss of revision numbers
In-Reply-To: <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org>
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
 <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org>
 <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org>
 <CAPyFy2DW0YDUK+kir2H_e8LVT-P-kQ0PMmKQO6m+016Wb=Hd0A@mail.gmail.com>
 <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com>
 <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org>
Message-ID: <e16ab2c2-d8fe-6b8c-56d4-789f0fa07041@FreeBSD.org>

On 2020-12-29 02:56, Pete Wright wrote:
> 
> On 12/28/20 4:38 PM, monochrome wrote:
>> what would be the git command for reverting source to a previous
>> version using these numbers? for example, with svn and old numbers:
>> svnlite update -r367627 /usr/src
>>
> I will generally just checkout the short git hash like so in my local
> checkout:
> $ git checkout gb81783dc98e6
> 
> you can quickly get the hashes by running "git log" from your checkout.

I think that git checkout <commit> is a wrong tool here.
I personally would use git reset --hard <commit>.
Note that that command would also revert any local uncommitted changes
as well!

My view of the difference between the commands:
- checkout: stage[*] a change that would modify the current state of the
branch to the selected commit's state
- reset: change the current branch (its head) to point to the selected
commit

[*] by stage I mean modify the working copy and the index.
That is, if after git checkout you would run git commit then you would
commit a change that reverts the current branch to the selected point.

-- 
Andriy



From monochrome at twcny.rr.com  Tue Dec 29 15:11:08 2020
From: monochrome at twcny.rr.com (monochrome)
Date: Tue, 29 Dec 2020 10:11:04 -0500
Subject: git and the loss of revision numbers
In-Reply-To: <e16ab2c2-d8fe-6b8c-56d4-789f0fa07041@FreeBSD.org>
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
 <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org>
 <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org>
 <CAPyFy2DW0YDUK+kir2H_e8LVT-P-kQ0PMmKQO6m+016Wb=Hd0A@mail.gmail.com>
 <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com>
 <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org>
 <e16ab2c2-d8fe-6b8c-56d4-789f0fa07041@FreeBSD.org>
Message-ID: <7bfab675-ddb4-bf53-d818-d35667c74522@twcny.rr.com>

ok, this appears to be what I was looking for

example:
git reset --hard f20c0e331
then:
git pull --ff-only
is again able to update as normal

I should point out also that this is from the point of view of any 
random person just building freebsd from source, not a developer, so 
there are no local changes. Though it does blow away changes to the conf 
file, that's a lesser issue to deal with.

thanks!

On 12/29/20 9:37 AM, Andriy Gapon wrote:
> On 2020-12-29 02:56, Pete Wright wrote:
>>
>> On 12/28/20 4:38 PM, monochrome wrote:
>>> what would be the git command for reverting source to a previous
>>> version using these numbers? for example, with svn and old numbers:
>>> svnlite update -r367627 /usr/src
>>>
>> I will generally just checkout the short git hash like so in my local
>> checkout:
>> $ git checkout gb81783dc98e6
>>
>> you can quickly get the hashes by running "git log" from your checkout.
> 
> I think that git checkout <commit> is a wrong tool here.
> I personally would use git reset --hard <commit>.
> Note that that command would also revert any local uncommitted changes
> as well!
> 
> My view of the difference between the commands:
> - checkout: stage[*] a change that would modify the current state of the
> branch to the selected commit's state
> - reset: change the current branch (its head) to point to the selected
> commit
> 
> [*] by stage I mean modify the working copy and the index.
> That is, if after git checkout you would run git commit then you would
> commit a change that reverts the current branch to the selected point.
> 

From naddy at mips.inka.de  Tue Dec 29 15:40:16 2020
From: naddy at mips.inka.de (Christian Weisgerber)
Date: Tue, 29 Dec 2020 16:36:05 +0100
Subject: git and the loss of revision numbers
In-Reply-To: <755854ef-63bf-ad8f-f6a0-6af194e98bd6@twcny.rr.com>
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
 <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org>
 <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org>
 <CAPyFy2DW0YDUK+kir2H_e8LVT-P-kQ0PMmKQO6m+016Wb=Hd0A@mail.gmail.com>
 <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com>
 <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org>
 <8fb16182-e590-6bf0-747f-bc820dea1a3e@twcny.rr.com>
 <84B2B085-97FD-4C63-96C5-0B65371060B7@FreeBSD.org>
 <755854ef-63bf-ad8f-f6a0-6af194e98bd6@twcny.rr.com>
Message-ID: <X+tM5eAADB5SeoQ1@lorvorc.mips.inka.de>

monochrome:

> the g is also in the uname output:
>
> main-c421-gf20c0e331-dirty

It's the brand new format: <branch>-c<count>-g<hash>[-dirty]

https://cgit.freebsd.org/src/commit/sys/conf/newvers.sh?id=8d405efd73d3991fe1647f91a2b7c9989dd5f18f

-- 
Christian "naddy" Weisgerber                          naddy at mips.inka.de

From avg at FreeBSD.org  Tue Dec 29 17:38:34 2020
From: avg at FreeBSD.org (Andriy Gapon)
Date: Tue, 29 Dec 2020 19:38:27 +0200
Subject: git and the loss of revision numbers
In-Reply-To: <7bfab675-ddb4-bf53-d818-d35667c74522@twcny.rr.com>
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
 <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org>
 <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org>
 <CAPyFy2DW0YDUK+kir2H_e8LVT-P-kQ0PMmKQO6m+016Wb=Hd0A@mail.gmail.com>
 <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com>
 <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org>
 <e16ab2c2-d8fe-6b8c-56d4-789f0fa07041@FreeBSD.org>
 <7bfab675-ddb4-bf53-d818-d35667c74522@twcny.rr.com>
Message-ID: <0adec2d2-acfb-9a3f-da69-aff7915ea67d@FreeBSD.org>

On 2020-12-29 17:11, monochrome wrote:
> ok, this appears to be what I was looking for
> 
> example:
> git reset --hard f20c0e331
> then:
> git pull --ff-only
> is again able to update as normal
> 
> I should point out also that this is from the point of view of any
> random person just building freebsd from source, not a developer, so
> there are no local changes. Though it does blow away changes to the conf
> file, that's a lesser issue to deal with.

git stash [save] and git stash pop can be used to try[*] to preserve
minor local changes.

[*] there can be merge conflicts after stash pop if the same file(s) are
changed upstream as well.

-- 
Andriy

From madpilot at FreeBSD.org  Tue Dec 29 18:12:42 2020
From: madpilot at FreeBSD.org (Guido Falsi)
Date: Tue, 29 Dec 2020 19:12:40 +0100
Subject: git and the loss of revision numbers
In-Reply-To: <0adec2d2-acfb-9a3f-da69-aff7915ea67d@FreeBSD.org>
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
 <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org>
 <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org>
 <CAPyFy2DW0YDUK+kir2H_e8LVT-P-kQ0PMmKQO6m+016Wb=Hd0A@mail.gmail.com>
 <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com>
 <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org>
 <e16ab2c2-d8fe-6b8c-56d4-789f0fa07041@FreeBSD.org>
 <7bfab675-ddb4-bf53-d818-d35667c74522@twcny.rr.com>
 <0adec2d2-acfb-9a3f-da69-aff7915ea67d@FreeBSD.org>
Message-ID: <aa5ae4c9-ac78-4ad4-593f-4a111d3146dc@FreeBSD.org>

On 29/12/20 18:38, Andriy Gapon wrote:
> On 2020-12-29 17:11, monochrome wrote:
>> ok, this appears to be what I was looking for
>>
>> example:
>> git reset --hard f20c0e331
>> then:
>> git pull --ff-only
>> is again able to update as normal
>>
>> I should point out also that this is from the point of view of any
>> random person just building freebsd from source, not a developer, so
>> there are no local changes. Though it does blow away changes to the conf
>> file, that's a lesser issue to deal with.
> 
> git stash [save] and git stash pop can be used to try[*] to preserve
> minor local changes.
> 
> [*] there can be merge conflicts after stash pop if the same file(s) are
> changed upstream as well.
> 

Anyone who already uses git knows this, probably, but for the sake of 
people who have no experience with it "git stash pop" behaviour can be 
startling(at least, it was for me when I first used it):

after a "git stash pop" which causes conflicts git will set up to 
actaully create a commit in the branch with the resolved conflict, which 
(usually for me) is not what one really wants.

I usually just do "git reset; git stash drop" in this case and then fix 
conflicts, to leave me with no extra commits, the changes in my checkout 
as I want them and no stashed ones (gt does not remove the stash until 
you commit the resolved changes, which, as I said is not what I want to 
do usually)

I hope I clearly explained this, and if this was obvious to everyone, 
sorry for the noise!

-- 
Guido Falsi <madpilot at FreeBSD.org>

From kostikbel at gmail.com  Tue Dec 29 19:26:40 2020
From: kostikbel at gmail.com (Konstantin Belousov)
Date: Tue, 29 Dec 2020 21:26:32 +0200
Subject: panic: Assertion pgrp->pg_jobc > 0 failed at kern_proc.c:816
In-Reply-To: <aa91221f-cfc6-6ba4-06d7-2251f52dd09c@FreeBSD.org>
References: <8f88c925-f12a-6a51-c2b3-c21c55de8dab@FreeBSD.org>
 <aa91221f-cfc6-6ba4-06d7-2251f52dd09c@FreeBSD.org>
Message-ID: <X+uC6DzgzEioKExN@kib.kiev.ua>

On Mon, Dec 28, 2020 at 12:44:18PM -0800, John Baldwin wrote:
> On 12/28/20 12:24 PM, John Baldwin wrote:
> > I got this panic again today in a VM when quitting a gdb
> > session after killing a child process via 'kill'.
> > 
> > panic: Assertion pgrp->pg_jobc > 0 failed at /git/bhyve/sys/kern/kern_proc.c:816
> > cpuid = 1
> > time = 1609185862
> > KDB: stack backtrace:
> > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00946547f0
> > vpanic() at vpanic+0x181/frame 0xfffffe0094654840
> > panic() at panic+0x43/frame 0xfffffe00946548a0
> > _refcount_update_saturated() at _refcount_update_saturated/frame 0xfffffe00946548e0
> > killjobc() at killjobc+0x6a6/frame 0xfffffe0094654940
> > exit1() at exit1+0x6af/frame 0xfffffe00946549b0
> > sys_sys_exit() at sys_sys_exit+0xd/frame 0xfffffe00946549c0
> > amd64_syscall() at amd64_syscall+0x12e/frame 0xfffffe0094654af0
> > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0094654af0
> > --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x8024c8f0a, rsp = 0x7fffffffe358, rbp = 0x7fffffffe370 ---
> > KDB: enter: panic
> > [ thread pid 44034 tid 102484 ]
> > Stopped at      kdb_enter+0x37: movq    $0,0x10ab066(%rip)
> > 
> > From what I can tell, the child process that was killed via 'kill' has
> > not yet exited and is stuck in ptracestop() from fork():
> > 
> > (kgdb) where
> > #0  sched_switch (td=0xfffffe0094001a00, flags=<optimized out>) at /git/bhyve/sys/kern/sched_ule.c:2147
> > #1  0xffffffff80bf4015 in mi_switch (flags=266) at /git/bhyve/sys/kern/kern_synch.c:542
> > #2  0xffffffff80bfeba5 in thread_suspend_switch (td=<optimized out>, p=<optimized out>)
> >     at /git/bhyve/sys/kern/kern_thread.c:1477
> > #3  0xffffffff80bef04b in ptracestop (td=0xfffffe0094001a00, sig=17, si=0x0)
> >     at /git/bhyve/sys/kern/kern_sig.c:2642
> > #4  0xffffffff80ba1a54 in fork_return (td=0xfffffe0094001a00, frame=0xfffffe0094671b00)
> >     at /git/bhyve/sys/kern/kern_fork.c:1106
> > #5  0xffffffff80ba18b0 in fork_exit (callout=0xffffffff80ba1950 <fork_return>, arg=0xfffffe0094001a00, 
> >     frame=0xfffffe0094671b00) at /git/bhyve/sys/kern/kern_fork.c:1069
> > #6  <signal handler called>
> > #7  0x00000008007b71aa in ?? ()
> > 
> > kgdb can't find the panicking process due to the zombproc removal, so I will
> > have to go work on kgdb to recover from that change. :(
> 
> I've come up with a shorter reproducer (original was trying to debug a perl script
> in OpenSSL's test suite).
> 
> Compile this program:
> 
> #include <sys/types.h>
> #include <sys/wait.h>
> #include <err.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
> 
> int
> main(void)
> {
> 	pid_t pid, wpid;
> 
> 	pid = fork();
> 	if (pid == -1)
> 		err(1, "fork");
> 	if (pid == 0) {
> 		printf("I'm in the child\n");
> 		exit(1);
> 	}
> 	printf("I'm in the parent\n");
> 	wpid = waitpid(pid, NULL, 0);
> 	if (wpid < 0)
> 		err(1, "waitpid");
> 
> 	return (0);
> }
> 
> Then in gdb do the following:
> 
> # gdb101 ./forktest
> ...
> (gdb) catch fork
> Catchpoint 1 (fork)
> (gdb) r
> Starting program: /mnt/forktest/forktest 
> 
> Catchpoint 1 (forked process 830), _fork () at _fork.S:4
> 4       _fork.S: No such file or directory.
> (gdb) kill
> Kill the program being debugged? (y or n) y
> [Inferior 1 (process 828) killed]
> (gdb) quit
> <panic>
> 
https://reviews.freebsd.org/D27816

From jhb at FreeBSD.org  Tue Dec 29 19:41:37 2020
From: jhb at FreeBSD.org (John Baldwin)
Date: Tue, 29 Dec 2020 11:41:34 -0800
Subject: git and the loss of revision numbers
In-Reply-To: <7bfab675-ddb4-bf53-d818-d35667c74522@twcny.rr.com>
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
 <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org>
 <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org>
 <CAPyFy2DW0YDUK+kir2H_e8LVT-P-kQ0PMmKQO6m+016Wb=Hd0A@mail.gmail.com>
 <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com>
 <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org>
 <e16ab2c2-d8fe-6b8c-56d4-789f0fa07041@FreeBSD.org>
 <7bfab675-ddb4-bf53-d818-d35667c74522@twcny.rr.com>
Message-ID: <eb886ba8-9b16-9351-fb13-6b625c4590c9@FreeBSD.org>

On 12/29/20 7:11 AM, monochrome wrote:
> ok, this appears to be what I was looking for
> 
> example:
> git reset --hard f20c0e331
> then:
> git pull --ff-only
> is again able to update as normal
> 
> I should point out also that this is from the point of view of any 
> random person just building freebsd from source, not a developer, so 
> there are no local changes. Though it does blow away changes to the conf 
> file, that's a lesser issue to deal with.

One other thing to consider is that if you are trying to track down
a regression, you can use 'git bisect' to do this and it will do
the binary search for you.  In the case of searching for a regression,
you will be better served by that tool than trying to use
'git reset --hard' directly.

The other approach you can use to avoid having to look up hashes would
be to create your own local tags each time you update.  Then you can
easily go back to that tag by name instead of having to look up the
hash.

-- 
John Baldwin

From steffen at sdaoden.eu  Tue Dec 29 21:05:03 2020
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Tue, 29 Dec 2020 22:04:54 +0100
Subject: HEADS UP: FreeBSD src repo transitioning to git this
 weekend
In-Reply-To: <20201229011939.GU31099@funkthat.com>
References: <CANCZdfrUsaw5jpN1ybpk0ADXdQYam0_NO0mPJd0-FMbuxPruhw@mail.gmail.com>
 <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org>
 <CANCZdfrF0B7uux_neg-4XGn2UCDd4noUm7zP_icHnrpZUgmzzA@mail.gmail.com>
 <CAOtMX2gV2dmyG4b1hZG24sUnqDVk=1pch4xgQmyUdtLrh48kYg@mail.gmail.com>
 <CANCZdfpb0MF+uoW=K3cQpL+3vNQjSBDeVMab5d4JJhUO4sy-2Q@mail.gmail.com>
 <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com>
 <20201218175241.GA72552@spindle.one-eyed-alien.net>
 <20201218182820.1P0tK%steffen@sdaoden.eu>
 <20201223023242.GG31099@funkthat.com>
 <20201223162417.v7Ce6%steffen@sdaoden.eu>
 <20201229011939.GU31099@funkthat.com>
Message-ID: <20201229210454.Lh4y_%steffen@sdaoden.eu>

John-Mark Gurney wrote in
 <20201229011939.GU31099 at funkthat.com>:
 |Steffen Nurpmeso wrote this message on Wed, Dec 23, 2020 at 17:24 +0100:
 |>|Then there's also the point that the repo is (looks like it) using
 |>|SHA-1 hashes, which are effectively broken, so depending upon them
 |>|to validate the tree is questionable anyways.
 |> 
 |> git uses the hardened SHA-1 for sure, which is, as far as i know,
 |> at least safe against the known attack.
 |> I .. have not tracked this, but i think upgrading to SHA-256 is
 |> possible, once this will become standard.  Just even more
 |> metadata, then.  I have not looked into this, still in progress.
 |
 |A new attack came out earlier this year:
 |https://eprint.iacr.org/2020/014.pdf

Impressive document.  Not a mathematician here, but still.

 |>From the paper:
 |> In particular, chosen-prefix collisions can break signature schemes and
 |> handshake security in secure channel protocols (TLS, SSH), if generated
 |> extremely quickly.
 |
 |The previous attack in 2017 did not break SHA-1 enough to render it's
 |use by git vulnerable, but the writing was on the wall for SHA-1...
 |
 |I believe this new attack makes git's use a SHA-1 vulnerable...
 |The type/length prefix that prevented the previous attacks from
 |working is not effective against the new attack...
 |
 |Also, the cost of the attack is not great ($45k), considering the recent

Ha.

 |SolarWinds supply chain attack, being able to smuggle a modified file
 |into a git repo, say an OS's build server, such that the tools don't
 |know the tree is modified is a real problem...

SHA-256 arrives, if you look at the git history.  Until then
signing a git tag even with SHA-1 is better than being unsealed.

This attack, well, interesting that FreeBSD with so many
developers with ssh push hasn't been soiled more often.  I am
cautious regarding such, there is a tremendous amount of
propaganda against Russia and China going on .. and then who
tapped the cables, who has the budget, hmm.  I have read one US
national security alert report once, and all i could see was
a supposed russian who logged into an open management console, and
immediately logged out again (if the session was printed
correctly).  On some software where this login possibility was
publicly announced as being a problem months before.  (I read
around once i read this report.) So given that the software would
at least log such login attempts it could even have been seen as
a kind reminder, whatever.  Maybe not.  Was it "national security
alert"?, i think yes.  Well.  It is always easy to point with
fingers at someone else.  But as always, situation is horror.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From jmg at funkthat.com  Wed Dec 30 00:46:24 2020
From: jmg at funkthat.com (John-Mark Gurney)
Date: Tue, 29 Dec 2020 16:46:20 -0800
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <20201229210454.Lh4y_%steffen@sdaoden.eu>
References: <CANCZdfrF0B7uux_neg-4XGn2UCDd4noUm7zP_icHnrpZUgmzzA@mail.gmail.com>
 <CAOtMX2gV2dmyG4b1hZG24sUnqDVk=1pch4xgQmyUdtLrh48kYg@mail.gmail.com>
 <CANCZdfpb0MF+uoW=K3cQpL+3vNQjSBDeVMab5d4JJhUO4sy-2Q@mail.gmail.com>
 <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com>
 <20201218175241.GA72552@spindle.one-eyed-alien.net>
 <20201218182820.1P0tK%steffen@sdaoden.eu>
 <20201223023242.GG31099@funkthat.com>
 <20201223162417.v7Ce6%steffen@sdaoden.eu>
 <20201229011939.GU31099@funkthat.com>
 <20201229210454.Lh4y_%steffen@sdaoden.eu>
Message-ID: <20201230004620.GB31099@funkthat.com>

Steffen Nurpmeso wrote this message on Tue, Dec 29, 2020 at 22:04 +0100:
>  |SolarWinds supply chain attack, being able to smuggle a modified file
>  |into a git repo, say an OS's build server, such that the tools don't
>  |know the tree is modified is a real problem...
> 
> SHA-256 arrives, if you look at the git history.  Until then
> signing a git tag even with SHA-1 is better than being unsealed.

Actually, no it is not.  It provides a false sense a security.  SHA-1
should only be used as a checksum (detecting non-malicous corruption)
now.

There's a reason I stopped signing (and even removed the historical
signatures) of the magnet links that I produce for FreeBSD.

This is also why I expanded the snapaid tool to support releases, to
make it extermely easy to verify signatures:
https://www.funkthat.com/gitea/jmg/snapaid

> This attack, well, interesting that FreeBSD with so many
> developers with ssh push hasn't been soiled more often.  I am

And that is why it isn't a major problem yet, in that there are
additional layers of security, both ssh and https that help
ensure integrity of the repo in transit...

> cautious regarding such, there is a tremendous amount of
> propaganda against Russia and China going on .. and then who
> tapped the cables, who has the budget, hmm.  I have read one US
> national security alert report once, and all i could see was

I am well aware of this, and infact, the reason I've been pushing
for better security like this IS because of the actions of the NSA...
I used to get lunch on a weekly basis across the street from one
of the early revealed NSA wiretap rooms.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

From rmacklem at uoguelph.ca  Wed Dec 30 02:02:59 2020
From: rmacklem at uoguelph.ca (Rick Macklem)
Date: Wed, 30 Dec 2020 02:02:48 +0000
Subject: r367672 broke the NFS server
Message-ID: <YQXPR0101MB0968DC349AFD081480768028DDD70@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>

Hi,

Post r367671...
When multiple files are being created by an NFS client in the same
directory, the VOP_CREATE()/ufs_create() can fail with ERELOOKUP.
This results in a EIO return to the NFS client.
--> This causes "nfsv4 client/server protocol prob err=10026"
      on the client for NFSv4.0 mounts.
      --> This explains why this error has been reported by
            several people lately, although it should "never happen".

Unfortunately, for the NFS server, the Lookup call is done separately
and it will not be easy to redo it, given the current NFS code structure.

Is there another way to deal with the problem r367672 was fixing that
avoids ufs_create() returning ERELOOKUP?

rick


From neel at neelc.org  Wed Dec 30 02:30:35 2020
From: neel at neelc.org (Neel Chauhan)
Date: Tue, 29 Dec 2020 18:30:23 -0800
Subject: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch
Message-ID: <eeab20a1316335317d3ff8cbf68c1cf1@neelc.org>

Hi freebsd-hackers@, CC'd freebsd-current@,

I hope you all had a wonderful holiday season.

I recently got a HP Spectre x360 13t-aw200 which is an Intel 
TigerLake-based laptop. It has the Intel "Evo" branding and an "Optane" 
SSD which I disabled (so I can get a "second" SSD).

On the Spectre, the NVMe is not detected: https://imgur.com/a/ighTwHQ

I don't know if it is HP or Intel, but the VMD IDs device id is 
8086:9a0b. I'm guessing Intel since Dell laptops (XPS, Vostro) also have 
this device ID [1].

Sadly, NVMe RAID is forced on this laptop.

I wrote a rough patch to add the device IDs, and the patch is below:

--- a/sys/dev/vmd/vmd.c
+++ b/sys/dev/vmd/vmd.c
@@ -66,13 +66,20 @@ struct vmd_type {
  #define INTEL_VENDOR_ID                0x8086
  #define INTEL_DEVICE_ID_VMD    0x201d
  #define INTEL_DEVICE_ID_VMD2   0x28c0
+#define INTEL_DEVICE_ID_VMD3   0x9a0b

  static struct vmd_type vmd_devs[] = {
          { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD,  "Intel Volume 
Management Device" },
          { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD2, "Intel Volume 
Management Device" },
+        { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD3, "Intel Volume 
Management Device" },
          { 0, 0, NULL }

However, I get a panic whenever I use this patch: 
https://imgur.com/a/XUQksOi

Without this patch, I am able to boot fine but can't see the SSD or any 
nvd* devices beyond a "none" device in `pciconf -lv`.

For those who know about PCI/ACPI subsystems, can you please tell me 
what's going wrong?

I'm still debugging in the meanwhile, but am no expert on PCI/ACPI 
subsystems. I may know more than most PC builders or CS grads, but not 
really enough to do it full-time.

The Spectre's SSD works fine with Windows 10 (obviously) and Linux 
(Fedora and Debian tested).

Best,

Neel Chauhan

Sources:

[1]: Linux probes:
  * Vostro: https://certification.ubuntu.com/hardware/202007-28047
  * XPS: https://linux-hardware.org/?probe=ba53f6e513

From rmacklem at uoguelph.ca  Wed Dec 30 04:44:11 2020
From: rmacklem at uoguelph.ca (Rick Macklem)
Date: Wed, 30 Dec 2020 04:44:06 +0000
Subject: if you are exporting UFS file systems via NFS on a post Nov. 15
 system, there is a problem
Message-ID: <YQXPR0101MB0968631FFBCBFC78FC79F0C3DDD70@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>

If you are exporting UFS file systems via NFS and your kernel is
built from head/current sources newer than Nov. 15
(r367672 or newer), the NFS service will be broken.

The only workaround is to turn both SU and SU+j off for the
exported file systems via tunefs.

rick

From bsd-lists at bsdforge.com  Wed Dec 30 04:58:49 2020
From: bsd-lists at bsdforge.com (Chris)
Date: Tue, 29 Dec 2020 20:59:22 -0800
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <20201230004620.GB31099@funkthat.com>
References: <CANCZdfrF0B7uux_neg-4XGn2UCDd4noUm7zP_icHnrpZUgmzzA@mail.gmail.com>
 <CAOtMX2gV2dmyG4b1hZG24sUnqDVk=1pch4xgQmyUdtLrh48kYg@mail.gmail.com>
 <CANCZdfpb0MF+uoW=K3cQpL+3vNQjSBDeVMab5d4JJhUO4sy-2Q@mail.gmail.com>
 <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com>
 <20201218175241.GA72552@spindle.one-eyed-alien.net>
 <20201218182820.1P0tK%steffen@sdaoden.eu>
 <20201223023242.GG31099@funkthat.com>
 <20201223162417.v7Ce6%steffen@sdaoden.eu>
 <20201229011939.GU31099@funkthat.com>
 <20201229210454.Lh4y_%steffen@sdaoden.eu>
 <20201230004620.GB31099@funkthat.com>
Message-ID: <274d765e4a841b5d52239d2dae58175e@bsdforge.com>

On 2020-12-29 16:46, John-Mark Gurney wrote:
> Steffen Nurpmeso wrote this message on Tue, Dec 29, 2020 at 22:04 +0100:
>>  |SolarWinds supply chain attack, being able to smuggle a modified file
>>  |into a git repo, say an OS's build server, such that the tools don't
>>  |know the tree is modified is a real problem...
>> 
>> SHA-256 arrives, if you look at the git history.  Until then
>> signing a git tag even with SHA-1 is better than being unsealed.
> 
> Actually, no it is not.  It provides a false sense a security.  SHA-1
> should only be used as a checksum (detecting non-malicous corruption)
> now.
> 
> There's a reason I stopped signing (and even removed the historical
> signatures) of the magnet links that I produce for FreeBSD.
> 
> This is also why I expanded the snapaid tool to support releases, to
> make it extermely easy to verify signatures:
> https://www.funkthat.com/gitea/jmg/snapaid
> 
>> This attack, well, interesting that FreeBSD with so many
>> developers with ssh push hasn't been soiled more often.  I am
> 
> And that is why it isn't a major problem yet, in that there are
> additional layers of security, both ssh and https that help
> ensure integrity of the repo in transit...
> 
>> cautious regarding such, there is a tremendous amount of
>> propaganda against Russia and China going on .. and then who
>> tapped the cables, who has the budget, hmm.  I have read one US
>> national security alert report once, and all i could see was
> 
> I am well aware of this, and infact, the reason I've been pushing
> for better security like this IS because of the actions of the NSA...
> I used to get lunch on a weekly basis across the street from one
> of the early revealed NSA wiretap rooms.
OK I've been pondering this since last night. If this is a reasonable
concern, and given all that's already gone into coercing git into
something FreeBSD friendly. Is it reasonable to consider putting all
that effort that's already been excreted, and what would need to be
done. To cobble up a FreeBSD version? [tongue-in-cheek]
fuk-git -- FreeBSDUsersCare-git. Sorry. It's a strain. But I needed
that acronym.
Seriously tho. It wouldn't be that hard to provide sha384(1) at a minimum.
Better; hmac-sha384, or any of a number of other digests. I'm just
thinking that if everyone pitched in, what with all the other work
that's already been done. It'd all get done on a timeline that wouldn't
leave the FreeBSD repo unsafe.
Mind you; much of this is all conceptual. But I just thought (hoped) it
might be worth while.

--Chris

From bsd-lists at bsdforge.com  Wed Dec 30 05:07:54 2020
From: bsd-lists at bsdforge.com (Chris)
Date: Tue, 29 Dec 2020 21:08:27 -0800
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <274d765e4a841b5d52239d2dae58175e@bsdforge.com>
References: <CANCZdfrF0B7uux_neg-4XGn2UCDd4noUm7zP_icHnrpZUgmzzA@mail.gmail.com>
 <CAOtMX2gV2dmyG4b1hZG24sUnqDVk=1pch4xgQmyUdtLrh48kYg@mail.gmail.com>
 <CANCZdfpb0MF+uoW=K3cQpL+3vNQjSBDeVMab5d4JJhUO4sy-2Q@mail.gmail.com>
 <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com>
 <20201218175241.GA72552@spindle.one-eyed-alien.net>
 <20201218182820.1P0tK%steffen@sdaoden.eu>
 <20201223023242.GG31099@funkthat.com>
 <20201223162417.v7Ce6%steffen@sdaoden.eu>
 <20201229011939.GU31099@funkthat.com>
 <20201229210454.Lh4y_%steffen@sdaoden.eu>
 <20201230004620.GB31099@funkthat.com>
 <274d765e4a841b5d52239d2dae58175e@bsdforge.com>
Message-ID: <763bf958855f8eb181dfa5d40568a008@bsdforge.com>

On 2020-12-29 20:59, Chris wrote:
> On 2020-12-29 16:46, John-Mark Gurney wrote:
>> Steffen Nurpmeso wrote this message on Tue, Dec 29, 2020 at 22:04 +0100:
>>>  |SolarWinds supply chain attack, being able to smuggle a modified file
>>>  |into a git repo, say an OS's build server, such that the tools don't
>>>  |know the tree is modified is a real problem...
>>> 
>>> SHA-256 arrives, if you look at the git history.  Until then
>>> signing a git tag even with SHA-1 is better than being unsealed.
>> 
>> Actually, no it is not.  It provides a false sense a security.  SHA-1
>> should only be used as a checksum (detecting non-malicous corruption)
>> now.
>> 
>> There's a reason I stopped signing (and even removed the historical
>> signatures) of the magnet links that I produce for FreeBSD.
>> 
>> This is also why I expanded the snapaid tool to support releases, to
>> make it extermely easy to verify signatures:
>> https://www.funkthat.com/gitea/jmg/snapaid
>> 
>>> This attack, well, interesting that FreeBSD with so many
>>> developers with ssh push hasn't been soiled more often.  I am
>> 
>> And that is why it isn't a major problem yet, in that there are
>> additional layers of security, both ssh and https that help
>> ensure integrity of the repo in transit...
>> 
>>> cautious regarding such, there is a tremendous amount of
>>> propaganda against Russia and China going on .. and then who
>>> tapped the cables, who has the budget, hmm.  I have read one US
>>> national security alert report once, and all i could see was
>> 
>> I am well aware of this, and infact, the reason I've been pushing
>> for better security like this IS because of the actions of the NSA...
>> I used to get lunch on a weekly basis across the street from one
>> of the early revealed NSA wiretap rooms.
> OK I've been pondering this since last night. If this is a reasonable
> concern, and given all that's already gone into coercing git into
> something FreeBSD friendly. Is it reasonable to consider putting all
> that effort that's already been excreted, and what would need to be
> done. To cobble up a FreeBSD version? [tongue-in-cheek]
> fuk-git -- FreeBSDUsersCare-git. Sorry. It's a strain. But I needed
face-palm; that was: fuc-git. A failed attempt at wit. :-(
the rest holds true.
> that acronym.
> Seriously tho. It wouldn't be that hard to provide sha384(1) at a minimum.
> Better; hmac-sha384, or any of a number of other digests. I'm just
> thinking that if everyone pitched in, what with all the other work
> that's already been done. It'd all get done on a timeline that wouldn't
> leave the FreeBSD repo unsafe.
> Mind you; much of this is all conceptual. But I just thought (hoped) it
> might be worth while.
> 
> --Chris
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"

From grarpamp at gmail.com  Wed Dec 30 05:55:33 2020
From: grarpamp at gmail.com (grarpamp)
Date: Wed, 30 Dec 2020 00:55:29 -0500
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <20201230004620.GB31099@funkthat.com>
References: <CANCZdfrF0B7uux_neg-4XGn2UCDd4noUm7zP_icHnrpZUgmzzA@mail.gmail.com>
 <CAOtMX2gV2dmyG4b1hZG24sUnqDVk=1pch4xgQmyUdtLrh48kYg@mail.gmail.com>
 <CANCZdfpb0MF+uoW=K3cQpL+3vNQjSBDeVMab5d4JJhUO4sy-2Q@mail.gmail.com>
 <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com>
 <20201218175241.GA72552@spindle.one-eyed-alien.net>
 <20201218182820.1P0tK%steffen@sdaoden.eu>
 <20201223023242.GG31099@funkthat.com>
 <20201223162417.v7Ce6%steffen@sdaoden.eu>
 <20201229011939.GU31099@funkthat.com>
 <20201229210454.Lh4y_%steffen@sdaoden.eu>
 <20201230004620.GB31099@funkthat.com>
Message-ID: <CAD2Ti2-4xS5n0+1oLOHyFh4+OCnwtNAAwMkkWzwRVDnt-xmb1Q@mail.gmail.com>

>> SHA-256 arrives, if you look at the git history.

> git's SHA-256 [...] requiring a super new git version to even test it out.

It's "in" current release 2.30.0 and before, duly caveated as experimental
and not fully featured yet...

git-init(1)
       --object-format=<format>
           Specify the given object format (hash algorithm) for the
           repository. The valid values are sha1 and (if enabled) sha256.
           sha1 is the default.

> continue to test how well it works and monitor the
> ecosystem for a transition in a few years when it is robust..

Sure, though perhaps freebsd may then find to enjoy a more
middle lead, ahead than the rather later move of svn->git,
and being already git it will be far less work.

There should be some freebsd press release when the
current git deploy is all done, as new people from outside
will like to know last big OS is on git and then use it more too.

> signatures of the magnet links

Signing torrent.asc, with stronger or even same hash as BT
protocol, still serve purpose of authenticate torrent file back
to a signer to the degree therein, caveat their platform security,
caveat sha-1 inside torrent still being abuseable by third party,
caveat etc. With no torrent.asc there is nothing directly saying
the torrent file / infohash itself went through freebsd project.
Whether torrent or git or else, there can be useable scope
and case for such "stronger over weaker" constructions.

gpg offers better hash algos than sha-1 these days,
all users should look into configuring and using it,
same goes for abandoning the old [a]symmetric algos
and weaker keys, made with old weak /dev/random, etc.

One cannot sign or verify anything without knowing gpg first :)

And even port called "age" is of simple utility too.

From o.hartmann at walstatt.org  Wed Dec 30 07:04:07 2020
From: o.hartmann at walstatt.org (Hartmann, O.)
Date: Wed, 30 Dec 2020 08:04:03 +0100
Subject: # Fssh_packet_write_wait: Connection to 77.183.250.3 port 22:
 Broken pipe
Message-ID: <20201230080403.5474da7c@hermann.fritz.box>

On recent 12-STABLE, 12.1-RELENG and 12.2-RELENG I face a very nasty problem which
occured a while ago after it seemed to have vanished for a while: running ssh in a xterm
on FreeBSD boxes as mentioned at the beginning ends up very rapidly in a lost connection
with

# Fssh_packet_write_wait: Connection to XXX.XXX.XXX.XXX port 22: Broken pipe

The backend is in most cases a CURRENT, 12.1-RELENG or 12.2-RELENG or 12-STABLE server. A
couple of months ago we moved from 11.3-RELENG to 12.1-RELENG (server side, clients were
always 13-CURRENT or 12-STABLE). With FreeBSD 11 as the backend, those broken pipes
occured, but not that frequent and rapid as it is the fact now. 

The "problem" can be mitigated somehow: running top or using the console prevents the
broken pipe fault for a while, but it still occurs. Running "screen" (port
sysutils/screen) does extend the usability of the console for a significant timespan, but
the broken pipe also occurs randomly, but it takes a significant time to occur.

All systems mentioned above are highly customized, so I used the chance of another, more
"generic" scenario to test. The backend is a most recent Xigmanas machine (running
Hardened FreeBSD 12, latest official issue, its based on FBSD 12.1). Accessing clients
are recent GhostBSD or FreeBSD 12.2-RELENG, utilizing Remmina (port sysutils/remmina). It
doesn't matter whether I take the ports from our local poudriere driven repository or
from one of the official ones. SSH via Remmina dies the same death as it does on all
customized boxes. And those failing scenarios are occur in all kind of networks,
home-ISP-lab/work, lab's network, home's network with foreign, Linux based CPE or other
vendor's CPE.

My conclusion is: either there is a serious problem with FreeBSD since 12, or there is a
config issue I'm not aware of, even with "vanilla" installations from official repository
running unchanged.

Kind regards,

oh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20201230/5ca6ccc7/attachment.sig>

From kostikbel at gmail.com  Wed Dec 30 12:53:19 2020
From: kostikbel at gmail.com (Konstantin Belousov)
Date: Wed, 30 Dec 2020 14:53:09 +0200
Subject: r367672 broke the NFS server
In-Reply-To: <YQXPR0101MB0968DC349AFD081480768028DDD70@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
References: <YQXPR0101MB0968DC349AFD081480768028DDD70@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
Message-ID: <X+x4NSeWI+z5QkP3@kib.kiev.ua>

On Wed, Dec 30, 2020 at 02:02:48AM +0000, Rick Macklem wrote:
> Hi,
> 
> Post r367671...
> When multiple files are being created by an NFS client in the same
> directory, the VOP_CREATE()/ufs_create() can fail with ERELOOKUP.
> This results in a EIO return to the NFS client.
> --> This causes "nfsv4 client/server protocol prob err=10026"
>       on the client for NFSv4.0 mounts.
>       --> This explains why this error has been reported by
>             several people lately, although it should "never happen".
> 
> Unfortunately, for the NFS server, the Lookup call is done separately
> and it will not be easy to redo it, given the current NFS code structure.
> 
> Is there another way to deal with the problem r367672 was fixing that
> avoids ufs_create() returning ERELOOKUP?

Idea of the change is to restart the syscall at top level.  So for NFS
server the right approach is to not send a response and also to not
free the request mbuf chain, but to restart processing.

I am sorry I forgot about NFS server when designing this fix, the only
mild excuse I can provide is that the change was quite complicated as is.

I will start looking at the fix.

From o.hartmann at walstatt.org  Wed Dec 30 13:14:54 2020
From: o.hartmann at walstatt.org (Hartmann, O.)
Date: Wed, 30 Dec 2020 14:14:48 +0100
Subject: # Fssh_packet_write_wait: Connection to 77.183.250.3 port 22:
 Broken pipe
In-Reply-To: <F020BEC8-C3B4-41E7-B4E9-5ECC93E6E762@macmic.franken.de>
References: <20201230080403.5474da7c@hermann.fritz.box>
 <F020BEC8-C3B4-41E7-B4E9-5ECC93E6E762@macmic.franken.de>
Message-ID: <20201230141448.48871cc5@hermann.fritz.box>

On Wed, 30 Dec 2020 12:13:44 +0100
Michael Tuexen <Michael.Tuexen at macmic.franken.de> wrote:

> On 30. Dec 2020, at 08:04, Hartmann, O. <o.hartmann at walstatt.org> wrote:
> > 
> > On recent 12-STABLE, 12.1-RELENG and 12.2-RELENG I face a very nasty problem which
> > occured a while ago after it seemed to have vanished for a while: running ssh in a
> > xterm on FreeBSD boxes as mentioned at the beginning ends up very rapidly in a lost
> > connection with  
> How can I reproduce the problem? Just ssh'ing into a server? Client and server running
> FreeBSD head? Are there middleboxes (NAT, Firewall) involved or does it also happen if
> client and server are directly connected? What does 'rapidly' mean: 1 second, 1 minute,
> 1 hour, 1 day?

Take this course: 12-STABLE (FreeBSD 12.2-STABLE #63 r368787+3cc3872829b1(stable/12): Mon
Dec 28 06:07:57 CET 2020 amd64). 

As a target (server) I just used a LibreELEC box, Leia 18. something, core 9.2.6. My
notebook this time is a Lenovo E540. ssh is running in xterm. After a successful login on
the KODI/LibreElec, wait for a couple of minutes. It is random, the session of mine died
after 2 to 5 minutes of idling, one can extend that timeframe by starting top on the
KODI/shell.

regards

oh

p.s. That is only one scenario that I faced at home just a couple of minutes ago.

> 
> Best regards
> Michael
> > 
> > # Fssh_packet_write_wait: Connection to XXX.XXX.XXX.XXX port 22: Broken pipe
> > 
> > The backend is in most cases a CURRENT, 12.1-RELENG or 12.2-RELENG or 12-STABLE
> > server. A couple of months ago we moved from 11.3-RELENG to 12.1-RELENG (server side,
> > clients were always 13-CURRENT or 12-STABLE). With FreeBSD 11 as the backend, those
> > broken pipes occured, but not that frequent and rapid as it is the fact now. 
> > 
> > The "problem" can be mitigated somehow: running top or using the console prevents the
> > broken pipe fault for a while, but it still occurs. Running "screen" (port
> > sysutils/screen) does extend the usability of the console for a significant timespan,
> > but the broken pipe also occurs randomly, but it takes a significant time to occur.
> > 
> > All systems mentioned above are highly customized, so I used the chance of another,
> > more "generic" scenario to test. The backend is a most recent Xigmanas machine
> > (running Hardened FreeBSD 12, latest official issue, its based on FBSD 12.1).
> > Accessing clients are recent GhostBSD or FreeBSD 12.2-RELENG, utilizing Remmina (port
> > sysutils/remmina). It doesn't matter whether I take the ports from our local
> > poudriere driven repository or from one of the official ones. SSH via Remmina dies
> > the same death as it does on all customized boxes. And those failing scenarios are
> > occur in all kind of networks, home-ISP-lab/work, lab's network, home's network with
> > foreign, Linux based CPE or other vendor's CPE.
> > 
> > My conclusion is: either there is a serious problem with FreeBSD since 12, or there
> > is a config issue I'm not aware of, even with "vanilla" installations from official
> > repository running unchanged.
> > 
> > Kind regards,
> > 
> > oh  
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20201230/5658deb2/attachment.sig>

From warlock at phouka.net  Wed Dec 30 15:41:26 2020
From: warlock at phouka.net (John Kennedy)
Date: Wed, 30 Dec 2020 07:40:01 -0800
Subject: # Fssh_packet_write_wait: Connection to 77.183.250.3 port 22:
 Broken pipe
In-Reply-To: <20201230080403.5474da7c@hermann.fritz.box>
References: <20201230080403.5474da7c@hermann.fritz.box>
Message-ID: <X+yfUbHBqH74S5UA@phouka1.phouka.net>

On Wed, Dec 30, 2020 at 08:04:03AM +0100, Hartmann, O. wrote:
> On recent 12-STABLE, 12.1-RELENG and 12.2-RELENG I face a very nasty problem which
> occured a while ago after it seemed to have vanished for a while: running ssh in a xterm
> on FreeBSD boxes as mentioned at the beginning ends up very rapidly in a lost connection
> with
> 
> # Fssh_packet_write_wait: Connection to XXX.XXX.XXX.XXX port 22: Broken pipe
> 
> The backend is in most cases a CURRENT, 12.1-RELENG or 12.2-RELENG or 12-STABLE server. A
> couple of months ago we moved from 11.3-RELENG to 12.1-RELENG (server side, clients were
> always 13-CURRENT or 12-STABLE). With FreeBSD 11 as the backend, those broken pipes
> occured, but not that frequent and rapid as it is the fact now. 
> 
> The "problem" can be mitigated somehow: running top or using the console prevents the
> broken pipe fault for a while, but it still occurs. Running "screen" (port
> sysutils/screen) does extend the usability of the console for a significant timespan, but
> the broken pipe also occurs randomly, but it takes a significant time to occur.

  So, I do a LOT of ssh-in-xterm and I can't say that I've seen anything that
looks like it is FreeBSD's fault (vs ISP, work firewall, work VPN, etc).  For
my cloud host (12.2-p2) I do tend to use the screen program.  At work, in pre-
Covid times (so up to last March 18th or so, whatever that works out to in
versioning/revisions; probably 12.1 or 12.0), I'd have sessions opened a week+.  
At home I'm all 13 at the moment.

  Because I'm running a lot of 13 at home (and before that, 12-stable) I tend
to reboot the box for update reasons.  Is it safe to assume that "very rapidly"
is measured in sub-days?

> My conclusion is: either there is a serious problem with FreeBSD since 12, or there is a
> config issue I'm not aware of, even with "vanilla" installations from official repository
> running unchanged.

  At work, my problems are all about crappy firewalls.  Even firewalls that
we've spent a LOT of money on (PaloAlto, the Juniper before it).  In all
fairness to them, we're running a University's worth of class-B through there
and they have all the state-tracking/deep-inspection goodness turned on trying
to protect everyone from the big bad internet so it's complicated.

  With putty, I've had to turn on TCP/IP keepalives and sending null packets.
The problem there just seems to be that the firewall hardware can only track
so many sessions and, when you stress it, it'll drop "idle" sessions (vs
active, vs not opening up a new one).  Systems hemorrhage connections all the
time when something eats the final connection-close packet, but they can time
the thing out.  The PaloAlto in my case doesn't know that so it just starts
reaping, getting valid idle connections some of the time.  So all my tricks
just involve some amount of traffic to keep that session more alive in the
non-host-state-tracker's brain.

  For SSH at work, I've set this up:

	host *
		TCPKeepAlive		yes
		ServerAliveInterval	60
		ServerAliveCountMax	3

  So, send TCP/IP keepalive packets, send some traffic every 60 seconds, and
tear down the session if you miss 3 of those.  I'll note at home that I haven't
had to do that.  For that cloud 12.2 system, I've had a connection "idle" for
21 hours (but running with a screen going, which is getting some amount of
bidirectional traffic going because it has a date/time stamp that gets updated
once a minute).

  Is 21 hours "significant" by your measurements?

  At home, I don't have a network firewall of any sort.  Probably the usual
unknowns with the ISP and crappyware NAT box they force me to use.

  My cloud system is running on DigitalOcean, for what that is worth.  I'm
not sure what they're doing for firewalls (I'm doing host firewalls out there,
so maybe nothing in my case).


From uqs at freebsd.org  Wed Dec 30 15:57:42 2020
From: uqs at freebsd.org (Ulrich =?utf-8?B?U3DDtnJsZWlu?=)
Date: Wed, 30 Dec 2020 16:57:38 +0100
Subject: git and the loss of revision numbers
In-Reply-To: <X+qBEmvOpuUmqAew@albert.catwhisker.org>
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
 <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org>
 <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org>
 <CAPyFy2DW0YDUK+kir2H_e8LVT-P-kQ0PMmKQO6m+016Wb=Hd0A@mail.gmail.com>
 <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com>
 <20201229005639.GS31099@funkthat.com>
 <X+qBEmvOpuUmqAew@albert.catwhisker.org>
Message-ID: <X+yjcsbfCE9VYCqG@acme.spoerlein.net>

On Mon, 2020-12-28 at 17:06:26 -0800, David Wolfskill wrote:
>On Mon, Dec 28, 2020 at 04:56:39PM -0800, John-Mark Gurney wrote:
>> monochrome wrote this message on Mon, Dec 28, 2020 at 19:38 -0500:
>> > what would be the git command for reverting source to a previous version
>> > using these numbers? for example, with svn and old numbers:
>> > svnlite update -r367627 /usr/src
>> >
>> > this is needed often when it blows up for someone tracking current
>>
>> Get the hash from a commit number:
>> $git rev-list --reverse HEAD | tail -n +255241 | head -n 1
>> 3cc0c0d66a065554459bd2f9b4f80cc07426464a
>>
>> so:
>> git checkout $(git rev-list --reverse HEAD | tail -n +255240 | head -n 1)
>> ....
>
>Or save a process:
>
>git rev-list --reverse HEAD | awk 'NR == 255241 {print; exit 0}'
>3cc0c0d66a065554459bd2f9b4f80cc07426464a
>
>(And thus:
>git checkout $(git rev-list --reverse HEAD | awk 'NR == 255241 {print; exit 0}')
>
>Could also pass the number to awk via the "-v var=value" command-line.)

Counting commits will not get you to SVN revision 12345, you need to 
look at the git notes, they are there for that exact reason.

(fun fact, r12345 isn't actually on the main branch, so don't try with 
that one)

% git log --oneline -n1 --notes --grep='revision=12346$' main
df4f0253cd89 Use NO_MTREE, not !USE_X11 && !USE_IMAKE, to determine package args. NO_MTREE should work as advertised (for both direct installation and pkg_add) now.
Notes:
     svn path=/head/; revision=12346

So df4f0253cd89 is the corresponding git commit to your SVN r12346

hth
Uli

From uqs at freebsd.org  Wed Dec 30 16:04:20 2020
From: uqs at freebsd.org (Ulrich =?utf-8?B?U3DDtnJsZWlu?=)
Date: Wed, 30 Dec 2020 17:04:17 +0100
Subject: git and the loss of revision numbers
In-Reply-To: <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com>
References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org>
 <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org>
 <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org>
 <CAPyFy2DW0YDUK+kir2H_e8LVT-P-kQ0PMmKQO6m+016Wb=Hd0A@mail.gmail.com>
 <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com>
Message-ID: <X+ylASvJe54Zpu2m@acme.spoerlein.net>

On Mon, 2020-12-28 at 19:38:05 -0500, monochrome wrote:
>what would be the git command for reverting source to a previous version
>using these numbers? for example, with svn and old numbers:
>svnlite update -r367627 /usr/src
>
>this is needed often when it blows up for someone tracking current

You need to fetch the git notes, then you can grep them for the SVN rev 
you're looking for.

$ git fetch origin "refs/notes/*:refs/notes/*" && git fetch
$ git checkout `git log --format=%h --notes --grep='revision=367627$' main`

It's git commit 9aa6d792b549 for reference.


>On 12/28/20 11:27 AM, Ed Maste wrote:
>> On Mon, 28 Dec 2020 at 07:08, Renato Botelho <garga at freebsd.org> wrote:
>>>
>>> FreeBSD bast.garga.net.br 13.0-CURRENT FreeBSD 13.0-CURRENT #19
>>> 3cc0c0d66a0-c255241(main)-dirty:
>>>               ^
>>>               This is an incremental counter of commits
>>
>> Also, uqs@ recently fixed an issue in newvers.sh (including the final,
>> non-updating svn revision) and reordered the information. An example
>> of the new format:
>>
>> main-c255126-gb81783dc98e6-dirty
>>   \     \       \            \
>>    \     \       \             local modifications
>>     \     \        hash
>>      \      commit count
>>        branch

Note, the `g` in there is by design, it's the format that git-describe 
will barf out.

hth
Uli

From david at catwhisker.org  Wed Dec 30 16:08:59 2020
From: david at catwhisker.org (David Wolfskill)
Date: Wed, 30 Dec 2020 08:08:50 -0800
Subject: # Fssh_packet_write_wait: Connection to 77.183.250.3 port 22:
 Broken pipe
In-Reply-To: <20201230080403.5474da7c@hermann.fritz.box>
References: <20201230080403.5474da7c@hermann.fritz.box>
Message-ID: <X+ymEk6xlrgyaui1@albert.catwhisker.org>

On Wed, Dec 30, 2020 at 08:04:03AM +0100, Hartmann, O. wrote:
> ...
> 
> # Fssh_packet_write_wait: Connection to XXX.XXX.XXX.XXX port 22: Broken pipe
> 
> The backend is in most cases a CURRENT, 12.1-RELENG or 12.2-RELENG or 12-STABLE server. A
> couple of months ago we moved from 11.3-RELENG to 12.1-RELENG (server side, clients were
> always 13-CURRENT or 12-STABLE). With FreeBSD 11 as the backend, those broken pipes
> occured, but not that frequent and rapid as it is the fact now. 
> 
> The "problem" can be mitigated somehow: running top or using the console prevents the
> broken pipe fault for a while, but it still occurs. Running "screen" (port
> sysutils/screen) does extend the usability of the console for a significant timespan, but
> the broken pipe also occurs randomly, but it takes a significant time to occur.

I have seen messages like that -- from a remote host that has
rebooted or to which the network connection has (otherwise) been
severed.

A couple of things that I do may have (significantly) reduced the
probability that I would encounter what you report under other
conditions.

Context: I work from my laptop, and ssh to ... well, just about
everything: machines in my house; machines at work; machines at work
accessible only from within the VPN hrough a bastion host; machines in
the FreeBSD.org cluster....  Usually concurrently.  The laptop normally
runs FreeBSD stable/12 (freshly built each morning), but it runs head
while I build head on it and for the smoke-test after the build is
complete.

* A long time ago, I placed "ServerAliveInterval 150" in ~/.ssh/config.
  (I suspect that this was well before Nov 2014, which was the
  beginning of my tenure with my current employer.  And yes, I had
  been using the above-described "ssh to everyhing" well before
  then -- I think I got in he habit around 1999, back at Whistle.)

* Whenever I am about to do something "sensitive," I run tmux
  (port/package sysutils/tmux -- same "ecological niche" as screen,
  but I switched from screen to tmux several years ago, and haven't
  looked back.)  This has become enough of a habit that I tend to
  run tmux from "muscle memory."  Or I have set up csh aliasses or
  scripts to "do stuff" that automagically invoke tmux, so I don't
  even notice.

* [Yeah, I wrote "a couple" up there; this is a bonus. :-) ]  I
  don't keep machines up longer than about 175 hours (a little over
  a week) at a stretch: I update my laptop and my "build machine"
  daily, and update the other machines under my control weekly.

> .... 

Peace,
david
-- 
David H. Wolfskill                              david at catwhisker.org
While Trump successfully conned a lot of people for a while, in the
end he's just a failure throwing a temper tantrum because he lost.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20201230/34a4bdad/attachment.sig>

From rmacklem at uoguelph.ca  Wed Dec 30 16:48:37 2020
From: rmacklem at uoguelph.ca (Rick Macklem)
Date: Wed, 30 Dec 2020 16:48:27 +0000
Subject: r367672 broke the NFS server
In-Reply-To: <X+x4NSeWI+z5QkP3@kib.kiev.ua>
References: <YQXPR0101MB0968DC349AFD081480768028DDD70@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>,
 <X+x4NSeWI+z5QkP3@kib.kiev.ua>
Message-ID: <YQXPR0101MB09687E622BDBBE59C964FAC4DDD70@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>

Kostik wrote:
>On Wed, Dec 30, 2020 at 02:02:48AM +0000, Rick Macklem wrote:
>> Hi,
>>
>> Post r367671...
>> When multiple files are being created by an NFS client in the same
>> directory, the VOP_CREATE()/ufs_create() can fail with ERELOOKUP.
>> This results in a EIO return to the NFS client.
>> --> This causes "nfsv4 client/server protocol prob err=10026"
>>       on the client for NFSv4.0 mounts.
>>       --> This explains why this error has been reported by
>>             several people lately, although it should "never happen".
>>
>> Unfortunately, for the NFS server, the Lookup call is done separately
>> and it will not be easy to redo it, given the current NFS code structure.
>>
>> Is there another way to deal with the problem r367672 was fixing that
>> avoids ufs_create() returning ERELOOKUP?
>
>Idea of the change is to restart the syscall at top level.  So for NFS
>server the right approach is to not send a response and also to not
>free the request mbuf chain, but to restart processing.
Yes. I took a look and I think restarting the operation by rolling the
working position in the mbuf lists back and redoing the operation
is feasible and easier than fixing the individual operations.

For NFSv4, you cannot redo the entire compound, since non-idempotent
operations like exclusive open may have already been completed.
However, rolling back to the beginning of the operation should be
doable.
--> It will serve as a good test, in that it may expose bugs in the
      RPC/operation code where failure (ERELOOKUP) doesn't clean
      things up correctly.
      --> In NFSv4, there is the open/lock state that cannot be updated
            for this error case. (The seqid stuff in NFSv4.0 Open can be fun.
            Its used to serialize the operations and the number must be
            incremented for some errors, but not for others. The 10026
            error occurs when you don't get this right.)

I'll start working on this to-day, but I have no idea how long it might
take?

>I am sorry I forgot about NFS server when designing this fix, the only
>mild excuse I can provide is that the change was quite complicated as is.
>I will start looking at the fix.
No problem. Sometimes I'd like to forget about NFS too;-).

For the rollback/redo the RPC/operation case, it's probably easier for me
to do it. As above, I'll start on it, but...

My main concern is how long it will take, given the FreeBSD13 release
starts soon.

rick
_______________________________________________
freebsd-current at freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"


From kostikbel at gmail.com  Wed Dec 30 17:27:17 2020
From: kostikbel at gmail.com (Konstantin Belousov)
Date: Wed, 30 Dec 2020 19:27:08 +0200
Subject: r367672 broke the NFS server
In-Reply-To: <YQXPR0101MB09687E622BDBBE59C964FAC4DDD70@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
References: <YQXPR0101MB0968DC349AFD081480768028DDD70@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
 <X+x4NSeWI+z5QkP3@kib.kiev.ua>
 <YQXPR0101MB09687E622BDBBE59C964FAC4DDD70@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
Message-ID: <X+y4bK8/1akNNh4Z@kib.kiev.ua>

On Wed, Dec 30, 2020 at 04:48:27PM +0000, Rick Macklem wrote:
> Kostik wrote:
> >On Wed, Dec 30, 2020 at 02:02:48AM +0000, Rick Macklem wrote:
> >> Hi,
> >>
> >> Post r367671...
> >> When multiple files are being created by an NFS client in the same
> >> directory, the VOP_CREATE()/ufs_create() can fail with ERELOOKUP.
> >> This results in a EIO return to the NFS client.
> >> --> This causes "nfsv4 client/server protocol prob err=10026"
> >>       on the client for NFSv4.0 mounts.
> >>       --> This explains why this error has been reported by
> >>             several people lately, although it should "never happen".
> >>
> >> Unfortunately, for the NFS server, the Lookup call is done separately
> >> and it will not be easy to redo it, given the current NFS code structure.
> >>
> >> Is there another way to deal with the problem r367672 was fixing that
> >> avoids ufs_create() returning ERELOOKUP?
> >
> >Idea of the change is to restart the syscall at top level.  So for NFS
> >server the right approach is to not send a response and also to not
> >free the request mbuf chain, but to restart processing.
> Yes. I took a look and I think restarting the operation by rolling the
> working position in the mbuf lists back and redoing the operation
> is feasible and easier than fixing the individual operations.
> 
> For NFSv4, you cannot redo the entire compound, since non-idempotent
> operations like exclusive open may have already been completed.
> However, rolling back to the beginning of the operation should be
> doable.
> --> It will serve as a good test, in that it may expose bugs in the
>       RPC/operation code where failure (ERELOOKUP) doesn't clean
>       things up correctly.
>       --> In NFSv4, there is the open/lock state that cannot be updated
>             for this error case. (The seqid stuff in NFSv4.0 Open can be fun.
>             Its used to serialize the operations and the number must be
>             incremented for some errors, but not for others. The 10026
>             error occurs when you don't get this right.)
Note that ERELOOKUP error can only show up from the VOPs that modify the volume.
Otherwise we simply do not call into SU.  In particular, I believe that opens
in the sense of NFS are safe.

Regardless of it, there should be either a catch-all check for ERELOOKUP,
or assert that ERELOOKUP did not leaked, as it is done for syscalls

> 
> I'll start working on this to-day, but I have no idea how long it might
> take?
> 
> >I am sorry I forgot about NFS server when designing this fix, the only
> >mild excuse I can provide is that the change was quite complicated as is.
> >I will start looking at the fix.
> No problem. Sometimes I'd like to forget about NFS too;-).
> 
> For the rollback/redo the RPC/operation case, it's probably easier for me
> to do it. As above, I'll start on it, but...
> 
> My main concern is how long it will take, given the FreeBSD13 release
> starts soon.
For sure I will help you if needed, and I believe that we could ask for
testing from Peter.

From ctuffli at gmail.com  Wed Dec 30 18:04:51 2020
From: ctuffli at gmail.com (Chuck Tuffli)
Date: Wed, 30 Dec 2020 10:04:38 -0800
Subject: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch
In-Reply-To: <eeab20a1316335317d3ff8cbf68c1cf1@neelc.org>
References: <eeab20a1316335317d3ff8cbf68c1cf1@neelc.org>
Message-ID: <CAKAYmMLn8rO-dJd+VYPguM9KmcXbkBiPnBu3bygRHBNpNn+S5w@mail.gmail.com>

On Tue, Dec 29, 2020 at 6:30 PM Neel Chauhan <neel at neelc.org> wrote:
>
> Hi freebsd-hackers@, CC'd freebsd-current@,
>
> I hope you all had a wonderful holiday season.
>
> I recently got a HP Spectre x360 13t-aw200 which is an Intel
> TigerLake-based laptop. It has the Intel "Evo" branding and an "Optane"
> SSD which I disabled (so I can get a "second" SSD).
>
> On the Spectre, the NVMe is not detected: https://imgur.com/a/ighTwHQ
>
> I don't know if it is HP or Intel, but the VMD IDs device id is
> 8086:9a0b. I'm guessing Intel since Dell laptops (XPS, Vostro) also have
> this device ID [1].
>
> Sadly, NVMe RAID is forced on this laptop.
>
> I wrote a rough patch to add the device IDs, and the patch is below:

FWIW, that is the same change I would have made. Peeking at the Linux
vmd driver, it doesn't appear to do anything special for 8086:9a0b as
compared to the 8086:2a0c device the FreeBSD driver already supports.
That said, the Linux driver reads a capability register to determine
the bus number start (vmd_bus_number_start()) which I don't see in the
FreeBSD driver. This is curious because, looking at the "lspci all"
output from the XPS link you provided, the NVMe device shows up in PCI
domain 0x1000 (i.e. not 0x0000). Which (and I have no direct
experience with this device or code) only happens if the bus number
start function returns 0x0.

What is the output from
# pciconf -rb pci0:0:14:0 0x40:0x48

--chuck

From peter at holm.cc  Wed Dec 30 18:23:15 2020
From: peter at holm.cc (Peter Holm)
Date: Wed, 30 Dec 2020 19:23:13 +0100
Subject: r367672 broke the NFS server
In-Reply-To: <X+y4bK8/1akNNh4Z@kib.kiev.ua>
References: <YQXPR0101MB0968DC349AFD081480768028DDD70@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
 <X+x4NSeWI+z5QkP3@kib.kiev.ua>
 <YQXPR0101MB09687E622BDBBE59C964FAC4DDD70@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
 <X+y4bK8/1akNNh4Z@kib.kiev.ua>
Message-ID: <20201230182313.GA22299@x8.osted.lan>

On Wed, Dec 30, 2020 at 07:27:08PM +0200, Konstantin Belousov wrote:
> On Wed, Dec 30, 2020 at 04:48:27PM +0000, Rick Macklem wrote:
> > Kostik wrote:
> > >On Wed, Dec 30, 2020 at 02:02:48AM +0000, Rick Macklem wrote:
> > >> Hi,
> > >>
> > >> Post r367671...
> > >> When multiple files are being created by an NFS client in the same
> > >> directory, the VOP_CREATE()/ufs_create() can fail with ERELOOKUP.
> > >> This results in a EIO return to the NFS client.
> > >> --> This causes "nfsv4 client/server protocol prob err=10026"
> > >>       on the client for NFSv4.0 mounts.
> > >>       --> This explains why this error has been reported by
> > >>             several people lately, although it should "never happen".
> > >>
> > >> Unfortunately, for the NFS server, the Lookup call is done separately
> > >> and it will not be easy to redo it, given the current NFS code structure.
> > >>
> > >> Is there another way to deal with the problem r367672 was fixing that
> > >> avoids ufs_create() returning ERELOOKUP?
> > >
> > >Idea of the change is to restart the syscall at top level.  So for NFS
> > >server the right approach is to not send a response and also to not
> > >free the request mbuf chain, but to restart processing.
> > Yes. I took a look and I think restarting the operation by rolling the
> > working position in the mbuf lists back and redoing the operation
> > is feasible and easier than fixing the individual operations.
> > 
> > For NFSv4, you cannot redo the entire compound, since non-idempotent
> > operations like exclusive open may have already been completed.
> > However, rolling back to the beginning of the operation should be
> > doable.
> > --> It will serve as a good test, in that it may expose bugs in the
> >       RPC/operation code where failure (ERELOOKUP) doesn't clean
> >       things up correctly.
> >       --> In NFSv4, there is the open/lock state that cannot be updated
> >             for this error case. (The seqid stuff in NFSv4.0 Open can be fun.
> >             Its used to serialize the operations and the number must be
> >             incremented for some errors, but not for others. The 10026
> >             error occurs when you don't get this right.)
> Note that ERELOOKUP error can only show up from the VOPs that modify the volume.
> Otherwise we simply do not call into SU.  In particular, I believe that opens
> in the sense of NFS are safe.
> 
> Regardless of it, there should be either a catch-all check for ERELOOKUP,
> or assert that ERELOOKUP did not leaked, as it is done for syscalls
> 
> > 
> > I'll start working on this to-day, but I have no idea how long it might
> > take?
> > 
> > >I am sorry I forgot about NFS server when designing this fix, the only
> > >mild excuse I can provide is that the change was quite complicated as is.
> > >I will start looking at the fix.
> > No problem. Sometimes I'd like to forget about NFS too;-).
> > 
> > For the rollback/redo the RPC/operation case, it's probably easier for me
> > to do it. As above, I'll start on it, but...
> > 
> > My main concern is how long it will take, given the FreeBSD13 release
> > starts soon.
> For sure I will help you if needed, and I believe that we could ask for
> testing from Peter.

Absolutely.
Not sure how I missed running NFS test the first time around.

- Peter

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

From neel at neelc.org  Thu Dec 31 00:38:25 2020
From: neel at neelc.org (Neel Chauhan)
Date: Wed, 30 Dec 2020 16:38:16 -0800
Subject: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch
In-Reply-To: <CAKAYmMLn8rO-dJd+VYPguM9KmcXbkBiPnBu3bygRHBNpNn+S5w@mail.gmail.com>
References: <eeab20a1316335317d3ff8cbf68c1cf1@neelc.org>
 <CAKAYmMLn8rO-dJd+VYPguM9KmcXbkBiPnBu3bygRHBNpNn+S5w@mail.gmail.com>
Message-ID: <f3a548aa4f435f25983f9d6b2a010af0@neelc.org>

Hi Chuck,

On 2020-12-30 10:04, Chuck Tuffli wrote:
> What is the output from
> # pciconf -rb pci0:0:14:0 0x40:0x48

The output is:

01 00 00 00 01 2e 68 02  00

> --chuck

I was also able to stop kernel panics by adding:

rman_fini(&sc->vmd_bus.rman);

In the fail: statement in vmd_attach().

But I still cannot detect the SSD.

-Neel

From neel at neelc.org  Thu Dec 31 01:21:18 2020
From: neel at neelc.org (Neel Chauhan)
Date: Wed, 30 Dec 2020 17:21:14 -0800
Subject: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch
In-Reply-To: <f3a548aa4f435f25983f9d6b2a010af0@neelc.org>
References: <eeab20a1316335317d3ff8cbf68c1cf1@neelc.org>
 <CAKAYmMLn8rO-dJd+VYPguM9KmcXbkBiPnBu3bygRHBNpNn+S5w@mail.gmail.com>
 <f3a548aa4f435f25983f9d6b2a010af0@neelc.org>
Message-ID: <3c55d6d50b1bcf1d45d4599502060f34@neelc.org>

To extend, I am getting an issue with `pci_read_device()` where it 
returns a `vid` (PCI Vendor ID) of 0xffff.

This ends up returning "Cannot allocate dinfo!" from vmd.

Log (via grep): https://imgur.com/a/tAmmY7i

-Neel

On 2020-12-30 16:38, Neel Chauhan wrote:
> Hi Chuck,
> 
> On 2020-12-30 10:04, Chuck Tuffli wrote:
>> What is the output from
>> # pciconf -rb pci0:0:14:0 0x40:0x48
> 
> The output is:
> 
> 01 00 00 00 01 2e 68 02  00
> 
>> --chuck
> 
> I was also able to stop kernel panics by adding:
> 
> rman_fini(&sc->vmd_bus.rman);
> 
> In the fail: statement in vmd_attach().
> 
> But I still cannot detect the SSD.
> 
> -Neel
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to 
> "freebsd-current-unsubscribe at freebsd.org"

From neel at neelc.org  Thu Dec 31 02:14:40 2020
From: neel at neelc.org (Neel Chauhan)
Date: Wed, 30 Dec 2020 18:14:36 -0800
Subject: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch
In-Reply-To: <3c55d6d50b1bcf1d45d4599502060f34@neelc.org>
References: <eeab20a1316335317d3ff8cbf68c1cf1@neelc.org>
 <CAKAYmMLn8rO-dJd+VYPguM9KmcXbkBiPnBu3bygRHBNpNn+S5w@mail.gmail.com>
 <f3a548aa4f435f25983f9d6b2a010af0@neelc.org>
 <3c55d6d50b1bcf1d45d4599502060f34@neelc.org>
Message-ID: <d428fa805b8ca15912f06546bef38c14@neelc.org>

I have attached two files:

  * pcidump.txt: A dump of `pciconf -lv`
  * acpidump.txt: A dump of `acpidump`

Hope this can help.

-Neel

On 2020-12-30 17:21, Neel Chauhan wrote:
> To extend, I am getting an issue with `pci_read_device()` where it
> returns a `vid` (PCI Vendor ID) of 0xffff.
> 
> This ends up returning "Cannot allocate dinfo!" from vmd.
> 
> Log (via grep): https://imgur.com/a/tAmmY7i
> 
> -Neel
> 
> On 2020-12-30 16:38, Neel Chauhan wrote:
>> Hi Chuck,
>> 
>> On 2020-12-30 10:04, Chuck Tuffli wrote:
>>> What is the output from
>>> # pciconf -rb pci0:0:14:0 0x40:0x48
>> 
>> The output is:
>> 
>> 01 00 00 00 01 2e 68 02  00
>> 
>>> --chuck
>> 
>> I was also able to stop kernel panics by adding:
>> 
>> rman_fini(&sc->vmd_bus.rman);
>> 
>> In the fail: statement in vmd_attach().
>> 
>> But I still cannot detect the SSD.
>> 
>> -Neel
>> _______________________________________________
>> freebsd-current at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to 
>> "freebsd-current-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to 
> "freebsd-current-unsubscribe at freebsd.org"
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pcidump.txt
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20201230/5a566868/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: acpidump.txt
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20201230/5a566868/attachment-0001.txt>

From neel at neelc.org  Thu Dec 31 05:04:17 2020
From: neel at neelc.org (Neel Chauhan)
Date: Wed, 30 Dec 2020 21:04:12 -0800
Subject: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch
In-Reply-To: <CAKAYmMLn8rO-dJd+VYPguM9KmcXbkBiPnBu3bygRHBNpNn+S5w@mail.gmail.com>
References: <eeab20a1316335317d3ff8cbf68c1cf1@neelc.org>
 <CAKAYmMLn8rO-dJd+VYPguM9KmcXbkBiPnBu3bygRHBNpNn+S5w@mail.gmail.com>
Message-ID: <75d6b956e227249774978dc09cd26c3f@neelc.org>

I think I found the issue:

This PCIe controller is not detected:

10000:e0:1d.0 PCI bridge [0604]: Intel Corporation Tiger Lake-LP PCI 
Express Root Port #9 [8086:a0b0] (rev 20) SI

I believe the above PCIe controller is exposed by VMD (as it is on 
Linux), but FreeBSD vmd/vmd_bus is unable to attach this controller.

It is likely because VMD uses PCI domain above 0x10000 but we aren't 
looking at this.

Source: 
https://github.com/torvalds/linux/blob/master/drivers/pci/controller/vmd.c#L437

Don't yet have a patch though. Sorry for the number of emails earlier.

-Neel

On 2020-12-30 10:04, Chuck Tuffli wrote:
> On Tue, Dec 29, 2020 at 6:30 PM Neel Chauhan <neel at neelc.org> wrote:
>> 
>> Hi freebsd-hackers@, CC'd freebsd-current@,
>> 
>> I hope you all had a wonderful holiday season.
>> 
>> I recently got a HP Spectre x360 13t-aw200 which is an Intel
>> TigerLake-based laptop. It has the Intel "Evo" branding and an 
>> "Optane"
>> SSD which I disabled (so I can get a "second" SSD).
>> 
>> On the Spectre, the NVMe is not detected: https://imgur.com/a/ighTwHQ
>> 
>> I don't know if it is HP or Intel, but the VMD IDs device id is
>> 8086:9a0b. I'm guessing Intel since Dell laptops (XPS, Vostro) also 
>> have
>> this device ID [1].
>> 
>> Sadly, NVMe RAID is forced on this laptop.
>> 
>> I wrote a rough patch to add the device IDs, and the patch is below:
> 
> FWIW, that is the same change I would have made. Peeking at the Linux
> vmd driver, it doesn't appear to do anything special for 8086:9a0b as
> compared to the 8086:2a0c device the FreeBSD driver already supports.
> That said, the Linux driver reads a capability register to determine
> the bus number start (vmd_bus_number_start()) which I don't see in the
> FreeBSD driver. This is curious because, looking at the "lspci all"
> output from the XPS link you provided, the NVMe device shows up in PCI
> domain 0x1000 (i.e. not 0x0000). Which (and I have no direct
> experience with this device or code) only happens if the bus number
> start function returns 0x0.
> 
> What is the output from
> # pciconf -rb pci0:0:14:0 0x40:0x48
> 
> --chuck
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to 
> "freebsd-current-unsubscribe at freebsd.org"

From darkfiberiru at gmail.com  Thu Dec 31 05:07:35 2020
From: darkfiberiru at gmail.com (Nick Wolff)
Date: Thu, 31 Dec 2020 00:07:17 -0500
Subject: usr.bin/xinstall r366697 versus: buildworld: lib/libc: install:
 short write to libc.so.7.debug: [_libinstall] Error code 71
In-Reply-To: <cb81af02-00cb-a6f8-7ad6-555f5220f468@FreeBSD.org>
References: <746a3af4-3daf-9029-bf48-23efa3f5da8e@gmail.com>
 <37d2a873-8cb9-b858-fa06-4bbfcf006835@gmail.com>
 <1e9e8649-0fe7-4b83-078d-f67908e2f430@gmail.com>
 <40C5DB30-4B7C-4A51-8069-B4E67298C558@FreeBSD.org>
 <9b6bbf0b-93d2-123e-ee5c-f8de660b150a@gmail.com>
 <b08bf10e-50f9-79c8-58e3-f46eac1307bd@gmail.com>
 <cb81af02-00cb-a6f8-7ad6-555f5220f468@FreeBSD.org>
Message-ID: <CACxAneAUjjdEA_aqpaCmpPOjg_4YJ5Wq+Y-gwBWm3H5cFc5LCw@mail.gmail.com>

I also have this breaking builds. Do we have plans to revert this until a
variant that doesn't break builds in some corner cases is completed?

On Tue, Dec 15, 2020 at 12:22 PM Ryan Moeller <freqlabs at freebsd.org> wrote:

>
> On 12/12/20 2:15 AM, Graham Perrin wrote:
> > On 23/11/2020 12:18, Graham Perrin wrote:
> >
> >> On 22/11/2020 12:00, Dimitry Andric wrote:
> >>> ?
> >>> I'd guess it's an unintended side-effect of
> >>> https://svnweb.freebsd.org/base?view=revision&revision=366697
> >>> ("install(1): Avoid unncessary fstatfs() calls and use mmap() based on
> >>> size").
> >>>
> >>> If you only revert usr.bin/xinstall to r366696, and then rebuild it,
> >>> does it still occur?
> >>>
> >>> -Dimitry
> >>
> >> Thank you!
> >>
> >> Success with r366696:
> >>
> >> ----
> >>
> >> ?
> >
> >
> > Re:
> > <
> https://lists.freebsd.org/pipermail/freebsd-current/2020-November/077634.html>
>
> > please, should I open a bug for this?
> >
> >
> > Is the issue exposed by my choice of gzip-9 for e.g. /usr/ and if so,
> > can I avoid it by (now) reverting to lz4 for that part, and/or any
> > other part, of the file system?
> >
> >
>
> Unfortunately I don't have an answer for you at this time, but ACK.
>
>
> -Ryan
>
>
> > ----
> >
> >
> > root at mowa219-gjp4-8570p:~ # zfs get mountpoint,compression
> > NAME PROPERTY     VALUE SOURCE
> > Transcend mountpoint /Volumes/t500                                  local
> > Transcend compression zstd
> > local
> > Transcend/VirtualBox mountpoint   /Volumes/t500/VirtualBox inherited
> > from Transcend
> > Transcend/VirtualBox compression  zstd inherited from Transcend
> > copperbowl mountpoint /copperbowl
> > local
> > copperbowl compression lz4
> > local
> > copperbowl/ROOT mountpoint
> > none                                           local
> > copperbowl/ROOT compression  lz4 inherited from copperbowl
> > copperbowl/ROOT/Waterfox mountpoint
> > /                                              local
> > copperbowl/ROOT/Waterfox compression  lz4 inherited from copperbowl
> > copperbowl/ROOT/r367081f mountpoint
> > /                                              local
> > copperbowl/ROOT/r367081f compression  lz4 inherited from copperbowl
> > copperbowl/ROOT/r367936e mountpoint
> > /                                              local
> > copperbowl/ROOT/r367936e compression  lz4 inherited from copperbowl
> > copperbowl/ROOT/r367936f mountpoint
> > /                                              local
> > copperbowl/ROOT/r367936f compression  lz4 inherited from copperbowl
> > copperbowl/ROOT/r367936f at 2020-03-20-06:19:45 mountpoint
> > -                                              -
> > copperbowl/ROOT/r367936f at 2020-03-20-06:19:45 compression
> > -                                              -
> > copperbowl/ROOT/r367936f at 2020-11-22-23:18:47 mountpoint
> > -                                              -
> > copperbowl/ROOT/r367936f at 2020-11-22-23:18:47 compression
> > -                                              -
> > copperbowl/ROOT/r367936f at 2020-12-06-16:23:14 mountpoint
> > -                                              -
> > copperbowl/ROOT/r367936f at 2020-12-06-16:23:14 compression
> > -                                              -
> > copperbowl/VirtualBox mountpoint
> > /usr/local/VirtualBox                          local
> > copperbowl/VirtualBox compression
> > gzip-9                                         local
> > copperbowl/iocage mountpoint   /copperbowl/iocage inherited from
> > copperbowl
> > copperbowl/iocage compression
> > gzip-9                                         local
> > copperbowl/iocage/download mountpoint /copperbowl/iocage/download
> > inherited from copperbowl
> > copperbowl/iocage/download compression
> > lz4                                            local
> > copperbowl/iocage/download/12.0-RELEASE mountpoint
> > /copperbowl/iocage/download/12.0-RELEASE inherited from copperbowl
> > copperbowl/iocage/download/12.0-RELEASE compression
> > lz4                                            local
> > copperbowl/iocage/images mountpoint   /copperbowl/iocage/images
> > inherited from copperbowl
> > copperbowl/iocage/images compression
> > lz4                                            local
> > copperbowl/iocage/jails mountpoint   /copperbowl/iocage/jails
> > inherited from copperbowl
> > copperbowl/iocage/jails compression
> > lz4                                            local
> > copperbowl/iocage/jails/jbrowsers mountpoint
> > /copperbowl/iocage/jails/jbrowsers inherited from copperbowl
> > copperbowl/iocage/jails/jbrowsers compression  lz4 inherited from
> > copperbowl/iocage/jails
> > copperbowl/iocage/jails/jbrowsers/root mountpoint
> > /copperbowl/iocage/jails/jbrowsers/root inherited from copperbowl
> > copperbowl/iocage/jails/jbrowsers/root compression  lz4 inherited from
> > copperbowl/iocage/jails
> > copperbowl/iocage/log mountpoint   /copperbowl/iocage/log inherited
> > from copperbowl
> > copperbowl/iocage/log compression
> > lz4                                            local
> > copperbowl/iocage/releases mountpoint /copperbowl/iocage/releases
> > inherited from copperbowl
> > copperbowl/iocage/releases compression
> > lz4                                            local
> > copperbowl/iocage/releases/12.0-RELEASE mountpoint
> > /copperbowl/iocage/releases/12.0-RELEASE inherited from copperbowl
> > copperbowl/iocage/releases/12.0-RELEASE compression  lz4 inherited
> > from copperbowl/iocage/releases
> > copperbowl/iocage/releases/12.0-RELEASE/root mountpoint
> > /copperbowl/iocage/releases/12.0-RELEASE/root inherited from copperbowl
> > copperbowl/iocage/releases/12.0-RELEASE/root compression
> > lz4                                            local
> > copperbowl/iocage/releases/12.0-RELEASE/root at jbrowsers mountpoint
> > -                                              -
> > copperbowl/iocage/releases/12.0-RELEASE/root at jbrowsers compression
> > -                                              -
> > copperbowl/iocage/templates mountpoint /copperbowl/iocage/templates
> > inherited from copperbowl
> > copperbowl/iocage/templates compression
> > lz4                                            local
> > copperbowl/poudriere mountpoint   /copperbowl/poudriere inherited from
> > copperbowl
> > copperbowl/poudriere compression
> > gzip-9                                         local
> > copperbowl/poudriere/data mountpoint
> > /usr/local/poudriere/data                      local
> > copperbowl/poudriere/data compression
> > gzip-9                                         local
> > copperbowl/poudriere/data/.m mountpoint /usr/local/poudriere/data/.m
> > inherited from copperbowl/poudriere/data
> > copperbowl/poudriere/data/.m compression  gzip-9 inherited from
> > copperbowl/poudriere/data
> > copperbowl/poudriere/data/cache mountpoint
> > /usr/local/poudriere/data/cache inherited from copperbowl/poudriere/data
> > copperbowl/poudriere/data/cache compression
> > off                                            local
> > copperbowl/poudriere/data/logs mountpoint
> > /usr/local/poudriere/data/logs inherited from copperbowl/poudriere/data
> > copperbowl/poudriere/data/logs compression
> > gzip-9                                         local
> > copperbowl/poudriere/data/packages mountpoint
> > /usr/local/poudriere/data/packages inherited from
> > copperbowl/poudriere/data
> > copperbowl/poudriere/data/packages compression
> > off                                            local
> > copperbowl/poudriere/data/wrkdirs mountpoint
> > /usr/local/poudriere/data/wrkdirs inherited from
> > copperbowl/poudriere/data
> > copperbowl/poudriere/data/wrkdirs compression
> > off                                            local
> > copperbowl/poudriere/jails mountpoint /copperbowl/poudriere/jails
> > inherited from copperbowl
> > copperbowl/poudriere/jails compression
> > gzip-9                                         local
> > copperbowl/poudriere/jails/head mountpoint
> > /usr/local/poudriere/jails/head                local
> > copperbowl/poudriere/jails/head compression
> > gzip-9                                         local
> > copperbowl/poudriere/jails/head at clean mountpoint
> > -                                              -
> > copperbowl/poudriere/jails/head at clean compression
> > -                                              -
> > copperbowl/poudriere/ports mountpoint /copperbowl/poudriere/ports
> > inherited from copperbowl
> > copperbowl/poudriere/ports compression  gzip-9 inherited from
> > copperbowl/poudriere
> > copperbowl/poudriere/ports/default mountpoint
> > /usr/local/poudriere/ports/default             local
> > copperbowl/poudriere/ports/default compression
> > gzip-9                                         local
> > copperbowl/poudriere/ports/freebsd-ports-kde mountpoint
> > /usr/local/poudriere/ports/freebsd-ports-kde   local
> > copperbowl/poudriere/ports/freebsd-ports-kde compression
> > gzip-9                                         local
> > copperbowl/tmp mountpoint
> > /tmp                                           local
> > copperbowl/tmp compression
> > off                                            local
> > copperbowl/usr mountpoint
> > /usr                                           local
> > copperbowl/usr compression
> > gzip-9                                         local
> > copperbowl/usr/home mountpoint   /usr/home inherited from copperbowl/usr
> > copperbowl/usr/home compression
> > lz4                                            local
> > copperbowl/usr/home at 2020-09-19-20:29-r365364 mountpoint
> > -                                              -
> > copperbowl/usr/home at 2020-09-19-20:29-r365364 compression
> > -                                              -
> > copperbowl/usr/ports mountpoint   /usr/ports inherited from
> > copperbowl/usr
> > copperbowl/usr/ports compression  gzip-9 inherited from copperbowl/usr
> > copperbowl/usr/src mountpoint   /usr/src inherited from copperbowl/usr
> > copperbowl/usr/src compression  gzip-9 inherited from copperbowl/usr
> > copperbowl/var mountpoint
> > /var                                           local
> > copperbowl/var compression  lz4 inherited from copperbowl
> > copperbowl/var/audit mountpoint   /var/audit inherited from
> > copperbowl/var
> > copperbowl/var/audit compression  lz4 inherited from copperbowl
> > copperbowl/var/crash mountpoint   /var/crash inherited from
> > copperbowl/var
> > copperbowl/var/crash compression  lz4 inherited from copperbowl
> > copperbowl/var/log mountpoint   /var/log inherited from copperbowl/var
> > copperbowl/var/log compression  lz4 inherited from copperbowl
> > copperbowl/var/mail mountpoint   /var/mail inherited from copperbowl/var
> > copperbowl/var/mail compression  lz4 inherited from copperbowl
> > copperbowl/var/tmp mountpoint   /var/tmp inherited from copperbowl/var
> > copperbowl/var/tmp compression  lz4 inherited from copperbowl
> > copperbowl/vm-bhyve mountpoint   /copperbowl/vm-bhyve inherited from
> > copperbowl
> > copperbowl/vm-bhyve compression  gzip-9
> >
> > _______________________________________________
> > freebsd-current at freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to
> > "freebsd-current-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>

From roberthuff at rcn.com  Thu Dec 31 05:13:20 2020
From: roberthuff at rcn.com (Robert Huff)
Date: Thu, 31 Dec 2020 00:13:16 -0500
Subject: problem building kernel for r368820
Message-ID: <24557.24044.631975.277382@jerusalem.litteratus.org>


Hello:
	I'm trying to update a system from:

FreeBSD 13.0-CURRENT #0 r365372: Sun Sep  6 10:51:26 EDT 2020 
amd64

	to the latest version.
	buildworld completes successfully.
	buildkernel, however, dies with:


        struct device dev;
                      ^
/usr/src/sys/sys/types.h:275:16: note: forward declaration of 'struct device'
typedef struct device   *device_t;
               ^
In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_backlight.c:12:
In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4:
In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:44:
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/backlight.h:152:9: error: implicit declaration of function 'dev_get_drvdata' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        return dev_get_drvdata(&bl_dev->dev);
               ^
In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_backlight.c:12:
In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4:
/usr/src/sys/compat/linuxkpi/common/include/linux/device.h:212:1: error: static declaration of 'dev_get_drvdata' follows non-static declaration
dev_get_drvdata(const struct device *dev)
^
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:242:9: note: previous implicit declaration is here
        return dev_get_drvdata(&dev->dev);
               ^
In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_backlight.c:12:
In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4:
/usr/src/sys/compat/linuxkpi/common/include/linux/device.h:219:1: error: static declaration of 'dev_set_drvdata' follows non-static declaration
dev_set_drvdata(struct device *dev, void *data)
^
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:248:2: note: previous implicit declaration is here
        dev_set_drvdata(&dev->dev, data);
        ^
In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_backlight.c:12:
In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4:
/usr/src/sys/compat/linuxkpi/common/include/linux/device.h:438:1: error: static declaration of 'device_unregister' follows non-static declaration
device_unregister(struct device *dev)
^
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:236:2: note: previous implicit declaration is here
        device_unregister(&client->dev);
        ^
/usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_backlight.c:277:27: error: initializing 'struct backlight_device *' with an expression of incompatible type 'void'
        struct backlight_device *bd = to_backlight_device(dev);
                                 ^    ~~~~~~~~~~~~~~~~~~~~~~~~
12 errors generated.
*** Error code 1

Stop.
make[4]: stopped in /usr/local/sys/modules/drm-current-kmod/linuxkpi
*** Error code 1
*** Error code 1

	(The configuration file is appended.)
	There's nothing in UPDATING to suggest a cause, and I haven't
seen anything on this list.  This implies it's my fault.
	Help, please?


			Respectfully,


				Robert Huff


#
# JERUSALEM --  kernel configuration file for FreeBSD/amd64
#
# For more information on this file, please read the config(5) manual page,
# and/or the handbook section on Kernel Configuration Files:
#
#    https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (https://www.FreeBSD.org/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the ../../conf/NOTES and NOTES files.
# If you are in doubt as to the purpose or necessity of a line, check first
# in NOTES.
#
# $FreeBSD: head/sys/amd64/conf/GENERIC  343949 2019-02-10 07:54:46Z cem $

cpu			HAMMER
ident		JERUSALEM

makeoptions	DEBUG=-g		# Build kernel with gdb(1) debug symbols
makeoptions	WITH_CTF=1		# Run ctfconvert(1) for DTrace support

options 	SCHED_ULE		# ULE scheduler
options 	NUMA			# Non-Uniform Memory Architecture support
options 	PREEMPTION	# Enable kernel thread preemption
options 	VIMAGE		# Subsystem virtualization, e.g. VNET
options 	INET			# InterNETworking
options 	INET6		# IPv6 communications protocols
options 	IPSEC_SUPPORT		# Allow kldload of ipsec and tcpmd5
options	ROUTE_MPATH		# Multipath routing support
options 	TCP_OFFLOAD	# TCP offload
options 	TCP_BLACKBOX	# Enhanced TCP event logging
options 	TCP_HHOOK		# hhook(9) framework for TCP
options	TCP_RFC7413	# TCP Fast Open
options 	SCTP_SUPPORT		# Allow kldload of SCTP
options 	FFS			# Berkeley Fast Filesystem
options 	SOFTUPDATES		# Enable FFS soft updates support
options 	UFS_ACL			# Support for access control lists
options 	UFS_DIRHASH		# Improve performance on big directories
options 	UFS_GJOURNAL		# Enable gjournal-based UFS journaling
options 	QUOTA			# Enable disk quotas for UFS
options 	MD_ROOT			# MD is a potential root device
options 	NFSCL			# Network Filesystem Client
options 	NFSD				# Network Filesystem Server
options 	NFSLOCKD		  	# Network Lock Manager
options 	NFS_ROOT		  	# NFS usable as /, requires NFSCL
options 	MSDOSFS			# MSDOS Filesystem
options 	CD9660			# ISO 9660 Filesystem
options 	PROCFS			# Process filesystem (requires PSEUDOFS)
options 	PSEUDOFS			# Pseudo-filesystem framework
options 	TMPFS			# Efficient memory filesystem
options 	GEOM_PART_GPT		# GUID Partition Tables.
options 	GEOM_RAID			# Soft RAID functionality.
options 	GEOM_LABEL		# Provides labelization
options 	EFIRT			# EFI Runtime Services support
options 	COMPAT_FREEBSD32	# Compatible with i386 binaries
options 	COMPAT_FREEBSD11	# Compatible with FreeBSD11
options 	COMPAT_FREEBSD12	# Compatible with FreeBSD12
options 	SCSI_DELAY=5000	# Delay (in ms) before probing SCSI
options 	KTRACE			# ktrace(1) support
options 	STACK			# stack(9) support
options 	SYSVSHM			# SYSV-style shared memory
options 	SYSVMSG			# SYSV-style message queues
options 	SYSVSEM			# SYSV-style semaphores
options 	_KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions
options 	PRINTF_BUFR_SIZE=128	# Prevent printf output being interspersed.
options 	KBD_INSTALL_CDEV	# install a CDEV entry in /dev
options 	HWPMC_HOOKS		# Necessary kernel hooks for hwpmc(4)
options 	AUDIT			# Security event auditing
options 	CAPABILITY_MODE	# Capsicum capability mode
options 	CAPABILITIES		# Capsicum capabilities
options 	MAC				# TrustedBSD MAC Framework
options 	KDTRACE_FRAME		# Ensure frames are compiled in
options 	KDTRACE_HOOKS		# Kernel DTrace hooks
options 	DDB_CTF			# Kernel ELF linker loads CTF data
options 	INCLUDE_CONFIG_FILE	# Include this file in kernel
options 	RACCT			# Resource accounting framework
options 	RACCT_DEFAULT_TO_DISABLED # Set kern.racct.enable=0 by default
options 	RCTL				# Resource limits

# Debugging support.  Always need this:
options 	KDB			# Enable kernel debugger support.
options 	KDB_TRACE		# Print a stack trace for a panic.
# For full debugger support use (turn off in stable branch):
options 	BUF_TRACKING		# Track buffer history
options 	DDB			# Support DDB.
options 	FULL_BUF_TRACKING	# Track more buffer history
options 	GDB			# Support remote GDB.
options 	DEADLKRES		# Enable the deadlock resolver
options 	INVARIANTS		# Enable calls of extra sanity checking
options 	INVARIANT_SUPPORT	# Extra sanity checks of internal structures, required by INVARIANTS
options 	QUEUE_MACRO_DEBUG_TRASH	# Trash queue(2) internal pointers on invalidation
options 	WITNESS			# Enable checks to detect deadlocks and cycles
options 	WITNESS_SKIPSPIN	# Don't run witness on spinlocks for speed
options 	MALLOC_DEBUG_MAXZONES=8	# Separate malloc(9) zones
options 	VERBOSE_SYSINIT=0	# Support debug.verbose_sysinit, off by default

# Kernel dump features.
options 	EKCD			# Support for encrypted kernel dumps
options 	GZIO			# gzip-compressed kernel and user dumps
options 	ZSTDIO			# zstd-compressed kernel and user dumps
options 	DEBUGNET		# debugnet networking
options 	NETDUMP			# netdump(4) client support
options 	NETGDB			# netgdb(4) client support

# Make an SMP-capable kernel by default
options 	SMP			# Symmetric MultiProcessor Kernel
options 	EARLY_AP_STARTUP

# CPU frequency control
device	cpufreq

# Bus support.
device	acpi
options 	IOMMU
device	pci
options 	PCI_HP			# PCI-Express native HotPlug
options	PCI_IOV			# PCI SR-IOV support

# Floppy drives
device	fdc

# ATA controllers
device		ahci			# AHCI-compatible SATA controllers
device		ata			# Legacy ATA/SATA controllers
device		mvs			# Marvell 88SX50XX/88SX60XX/88SX70XX/SoC SATA
device		siis			# SiliconImage SiI3124/SiI3132/SiI3531 SATA

# ATA/SCSI peripherals
device		scbus		# SCSI bus (required for ATA/SCSI)
device		ch			# SCSI media changers
device		da			# Direct Access (disks)
device		sa			# Sequential Access (tape etc)
device		cd			# CD
device		pass			# Passthrough device (direct ATA/SCSI access)
device		ses			# Enclosure Services (SES and SAF-TE)
#device		ctl			# CAM Target Layer

# NVM Express (NVMe) support
device		nvme			# base NVMe driver
device		nvd			# expose NVMe namespaces as disks, depends on nvme

# atkbdc0 controls both the keyboard and the PS/2 mouse
device		atkbdc		# AT keyboard controller
device		atkbd		# AT keyboard
device		psm			# PS/2 mouse

device		kbdmux		# keyboard multiplexer

device		vga			# VGA video card driver
options		VESA			# Add support for VESA BIOS Extensions (VBE)

device		splash			# Splash screen and screen saver support

# syscons is the default console driver, resembling an SCO console
device		sc
options 	SC_PIXEL_MODE		# add support for the raster text mode

# vt is the new video console driver
device		vt
device		vt_vga
device		vt_efifb

device		agp			# support several AGP chipsets

# PCCARD (PCMCIA) support
# PCMCIA and cardbus bridge support
device		cbb			# cardbus (yenta) bridge
device		pccard			# PC Card (16-bit) bus
device		cardbus			# CardBus (32-bit) bus

# Serial (COM) ports
device		uart			# Generic UART driver

# Parallel port
device		ppc
device		ppbus			# Parallel port bus (required)
device		lpt			# Printer
device		ppi			# Parallel port interface device
#device		vpo			# Requires scbus and da

device		puc			# Multi I/O cards and multi-channel UARTs

# These PCI/PCI-X/PCIe Ethernet NICs use iflib infrastructure

device 		iflib
device		em			# Intel PRO/1000 Gigabit Ethernet Family
device		ix			# Intel PRO/10GbE PCIE PF Ethernet
device		ixv			# Intel PRO/10GbE PCIE VF Ethernet
device		ixl			# Intel 700 Series Physical Function
device		iavf			# Intel Adaptive Virtual Function
device		ice			# Intel 800 Series Physical Function
device		vmx			# VMware VMXNET3 Ethernet
device		axp			# AMD EPYC integrated NIC

# PCI Ethernet NICs.

device		bxe			# Broadcom NetXtreme II BCM5771X/BCM578XX 10GbE
device		le			# AMD Am7900 LANCE and Am79C9xx PCnet
device		ti			# Alteon Networks Tigon I/II gigabit Ethernet


# PCI Ethernet NICs that use the common MII bus controller code.
# NOTE: Be sure to keep the 'device miibus' line in order to use these NICs!
device		miibus			# MII bus support
device		ae			# Attansic/Atheros L2 FastEthernet
device		age			# Attansic/Atheros L1 Gigabit Ethernet
device		alc			# Atheros AR8131/AR8132 Ethernet
device		ale			# Atheros AR8121/AR8113/AR8114 Ethernet
device		bce			# Broadcom BCM5706/BCM5708 Gigabit Ethernet
device		bfe			# Broadcom BCM440x 10/100 Ethernet
device		bge			# Broadcom BCM570xx Gigabit Ethernet
device		cas			# Sun Cassini/Cassini+ and NS DP83065 Saturn
device		dc			# DEC/Intel 21143 and various workalikes
device		et			# Agere ET1310 10/100/Gigabit Ethernet
device		fxp			# Intel EtherExpress PRO/100B (82557, 82558)
device		gem			# Sun GEM/Sun ERI/Apple GMAC
device		jme			# JMicron JMC250 Gigabit/JMC260 Fast Ethernet
device		lge			# Level 1 LXT1001 gigabit Ethernet
device		msk			# Marvell/SysKonnect Yukon II Gigabit Ethernet
device		nfe			# nVidia nForce MCP on-board Ethernet
device		nge			# NatSemi DP83820 gigabit Ethernet
device		re			# RealTek 8139C+/8169/8169S/8110S
device		rl			# RealTek 8129/8139
device		sge			# Silicon Integrated Systems SiS190/191
device		sis			# Silicon Integrated Systems SiS 900/SiS 7016
device		sk			# SysKonnect SK-984x & SK-982x gigabit Ethernet
device		ste			# Sundance ST201 (D-Link DFE-550TX)
device		stge			# Sundance/Tamarack TC9021 gigabit Ethernet
device		vge			# VIA VT612x gigabit Ethernet
device		vr			# VIA Rhine, Rhine II
device		xl			# 3Com 3c90x (``Boomerang'', ``Cyclone'')

# Wireless NIC cards
device		wlan			# 802.11 support
options		IEEE80211_DEBUG		# enable debug msgs
options		IEEE80211_SUPPORT_MESH	# enable 802.11s draft support
device		wlan_wep		# 802.11 WEP support
device		wlan_ccmp		# 802.11 CCMP support
device		wlan_tkip		# 802.11 TKIP support
device		wlan_amrr		# AMRR transmit rate control algorithm
device		an			# Aironet 4500/4800 802.11 wireless NICs.
device		ath			# Atheros NICs
device		ath_pci			# Atheros pci/cardbus glue
device		ath_hal			# pci/cardbus chip support
options		AH_AR5416_INTERRUPT_MITIGATION # AR5416 interrupt mitigation
options		ATH_ENABLE_11N		# Enable 802.11n support for AR5416 and later
device		ath_rate_sample		# SampleRate tx rate control for ath
#device		bwi			# Broadcom BCM430x/BCM431x wireless NICs.
#device		bwn			# Broadcom BCM43xx wireless NICs.
device		ipw			# Intel 2100 wireless NICs.
device		iwi			# Intel 2200BG/2225BG/2915ABG wireless NICs.
device		iwn			# Intel 4965/1000/5000/6000 wireless NICs.
device		malo			# Marvell Libertas wireless NICs.
device		mwl			# Marvell 88W8363 802.11n wireless NICs.
device		ral			# Ralink Technology RT2500 wireless NICs.
device		wi			# WaveLAN/Intersil/Symbol 802.11 wireless NICs.
device		wpi			# Intel 3945ABG wireless NICs.

# Pseudo devices.
device		crypto		# core crypto support
device		loop			# Network loopback
device		padlock_rng	# VIA Padlock RNG
device		rdrand_rng	# Intel Bull Mountain RNG
device		ether		# Ethernet support
device		vlan			# 802.1Q VLAN support
device		md			# Memory "disks"
device		gif			# IPv6 and IPv4 tunneling
device		firmware		# firmware assist module

# The `bpf' device enables the Berkeley Packet Filter.
# Be aware of the administrative consequences of enabling this!
# Note that 'bpf' is required for DHCP.
device		bpf			# Berkeley packet filter

# USB support
options 	USB_DEBUG		# enable debug msgs
device	uhci			# UHCI PCI->USB interface
device	ohci			# OHCI PCI->USB interface
device	ehci			# EHCI PCI->USB interface (USB 2.0)
device	xhci			# XHCI PCI->USB interface (USB 3.0)
device	usb			# USB Bus (required)
device	ukbd			# Keyboard
device	umass		# Disks/Mass storage - Requires scbus and da

# Sound support
device		sound			# Generic sound driver (required)
device		snd_cmi			# CMedia CMI8338/CMI8738
device		snd_csa			# Crystal Semiconductor CS461x/428x
device		snd_emu10kx		# Creative SoundBlaster Live! and Audigy
device		snd_es137x		# Ensoniq AudioPCI ES137x
device		snd_hda			# Intel High Definition Audio
device		snd_ich			# Intel, NVidia and other ICH AC'97 Audio
device		snd_via8233		# VIA VT8233x Audio

# MMC/SD
device		mmc			# MMC/SD bus
device		mmcsd			# MMC/SD memory card
device		sdhci			# Generic PCI SD Host Controller

# VirtIO support
device		virtio			# Generic VirtIO bus (required)
device		virtio_pci		# VirtIO PCI device
device		vtnet			# VirtIO Ethernet device
device		virtio_blk		# VirtIO Block device
device		virtio_scsi		# VirtIO SCSI device
device		virtio_balloon		# VirtIO Memory Balloon device

# HyperV drivers and enhancement support
device		hyperv			# HyperV drivers 

# Xen HVM Guest Optimizations
# NOTE: XENHVM depends on xenpci.  They must be added or removed together.
options 	XENHVM			# Xen HVM kernel infrastructure
device	xenpci			# Xen HVM Hypervisor services driver

# Netmap provides direct access to TX/RX rings on supported NICs
device		netmap			# netmap(4) support

# evdev interface
options 	EVDEV_SUPPORT		# evdev support in legacy drivers
device	evdev			# input event device support
device	uinput			# install /dev/uinput cdev

From rmacklem at uoguelph.ca  Thu Dec 31 05:16:30 2020
From: rmacklem at uoguelph.ca (Rick Macklem)
Date: Thu, 31 Dec 2020 05:16:27 +0000
Subject: r367672 broke the NFS server
In-Reply-To: <X+y4bK8/1akNNh4Z@kib.kiev.ua>
References: <YQXPR0101MB0968DC349AFD081480768028DDD70@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
 <X+x4NSeWI+z5QkP3@kib.kiev.ua>
 <YQXPR0101MB09687E622BDBBE59C964FAC4DDD70@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>,
 <X+y4bK8/1akNNh4Z@kib.kiev.ua>
Message-ID: <YQXPR0101MB0968B36B267F4217C74CC9E9DDD60@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>

Rick Macklem wrote:
>Kostik wrote:
> >
> >Idea of the change is to restart the syscall at top level.  So for NFS
> >server the right approach is to not send a response and also to not
> >free the request mbuf chain, but to restart processing.
> Yes. I took a look and I think restarting the operation by rolling the
> working position in the mbuf lists back and redoing the operation
> is feasible and easier than fixing the individual operations.
>
> For NFSv4, you cannot redo the entire compound, since non-idempotent
> operations like exclusive open may have already been completed.
> However, rolling back to the beginning of the operation should be
> doable.
Turned out to be quite easy. I'll stick a patch up on phabricator
tomorrow, after I do a little more testing.
NFSv4.0 is still broken, because it screws up the seqid, but I can
fix that separately.

I do see the code looping about 2-3 times before it gets a successful
ufs_create(). Does that sound reasonable?
Here's some debug printfs for the test run of 4 concurrent compiles.
(proc=8 is create and proc=12 is remove. Each line is a ERELOOKUP
 retry. This is for the 4 threads, but I had the thread tid in another printf
 and it showed 2-3 attempts for the same thread. They should be serialized
 by the exclusive lock on the directory vnode.)
tryag3 stat=0 proc=8
tryag3 stat=0 proc=8
tryag3 stat=0 proc=8
tryag3 stat=0 proc=12
tryag3 stat=0 proc=8
tryag3 stat=0 proc=8
tryag3 stat=0 proc=8
tryag3 stat=0 proc=8
tryag3 stat=0 proc=8
tryag3 stat=0 proc=12
tryag3 stat=0 proc=8
tryag3 stat=0 proc=8
tryag3 stat=0 proc=8
tryag3 stat=0 proc=8
tryag3 stat=0 proc=8
tryag3 stat=0 proc=12
tryag3 stat=0 proc=8
tryag3 stat=0 proc=8
tryag3 stat=0 proc=8
tryag3 stat=0 proc=12
tryag3 stat=0 proc=8
tryag3 stat=0 proc=8
tryag3 stat=0 proc=8
tryag3 stat=0 proc=12
tryag3 stat=0 proc=8
tryag3 stat=0 proc=8
tryag3 stat=0 proc=8
tryag3 stat=0 proc=8
tryag3 stat=0 proc=8
tryag3 stat=0 proc=8
tryag3 stat=0 proc=12
tryag3 stat=0 proc=8
tryag3 stat=0 proc=8

Thanks for the suggestion, Kostik.

rick

> --> It will serve as a good test, in that it may expose bugs in the
>       RPC/operation code where failure (ERELOOKUP) doesn't clean
>       things up correctly.
>       --> In NFSv4, there is the open/lock state that cannot be updated
>             for this error case. (The seqid stuff in NFSv4.0 Open can be fun.
>             Its used to serialize the operations and the number must be
>             incremented for some errors, but not for others. The 10026
>             error occurs when you don't get this right.)
Note that ERELOOKUP error can only show up from the VOPs that modify the volume.
Otherwise we simply do not call into SU.  In particular, I believe that opens
in the sense of NFS are safe.

Regardless of it, there should be either a catch-all check for ERELOOKUP,
or assert that ERELOOKUP did not leaked, as it is done for syscalls

>
> I'll start working on this to-day, but I have no idea how long it might
> take?
>
> >I am sorry I forgot about NFS server when designing this fix, the only
> >mild excuse I can provide is that the change was quite complicated as is.
> >I will start looking at the fix.
> No problem. Sometimes I'd like to forget about NFS too;-).
>
> For the rollback/redo the RPC/operation case, it's probably easier for me
> to do it. As above, I'll start on it, but...
>
> My main concern is how long it will take, given the FreeBSD13 release
> starts soon.
For sure I will help you if needed, and I believe that we could ask for
testing from Peter.
_______________________________________________
freebsd-current at freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"


From neel at neelc.org  Thu Dec 31 05:37:33 2020
From: neel at neelc.org (Neel Chauhan)
Date: Wed, 30 Dec 2020 21:37:30 -0800
Subject: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch
In-Reply-To: <75d6b956e227249774978dc09cd26c3f@neelc.org>
References: <eeab20a1316335317d3ff8cbf68c1cf1@neelc.org>
 <CAKAYmMLn8rO-dJd+VYPguM9KmcXbkBiPnBu3bygRHBNpNn+S5w@mail.gmail.com>
 <75d6b956e227249774978dc09cd26c3f@neelc.org>
Message-ID: <8978ff9014c0d6dddaf3fb0d599dfb59@neelc.org>

On 2020-12-30 21:04, Neel Chauhan wrote:
> It is likely because VMD uses PCI domain above 0x10000 but we aren't
> looking at this.

The 0x10000 is purely a Linux construct. It seems the PCI domains are 
virtual.

Source: https://lists.x.org/archives/xorg-devel/2016-August/050590.html

-Neel

From neel at neelc.org  Thu Dec 31 05:42:52 2020
From: neel at neelc.org (Neel Chauhan)
Date: Wed, 30 Dec 2020 21:42:42 -0800
Subject: PCIe Root Port/Bus Not Detected in VMD
Message-ID: <aa9632b47ad2173154fb5f11456f531d@neelc.org>

Hi freebsd-current@,

My apologies for so many emails from me. I sent another copy of this 
email to freebsd-hackers at .

I have the following patch:

diff --git a/sys/dev/vmd/vmd.c b/sys/dev/vmd/vmd.c
index 2cc6f45bed9..7cc0a8a91a7 100644
--- a/sys/dev/vmd/vmd.c
+++ b/sys/dev/vmd/vmd.c
@@ -66,10 +66,12 @@ struct vmd_type {
  #define INTEL_VENDOR_ID		0x8086
  #define INTEL_DEVICE_ID_VMD	0x201d
  #define INTEL_DEVICE_ID_VMD2	0x28c0
+#define INTEL_DEVICE_ID_VMD3	0x9a0b

  static struct vmd_type vmd_devs[] = {
          { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD,  "Intel Volume 
Management Device" },
          { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD2, "Intel Volume 
Management Device" },
+        { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD3, "Intel Volume 
Management Device" },
          { 0, 0, NULL }
  };

@@ -425,6 +427,7 @@ vmd_attach(device_t dev)
  	return (0);

  fail:
+	rman_fini(&sc->vmd_bus.rman);
  	vmd_free(sc);
  	return (ENXIO);
  }

This patch helps me detect the VMD controller, but I am unable to attach 
to it.

Therefore, I am not able to attach any PCIe buses that will be used by a 
NVMe SSD.

If this patch worked, I would see these devices (as I do in Linux):

10000:e0:1d.0 PCI bridge [0604]: Intel Corporation Tiger Lake-LP PCI 
Express Root Port #9 [8086:a0b0] (rev 20) SI
10000:e0:1d.2 PCI bridge [0604]: Intel Corporation Device [8086:a0b2] 
(rev 20)
10000:e1:00.0 Non-Volatile memory controller [0108]: Intel Corporation 
Device [8086:0975] (rev 03)
10000:e2:00.0 Non-Volatile memory controller [0108]: Intel Corporation 
Device [8086:0975]

And therefore a `nvd*` device.

Could a developer please help me with this?

-Neel

===

https://www.neelc.org/

From neel at neelc.org  Thu Dec 31 05:45:25 2020
From: neel at neelc.org (Neel Chauhan)
Date: Wed, 30 Dec 2020 21:45:22 -0800
Subject: PCIe Root Port/Bus Not Detected in VMD
In-Reply-To: <aa9632b47ad2173154fb5f11456f531d@neelc.org>
References: <aa9632b47ad2173154fb5f11456f531d@neelc.org>
Message-ID: <ba5b92e33d83fe5c5a235537203a1c09@neelc.org>

For reference, I am attaching the `pciconf -lv` and `acpidump -dt` 
dumps.

-Neel

On 2020-12-30 21:42, Neel Chauhan wrote:
> Hi freebsd-current@,
> 
> My apologies for so many emails from me. I sent another copy of this
> email to freebsd-hackers at .
> 
> I have the following patch:
> 
> diff --git a/sys/dev/vmd/vmd.c b/sys/dev/vmd/vmd.c
> index 2cc6f45bed9..7cc0a8a91a7 100644
> --- a/sys/dev/vmd/vmd.c
> +++ b/sys/dev/vmd/vmd.c
> @@ -66,10 +66,12 @@ struct vmd_type {
>  #define INTEL_VENDOR_ID		0x8086
>  #define INTEL_DEVICE_ID_VMD	0x201d
>  #define INTEL_DEVICE_ID_VMD2	0x28c0
> +#define INTEL_DEVICE_ID_VMD3	0x9a0b
> 
>  static struct vmd_type vmd_devs[] = {
>          { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD,  "Intel Volume
> Management Device" },
>          { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD2, "Intel Volume
> Management Device" },
> +        { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD3, "Intel Volume
> Management Device" },
>          { 0, 0, NULL }
>  };
> 
> @@ -425,6 +427,7 @@ vmd_attach(device_t dev)
>  	return (0);
> 
>  fail:
> +	rman_fini(&sc->vmd_bus.rman);
>  	vmd_free(sc);
>  	return (ENXIO);
>  }
> 
> This patch helps me detect the VMD controller, but I am unable to 
> attach to it.
> 
> Therefore, I am not able to attach any PCIe buses that will be used by
> a NVMe SSD.
> 
> If this patch worked, I would see these devices (as I do in Linux):
> 
> 10000:e0:1d.0 PCI bridge [0604]: Intel Corporation Tiger Lake-LP PCI
> Express Root Port #9 [8086:a0b0] (rev 20) SI
> 10000:e0:1d.2 PCI bridge [0604]: Intel Corporation Device [8086:a0b2] 
> (rev 20)
> 10000:e1:00.0 Non-Volatile memory controller [0108]: Intel Corporation
> Device [8086:0975] (rev 03)
> 10000:e2:00.0 Non-Volatile memory controller [0108]: Intel Corporation
> Device [8086:0975]
> 
> And therefore a `nvd*` device.
> 
> Could a developer please help me with this?
> 
> -Neel
> 
> ===
> 
> https://www.neelc.org/
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to 
> "freebsd-current-unsubscribe at freebsd.org"
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: acpidump.txt
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20201230/39c67288/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pcidump.txt
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20201230/39c67288/attachment-0001.txt>

From grahamperrin at gmail.com  Thu Dec 31 08:13:37 2020
From: grahamperrin at gmail.com (Graham Perrin)
Date: Thu, 31 Dec 2020 08:13:34 +0000
Subject: drwxr-xr-x by default for automatically created mount points
Message-ID: <df7b840e-9f17-1177-d699-93b20eb7377a@gmail.com>

In brief (for example):

grahamperrin at mowa219-gjp4-8570p:~ % ls -dhl /media/da1p1
drwxr-xr-x? 3 root? wheel?? 512B 30 Dec 13:29 /media/da1p1
grahamperrin at mowa219-gjp4-8570p:~ % touch /media/da1p1/touched
touch: /media/da1p1/touched: Permission denied

? is drwxr-xr-x as a default the norm?

In greater detail: <https://pastebin.com/DnRT8GAM>


From kostikbel at gmail.com  Thu Dec 31 11:40:18 2020
From: kostikbel at gmail.com (Konstantin Belousov)
Date: Thu, 31 Dec 2020 13:40:03 +0200
Subject: r367672 broke the NFS server
In-Reply-To: <YQXPR0101MB0968B36B267F4217C74CC9E9DDD60@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
References: <YQXPR0101MB0968DC349AFD081480768028DDD70@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
 <X+x4NSeWI+z5QkP3@kib.kiev.ua>
 <YQXPR0101MB09687E622BDBBE59C964FAC4DDD70@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
 <X+y4bK8/1akNNh4Z@kib.kiev.ua>
 <YQXPR0101MB0968B36B267F4217C74CC9E9DDD60@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
Message-ID: <X+24k2sOYQ5bPfOR@kib.kiev.ua>

On Thu, Dec 31, 2020 at 05:16:27AM +0000, Rick Macklem wrote:
> Rick Macklem wrote:
> >Kostik wrote:
> > >
> > >Idea of the change is to restart the syscall at top level.  So for NFS
> > >server the right approach is to not send a response and also to not
> > >free the request mbuf chain, but to restart processing.
> > Yes. I took a look and I think restarting the operation by rolling the
> > working position in the mbuf lists back and redoing the operation
> > is feasible and easier than fixing the individual operations.
> >
> > For NFSv4, you cannot redo the entire compound, since non-idempotent
> > operations like exclusive open may have already been completed.
> > However, rolling back to the beginning of the operation should be
> > doable.
> Turned out to be quite easy. I'll stick a patch up on phabricator
> tomorrow, after I do a little more testing.
> NFSv4.0 is still broken, because it screws up the seqid, but I can
> fix that separately.
> 
> I do see the code looping about 2-3 times before it gets a successful
> ufs_create(). Does that sound reasonable?
In the simple case, it could be described as is: ERELOOKUP is returned
if the parent directory cannot be locked sleep-less, and we have to drop
the lock for opened vnode to sleep on it. More elaborate (but still
not precise) description is that parent directory might also need to
be synced, in which case its parent might need to be locked, and so on
recursively.

Slightly reformulating, I expect that ERELOOKUPs come out in case several
threads create files in the same directory.

> Here's some debug printfs for the test run of 4 concurrent compiles.
> (proc=8 is create and proc=12 is remove. Each line is a ERELOOKUP
>  retry. This is for the 4 threads, but I had the thread tid in another printf
>  and it showed 2-3 attempts for the same thread. They should be serialized
>  by the exclusive lock on the directory vnode.)
I cannot make any conclusion from the output and its description.
Are there opens that do not result in ERELOOKUP, i.e. does the op
eventually succeed ?  What is the ratio of ERELOOKUP vs. success ?

Also note that any VOP that modify the volume' metadata might result
in ERELOOKUP.

> tryag3 stat=0 proc=8
> tryag3 stat=0 proc=8

From deischen at freebsd.org  Thu Dec 31 18:33:38 2020
From: deischen at freebsd.org (Daniel Eischen)
Date: Thu, 31 Dec 2020 13:33:25 -0500 (EST)
Subject: poudriere: services_mkdb recompile with larger PROTOMAX
Message-ID: <Pine.GSO.4.64.2012311333100.10270@sea.ntplx.net>

I see this message in src/UPDATING:

20201216:
   The services database has been updated to cover more of the basic
   services expected in a modern system. The database is big enough
   that it will cause issues in mergemaster in Releases previous to
   12.2 and 11.3, or in very old current systems from before r358154.

I'm trying to update a poudriere jail from a freshly built -current
system (r368820):

    FreeBSD vega.my.domain 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r368820
    Wed Dec 30 15:55:06 EST 2020

I've tried running this command twice:

    export MAKEOBJDIRPREFIX=/opt/FreeBSD/obj/head.obj
    poudriere jail -u -j 13amd64

[ /opt/FreeBSD/obj/head.obj is my freshly built (r368820) obj tree is ]

services_mkdb was updated in the jail on the first pass:

    # ls -l /usr/local/poudriere/jails/13amd64/usr/sbin/services_mkdb
    -r-xr-xr-x  1 root  wheel  15288 Dec 31 13:02  /usr/local/poudriere/jails/13amd64/usr/sbin/services_mkdb

But as on the first pass of 'poudriere jail -u -j 13amd64`, I still get
the following error:

...

--- _CONFSINS_services ---
install -N /opt/FreeBSD/svn/head/etc  -C -o root  -g wheel -m 644  /opt/FreeBSD/svn/head/usr.sbin/services_mkdb/services /usr/local/poudriere/jails/13amd64/etc/services
--- installconfig_subdir_usr.bin ---
--- installconfig_subdir_usr.bin/nice ---
===> usr.bin/nice (installconfig)
--- installconfig_subdir_usr.sbin ---
--- afterinstallconfig ---
--- installconfig_subdir_lib ---
--- installconfig_subdir_lib/ncurses ---
--- installconfig_subdir_lib/ncurses/ncurses ---
===> lib/ncurses/ncurses (installconfig)
--- installconfig_subdir_usr.sbin ---
services_mkdb -l -q -o /usr/local/poudriere/jails/13amd64/var/db/services.db  /usr/local/poudriere/jails/13amd64/etc/services
--- installconfig_subdir_usr.bin ---
--- installconfig_subdir_usr.bin/nl ---
===> usr.bin/nl (installconfig)
--- installconfig_subdir_usr.sbin ---
services_mkdb: Ran out of protocols adding `divert'; recompile with larger PROTOMAX

What's the work-around for this?  services_mkdb seems to have been
updated on the first pass off 'poudiere jail -u ...', but still fails
on the second pass.

-- 
DE

From jmg at funkthat.com  Thu Dec 31 19:39:17 2020
From: jmg at funkthat.com (John-Mark Gurney)
Date: Thu, 31 Dec 2020 11:39:08 -0800
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <CAD2Ti2-4xS5n0+1oLOHyFh4+OCnwtNAAwMkkWzwRVDnt-xmb1Q@mail.gmail.com>
References: <CANCZdfpb0MF+uoW=K3cQpL+3vNQjSBDeVMab5d4JJhUO4sy-2Q@mail.gmail.com>
 <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com>
 <20201218175241.GA72552@spindle.one-eyed-alien.net>
 <20201218182820.1P0tK%steffen@sdaoden.eu>
 <20201223023242.GG31099@funkthat.com>
 <20201223162417.v7Ce6%steffen@sdaoden.eu>
 <20201229011939.GU31099@funkthat.com>
 <20201229210454.Lh4y_%steffen@sdaoden.eu>
 <20201230004620.GB31099@funkthat.com>
 <CAD2Ti2-4xS5n0+1oLOHyFh4+OCnwtNAAwMkkWzwRVDnt-xmb1Q@mail.gmail.com>
Message-ID: <20201231193908.GC31099@funkthat.com>

grarpamp wrote this message on Wed, Dec 30, 2020 at 00:55 -0500:
> > signatures of the magnet links
> 
> Signing torrent.asc, with stronger or even same hash as BT
> protocol, still serve purpose of authenticate torrent file back
> to a signer to the degree therein, caveat their platform security,
> caveat sha-1 inside torrent still being abuseable by third party,
> caveat etc. With no torrent.asc there is nothing directly saying
> the torrent file / infohash itself went through freebsd project.
> Whether torrent or git or else, there can be useable scope
> and case for such "stronger over weaker" constructions.

There is already HTTPS to protect the "authenticity" of the magnet
link.  Yes, someone could vandalize the wiki page but I'm now
subscribed and will notice it...

Also, magnet links are not officially supported the project..  I
provide them because I think it's useful, and there are some people
who request them...

One of the large parts of security is that not everyone knows the
in's and out's of security, so people who don't know, will have heard
that SHA-1 is a cryptographic hash, and assume that something is secure
when using it.  It's difficult to educate people on these points..

> gpg offers better hash algos than sha-1 these days,
> all users should look into configuring and using it,
> same goes for abandoning the old [a]symmetric algos
> and weaker keys, made with old weak /dev/random, etc.
> 
> One cannot sign or verify anything without knowing gpg first :)

snapaid was designed to make it even easier...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

From allanjude at freebsd.org  Thu Dec 31 19:51:13 2020
From: allanjude at freebsd.org (Allan Jude)
Date: Thu, 31 Dec 2020 14:51:06 -0500
Subject: Enabling AESNI by default
Message-ID: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org>

We've had the AESNI module for quite a few years now, and it has not
caused any problems.

I am wondering if there are any objections to including it in GENERIC,
so that users get the benefit without having to have the "tribal
knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc),
you need to load aesni.ko'

Userspace crypto that uses openssl or similar libraries is already
taking advantage of these CPU instructions if they are available, by
excluding this feature from GENERIC we are just causing the "out of the
box" experience to by very very slow for crypto.

For example, writing 1MB blocks to a GELI encrypted swap-backed md(4)
device:

with 8 jobs on a 10 core Intel Xeon CPU E5-2630 v4 @ 2.20GHz

fio --filename=/dev/md0.eli --device=1 --name=geli --rw=write --bs=1m
--numjobs=8 --iodepth=16 --end_fsync=1 --ioengine=pvsync
--group_reporting --fallocate=none --runtime=60 --time_based


stock:
write: IOPS=530, BW=530MiB/s (556MB/s) (31.1GiB/60012msec)

with aesni.ko loaded:
write: IOPS=2824, BW=2825MiB/s (2962MB/s) (166GiB/60002msec)


Does anyone have a compelling reason to deny our users the 5x speedup?


-- 
Allan Jude

From shawn.webb at hardenedbsd.org  Thu Dec 31 20:07:06 2020
From: shawn.webb at hardenedbsd.org (Shawn Webb)
Date: Thu, 31 Dec 2020 15:07:02 -0500
Subject: Enabling AESNI by default
In-Reply-To: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org>
References: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org>
Message-ID: <20201231200702.22gvepvlzfwncalz@mutt-hbsd>

On Thu, Dec 31, 2020 at 02:51:06PM -0500, Allan Jude wrote:
> We've had the AESNI module for quite a few years now, and it has not
> caused any problems.
> 
> I am wondering if there are any objections to including it in GENERIC,
> so that users get the benefit without having to have the "tribal
> knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc),
> you need to load aesni.ko'
> 
> Userspace crypto that uses openssl or similar libraries is already
> taking advantage of these CPU instructions if they are available, by
> excluding this feature from GENERIC we are just causing the "out of the
> box" experience to by very very slow for crypto.
> 
> For example, writing 1MB blocks to a GELI encrypted swap-backed md(4)
> device:
> 
> with 8 jobs on a 10 core Intel Xeon CPU E5-2630 v4 @ 2.20GHz
> 
> fio --filename=/dev/md0.eli --device=1 --name=geli --rw=write --bs=1m
> --numjobs=8 --iodepth=16 --end_fsync=1 --ioengine=pvsync
> --group_reporting --fallocate=none --runtime=60 --time_based
> 
> 
> stock:
> write: IOPS=530, BW=530MiB/s (556MB/s) (31.1GiB/60012msec)
> 
> with aesni.ko loaded:
> write: IOPS=2824, BW=2825MiB/s (2962MB/s) (166GiB/60002msec)
> 
> 
> Does anyone have a compelling reason to deny our users the 5x speedup?

Note: HardenedBSD has had AESNI enabled on amd64 for nearly six years.
Not a single complaint.

For reference, HardenedBSD commit:
a5aabd1c8dcc2a5097de56c54ec2a1c8d9352896

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

GPG Key ID:          0xFF2E67A277F8E1FA
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23 0FB2
https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20201231/d50a0afe/attachment.sig>

From franco at lastsummer.de  Thu Dec 31 20:15:15 2020
From: franco at lastsummer.de (Franco Fichtner)
Date: Thu, 31 Dec 2020 21:15:02 +0100
Subject: Enabling AESNI by default
In-Reply-To: <20201231200702.22gvepvlzfwncalz@mutt-hbsd>
References: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org>
 <20201231200702.22gvepvlzfwncalz@mutt-hbsd>
Message-ID: <7DF6338B-9DDF-4F3C-B217-DADD72D16898@lastsummer.de>

https://cgit.freebsd.org/src/commit/sys/crypto/aesni?h=stable/12&id=95b37a4ed741fd116809d0f2cb295c4e9977f5b6

may have subtly broken a number of IPsec installations by stalling active
connections after certain amounts of traffic transferred.  We're still
trying to confirm, but it looks like this had an overall impact on 12.0
and 12.1 except that only one person in OPNsense traced it back to aesni.ko
to our knowledge to effective work around an apparent issue there.

If that is not the actual fix, the problem still exists in 12.2 and onward ;)

https://github.com/opnsense/core/issues/4415

To answer the question: I guess so, yes, enable for all to have proper errata
and increased "test" coverage...


Cheers,
Franco

> On 31. Dec 2020, at 9:07 PM, Shawn Webb <shawn.webb at hardenedbsd.org> wrote:
> 
> On Thu, Dec 31, 2020 at 02:51:06PM -0500, Allan Jude wrote:
>> We've had the AESNI module for quite a few years now, and it has not
>> caused any problems.
>> 
>> I am wondering if there are any objections to including it in GENERIC,
>> so that users get the benefit without having to have the "tribal
>> knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc),
>> you need to load aesni.ko'
>> 
>> Userspace crypto that uses openssl or similar libraries is already
>> taking advantage of these CPU instructions if they are available, by
>> excluding this feature from GENERIC we are just causing the "out of the
>> box" experience to by very very slow for crypto.
>> 
>> For example, writing 1MB blocks to a GELI encrypted swap-backed md(4)
>> device:
>> 
>> with 8 jobs on a 10 core Intel Xeon CPU E5-2630 v4 @ 2.20GHz
>> 
>> fio --filename=/dev/md0.eli --device=1 --name=geli --rw=write --bs=1m
>> --numjobs=8 --iodepth=16 --end_fsync=1 --ioengine=pvsync
>> --group_reporting --fallocate=none --runtime=60 --time_based
>> 
>> 
>> stock:
>> write: IOPS=530, BW=530MiB/s (556MB/s) (31.1GiB/60012msec)
>> 
>> with aesni.ko loaded:
>> write: IOPS=2824, BW=2825MiB/s (2962MB/s) (166GiB/60002msec)
>> 
>> 
>> Does anyone have a compelling reason to deny our users the 5x speedup?
> 
> Note: HardenedBSD has had AESNI enabled on amd64 for nearly six years.
> Not a single complaint.
> 
> For reference, HardenedBSD commit:
> a5aabd1c8dcc2a5097de56c54ec2a1c8d9352896
> 
> Thanks,
> 
> -- 
> Shawn Webb
> Cofounder / Security Engineer
> HardenedBSD
> 
> GPG Key ID:          0xFF2E67A277F8E1FA
> GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9  3633 C85B 0AF8 AB23 0FB2
> https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc


From ronald-lists at klop.ws  Thu Dec 31 20:35:56 2020
From: ronald-lists at klop.ws (Ronald Klop)
Date: Thu, 31 Dec 2020 21:35:53 +0100 (CET)
Subject: Enabling AESNI by default
In-Reply-To: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org>
Message-ID: <750559933.8900.1609446953164@localhost>

 Yes! Took me until last month to notice that I needed to load aesni in loader.conf instead of rc.conf because swap geli is configured before kld_list.
Years of optimization thrown away.


Regards, 
Ronald.


Van: Allan Jude <allanjude at freebsd.org>
Datum: 31 december 2020 20:51
Aan: FreeBSD Current <freebsd-current at freebsd.org>
Onderwerp: Enabling AESNI by default

> 
> 
> We've had the AESNI module for quite a few years now, and it has not
> caused any problems.
> 
> I am wondering if there are any objections to including it in GENERIC,
> so that users get the benefit without having to have the "tribal
> knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc),
> you need to load aesni.ko'
> 
> Userspace crypto that uses openssl or similar libraries is already
> taking advantage of these CPU instructions if they are available, by
> excluding this feature from GENERIC we are just causing the "out of the
> box" experience to by very very slow for crypto.
> 
> For example, writing 1MB blocks to a GELI encrypted swap-backed md(4)
> device:
> 
> with 8 jobs on a 10 core Intel Xeon CPU E5-2630 v4 @ 2.20GHz
> 
> fio --filename=/dev/md0.eli --device=1 --name=geli --rw=write --bs=1m
> --numjobs=8 --iodepth=16 --end_fsync=1 --ioengine=pvsync
> --group_reporting --fallocate=none --runtime=60 --time_based
> 
> 
> stock:
> write: IOPS=530, BW=530MiB/s (556MB/s) (31.1GiB/60012msec)
> 
> with aesni.ko loaded:
> write: IOPS=2824, BW=2825MiB/s (2962MB/s) (166GiB/60002msec)
> 
> 
> Does anyone have a compelling reason to deny our users the 5x speedup?
> 
> 
> -- 
> Allan Jude
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
> 
> 
> 
> 

From bsd-lists at bsdforge.com  Thu Dec 31 21:58:26 2020
From: bsd-lists at bsdforge.com (Chris)
Date: Thu, 31 Dec 2020 13:59:02 -0800
Subject: Enabling AESNI by default
In-Reply-To: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org>
References: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org>
Message-ID: <048a95427c6a9c30fad8f2dd882dc70f@bsdforge.com>

On 2020-12-31 11:51, Allan Jude wrote:
> We've had the AESNI module for quite a few years now, and it has not
> caused any problems.
> 
> I am wondering if there are any objections to including it in GENERIC,
> so that users get the benefit without having to have the "tribal
> knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc),
> you need to load aesni.ko'
> 
> Userspace crypto that uses openssl or similar libraries is already
> taking advantage of these CPU instructions if they are available, by
> excluding this feature from GENERIC we are just causing the "out of the
> box" experience to by very very slow for crypto.
> 
> For example, writing 1MB blocks to a GELI encrypted swap-backed md(4)
> device:
> 
> with 8 jobs on a 10 core Intel Xeon CPU E5-2630 v4 @ 2.20GHz
> 
> fio --filename=/dev/md0.eli --device=1 --name=geli --rw=write --bs=1m
> --numjobs=8 --iodepth=16 --end_fsync=1 --ioengine=pvsync
> --group_reporting --fallocate=none --runtime=60 --time_based
> 
> 
> stock:
> write: IOPS=530, BW=530MiB/s (556MB/s) (31.1GiB/60012msec)
> 
> with aesni.ko loaded:
> write: IOPS=2824, BW=2825MiB/s (2962MB/s) (166GiB/60002msec)
> 
> 
> Does anyone have a compelling reason to deny our users the 5x speedup?
FWIW I'd just like to suggest that I'm a +1 for adding it to GENERIC.
Thanks for suggesting this, and have a Happy New Year!

--Chris

From freebsd-rwg at gndrsh.dnsmgr.net  Thu Dec 31 22:09:21 2020
From: freebsd-rwg at gndrsh.dnsmgr.net (Rodney W. Grimes)
Date: Thu, 31 Dec 2020 14:09:17 -0800 (PST)
Subject: Enabling AESNI by default
In-Reply-To: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org>
Message-ID: <202012312209.0BVM9HHk088051@gndrsh.dnsmgr.net>

> We've had the AESNI module for quite a few years now, and it has not
> caused any problems.
> 
> I am wondering if there are any objections to including it in GENERIC,
> so that users get the benefit without having to have the "tribal
> knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc),
> you need to load aesni.ko'
> 
> Userspace crypto that uses openssl or similar libraries is already
> taking advantage of these CPU instructions if they are available, by
> excluding this feature from GENERIC we are just causing the "out of the
> box" experience to by very very slow for crypto.
> 
> For example, writing 1MB blocks to a GELI encrypted swap-backed md(4)
> device:
> 
> with 8 jobs on a 10 core Intel Xeon CPU E5-2630 v4 @ 2.20GHz
> 
> fio --filename=/dev/md0.eli --device=1 --name=geli --rw=write --bs=1m
> --numjobs=8 --iodepth=16 --end_fsync=1 --ioengine=pvsync
> --group_reporting --fallocate=none --runtime=60 --time_based
> 
> 
> stock:
> write: IOPS=530, BW=530MiB/s (556MB/s) (31.1GiB/60012msec)
> 
> with aesni.ko loaded:
> write: IOPS=2824, BW=2825MiB/s (2962MB/s) (166GiB/60002msec)
> 
> 
> Does anyone have a compelling reason to deny our users the 5x speedup?

Its for ever dead code on a large number of machines that do not have
the hardware for it.  I know that is a decreasing set, but imho it
would be better to somehow ONLY load the module if you had CPU
support for it.  The down side is that detection would probably have
to be in the laoder as this code can be used very early on.

-- 
Rod Grimes                                                 rgrimes at freebsd.org

From rwmaillists at googlemail.com  Thu Dec 31 22:15:38 2020
From: rwmaillists at googlemail.com (RW)
Date: Thu, 31 Dec 2020 22:15:30 +0000
Subject: HEADS UP: FreeBSD src repo transitioning to git this weekend
In-Reply-To: <20201231193908.GC31099@funkthat.com>
References: <CANCZdfpb0MF+uoW=K3cQpL+3vNQjSBDeVMab5d4JJhUO4sy-2Q@mail.gmail.com>
 <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com>
 <20201218175241.GA72552@spindle.one-eyed-alien.net>
 <20201218182820.1P0tK%steffen@sdaoden.eu>
 <20201223023242.GG31099@funkthat.com>
 <20201223162417.v7Ce6%steffen@sdaoden.eu>
 <20201229011939.GU31099@funkthat.com>
 <20201229210454.Lh4y_%steffen@sdaoden.eu>
 <20201230004620.GB31099@funkthat.com>
 <CAD2Ti2-4xS5n0+1oLOHyFh4+OCnwtNAAwMkkWzwRVDnt-xmb1Q@mail.gmail.com>
 <20201231193908.GC31099@funkthat.com>
Message-ID: <20201231221530.4f709bb6@gumby.homeunix.com>

On Thu, 31 Dec 2020 11:39:08 -0800
John-Mark Gurney wrote:

> grarpamp wrote this message on Wed, Dec 30, 2020 at 00:55 -0500:
> > > signatures of the magnet links  
> > 
> > Signing torrent.asc, with stronger or even same hash as BT
> > protocol, still serve purpose of authenticate torrent file back
> > to a signer to the degree therein, caveat their platform security,
> > caveat sha-1 inside torrent still being abuseable by third party,
> > caveat etc
> One of the large parts of security is that not everyone knows the
> in's and out's of security, so people who don't know, will have heard
> that SHA-1 is a cryptographic hash, and assume that something is
> secure when using it.  

Is there any reason to think it's insecure?  Even if a collision attack
can be make to work against bittorrent, the attacker would need to have
control over the contents of the legitimate torrent as well as the
bogus one.

It wouldn't be "abuseable by third party".

From kp at FreeBSD.org  Thu Dec 31 22:20:12 2020
From: kp at FreeBSD.org (Kristof Provost)
Date: Thu, 31 Dec 2020 23:20:10 +0100
Subject: Enabling AESNI by default
In-Reply-To: <202012312209.0BVM9HHk088051@gndrsh.dnsmgr.net>
References: <202012312209.0BVM9HHk088051@gndrsh.dnsmgr.net>
Message-ID: <0D67F84B-248D-4680-8D91-2CAEDCDD7ED7@FreeBSD.org>

On 31 Dec 2020, at 23:09, Rodney W. Grimes wrote:
> Its for ever dead code on a large number of machines that do not have
> the hardware for it.  I know that is a decreasing set, but imho it
> would be better to somehow ONLY load the module if you had CPU
> support for it.  The down side is that detection would probably have
> to be in the laoder as this code can be used very early on.
>
According to kldstat it uses all of 42KB of memory.

     16    1 0xffffffff83313000     a290 aesni.ko

That?s such a trivial amount of memory it?s not even worth 
mentioning. Even in tiny embedded systems (and who runs tiny embedded 
systems on x86?) it?s utterly insignificant.

Even if it were significant, how many of the systems without the 
relevant hardware are ever going to run 13?

Regards,
Kristof

From asomers at freebsd.org  Thu Dec 31 22:24:22 2020
From: asomers at freebsd.org (Alan Somers)
Date: Thu, 31 Dec 2020 15:24:09 -0700
Subject: Enabling AESNI by default
In-Reply-To: <0D67F84B-248D-4680-8D91-2CAEDCDD7ED7@FreeBSD.org>
References: <202012312209.0BVM9HHk088051@gndrsh.dnsmgr.net>
 <0D67F84B-248D-4680-8D91-2CAEDCDD7ED7@FreeBSD.org>
Message-ID: <CAOtMX2jQPXSq+VXh_-Xs+qTZTW=qNg3+-At-NH9q1QaDR0jGfg@mail.gmail.com>

On Thu, Dec 31, 2020 at 3:20 PM Kristof Provost <kp at freebsd.org> wrote:

> On 31 Dec 2020, at 23:09, Rodney W. Grimes wrote:
> > Its for ever dead code on a large number of machines that do not have
> > the hardware for it.  I know that is a decreasing set, but imho it
> > would be better to somehow ONLY load the module if you had CPU
> > support for it.  The down side is that detection would probably have
> > to be in the laoder as this code can be used very early on.
> >
> According to kldstat it uses all of 42KB of memory.
>
>      16    1 0xffffffff83313000     a290 aesni.ko
>
> That?s such a trivial amount of memory it?s not even worth
> mentioning. Even in tiny embedded systems (and who runs tiny embedded
> systems on x86?) it?s utterly insignificant.
>
> Even if it were significant, how many of the systems without the
> relevant hardware are ever going to run 13?
>
> Regards,
> Kristof
>

And tiny embedded systems are probably running custom kernels anyway, so
they can remove it.  I'm sold.  Let's put it in GENERIC.
-Alan

From jhb at FreeBSD.org  Thu Dec 31 22:28:09 2020
From: jhb at FreeBSD.org (John Baldwin)
Date: Thu, 31 Dec 2020 14:28:07 -0800
Subject: PCIe Root Port/Bus Not Detected in VMD
In-Reply-To: <ba5b92e33d83fe5c5a235537203a1c09@neelc.org>
References: <aa9632b47ad2173154fb5f11456f531d@neelc.org>
 <ba5b92e33d83fe5c5a235537203a1c09@neelc.org>
Message-ID: <40b48007-5e60-cd87-0242-15239869d370@FreeBSD.org>

On 12/30/20 9:45 PM, Neel Chauhan wrote:
> For reference, I am attaching the `pciconf -lv` and `acpidump -dt` 
> dumps.

Hmm, the acpidump doesn't have the -d contents, only the -t, and
PCI bridges are generally enumerated in the the -d part.  These
PCI bridges aren't enumerated in ACPI though, so that probably
doesn't matter.

The dinfo getting 0xffff means that somehow the way the PCI config
access is being handled for the child devices in vmd.c is wrong for
this bridge.  You might have to spelunk in the Linux driver to see
if the logic in vmd_read_config() and vmd_write_config() is
correct.

-- 
-- 
John Baldwin

From ctuffli at gmail.com  Thu Dec 31 22:40:29 2020
From: ctuffli at gmail.com (Chuck Tuffli)
Date: Thu, 31 Dec 2020 14:40:17 -0800
Subject: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch
In-Reply-To: <f3a548aa4f435f25983f9d6b2a010af0@neelc.org>
References: <eeab20a1316335317d3ff8cbf68c1cf1@neelc.org>
 <CAKAYmMLn8rO-dJd+VYPguM9KmcXbkBiPnBu3bygRHBNpNn+S5w@mail.gmail.com>
 <f3a548aa4f435f25983f9d6b2a010af0@neelc.org>
Message-ID: <CAKAYmM+ZxLAAKHDd4kg9nmDnfHjCJvoTL_aKm_HVwAw1-7xnZA@mail.gmail.com>

On Wed, Dec 30, 2020 at 4:38 PM Neel Chauhan <neel at neelc.org> wrote:
>
> Hi Chuck,
>
> On 2020-12-30 10:04, Chuck Tuffli wrote:
> > What is the output from
> > # pciconf -rb pci0:0:14:0 0x40:0x48
>
> The output is:
>
> 01 00 00 00 01 2e 68 02  00

Perfect. The Linux driver says the 8086:9a0b device you have "... may
provide root port configuration information which limits bus
numbering" which causes the code to read the VM Capability register
(0x40) and the VM Configuration register (0x44). Here, VMCAP = 0x0001
where bit 0 set appears to mean the config register has starting bus
number information. VMCFG = 0x2e01 where bits 5:4 give the coded start
number of bus 224 or 0xe0 which matches the PCI bridge shown in the
lspci output (i.e. 10000:e0:06.0).

I wonder if mirroring the logic in [1] and setting
    bus->rman.rm_start = 224;
in vmd_attach() might help.

> I was also able to stop kernel panics by adding:
>
> rman_fini(&sc->vmd_bus.rman);
>
> In the fail: statement in vmd_attach().
>
> But I still cannot detect the SSD.

[1] https://github.com/torvalds/linux/blob/master/drivers/pci/controller/vmd.c#L507

--chuck

From ian at freebsd.org  Thu Dec 31 22:46:19 2020
From: ian at freebsd.org (Ian Lepore)
Date: Thu, 31 Dec 2020 15:46:14 -0700
Subject: Enabling AESNI by default
In-Reply-To: <202012312209.0BVM9HHk088051@gndrsh.dnsmgr.net>
References: <202012312209.0BVM9HHk088051@gndrsh.dnsmgr.net>
Message-ID: <93dd4cadbcfbe8883a72144772d713a24124c584.camel@freebsd.org>

On Thu, 2020-12-31 at 14:09 -0800, Rodney W. Grimes wrote:
> > We've had the AESNI module for quite a few years now, and it has
> > not
> > caused any problems.
> > 
> > I am wondering if there are any objections to including it in
> > GENERIC,
> > so that users get the benefit without having to have the "tribal
> > knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC,
> > etc),
> > you need to load aesni.ko'
> > 
> > Userspace crypto that uses openssl or similar libraries is already
> > taking advantage of these CPU instructions if they are available,
> > by
> > excluding this feature from GENERIC we are just causing the "out of
> > the
> > box" experience to by very very slow for crypto.
> > 
> > For example, writing 1MB blocks to a GELI encrypted swap-backed
> > md(4)
> > device:
> > 
> > with 8 jobs on a 10 core Intel Xeon CPU E5-2630 v4 @ 2.20GHz
> > 
> > fio --filename=/dev/md0.eli --device=1 --name=geli --rw=write --
> > bs=1m
> > --numjobs=8 --iodepth=16 --end_fsync=1 --ioengine=pvsync
> > --group_reporting --fallocate=none --runtime=60 --time_based
> > 
> > 
> > stock:
> > write: IOPS=530, BW=530MiB/s (556MB/s) (31.1GiB/60012msec)
> > 
> > with aesni.ko loaded:
> > write: IOPS=2824, BW=2825MiB/s (2962MB/s) (166GiB/60002msec)
> > 
> > 
> > Does anyone have a compelling reason to deny our users the 5x
> > speedup?
> 
> Its for ever dead code on a large number of machines that do not have
> the hardware for it.  I know that is a decreasing set, but imho it
> would be better to somehow ONLY load the module if you had CPU
> support for it.  The down side is that detection would probably have
> to be in the laoder as this code can be used very early on.
> 

Not nearly so much as the code to support the PC/AT RTC and i8254
hardware as kernel eventtimers is dead code, probably today on
virtually every x86 machine that runs freebsd.

In other words, if you want to start worrying about mostly-unused code,
aesni is not the place to start.

-- Ian



From deischen at freebsd.org  Thu Dec 31 22:47:22 2020
From: deischen at freebsd.org (Daniel Eischen)
Date: Thu, 31 Dec 2020 17:47:16 -0500 (EST)
Subject: Bug in r361898 (was Re: poudriere: services_mkdb recompile with
 larger PROTOMAX)
In-Reply-To: <Pine.GSO.4.64.2012311333100.10270@sea.ntplx.net>
References: <Pine.GSO.4.64.2012311333100.10270@sea.ntplx.net>
Message-ID: <Pine.GSO.4.64.2012311743060.11233@sea.ntplx.net>

On Thu, 31 Dec 2020, Daniel Eischen wrote:

> I see this message in src/UPDATING:
>
> 20201216:
>  The services database has been updated to cover more of the basic
>  services expected in a modern system. The database is big enough
>  that it will cause issues in mergemaster in Releases previous to
>  12.2 and 11.3, or in very old current systems from before r358154.
>
> I'm trying to update a poudriere jail from a freshly built -current
> system (r368820):
>
>   FreeBSD vega.my.domain 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r368820
>   Wed Dec 30 15:55:06 EST 2020
>
> I've tried running this command twice:
>
>   export MAKEOBJDIRPREFIX=/opt/FreeBSD/obj/head.obj
>   poudriere jail -u -j 13amd64
>
> [ /opt/FreeBSD/obj/head.obj is my freshly built (r368820) obj tree is ]
>
> services_mkdb was updated in the jail on the first pass:
>
>   # ls -l /usr/local/poudriere/jails/13amd64/usr/sbin/services_mkdb
>   -r-xr-xr-x  1 root  wheel  15288 Dec 31 13:02 
> /usr/local/poudriere/jails/13amd64/usr/sbin/services_mkdb
>
> But as on the first pass of 'poudriere jail -u -j 13amd64`, I still get
> the following error:
>
> ...
>
> --- _CONFSINS_services ---
> install -N /opt/FreeBSD/svn/head/etc  -C -o root  -g wheel -m 644 
> /opt/FreeBSD/svn/head/usr.sbin/services_mkdb/services 
> /usr/local/poudriere/jails/13amd64/etc/services
> --- installconfig_subdir_usr.bin ---
> --- installconfig_subdir_usr.bin/nice ---
> ===> usr.bin/nice (installconfig)
> --- installconfig_subdir_usr.sbin ---
> --- afterinstallconfig ---
> --- installconfig_subdir_lib ---
> --- installconfig_subdir_lib/ncurses ---
> --- installconfig_subdir_lib/ncurses/ncurses ---
> ===> lib/ncurses/ncurses (installconfig)
> --- installconfig_subdir_usr.sbin ---
> services_mkdb -l -q -o /usr/local/poudriere/jails/13amd64/var/db/services.db 
> /usr/local/poudriere/jails/13amd64/etc/services
> --- installconfig_subdir_usr.bin ---
> --- installconfig_subdir_usr.bin/nl ---
> ===> usr.bin/nl (installconfig)
> --- installconfig_subdir_usr.sbin ---
> services_mkdb: Ran out of protocols adding `divert'; recompile with larger 
> PROTOMAX
>
> What's the work-around for this?  services_mkdb seems to have been
> updated on the first pass off 'poudiere jail -u ...', but still fails
> on the second pass.

A typo (tdp was used instead of tcp) in the services file seems to
have been introduced in r361898.  This is the patch that fixes the
problem for me.

Index: usr.sbin/services_mkdb/services
===================================================================
--- usr.sbin/services_mkdb/services (revision 368820)
+++ usr.sbin/services_mkdb/services (working copy)
@@ -1788,7 +1788,7 @@
  iscsi-target 3260/udp   # iSCSI port
  mysql  3306/tcp   #MySQL
  mysql  3306/udp   #MySQL
-ms-wbt-server 3389/tdp   rdp #MS WBT Server
+ms-wbt-server 3389/tcp   rdp #MS WBT Server
  ms-wbt-server 3389/udp   #MS WBT Server
  efi-lm  3392/tcp   #EFI License Management
  efi-lm  3392/udp   #EFI License Management

-- 
DE

From jhb at FreeBSD.org  Thu Dec 31 22:51:50 2020
From: jhb at FreeBSD.org (John Baldwin)
Date: Thu, 31 Dec 2020 14:51:48 -0800
Subject: Enabling AESNI by default
In-Reply-To: <7DF6338B-9DDF-4F3C-B217-DADD72D16898@lastsummer.de>
References: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org>
 <20201231200702.22gvepvlzfwncalz@mutt-hbsd>
 <7DF6338B-9DDF-4F3C-B217-DADD72D16898@lastsummer.de>
Message-ID: <919661a7-cfd6-c106-244f-16853e34b059@FreeBSD.org>

On 12/31/20 12:15 PM, Franco Fichtner wrote:
> https://cgit.freebsd.org/src/commit/sys/crypto/aesni?h=stable/12&id=95b37a4ed741fd116809d0f2cb295c4e9977f5b6
> 
> may have subtly broken a number of IPsec installations by stalling active
> connections after certain amounts of traffic transferred.  We're still
> trying to confirm, but it looks like this had an overall impact on 12.0
> and 12.1 except that only one person in OPNsense traced it back to aesni.ko
> to our knowledge to effective work around an apparent issue there.
> 
> If that is not the actual fix, the problem still exists in 12.2 and onward ;)

We don't support AES-CCM for IPsec, so there is 0 chance that commit has any
effect on IPsec in 12.  There's not much detail in the forum posts though
(e.g. netstat -s output to get ipsec, esp, and ah stats).  Also, at least
one forum post mentioned it happened when doing an upgrade from 11.2 to 12.1
which is a larger set of changes.  I know the pfsense folks had a major
performance regression due to iflib with Intel e1000 devices that might
manifest as this perhaps?  Disabling aseni might just be throttling the
connection slow enough to avoid hitting a bug in a NIC driver for example.
I think netstat -s would be a better place to start to try to debug this.

> https://github.com/opnsense/core/issues/4415

-- 
John Baldwin

From jhb at FreeBSD.org  Thu Dec 31 22:54:57 2020
From: jhb at FreeBSD.org (John Baldwin)
Date: Thu, 31 Dec 2020 14:54:55 -0800
Subject: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch
In-Reply-To: <CAKAYmM+ZxLAAKHDd4kg9nmDnfHjCJvoTL_aKm_HVwAw1-7xnZA@mail.gmail.com>
References: <eeab20a1316335317d3ff8cbf68c1cf1@neelc.org>
 <CAKAYmMLn8rO-dJd+VYPguM9KmcXbkBiPnBu3bygRHBNpNn+S5w@mail.gmail.com>
 <f3a548aa4f435f25983f9d6b2a010af0@neelc.org>
 <CAKAYmM+ZxLAAKHDd4kg9nmDnfHjCJvoTL_aKm_HVwAw1-7xnZA@mail.gmail.com>
Message-ID: <d9fba1e0-4383-f4aa-b580-309e4f408162@FreeBSD.org>

On 12/31/20 2:40 PM, Chuck Tuffli wrote:
> On Wed, Dec 30, 2020 at 4:38 PM Neel Chauhan <neel at neelc.org> wrote:
>>
>> Hi Chuck,
>>
>> On 2020-12-30 10:04, Chuck Tuffli wrote:
>>> What is the output from
>>> # pciconf -rb pci0:0:14:0 0x40:0x48
>>
>> The output is:
>>
>> 01 00 00 00 01 2e 68 02  00
> 
> Perfect. The Linux driver says the 8086:9a0b device you have "... may
> provide root port configuration information which limits bus
> numbering" which causes the code to read the VM Capability register
> (0x40) and the VM Configuration register (0x44). Here, VMCAP = 0x0001
> where bit 0 set appears to mean the config register has starting bus
> number information. VMCFG = 0x2e01 where bits 5:4 give the coded start
> number of bus 224 or 0xe0 which matches the PCI bridge shown in the
> lspci output (i.e. 10000:e0:06.0).
> 
> I wonder if mirroring the logic in [1] and setting
>     bus->rman.rm_start = 224;
> in vmd_attach() might help.
> 
>> I was also able to stop kernel panics by adding:
>>
>> rman_fini(&sc->vmd_bus.rman);
>>
>> In the fail: statement in vmd_attach().
>>
>> But I still cannot detect the SSD.
> 
> [1] https://github.com/torvalds/linux/blob/master/drivers/pci/controller/vmd.c#L507

You will also need to subtract that starting bus number from the bus number used
to compute the offset into the PCI-express region for config register read/write
as this code does:

https://github.com/torvalds/linux/blob/master/drivers/pci/controller/vmd.c#L339

Also, that means the vm_bus.c can't hardcode reading from bus 0.  Instead,
vmd(4) might need to export an IVAR to vmd_bus(4) that is the starting bus
number and vm_bus needs to use that instead of hardcoding 0.

-- 
John Baldwin

From rmacklem at uoguelph.ca  Thu Dec 31 22:56:14 2020
From: rmacklem at uoguelph.ca (Rick Macklem)
Date: Thu, 31 Dec 2020 22:56:04 +0000
Subject: r367672 broke the NFS server
In-Reply-To: <X+24k2sOYQ5bPfOR@kib.kiev.ua>
References: <YQXPR0101MB0968DC349AFD081480768028DDD70@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
 <X+x4NSeWI+z5QkP3@kib.kiev.ua>
 <YQXPR0101MB09687E622BDBBE59C964FAC4DDD70@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
 <X+y4bK8/1akNNh4Z@kib.kiev.ua>
 <YQXPR0101MB0968B36B267F4217C74CC9E9DDD60@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>,
 <X+24k2sOYQ5bPfOR@kib.kiev.ua>
Message-ID: <YQXPR0101MB09684B812D683CFA9E960664DDD60@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>

Just fyi, I have  put a patch up on phabricator as D27875 that seems
to fix the problem for all NFS client mounts except NFSv4.0.
NFSv4.0 will require an additional fix so that the "seqid" is
properly maintained during redos of the Open caused by
the ERELOOKUP redo.

If anyone is running a recent head kernel on a system that
NFS exports UFS file systems, please test this patch.

Peter, can you test this?

If acquiring the patch from phabricator is awkward,
just email and I will send you a copy of the patch.

Thanks, rick
ps: If possible, I'd like to commit this patch in a
     couple of days, given the FreeBSD release schedule.

________________________________________
From: owner-freebsd-current at freebsd.org <owner-freebsd-current at freebsd.org> on behalf of Konstantin Belousov <kostikbel at gmail.com>
Sent: Thursday, December 31, 2020 6:40 AM
To: Rick Macklem
Cc: freebsd-current at freebsd.org; Alan Somers; Kirk McKusick; Mark Johnston
Subject: Re: r367672 broke the NFS server

CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to IThelp at uoguelph.ca


On Thu, Dec 31, 2020 at 05:16:27AM +0000, Rick Macklem wrote:
> Rick Macklem wrote:
> >Kostik wrote:
> > >
> > >Idea of the change is to restart the syscall at top level.  So for NFS
> > >server the right approach is to not send a response and also to not
> > >free the request mbuf chain, but to restart processing.
> > Yes. I took a look and I think restarting the operation by rolling the
> > working position in the mbuf lists back and redoing the operation
> > is feasible and easier than fixing the individual operations.
> >
> > For NFSv4, you cannot redo the entire compound, since non-idempotent
> > operations like exclusive open may have already been completed.
> > However, rolling back to the beginning of the operation should be
> > doable.
> Turned out to be quite easy. I'll stick a patch up on phabricator
> tomorrow, after I do a little more testing.
> NFSv4.0 is still broken, because it screws up the seqid, but I can
> fix that separately.
>
> I do see the code looping about 2-3 times before it gets a successful
> ufs_create(). Does that sound reasonable?
In the simple case, it could be described as is: ERELOOKUP is returned
if the parent directory cannot be locked sleep-less, and we have to drop
the lock for opened vnode to sleep on it. More elaborate (but still
not precise) description is that parent directory might also need to
be synced, in which case its parent might need to be locked, and so on
recursively.

Slightly reformulating, I expect that ERELOOKUPs come out in case several
threads create files in the same directory.

> Here's some debug printfs for the test run of 4 concurrent compiles.
> (proc=8 is create and proc=12 is remove. Each line is a ERELOOKUP
>  retry. This is for the 4 threads, but I had the thread tid in another printf
>  and it showed 2-3 attempts for the same thread. They should be serialized
>  by the exclusive lock on the directory vnode.)
I cannot make any conclusion from the output and its description.
Are there opens that do not result in ERELOOKUP, i.e. does the op
eventually succeed ?  What is the ratio of ERELOOKUP vs. success ?

Also note that any VOP that modify the volume' metadata might result
in ERELOOKUP.

> tryag3 stat=0 proc=8
> tryag3 stat=0 proc=8
_______________________________________________
freebsd-current at freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"


From jhb at FreeBSD.org  Thu Dec 31 22:59:15 2020
From: jhb at FreeBSD.org (John Baldwin)
Date: Thu, 31 Dec 2020 14:59:13 -0800
Subject: Enabling AESNI by default
In-Reply-To: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org>
References: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org>
Message-ID: <246743d3-ffd8-2101-7c07-2c2a9cc033ce@FreeBSD.org>

On 12/31/20 11:51 AM, Allan Jude wrote:
> We've had the AESNI module for quite a few years now, and it has not
> caused any problems.
> 
> I am wondering if there are any objections to including it in GENERIC,
> so that users get the benefit without having to have the "tribal
> knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc),
> you need to load aesni.ko'
> 
> Userspace crypto that uses openssl or similar libraries is already
> taking advantage of these CPU instructions if they are available, by
> excluding this feature from GENERIC we are just causing the "out of the
> box" experience to by very very slow for crypto.
> 
> For example, writing 1MB blocks to a GELI encrypted swap-backed md(4)
> device:
> 
> with 8 jobs on a 10 core Intel Xeon CPU E5-2630 v4 @ 2.20GHz
> 
> fio --filename=/dev/md0.eli --device=1 --name=geli --rw=write --bs=1m
> --numjobs=8 --iodepth=16 --end_fsync=1 --ioengine=pvsync
> --group_reporting --fallocate=none --runtime=60 --time_based
> 
> 
> stock:
> write: IOPS=530, BW=530MiB/s (556MB/s) (31.1GiB/60012msec)
> 
> with aesni.ko loaded:
> write: IOPS=2824, BW=2825MiB/s (2962MB/s) (166GiB/60002msec)
> 
> 
> Does anyone have a compelling reason to deny our users the 5x speedup?

I think this is fine.  I do hope to add AES support to ossl(4) at
some point, and it may be that ossl(4) will supplant aesni(4) (and
armv8crypto(4)) at that point, but aesni in GENERIC makes sense
right now (and I'd say to MFC it to 12).  armv8crypto in arm64
GENERIC will make sense once AES-XTS support (currently in a review)
lands.

-- 
John Baldwin