Re: WITHOUT_PF breaks buildworld

[Konrad Sewiłło-Jopek]

Hi,

I think the reason is somewhere in tools/build/test-includes:

--- net/if_pfsync.o ---
In file included from net/if_pfsync.c:1:
In file included from
[...]freebsd/arm64.aarch64/tmp/usr/include/net/if_pfsync.h:56:
[...]freebsd/arm64.aarch64/tmp/usr/include/net/pfvar.h:65:10: fatal error:
'netpfil/pf/pf.h' file not found
#include 
 ^
1 error generated.
*** [net/if_pfsync.o] Error code 1

make[3]: stopped in [...]freebsd/tools/build/test-includes
--- net/pfvar.o ---
In file included from net/pfvar.c:1:
[...]freebsd/arm64.aarch64/tmp/usr/include/net/pfvar.h:65:10: fatal error:
'netpfil/pf/pf.h' file not found
#include 
 ^
1 error generated.
*** [net/pfvar.o] Error code 1

make[3]: stopped in [...]freebsd/tools/build/test-includes
2 errors

make[3]: stopped in [...]freebsd/tools/build/test-includes
*** [test-includes] Error code 2

make[2]: stopped in [...]freebsd
1 error

Best regards,
Konrad Sewiłło-Jopek


niedz., 19 gru 2021 o 12:26 Gary Jennejohn 
napisał(a):

> On Sun, 19 Dec 2021 19:05:35 +0800
> Alastair Hogge  wrote:
>
> > On Sunday, 19 December 2021 6:47:23 PM AWST Gary Jennejohn wrote:
> > > Some recent change, probably in a .mk file, breaks builworld on HEAD
> > > when WITHOUT_PF is enabled in src.conf.
> >
> > I have had to disable WITHOUT_PF since 2020-07-27, but probably earlier.
> >
>
> Hmm.  I did a successful buildworld a few days ago with WITHOUT_PF
> enabled, so it's new breakge for me at least.
>
> I don't enable pf in the kernel and don't need it in userland.
>
> > > Disabling WITHOUT_PF results in a successful buildworld.
> > >
> > > The reported error is that netpfil/pf/pf.h can't be found.
> >
> > Some ports depend on that too.
> >
>
> It may not be a problem for ports.  Depends on where they look for
> it.  The file is still there under /sys and /usr/include.
>
> --
> Gary Jennejohn
>
>

pkg upgrade -n -f: Child process pid=… terminated abnormally: Segmentation fault

[Graham Perrin]

Is the fault maybe because the OS is outdated (1400043)?



Updating FreeBSD repository catalogue...
Fetching packagesite.pkg: 100% 6 MiB 1.1MB/s 00:06
pkg: cannot parse fingerprints: error while parsing : line: 1, 
column: 0 - 'key must begin with a letter', character: '-'

Processing entries: 0%
pkg: repository FreeBSD contains packages for wrong OS version: 
FreeBSD:14:amd64

Processing entries: 100%
Unable to update repository FreeBSD
Updating poudriere repository catalogue...
poudriere repository is up to date.
Error updating repositories!
Checking for upgrades (2448 candidates): 89%
Child process pid=47594 terminated abnormally: Segmentation fault
root@mowa219-gjp4-8570p-freebsd:~# pkg upgrade
Updating FreeBSD repository catalogue...
Fetching packagesite.pkg: 100% 6 MiB 1.1MB/s 00:06
pkg: cannot parse fingerprints: error while parsing : line: 1, 
column: 0 - 'key must begin with a letter', character: '-'

Processing entries: 0%
Newer FreeBSD version for package munge:
To ignore this error set IGNORE_OSVERSION=yes
- package: 1400045
- running kernel: 1400043
Ignore the mismatch and continue? [y/N]: y
Processing entries: 100%
Fetching provides database: 100% 15 MiB 1.2MB/s 00:13
Extracting databasesuccess
FreeBSD repository update completed. 31167 packages processed.
Updating poudriere repository catalogue...
poudriere repository is up to date.
All repositories are up to date.
Checking for upgrades (122 candidates): 100%
Processing candidates (122 candidates): 100%
The following 105 package(s) will be affected (of 0 checked):
Installed packages to be UPGRADED:
amfora: 1.8.0_1 -> 1.9.1 [FreeBSD]
…
virtual_oss: 1.2.15 -> 1.2.16 [FreeBSD]
Number of packages to be upgraded: 105
283 MiB to be downloaded.
Proceed with this action? [y/N]: n
root@mowa219-gjp4-8570p-freebsd:~# pkg upgrade -n -f
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating poudriere repository catalogue...
poudriere repository is up to date.
All repositories are up to date.
Checking for upgrades (2448 candidates): 89%
Child process pid=48795 terminated abnormally: Segmentation fault
root@mowa219-gjp4-8570p-freebsd:~#

Re: Panic: Page Fault in Kernel: Yesterday's CURRENT

[Michael Butler via freebsd-current]

Confirmed. The kernel at ..

FreeBSD 14.0-CURRENT #0 f06f1d1fdb9: Mon Dec 20 12:24:51 EST 2021

 .. boots successfully.

The kernel at ..

FreeBSD 14.0-CURRENT #1 553af8f1ec7: Tue Dec 21 15:16:10 EST 2021

 .. fails immediately after printing something like ..

Timecounters tick every 1.000 msec
Timecounter "TSC" frequency 701570048 Hz quality 800

 .. but before initializing ipfw as it used to,

Michael

On 12/21/21 12:01, Michael Butler via freebsd-current wrote:

I have an old pentium-3 that also won't boot kernels built after Dec 6th.

I suspect the commits listed below but, with the device being remote and 
having no DRAC, I'm struggling to test this theory.


The relevant commits ..

commit 553af8f1ec71d397b5b4fd5876622b9269936e63
Author: Mark Johnston 
Date:   Mon Dec 6 10:42:19 2021 -0500

     x86: Perform late TSC calibration before LAPIC timer calibration

commit 62d09b46ad7508ae74d462e49234f0a80f91ff69
Author: Mark Johnston 
Date:   Mon Dec 6 10:42:10 2021 -0500

     x86: Defer LAPIC calibration until after timecounters are available

It's currently running git rev e43d081f352 and I have a kernel at git 
rev f06f1d1fdb969fa7a0a6eefa030d8536f365eb6e to test later this evening,


 Michael


On 12/17/21 15:07, Larry Rosenman wrote:

On 12/17/2021 1:36 pm, Mark Johnston wrote:

On Fri, Dec 10, 2021 at 10:43:19AM -0600, Larry Rosenman wrote:

14-2021_12_07-1217 -  -  1.87G 2021-12-07 12:17
14-2021_12_09-1957 NR /  121G  2021-12-09 19:57

If that's any help


I can't tell what this is saying.  A kernel built on the 7th does not
crash, or...?  Which revision did you update from before you started
seeing crashes?

From a kgdb session it'd be useful to see output from

(kgdb) frame 8
(kgdb) p/x *tmp

to start.



Correct, the 7th didn't panic, but the 9th did, and yesterday's too.

Grrr
ler in borg in /mnt on ☁️  (us-east-1)
❯ kgdb -c /var/crash/vmcore.0  /mnt/boot/kernel/kernel
GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD]
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd14.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
 .

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /mnt/boot/kernel/kernel...
(No debugging symbols found in /mnt/boot/kernel/kernel)
Failed to open vmcore: /var/crash/vmcore.0: Permission denied
(kgdb) bt
No stack.
quitb)

ler in borg in /mnt on ☁️  (us-east-1) took 6s
❯ sudo chmod +r /var/crash/*

ler in borg in /mnt on ☁️  (us-east-1)
❯ kgdb -c /var/crash/vmcore.0  /mnt/boot/kernel/kernel
GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD]
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd14.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
 .

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /mnt/boot/kernel/kernel...
(No debugging symbols found in /mnt/boot/kernel/kernel)
/wrkdirs/usr/ports/devel/gdb/work-py37/gdb-11.1/gdb/thread.c:1345: 
internal-error: void switch_to_thread(thread_info *): Assertion `thr 
!= NULL' failed.

A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n

This is a bug, please report it.  For instructions, see:
.

/wrkdirs/usr/ports/devel/gdb/work-py37/gdb-11.1/gdb/thread.c:1345: 
internal-error: void switch_to_thread(thread_info *): Assertion `thr 
!= NULL' failed.

A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) n
Command aborted.
(kgdb) bt
No thread selected.
(kgdb) fr 8
No thread selected.
(kgdb)


On 12/10/2021 10:36 am, Alexander Motin wrote:
> Hi Larry,
>
> This looks like some use-after-free or otherwise corrupted callout
> structure.  Unfortunately the backtrace does not tell what was the
> callout.  When was the previous update to look what could change?
>
> On 10.12.2021 11:24, Larry 

Re: Kernel panic in networking code

[Dustin Marquess]

On Thu, Dec 9, 2021 at 12:35 PM Shawn Webb  wrote:
>
> On Thu, Dec 09, 2021 at 12:05:30PM -0500, Mark Johnston wrote:
> > On Thu, Dec 09, 2021 at 10:20:10AM -0500, Shawn Webb wrote:
> > > Hey all,
> > >
> > > It looks like there's a potential deadlock in some networking code,
> > > specifically with ipv4 jails. I can reproduce by running Poudriere on
> > > 14-CURRENT.
> > >
> > > I am using HardenedBSD 14-CURRENT, but we don't have any changes to
> > > any point in the code paths that would trigger/cause this kind of
> > > kernel panic.
> > >
> > > I've uploaded the crash.txt file here:
> > > https://hardenedbsd.org/~shawn/2021-12-09_crash-01.txt
> >
> > There is some WIP to address this in https://reviews.freebsd.org/D9
> > and its followup revision.
>
> Awesome. Thanks for the response! I'll follow along. I'm happy to test
> out the patch before it lands if needed/wanted.

I've been running glebius's revised D9 patch from Friday on my
HardenedBSD -CURRENT box since he posted it, and I haven't had any
jail related issues since. Granted I'm not running pourdriere builds
either, but I guess I could kick one off...


-Dustin

Re: Panic: Page Fault in Kernel: Yesterday's CURRENT

[Michael Butler via freebsd-current]

I have an old pentium-3 that also won't boot kernels built after Dec 6th.

I suspect the commits listed below but, with the device being remote and 
having no DRAC, I'm struggling to test this theory.


The relevant commits ..

commit 553af8f1ec71d397b5b4fd5876622b9269936e63
Author: Mark Johnston 
Date:   Mon Dec 6 10:42:19 2021 -0500

x86: Perform late TSC calibration before LAPIC timer calibration

commit 62d09b46ad7508ae74d462e49234f0a80f91ff69
Author: Mark Johnston 
Date:   Mon Dec 6 10:42:10 2021 -0500

x86: Defer LAPIC calibration until after timecounters are available

It's currently running git rev e43d081f352 and I have a kernel at git 
rev f06f1d1fdb969fa7a0a6eefa030d8536f365eb6e to test later this evening,


Michael


On 12/17/21 15:07, Larry Rosenman wrote:

On 12/17/2021 1:36 pm, Mark Johnston wrote:

On Fri, Dec 10, 2021 at 10:43:19AM -0600, Larry Rosenman wrote:

14-2021_12_07-1217 -  -  1.87G 2021-12-07 12:17
14-2021_12_09-1957 NR /  121G  2021-12-09 19:57

If that's any help


I can't tell what this is saying.  A kernel built on the 7th does not
crash, or...?  Which revision did you update from before you started
seeing crashes?

From a kgdb session it'd be useful to see output from

(kgdb) frame 8
(kgdb) p/x *tmp

to start.



Correct, the 7th didn't panic, but the 9th did, and yesterday's too.

Grrr
ler in borg in /mnt on ☁️  (us-east-1)
❯ kgdb -c /var/crash/vmcore.0  /mnt/boot/kernel/kernel
GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD]
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd14.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
     .

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /mnt/boot/kernel/kernel...
(No debugging symbols found in /mnt/boot/kernel/kernel)
Failed to open vmcore: /var/crash/vmcore.0: Permission denied
(kgdb) bt
No stack.
quitb)

ler in borg in /mnt on ☁️  (us-east-1) took 6s
❯ sudo chmod +r /var/crash/*

ler in borg in /mnt on ☁️  (us-east-1)
❯ kgdb -c /var/crash/vmcore.0  /mnt/boot/kernel/kernel
GNU gdb (GDB) 11.1 [GDB v11.1 for FreeBSD]
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd14.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
     .

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /mnt/boot/kernel/kernel...
(No debugging symbols found in /mnt/boot/kernel/kernel)
/wrkdirs/usr/ports/devel/gdb/work-py37/gdb-11.1/gdb/thread.c:1345: 
internal-error: void switch_to_thread(thread_info *): Assertion `thr != 
NULL' failed.

A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n

This is a bug, please report it.  For instructions, see:
.

/wrkdirs/usr/ports/devel/gdb/work-py37/gdb-11.1/gdb/thread.c:1345: 
internal-error: void switch_to_thread(thread_info *): Assertion `thr != 
NULL' failed.

A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) n
Command aborted.
(kgdb) bt
No thread selected.
(kgdb) fr 8
No thread selected.
(kgdb)


On 12/10/2021 10:36 am, Alexander Motin wrote:
> Hi Larry,
>
> This looks like some use-after-free or otherwise corrupted callout
> structure.  Unfortunately the backtrace does not tell what was the
> callout.  When was the previous update to look what could change?
>
> On 10.12.2021 11:24, Larry Rosenman wrote:
>> FreeBSD borg.lerctr.org 14.0-CURRENT FreeBSD 14.0-CURRENT #15
>> main-n251537-ab639f2398b: Thu Dec  9 19:45:37 CST 2021
>> r...@borg.lerctr.org:/usr/obj/usr/src/amd64.amd64/sys/LER-MINIMAL
>> amd64
>>
>> VMCORE *IS* available.
>>
>>
>>
>>
>> Unread portion of the kernel message buffer:
>> kernel trap 12 with interrupts disabled
>>
>>
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 0; apic id = 20
>> fault virtual address   = 0x0
>> fault code 

Re: What to do about tgammal?

[Steve Kargl]

On Tue, Dec 21, 2021 at 03:46:40PM +0100, Marc Fonvieille wrote:
> Le 20.12.2021 16:48, Steve Kargl a écrit :
> > On Mon, Dec 20, 2021 at 11:15:53AM +0100, Marc Fonvieille wrote:
> > >
> > > I assume what Steve is talking about is the corresponding value in
> > > decimal of the number of ULP.
> > > 
> > 
> > Bad assumption.  Please read Goldberg's paper.  I am talking
> > about ULP in the underlying floating point format.
> >
> 
> Thanks, it's more clear now: it's the ULP value.
> Is your tlibm_libm program available for testing ?  If I find time I'd like to
> do some tests.
> 

Not at the moment.  tlibm only handles math functions with
a single real agrument [1].  I've been thinking about adding
the 2 argument functions such as atan2 and complex argument
function, but lack the time.  I also need to improve the man
page to decoment the default domain for each function and its
complete domain.

[1] acos, acosh, asin, asinh, atan, atanh, cbrt, cos, cosh, erf,
erfc, exp, exp2, expm1, j0, j1, lgamma, log, log10, log1p,
log2, sin, sinh, sqrt, tan, tanh, tgamma, y0, y1.
-- 
Steve

Re: What to do about tgammal?

[Marc Fonvieille]

Le 20.12.2021 16:48, Steve Kargl a écrit :
> On Mon, Dec 20, 2021 at 11:15:53AM +0100, Marc Fonvieille wrote:
> >
> > I assume what Steve is talking about is the corresponding value in
> > decimal of the number of ULP.
> > 
> 
> Bad assumption.  Please read Goldberg's paper.  I am talking
> about ULP in the underlying floating point format.
>

Thanks, it's more clear now: it's the ULP value.
Is your tlibm_libm program available for testing ?  If I find time I'd like to
do some tests.

-- 
Marc

Re: Arduino IDF -> make/automake based environment

[FreeBSD User]

Am Mon, 20 Dec 2021 14:35:10 +0100
schrieb Marc Fonvieille :

> Le 19.12.2021 21:03, Andrew Stevenson a écrit :
> > 
> >   
> > > On 19. Dec 2021, at 12:18, FreeBSD User 
> > > wrote:
> > > 
> > > environment. Since I'm interested in coding for some smaller
> > > AMTEL MCUs and ESP32 and like to digg a bit deeper than simply
> > > clicking a host base from a menu, I'm not afraid of doing some
> > > larger basic setup if needed.  
> > 
> > If by small AMTEL MCUs you mean AVRs then avr-gcc and avrdude are
> > in ports. 
> 
> For ESP32, you should look at:
> https://wiki.freebsd.org/electronics/arduino/esp32
> and
> https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-for-arduino-on-freebsd12-update-2021-08-17.78408/
> 

Great!

Thanks a lot.

Oliver