Re: main cadd2ca217 doesn't boot

[tuexen]

> On 26. May 2024, at 09:29, Bojan Novković  wrote:
> 
> Hi,
> 
> da76d349b6b1 replaced a UMA-related symbol but missed three instances where 
> the old one was used, ultimately causing the wrong UMA page allocator to get 
> selected and crashing the machine.
> 
> I tested this patch as a part of a bigger series where it works fine, so this 
> slipped through cracks without getting noticed.
> 
> I've attached a patch with a fix, I can boot an amd64 VM with it applied.
> Could you please give it a try and let me know if it fixes the issue?
Hi Hojan,

this fixes the issue for me using an arm64 VM (VMWare Fusion).

Best regards
Michael
> 
> Bojan
> 

Re: Request for Testing: TCP RACK

[tuexen]

> On 10. Apr 2024, at 13:40, Nuno Teixeira  wrote:
> 
> Hello all,
> 
> @ current 1500018 and fetching torrents with net-p2p/qbittorrent finished 
> ~2GB download and connection UP until the end: 
> 
> ---
> Apr 10 11:26:46 leg kernel: re0: watchdog timeout
> Apr 10 11:26:46 leg kernel: re0: link state changed to DOWN
> Apr 10 11:26:49 leg dhclient[58810]: New IP Address (re0): 192.168.1.67
> Apr 10 11:26:49 leg dhclient[58814]: New Subnet Mask (re0): 255.255.255.0
> Apr 10 11:26:49 leg dhclient[58818]: New Broadcast Address (re0): 
> 192.168.1.255
> Apr 10 11:26:49 leg kernel: re0: link state changed to UP
> Apr 10 11:26:49 leg dhclient[58822]: New Routers (re0): 192.168.1.1
> ---
> 
> In the past tests, I've got more watchdog timeouts, connection goes down and 
> a reboot needed to put it back (`service netif restart` didn't work).
> 
> Other way to reproduce this is using sysutils/restic (backup program) to 
> read/check all files from a remote server via sftp:
> 
> `restic -r sftp:user@remote:restic-repo check --read-data` from a 60GB 
> compressed backup.
> 
> ---
> watchdog timeout x3 as above
> ---
> 
> restic check fail log @ 15% progress:
> ---
> 
> Load(, 17310001, 0) returned error, retrying after 
> 1.7670599s: connection lost
> Load(, 17456892, 0) returned error, retrying after 
> 4.619104908s: connection lost
> Load(, 17310001, 0) returned error, retrying after 
> 5.477648517s: connection lost
> List(lock) returned error, retrying after 293.057766ms: connection lost
> List(lock) returned error, retrying after 385.206693ms: connection lost
> List(lock) returned error, retrying after 1.577594281s: connection lost
> 
> 
> Connection continues UP.
Hi,

I'm not sure what the issue is you are reporting. Could you state
what behavior you are experiencing with the base stack and with
the RACK stack. In particular, what the difference is?

Best regards
Michael
> 
> Cheers,
> 
>  escreveu (quinta, 28/03/2024 à(s) 15:53):
>> On 28. Mar 2024, at 15:00, Nuno Teixeira  wrote:
>> 
>> Hello all!
>> 
>> Running rack @b7b78c1c169 "Optimize HPTS..." very happy on my laptop (amd64)!
>> 
>> Thanks all!
> Thanks for the feedback!
> 
> Best regards
> Michael
>> 
>> Drew Gallatin  escreveu (quinta, 21/03/2024 à(s) 
>> 12:58):
>> The entire point is to *NOT* go through the overhead of scheduling something 
>> asynchronously, but to take advantage of the fact that a user/kernel 
>> transition is going to trash the cache anyway.
>> 
>> In the common case of a system which has less than the threshold  number of 
>> connections , we access the tcp_hpts_softclock function pointer, make one 
>> function call, and access hpts_that_need_softclock, and then return.  So 
>> that's 2 variables and a function call.
>> 
>> I think it would be preferable to avoid that call, and to move the 
>> declaration of tcp_hpts_softclock and hpts_that_need_softclock so that they 
>> are in the same cacheline.  Then we'd be hitting just a single line in the 
>> common case.  (I've made comments on the review to that effect).
>> 
>> Also, I wonder if the threshold could get higher by default, so that hpts is 
>> never called in this context unless we're to the point where we're 
>> scheduling thousands of runs of the hpts thread (and taking all those clock 
>> interrupts).
>> 
>> Drew
>> 
>> On Wed, Mar 20, 2024, at 8:17 PM, Konstantin Belousov wrote:
>>> On Tue, Mar 19, 2024 at 06:19:52AM -0400, rrs wrote:
 Ok I have created
 
 https://reviews.freebsd.org/D44420
 
 
 To address the issue. I also attach a short version of the patch that Nuno
 can try and validate
 
 it works. Drew you may want to try this and validate the optimization does
 kick in since I can
 
 only now test that it does not on my local box :)
>>> The patch still causes access to all cpu's cachelines on each userret.
>>> It would be much better to inc/check the threshold and only schedule the
>>> call when exceeded.  Then the call can occur in some dedicated context,
>>> like per-CPU thread, instead of userret.
>>> 
 
 
 R
 
 
 
 On 3/18/24 3:42 PM, Drew Gallatin wrote:
> No.  The goal is to run on every return to userspace for every thread.
> 
> Drew
> 
> On Mon, Mar 18, 2024, at 3:41 PM, Konstantin Belousov wrote:
>> On Mon, Mar 18, 2024 at 03:13:11PM -0400, Drew Gallatin wrote:
>>> I got the idea from
>>> https://people.mpi-sws.org/~druschel/publications/soft-timers-tocs.pdf
>>> The gist is that the TCP pacing stuff needs to run frequently, and
>>> rather than run it out of a clock interrupt, its more efficient to run
>>> it out of a system call context at just the point where we return to
>>> userspace and the cache is trashed anyway. The current implementation
>>> is fine for our workload, but probably not idea for a generic system.
>>> Especially one where something is banging on system calls.
>>> 
>>> Ast's could be the right 

Re: Request for Testing: TCP RACK

[tuexen]

> On 28. Mar 2024, at 15:00, Nuno Teixeira  wrote:
> 
> Hello all!
> 
> Running rack @b7b78c1c169 "Optimize HPTS..." very happy on my laptop (amd64)!
> 
> Thanks all!
Thanks for the feedback!

Best regards
Michael
> 
> Drew Gallatin  escreveu (quinta, 21/03/2024 à(s) 12:58):
> The entire point is to *NOT* go through the overhead of scheduling something 
> asynchronously, but to take advantage of the fact that a user/kernel 
> transition is going to trash the cache anyway.
> 
> In the common case of a system which has less than the threshold  number of 
> connections , we access the tcp_hpts_softclock function pointer, make one 
> function call, and access hpts_that_need_softclock, and then return.  So 
> that's 2 variables and a function call.
> 
> I think it would be preferable to avoid that call, and to move the 
> declaration of tcp_hpts_softclock and hpts_that_need_softclock so that they 
> are in the same cacheline.  Then we'd be hitting just a single line in the 
> common case.  (I've made comments on the review to that effect).
> 
> Also, I wonder if the threshold could get higher by default, so that hpts is 
> never called in this context unless we're to the point where we're scheduling 
> thousands of runs of the hpts thread (and taking all those clock interrupts).
> 
> Drew
> 
> On Wed, Mar 20, 2024, at 8:17 PM, Konstantin Belousov wrote:
>> On Tue, Mar 19, 2024 at 06:19:52AM -0400, rrs wrote:
>>> Ok I have created
>>> 
>>> https://reviews.freebsd.org/D44420
>>> 
>>> 
>>> To address the issue. I also attach a short version of the patch that Nuno
>>> can try and validate
>>> 
>>> it works. Drew you may want to try this and validate the optimization does
>>> kick in since I can
>>> 
>>> only now test that it does not on my local box :)
>> The patch still causes access to all cpu's cachelines on each userret.
>> It would be much better to inc/check the threshold and only schedule the
>> call when exceeded.  Then the call can occur in some dedicated context,
>> like per-CPU thread, instead of userret.
>> 
>>> 
>>> 
>>> R
>>> 
>>> 
>>> 
>>> On 3/18/24 3:42 PM, Drew Gallatin wrote:
 No.  The goal is to run on every return to userspace for every thread.
 
 Drew
 
 On Mon, Mar 18, 2024, at 3:41 PM, Konstantin Belousov wrote:
> On Mon, Mar 18, 2024 at 03:13:11PM -0400, Drew Gallatin wrote:
>> I got the idea from
>> https://people.mpi-sws.org/~druschel/publications/soft-timers-tocs.pdf
>> The gist is that the TCP pacing stuff needs to run frequently, and
>> rather than run it out of a clock interrupt, its more efficient to run
>> it out of a system call context at just the point where we return to
>> userspace and the cache is trashed anyway. The current implementation
>> is fine for our workload, but probably not idea for a generic system.
>> Especially one where something is banging on system calls.
>> 
>> Ast's could be the right tool for this, but I'm super unfamiliar with
>> them, and I can't find any docs on them.
>> 
>> Would ast_register(0, ASTR_UNCOND, 0, func) be roughly equivalent to
>> what's happening here?
> This call would need some AST number added, and then it registers the
> ast to run on next return to userspace, for the current thread.
> 
> Is it enough?
>> 
>> Drew
> 
>> 
>> On Mon, Mar 18, 2024, at 2:33 PM, Konstantin Belousov wrote:
>>> On Mon, Mar 18, 2024 at 07:26:10AM -0500, Mike Karels wrote:
 On 18 Mar 2024, at 7:04, tue...@freebsd.org wrote:
 
>> On 18. Mar 2024, at 12:42, Nuno Teixeira
>  wrote:
>> 
>> Hello all!
>> 
>> It works just fine!
>> System performance is OK.
>> Using patch on main-n268841-b0aaf8beb126(-dirty).
>> 
>> ---
>> net.inet.tcp.functions_available:
>> Stack   D
> AliasPCB count
>> freebsd freebsd  0
>> rack*
> rack 38
>> ---
>> 
>> It would be so nice that we can have a sysctl tunnable for
> this patch
>> so we could do more tests without recompiling kernel.
> Thanks for testing!
> 
> @gallatin: can you come up with a patch that is acceptable
> for Netflix
> and allows to mitigate the performance regression.
 
 Ideally, tcphpts could enable this automatically when it
> starts to be
 used (enough?), but a sysctl could select auto/on/off.
>>> There is already a well-known mechanism to request execution of the
>>> specific function on return to userspace, namely AST.  The difference
>>> with the current hack is that the execution is requested for one
> callback
>>> in the context of the specific thread.
>>> 
>>> Still, it might be worth a try to use it; what 

Re: Problem with make installworld

[tuexen]

> On 21. Mar 2024, at 18:12, Dimitry Andric  wrote:
> 
> On 21 Mar 2024, at 01:12, tue...@freebsd.org wrote:
>> 
>>> On 21. Mar 2024, at 00:27, Dimitry Andric  wrote:
>>> 
>>> On 20 Mar 2024, at 21:44, tue...@freebsd.org wrote:
>>>> 
>>>> I'm trying to run make buildworld / make installworld on a recent main 
>>>> branch
>>>> (some days old).
>>>> 
>>>> The problem is related to lib/libc/tests/ssp/Makefile
>>>> which contains:
>>>> _libclang_rt_ubsan= 
>>>> ${SYSROOT}${SANITIZER_LIBDIR}/libclang_rt.ubsan_standalone-${CRTARCH}.a
>>>> if exists(${_libclang_rt_ubsan})
>>>> PROGS+= h_raw
>>>> LDADD.h_raw+=   ${SANITIZER_LDFLAGS}
>>>> 
>>>> When running make buildworld, we have
>>>> ${SYSROOT} = /usr/obj/usr/home/tuexen/freebsd-src/powerpc.powerpc64/tmp
>>>> ${SANITIZER_LIBDIR} = /usr/lib/clang/17/lib/freebsd
>>>> and so the script is looking for
>>>> /usr/obj/usr/home/tuexen/freebsd-src/powerpc.powerpc64/tmp/usr/lib/clang/17/lib/freebsd/libclang_rt.ubsan_standalone-powerpc64.a
>>>> which does not exist:
>>>> tuexen@blackbird:~ % ls -l 
>>>> /usr/obj/usr/home/tuexen/freebsd-src/powerpc.powerpc64/tmp/usr/lib/clang/17/lib/freebsd/
>>>> total 652
>>>> -r--r--r--  1 root wheel 284316 Mar 20 18:03 libclang_rt.profile-powerpc.a
>>>> -r--r--r--  1 root wheel 380704 Mar 20 17:41 
>>>> libclang_rt.profile-powerpc64.a
>>>> 
>>>> Therefore, h_raw to NOT built.
>>> 
>>> As far as I can see, for powerpc64 it should have been built somewhere 
>>> during the libraries stage. So it's a bit strange that you don't have the 
>>> file. Did you use any special options to build?
>> No, not any I'm aware of. I can run tests or provide further information.
> 
> This was my mistake: I recently refactored lib/libclang_rt/Makefile to make 
> it more readable and maintainable, but it accidentally broke building of most 
> of the libclang_rt*.a files for powerpc64. It should now be fixed by 
> https://cgit.freebsd.org/src/commit/?id=f0620ceeccf0 .
Hi Dimitry,

I tested the main branch with your fix and I can confirm that the
problem is fixed.

Thank you very much for the quick fix!

Best regards
Michael
> 
> -Dimitry
> 

Re: Problem with make installworld

[tuexen]

> On 21. Mar 2024, at 00:27, Dimitry Andric  wrote:
> 
> On 20 Mar 2024, at 21:44, tue...@freebsd.org wrote:
>> 
>> I'm trying to run make buildworld / make installworld on a recent main branch
>> (some days old).
>> 
>> The problem is related to lib/libc/tests/ssp/Makefile
>> which contains:
>> _libclang_rt_ubsan= 
>> ${SYSROOT}${SANITIZER_LIBDIR}/libclang_rt.ubsan_standalone-${CRTARCH}.a
>> if exists(${_libclang_rt_ubsan})
>> PROGS+= h_raw
>> LDADD.h_raw+=   ${SANITIZER_LDFLAGS}
>> 
>> When running make buildworld, we have
>> ${SYSROOT} = /usr/obj/usr/home/tuexen/freebsd-src/powerpc.powerpc64/tmp
>> ${SANITIZER_LIBDIR} = /usr/lib/clang/17/lib/freebsd
>> and so the script is looking for
>> /usr/obj/usr/home/tuexen/freebsd-src/powerpc.powerpc64/tmp/usr/lib/clang/17/lib/freebsd/libclang_rt.ubsan_standalone-powerpc64.a
>> which does not exist:
>> tuexen@blackbird:~ % ls -l 
>> /usr/obj/usr/home/tuexen/freebsd-src/powerpc.powerpc64/tmp/usr/lib/clang/17/lib/freebsd/
>> total 652
>> -r--r--r--  1 root wheel 284316 Mar 20 18:03 libclang_rt.profile-powerpc.a
>> -r--r--r--  1 root wheel 380704 Mar 20 17:41 libclang_rt.profile-powerpc64.a
>> 
>> Therefore, h_raw to NOT built.
> 
> As far as I can see, for powerpc64 it should have been built somewhere during 
> the libraries stage. So it's a bit strange that you don't have the file. Did 
> you use any special options to build?
No, not any I'm aware of. I can run tests or provide further information.

Best regards
Michael
> 
> -Dimitry
> 

Problem with make installworld

[tuexen]

Dear all,

I'm trying to run make buildworld / make installworld on a recent main branch
(some days old).

The problem is related to lib/libc/tests/ssp/Makefile
which contains:
_libclang_rt_ubsan= 
${SYSROOT}${SANITIZER_LIBDIR}/libclang_rt.ubsan_standalone-${CRTARCH}.a
if exists(${_libclang_rt_ubsan})
PROGS+= h_raw
LDADD.h_raw+=   ${SANITIZER_LDFLAGS}

When running make buildworld, we have
${SYSROOT} = /usr/obj/usr/home/tuexen/freebsd-src/powerpc.powerpc64/tmp
${SANITIZER_LIBDIR} = /usr/lib/clang/17/lib/freebsd
and so the script is looking for
/usr/obj/usr/home/tuexen/freebsd-src/powerpc.powerpc64/tmp/usr/lib/clang/17/lib/freebsd/libclang_rt.ubsan_standalone-powerpc64.a
which does not exist:
tuexen@blackbird:~ % ls -l 
/usr/obj/usr/home/tuexen/freebsd-src/powerpc.powerpc64/tmp/usr/lib/clang/17/lib/freebsd/
total 652
-r--r--r--  1 root wheel 284316 Mar 20 18:03 libclang_rt.profile-powerpc.a
-r--r--r--  1 root wheel 380704 Mar 20 17:41 libclang_rt.profile-powerpc64.a

Therefore, h_raw to NOT built.

However, when make installworld runs, we have
${SYSROOT} =
${SANITIZER_LIBDIR} = /usr/lib/clang/17/lib/freebsd
and so the script is looking for
/usr/lib/clang/17/lib/freebsd/libclang_rt.ubsan_standalone-powerpc64.a
which does exist:
tuexen@blackbird:~ % ls -l /usr/lib/clang/17/lib/freebsd/
total 47320
-r--r--r--  1 root wheel 14485032 Dec 24 22:48 libclang_rt.asan-powerpc64.a
-r--r--r--  1 root wheel  1249352 Dec 24 22:48 libclang_rt.asan-powerpc64.so
-r--r--r--  1 root wheel 9820 Dec 24 22:48 
libclang_rt.asan-preinit-powerpc64.a
-r--r--r--  1 root wheel   176354 Dec 24 22:48 libclang_rt.asan_cxx-powerpc64.a
-r--r--r--  1 root wheel10154 Dec 24 22:48 
libclang_rt.asan_static-powerpc64.a
-r--r--r--  1 root wheel  8261052 Dec 24 22:48 libclang_rt.msan-powerpc64.a
-r--r--r--  1 root wheel   166924 Dec 24 22:48 libclang_rt.msan_cxx-powerpc64.a
-r--r--r--  1 root wheel   284316 Dec 24 22:51 libclang_rt.profile-powerpc.a
-r--r--r--  1 root wheel   380704 Dec 24 22:48 libclang_rt.profile-powerpc64.a
-r--r--r--  1 root wheel  3925468 Dec 24 22:48 libclang_rt.stats-powerpc64.a
-r--r--r--  1 root wheel 9770 Dec 24 22:48 
libclang_rt.stats_client-powerpc64.a
-r--r--r--  1 root wheel 14144552 Dec 24 22:48 libclang_rt.tsan-powerpc64.a
-r--r--r--  1 root wheel   295650 Dec 24 22:48 libclang_rt.tsan_cxx-powerpc64.a
-r--r--r--  1 root wheel64462 Dec 24 22:48 
libclang_rt.ubsan_minimal-powerpc64.a
-r--r--r--  1 root wheel  4550190 Dec 24 22:48 
libclang_rt.ubsan_standalone-powerpc64.a
-r--r--r--  1 root wheel   113638 Dec 24 22:48 
libclang_rt.ubsan_standalone_cxx-powerpc64.a

Therefore, h_raw is tried to be installed, which fails since it wasn't built.

Is it intended that ${SYSROOT} is different during make installworld and make 
buildworld?

This is on a Power9 system, but I guess this is not relevant... But maybe I'm 
wrong.

Best regards
Michael

Re: Request for Testing: TCP RACK

[tuexen]

> On 18. Mar 2024, at 12:42, Nuno Teixeira  wrote:
> 
> Hello all!
> 
> It works just fine!
> System performance is OK.
> Using patch on main-n268841-b0aaf8beb126(-dirty).
> 
> ---
> net.inet.tcp.functions_available:
> Stack   D AliasPCB count
> freebsd   freebsd  0
> rack* rack 38
> ---
> 
> It would be so nice that we can have a sysctl tunnable for this patch
> so we could do more tests without recompiling kernel.
Thanks for testing!

@gallatin: can you come up with a patch that is acceptable for Netflix
and allows to mitigate the performance regression.

Best regards
Michael
> 
> Thanks all!
> Really happy here :)
> 
> Cheers,
> 
> Nuno Teixeira  escreveu (domingo, 17/03/2024 à(s) 20:26):
>> 
>> Hello,
>> 
>>> I don't have the full context, but it seems like the complaint is a 
>>> performance regression in bonnie++ and perhaps other things when tcp_hpts 
>>> is loaded, even when it is not used.  Is that correct?
>>> 
>>> If so, I suspect its because we drive the tcp_hpts_softclock() routine from 
>>> userret(), in order to avoid tons of timer interrupts and context switches. 
>>>  To test this theory,  you could apply a patch like:
>> 
>> It's affecting overall system performance, bonnie was just a way to
>> get some numbers to compare.
>> 
>> Tomorrow I will test patch.
>> 
>> Thanks!
>> 
>> --
>> Nuno Teixeira
>> FreeBSD Committer (ports)
> 
> 
> 
> -- 
> Nuno Teixeira
> FreeBSD Committer (ports)

Re: Request for Testing: TCP RACK

[tuexen]

> On 17. Mar 2024, at 16:39, Drew Gallatin  wrote:
> 
> I don't have the full context, but it seems like the complaint is a 
> performance regression in bonnie++ and perhaps other things when tcp_hpts is 
> loaded, even when it is not used.  Is that correct?
Correct.
> 
> If so, I suspect its because we drive the tcp_hpts_softclock() routine from 
> userret(), in order to avoid tons of timer interrupts and context switches.  
> To test this theory,  you could apply a patch like:
> 
> diff --git a/sys/kern/subr_trap.c b/sys/kern/subr_trap.c
> index e9a16cd0b36e..54b540c97123 100644
> --- a/sys/kern/subr_trap.c
> +++ b/sys/kern/subr_trap.c
> @@ -138,7 +138,7 @@ userret(struct thread *td, struct trapframe *frame)
> * Software Timer Support for Network Processing"
> * by Mohit Aron and Peter Druschel.
> */
> -   tcp_hpts_softclock();
> +   /*tcp_hpts_softclock();*/
>/*
> * Let the scheduler adjust our priority etc.
> */
> 
> 
> If that fixes it, I suspect we should either make this hook optional for 
> casual users of tcp_hpts(), or add some kind of "last called" timestamp to 
> prevent it being called over and over and over on workloads which are syscall 
> heavy.
Nuno, can you test that?
> 
> Note that for non-casual users of hpts (like Netflix, with hundreds of 
> thousands of TCP connections managed by hpts), this call is a huge win, so I 
> think we'd prefer that it remain in some form.
Sure.

Best regards
Michael
> 
> Drew

Re: Request for Testing: TCP RACK

[tuexen]

> On 16. Mar 2024, at 21:29, Nuno Teixeira  wrote:
> 
>> Just to double check: you only load the tcp_rack. You don't run
>> sysctl net.inet.tcp.functions_default=rack
> 
> I'm not using sysctl, just loading module.
And you also don't have
net.inet.tcp.functions_default=rack
in /etc/sysctl.conf
This means that no TCP connection will actually use the RACK stack.
> 
>> What does "poudriere testport net/gitup" do? Only build stuff or does is
>> also download something?
>> 
>> What does bonnie++ do?
> 
> poudriere is for testing ports and it uses jails to build stuff.
> It have restrict access to net to fetch distfiles (not the case as
> distfile is present on disk)
> 
> bonnie++ is a disk benchmark
Thanks for clarifying.
> 
>> Could you reboot the system, run the test, do kldload tcphpts, run
>> the test again, do kldload tcp_rack, and run it again.
> 
> The previous test [2] was obtained by loading tcp_rack
> 
> Now I will post results for test [3] by loading (only) tcphpts module.
Great. This makes sure that the degradation is related to TCPHPTS and
not the RACK stack.
> 
> [3] kldload tcphpts:
> 
> ==> poudriere testport net/gitup:
> 55.26s real 5.23s user  1m19.91s sys
So this test goes up from 11 seconds to 55 seconds...
> 
> ==> bonnie++
> Version  1.98   --Sequential Output-- --Sequential Input- 
> --Random-
>   -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
> Name:Size etc/sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec 
> %CP
> leg.home32G   12k  99 73.0m  99 51.1m  99   27k  99  128m  99  8038 
> 2194
> Latency  1763ms 194ms   23979us 431ms1267us2776us
> Version  1.98   --Sequential Create-- Random 
> Create
> leg.home-Create-- --Read--- -Delete-- -Create-- --Read--- 
> -Delete--
> files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
>16 7017.934752  98 21243.823180 100 7780.918458  99
> 9281.48  98 21368.647657 100 7457.828733  99
> Latency  3015us 220us2398us1106us 386us2473us
> 
> Summary:
> 
> - I can't remember better tests to do as I can feel the entire OS is
> being slow, without errors, just slow.
This is interesting. It seems a consequence on loading TCPHPTS, not actually
using it.

I have CCed Drew and Randall, who know much more about HPTS and might have
follow up questions. I'll bring the issue up in the FreeBSD transport call
next Thursday.

What hardware are you using?

Best regards
Michael
> - Approx. results as test [2]
> 
> 
> 
> 
> Nuno Teixeira
> FreeBSD Committer (ports)

Re: Request for Testing: TCP RACK

[tuexen]

> On 16. Mar 2024, at 20:06, Nuno Teixeira  wrote:
> 
>>> Will update amd64 laptop to main-n268827-75464941dc17 (Mar 16) and test it.
>> Please do so...
> 
> @main-n268827-75464941dc17 GENERIC-NODEBUG amd64
> 
> Ok, I think I have here some numbers related to disk performance being
> affected by tcp_rack that somehow is messing with something.
> 
> NOTES:
> - test [1] was done after a boot without tcp_rack in loader.conf and
> [2] tcp_rack was loaded manually with kldload (without rebooting)
> - After unloading tcp_rack, same results as [2]
> - Cannot unload tcptpts: device busy
tcphpts does not support unloading. So that is fine.

Just to double check: you only load the tcp_rack. You don't run
sysctl net.inet.tcp.functions_default=rack

This means you load RACK, but you don't use it.

What does "poudriere testport net/gitup" do? Only build stuff or does is
also download something?

What does bonnie++ do?

Could you reboot the system, run the test, do kldload tcphpts, run
the test again, do kldload tcp_rack, and run it again.

I'm wondering if tcphpts is affecting the measurements...

Thanks for testing.

Best regards
Michael
> 
> [1] without tcp_rack loaded:
> 
> ==> poudriere testport net/gitup:
> 11.16s real 5.35s user  6.35s sys
> 
> ==> bonnie++:
> Version  1.98   --Sequential Output-- --Sequential Input- 
> --Random-
>   -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
> Name:Size etc/sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec 
> %CP
> leg.home32G   25k  99  105m  99 88.7m  99   77k  99  198m  99 12716 
> 1784
> Latency   351ms1793us2340us 241ms 638us2514us
> Version  1.98   --Sequential Create-- Random 
> Create
> leg.home-Create-- --Read--- -Delete-- -Create-- --Read--- 
> -Delete--
> files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
>16 14908.273230  97 + +++ 6878.516657  99
> 15194.808063  97 + +++ 8019.731670  99
> Latency  1108us 182us2228us1013us 152us2424us
> 
> [2] kldload tcp_rack:
> 
> ==> poudriere testport net/gitup:
> 1m0.54s real4.98s user  1m31.38s sys
> 
> ==> bonnie++:
> Version  1.98   --Sequential Output-- --Sequential Input- 
> --Random-
>   -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
> Name:Size etc/sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec 
> %CP
> leg.home32G   14k  99 78.0m  99 46.6m  99   25k  99  120m  99  6688 
> 2161
> Latency   676ms   18309us   76171us 385ms 924us2274us
> Version  1.98   --Sequential Create-- Random 
> Create
> leg.home-Create-- --Read--- -Delete-- -Create-- --Read--- 
> -Delete--
> files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
>16 8139.513260  96 19437.792294  99 5494.638508  99
> 8099.275425  96 19723.528878  99 6363.123671  99
> Latency  2982us 338us3072us1135us 591us3236us
> 
> Cheers,
> 
> 
> 
> 
> 
> 
> 
> --
> Nuno Teixeira
> FreeBSD Committer (ports)

Re: Request for Testing: TCP RACK

[tuexen]

> On 16. Mar 2024, at 15:00, Nuno Teixeira  wrote:
> 
>> If you load tcp_rack via kldload, tcphtps get loaded automatically.
>> If you load if via /boot/loader.conf, you need to have
>> tcphpts_load="YES"
>> in addition to
>> tcp_rack_load="YES"
> 
> As of my tests, loader.conf: tcp_rack_load="YES" loads tcphtps.ko auto:
> 
> 31 0x81f53000545e0 tcp_rack.ko
> 42 0x81fa800014588 tcphpts.ko
Interesting. Works on my arm64 machine, too. I think when I tested things
for writing the article, I figured out that just doing
tcp_rack_load="YES"
in /boot/loader.conf was not working on a kernel configured without
TCPHPTS.
> 
> On aarch64 (rpi4) I didn't get any performance issues in
> 
> main-n268730-96ad640178ea (Mar 8)
> and
> main-n268827-75464941dc17 (Mar 16)
> 
> So it seems not related to rack commit e18b97bd63a8: Update to bring
> the rack stack with all its fixes in.
> 
> Will update amd64 laptop to main-n268827-75464941dc17 (Mar 16) and test it.
Please do so...

Best regards
Michael
> -- 
> Nuno Teixeira
> FreeBSD Committer (ports)

Re: Request for Testing: TCP RACK

[tuexen]

> On 16. Mar 2024, at 11:59, Nuno Teixeira  wrote:
> 
>>> Resuming I only need to add:
>>> 
>>> options TCPHPTS
>>> 
>>> Is this correct?
>>> 
>> 
>> Yeah, that will probably fix it.  According to a comment in
>> /usr/src/sys/netinet/tcp_hpts.c it adds a high precision timer
>> system for tcp, used by RACK and BBR.
> 
> As tuexen said, on main, loader.conf: tcp_rack_load="YES" will load
> tcphpts.ko as I am seing in my rpi4 right now.
If you load tcp_rack via kldload, tcphtps get loaded automatically.
If you load if via /boot/loader.conf, you need to have
tcphpts_load="YES"
in addition to
tcp_rack_load="YES"

Best regards
Michael
> I'm testing it and check its performance.
> 
> I will test again on my amd64 laptop and run more tests too.
> 
> 
> -- 
> Nuno Teixeira
> FreeBSD Committer (ports)

Re: Request for Testing: TCP RACK

[tuexen]

> On 16. Mar 2024, at 11:11, Nuno Teixeira  wrote:
> 
> (...)
> 
>> These entries are missing in GENERIC:
>> 
>> makeoptions WITH_EXTRA_TCP_STACKS=1
> 
> From 
> https://cgit.freebsd.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc
> WITH_EXTRA_TCP_STACKS was  dropped.
> 
>> options TCPHPTS
> 
> That's the missing option in GENERIC that could lead to my slow
> opearations problem
On main, this will be automatically loaded as a module when you
load tcp_rack.
> 
>> options TCP_RACK
> 
> Don't think I need this one as I will use kernel module instead of
> building it in kernel.
Correct.
> 
> Resuming I only need to add:
> 
> options TCPHPTS
> 
> Is this correct?
No. Not on main.

Best regards
Michael
> 
> Thanks,
> 
> -- 
> Nuno Teixeira
> FreeBSD Committer (ports)

Re: Request for Testing: TCP RACK

[tuexen]

> On 16. Mar 2024, at 08:57, Nuno Teixeira  wrote:
> 
> Hello all,
> 
> On a laptop i7/16MB ram, desktop use and port testing (poudriere) I've
> noticed that all operations on OS was increased by 3 to 5 times
> longer.
> examples:
> - firefox took way long time to open
> - poudriere testport tooked up to 3 times longer to finished
How did you enable the RACK stack? Does the poudriere involve
network interaction?

Best regards
Michael
> 
> make.conf:
> KERNCONF=GENERIC-NODEBUG
> src.conf:
> WITH_MALLOC_PRODUCTION=yes
> 
> tested on main-n268800-6a6ec90681cf
> 
> Thanks,
> 
>  escreveu (quinta, 14/03/2024 à(s) 10:51):
>> 
>>> On 14. Mar 2024, at 11:04, Dag-Erling Smørgrav  wrote:
>>> 
>>> tue...@freebsd.org writes:
 Gary Jennejohn  writes:
> In the article we have option TCPHPTS and option TCP_RACK.  But in
> /sys/conf/NOTES we have options TCPHPTS and options TCP_RACK and
> not option.
 Thanks for reporting, that is a typo in the article. It should
 always read options instead of option.
>>> 
>>> It's not a typo, both spellings work, cf. config(5).
>> Thank you very much for the hint. I did not know this. I wrote
>> option in the article (for whatever reason) and tested the
>> configs using options...
>> 
>> Best regards
>> Michael
>>> 
>>> DES
>>> --
>>> Dag-Erling Smørgrav - d...@freebsd.org
>> 
> 
> 
> -- 
> Nuno Teixeira
> FreeBSD Committer (ports)

Re: Request for Testing: TCP RACK

[tuexen]

> On 14. Mar 2024, at 11:04, Dag-Erling Smørgrav  wrote:
> 
> tue...@freebsd.org writes:
>> Gary Jennejohn  writes:
>>> In the article we have option TCPHPTS and option TCP_RACK.  But in
>>> /sys/conf/NOTES we have options TCPHPTS and options TCP_RACK and
>>> not option.
>> Thanks for reporting, that is a typo in the article. It should
>> always read options instead of option.
> 
> It's not a typo, both spellings work, cf. config(5).
Thank you very much for the hint. I did not know this. I wrote
option in the article (for whatever reason) and tested the
configs using options...

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

Re: Request for Testing: TCP RACK

[tuexen]

> On 13. Mar 2024, at 08:06, Gary Jennejohn  wrote:
> 
> On Tue, 12 Mar 2024 20:14:17 +0100
> tue...@freebsd.org wrote:
> 
>>> On 12. Mar 2024, at 14:39, Nuno Teixeira  wrote:
>>> 
>>> Hello,
>>> 
>>> I'm curious about tcp RACK.
>>> 
>>> As I do not run on a server background, only a laptop and a rpi4 for
>>> poudriere, git, browsing, some torrent and ssh/sftp connections, will
>>> I see any difference using RACK?
>>> What tests should I do for comparison?
>> You might want to read the following article in the FreeBSD Journal:
>> https://freebsdfoundation.org/our-work/journal/browser-based-edition/rack-and-alternate-tcp-stacks-for-freebsd/
>> 
>> There is no specific area for testing. Just test the stack on
>> the systems you use with the workload you use and report back
>> any issues...
>> 
> 
> In the article we have option TCPHPTS and option TCP_RACK.  But in
> /sys/conf/NOTES we have options TCPHPTS and options TCP_RACK and
> not option.
Thanks for reporting, that is a typo in the article. It should
always read options instead of option.

Best regards
Michael
> 
> --
> Gary Jennejohn

Re: Request for Testing: TCP RACK

[tuexen]

> On 12. Mar 2024, at 14:39, Nuno Teixeira  wrote:
> 
> Hello,
> 
> I'm curious about tcp RACK.
> 
> As I do not run on a server background, only a laptop and a rpi4 for
> poudriere, git, browsing, some torrent and ssh/sftp connections, will
> I see any difference using RACK?
> What tests should I do for comparison?
You might want to read the following article in the FreeBSD Journal:
https://freebsdfoundation.org/our-work/journal/browser-based-edition/rack-and-alternate-tcp-stacks-for-freebsd/

There is no specific area for testing. Just test the stack on
the systems you use with the workload you use and report back
any issues...

Best regards
Michael
> 
> Thanks,
> 
>  escreveu (quinta, 16/11/2023 à(s) 15:10):
>> 
>> Dear all,
>> 
>> recently the main branch was changed to build the TCP RACK stack
>> which is a loadable kernel module, by default:
>> https://cgit.FreeBSD.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc
>> 
>> As discussed on the bi-weekly transport call, it would be great if people
>> could test the RACK stack for their workload. Please report any problems to 
>> the
>> net@ mailing list or open an issue in the bug tracker and drop me a note via 
>> email.
>> This includes regressions in CPU usage, regressions in performance or any 
>> other
>> unexpected change you observe.
>> 
>> You can load the kernel module using
>> kldload tcp_rack
>> 
>> You can make the RACK stack the default stack using
>> sysctl net.inet.tcp.functions_default=rack
>> 
>> Based on the feedback we get, the default stack might be switched to the
>> RACK stack.
>> 
>> Please let me know if you have any questions.
>> 
>> Best regards
>> Michael
>> 
>> 
>> 
> 
> 
> -- 
> Nuno Teixeira
> FreeBSD Committer (ports)

Re: kernel crash in tcp_subr.c:2386

[tuexen]

> On Feb 12, 2024, at 10:36, Alexander Leidinger  
> wrote:
> 
> Hi,
> 
> I got a coredump with sources from 2024-02-10-144617 (GMT+0100):
Hi Alexander,

we are aware of this problem, but haven't found a way to reproduce it.
Do you know how to reproduce this?

Best regards
Michael
> ---snip---
> __curthread () at /space/system/usr_src/sys/amd64/include/pcpu_aux.h:57
> 57  __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct 
> pcpu,
> (kgdb) #0  __curthread () at 
> /space/system/usr_src/sys/amd64/include/pcpu_aux.h:57
>td = 
> #1  doadump (textdump=textdump@entry=1)
>at /space/system/usr_src/sys/kern/kern_shutdown.c:403
>error = 0
>coredump = 
> #2  0x8052fe85 in kern_reboot (howto=260)
>at /space/system/usr_src/sys/kern/kern_shutdown.c:521
>once = 0
>__pc = 
> #3  0x80530382 in vpanic (
>fmt=0x808df476 "Assertion %s failed at %s:%d",
>ap=ap@entry=0xfe08a079ebf0)
>at /space/system/usr_src/sys/kern/kern_shutdownc:973
>buf = "Assertion !callout_active(>t_callout) failed at 
> /space/system/usr_src/sys/netinet/tcp_subr.c:2386", '\000' 
>__pc = 
>__pc = 
>__pc = 
>other_cpus = {__bits = {14680063, 0 }}
>td = 0xf8068ef99740
>bootopt = 
>newpanic = 
> #4  0x805301d3 in panic (fmt=)
>at /space/system/usr_src/sys/kern/kern_shutdown.c:889
>ap = {{gp_offset = 32, fp_offset = 48,
>overflow_arg_area = 0xfe08a079ec20,
>reg_save_area = 0xfe08a079ebc0}}
> #5  0x806c9d8c in tcp_discardcb (tp=tp@entry=0xf80af441ba80)
>at /space/system/usr_src/sys/netinet/tcp_subr.c:2386
>inp = 0xf80af441ba80
>so = 0xf804d23d2780
>m = 
>isipv6 = 
> #6  0x806d6291 in tcp_usr_detach (so=0xf804d23d2780)
>at /space/system/usr_src/sys/netinet/tcp_usrreq.c:214
>inp = 0xf80af441ba80
>tp = 0xf80af441ba80
> #7  0x805dba57 in sofree (so=0xf804d23d2780)
>at /space/system/usr_src/sys/kern/uipc_socket.c:1205
>pr = 0x80a8bd18 
> #8  sorele_locked (so=so@entry=0xf804d23d2780)
>at /space/system/usr_src/sys/kern/uipc_socket.c:1232
> No locals.
> #9  0x805dc8c0 in soclose (so=0xf804d23d2780)
>at /space/system/usr_src/sys/kern/uipc_socket.c:1302
>lqueue = {tqh_first = 0xf8068ef99740,
>  tqh_last = 0xfe08a079ed40}
>error = 0
>saved_vnet = 0x0
>last = 
>listening = 
> #10 0x804ccbd1 in fo_close (fp=0xf805f2dfc500, td=)
>at /space/system/usr_src/sys/sys/file.h:390
> No locals.
> #11 _fdrop (fp=fp@entry=0xf805f2dfc500, td=,
>td@entry=0xf8068ef99740)
>at /space/system/usr_src/sys/kern/kern_descrip.c:3666
>count = 
>error = 
> #12 0x804d02f3 in closef (fp=fp@entry=0xf805f2dfc500,
>td=td@entry=0xf8068ef99740)
>at /space/system/usr_src/sys/kern/kern_descrip.c:2839
>_error = 0
>_fp = 0xf805f2dfc500
>lf = {l_start = -8791759350504, l_len = -8791759350528, l_pid = 0,
>  l_type = 0, l_whence = 0, l_sysid = 0}
>vp = 
>fdtol = 
>fdp = 
> #13 0x804cd50c in closefp_impl (fdp=0xfe07afebf860, fd=19,
>fp=0xf805f2dfc500, td=0xf8068ef99740, audit=)
>at /space/system/usr_src/sys/kern/kern_descrip.c:1315
>error = 
> #14 closefp (fdp=0xfe07afebf860, fd=19, fp=0xf805f2dfc500,
>td=0xf8068ef99740, holdleaders=true, audit=)
>at /space/system/usr_src/sys/kern/kern_descrip.c:1372
> No locals.
> #15 0x808597d6 in syscallenter (td=0xf8068ef99740)
>at /space/system/usr_src/sys/amd64/amd64/../../kern/subr_syscall.c:186
>se = 0x80a48330 
>p = 0xfe07f29995c0
>sa = 0xf8068ef99b30
>error = 
>sy_thr_static = 
>traced = 
> #16 amd64_syscall (td=0xf8068ef99740, traced=0)
>at /space/system/usr_src/sys/amd64/amd64/trap.c:1192
>ksi = {ksi_link = {tqe_next = 0xfe08a079ef30,
>tqe_prev = 0x808588af }, ksi_info = {
>si_signo = 1, si_errno = 0, si_code = 2015268872, si_pid = -512,
>si_uid = 2398721856, si_status = -2042,
>si_addr = 0xfe08a079ef40, si_value = {sival_int = -1602621824,
>  sival_ptr = 0xfe08a079ee80, sigval_int = -1602621824,
>  sigval_ptr = 0xfe08a079ee80}, _reason = {_fault = {
>_trapno = 1489045984}, _timer = {_timerid = 1489045984,
>_overrun = 17999}, _mesgq = {_mqd = 1489045984}, _poll = {
>_band = 77306605406688}, _capsicum = {_syscall = 1489045984},
>  __spare__ = {__spare1__ = 77306605406688, __spare2__ = {
>  1489814048, 17999, 208, 0, 0, 0, 992191072,
>  ksi_flags = 975329968, ksi_sigq = 

Re: Request for Testing: TCP RACK

[tuexen]

> On Jan 5, 2024, at 08:48, tue...@freebsd.org wrote:
> 
>> On Jan 4, 2024, at 21:39, Herbert J. Skuhra  wrote:
>> 
>> On Thu, 04 Jan 2024 21:22:22 +0100, tue...@freebsd.org wrote:
>>> 
 On Jan 4, 2024, at 18:52, Herbert J. Skuhra  wrote:
 
 On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote:
> 
> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
>> 
>> Hi,
>> 
>> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
>>> 
 On Nov 16, 2023, at 20:06, Herbert J. Skuhra  wrote:
 
 On Thu, 16 Nov 2023 19:07:29 +0100, Olivier Cochard-Labbé wrote:
> 
> On Thu, Nov 16, 2023 at 5:10 PM Herbert J. Skuhra  
> wrote:
> 
>> 
>> OK, I am now running GENERIC-NODEBUG + "options TCPHPTS".
>> 
>> After setting "sysctl net.inet.tcp.functions_default=rack" git no
>> longer works:
>> 
>> 
> Are you using a fresh 15 head or a specific network setup ?
> 
> Because I'm not able to reproduce your problem on my system:
> 
> $ uname -a
> FreeBSD bigone 15.0-CURRENT FreeBSD 15.0-CURRENT #0
> main-n266452-070d9e3540e6: Thu Nov 16 17:53:15 CET 2023
> root@bigone:/usr/obj/usr/src/amd64.amd64/sys/TCPHPTS
> amd64
> $ cat /usr/src/sys/amd64/conf/TCPHPTS
> include GENERIC-NODEBUG
> ident   TCPHPTS
> options TCPHPTS
> $ sysctl net.inet.tcp.functions_default
> net.inet.tcp.functions_default: rack
> $ git clone -q g...@github.com:freebsd/freebsd-src.git && echo working
> working
> $
 
 OK, (g)it works if I disable pf. Do you use pf?
>>> Can you share your pf config such that I can reproduce the problem 
>>> locally?
>> 
>> 1. It even fails with a simple pf.conf:
>> pass in all
>> pass out all
>> 
>> 2. Fetching port distfiles also failed.
>> 
>> 3. If I disable rxcsum on the ethernet adapter (igb0) it works.
> 
> Disabling lro also resolves the issue.
 
 If I run "sysctl net.inet.tcp.rack.features.cmpack=0" I don't have to
 disable rxcsum/tcxsum or lro on igb0.
>>> Does the problem also goes away if you disable pf completely, but keep
>>> compressed acks enabled?
>> 
>> Yes, it works with pf disabled and compressed acks enabled.
> Thanks for the information!
A patch is available at:
https://reviews.freebsd.org/D43769

Best regards
Michael
> 
> Best regards
> Michael
>> 
>> --
>> Herbert
> 
> 

Re: Request for Testing: TCP RACK

[tuexen]

> On Jan 4, 2024, at 21:39, Herbert J. Skuhra  wrote:
> 
> On Thu, 04 Jan 2024 21:22:22 +0100, tue...@freebsd.org wrote:
>> 
>>> On Jan 4, 2024, at 18:52, Herbert J. Skuhra  wrote:
>>> 
>>> On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote:
 
 On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
> 
> Hi,
> 
> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
>> 
>>> On Nov 16, 2023, at 20:06, Herbert J. Skuhra  wrote:
>>> 
>>> On Thu, 16 Nov 2023 19:07:29 +0100, Olivier Cochard-Labbé wrote:
 
 On Thu, Nov 16, 2023 at 5:10 PM Herbert J. Skuhra  
 wrote:
 
> 
> OK, I am now running GENERIC-NODEBUG + "options TCPHPTS".
> 
> After setting "sysctl net.inet.tcp.functions_default=rack" git no
> longer works:
> 
> 
 Are you using a fresh 15 head or a specific network setup ?
 
 Because I'm not able to reproduce your problem on my system:
 
 $ uname -a
 FreeBSD bigone 15.0-CURRENT FreeBSD 15.0-CURRENT #0
 main-n266452-070d9e3540e6: Thu Nov 16 17:53:15 CET 2023
 root@bigone:/usr/obj/usr/src/amd64.amd64/sys/TCPHPTS
 amd64
 $ cat /usr/src/sys/amd64/conf/TCPHPTS
 include GENERIC-NODEBUG
 ident   TCPHPTS
 options TCPHPTS
 $ sysctl net.inet.tcp.functions_default
 net.inet.tcp.functions_default: rack
 $ git clone -q g...@github.com:freebsd/freebsd-src.git && echo working
 working
 $
>>> 
>>> OK, (g)it works if I disable pf. Do you use pf?
>> Can you share your pf config such that I can reproduce the problem 
>> locally?
> 
> 1. It even fails with a simple pf.conf:
> pass in all
> pass out all
> 
> 2. Fetching port distfiles also failed.
> 
> 3. If I disable rxcsum on the ethernet adapter (igb0) it works.
 
 Disabling lro also resolves the issue.
>>> 
>>> If I run "sysctl net.inet.tcp.rack.features.cmpack=0" I don't have to
>>> disable rxcsum/tcxsum or lro on igb0.
>> Does the problem also goes away if you disable pf completely, but keep
>> compressed acks enabled?
> 
> Yes, it works with pf disabled and compressed acks enabled.
Thanks for the information!

Best regards
Michael
> 
> --
> Herbert

Re: Request for Testing: TCP RACK

[tuexen]

> On Jan 4, 2024, at 18:52, Herbert J. Skuhra  wrote:
> 
> On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote:
>> 
>> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
>>> 
>>> Hi,
>>> 
>>> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
 
> On Nov 16, 2023, at 20:06, Herbert J. Skuhra  wrote:
> 
> On Thu, 16 Nov 2023 19:07:29 +0100, Olivier Cochard-Labbé wrote:
>> 
>> On Thu, Nov 16, 2023 at 5:10 PM Herbert J. Skuhra  
>> wrote:
>> 
>>> 
>>> OK, I am now running GENERIC-NODEBUG + "options TCPHPTS".
>>> 
>>> After setting "sysctl net.inet.tcp.functions_default=rack" git no
>>> longer works:
>>> 
>>> 
>> Are you using a fresh 15 head or a specific network setup ?
>> 
>> Because I'm not able to reproduce your problem on my system:
>> 
>> $ uname -a
>> FreeBSD bigone 15.0-CURRENT FreeBSD 15.0-CURRENT #0
>> main-n266452-070d9e3540e6: Thu Nov 16 17:53:15 CET 2023
>> root@bigone:/usr/obj/usr/src/amd64.amd64/sys/TCPHPTS
>> amd64
>> $ cat /usr/src/sys/amd64/conf/TCPHPTS
>> include GENERIC-NODEBUG
>> ident   TCPHPTS
>> options TCPHPTS
>> $ sysctl net.inet.tcp.functions_default
>> net.inet.tcp.functions_default: rack
>> $ git clone -q g...@github.com:freebsd/freebsd-src.git && echo working
>> working
>> $
> 
> OK, (g)it works if I disable pf. Do you use pf?
 Can you share your pf config such that I can reproduce the problem locally?
>>> 
>>> 1. It even fails with a simple pf.conf:
>>>  pass in all
>>>  pass out all
>>> 
>>> 2. Fetching port distfiles also failed.
>>> 
>>> 3. If I disable rxcsum on the ethernet adapter (igb0) it works.
>> 
>> Disabling lro also resolves the issue.
> 
> If I run "sysctl net.inet.tcp.rack.features.cmpack=0" I don't have to
> disable rxcsum/tcxsum or lro on igb0.
Does the problem also goes away if you disable pf completely, but keep
compressed acks enabled?

Best regards
Michael
> 
> --
> Herbert
> 

Re: Request for Testing: TCP RACK

[tuexen]

> On Jan 4, 2024, at 15:22, Herbert J. Skuhra  wrote:
> 
> On Thu, 04 Jan 2024 14:57:59 +0100, tue...@fh-muenster.de wrote:
>> 
>>> On Jan 4, 2024, at 11:40, Herbert J. Skuhra  wrote:
>>> 
>>> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
 
 Hi,
 
 On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
> 
>> On Nov 16, 2023, at 20:06, Herbert J. Skuhra  wrote:
>> 
>> On Thu, 16 Nov 2023 19:07:29 +0100, Olivier Cochard-Labbé wrote:
>>> 
>>> On Thu, Nov 16, 2023 at 5:10 PM Herbert J. Skuhra  
>>> wrote:
>>> 
 
 OK, I am now running GENERIC-NODEBUG + "options TCPHPTS".
 
 After setting "sysctl net.inet.tcp.functions_default=rack" git no
 longer works:
 
 
>>> Are you using a fresh 15 head or a specific network setup ?
>>> 
>>> Because I'm not able to reproduce your problem on my system:
>>> 
>>> $ uname -a
>>> FreeBSD bigone 15.0-CURRENT FreeBSD 15.0-CURRENT #0
>>> main-n266452-070d9e3540e6: Thu Nov 16 17:53:15 CET 2023
>>> root@bigone:/usr/obj/usr/src/amd64.amd64/sys/TCPHPTS
>>> amd64
>>> $ cat /usr/src/sys/amd64/conf/TCPHPTS
>>> include GENERIC-NODEBUG
>>> ident   TCPHPTS
>>> options TCPHPTS
>>> $ sysctl net.inet.tcp.functions_default
>>> net.inet.tcp.functions_default: rack
>>> $ git clone -q g...@github.com:freebsd/freebsd-src.git && echo working
>>> working
>>> $
>> 
>> OK, (g)it works if I disable pf. Do you use pf?
> Can you share your pf config such that I can reproduce the problem 
> locally?
 
 1. It even fails with a simple pf.conf:
 pass in all
 pass out all
 
 2. Fetching port distfiles also failed.
 
 3. If I disable rxcsum on the ethernet adapter (igb0) it works.
>>> 
>>> Disabling lro also resolves the issue.
>>> 
>>> Not OK:
>>> 
>>> igb0: flags=1008843 metric 
>>> 0 mtu 1500
>>>  
>>> options=4e527bb
>>> 
>>> OK:
>>> 
>>> igb0: flags=1008843 metric 
>>> 0 mtu 1500
>>>  
>>> options=4e523bb
>> What kind of NIC do you have? Can you post the output of
>> dmesg | grep igb0
> 
> igb0:  port 0xf000-0xf01f mem 
> 0xfc20-0xfc27,0xfc28-0xfc283fff irq 28 at device 0.0 on pci3
> igb0: EEPROM V3.16-0 eTrack 0x84d6
> igb0: Using 1024 TX descriptors and 1024 RX descriptors
> igb0: Using 4 RX queues 4 TX queues
> igb0: Using MSI-X interrupts with 5 vectors
> igb0: Ethernet address: aa:bb:cc:dd:ee:ff
> igb0: netmap queues/slots: TX 4/1024, RX 4/1024
> igb0: link state changed to UP
> igb0: link state changed to DOWN
> igb0: link state changed to UP
Hi Herbert,

thank you very much. I'll see if I have such a NIC in one of my test systems 
and will report back.

Best regards
Michael
> 
> --
> Herbert
> 

Re: Request for Testing: TCP RACK

[tuexen]

> On Jan 4, 2024, at 11:40, Herbert J. Skuhra  wrote:
> 
> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
>> 
>> Hi,
>> 
>> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
>>> 
 On Nov 16, 2023, at 20:06, Herbert J. Skuhra  wrote:
 
 On Thu, 16 Nov 2023 19:07:29 +0100, Olivier Cochard-Labbé wrote:
> 
> On Thu, Nov 16, 2023 at 5:10 PM Herbert J. Skuhra  
> wrote:
> 
>> 
>> OK, I am now running GENERIC-NODEBUG + "options TCPHPTS".
>> 
>> After setting "sysctl net.inet.tcp.functions_default=rack" git no
>> longer works:
>> 
>> 
> Are you using a fresh 15 head or a specific network setup ?
> 
> Because I'm not able to reproduce your problem on my system:
> 
> $ uname -a
> FreeBSD bigone 15.0-CURRENT FreeBSD 15.0-CURRENT #0
> main-n266452-070d9e3540e6: Thu Nov 16 17:53:15 CET 2023
> root@bigone:/usr/obj/usr/src/amd64.amd64/sys/TCPHPTS
> amd64
> $ cat /usr/src/sys/amd64/conf/TCPHPTS
> include GENERIC-NODEBUG
> ident   TCPHPTS
> options TCPHPTS
> $ sysctl net.inet.tcp.functions_default
> net.inet.tcp.functions_default: rack
> $ git clone -q g...@github.com:freebsd/freebsd-src.git && echo working
> working
> $
 
 OK, (g)it works if I disable pf. Do you use pf?
>>> Can you share your pf config such that I can reproduce the problem locally?
>> 
>> 1. It even fails with a simple pf.conf:
>> pass in all
>> pass out all
>> 
>> 2. Fetching port distfiles also failed.
>> 
>> 3. If I disable rxcsum on the ethernet adapter (igb0) it works.
> 
> Disabling lro also resolves the issue.
> 
> Not OK:
> 
> igb0: flags=1008843 metric 0 
> mtu 1500
>  
> options=4e527bb
> 
> OK:
> 
> igb0: flags=1008843 metric 0 
> mtu 1500
>  
> options=4e523bb
What kind of NIC do you have? Can you post the output of
dmesg | grep igb0

Best regards
Michael
> 
> --
> Herbert
> 

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

[tuexen]

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

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

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

[tuexen]

> On Dec 29, 2023, at 14:07, Konstantin Belousov  wrote:
> 
> On Fri, Dec 29, 2023 at 01:50:34PM +0100, Dimitry Andric wrote:
>> The problem is really that our kernel headers (those under sys/) require 
>> C99. The only thing that 
>> https://cgit.freebsd.org/src/commit/?id=a8b70cf26030d68631200619bd1b0ad35b34b6b8
>>  did was move two static inline functions from sys/netinet/tcp_var.h to 
>> sys/netinet/tcp.h, and it looks like the former header is never directly 
>> included by ports. The latter is, so those ports should be switched to C99, 
>> or the sys/netinet/tcp.h header should be fixed to use __inline instead.
>> 
> netinet/tcp.h is required by POSIX, and as far as we support applications
> using C89, it must stay C89 compatible.
> 
> But why userspace would need these newish accessors at all?  IMO at least
TCP is now using flags that are not contained in the th_flags field anymore,
but also use the th_x2 field.

People were assuming that all flags are in th_flags and th_x2 is not used and
used it for internal processing. This was causing problems.

Using the accessor functions hides the split between th_flags and th_x2.
See, for example,
https://cgit.FreeBSD.org/src/commit/?id=a8b70cf26030d68631200619bd1b0ad35b34b6b8
 

> for userspace they do not add any value except additional namespace pollution.
> They should be hidden under #ifdef _KERNEL.
That might be possible. A kernel build with this completes. Haven't checked a
buildlworld. Will report when its done.

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

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

[tuexen]

> On Dec 29, 2023, at 13:50, Dimitry Andric  wrote:
> 
> The problem is really that our kernel headers (those under sys/) require C99. 
> The only thing that 
> https://cgit.freebsd.org/src/commit/?id=a8b70cf26030d68631200619bd1b0ad35b34b6b8
>  did was move two static inline functions from sys/netinet/tcp_var.h to 
> sys/netinet/tcp.h, and it looks like the former header is never directly 
> included by ports. The latter is, so those ports should be switched to C99, 
> or the sys/netinet/tcp.h header should be fixed to use __inline instead.
Any preferred way? Maybe using __inline is the least intrusive way:
https://reviews.freebsd.org/D43231

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

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

[tuexen]

> On Dec 29, 2023, at 13:50, Dimitry Andric  wrote:
> 
> The problem is really that our kernel headers (those under sys/) require C99. 
> The only thing that 
> https://cgit.freebsd.org/src/commit/?id=a8b70cf26030d68631200619bd1b0ad35b34b6b8
>  did was move two static inline functions from sys/netinet/tcp_var.h to 
> sys/netinet/tcp.h, and it looks like the former header is never directly 
> included by ports. The latter is, so those ports should be switched to C99, 
> or the sys/netinet/tcp.h header should be fixed to use __inline instead.
Any preferred way? Maybe using __inline is the least intrusive way:
https://reviews.freebsd.org/D43231

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

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

[tuexen]

> On Dec 29, 2023, at 10:18, Nuno Teixeira  wrote:
> 
> Hello all,
> 
> From 157 to 158 devel/nspr (dependency of firefox) fails:
> 
> ###
> cc -o prmapopt.o -c -fvisibility=hidden-O2 -pipe  
> -fstack-protector-strong -fno-strict-aliasing   -ansi -Wall -fPIC  -UDEBUG 
> -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" 
> -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DNDEBUG=1 
> -DHAVE_VISIBILITY_HIDDEN_ATTRIBUTE=1 -DHAVE_VISIBILITY_PRAGMA=1 -DXP_UNIX=1 
> -DFREEBSD=1 -DHAVE_BSD_FLOCK=1 -DHAVE_SOCKLEN_T=1 
> -DHAVE_POINTER_LOCALTIME_R=1 -DHAVE_DLADDR=1 -DHAVE_LCHOWN=1 
> -DHAVE_SETPRIORITY=1 -DHAVE_STRERROR=1 -DHAVE_SYSCALL=1 
> -DHAVE_SECURE_GETENV=1 -D_REENTRANT=1 -D_THREAD_SAFE=1 -DFORCE_PR_LOG 
> -D_PR_PTHREADS -UHAVE_CVAR_BUILT_ON_SEM -D_NSPR_BUILD_ 
> -I../../../dist/include/nspr -I./../../pr/include 
> -I../../../pr/include/private  prmapopt.c
> In file included from prmapopt.c:46:
> /usr/include/netinet/tcp.h:82:8: error: unknown type name 'inline'
>   82 | static inline uint16_t
>  |^
> /usr/include/netinet/tcp.h:82:23: error: expected ';' after top level 
> declarator
>   82 | static inline uint16_t
>  |   ^
> /usr/include/netinet/tcp.h:88:8: error: unknown type name 'inline'
>   88 | static inline void
>  |^
> 3 errors generated.
> ###
> 
> Any clues?
You are compiling with -ansi, which means C89. C89 does not support inline.
I think support for inline was added in C99.

I think we have two options:
1. Build the ports with a C version of at least C99.
2. Remove the inline from tcp_[gs]et_flags().

Best regards
Michael
> -- 
> Nuno Teixeira
> FreeBSD Committer (ports)

Re: Problem building kernel

[tuexen]

> On Dec 24, 2023, at 19:31, Justin Hibbits  wrote:
> 
> Hi Michael,
> 
> The GENERIC config is for 32-bit powerpc, GENERIC64 is what you want
> for 64-bit config.
Hi Justin,

thanks a lot! That was the problem.

Best regards
Michael
> 
> - Justin
> 
> On Sun, 24 Dec 2023 12:18:55 +0100
> tue...@freebsd.org wrote:
> 
>> Dear all,
>> 
>> I just tried to build world and kernel on a 64-bit PPC system.
>> 
>> make -j 32 buildworld
>> 
>> ran without problems.
>> However
>> 
>> make kernel KERNCONF=GENERIC
>> 
>> breaks with
>> ..
>> --- all_subdir_accf_data ---
>> --- accf_data.kld ---
>> ld -m elf32ppc_fbsd -warn-common --build-id=sha1 --no-toc-optimize
>> -r  -o accf_data.kld accf_data.o --- all_subdir_acl_nfs4 ---
>> --- offset.inc ---
>> sh /usr/home/tuexen/freebsd-src/sys/kern/genoffset.sh genoffset.o >
>> offset.inc --- all_subdir_accf_data ---
>> ld: error: accf_data.o is incompatible with elf32ppc_fbsd
>> *** [accf_data.kld] Error code 1
>> 
>> make[4]: stopped in /usr/home/tuexen/freebsd-src/sys/modules/accf_data
>>  5.79 real22.37 user15.35 sys
>> 
>> make[1]: stopped in /usr/home/tuexen/freebsd-src
>> 
>> make: stopped in /usr/home/tuexen/freebsd-src
>> tuexen@blackbird:
>> 
>> Any idea what is going wrong?
>> 
>> Best regards
>> Michael
> 

Re: Problem building kernel

[tuexen]

> On Dec 24, 2023, at 12:27, Vladimir Kondratyev  wrote:
> 
> On 24.12.2023 14:18, tue...@freebsd.org wrote:
>> Dear all,
>> I just tried to build world and kernel on a 64-bit PPC system.
>> make -j 32 buildworld
>> ran without problems.
>> However
>> make kernel KERNCONF=GENERIC
>> breaks with
>> ..
>> --- all_subdir_accf_data ---
>> --- accf_data.kld ---
>> ld -m elf32ppc_fbsd -warn-common --build-id=sha1 --no-toc-optimize  -r  -o 
>> accf_data.kld accf_data.o
>> --- all_subdir_acl_nfs4 ---
>> --- offset.inc ---
>> sh /usr/home/tuexen/freebsd-src/sys/kern/genoffset.sh genoffset.o > 
>> offset.inc
>> --- all_subdir_accf_data ---
>> ld: error: accf_data.o is incompatible with elf32ppc_fbsd
>> *** [accf_data.kld] Error code 1
>> make[4]: stopped in /usr/home/tuexen/freebsd-src/sys/modules/accf_data
>>   5.79 real    22.37 user15.35 sys
>> make[1]: stopped in /usr/home/tuexen/freebsd-src
>> make: stopped in /usr/home/tuexen/freebsd-src
>> tuexen@blackbird:
>> Any idea what is going wrong?
>> Best regards
>> Michael
> 
> Latest LKPI changes broke 32 bit archs and powerpc.
> 
> I am going to fix them. Sorry for breakage.
No problem. If you want me to test a fix, drop me an e-mail.

Best regards
Michael
> 
> -- 
> WBR
> Vladimir Kondratyev
> 
> 

Problem building kernel

[tuexen]

Dear all,

I just tried to build world and kernel on a 64-bit PPC system.

make -j 32 buildworld

ran without problems.
However

make kernel KERNCONF=GENERIC

breaks with
..
--- all_subdir_accf_data ---
--- accf_data.kld ---
ld -m elf32ppc_fbsd -warn-common --build-id=sha1 --no-toc-optimize  -r  -o 
accf_data.kld accf_data.o
--- all_subdir_acl_nfs4 ---
--- offset.inc ---
sh /usr/home/tuexen/freebsd-src/sys/kern/genoffset.sh genoffset.o > offset.inc
--- all_subdir_accf_data ---
ld: error: accf_data.o is incompatible with elf32ppc_fbsd
*** [accf_data.kld] Error code 1

make[4]: stopped in /usr/home/tuexen/freebsd-src/sys/modules/accf_data
   5.79 real22.37 user15.35 sys

make[1]: stopped in /usr/home/tuexen/freebsd-src

make: stopped in /usr/home/tuexen/freebsd-src
tuexen@blackbird:

Any idea what is going wrong?

Best regards
Michael

Re: Request for Testing: TCP RACK

[tuexen]

> On Nov 18, 2023, at 00:37, Tomoaki AOKI  wrote:
> 
> On Fri, 17 Nov 2023 18:51:05 +0100
> tue...@freebsd.org wrote:
> 
>>> On Nov 17, 2023, at 17:06, Johan Hendriks  wrote:
>>> 
>>> I am running the rack stack for quiet some time now on a baremetal machiene 
>>> and never had problems.
>>> Also use pf.  This is a test machine so not a lot happening on it.
>>> 
>>> Are there any thing we can test? Do we have some test scripts we can run?
>> We are actually interested in feedback about using the stack in whatever
>> use case you use TCP for. The stack has been tested with the Netflix use
>> case, but not so much with others. That is why we ask for broader testing.
>> 
>> Best regards
>> Michael
> 
> Are there any difference regarding with performance between main and
> stable/14? If so, please ignore below.
> 
> I have stable/14 environment which is configured to be able to switch
> to TCP RACK and experienced huge performance loss when writing
> a large file to smbfs share on commercial NAS. CC is cubic.
> Testing large archive on the smbfs share doesn't seem to be
> affected.
> 
> Comparison between default (freebsd) and rack TCP stack using
> sysutils/clone on stable/14 at commit 7d1321288ad9, amd64.
> Last 3 lines of outputs from clone (upload to NAS) are shown.
Thank you very much for testing. This is what we are looking
for. Would it be possible to repeat the test using NewReno as
the CC?

Best regards
Michael
> 
> Before switching to rack:
> 1 item copied, 2342.4 MB in 39.12 s -- 59.9 MB/s
> Leaked memory: 0 bytes
> No errors occured.
> 
> Unmount the smbfs share, switch to rack, and after remount:
> 1 item copied, 2342.4 MB in 926.59 s -- 2.5 MB/s
> Leaked memory: 0 bytes
> No errors occured.
> 
> Switch back to freebsd (default) without unmounting:
> 1 item copied, 2342.4 MB in 906.94 s -- 2.6 MB/s
> Leaked memory: 0 bytes
> No errors occured.
> 
> Unmount and remount the smbfs share:
> 1 item copied, 2342.4 MB in 39.12 s -- 59.9 MB/s
> Leaked memory: 0 bytes
> No errors occured.
> 
> 
> Regards.
> 
> -- 
> Tomoaki AOKI

Re: Request for Testing: TCP RACK

[tuexen]

> On Nov 17, 2023, at 17:06, Johan Hendriks  wrote:
> 
> I am running the rack stack for quiet some time now on a baremetal machiene 
> and never had problems.
> Also use pf.  This is a test machine so not a lot happening on it.
> 
> Are there any thing we can test? Do we have some test scripts we can run?
We are actually interested in feedback about using the stack in whatever
use case you use TCP for. The stack has been tested with the Netflix use
case, but not so much with others. That is why we ask for broader testing.

Best regards
Michael
> 
> 
> 
> 

Re: Request for Testing: TCP RACK

[tuexen]

> On Nov 16, 2023, at 20:06, Herbert J. Skuhra  wrote:
> 
> On Thu, 16 Nov 2023 19:07:29 +0100, Olivier Cochard-Labbé wrote:
>> 
>> On Thu, Nov 16, 2023 at 5:10 PM Herbert J. Skuhra  wrote:
>> 
>>> 
>>> OK, I am now running GENERIC-NODEBUG + "options TCPHPTS".
>>> 
>>> After setting "sysctl net.inet.tcp.functions_default=rack" git no
>>> longer works:
>>> 
>>> 
>> Are you using a fresh 15 head or a specific network setup ?
>> 
>> Because I'm not able to reproduce your problem on my system:
>> 
>> $ uname -a
>> FreeBSD bigone 15.0-CURRENT FreeBSD 15.0-CURRENT #0
>> main-n266452-070d9e3540e6: Thu Nov 16 17:53:15 CET 2023
>> root@bigone:/usr/obj/usr/src/amd64.amd64/sys/TCPHPTS
>> amd64
>> $ cat /usr/src/sys/amd64/conf/TCPHPTS
>> include GENERIC-NODEBUG
>> ident   TCPHPTS
>> options TCPHPTS
>> $ sysctl net.inet.tcp.functions_default
>> net.inet.tcp.functions_default: rack
>> $ git clone -q g...@github.com:freebsd/freebsd-src.git && echo working
>> working
>> $
> 
> OK, (g)it works if I disable pf. Do you use pf?
Can you share your pf config such that I can reproduce the problem locally?

Best regards
Michael
> 
> --
> Herbert

Re: Request for Testing: TCP RACK

[tuexen]

> On Nov 16, 2023, at 14:05, Herbert J. Skuhra  wrote:
> 
> On Thu, 16 Nov 2023 13:06:03 +0100, "Herbert J. Skuhra" wrote:
>> 
>> Hi,
>> 
>> On Thu, 16 Nov 2023 10:13:05 +0100, tue...@freebsd.org wrote:
>>> 
>>> Dear all,
>>> 
>>> recently the main branch was changed to build the TCP RACK stack
>>> which is a loadable kernel module, by default:
>>> https://cgit.FreeBSD.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc
>>> 
>>> As discussed on the bi-weekly transport call, it would be great if people
>>> could test the RACK stack for their workload. Please report any problems to 
>>> the
>>> net@ mailing list or open an issue in the bug tracker and drop me a note 
>>> via email.
>>> This includes regressions in CPU usage, regressions in performance or any 
>>> other
>>> unexpected change you observe.
>>> 
>>> You can load the kernel module using
>>> kldload tcp_rack
>>> 
>>> You can make the RACK stack the default stack using
>>> sysctl net.inet.tcp.functions_default=rack
>>> 
>>> Based on the feedback we get, the default stack might be switched to the
>>> RACK stack.
>>> 
>>> Please let me know if you have any questions.
>> 
>> I am running main-n266450-a592812327de with a GENERIC-NODEBUG kernel.
>> 
>> # kldload tcp_rack
>> kldload: an error occurred while loading module tcp_rack. Please check
>> dmesg(8) for more details.
>> 
>> In dmesg:
>> KLD tcp_rack.ko: depends on tcphpts - not available or version mismatch
>> linker_load_file: /boot/kernel/tcp_rack.ko - unsupported file type
>> 
>> So you have to build a kernel with "options TCPHPTS" first?
> 
> OK, I am now running GENERIC-NODEBUG + "options TCPHPTS".
> 
> After setting "sysctl net.inet.tcp.functions_default=rack" git no
> longer works:
> 
> # sysctl net.inet.tcp.functions_default=rack
> $ git pull
> client_loop: send disconnect: Broken pipe
> fatal: the remote end hung up upon initial contact
> # sysctl net.inet.tcp.functions_default=freebsd
> $ git pull
> Already up to date.
Interesting. It works on my development system:
tuexen@head:~/freebsd-src % sysctl net.inet.tcp.functions_default
net.inet.tcp.functions_default: rack
tuexen@head:~/freebsd-src % git pull
Already up to date.
tuexen@head:~/freebsd-src %
Could you provide a .pcapng file covering the `git pull` command?

Best regards
Michael
> 
> --
> Herbert

Re: Request for Testing: TCP RACK

[tuexen]

> On Nov 16, 2023, at 13:06, Herbert J. Skuhra  wrote:
> 
> Hi,
> 
> On Thu, 16 Nov 2023 10:13:05 +0100, tue...@freebsd.org wrote:
>> 
>> Dear all,
>> 
>> recently the main branch was changed to build the TCP RACK stack
>> which is a loadable kernel module, by default:
>> https://cgit.FreeBSD.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc
>> 
>> As discussed on the bi-weekly transport call, it would be great if people
>> could test the RACK stack for their workload. Please report any problems to 
>> the
>> net@ mailing list or open an issue in the bug tracker and drop me a note via 
>> email.
>> This includes regressions in CPU usage, regressions in performance or any 
>> other
>> unexpected change you observe.
>> 
>> You can load the kernel module using
>> kldload tcp_rack
>> 
>> You can make the RACK stack the default stack using
>> sysctl net.inet.tcp.functions_default=rack
>> 
>> Based on the feedback we get, the default stack might be switched to the
>> RACK stack.
>> 
>> Please let me know if you have any questions.
> 
> I am running main-n266450-a592812327de with a GENERIC-NODEBUG kernel.
> 
> # kldload tcp_rack
> kldload: an error occurred while loading module tcp_rack. Please check
> dmesg(8) for more details.
> 
> In dmesg:
> KLD tcp_rack.ko: depends on tcphpts - not available or version mismatch
> linker_load_file: /boot/kernel/tcp_rack.ko - unsupported file type
> 
> So you have to build a kernel with "options TCPHPTS" first?
Hi Herbert,

yes this is correct. For whatever reason I was assuming the TCPHPTS is already
enabled in all configs, but this is not correct.

Will put up an review to do this tomorrow. Thanks for reporting.

Best regards
Michael
> 
> --
> Herbert

Request for Testing: TCP RACK

[tuexen]

Dear all,

recently the main branch was changed to build the TCP RACK stack
which is a loadable kernel module, by default:
https://cgit.FreeBSD.org/src/commit/?id=3a338c534154164504005beb00a3c6feb03756cc

As discussed on the bi-weekly transport call, it would be great if people
could test the RACK stack for their workload. Please report any problems to the
net@ mailing list or open an issue in the bug tracker and drop me a note via 
email.
This includes regressions in CPU usage, regressions in performance or any other
unexpected change you observe.

You can load the kernel module using
kldload tcp_rack

You can make the RACK stack the default stack using
sysctl net.inet.tcp.functions_default=rack

Based on the feedback we get, the default stack might be switched to the
RACK stack.

Please let me know if you have any questions.

Best regards
Michael

Re: cc_vegas isn't built in recent current

[tuexen]

> On 12. Jul 2023, at 14:42, void  wrote:
> 
> Maybe the question I need to ask before asking about this is
> "what is the best tcp algo to use in the situation where:
> 
> 1. gigabit fibre on consumer FTTP
> 2. on a freebsd host whose purpose is hosting bhyve guests"
> 
> I expected to load cc_vegas as, from what I've read, it's the
Due to a bug, cc_vegas and a couple of other cc modules were
not build when they should. This is fixed in
https://cgit.FreeBSD.org/src/commit/?id=be78a31188c530c93700396ecfdb5604a8f22fff
> best (most responsive/throughput) for the context but the
> reading materials are from 2013 i think. 
> So, what's in the opinion of the list the best algo in the context?
> 
> The second thing is that cc_vegas doesn't build. Latest sources
> are main-264125. The OS is at n264089. The kld is missing because when world 
> was built this kld obviously wasn't. I tried to build directly
> just now:
> 
> # snip
> # cd /usr/src/sys/modules/cc/cc_vegas
> # make
> Building /usr/obj/usr/src/amd64.amd64/sys/modules/cc/cc_vegas/machine
> machine -> /usr/src/sys/amd64/include
> Building /usr/obj/usr/src/amd64.amd64/sys/modules/cc/cc_vegas/x86
> x86 -> /usr/src/sys/x86/include
> Building /usr/obj/usr/src/amd64.amd64/sys/modules/cc/cc_vegas/i386
> i386 -> /usr/src/sys/i386/include
> Building /usr/obj/usr/src/amd64.amd64/sys/modules/cc/cc_vegas/opt_kern_tls.h
> Building /usr/obj/usr/src/amd64.amd64/sys/modules/cc/cc_vegas/opt_global.h
> Building /usr/obj/usr/src/amd64.amd64/sys/modules/cc/cc_vegas/cc_vegas.o
> /usr/src/sys/netinet/cc/cc_vegas.c:136:32: error: no member named 't_osd' in 
> 'struct tcpcb'
>   e_t = khelp_get_osd((ccv, t_osd), ertt_id);
>~^~
> /usr/src/sys/netinet/cc/cc_module.h:59:41: note: expanded from macro 'CCV'
>   #define CCV(ccv, what) (ccv)->ccvc.tcp->what
>   ~~~  ^
>   1 error generated.
>   *** Error code 1
> 
> Stop.
> make: stopped in /usr/src/sys/modules/cc/cc_vegas
That is another bug. I plan to fix it once I figured out how to do this 
appropriately.

Best regards
Michael
> 
> # snip
> 
> -- 
> 

Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C

[tuexen]

> On 8. Mar 2023, at 11:42, FreeBSD User  wrote:
> 
> Am Wed, 8 Mar 2023 11:28:11 +0100
> Dimitry Andric  schrieb:
> 
>> On 8 Mar 2023, at 11:19, FreeBSD User  wrote:
>> ...
>>> But I don't understand why the make environment is trying to compile a 
>>> piece of code that
>>> is disabled via "nodevice" as shown in my initial report herein:
>>> 
>>> [...]
>>> src/sys/dev/an/if_an_pci.c:143:1: error: a function definition without a 
>>> prototype is
>>> deprecated in all versions of C and is not supported in C2x
>>> [-Werror,-Wdeprecated-non-prototype]
>>> [...]  
>> 
>> The "nodevice" is for your custom kernel configuration, but as far as I
>> can see an(4) is still built as a module, see sys/modules/Makefile:
>> 
>> ...
>> .if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64"
>> _agp=   agp
>> _an=an
>> 
>> -Dimitry
>> 
> 
> Oh, I'm sorry,
> my fault in logic!
> 
> Is there a "knob" to explicitely disable that specific module from being 
> built from a point of
> view of a user like me (not touching the base build system)?
Use
WITHOUT_MODULES=an
in
/etc/make.conf

Best regards
Michael
> 
> -- 
> O. Hartmann

Re: trpt(8) to be decomissioned

[tuexen]

> On 5. Nov 2022, at 01:54, Cy Schubert  wrote:
> 
> In message , Gleb Smirnoff writes:
>>  Max,
>> 
>> the reason I want to retire it is not that it consumes 40 Kb
>> in the repository.  The reason is that knows kernel structures,
>> and fails to compile after changes to them.  So the tool that
>> nobody uses requires special care when working on TCP.  The
>> kernel headers disclose the structures for trpt (with some
>> protection with _WANT_TCPCB, though) and some software from
>> ports (not calling names!) would start use them too. Now a
>> kernel developer needs to care not only about trpt, but
>> about this software, too.
> 
> I recall when Bryan Cantrill came to one of the local hotels here to 
> announce Solaris 9, I remember him saying that Solaris truss was now an app 
> that called DTrace functions. If people feel the need for trpt-like 
> utility, would it be an idea to write it using DTrace calls? Could it be a 
> GSoC project? It would be kind of neat for a co-op student or someone to 
> get their feet wet with systems programming.
> 
> I typically use DTrace when snooping around looking for that proverbial 
> needle in a haystack. And TCPDEBUG seems to be one of those things that 
> DTrace was designed to replace.
> 
> It would be a good project to have a still in school upcoming developer to 
> work on.
That plan is to use BBLog as an replacement.

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

Re: security/clamav: /ar/run on TMPFS renders the port broken by design

[tuexen]

> On 27. Aug 2022, at 08:30, FreeBSD User  wrote:
> 
> Hello,
> 
> I'm referencing to Bug 259699 [2] and Bug 259585 [1].
> 
> Port security/clamav is without doubt for many of FreeBSD users an important 
> piece of security
> software so I assume a widespread usage.
> 
> It is also a not uncommon use case to use NanoBSD or any kind of 
> low-memory-footprint
> installation schemes in which /var/run - amongst other system folders - are 
> created at boot
> time as TMPFS and highly volatile.
> 
> In our case, the boxes running a small security appliance based upon FreeBSD 
> is rebooted every
> 24 hours and so /var/run is vanishing.
Why are you rebooting every 24 hours?

Best regards
Michael
> 
> To make the long story short:
> 
> The solution for this problem would be a check for existence and take action 
> addendum in
> precmd() routine of the rc-script as sketched in Bug 259699.
> The maintainer rejects such a workaround by arguing this would violate POLA 
> (see comment 4 in
> PR 259699 [2]. The maintainer's argument regaring to mtree's files are sound 
> to me.
> 
> The question is: how can this issue be solved?
> 
> It is really hard to always chenge our local repository and patch whenever 
> clamav has been
> patched and modified for what reason ever.
> 
> Tahanks for reading,
> 
> kind regards
> 
> O. Hartmann
> 
> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259585
> [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259699
> 
> 
> -- 
> O. Hartmann
> 

Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored

[tuexen]

> On 23. Apr 2022, at 02:24, Gleb Smirnoff  wrote:
> 
>  Michael,
> 
> On Sat, Apr 23, 2022 at 01:54:25AM +0200, Michael Tuexen wrote:
> M> > here is a patch that should help with the IPv6 problem. I'm not
> M> > yet committing it, it might be not final.
> M> 
> M> when I was looking at the code, I was also wondering if it would make
> M> more sense to check for M_LOOP.
> M> 
> M> However, isn't the rcvif wrong for the first two received packets? I
> M> would expect it always to be the loopback interface. Is that expectation
> M> wrong?
> 
> The IPv6 has a special feature of calling (ifp->if_output)(origifp, ...
> 
> I don't fully understand it, but Alexander does.
> 
> What I can observe is that it works differently for the original packet,
> its first retransmit and second retransmit. Still unclear to me why.
I consider this also strange. The three packets are identical.
So I would expect, that all of these are handled the same way.
> 
> Here is how to observe it:
> 
> dtrace
>-n 'fbt::ip6_output:entry
>{ printf("ro %p ifp %p\n", args[2], args[2]->ro_nh ? 
> args[2]->ro_nh->nh_ifp : 0); }'
>-n 'fbt::ip6_output_send:entry { printf("ifp %p origifp %p\n", args[1], 
> args[2]); }'
> 
> And you will see this:
> 
>  1  45625 ip6_output:entry ro f800122c19a0 ifp 0
>  1  22539ip6_output_send:entry ifp f800027cb800 origifp 
> f800020db000
> 
>  0  45625 ip6_output:entry ro f800122c19a0 ifp 
> f800027cb800
>  0  22539ip6_output_send:entry ifp f800027cb800 origifp 
> f800020db000
> 
>  0  45625 ip6_output:entry ro f800122c19a0 ifp 
> f800027cb800
>  0  22539ip6_output_send:entry ifp f800027cb800 origifp 
> f800027cb800
> 
> So, on packet three (second retransmit) the origifp is equal to ifp (is lo0) 
> and now
> packet passes validation. However, the more I read it, the more it seems to 
> me that
> actually packet three is incorrect and first two are correct :)
> 
> To cope with this self inflicted damage of (ifp->if_output)(origifp, IPV6 
> introduced
> M_LOOP and uses it internally. Looks like a quick solution for IPv6 is to use 
> it.
> However, I will commit it only once we got understanding why the hell a 
> second retransmit
> is different.
> 
> M> I also have an additional question:
> M> Why is this check protected by an (ia != NULL) condition? It does not make
> M> any use of ia?
> 
> It is a host protection feature, so checks only packets that are destined to 
> us.
> This allows to do basic antispoof checks for a host not equipped with any 
> firewall.
Understood. I was confused, since all other code protected by (ia != NULL) 
actually
depends on ia not being the NULL pointer.

Best regards
Michael
> 
> For a machine acting as a router better behavior is not to drop anything 
> routed
> through unless explicitly told so by a filtering policy.
> 
> -- 
> Gleb Smirnoff

Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored

[tuexen]

> On 23. Apr 2022, at 01:38, Gleb Smirnoff  wrote:
> 
> Hi Florian,
> 
> here is a patch that should help with the IPv6 problem. I'm not
> yet committing it, it might be not final.
Hi Gleb,

when I was looking at the code, I was also wondering if it would make
more sense to check for M_LOOP.

However, isn't the rcvif wrong for the first two received packets? I
would expect it always to be the loopback interface. Is that expectation
wrong?

I also have an additional question:
Why is this check protected by an (ia != NULL) condition? It does not make
any use of ia?

Best regards
Michael
> -- 
> Gleb Smirnoff
> 

Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored

[tuexen]

> On 16. Apr 2022, at 00:05, tue...@freebsd.org wrote:
> 
>> On 15. Apr 2022, at 23:39, Florian Smeets  wrote:
>> 
>> On 15.04.22 21:24, tue...@freebsd.org wrote:
 On 15. Apr 2022, at 20:20, Florian Smeets  wrote:
 
 
 Hi,
 
 there seems to be an issue with local IPv6 TCP connections on main. I have 
 been seeing this for a couple of months at least. pkg upgr on my webserver 
 hosting the pkg repo is very slow, all other hosts can connect to the pkg 
 repo just fine. So IPv6 connections from external hosts are not affected.
 
 I thought I must have misconfigured something, as my setup is a bit weird. 
 Yesterday I noticed the same issue on a different host, turns out all my 
 14.0 hosts seem to be affected, cognet@ could also reproduce it on one of 
 his systems.
 
 The service/software used does not seem to matter, I tried with port 22, 
 25, 80 and 443.
 
 ICMP and UDP don't seem to be affected. ping6 gets replies immediately. 
 And UDP connections with nc -l -u / nc -u don't have any delay, sent data 
 is received immediately.
 
 Testing local TCP connections show this:
 
 flo@rp64:~ $ ifconfig dwc0|grep 2003
inet6 2003:cf:df49:c97:4c59:ebff:fec1:463d prefixlen 64 autoconf
 flo@rp64:~ $ nc -v 2003:cf:df49:c97:4c59:ebff:fec1:463d 22
 [3 second delay here]
 Connection to 2003:cf:df49:c97:4c59:ebff:fec1:463d 22 port [tcp/ssh] 
 succeeded!
 SSH-2.0-OpenSSH_8.9 FreeBSD-20220413
 
>> 
 
 I need help debugging this, I don't know how to analyze this further. I 
 will start bisecting this, but I thought maybe someone has an idea.
>>> Hi Florian,
>>> I can reproduce this locally, will try to figure out what is going on. If 
>>> you can bisect it, it would be great.
>> 
>> Found the culprit 1817be481b8703ae86730b151a6f49cc3022930f. And indeed 
>> toggling net.inet6.ip6.source_address_validation makes the issue go away on 
>> latest main.
> Cool, thanks for providing the information. However, I don't understand why 
> results in dropping the first two SYN segments (this should not happen)
> and why the third is accepted (they should all treated the same).
The first two packets don't have the loopback interface as its rcv interface, 
so Gleb's check for IFF_LOOPBACK fails. The second
retransmission of the SYN has the loopback interface as its rcv interface, so 
Gleb check passes.
I also do not see the problem with ICMP6, UDP or SCTP over IPv6.
Don't know what is special about TCP, maybe Gleb knows out of his head...

Best regards
Michael
> 
> Best regards
> Michael
>> 
>> Florian
>> 
> 
> 

Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored

[tuexen]

> On 15. Apr 2022, at 23:39, Florian Smeets  wrote:
> 
> On 15.04.22 21:24, tue...@freebsd.org wrote:
>>> On 15. Apr 2022, at 20:20, Florian Smeets  wrote:
>>> 
>>> 
>>> Hi,
>>> 
>>> there seems to be an issue with local IPv6 TCP connections on main. I have 
>>> been seeing this for a couple of months at least. pkg upgr on my webserver 
>>> hosting the pkg repo is very slow, all other hosts can connect to the pkg 
>>> repo just fine. So IPv6 connections from external hosts are not affected.
>>> 
>>> I thought I must have misconfigured something, as my setup is a bit weird. 
>>> Yesterday I noticed the same issue on a different host, turns out all my 
>>> 14.0 hosts seem to be affected, cognet@ could also reproduce it on one of 
>>> his systems.
>>> 
>>> The service/software used does not seem to matter, I tried with port 22, 
>>> 25, 80 and 443.
>>> 
>>> ICMP and UDP don't seem to be affected. ping6 gets replies immediately. And 
>>> UDP connections with nc -l -u / nc -u don't have any delay, sent data is 
>>> received immediately.
>>> 
>>> Testing local TCP connections show this:
>>> 
>>> flo@rp64:~ $ ifconfig dwc0|grep 2003
>>> inet6 2003:cf:df49:c97:4c59:ebff:fec1:463d prefixlen 64 autoconf
>>> flo@rp64:~ $ nc -v 2003:cf:df49:c97:4c59:ebff:fec1:463d 22
>>> [3 second delay here]
>>> Connection to 2003:cf:df49:c97:4c59:ebff:fec1:463d 22 port [tcp/ssh] 
>>> succeeded!
>>> SSH-2.0-OpenSSH_8.9 FreeBSD-20220413
>>> 
> 
>>> 
>>> I need help debugging this, I don't know how to analyze this further. I 
>>> will start bisecting this, but I thought maybe someone has an idea.
>> Hi Florian,
>> I can reproduce this locally, will try to figure out what is going on. If 
>> you can bisect it, it would be great.
> 
> Found the culprit 1817be481b8703ae86730b151a6f49cc3022930f. And indeed 
> toggling net.inet6.ip6.source_address_validation makes the issue go away on 
> latest main.
Cool, thanks for providing the information. However, I don't understand why 
results in dropping the first two SYN segments (this should not happen)
and why the third is accepted (they should all treated the same).

Best regards
Michael
> 
> Florian
> 

Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored

[tuexen]

> On 15. Apr 2022, at 20:20, Florian Smeets  wrote:
> 
> [bcc to net@ for wider exposure]
> 
> Hi,
> 
> there seems to be an issue with local IPv6 TCP connections on main. I have 
> been seeing this for a couple of months at least. pkg upgr on my webserver 
> hosting the pkg repo is very slow, all other hosts can connect to the pkg 
> repo just fine. So IPv6 connections from external hosts are not affected.
> 
> I thought I must have misconfigured something, as my setup is a bit weird. 
> Yesterday I noticed the same issue on a different host, turns out all my 14.0 
> hosts seem to be affected, cognet@ could also reproduce it on one of his 
> systems.
> 
> The service/software used does not seem to matter, I tried with port 22, 25, 
> 80 and 443.
> 
> ICMP and UDP don't seem to be affected. ping6 gets replies immediately. And 
> UDP connections with nc -l -u / nc -u don't have any delay, sent data is 
> received immediately.
> 
> Testing local TCP connections show this:
> 
> flo@rp64:~ $ ifconfig dwc0|grep 2003
>   inet6 2003:cf:df49:c97:4c59:ebff:fec1:463d prefixlen 64 autoconf
> flo@rp64:~ $ nc -v 2003:cf:df49:c97:4c59:ebff:fec1:463d 22
> [3 second delay here]
> Connection to 2003:cf:df49:c97:4c59:ebff:fec1:463d 22 port [tcp/ssh] 
> succeeded!
> SSH-2.0-OpenSSH_8.9 FreeBSD-20220413
> 
> tcpdump on lo0 shows that the first two SYN packets are ignored / time out, 
> then the connection is successfully established.
> 
> 19:28:38.685128 IP6 2003:cf:df49:c97:4c59:ebff:fec1:463d.61294 > 
> 2003:cf:df49:c97:4c59:ebff:fec1:463d.22: Flags [S], seq 2489479594, win 
> 65535, options [mss 16324,nop,wscale 6,sackOK,TS val 3410505643 ecr 0], 
> length 0
> 
> 19:28:39.696047 IP6 2003:cf:df49:c97:4c59:ebff:fec1:463d.61294 > 
> 2003:cf:df49:c97:4c59:ebff:fec1:463d.22: Flags [S], seq 2489479594, win 
> 65535, options [mss 16324,nop,wscale 6,sackOK,TS val 3410506654 ecr 0], 
> length 0
> 
> 19:28:41.897836 IP6 2003:cf:df49:c97:4c59:ebff:fec1:463d.61294 > 
> 2003:cf:df49:c97:4c59:ebff:fec1:463d.22: Flags [S], seq 2489479594, win 
> 65535, options [mss 16324,nop,wscale 6,sackOK,TS val 3410508856 ecr 0], 
> length 0
> 
> 19:28:41.897907 IP6 2003:cf:df49:c97:4c59:ebff:fec1:463d.22 > 
> 2003:cf:df49:c97:4c59:ebff:fec1:463d.61294: Flags [S.], seq 2857552476, ack 
> 2489479595, win 65535, options [mss 16324,nop,wscale 6,sackOK,TS val 
> 1858349482 ecr 3410508856], length 0
> 
> 19:28:41.897962 IP6 2003:cf:df49:c97:4c59:ebff:fec1:463d.61294 > 
> 2003:cf:df49:c97:4c59:ebff:fec1:463d.22: Flags [.], ack 1, win 1276, options 
> [nop,nop,TS val 3410508856 ecr 1858349482], length 0
> 
> I need help debugging this, I don't know how to analyze this further. I will 
> start bisecting this, but I thought maybe someone has an idea.
Hi Florian,

I can reproduce this locally, will try to figure out what is going on. If you 
can bisect it, it would be great.

Best regards
Michael
> 
> Thanks,
> Florian
> 

Re: fd7daa727126 breaks buildkernel when KERN_TLS is not defined

[tuexen]

> On 9. Feb 2022, at 11:43, Gary Jennejohn  wrote:
> 
> Commit fd7daa727126 to /usr/src/sys/netinet/tcp_usrreq.c breaks buildkernel
> when KERN_TLS is not defined.
Fixed in 
https://cgit.FreeBSD.org/src/commit/?id=528c76492402d9be8ec83a0a769f0d70e2a32f61

Thanks for reporting.

Best regards
Michael
> This patch fixes it for me:
> 
> --- tcp_usrreq.c.orig 2022-02-09 10:25:46.851034000 +
> +++ tcp_usrreq.c  2022-02-09 10:30:27.541058000 +
> @@ -2119,12 +2119,12 @@
> int
> tcp_default_ctloutput(struct inpcb *inp, struct sockopt *sopt)
> {
> - struct socket *so = inp->inp_socket;
>   struct tcpcb *tp = intotcpcb(inp);
>   int error, opt, optval;
>   u_int   ui;
>   struct  tcp_info ti;
> #ifdef KERN_TLS
> + struct socket *so = inp->inp_socket;
>   struct tls_enable tls;
> #endif
>   char*pbuf, buf[TCP_LOG_ID_LEN];
> @@ -2136,7 +2136,9 @@
>   INP_WLOCK_ASSERT(inp);
>   KASSERT((inp->inp_flags & (INP_TIMEWAIT | INP_DROPPED)) == 0,
>   ("inp_flags == %x", inp->inp_flags));
> +#ifdef KERN_TLS
>   KASSERT(so != NULL, ("inp_socket == NULL"));
> +#endif
> 
>   switch (sopt->sopt_level) {
> #ifdef INET6
> 
> -- 
> Gary Jennejohn
> 

Re: Problems compiling kernel

[tuexen]

> On 30. Dec 2021, at 20:42, Konstantin Belousov  wrote:
> 
> On Thu, Dec 30, 2021 at 08:33:09PM +0100, tue...@freebsd.org wrote:
>>> On 30. Dec 2021, at 20:26, Michael Gmelin  wrote:
>>> 
>>> This should have been resolved today in 
>>> https://cgit.freebsd.org/src/commit/?id=5e6a2d6eb220d780c9128c81b58f133114061415
>> I do have that commit locally in the tree... But I can't build world or 
>> kernel.
>> 
>> Looking for libc++.so.1 I get
>> 
>> tuexen@head:~/freebsd-src % ls -l /usr/lib/libc++*
>> -r--r--r--  1 root  wheel  6939492 Dec 30 11:38 /usr/lib/libc++.a
>> -r--r--r--  1 root  wheel   68 Jan 28  2021 /usr/lib/libc++.so
>> -r--r--r--  1 root  wheel35234 Dec 30 11:38 /usr/lib/libc++experimental.a
>> tuexen@head:~/freebsd-src % ls -l /lib/libc++*
>> ls: No match.
>> tuexen@head:~/freebsd-src % 
>> 
>> How can I build a kernel?
> 
> Take libc++.so.1 somewhere, for instance from
> https://download.freebsd.org/ftp/snapshots/amd64/amd64/14.0-CURRENT/base.txz
> archive, and put the library to /lib.
Works perfectly!

Thank you very mich for the quick help!

Best regards
Michael

Re: Problems compiling kernel

[tuexen]

> On 30. Dec 2021, at 20:26, Michael Gmelin  wrote:
> 
> This should have been resolved today in 
> https://cgit.freebsd.org/src/commit/?id=5e6a2d6eb220d780c9128c81b58f133114061415
I do have that commit locally in the tree... But I can't build world or kernel.

Looking for libc++.so.1 I get

tuexen@head:~/freebsd-src % ls -l /usr/lib/libc++*
-r--r--r--  1 root  wheel  6939492 Dec 30 11:38 /usr/lib/libc++.a
-r--r--r--  1 root  wheel   68 Jan 28  2021 /usr/lib/libc++.so
-r--r--r--  1 root  wheel35234 Dec 30 11:38 /usr/lib/libc++experimental.a
tuexen@head:~/freebsd-src % ls -l /lib/libc++*
ls: No match.
tuexen@head:~/freebsd-src % 

How can I build a kernel?

Best regards
Michael
> 
> -m
> 
>> On 30. Dec 2021, at 20:17, tue...@freebsd.org wrote:
>> 
>> Dear all,
>> 
>> on a system updated yesterday I get
>> 
>> tuexen@head:~/freebsd-src % git branch
>> * main
>> tuexen@head:~/freebsd-src % git pull
>> Already up to date.
>> tuexen@head:~/freebsd-src % uname -a
>> FreeBSD head 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n252035-63f7f3921bd: 
>> Thu Dec 30 11:33:16 CET 2021 
>> root@head:/usr/obj/usr/home/tuexen/freebsd-src/amd64.amd64/sys/TCP  amd64
>> tuexen@head:~/freebsd-src % sudo make -j 4 kernel KERNCONF=TCP
>> ld-elf.so.1: Shared object "libc++.so.1" not found, required by "cc"
>> make: "/usr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line 201: 
>> warning: "cc -v 2>&1 | grep "gcc version"" returned non-zero status
>> make: "/usr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line 205: 
>> Unable to determine compiler type for CC=cc.  Consider setting COMPILER_TYPE.
>> 
>> make: stopped in /usr/home/tuexen/freebsd-src
>> tuexen@head:~/freebsd-src % 
>> 
>> any idea what I did wrong and how to fix it?
>> 
>> Thanks for any hints.
>> 
>> Best regards
>> Michael

Problems compiling kernel

[tuexen]

Dear all,

on a system updated yesterday I get

tuexen@head:~/freebsd-src % git branch
* main
tuexen@head:~/freebsd-src % git pull
Already up to date.
tuexen@head:~/freebsd-src % uname -a
FreeBSD head 14.0-CURRENT FreeBSD 14.0-CURRENT #1 main-n252035-63f7f3921bd: Thu 
Dec 30 11:33:16 CET 2021 
root@head:/usr/obj/usr/home/tuexen/freebsd-src/amd64.amd64/sys/TCP  amd64
tuexen@head:~/freebsd-src % sudo make -j 4 kernel KERNCONF=TCP
ld-elf.so.1: Shared object "libc++.so.1" not found, required by "cc"
make: "/usr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line 201: 
warning: "cc -v 2>&1 | grep "gcc version"" returned non-zero status
make: "/usr/home/tuexen/freebsd-src/share/mk/bsd.compiler.mk" line 205: Unable 
to determine compiler type for CC=cc.  Consider setting COMPILER_TYPE.

make: stopped in /usr/home/tuexen/freebsd-src
tuexen@head:~/freebsd-src % 

any idea what I did wrong and how to fix it?

Thanks for any hints.

Best regards
Michael

Re: "Khelp module "ertt" can't unload until its refcount drops from 1 to 0." after "All buffers synced."?

[tuexen]

> On 19. Nov 2021, at 00:11, Mark Millard  wrote:
> 
>> On 2021-Nov-18, at 12:31, tue...@freebsd.org  wrote:
>> 
>>> On 17. Nov 2021, at 21:13, Mark Millard via freebsd-current 
>>>  wrote:
>>> 
>>> I've not noticed the ertt message before in:
>>> 
>>> . . .
>>> Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to stop... 
>>> done
>>> All buffers synced.
>>> Uptime: 1d9h57m18s
>>> Khelp module "ertt" can't unload until its refcount drops from 1 to 0.
>> Hi Mark,
>> 
>> what kernel configuration are you using? What kernel modules are loaded?
> 
> The shutdown was of my ZFS boot media but the machine is
> currently doing builds on the UFS media. (The ZFS media is
> present but not mounted). For now I provide information
> from the booted UFS system. The UFS context is intended
> to be nearly a copy of the brctl selection for main [so: 14]
> from the ZFS media. Both systems have been doing the same
> poudriere builds for various comparison/contrast purposes.
> The current build activity will likely take 16+ hrs.
Hi Mark,

thanks a lot for the information. I was contemplating whether this message
was related to a recent change in the TCP congestion module handling, but
since it was already there in February, this is not the case. Will try to
reproduce this, but wasn't able up to now.

Best regards
Michael
> 
> For reference for now (from UFS context):
> 
> # uname -apKU
> FreeBSD HC_CA72_UFS 14.0-CURRENT FreeBSD 14.0-CURRENT #19 
> main-n250667-20aa359773be-dirty: Sun Nov 14 02:57:32 PST 2021 
> root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72
>   arm64 aarch64 1400042 1400042
> 
> This environment was built with -mcpu=cortex-a72 in use and the
> system is a 16 core Cortex-A72 system. (I've caught a FreeBSD
> weak memory model error in the past with such -mcpu=cortext-a72
> use on a Cortext-A72 system, not that I have evidence of such
> here.)
> 
> # kldstat
> Id Refs AddressSize Name
> 1   18 0x  12b1660 kernel
> 21 0x012b2000   41e070 zfs.ko
> 31 0x016d100026af8 cryptodev.ko
> 41 0x00019a4027000 nullfs.ko
> 51 0x00019a42700025000 fdescfs.ko
> 
> # more /usr/main-src/sys/arm64/conf/GENERIC-NODBG-CA72
> include "GENERIC-NODBG"
> 
> ident   GENERIC-NODBG-CA72
> 
> makeoptions CONF_CFLAGS="-mcpu=cortex-a72"
> 
> # more /usr/main-src/sys/arm64/conf/GENERIC-NODBG
> #
> # GENERIC -- Custom configuration for the arm64/aarch64
> #
> 
> include "GENERIC"
> 
> ident   GENERIC-NODBG
> 
> makeoptions DEBUG=-g# Build kernel with gdb(1) debug 
> symbols
> 
> options ALT_BREAK_TO_DEBUGGER
> 
> options KDB # Enable kernel debugger support
> 
> # For minimum debugger support (stable branch) use:
> #optionsKDB_TRACE   # Print a stack trace for a panic
> options DDB # Enable the kernel debugger
> 
> # Extra stuff:
> #optionsVERBOSE_SYSINIT=0   # Enable verbose sysinit messages
> #optionsBOOTVERBOSE=1
> #optionsBOOTHOWTO=RB_VERBOSE
> #optionsKTR
> #optionsKTR_MASK=KTR_TRAP
> ##options   KTR_CPUMASK=0xF
> #optionsKTR_VERBOSE
> 
> # Disable any extra checking for. . .
> nooptions   DEADLKRES   # Enable the deadlock resolver
> nooptions   INVARIANTS  # Enable calls of extra sanity 
> checking
> nooptions   INVARIANT_SUPPORT   # Extra sanity checks of internal 
> structures, required by INVARIANTS
> nooptions   WITNESS # Enable checks to detect deadlocks 
> and cycles
> nooptions   WITNESS_SKIPSPIN# Don't run witness on spinlocks for 
> speed
> nooptions   DIAGNOSTIC
> nooptions   MALLOC_DEBUG_MAXZONES   # Separate malloc(9) zones
> nooptions   BUF_TRACKING
> nooptions   FULL_BUF_TRACKING
> 
> 
> The builds do include a bulk for targeting armv7
> (so 32-bit compatibility) but that bulk has not
> started yet in the UFS context.
> 
> # poudriere jail -jmain-CA7 -i
> Jail name: main-CA7
> Jail version:  14.0-CURRENT
> Jail arch: arm.armv7
> Jail method:   null
> Jail mount:/usr/obj/DESTDIRs/main-CA7-poud
> Jail fs:   
> Jail updated:  2021-11-16 02:24:57
> Jail pkgbase:  disabled
> 
> My networking context is simple context does not provide
> services outside the local network. The services are normal
> ones, such as nfs, ssh, and whatever default things. ntpd
> is in use. distfiles are downloaded during builds. It is not
> a desktop environment, not even a video card.
> 
> I've noticed a 2021-Feb-22 report in:
> 
> https://forums.freebsd.org/threads/whats-the-error-khelp-module-ertt-unload.79009/
> 
> so getting the message does not appear to be unique to my
> context.
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
> 

Re: "Khelp module "ertt" can't unload until its refcount drops from 1 to 0." after "All buffers synced."?

[tuexen]

> On 17. Nov 2021, at 21:13, Mark Millard via freebsd-current 
>  wrote:
> 
> I've not noticed the ertt message before in:
> 
> . . .
> Waiting (max 60 seconds) for system thread `bufspacedaemon-1' to stop... done
> All buffers synced.
> Uptime: 1d9h57m18s
> Khelp module "ertt" can't unload until its refcount drops from 1 to 0.
Hi Mark,

what kernel configuration are you using? What kernel modules are loaded?

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

Re: ssh connections break with "Fssh_packet_write_wait" on 13 [SOLVED]

[tuexen]

> On 9. Jun 2021, at 08:57, Don Lewis  wrote:
> 
> On  8 Jun, Michael Gmelin wrote:
>> 
>> 
>> On Thu, 3 Jun 2021 15:09:06 +0200
>> Michael Gmelin  wrote:
>> 
>>> On Tue, 1 Jun 2021 13:47:47 +0200
>>> Michael Gmelin  wrote:
>>> 
 Hi,
 
 Since upgrading servers from 12.2 to 13.0, I get
 
 Fssh_packet_write_wait: Connection to 1.2.3.4 port 22: Broken pipe
 
 consistently, usually after about 11 idle minutes, that's with and
 without pf enabled. Client (11.4 in a VM) wasn't altered.
 
 Verbose logging (client and server side) doesn't show anything
 special when the connection breaks. In the past, QoS problems
 caused these disconnects, but I didn't see anything apparent
 changing between 12.2 and 13 in this respect.
 
 I did a test on a newly commissioned server to rule out other
 factors (so, same client connections, some routes, same
 everything). On 12.2 before the update: Connection stays open for
 hours. After the update (same server): connections breaks
 consistently after < 15 minutes (this is with unaltered
 configurations, no *AliveInterval configured on either side of the
 connection). 
>>> 
>>> I did a little bit more testing and realized that the problem goes
>>> away when I disable "Proportional Rate Reduction per RFC 6937" on the
>>> server side:
>>> 
>>> sysctl net.inet.tcp.do_prr=0
>>> 
>>> Keeping it on and enabling net.inet.tcp.do_prr_conservative doesn't
>>> fix the problem.
>>> 
>>> This seems to be specific to Parallels. After some more digging, I
>>> realized that Parallels Desktop's NAT daemon (prl_naptd) handles
>>> keep-alive between the VM and the external server on its own. There is
>>> no direct communication between the client and the server. This means:
>>> 
>>> - The NAT daemon starts sending keep-alive packages right away (not
>>> after the VM's net.inet.tcp.keepidle), every 75 seconds.
>>> - Keep-alive packages originating in the VM never reach the server.
>>> - Keep-alive originating on the server never reaches the VM.
>>> - Client and server basically do keep-alive with the nat daemon, not
>>> with each other.
>>> 
>>> It also seems like Parallels is filtering the tos field (so it's
>>> always 0x00), but that's unrelated.
>>> 
>>> I configured a bhyve VM running FreeBSD 11.4 on a separate laptop on
>>> the same network for comparison and is has no such issues.
>>> 
>>> Looking at TCP dump output on the server, this is what a keep-alive
>>> package sent by Parallels looks like:
>>> 
>>> 10:14:42.449681 IP (tos 0x0, ttl 64, id 15689, offset 0, flags
>>> [none], proto TCP (6), length 40)
>>>   192.168.1.1.58222 > 192.168.1.2.22: Flags [.], cksum x (correct),
>>>   seq 2534, ack 3851, win 4096, length 0
>>> 
>>> While those originating from the bhyve VM (after lowering
>>> net.inet.tcp.keepidle) look like this:
>>> 
>>> 12:18:43.105460 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF],
>>>   proto TCP (6), length 52)
>>>   192.168.1.3.57555 > 192.168.1.2.22: Flags [.], cksum x
>>>   (correct), seq 1780337696, ack 45831723, win 1026, options
>>>   [nop,nop,TS val 3003646737 ecr 3331923346], length 0
>>> 
>>> Like written above, once net.inet.tcp.do_prr is disabled, keepalive
>>> seems to be working just fine. Otherwise, Parallel's NAT daemon kills
>>> the connection, as its keep-alive requests are not answered (well,
>>> that's what I think is happening):
>>> 
>>> 10:19:43.614803 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
>>>   proto TCP (6), length 40)
>>>   192.168.1.1.58222 > 192.168.1.2.22: Flags [R.], cksum x (correct),
>>>   seq 2535, ack 3851, win 4096, length 0
>>> 
>>> The easiest way to work around the problem Client side is to configure
>>> ServerAliveInterval in ~/.ssh/config in the Client VM.
>>> 
>>> I'm curious though if this is basically a Parallels problem that has
>>> only been exposed by PRR being more correct (which is what I suspect),
>>> or if this is actually a FreeBSD problem.
>>> 
>> 
>> So, PRR probably was a red herring and the real reason that's happening
>> is that FreeBSD (since version 13[0]) by default discards packets
>> without timestamps for connections that formally had negotiated to have
>> them. This new behavior seems to be in line with RFC 7323, section
>> 3.2[1]:
>> 
>>   "Once TSopt has been successfully negotiated, that is both  and
>>contain TSopt, the TSopt MUST be sent in every non-
>>   segment for the duration of the connection, and SHOULD be sent in an
>>segment (see Section 5.2 for details)."
>> 
>> As it turns out, macOS does exactly this - send keep-alive packets
>> without a timestamp for connections that were negotiated to have them.
> 
> I wonder if I'm running into this with ssh connections to freefall.  My
> outgoing IPv6 connections pass through an ipfw firewall that uses
> dynamic rules.  When the dynamic rule gets close to expiration, it
> generates keep alive packets that just seem to be ignored by freefall.
> Eventually the 

Re: OpenZFS imports, status update

[tuexen]

> On 9. Jun 2021, at 03:07, tech-lists  wrote:
> 
> Hi,
> 
> On Tue, Jun 08, 2021 at 04:52:43PM -0600, Warner Losh wrote:
>> Top posting...
>> 
>> You can do a 'git remote purge freebsd' to reset the branch names, then
>> you'll be able to do a normal pull.
> 
> This doesn't work for me. I use the anonssh method of updating the tree
> 
> % git remote -v
> originssh://anon...@git.freebsd.org/src.git (fetch)
> originssh://anon...@git.freebsd.org/src.git (push)
> 
> % gvs
> srctree last updated: Wed Jun 9 02:19:47 2021 +0200 version: 245848
> 
> root@desktop:/root# cd /usr/src
> 
> root@desktop:/usr/src# git version
> git version 2.31.1
> 
> root@desktop:/usr/src# git checkout stable/13
> Already on 'stable/13'
> Your branch is behind 'origin/stable/13' by 6922 commits, and can be 
> fast-forwarded.
>  (use "git pull" to update your local branch)
> 
> root@desktop:/usr/src# git remote purge freebsd
> error: Unknown subcommand: purge
Try: git remote prune freebsd

Best regards
Michael
> usage: git remote [-v | --verbose]
>   or: git remote add [-t ] [-m ] [-f] [--tags | --no-tags] 
> [--mirror=]  
>   or: git remote rename  
>   or: git remote remove 
>   or: git remote set-head  (-a | --auto | -d | --delete | )
>   or: git remote [-v | --verbose] show [-n] 
>   or: git remote prune [-n | --dry-run] 
>   or: git remote [-v | --verbose] update [-p | --prune] [( | 
> )...]
>   or: git remote set-branches [--add]  ...
>   or: git remote get-url [--push] [--all] 
>   or: git remote set-url [--push]   []
>   or: git remote set-url --add  
>   or: git remote set-url --delete  
> 
>-v, --verbose be verbose; must be placed before a subcommand
> 
> -- 
> J.

Re: ssh connections break with "Fssh_packet_write_wait" on 13 [SOLVED]

[tuexen]

) by default discards packets
>> without timestamps for connections that formally had negotiated to have
>> them. This new behavior seems to be in line with RFC 7323, section
>> 3.2[1]:
>> 
>>   "Once TSopt has been successfully negotiated, that is both  and
>>contain TSopt, the TSopt MUST be sent in every non-
>>   segment for the duration of the connection, and SHOULD be sent in an
>>segment (see Section 5.2 for details)."
>> 
>> As it turns out, macOS does exactly this - send keep-alive packets
>> without a timestamp for connections that were negotiated to have them.
>> 
>> Under normal circumstances - ssh from macOS to a server running FreeBSD
>> 13 - this won't be noticed, since macOS uses the same default settings
>> as FreeBSD (2 hours idle time, 75 seconds intervals), so the server
>> side initiated keep-alive will save the connection before it has a
>> chance to break due to eight consecutive unanswered keep-alives at the
>> client side.
>> 
>> This is different for ssh connections originating from a VM inside
>> Parallels, as connections created by prl_naptd will start sending tcp
>> keep-alives shortly after the connection becomes idle. As a result,
>> idle connections break after about 11 minutes of idle time (60s
>> + 8*75s = 660s == 11m), unless countermeasures are taken.
>> 
>> An easy way to demonstrate the problem is to change keep-alive defaults
>> on *macOS* using sysctl and sshing to a FreeBSD 13 server:
>> 
>>   $ sudo sysctl net.inet.tcp.keepidle=5000
>>   $ sudo sysctl net.inet.tcp.keepintvl=5000
>>   $ ssh -oTCPKeepAlive=yes myserver
>> 
>> This way, the problem described can be reproduced quite easily:
>> Disconnect due to broken pipe after 45-60 seconds of idle time, tcpdump
>> confirming that keep-alive packets don't have tcp timestamps, while
>> they were used when negotiating the connection.
>> 
>> There are various ways to work around the issue.
>> 
>> Client side workarounds:
>> - Use ServerAlive* settings in ~/.ssh/config (ssh only)
>> - Tune net.inet.tcp.keep* sysctls on macOS (for all services)
>> 
>> Server side workarounds:
>> - Use ClientAlive* settings in ~/.ssh/config (ssh only)
>> - Tolerate missing timestamps in packets using sysctl, which makes
>> FreeBSD 13 behave like previous versions did:
>> 
>>   sysctl net.inet.tcp.tolerate_missing_ts=1
>> 
>> The last option probably being the most practical one.
>> 
>> rscheff@ and tuexen@ (thank you!) were able to reproduce the issue and
>> reached out to Apple to see if there is something they can do to fix
>> this at their end (macOS) in the future.
> 
> Can we please have the default of tolerate_missing_ts in
> current, stable/13 and an errata issued to releng_13 changing
> this value to =1 and staying that way until the buggy tcp
> stacks are found and eliminated.
The interesting part of your statement is that we find these stacks
now by using the value of 0. But seriously, I thought that reasonable
modern stacks would follow the RFC, which is not the case.
I'll change the value in current and stable/13. But I have no idea
about an errata. Will bring it up at the next transport call.

Best regards
Michael
> 
>> 
>> Best
>> Michael
>> 
>> [0]https://cgit.freebsd.org/src/commit/?id=283c76c7c3f2f634f19f303a771a3f81fe890cab
>> [1]https://datatracker.ietf.org/doc/html/rfc7323#section-3.2
>> 
>> -- 
>> Michael Gmelin
>> 
>> 
> 
> -- 
> Rod Grimes rgri...@freebsd.org
> 

Re: htcp is not NEWRENO:newreno

[tuexen]

> On 26. May 2021, at 16:53, Marek Zarychta  
> wrote:
> 
> Dear subscribers and devs,
> 
> I am running CURRENT with RACK[1] and HTCP[2] and recently get kernel
> message buffer messages like this one:
> cc_algo:htcp is not NEWRENO:newreno
> Should I be worried about this assertion?
Hi Marek,
RACK has been tested with newreno and some of its functionality requires 
newreno.
In this case dealing with ECN. RACK detects this and reports it.

Best regards
Michael
> 
> [1] net.inet.tcp.functions_default=rack
> [2] net.inet.tcp.cc.algorithm=htcp
> -- 
> Marek Zarychta
> 

Re: TCP Connection hang - MSS again

[Michael Tuexen]

> On 6. Apr 2021, at 19:02, Rodney W. Grimes  
> wrote:
> 
>> 06.04.2021 19:54, Rodney W. Grimes wrote:
 05.04.2021 19:44, Rozhuk Ivan wrote:
 
>>> As I understand, in some cases remote host does not reply with MSS
>>> option, and host behind router continue use mss 8960, that dropped
>>> by router.  
>> If the peer does not provide an MSS option, your local FreeBSD based
>> host should use an MSS of net.inet.tcp.mssdflt bytes. The default is
>> 536. So I don't think this should be a problem.
> 
> Thats it!
> Thanks, it was ~64k in mine config.
 
 This is also per-host setting, you know :-)
 
 It is generally bad idea using MTU over 1500 for an interface facing 
 public network
 without -mtu 1500. You see, because TCP MSS affects only TCP and there is 
 also UDP
 that happily produces oversized datagramms for DNS or RTP or NFS or 
 tunneling like L2TP or OpenVPN etc.
 relying on IP fragmentation.
 
 I still recommend using -mtu 1500 in addition to mssdflt in your case.
>>> 
>>> I do not recommend such a setting.  That would defeat any jumbo frame usage
>>> locally!
>> 
>> Why? Default route should not be used for local delivery.
> 
> Your right, but we are both making assumptions, I assumed that most
> likely the only route on the system is the default route, and your
> assuming that they are running with something more than a default
> route.
> 
>>> The gateway/router that is forwarding packets to the internet connection
>>> needs its upstream interface mtu set properly, and configured to properly
>>> return icmp need fragement messages on the interfaces towards the
>>> internal network.
>> 
>> This results in extra delays and retransmission during outgoing data 
>> transfer, not good.
>> The mechanics is much more fragile than default route's mtu attribute.
> 
> The delay should be pretty slight, the router is going to return an
> icmp message, and if configured to do so frag the packets and
> forward them on, no retransmission would occur as the DF flag
> is not normally set unless explicitly requested.
1. Isn't a router either fragmenting a packet and forwarding the
  fragments or sending back an ICMP packet and dropping the packet?
2. Isn't FreeBSDs TCP implementation setting the DF bit, if
  net.inet.tcp.path_mtu_discovery is set to 1, which is the default.

So it would take one RTT to the router For TCP to react and reduce the MSS.

Best regards
Michael
> 
> It still makes no since to me to increase the interface MTU and then
> crank it back down by using a route MTU.  You might as well just leave
> the MTU alone and not have 2 configurations items more or less doing
> nothing.
> 
> -- 
> Rod Grimes rgri...@freebsd.org
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

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

Re: TCP Connection hang - MSS again

[tuexen]

> On 5. Apr 2021, at 11:44, Rozhuk Ivan  wrote:
> 
> Hi!
> 
> 
> TCP Connection hang then I try to open 
> https://online.sberbank.ru/CSAFront/index.do#/
> 
> FreeBSD 13 desktop + FreeBSD 13 router (pf).
> http://www.netlab.linkpc.net/download/software/os_cfg/FBSD/13/base/etc/sysctl.conf
> FreeBSD 13 desktop have no known problems with other websites.
> Only with one remonte FreeBSD 12 with same sysctl.conf and mtu 9k.
> If I set mtu to 1500 on desktop - issue is gone.
> 
> Router pf.conf contain:
> scrub out on $ext_v4_if0 all random-id min-ttl 128 max-mss 1400
> scrub in on $ext_v4_if0 all max-mss 1400
> 
> 
> Android 9 and FreeBSD 12.2 have no this issue (both @WiFi).
> 
> 
> As I understand, in some cases remote host does not reply with MSS option, 
> and host behind
> router continue use mss 8960, that dropped by router.
If the peer does not provide an MSS option, your local FreeBSD based host should
use an MSS of net.inet.tcp.mssdflt bytes. The default is 536. So I don't think
this should be a problem.

Best regards
Michael
> 
> (pf scrub rules disabled for this log), tcpdump | grep mss:
>176.99.179.102.60903 > 194.54.14.131.443: Flags [S], cksum 0xd0a2 
> (correct), seq 3696980106, win 65535, options [mss 8960,nop,wscale 
> 10,sackOK,TS val 3763275954 ecr 0], length 0
>176.99.179.102.60719 > 194.54.14.131.443: Flags [S], cksum 0xd796 
> (correct), seq 232307963, win 65535, options [mss 8960,nop,wscale 
> 10,sackOK,TS val 1963519951 ecr 0], length 0
>176.99.179.102.50146 > 194.54.14.131.443: Flags [S], cksum 0x1aa9 
> (correct), seq 3968469659, win 65535, options [mss 8960,nop,wscale 
> 10,sackOK,TS val 3417199378 ecr 0], length 0
>176.99.179.102.50646 > 194.54.14.131.443: Flags [S], cksum 0xb3ba 
> (correct), seq 3774081696, win 65535, options [mss 8960,nop,wscale 
> 10,sackOK,TS val 1089629786 ecr 0], length 0
>176.99.179.102.56843 > 194.54.14.131.443: Flags [S], cksum 0xc4dd 
> (correct), seq 647662718, win 65535, options [mss 8960,nop,wscale 
> 10,sackOK,TS val 4054756545 ecr 0], length 0
>194.54.14.131.443 > 176.99.179.102.56843: Flags [S.], cksum 0x35dd 
> (correct), seq 186241788, ack 647662719, win 65535, options [mss 
> 1380,nop,wscale 3,nop,nop,sackOK,nop,nop,TS val 2541298941 ecr 4054756545], 
> length 0
>176.99.179.102.65364 > 194.54.14.131.443: Flags [S], cksum 0x17a0 
> (correct), seq 1603248650, win 65535, options [mss 8960,nop,wscale 
> 10,sackOK,TS val 1794142451 ecr 0], length 0
>176.99.179.102.59862 > 194.54.14.131.443: Flags [S], cksum 0x2736 
> (correct), seq 4000339086, win 65535, options [mss 8960,nop,wscale 
> 10,sackOK,TS val 4084903147 ecr 0], length 0
>176.99.179.102.60915 > 194.54.14.131.443: Flags [S], cksum 0xd964 
> (correct), seq 95236311, win 65535, options [mss 8960,nop,wscale 10,sackOK,TS 
> val 1297197380 ecr 0], length 0
>176.99.179.102.58717 > 194.54.14.131.443: Flags [S], cksum 0xf92e 
> (correct), seq 1785704794, win 65535, options [mss 8960,nop,wscale 
> 10,sackOK,TS val 1392944917 ecr 0], length 0
>194.54.14.131.443 > 176.99.179.102.58717: Flags [S.], cksum 0xe020 
> (correct), seq 2800465814, ack 1785704795, win 65535, options [mss 
> 1380,nop,wscale 3,nop,nop,sackOK,nop,nop,TS val 2541366941 ecr 1392944917], 
> length 0
>176.99.179.102.53377 > 194.54.14.131.443: Flags [S], cksum 0x8fdd 
> (correct), seq 3235103847, win 65535, options [mss 8960,nop,wscale 
> 10,sackOK,TS val 1359134165 ecr 0], length 0
> 
> 
> Is it possible to force FreeBSD always ask with tcp mss option?
> Is any other other options to work around this?
> 
> 
> 
> 
> 
> 
> Full connections log:
> 
> 12:06:44.205766 70:85:c2:43:67:5b > 78:da:6e:28:c9:c0, ethertype IPv4 
> (0x0800), length 74: (tos 0x0, ttl 128, id 0, offset 0, flags [DF], proto TCP 
> (6), length 60)
>176.99.179.102.54064 > 194.54.14.131.443: Flags [S], cksum 0xca3f 
> (correct), seq 980200339, win 65535, options [mss 1400,nop,wscale 
> 10,sackOK,TS val 1268859625 ecr 0], length 0
> 12:06:44.206997 78:da:6e:28:c9:c0 > 70:85:c2:43:67:5b, ethertype IPv4 
> (0x0800), length 60: (tos 0x0, ttl 59, id 57535, offset 0, flags [none], 
> proto TCP (6), length 40)
>194.54.14.131.443 > 176.99.179.102.54064: Flags [S.], cksum 0x5d05 
> (correct), seq 2754330417, ack 980200340, win 0, length 0
> 12:06:44.207126 70:85:c2:43:67:5b > 78:da:6e:28:c9:c0, ethertype IPv4 
> (0x0800), length 54: (tos 0x0, ttl 128, id 0, offset 0, flags [DF], proto TCP 
> (6), length 40)
>176.99.179.102.54064 > 194.54.14.131.443: Flags [.], cksum 0x5d06 
> (correct), seq 1, ack 1, win 65535, length 0
> 12:06:44.210824 78:da:6e:28:c9:c0 > 70:85:c2:43:67:5b, ethertype IPv4 
> (0x0800), length 60: (tos 0x0, ttl 59, id 45037, offset 0, flags [DF], proto 
> TCP (6), length 40)
>194.54.14.131.443 > 176.99.179.102.54064: Flags [.], cksum 0x5d06 
> (correct), seq 1, ack 1, win 65535, length 0
> 12:06:44.211130 70:85:c2:43:67:5b > 78:da:6e:28:c9:c0, ethertype IPv4 
> (0x0800), length 571: (tos 0x0, ttl 128, 

Re: Is there any machine RISC-V implemented ?

[Michael Tuexen]

> On 25. Dec 2020, at 01:43, KIRIYAMA Kazuhiko  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@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

Re: kldref: too many segments on kernel build

[Michael Tuexen]

> On 19. Aug 2020, at 06:19, Dustin Marquess  wrote:
> 
> On Tue, Aug 18, 2020 at 3:19 PM Michael Butler
>  wrote:
>> 
>> Any thoughts as to why this is happening when I build a (custom) kernel?
>> 
>> kldxref: /boot/kernel/kernel: too many segments
> 
> I'm seeing this too.  I haven't tried actually booting the kernel
> because of this.
I also see this... The kernel boots just fine.

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

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

Re: ? ????? ??: vnc can't connect to socket

[Michael Tuexen]

> On 22. Jun 2020, at 15:55, Michael Tuexen  wrote:
> 
>> On 21. Jun 2020, at 23:12, Rodney W. Grimes  
>> wrote:
>> 
>>>> On Sun, 2020-06-21 at 14:54 +0200, Michael Tuexen wrote:
>>>>>> On 21. Jun 2020, at 14:28, Kostya Berger 
>>>>>> wrote:
>>>>>> 
>>>>>> Ok, it turns out, it gives the previously mentioned error only if I
>>>>>> use VNC server string 0.0.0.0:5900 (as I always did). in my VNC
>>>>>> client.But when replaced with127.0.0.1:5900it connects all right.
>>>>> 
>>>>> I don't hink 0.0.0.0 is a valid destination address you can use in
>>>>> connect(). Using 127.0.0.1 should
>>>>> be fine.
>>> 
>>> I do not believe that this is a destination address when your talking
>>> about 0.0.0.0:5900 on the VNC server side, that is a wild card accept
>>> any address and if this has been broken.. it must be fixed!
>>> 
>>>>> I guess, https://svnweb.freebsd.org/changeset/base/361752 is the
>>>>> relevant commit here.
>>>>> 
>>>> 
>>>> *BSD has always accepted 0 as a synonym for localhost (and iirc, linux
>>>> does not).  If this no longer works, it's a regression which is going
>>>> to cause existing applications and scripts to fail.  At the very least
>>>> it deserves an entry in UPDATING.
>>> 
>>> I am not aware of that, but can not deny it either, and just confirmed
>>> it to be true:
>>> root {1002}# telnet 0.0.0.0 22
>>> Trying 0.0.0.0...
>>> Connected to 0.0.0.0.
>>> Escape character is '^]'.
>>> SSH-2.0-OpenSSH_7.8 FreeBSD-20180909
>> 
>> And to add the netstat data to show what connected:
>> tcp4   0  0 127.0.0.1.22   127.0.0.1.43135ESTABLISHED
>> tcp4  38  0 127.0.0.1.43135127.0.0.1.22   ESTABLISHED
>> 
>> Can we back this commit out, discuss it in next weeks call,
>> and then find a way forward?
>> 
>>> 
>>> INADDR_ANY is the wildcard listen address, but as a destination what code 
>>> remapped
>>> it to 127.0.0.1?
>>> 
>>> We should very seriously consider restoring this behavior.
> Reallowing 0.0.0.0 is covered by https://reviews.freebsd.org/D25401
Fixed in https://svnweb.freebsd.org/changeset/base/363256

Best regards
Michael
> 
> Best regards
> Michael
>>> 
>>>> -- Ian
>>>> 
>>>>> Best regards
>>>>> Michael
>>>>>> ?? ?? Yahoo ? ??? Android 
>>>>>> 
>>>>>> ??, 21 ???. 2020 ? 9:40 Kostya Berger
>>>>>> ???(-?):   Hi,upgraded to 362292 via buildworld.Now I cannot
>>>>>> connect to my bhyve guest as I used to: neither via VNC nor via
>>>>>> RDP.VNC gets error: unable to connect the socket. Address family
>>>>>> not supported by protocol family (47).
>>>>>> Neither can I ping my bhyve IP (it uses a separate NIC and should
>>>>>> have no problems)
>>>>>> Internet connectivity is ok and I can ping other hosts on my
>>>>>> network.
>>>>>> In 359997 all works fine.
>>>>>> ?? ?? Yahoo ? ??? Android  
>>>>>> ___
>>>>>> freebsd-current@freebsd.org mailing list
>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>>>> To unsubscribe, send any mail to "
>>>>>> freebsd-current-unsubscr...@freebsd.org"
>>>>> 
>>>>> ___
>>>>> freebsd-current@freebsd.org mailing list
>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>>> To unsubscribe, send any mail to "
>>>>> freebsd-current-unsubscr...@freebsd.org"
>>>>> 
>>>> 
>>>> ___
>>>> freebsd-current@freebsd.org mailing list
>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>>>> 
>>>> 
>>> 
>>> -- 
>>> Rod Grimes 
>>> rgri...@freebsd.org
>>> ___
>>> freebsd-current@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>>> 
>> 
>> -- 
>> Rod Grimes 
>> rgri...@freebsd.org
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

Re: `shutdown -p now` fails to power off with VirtualBox UEFI boot

[Michael Tuexen]

> On 22. Jun 2020, at 16:57, Warner Losh  wrote:
> 
> On Mon, Jun 22, 2020 at 4:14 AM Yasuhiro KIMURA  wrote:
> 
>> From: Yasuhiro KIMURA 
>> Subject: Re: `shutdown -p now` fails to power off with VirtualBox UEFI boot
>> Date: Mon, 22 Jun 2020 16:45:23 +0900 (JST)
>> 
>>> I tried bisect and found this problem happens with r342108 and
>>> after. Commit message of r342108 says as following.
>>> 
>>> yasu@rolling-vm-freebsd5[1012]% LANG=C svn log -c 342108
>>> 
>>> r342108 | cem | 2018-12-15 14:46:04 +0900 (Sat, 15 Dec 2018) | 7 lines
>>> 
>>> efirt: When present, attempt to use EFI runtime services to shutdown
>>> 
>>> PR: maybe related to 233998 (inconclusive at this time)
>>> Submitted by:   byuu  (previous version)
>>> Reviewed by:imp
>>> Differential Revision:  https://reviews.freebsd.org/D18506
>>> 
>>> 
>>> yasu@rolling-vm-freebsd5[1013]%
>>> 
>>> Judging from it, I think it's very likely that this commit caused the
>>> problem.
>>> 
>>> Then is there anything I can do for further investigation?
>> 
>> I submitted this problem to Bugzilla.
>> 
>> Bug 247474 - `shutdown -p now` fails to power off with VirtualBox UEFI boot
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247474
>> 
> 
> Does setting the tunable hw.efi.poweroff=0 help you?
That works for me (FreeBSD head on Virtual Box, latest release, on Mac OS).

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

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

Re: ? ????? ??: vnc can't connect to socket

[Michael Tuexen]

> On 21. Jun 2020, at 23:12, Rodney W. Grimes  
> wrote:
> 
>>> On Sun, 2020-06-21 at 14:54 +0200, Michael Tuexen wrote:
>>>>> On 21. Jun 2020, at 14:28, Kostya Berger 
>>>>> wrote:
>>>>> 
>>>>> Ok, it turns out, it gives the previously mentioned error only if I
>>>>> use VNC server string 0.0.0.0:5900 (as I always did). in my VNC
>>>>> client.But when replaced with127.0.0.1:5900it connects all right.
>>>> 
>>>> I don't hink 0.0.0.0 is a valid destination address you can use in
>>>> connect(). Using 127.0.0.1 should
>>>> be fine.
>> 
>> I do not believe that this is a destination address when your talking
>> about 0.0.0.0:5900 on the VNC server side, that is a wild card accept
>> any address and if this has been broken.. it must be fixed!
>> 
>>>> I guess, https://svnweb.freebsd.org/changeset/base/361752 is the
>>>> relevant commit here.
>>>> 
>>> 
>>> *BSD has always accepted 0 as a synonym for localhost (and iirc, linux
>>> does not).  If this no longer works, it's a regression which is going
>>> to cause existing applications and scripts to fail.  At the very least
>>> it deserves an entry in UPDATING.
>> 
>> I am not aware of that, but can not deny it either, and just confirmed
>> it to be true:
>> root {1002}# telnet 0.0.0.0 22
>> Trying 0.0.0.0...
>> Connected to 0.0.0.0.
>> Escape character is '^]'.
>> SSH-2.0-OpenSSH_7.8 FreeBSD-20180909
> 
> And to add the netstat data to show what connected:
> tcp4   0  0 127.0.0.1.22   127.0.0.1.43135ESTABLISHED
> tcp4  38  0 127.0.0.1.43135127.0.0.1.22   ESTABLISHED
> 
> Can we back this commit out, discuss it in next weeks call,
> and then find a way forward?
> 
>> 
>> INADDR_ANY is the wildcard listen address, but as a destination what code 
>> remapped
>> it to 127.0.0.1?
>> 
>> We should very seriously consider restoring this behavior.
Reallowing 0.0.0.0 is covered by https://reviews.freebsd.org/D25401

Best regards
Michael
>> 
>>> -- Ian
>>> 
>>>> Best regards
>>>> Michael
>>>>> ?? ?? Yahoo ? ??? Android 
>>>>> 
>>>>> ??, 21 ???. 2020 ? 9:40 Kostya Berger
>>>>> ???(-?):   Hi,upgraded to 362292 via buildworld.Now I cannot
>>>>> connect to my bhyve guest as I used to: neither via VNC nor via
>>>>> RDP.VNC gets error: unable to connect the socket. Address family
>>>>> not supported by protocol family (47).
>>>>> Neither can I ping my bhyve IP (it uses a separate NIC and should
>>>>> have no problems)
>>>>> Internet connectivity is ok and I can ping other hosts on my
>>>>> network.
>>>>> In 359997 all works fine.
>>>>> ?? ?? Yahoo ? ??? Android  
>>>>> ___
>>>>> freebsd-current@freebsd.org mailing list
>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>>> To unsubscribe, send any mail to "
>>>>> freebsd-current-unsubscr...@freebsd.org"
>>>> 
>>>> ___
>>>> freebsd-current@freebsd.org mailing list
>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>> To unsubscribe, send any mail to "
>>>> freebsd-current-unsubscr...@freebsd.org"
>>>> 
>>> 
>>> ___
>>> freebsd-current@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>>> 
>>> 
>> 
>> -- 
>> Rod Grimes 
>> rgri...@freebsd.org
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>> 
> 
> -- 
> Rod Grimes rgri...@freebsd.org

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

Re: ? ????? ??: vnc can't connect to socket

[Michael Tuexen]

> On 21. Jun 2020, at 23:12, Rodney W. Grimes  
> wrote:
> 
>>> On Sun, 2020-06-21 at 14:54 +0200, Michael Tuexen wrote:
>>>>> On 21. Jun 2020, at 14:28, Kostya Berger 
>>>>> wrote:
>>>>> 
>>>>> Ok, it turns out, it gives the previously mentioned error only if I
>>>>> use VNC server string 0.0.0.0:5900 (as I always did). in my VNC
>>>>> client.But when replaced with127.0.0.1:5900it connects all right.
>>>> 
>>>> I don't hink 0.0.0.0 is a valid destination address you can use in
>>>> connect(). Using 127.0.0.1 should
>>>> be fine.
>> 
>> I do not believe that this is a destination address when your talking
>> about 0.0.0.0:5900 on the VNC server side, that is a wild card accept
>> any address and if this has been broken.. it must be fixed!
>> 
>>>> I guess, https://svnweb.freebsd.org/changeset/base/361752 is the
>>>> relevant commit here.
>>>> 
>>> 
>>> *BSD has always accepted 0 as a synonym for localhost (and iirc, linux
>>> does not).  If this no longer works, it's a regression which is going
>>> to cause existing applications and scripts to fail.  At the very least
>>> it deserves an entry in UPDATING.
>> 
>> I am not aware of that, but can not deny it either, and just confirmed
>> it to be true:
>> root {1002}# telnet 0.0.0.0 22
>> Trying 0.0.0.0...
>> Connected to 0.0.0.0.
>> Escape character is '^]'.
>> SSH-2.0-OpenSSH_7.8 FreeBSD-20180909
> 
> And to add the netstat data to show what connected:
> tcp4   0  0 127.0.0.1.22   127.0.0.1.43135ESTABLISHED
> tcp4  38  0 127.0.0.1.43135127.0.0.1.22   ESTABLISHED
> 
> Can we back this commit out, discuss it in next weeks call,
> and then find a way forward?
The commit changes the behaviour of calling connect(..., addr, ...) on a 
TCP/IPv4 socket by

(a) failing it and indicating EAFNOSUPPORT if addr == 255.255.255.255
(b) failing it and indicating EAFNOSUPPORT if addr == 0.0.0.0

I think it is correct in doing (a). There is no doubt about that, since TCP only
supports unicast.

(b) can be changed. As we discussed, for IPv6 connecting to ::0 is changed to 
::1 in
https://svnweb.freebsd.org/base/head/sys/netinet6/in6_pcb.c?view=markup#l370.
However, in_pcbladdr() does not do that mapping. 

Let me figure out why 0.0.0.0 works as an address you can connect to. Then I can
prepare a patch to allow 0.0.0.0 again. I don't see a reason why we need to 
revert
r361752 and introduce it partially again. OK?

Best regards
Michael
> 
>> 
>> INADDR_ANY is the wildcard listen address, but as a destination what code 
>> remapped
>> it to 127.0.0.1?
>> 
>> We should very seriously consider restoring this behavior.
>> 
>>> -- Ian
>>> 
>>>> Best regards
>>>> Michael
>>>>> ?? ?? Yahoo ? ??? Android 
>>>>> 
>>>>> ??, 21 ???. 2020 ? 9:40 Kostya Berger
>>>>> ???(-?):   Hi,upgraded to 362292 via buildworld.Now I cannot
>>>>> connect to my bhyve guest as I used to: neither via VNC nor via
>>>>> RDP.VNC gets error: unable to connect the socket. Address family
>>>>> not supported by protocol family (47).
>>>>> Neither can I ping my bhyve IP (it uses a separate NIC and should
>>>>> have no problems)
>>>>> Internet connectivity is ok and I can ping other hosts on my
>>>>> network.
>>>>> In 359997 all works fine.
>>>>> ?? ?? Yahoo ? ??? Android  
>>>>> ___
>>>>> freebsd-current@freebsd.org mailing list
>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>>> To unsubscribe, send any mail to "
>>>>> freebsd-current-unsubscr...@freebsd.org"
>>>> 
>>>> ___
>>>> freebsd-current@freebsd.org mailing list
>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>> To unsubscribe, send any mail to "
>>>> freebsd-current-unsubscr...@freebsd.org"
>>>> 
>>> 
>>> ___
>>> freebsd-current@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>>> 
>>> 
>> 
>> -- 
>> Rod Grimes 
>> rgri...@freebsd.org
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>> 
> 
> -- 
> Rod Grimes rgri...@freebsd.org

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

Re: В ответ на: vnc can't connect to socket

[Michael Tuexen]

> On 21. Jun 2020, at 20:02, Ian Lepore  wrote:
> 
> On Sun, 2020-06-21 at 19:54 +0200, Michael Tuexen wrote:
>>> On 21. Jun 2020, at 19:40, Ian Lepore  wrote:
>>> 
>>> On Sun, 2020-06-21 at 14:54 +0200, Michael Tuexen wrote:
>>>>> On 21. Jun 2020, at 14:28, Kostya Berger >>>>> 
>>>>> wrote:
>>>>> 
>>>>> Ok, it turns out, it gives the previously mentioned error only
>>>>> if I
>>>>> use VNC server string 0.0.0.0:5900 (as I always did). in my VNC
>>>>> client.But when replaced with127.0.0.1:5900it connects all
>>>>> right.
>>>> 
>>>> I don't hink 0.0.0.0 is a valid destination address you can use
>>>> in
>>>> connect(). Using 127.0.0.1 should
>>>> be fine.
>>>> 
>>>> I guess, https://svnweb.freebsd.org/changeset/base/361752 is the
>>>> relevant commit here.
>>>> 
>>> 
>>> *BSD has always accepted 0 as a synonym for localhost (and iirc, linux
>>> does not).  If this no longer works, it's a regression which is going
>>> to cause existing applications and scripts to fail.  At the very least
>>> it deserves an entry in UPDATING.
>> 
>> Hmm. 0.0.0.0 is a wildcard address, meaning any of my local addresses.
>> I do understand how that works for binding a TCP socket you will be
>> listening on. It just means accept TCP connections on all addresses.
>> The destination address of the incoming SYN segment will determine which
>> one to use. However, which of the local addresses should be used
>> when calling connect() with 0.0.0.0? How should this choice be made?
>> 
>> Best regards
>> Michael
>> 
> 
> I don't know.  I had thought the idea was sanctioned by a couple RFCs,
> but I just had a fresh look at them (1122, 5735) and it now appears to
> me that in both cases it sanctions using 0.0.0.0 as a source address,
> but not as a destination.  So now I'm thinking maybe it has been a
You can use 0.0.0.0 as a source address in specific packets (mainly
ones where you don't know your local address like during address
configuration), but you can't use it as a destination address.

In the TCP case (which is we are looking at), you can't use it
as a source or destination address.

However, this issue is not about addresses in packets, but
address usage in the API, the connect() call for TCP in particular.
> historical mistake amongst the BSDs to accept it as a destination
> address synonym for 127.0.0.1.
That might be possible. But it would be much better to use 127.0.0.1
if you mean it.
> 
> I was mostly just pointing out this change to no longer accept it is
> going to be a big surprise to many people when it hits the streets in a
> release.  I know it's going to break things at $work, we'll have to
> start combing around for uses of it and make changes.  (Fixing my 20+
> years of finger-memory for "nc 0 " will be harder.)
OK. I'll bring that up in the bi-weekly transport telco.
It was clear to disallow multicast, but the patch also wanted to
deal with 0.0.0.0. For IPv6, there is such a mapping from
connect(::0) to connect(::1). So for consistency it might make
sense to do/keep the same for IPv4. I need to look at the code
why this is working at all for IPv4 as you say it is.

Best regards
Michael
> 
> -- Ian
> 
> 

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

Re: В ответ на: vnc can't connect to socket

[Michael Tuexen]

> On 21. Jun 2020, at 19:40, Ian Lepore  wrote:
> 
> On Sun, 2020-06-21 at 14:54 +0200, Michael Tuexen wrote:
>>> On 21. Jun 2020, at 14:28, Kostya Berger 
>>> wrote:
>>> 
>>> Ok, it turns out, it gives the previously mentioned error only if I
>>> use VNC server string 0.0.0.0:5900 (as I always did). in my VNC
>>> client.But when replaced with127.0.0.1:5900it connects all right.
>> 
>> I don't hink 0.0.0.0 is a valid destination address you can use in
>> connect(). Using 127.0.0.1 should
>> be fine.
>> 
>> I guess, https://svnweb.freebsd.org/changeset/base/361752 is the
>> relevant commit here.
>> 
> 
> *BSD has always accepted 0 as a synonym for localhost (and iirc, linux
> does not).  If this no longer works, it's a regression which is going
> to cause existing applications and scripts to fail.  At the very least
> it deserves an entry in UPDATING.
Hmm. 0.0.0.0 is a wildcard address, meaning any of my local addresses.
I do understand how that works for binding a TCP socket you will be
listening on. It just means accept TCP connections on all addresses.
The destination address of the incoming SYN segment will determine which
one to use. However, which of the local addresses should be used
when calling connect() with 0.0.0.0? How should this choice be made?

Best regards
Michael
> 
> -- Ian
> 
>> Best regards
>> Michael
>>> Отправлено из Yahoo Почты для Android 
>>> 
>>> вс, 21 июн. 2020 в 9:40 Kostya Berger
>>> написал(-а):   Hi,upgraded to 362292 via buildworld.Now I cannot
>>> connect to my bhyve guest as I used to: neither via VNC nor via
>>> RDP.VNC gets error: unable to connect the socket. Address family
>>> not supported by protocol family (47).
>>> Neither can I ping my bhyve IP (it uses a separate NIC and should
>>> have no problems)
>>> Internet connectivity is ok and I can ping other hosts on my
>>> network.
>>> In 359997 all works fine.
>>> Отправлено из Yahoo Почты для Android  
>>> ___
>>> freebsd-current@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "
>>> freebsd-current-unsubscr...@freebsd.org"
>> 
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "
>> freebsd-current-unsubscr...@freebsd.org"
>> 
> 

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

Re: В ответ на: vnc can't connect to socket

[Michael Tuexen]

> On 21. Jun 2020, at 14:28, Kostya Berger  wrote:
> 
> Ok, it turns out, it gives the previously mentioned error only if I use VNC 
> server string 0.0.0.0:5900 (as I always did). in my VNC client.But when 
> replaced with127.0.0.1:5900it connects all right.
I don't hink 0.0.0.0 is a valid destination address you can use in connect(). 
Using 127.0.0.1 should
be fine.

I guess, https://svnweb.freebsd.org/changeset/base/361752 is the relevant 
commit here.

Best regards
Michael
> Отправлено из Yahoo Почты для Android 
> 
> вс, 21 июн. 2020 в 9:40 Kostya Berger написал(-а):   
> Hi,upgraded to 362292 via buildworld.Now I cannot connect to my bhyve guest 
> as I used to: neither via VNC nor via RDP.VNC gets error: unable to connect 
> the socket. Address family not supported by protocol family (47).
> Neither can I ping my bhyve IP (it uses a separate NIC and should have no 
> problems)
> Internet connectivity is ok and I can ping other hosts on my network.
> In 359997 all works fine.
> Отправлено из Yahoo Почты для Android  
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

Re: gcc versus clang issue for 32-bit binaries

[Michael Tuexen]

> On 10. Jun 2020, at 20:30, Damjan Jovanovic  wrote:
> 
> MAP_FIXED is generally bad news, as it overwrites any prior mappings within 
> the range of addresses being mapped to.
> 
> They should use MAP_FIXED | MAP_EXCL instead, which will fail if any mappings 
> already exist in the range, and then maybe retry with another range if it 
> fails. Linux and NetBSD have MAP_TRYFIXED instead, which does the retrying 
> internally. Or at the very least, run mincore() on every page in the range to 
> verify that nothing is mapped before using mmap() with MAP_FIXED.
It is used in syzkaller. Some go code generates C include files... So right now 
I might want
to stick with a value.
> 
> If there is no other way but to use a single hardcoded value, check 
> /proc//map for a number of different processes, 32 and 64 bit, and find 
> an address range that isn't used often.
Thanks for the hint. I tried to find one. Let's see how good this guess is.

Best regards
Michael
> 
> Damjan
> 
> 
> On Wed, Jun 10, 2020 at 7:40 PM Michael Tuexen  wrote:
> > On 10. Jun 2020, at 18:59, Mark Johnston  wrote:
> > 
> > On Wed, Jun 10, 2020 at 06:41:50PM +0200, Michael Tuexen wrote:
> >> Dear all,
> >> 
> >> consider the following program test.c:
> >> 
> >> #include 
> >> #include 
> >> 
> >> int 
> >> main(void)
> >> {
> >>  void *p;
> >>  
> >>  p = mmap((void *)0x2000, 0x100, PROT_READ | PROT_WRITE | 
> >> PROT_EXEC, MAP_ANON | MAP_PRIVATE | MAP_FIXED, -1, 0);
> >>  printf("p= %p\n", p);
> >>  return (0);
> >> }
> >> 
> >> On i386 the following happens:
> >> * when compiling it with cc and running it, it crashes.
> >> * when compiling it with gcc it runs fine.
> >> 
> >> On amd64 the following happens:
> >> * when compiling it with cc -m64 it runs fine.
> >> * when compiling it with cc -m32 is crashes.
> >> * when compiling it with gcc -m64 it runs fine.
> >> * when compiling it with gcc -m32 it runs fine.
> >> 
> >> So why does the above program crash when compiled for 32-bit when using 
> >> clang, but runs fine when compiled with gcc.
> > 
> > The difference is between ld.bfd and ld.lld, which emit executables with
> > different entry point addresses.  cc -m32 -fuse-ld=bfd gives an
> > executable that does not crash.
> > 
> > When linked with lld, libc and ld-elf get mapped into the region
> > [0x2000,0x2100], so the program crashes when the libc.so mapping
> > is overwritten with that created by the mmap() call and the program
> > calls printf().
> > 
> >> I'm testing this on 32-bit and 64-bit head systems. gcc is from ports.
> >> 
> >> The reason I'm looking into it is that I want to get syzkaller working on 
> >> 32-bit with clang.
> > 
> > Do you know why SYZ_DATA_OFFSET is hard-coded the way it is?  It looks
> > like it works more or less by accident, but at a glance I don't see why
> > it has to be a fixed mapping.
> I don't know, it comes from:
> https://github.com/google/syzkaller/blob/master/sys/targets/targets.go#L450
> 
> Do you have a value which can be used on FreeBSD? Then we can just change 
> it...
> 
> Best regards
> Michael
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

Re: gcc versus clang issue for 32-bit binaries

[Michael Tuexen]

> On 10. Jun 2020, at 18:59, Mark Johnston  wrote:
> 
> On Wed, Jun 10, 2020 at 06:41:50PM +0200, Michael Tuexen wrote:
>> Dear all,
>> 
>> consider the following program test.c:
>> 
>> #include 
>> #include 
>> 
>> int 
>> main(void)
>> {
>>  void *p;
>>  
>>  p = mmap((void *)0x2000, 0x100, PROT_READ | PROT_WRITE | 
>> PROT_EXEC, MAP_ANON | MAP_PRIVATE | MAP_FIXED, -1, 0);
>>  printf("p= %p\n", p);
>>  return (0);
>> }
>> 
>> On i386 the following happens:
>> * when compiling it with cc and running it, it crashes.
>> * when compiling it with gcc it runs fine.
>> 
>> On amd64 the following happens:
>> * when compiling it with cc -m64 it runs fine.
>> * when compiling it with cc -m32 is crashes.
>> * when compiling it with gcc -m64 it runs fine.
>> * when compiling it with gcc -m32 it runs fine.
>> 
>> So why does the above program crash when compiled for 32-bit when using 
>> clang, but runs fine when compiled with gcc.
> 
> The difference is between ld.bfd and ld.lld, which emit executables with
> different entry point addresses.  cc -m32 -fuse-ld=bfd gives an
> executable that does not crash.
> 
> When linked with lld, libc and ld-elf get mapped into the region
> [0x2000,0x2100], so the program crashes when the libc.so mapping
> is overwritten with that created by the mmap() call and the program
> calls printf().
> 
>> I'm testing this on 32-bit and 64-bit head systems. gcc is from ports.
>> 
>> The reason I'm looking into it is that I want to get syzkaller working on 
>> 32-bit with clang.
> 
> Do you know why SYZ_DATA_OFFSET is hard-coded the way it is?  It looks
> like it works more or less by accident, but at a glance I don't see why
> it has to be a fixed mapping.
It looks like 0x1000 works fine on my 32-bit VM.
I added you as a reviewer on https://github.com/google/syzkaller/pull/1809

Best regards
Michael


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

Re: gcc versus clang issue for 32-bit binaries

[Michael Tuexen]

> On 10. Jun 2020, at 18:59, Mark Johnston  wrote:
> 
> On Wed, Jun 10, 2020 at 06:41:50PM +0200, Michael Tuexen wrote:
>> Dear all,
>> 
>> consider the following program test.c:
>> 
>> #include 
>> #include 
>> 
>> int 
>> main(void)
>> {
>>  void *p;
>>  
>>  p = mmap((void *)0x2000, 0x100, PROT_READ | PROT_WRITE | 
>> PROT_EXEC, MAP_ANON | MAP_PRIVATE | MAP_FIXED, -1, 0);
>>  printf("p= %p\n", p);
>>  return (0);
>> }
>> 
>> On i386 the following happens:
>> * when compiling it with cc and running it, it crashes.
>> * when compiling it with gcc it runs fine.
>> 
>> On amd64 the following happens:
>> * when compiling it with cc -m64 it runs fine.
>> * when compiling it with cc -m32 is crashes.
>> * when compiling it with gcc -m64 it runs fine.
>> * when compiling it with gcc -m32 it runs fine.
>> 
>> So why does the above program crash when compiled for 32-bit when using 
>> clang, but runs fine when compiled with gcc.
> 
> The difference is between ld.bfd and ld.lld, which emit executables with
> different entry point addresses.  cc -m32 -fuse-ld=bfd gives an
> executable that does not crash.
> 
> When linked with lld, libc and ld-elf get mapped into the region
> [0x2000,0x2100], so the program crashes when the libc.so mapping
> is overwritten with that created by the mmap() call and the program
> calls printf().
> 
>> I'm testing this on 32-bit and 64-bit head systems. gcc is from ports.
>> 
>> The reason I'm looking into it is that I want to get syzkaller working on 
>> 32-bit with clang.
> 
> Do you know why SYZ_DATA_OFFSET is hard-coded the way it is?  It looks
> like it works more or less by accident, but at a glance I don't see why
> it has to be a fixed mapping.
I don't know, it comes from:
https://github.com/google/syzkaller/blob/master/sys/targets/targets.go#L450

Do you have a value which can be used on FreeBSD? Then we can just change it...

Best regards
Michael

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

gcc versus clang issue for 32-bit binaries

[Michael Tuexen]

Dear all,

consider the following program test.c:

#include 
#include 

int 
main(void)
{
void *p;

p = mmap((void *)0x2000, 0x100, PROT_READ | PROT_WRITE | 
PROT_EXEC, MAP_ANON | MAP_PRIVATE | MAP_FIXED, -1, 0);
printf("p= %p\n", p);
return (0);
}

On i386 the following happens:
* when compiling it with cc and running it, it crashes.
* when compiling it with gcc it runs fine.

On amd64 the following happens:
* when compiling it with cc -m64 it runs fine.
* when compiling it with cc -m32 is crashes.
* when compiling it with gcc -m64 it runs fine.
* when compiling it with gcc -m32 it runs fine.

So why does the above program crash when compiled for 32-bit when using clang, 
but runs fine when compiled with gcc.
I'm testing this on 32-bit and 64-bit head systems. gcc is from ports.

The reason I'm looking into it is that I want to get syzkaller working on 
32-bit with clang.

Best regards
Michael

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

Re: Error loading tcp_bbr kernel module

[Michael Tuexen]

> On 9. May 2020, at 18:07, Gordon Bergling  wrote:
> 
> Hi Michael,
> 
> On Sat, May 09, 2020 at 05:42:55PM +0200, Michael Tuexen wrote:
>>> On 9. May 2020, at 16:25, Gordon Bergling  wrote:
>>> I tried tcp_rack and tcp_bbr, since both are separate TCP stacks. I just 
>>> posted the wrong error message. Both TCP stacks weren’t loadable as a 
>>> kernel module with just the former mentioned build option.
>>> 
>>> I currently have build running with both kernel options  you mentioned.
>>> 
>>> If the build is successful and I can change the default TCP stack to RACK 
>>> and BBR I let you know.
>> That would be great. I have them running on my machines, but I might have 
>> missed something.
>>> 
>>> Further I didn’t find any documentation within tcp(4) regarding RACK and 
>>> BBR. Since I am about to enhance the manpages, I’ll extent tcp(4) about 
>>> information about RACK and BBR, but this is a different topic.
>>> 
>> Yes it is. And I would suggest to use separate man pages, a single one for 
>> each stack.
>> The the generic man page might refer to them...
> 
> My first thoughts on this topic were about to extent tcp(4) and create links 
> to
> tcp_rack(4) and tcp_bbr(4), but separate manpages maybe the way to go. I just
> have to investigate the respective details. I was once very deep into TCP/IP, 
> while building perimeter firewalls with FreeBSD, but this was 20 years ago.
> 
> I add you as a reviever for the differential once I have a rough cut 
> for the manpages ready.
Hi Gordon,

please do so. Don't forget to add rrs@, since he wrote both stacks.

Best regards
Michael
> 
> Best regards,
> 
> Gordon
> 
>>>> Am 09.05.2020 um 14:37 schrieb Michael Tuexen :
>>>>> On 9. May 2020, at 14:18, Gordon Bergling  
>>>>> wrote:
>>>>> 
>>>>> Greetings,
>>>>> 
>>>>> I build -CURRENT with WITH_EXTRA_TCP_STACKS=1, but I got the following 
>>>>> error
>>>>> when I try to load for example tcp_bbr.ko.
>>>>> z
>>>>> kldload: an error occurred while loading module tcp_rack.ko. Please check 
>>>>> dmesg(8) for more details.
>>>> This indicates that you want to load the RACK stack.
>>>> 
>>>> Please note that you need for BBR and RACK:
>>>> optionsTCPHPTS
>>>> in the kernel config and in addition to that for RACK
>>>> optionsRATELIMIT
>>>> 
>>>>> dmesg shows:
>>>>> 
>>>>> KLD tcp_bbr.ko: depends on tcphpts - not available or version mismatch
>>>>> linker_load_file: /boot/kernel/tcp_bbr.ko - unsupported file type
>>>>> 
>>>>> Any hints on solving the problem?
>>>>> 
>>>>> The kernel config is GENERIC.
>>>>> 
>>>>> Best regards,
>>>>> 
>>>>> Gordon

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

Re: Error loading tcp_bbr kernel module

[Michael Tuexen]

> On 9. May 2020, at 16:25, Gordon Bergling  wrote:
> 
> Hi Michael,
> 
> thanks for your reply.
> 
> I tried tcp_rack and tcp_bbr, since both are separate TCP stacks. I just 
> posted the wrong error message. Both TCP stacks weren’t loadable as a kernel 
> module with just the former mentioned build option.
> 
> I currently have build running with both kernel options  you mentioned.
> 
> If the build is successful and I can change the default TCP stack to RACK and 
> BBR I let you know.
That would be great. I have them running on my machines, but I might have 
missed something.
> 
> Further I didn’t find any documentation within tcp(4) regarding RACK and BBR. 
> Since I am about to enhance the manpages, I’ll extent tcp(4) about 
> information about RACK and BBR, but this is a different topic.
> 
Yes it is. And I would suggest to use separate man pages, a single one for each 
stack.
The the generic man page might refer to them...

Best regards
Michael
> Best regards,
> 
> Gordon
> 
>> Am 09.05.2020 um 14:37 schrieb Michael Tuexen :
>> 
>>> On 9. May 2020, at 14:18, Gordon Bergling  wrote:
>>> 
>>> Greetings,
>>> 
>>> I build -CURRENT with WITH_EXTRA_TCP_STACKS=1, but I got the following error
>>> when I try to load for example tcp_bbr.ko.
>>> z
>>> kldload: an error occurred while loading module tcp_rack.ko. Please check 
>>> dmesg(8) for more details.
>> This indicates that you want to load the RACK stack.
>> 
>> Please note that you need for BBR and RACK:
>> options  TCPHPTS
>> in the kernel config and in addition to that for RACK
>> options  RATELIMIT
>> 
>> Best regards
>> Michael
>>> 
>>> dmesg shows:
>>> 
>>> KLD tcp_bbr.ko: depends on tcphpts - not available or version mismatch
>>> linker_load_file: /boot/kernel/tcp_bbr.ko - unsupported file type
>>> 
>>> Any hints on solving the problem?
>>> 
>>> The kernel config is GENERIC.
>>> 
>>> Best regards,
>>> 
>>> Gordon
>>> ___
>>> freebsd-current@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>> 
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

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

Re: Error loading tcp_bbr kernel module

[Michael Tuexen]

> On 9. May 2020, at 14:18, Gordon Bergling  wrote:
> 
> Greetings,
> 
> I build -CURRENT with WITH_EXTRA_TCP_STACKS=1, but I got the following error
> when I try to load for example tcp_bbr.ko.
> z
> kldload: an error occurred while loading module tcp_rack.ko. Please check 
> dmesg(8) for more details.
This indicates that you want to load the RACK stack.

Please note that you need for BBR and RACK:
options TCPHPTS
in the kernel config and in addition to that for RACK
options RATELIMIT

Best regards
Michael
> 
> dmesg shows:
> 
> KLD tcp_bbr.ko: depends on tcphpts - not available or version mismatch
> linker_load_file: /boot/kernel/tcp_bbr.ko - unsupported file type
> 
> Any hints on solving the problem?
> 
> The kernel config is GENERIC.
> 
> Best regards,
> 
> Gordon
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

Re: How to enable tcp bbr in FreeBSD???

[Michael Tuexen]

> On 26. Apr 2020, at 15:09, Randall Stewart  wrote:
> 
> I am thinking that this really needs to have
> a deeper support in the transport.
> 
> I see that OOB is even in socket_dgram process and there
> are comments in there that indicate it may be a problem.. I 
> know UDP does not support it.
> 
> So I think what is needed here is
> 
> 1) a new pru_method that at send/rcv it can query if PRUS_EOF  PRUS_OOB
>   is supported.
Not sure what you need to check for PRUS_EOF?
> 2) For UDP either query would return false.
> 3) For TCP this would resolve to a stack specific query. For the 
>   freebsd stack, it would return true for both, for Rack or BBR
>   you would get True for PRUS_EOF and False for PRUS_OOB. This way
>   you could capture an error in any case by adding a check at the
>   top of send/recv and immediately return an error as appropriate.
> 4) I would also think like all pru methods, you get a default of true/true
>   so that way I guess unix domain sockets would continue as they are (not
>   sure if they support these or not I should probably look)
Hmm. Thinking about this:

I guess we want to focus on TCP, since my understanding is that the
problem is that some TCP stacks do support OOB, some don't. So you
can't query that right now via a TCP value.

So couldn't we check in tcp_usr_send() if the stack currently being
used for the socket support OOB? It would be a stack specific value.
Such a change should fix this issue and does not impact other protocols.

Best regards
Michael
> 
> 
> R
> 
>> On Apr 26, 2020, at 8:55 AM, Randall Stewart  wrote:
>> 
>> Sure..
>> 
>> I will take a look at it. 
>> 
>> R
>> 
>>> On Apr 26, 2020, at 8:51 AM, Michael Tuexen 
>>>  wrote:
>>> 
>>> 
>>> 
>>>> On 26. Apr 2020, at 13:34, Randall Stewart via freebsd-transport 
>>>>  wrote:
>>>> 
>>>> I have pulled down the reproducers.. one thing to note
>>>> is they are all rack (though it could be that the problems
>>>> are also in BBR). And of course FreeBSD is behind NF in
>>>> rack at least.
>>>> 
>>>> I need to work on getting things updated.. one thing Michael, 
>>>> both Rack and BBR in NF have lost the OOB handling. Please do
>>>> not commit any more changes to Rack .. since that work has already
>>>> been done.
>>> I understand that the support of MSG_OOB is gone, but if you want
>>> to return an error to the user when he uses MSG_OOB, you need to
>>> trigger this error in the protocol specific code.
>>> 
>>> I don't think we can return an error in all cases (also for the
>>> default stack), since that would change existing behaviour.
>>> 
>>> I leave this up to you.
>>> 
>>> Best regards
>>> Michael
>>>> 
>>>> R
>>>> 
>>>>> On Apr 26, 2020, at 7:28 AM, Randall Stewart  wrote:
>>>>> 
>>>>> This is actually the first I have heard of these bugs…
>>>>> 
>>>>> I will have look at them Mark.
>>>>> 
>>>>> R
>>>>> 
>>>>>> On Apr 24, 2020, at 10:23 AM, Mark Johnston  wrote:
>>>>>> 
>>>>>> On Fri, Apr 24, 2020 at 03:15:08PM +0100, Tom Jones wrote:
>>>>>>> r...@freebsd.org
>>>>>>> Bcc: 
>>>>>>> Subject: Re: How to enable tcp bbr in FreeBSD???
>>>>>>> Reply-To: 
>>>>>>> In-Reply-To: <6042155a-297b-d85e-1d64-24d93da32...@gmail.com>
>>>>>>> 
>>>>>>> 
>>>>>>> ... snip ...
>>>>>>>> 
>>>>>>>> Maybe it is not ready for prime time, i do not know why it is not in 
>>>>>>>> the
>>>>>>>> default build.
>>>>>>>> Maybe ask the committer.
>>>>>>>> 
>>>>>>> 
>>>>>>> I have added rrs@ in cc and the freebsd-transport list. 
>>>>>>> 
>>>>>>> Does anyone know if there are plans to enable alternate TCP stacks in
>>>>>>> generic? 
>>>>>>> 
>>>>>>> Is there a stability point we need to hit first?
>>>>>> 
>>>>>> There are a couple of open bugs found by syzkaller (complete with
>>>>>> reproducers) that appeared when I enabled the alternate TCP stacks:
>>>>>> 
>>>>>> https://syzkalle

Re: Compiling MOD_CC into kernel (TCP congestion control)?

[Michael Tuexen]

> On 25. Apr 2020, at 19:28, Hartmann, O.  wrote:
> 
> On a firewall/router project of ours I try to experiment with several
> options/algorithms for mod_cc(4). The kernel is compiled statically, so
> that no kernel module can be loaded at runtime, therefor I need to
> compile the different modules mod_cc into the kernel.
> 
> The manpage mod_cc(4) states: " ... Algorithm modules can be compiled
> into the kernel or loaded as kernel modules ..."
> 
> Trying to figure out which manpage could hold the necessary information
> how to proceed with compiling those modules statically into the kernel,
> I tried tcp(4), mod_cc(4) and tried to get some informations from
> /usr/src/sys/conf/NOTES - without any succes.
> 
> Can someone point me to the correct manpage to perform the desired task?
Hi,

I can't point you to a man page, but do you get what you want if you add
lines like the existing one
netinet/cc/cc_newreno.c optional inet | inet6
to sys/conf/files for the CC modules you would like to get compiled in your
kernel?

Best regards
Michael
> 
> Thanks in advance,
> kind regards
> 
> O. Hartmann

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

Re: How to enable tcp bbr in FreeBSD???

[Michael Tuexen]

> On 24. Apr 2020, at 23:41, Neel Chauhan  wrote:
> 
> Not OP, but would BBR work with VNET, or is that a WIP?
I would say it should work. At least, if not I would consider it a bug.
I think most testing was not done with multiple VNETs.

Best regards
Michael
> 
> I'm sorry if none of you are familiar with VNET.
> 
> -Neel
> 
> ===
> 
> https://www.neelc.org/
> BTW: Not neel@ the committer
> 
> On 2020-04-24 12:25, Michael Tuexen wrote:
>>> On 24. Apr 2020, at 21:06, Rodney W. Grimes  
>>> wrote:
>>>> On Fri, Apr 24, 2020 at 01:31:35PM +0200, Kurt Jaeger wrote:
>>>>> Thanks. Is BBR active automatically or is there a sysctl or
>>>>> socket option to activate it ?
>>>> net.inet.tcp.cc.available: List available congestion control algorithms
>>>> net.inet.tcp.cc.algorithm: Default congestion control algorithm
>>> Start at:
>>> man mod_cc
>> BBR is conceptually a CC, but in FreeBSD it is NOT implemented as a CC 
>> module.
>> It is a TCP stack. You need to load it using
>> kldload tcp_bbr
>> and then either make it the default by
>> sudo sysctl net.inet.tcp.functions_default=bbr
>> or use the IPPROTO_TCP level socket option TCP_FUNCTION_BLK to set the stack
>> to BBR. The uperf test tool allows to set the TCP stack for measurements.
>> Please note that you need to compile the kernel with
>> makeoptions  WITH_EXTRA_TCP_STACKS=1
>> options  TCPHPTS
>> Best regards
>> Michael
>>> --
>>> Rod Grimes 
>>> rgri...@freebsd.org
>>> ___
>>> freebsd-current@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

Re: How to enable tcp bbr in FreeBSD???

[Michael Tuexen]

> On 24. Apr 2020, at 21:06, Rodney W. Grimes  
> wrote:
> 
>> On Fri, Apr 24, 2020 at 01:31:35PM +0200, Kurt Jaeger wrote:
>>> 
>>> Thanks. Is BBR active automatically or is there a sysctl or
>>> socket option to activate it ?
>> 
>> net.inet.tcp.cc.available: List available congestion control algorithms
>> net.inet.tcp.cc.algorithm: Default congestion control algorithm
> 
> Start at:
> man mod_cc
BBR is conceptually a CC, but in FreeBSD it is NOT implemented as a CC module.
It is a TCP stack. You need to load it using
kldload tcp_bbr
and then either make it the default by
sudo sysctl net.inet.tcp.functions_default=bbr
or use the IPPROTO_TCP level socket option TCP_FUNCTION_BLK to set the stack
to BBR. The uperf test tool allows to set the TCP stack for measurements.
Please note that you need to compile the kernel with
makeoptions WITH_EXTRA_TCP_STACKS=1
options TCPHPTS

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

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

Re: How to enable tcp bbr in FreeBSD???

[Michael Tuexen]

> On 24. Apr 2020, at 16:23, Mark Johnston  wrote:
> 
> On Fri, Apr 24, 2020 at 03:15:08PM +0100, Tom Jones wrote:
>> r...@freebsd.org
>> Bcc: 
>> Subject: Re: How to enable tcp bbr in FreeBSD???
>> Reply-To: 
>> In-Reply-To: <6042155a-297b-d85e-1d64-24d93da32...@gmail.com>
>> 
>> 
>> ... snip ...
>>> 
>>> Maybe it is not ready for prime time, i do not know why it is not in the
>>> default build.
>>> Maybe ask the committer.
>>> 
>> 
>> I have added rrs@ in cc and the freebsd-transport list. 
>> 
>> Does anyone know if there are plans to enable alternate TCP stacks in
>> generic? 
>> 
>> Is there a stability point we need to hit first?
> 
> There are a couple of open bugs found by syzkaller (complete with
> reproducers) that appeared when I enabled the alternate TCP stacks:
> 
> https://syzkaller.appspot.com/bug?id=986b4cecd84439df9794bda1a45d9cf0f50356fe
> https://syzkaller.appspot.com/bug?id=048f650e99696f881872a285cef0e3b9bd4f4e25
> 
> I'd expect these to be fixed before providing the alternate stacks in
> GENERIC.
We talked about these yesterday in the FreeBSD telco. At least some of them are
related to OOB data. The plan is to disable handling of OOB data in the 
alternate
stacks. Will bring up a patch and see if that fixes the issues.

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

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

Re: Pkg repository is broken...

[Michael Tuexen]

> On 7. Mar 2020, at 22:12, Andrey Fesenko  wrote:
> 
> On Sun, Mar 8, 2020 at 12:02 AM Michael Tuexen  wrote:
>> 
>> 
>> 
>>> On 7. Mar 2020, at 21:37, Michael Gmelin  wrote:
>>> 
>>> 
>>> 
>>>> On 7. Mar 2020, at 19:01, Michael Tuexen  wrote:
>>>> 
>>>> 
>>>>> 
>>>>>> On 7. Mar 2020, at 18:18, Michael Gmelin  wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On 7. Mar 2020, at 18:08, Michael Tuexen  wrote:
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> On 7. Mar 2020, at 16:46, Michael Gmelin  wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On Sat, 07 Mar 2020 11:30:58 -0400
>>>>>>>> Waitman Gobble  wrote:
>>>>>>>> 
>>>>>>>> On 2020-03-07 05:10, Ronald Klop wrote:
>>>>>>>>> On Sat, 07 Mar 2020 01:38:55 +0100, Greg 'groggy' Lehey
>>>>>>>>>  wrote:
>>>>>>>>> 
>>>>>>>>>> On Friday,  6 March 2020 at 12:29:44 +0100, Lars Engels wrote:
>>>>>>>>>>> On Wed, Mar 04, 2020 at 03:16:14PM +1100, Greg 'groggy' Lehey
>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Any workarounds in the meantime?  This must affect a lot of
>>>>>>>>>>>> people, including those who use 12-:
>>>>>>>>>>>> 
>>>>>>>>>>>> pkg: wrong architecture: FreeBSD:12.0:amd64 instead of
>>>>>>>>>>>> FreeBSD:12:amd64
>>>>>>>>>>>> pkg: repository FreeBSD contains packages with wrong ABI:
>>>>>>>>>>>> FreeBSD:12.0:amd64
>>>>>>>>>>> 
>>>>>>>>>>> Still broken for me on 12.1.
>>>>>>>>>> 
>>>>>>>>>> Strange.  Mine cleared up automatically the following day.
>>>>>>>>>> 
>>>>>>>>>> It's also strange how few replies I have received.  Two private
>>>>>>>>>> messages (why?), yours, and that was it.  You'd think that people
>>>>>>>>>> would be screaming.
>>>>>>>>>> 
>>>>>>>>>> Greg
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> I'm not screaming because I'm settling with the situation and
>>>>>>>>> starting to make workarounds.
>>>>>>>>> And wondering where the official communication of the community is.
>>>>>>>>> Nothing about this situation on www.freebsd.org. All information
>>>>>>>>> about the situation seems scattered through the mailinglists.
>>>>>>>>> 
>>>>>>>>> Things are working for me on 13-CURRENT again, but still broken on
>>>>>>>>> 12.1-RELEASE. See attachment.
>>>>>>>>> 
>>>>>>>>> Ronald.
>>>>>>>>> ___
>>>>>>>>> freebsd-current@freebsd.org mailing list
>>>>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>>>>>>> To unsubscribe, send any mail to
>>>>>>>>> "freebsd-current-unsubscr...@freebsd.org"
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Did you try:
>>>>>>>> pkg update -f
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I installed 12.1 on a new laptop yesterday, I have not experienced
>>>>>>>> issues with pkg.
>>>>>>>> 
>>>>>>> 
>>>>>>> This was only an issue on the "latest" branch. If you don't alter
>>>>>>> "/etc/pkg/FreeBSD.conf", you'll get packages from the "quarterly"
>>>>>>> branch, which fortunately wasn't affected.
>>>>>> 
>>>>>> Any idea what is wrong on a stable/12 machine:
>>>>>> 
>>>>>> tuexen@stable12:~ 

Re: Pkg repository is broken...

[Michael Tuexen]

> On 7. Mar 2020, at 21:37, Michael Gmelin  wrote:
> 
> 
> 
>> On 7. Mar 2020, at 19:01, Michael Tuexen  wrote:
>> 
>> 
>>> 
>>>> On 7. Mar 2020, at 18:18, Michael Gmelin  wrote:
>>>> 
>>>> 
>>>> 
>>>>> On 7. Mar 2020, at 18:08, Michael Tuexen  wrote:
>>>> 
>>>> 
>>>>> 
>>>>> On 7. Mar 2020, at 16:46, Michael Gmelin  wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Sat, 07 Mar 2020 11:30:58 -0400
>>>>>> Waitman Gobble  wrote:
>>>>>> 
>>>>>> On 2020-03-07 05:10, Ronald Klop wrote:
>>>>>>> On Sat, 07 Mar 2020 01:38:55 +0100, Greg 'groggy' Lehey
>>>>>>>  wrote:
>>>>>>> 
>>>>>>>> On Friday,  6 March 2020 at 12:29:44 +0100, Lars Engels wrote:  
>>>>>>>>> On Wed, Mar 04, 2020 at 03:16:14PM +1100, Greg 'groggy' Lehey
>>>>>>>>> wrote:  
>>>>>>>>>> 
>>>>>>>>>> Any workarounds in the meantime?  This must affect a lot of
>>>>>>>>>> people, including those who use 12-:
>>>>>>>>>> 
>>>>>>>>>> pkg: wrong architecture: FreeBSD:12.0:amd64 instead of 
>>>>>>>>>> FreeBSD:12:amd64
>>>>>>>>>> pkg: repository FreeBSD contains packages with wrong ABI: 
>>>>>>>>>> FreeBSD:12.0:amd64  
>>>>>>>>> 
>>>>>>>>> Still broken for me on 12.1.  
>>>>>>>> 
>>>>>>>> Strange.  Mine cleared up automatically the following day.
>>>>>>>> 
>>>>>>>> It's also strange how few replies I have received.  Two private
>>>>>>>> messages (why?), yours, and that was it.  You'd think that people
>>>>>>>> would be screaming.
>>>>>>>> 
>>>>>>>> Greg  
>>>>>>> 
>>>>>>> 
>>>>>>> I'm not screaming because I'm settling with the situation and
>>>>>>> starting to make workarounds.
>>>>>>> And wondering where the official communication of the community is.
>>>>>>> Nothing about this situation on www.freebsd.org. All information
>>>>>>> about the situation seems scattered through the mailinglists.
>>>>>>> 
>>>>>>> Things are working for me on 13-CURRENT again, but still broken on
>>>>>>> 12.1-RELEASE. See attachment.
>>>>>>> 
>>>>>>> Ronald.
>>>>>>> ___
>>>>>>> freebsd-current@freebsd.org mailing list
>>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>>>>> To unsubscribe, send any mail to 
>>>>>>> "freebsd-current-unsubscr...@freebsd.org"  
>>>>>> 
>>>>>> 
>>>>>> Did you try:
>>>>>> pkg update -f
>>>>>> 
>>>>>> 
>>>>>> I installed 12.1 on a new laptop yesterday, I have not experienced 
>>>>>> issues with pkg.
>>>>>> 
>>>>> 
>>>>> This was only an issue on the "latest" branch. If you don't alter
>>>>> "/etc/pkg/FreeBSD.conf", you'll get packages from the "quarterly"
>>>>> branch, which fortunately wasn't affected.
>>>> 
>>>> Any idea what is wrong on a stable/12 machine:
>>>> 
>>>> tuexen@stable12:~ % sudo pkg update 
>>>> Password:
>>>> Updating FreeBSD repository catalogue...
>>>> pkg: repository meta has wrong version 2
>>>> pkg: Repository FreeBSD load error: meta cannot be loaded No error: 0
>>>> Fetching meta.txz: 100%916 B   0.9kB/s00:01
>>>> pkg: repository meta has wrong version 2
>>>> repository FreeBSD has no meta file, using default settings
>>>> Fetching packagesite.txz: 100%6 MiB 586.4kB/s00:11
>>>> pkg: repository meta has wrong version 2
>>>> pkg: Repository FreeBSD load error: meta cannot be loaded No error: 0
>>>> Unable to open created repository FreeBSD
>>>> Unable to update repository 

Re: Pkg repository is broken...

[Michael Tuexen]

> On 7. Mar 2020, at 18:18, Michael Gmelin  wrote:
> 
> 
> 
>> On 7. Mar 2020, at 18:08, Michael Tuexen  wrote:
>> 
>> 
>>> 
>>> On 7. Mar 2020, at 16:46, Michael Gmelin  wrote:
>>> 
>>> 
>>> 
>>>> On Sat, 07 Mar 2020 11:30:58 -0400
>>>> Waitman Gobble  wrote:
>>>> 
>>>> On 2020-03-07 05:10, Ronald Klop wrote:
>>>>> On Sat, 07 Mar 2020 01:38:55 +0100, Greg 'groggy' Lehey
>>>>>  wrote:
>>>>> 
>>>>>> On Friday,  6 March 2020 at 12:29:44 +0100, Lars Engels wrote:  
>>>>>>> On Wed, Mar 04, 2020 at 03:16:14PM +1100, Greg 'groggy' Lehey
>>>>>>> wrote:  
>>>>>>>> 
>>>>>>>> Any workarounds in the meantime?  This must affect a lot of
>>>>>>>> people, including those who use 12-:
>>>>>>>> 
>>>>>>>> pkg: wrong architecture: FreeBSD:12.0:amd64 instead of 
>>>>>>>> FreeBSD:12:amd64
>>>>>>>> pkg: repository FreeBSD contains packages with wrong ABI: 
>>>>>>>> FreeBSD:12.0:amd64  
>>>>>>> 
>>>>>>> Still broken for me on 12.1.  
>>>>>> 
>>>>>> Strange.  Mine cleared up automatically the following day.
>>>>>> 
>>>>>> It's also strange how few replies I have received.  Two private
>>>>>> messages (why?), yours, and that was it.  You'd think that people
>>>>>> would be screaming.
>>>>>> 
>>>>>> Greg  
>>>>> 
>>>>> 
>>>>> I'm not screaming because I'm settling with the situation and
>>>>> starting to make workarounds.
>>>>> And wondering where the official communication of the community is.
>>>>> Nothing about this situation on www.freebsd.org. All information
>>>>> about the situation seems scattered through the mailinglists.
>>>>> 
>>>>> Things are working for me on 13-CURRENT again, but still broken on
>>>>> 12.1-RELEASE. See attachment.
>>>>> 
>>>>> Ronald.
>>>>> ___
>>>>> freebsd-current@freebsd.org mailing list
>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>>> To unsubscribe, send any mail to 
>>>>> "freebsd-current-unsubscr...@freebsd.org"  
>>>> 
>>>> 
>>>> Did you try:
>>>> pkg update -f
>>>> 
>>>> 
>>>> I installed 12.1 on a new laptop yesterday, I have not experienced 
>>>> issues with pkg.
>>>> 
>>> 
>>> This was only an issue on the "latest" branch. If you don't alter
>>> "/etc/pkg/FreeBSD.conf", you'll get packages from the "quarterly"
>>> branch, which fortunately wasn't affected.
>> 
>> Any idea what is wrong on a stable/12 machine:
>> 
>> tuexen@stable12:~ % sudo pkg update 
>> Password:
>> Updating FreeBSD repository catalogue...
>> pkg: repository meta has wrong version 2
>> pkg: Repository FreeBSD load error: meta cannot be loaded No error: 0
>> Fetching meta.txz: 100%916 B   0.9kB/s00:01
>> pkg: repository meta has wrong version 2
>> repository FreeBSD has no meta file, using default settings
>> Fetching packagesite.txz: 100%6 MiB 586.4kB/s00:11
>> pkg: repository meta has wrong version 2
>> pkg: Repository FreeBSD load error: meta cannot be loaded No error: 0
>> Unable to open created repository FreeBSD
>> Unable to update repository FreeBSD
>> Error updating repositories!
>> tuexen@stable12:~ % sudo pkg update -f
>> Updating FreeBSD repository catalogue...
>> pkg: repository meta has wrong version 2
>> pkg: Repository FreeBSD load error: meta cannot be loaded No error: 0
>> Fetching meta.txz: 100%916 B   0.9kB/s00:01
>> pkg: repository meta has wrong version 2
>> repository FreeBSD has no meta file, using default settings
>> Fetching packagesite.txz: 100%6 MiB 645.0kB/s00:10
>> pkg: repository meta has wrong version 2
>> pkg: Repository FreeBSD load error: meta cannot be loaded No error: 0
>> Unable to open created repository FreeBSD
>> Unable to update repository FreeBSD
>> Error updating repositories!
>> tuexen@stable12:~ % sudo pkg upgrade
>> Updating FreeBSD repository

Re: panic: vm_page_astate_fcmpset: invalid head requeue request on RPI3

[Michael Tuexen]

> On 2. Jan 2020, at 01:12, bob prohaska  wrote:
> 
> While playing at compiling www/chromium using 
> FreeBSD 13.0-CURRENT (GENERIC) #2 r356165: Mon Dec 30 09:59:03 PST 2019
> the machine crashed, reporting 
> panic: vm_page_astate_fcmpset: invalid head requeue request for page 
> 0xfd0031880490
This problem is NOT arm specific. I've seen it on an amd64 system running 
syzkaller:
http://212.201.121.91:1/crash?id=00704eb865e893ffda473a4859e062eef512cbde

Best regards
Michael
> 
> cpuid = 2
> time = 1577921727
> KDB: stack backtrace:
> db_trace_self() at db_trace_self_wrapper+0x28
>pc = 0x00735c5c  lr = 0x00106814
>sp = 0x521ec240  fp = 0x521ec450
> 
> db_trace_self_wrapper() at vpanic+0x18c
>pc = 0x00106814  lr = 0x00408d90
>sp = 0x521ec460  fp = 0x521ec510
> 
> vpanic() at panic+0x44
>pc = 0x00408d90  lr = 0x00408b40
>sp = 0x521ec520  fp = 0x521ec5a0
> 
> panic() at _vm_page_pqstate_commit_dequeue+0x340
>pc = 0x00408b40  lr = 0x006ed840
>sp = 0x521ec5b0  fp = 0x521ec5f0
> 
> _vm_page_pqstate_commit_dequeue() at vm_page_pqstate_commit_dequeue+0xb8
>pc = 0x006ed840  lr = 0x006e954c
>sp = 0x521ec600  fp = 0x521ec640
> 
> vm_page_pqstate_commit_dequeue() at vm_page_pqstate_commit+0x50
>pc = 0x006e954c  lr = 0x006e93ac
>sp = 0x521ec650  fp = 0x521ec670
> 
> vm_page_pqstate_commit() at vm_pageout_laundry_worker+0x5e4
>pc = 0x006e93ac  lr = 0x006f02c0
>sp = 0x521ec680  fp = 0x521ec940
> 
> vm_pageout_laundry_worker() at fork_exit+0x7c
>pc = 0x006f02c0  lr = 0x003c7fdc
>sp = 0x521ec950  fp = 0x521ec980
> 
> fork_exit() at fork_trampoline+0x10
>pc = 0x003c7fdc  lr = 0x0075230c
>sp = 0x521ec990  fp = 0x
> 
> KDB: enter: panic
> [ thread pid 21 tid 100071 ]
> Stopped at  0
> db> bt
> Tracing pid 21 tid 100071 td 0xfd0001078560
> db_trace_self() at db_stack_trace+0xf8
>pc = 0x00735c5c  lr = 0x00103c58
>sp = 0x521ebe10  fp = 0x521ebe40
> 
> db_stack_trace() at db_command+0x228
>pc = 0x00103c58  lr = 0x001038d0
>sp = 0x521ebe50  fp = 0x521ebf30
> 
> db_command() at db_command_loop+0x58
>pc = 0x001038d0  lr = 0x00103678
>sp = 0x521ebf40  fp = 0x521ebf60
> 
> db_command_loop() at db_trap+0xf4
>pc = 0x00103678  lr = 0x0010697c
>sp = 0x521ebf70  fp = 0x521ec190
> 
> db_trap() at kdb_trap+0x1d8
>pc = 0x0010697c  lr = 0x004510d0
>sp = 0x521ec1a0  fp = 0x521ec250
> 
> kdb_trap() at do_el1h_sync+0xf4
>pc = 0x004510d0  lr = 0x00752588
>sp = 0x521ec260  fp = 0x521ec290
> 
> do_el1h_sync() at handle_el1h_sync+0x78
>pc = 0x00752588  lr = 0x00738078
>sp = 0x521ec2a0  fp = 0x521ec3b0
> 
> handle_el1h_sync() at kdb_enter+0x34
>pc = 0x00738078  lr = 0x0045071c
>sp = 0x521ec3c0  fp = 0x521ec450
> 
> kdb_enter() at vpanic+0x1a8
>pc = 0x0045071c  lr = 0x00408dac
>sp = 0x521ec460  fp = 0x521ec510
> 
> vpanic() at panic+0x44
>pc = 0x00408dac  lr = 0x00408b40
>sp = 0x521ec520  fp = 0x521ec5a0
> 
> panic() at _vm_page_pqstate_commit_dequeue+0x340
>pc = 0x00408b40  lr = 0x006ed840
>sp = 0x521ec5b0  fp = 0x521ec5f0
> 
> _vm_page_pqstate_commit_dequeue() at vm_page_pqstate_commit_dequeue+0xb8
>pc = 0x006ed840  lr = 0x006e954c
>sp = 0x521ec600  fp = 0x521ec640
> 
> vm_page_pqstate_commit_dequeue() at vm_page_pqstate_commit+0x50
>pc = 0x006e954c  lr = 0x006e93ac
>sp = 0x521ec650  fp = 0x521ec670
> 
> vm_page_pqstate_commit() at vm_pageout_laundry_worker+0x5e4
>pc = 0x006e93ac  lr = 0x006f02c0
>sp = 0x521ec680  fp = 0x521ec940
> 
> vm_pageout_laundry_worker() at fork_exit+0x7c
>pc = 0x006f02c0  lr = 0x003c7fdc
>sp = 0x521ec950  fp = 0x521ec980
> 
> fork_exit() at fork_trampoline+0x10
>pc = 0x003c7fdc  lr = 0x0075230c
>sp = 0x521ec990  fp = 0x
> 
> db> 
> 
> Thanks for reading, if there's anything to try please let me know.
> 
> bob prohaska
> 
> ___
> freebsd-...@freebsd.org mailing list
> 

Re: SVN r353480 now mandates kernel option VIMAGE

[Michael Tuexen]

> On 13. Oct 2019, at 21:26, Michael Butler  wrote:
> 
> sys/net/route.c will no longer compile when VIMAGE is removed from the
> kernel,
That wasn't intended. Fixed in r353482.

Sorry for the breakage and thank you very much for reporting!

Best regards
Michael
> 
>   imb

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

Re: SVN r353480 now mandates kernel option VIMAGE

[Michael Tuexen]

> On 13. Oct 2019, at 21:26, Michael Butler  wrote:
> 
> sys/net/route.c will no longer compile when VIMAGE is removed from the
> kernel,
Let me look at it...

Best regards
Michael
> 
>   imb

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

Re: panic: rcv_start < rcv_end

[Michael Tuexen]

> On 10. Sep 2019, at 14:37, Yuri Pankov  wrote:
> 
> Just seen this almost immediately after booting the system installed from 
> amd64-20190906-r351901 snapshot, trying to do initial pkg bootstrap.  Sadly, 
> I didn't have the swap/dump device configured at the time, so no dump was 
> saved.
> 
> But it looks like I'm not alone, seeing the 
> https://forums.freebsd.org/threads/kernel-panic-on-bhyve-virtualization.7/
>  topic.  Note that I'm running on bare metal, so bhyve isn't involved. My 
> panic screenshot is at https://pasteboard.co/IwLaXXb.jpg.
> 
> In (the most likely) case it's not helpful enough, I'm now running with dump 
> device configured, and will update if/when the panic reproduces.
This panic should be fixed by:
https://svnweb.freebsd.org/changeset/base/352072

Please drop me a note if not.

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

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

Re: kernel module code coverage

[Michael Tuexen]

> On 8. Aug 2019, at 15:52, Alan Somers  wrote:
> 
> On Thu, Aug 8, 2019 at 7:42 AM Michael Tuexen  wrote:
>> 
>> 
>> 
>>> On 8. Aug 2019, at 14:24, Slava Shwartsman  wrote:
>>> 
>>> Apparently, Bullseye are dropping support for FreeBSD.
>>> 
>>> We are looking for an alternative for kernel module run time analysis.
>>> Mostly interested in code coverage (for now).
>>> 
>>> Any suggestions that work for you?
>> Have you looked into /dev/kcov. This is used by SYZKALLER for getting
>> coverage information from the kernel.
>> 
>> Best regards
>> Michael
>>> 
>>> 
>>> Slava
> 
> That's part of Matt Macy's gcov project, right?.  However, while it
> works for the kernel itself, it doesn't work for modules.
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239194
> -Alan
I think it came from Andrew... So you might assign the bug to him or at least
get him in the loop.

Best regards
Michael

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

Re: kernel module code coverage

[Michael Tuexen]

> On 8. Aug 2019, at 16:16, Slava Shwartsman  wrote:
> 
> 
> 
> On 08-Aug-19 16:52, Alan Somers wrote:
>> On Thu, Aug 8, 2019 at 7:42 AM Michael Tuexen  wrote:
>>> 
>>> 
>>> 
>>>> On 8. Aug 2019, at 14:24, Slava Shwartsman  wrote:
>>>> 
>>>> Apparently, Bullseye are dropping support for FreeBSD.
>>>> 
>>>> We are looking for an alternative for kernel module run time analysis.
>>>> Mostly interested in code coverage (for now).
>>>> 
>>>> Any suggestions that work for you?
>>> Have you looked into /dev/kcov. This is used by SYZKALLER for getting
>>> coverage information from the kernel.
>>> 
> 
> Thanks.
> Is there a man page for /dev/kcov?
I don't think so. There was no man page in the commit which introduced the 
feature:
https://svnweb.freebsd.org/base?view=revision=342962

You might want to look at:
https://github.com/google/syzkaller/blob/master/tools/kcovtrace/kcovtrace.c
how to use it.

Best regards
Michael
> 
>>> Best regards
>>> Michael
>>>> 
>>>> 
>>>> Slava
>> That's part of Matt Macy's gcov project, right?.  However, while it
>> works for the kernel itself, it doesn't work for modules.
> 
> In worst case, I can build my module into the kernel, right?
> 
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239194
>> -Alan
> 
> 
> Slava

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

Re: kernel module code coverage

[Michael Tuexen]

> On 8. Aug 2019, at 14:24, Slava Shwartsman  wrote:
> 
> Apparently, Bullseye are dropping support for FreeBSD.
> 
> We are looking for an alternative for kernel module run time analysis.
> Mostly interested in code coverage (for now).
> 
> Any suggestions that work for you?
Have you looked into /dev/kcov. This is used by SYZKALLER for getting
coverage information from the kernel.

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

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

Re: error: yacc.h: No such file or directory

[Michael Tuexen]

> On 18. Jun 2019, at 12:56, Kubilay Kocak  wrote:
> 
> On 18/06/2019 5:42 pm, Michael Tuexen wrote:
>> Dear all,
>> I'm trying to run
>> sudo make buildworld
>> in a directory with r349168.
>> The result is:
>> cc  -O2 -pipe -I/usr/home/tuexen/head/usr.bin/mkesdb_static 
>> -I/usr/home/tuexen/head/usr.bin/mkesdb_static/../mkesdb  
>> -I/usr/home/tuexen/head/usr.bin/mkesdb_static/../../lib/libc/iconv  -g -MD  
>> -MF.depend.lex.o -MTlex.o -std=gnu99 
>> -I/usr/obj/usr/home/tuexen/head/powerpc.powerpc64/tmp/legacy/usr/include -c 
>> lex.c -o lex.o
>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:46:18: error: yacc.h: No such 
>> file or directory
>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l: In function 'yylex':
>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: 'R_LN' undeclared 
>> (first use in this function)
>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: (Each undeclared 
>> identifier is reported only once
>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: for each function it 
>> appears in.)
>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:72: error: 'yylval' undeclared 
>> (first use in this function)
>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:73: error: 'L_IMM' undeclared 
>> (first use in this function)
>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:76: error: 'R_NAME' undeclared 
>> (first use in this function)
>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:77: error: 'R_ENCODING' 
>> undeclared (first use in this function)
>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:78: error: 'R_VARIABLE' 
>> undeclared (first use in this function)
>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:79: error: 'R_DEFCSID' undeclared 
>> (first use in this function)
>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:80: error: 'R_INVALID' undeclared 
>> (first use in this function)
>> /usr/home/tuexen/head/usr.bin/mkesdb/lex.l:88: error: 'L_STRING' undeclared 
>> (first use in this function)
>> *** Error code 1
>> Stop.
>> make[3]: stopped in /usr/home/tuexen/head/usr.bin/mkesdb_static
>> *** Error code 1
>> Stop.
>> make[2]: stopped in /usr/home/tuexen/head
>> *** Error code 1
>> Stop.
>> make[1]: stopped in /usr/home/tuexen/head
>> *** Error code 1
>> Stop.
>> make: stopped in /usr/home/tuexen/head
>> This is on a 64 bit PPC system. Doing sudo rm -rf /usr/obj does not resolve 
>> the issue.
>> Any idea what is going wrong?
>> Best regards
>> Michael
> 
> Have seen another report on Twitter yesterday. Didn't see a full build log, 
> but theirs was had apparently without -j, apparently on June 14 sources:
> 
> Error:
> /usr/src/usr.bin/mkesdb/lex.1:46:10: fatal error: 'yacc.h' file not found
> 
> Have not heard back from them whether it continued after trying -j2 but I did 
> ask them to hit up freebsd-current if it continued to be an issue
OK, I started the build again with -j 2 and it seems that the problem does not 
occur.

Since I have been using make buildworld without -j n in the past on that 
machine, the
problem seems to be introduced recently. Any idea what is the cause of the 
problem?

Best regards
Michael
> 

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

error: yacc.h: No such file or directory

[Michael Tuexen]

Dear all,

I'm trying to run
sudo make buildworld
in a directory with r349168.

The result is:
cc  -O2 -pipe -I/usr/home/tuexen/head/usr.bin/mkesdb_static 
-I/usr/home/tuexen/head/usr.bin/mkesdb_static/../mkesdb  
-I/usr/home/tuexen/head/usr.bin/mkesdb_static/../../lib/libc/iconv  -g -MD  
-MF.depend.lex.o -MTlex.o -std=gnu99 
-I/usr/obj/usr/home/tuexen/head/powerpc.powerpc64/tmp/legacy/usr/include -c 
lex.c -o lex.o
/usr/home/tuexen/head/usr.bin/mkesdb/lex.l:46:18: error: yacc.h: No such file 
or directory
/usr/home/tuexen/head/usr.bin/mkesdb/lex.l: In function 'yylex':
/usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: 'R_LN' undeclared (first 
use in this function)
/usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: (Each undeclared 
identifier is reported only once
/usr/home/tuexen/head/usr.bin/mkesdb/lex.l:60: error: for each function it 
appears in.)
/usr/home/tuexen/head/usr.bin/mkesdb/lex.l:72: error: 'yylval' undeclared 
(first use in this function)
/usr/home/tuexen/head/usr.bin/mkesdb/lex.l:73: error: 'L_IMM' undeclared (first 
use in this function)
/usr/home/tuexen/head/usr.bin/mkesdb/lex.l:76: error: 'R_NAME' undeclared 
(first use in this function)
/usr/home/tuexen/head/usr.bin/mkesdb/lex.l:77: error: 'R_ENCODING' undeclared 
(first use in this function)
/usr/home/tuexen/head/usr.bin/mkesdb/lex.l:78: error: 'R_VARIABLE' undeclared 
(first use in this function)
/usr/home/tuexen/head/usr.bin/mkesdb/lex.l:79: error: 'R_DEFCSID' undeclared 
(first use in this function)
/usr/home/tuexen/head/usr.bin/mkesdb/lex.l:80: error: 'R_INVALID' undeclared 
(first use in this function)
/usr/home/tuexen/head/usr.bin/mkesdb/lex.l:88: error: 'L_STRING' undeclared 
(first use in this function)
*** Error code 1

Stop.
make[3]: stopped in /usr/home/tuexen/head/usr.bin/mkesdb_static
*** Error code 1

Stop.
make[2]: stopped in /usr/home/tuexen/head
*** Error code 1

Stop.
make[1]: stopped in /usr/home/tuexen/head
*** Error code 1

Stop.
make: stopped in /usr/home/tuexen/head

This is on a 64 bit PPC system. Doing sudo rm -rf /usr/obj does not resolve the 
issue.

Any idea what is going wrong?

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

Re: random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG' returned no entropy.

[Michael Tuexen]

> On 8. May 2019, at 18:13, Andrey V. Elsukov  wrote:
> 
> Hi,
> 
> today I updated one of my test machines and discovered that message from
> the subject periodically printed in the console.
Fixed in  https://svnweb.freebsd.org/changeset/base/347329

Best regards
Michael
> 
> FreeBSD 13.0-CURRENT r347327=4f47587(svn_head) GENERIC-NODEBUG amd64
> FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on
> LLVM 8.0.0)
> VT(vga): resolution 640x480
> CPU: Intel(R) Xeon(R) CPU E5-2660 v4@ 2.00GHz (2000.04-MHz K8-class CPU)
> ...
> real memory  = 68719476736 (65536 MB)
> avail memory = 66722340864 (63631 MB)
> Event timer "LAPIC" quality 600
> ACPI APIC Table: 
> FreeBSD/SMP: Multiprocessor System Detected: 28 CPUs
> FreeBSD/SMP: 2 package(s) x 14 core(s)
> ...
> 
> % grep -c random /var/run/dmesg.boot
> 606
> 
> % grep random /var/run/dmesg.boot | head -10
> __stack_chk_init: WARNING: Initializing stack protection with non-random
> cookies!
> random: entropy device external interface
> random: registering fast source Intel Secure Key RNG
> random: fast provider: "Intel Secure Key RNG"
> arc4random: WARNING: initial seeding bypassed the cryptographic random
> device because it was not yet seeded and the knob
> 'bypass_before_seeding' was enabled.
> random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG'
> returned no entropy.
> random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG'
> returned no entropy.
> random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG'
> returned no entropy.
> random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG'
> returned no entropy.
> random_sources_feed: rs_read for hardware device 'Intel Secure Key RNG'
> returned no entropy.
> 
> % sysctl -a | grep -v random_sources_feed | grep rand
> kern.fallback_elf_brand: -1
> devicerandom
> devicerdrand_rng
> kern.randompid: 0
> kern.elf32.fallback_brand: -1
> kern.elf64.fallback_brand: -1
> kern.random.fortuna.minpoolsize: 64
> kern.random.harvest.mask_symbolic:
> PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,[NET_ETHER],NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED
> kern.random.harvest.mask_bin: 000100011101
> kern.random.harvest.mask: 66015
> kern.random.use_chacha20_cipher: 0
> kern.random.block_seeded_status: 0
> kern.random.random_sources: 'Intel Secure Key RNG'
> kern.random.initial_seeding.disable_bypass_warnings: 0
> kern.random.initial_seeding.arc4random_bypassed_before_seeding: 1
> kern.random.initial_seeding.read_random_bypassed_before_seeding: 0
> kern.random.initial_seeding.bypass_before_seeding: 1
> net.inet.ip.portrange.randomtime: 45
> net.inet.ip.portrange.randomcps: 10
> net.inet.ip.portrange.randomized: 1
> net.inet.ip.random_id_total: 0
> net.inet.ip.random_id_collisions: 0
> net.inet.ip.random_id_period: 0
> net.inet.ip.random_id: 0
> net.key.int_random: 60
> debug.fail_point.status_fill_kinfo_vnode__random_path: off
> debug.fail_point.fill_kinfo_vnode__random_path: off
> debug.fail_point.status_random_fortuna_pre_read: off
> debug.fail_point.random_fortuna_pre_read: off
> security.stack_protect.permit_nonrandom_cookies: 1
> 
> -- 
> WBR, Andrey V. Elsukov
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

[Michael Tuexen]

Resending from correct address...
> On 22. Sep 2018, at 05:57, Warner Losh  wrote:
> 
> Hmmm, what does make -V LINKER_TYPE and make -V LINKER_FEATURES say?
> 
> They look good for me, but the only way you get this error is if they are
> wrong.
> 
> Although from your typescript, I see:
> 
> ===> lib/libc (cleandir)
> make[4]: "/usr/home/bcran/workspace/freebsd/lib/libc/Makefile" line 26:
> amd64 libc requires linker ifunc support
> 
> which tells me that we need to exclude all the non-build targets from this
> check This will use the HOST linker rather than the TARGET linker.
> 
> So something like:
> 
> diff --git a/lib/libc/Makefile b/lib/libc/Makefile
> index a1ce123c0f33..11575e1cabff 100644
> --- a/lib/libc/Makefile
> +++ b/lib/libc/Makefile
> @@ -21,10 +21,12 @@ LIBC_ARCH=${MACHINE_ARCH}
> LIBC_ARCH=${MACHINE_CPUARCH}
> .endif
> 
> +.if build(all)
> .if (${LIBC_ARCH} == amd64 || ${LIBC_ARCH} == i386) && \
>defined(LINKER_FEATURES) && ${LINKER_FEATURES:Mifunc} == ""
> .error ${LIBC_ARCH} libc requires linker ifunc support
> .endif
> +.endif
Using this patch I was able to build/install world and kernel on an i386 system.
However, after removing it, I can't build world then. When trying to compile a
kernel "the old way" I end up with:

tuexen@head:~/head/sys/i386/conf % config -g TCP
WARNING: duplicate option `GEOM_PART_GPT' encountered.
Kernel build directory is ../compile/TCP
Don't forget to do ``make cleandepend && make depend''
tuexen@head:~/head/sys/i386/conf % cd ../compile/TCP/
tuexen@head:~/head/sys/i386/compile/TCP % make -j 6
make: "../../../conf/../../../conf/kern.pre.mk" line 126: amd64/i386 kernel 
requires linker ifunc support

This is r338893.

amd64 works without any problem. So this is i386 specific. Any idea how to fix 
it?

Best regards
Michael
> 
> # All library objects contain FreeBSD revision strings by default; they
> may be
> # excluded as a space-saving measure.  To produce a library that does
> 
> may be needed, but the problem may be related to caching these values from
> the host as well, even though we rebuild them...
> 
> Warner
> 
> On Fri, Sep 21, 2018 at 9:38 PM Rebecca Cran  wrote:
> 
>> On 9/21/18 9:35 PM, Warner Losh wrote:
>>> 
>>> I meant to add, can you give a few lines before the error is spewed
>>> here in email? My IRC computer died before I could see any answers
>>> there...
>>> 
>>> My 11.2-stable system has 6.0.1, so I can't test from there.
>> 
>> 
>> I've uploaded the full 'buildworld' output to
>> https://bluestop.org/files/typescript.txt .
>> 
>> 
>> --
>> 
>> Rebecca
>> 
>> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

Re: 12.0-ALPHA6 dumps with 'Fatal double fault'

[Michael Tuexen]

> On 20. Sep 2018, at 19:11, Michael Schmiedgen  wrote:
> 
> Hi Michael,
> 
> many thanks for your help.
> 
> 
> On 20.09.2018 18:15, Michael Tuexen wrote:
>>> On 20. Sep 2018, at 17:12, Michael Schmiedgen  wrote:
>>> 
>>> 
>>>> Can you elaborate which port was triggering the fault and which platform 
>>>> you are using?
>>>> I would like to reproduce the issue and fix it.
>>> 
>>> Port is devel/apr1 and platform is amd64.
>> Works fine on my side. It would be helpful if you could build a kernel with
>> debug symbols, reproduce the problem and provide a stack strace.
> 
> Unfortunately I cannot. It is a production machine without debug that does not
> like to run on 11.1 OR 11.2 for some strange reason [1]. And I really do not
I'm not referring to 11.1 or 11.2. Just the kernel you use with debug symbols.
> want to run it on 11.0 anymore. Perhaps it is some crappy hardware from our
> hoster, I don't know. Anyway, after minimal-updating SVN to very-latest and
> removing SCTP it behaves just fine under load.
Removing SCTP means removing it from the kernel or disabling it in the port?
> 
> 
>> Since you said that it crashed multiple times makes me wonder if this problem
>> is related to SCTP in particular or if there is some other generic issue...
> 
> The mentioned commit [2] lies exactly in my SVN update delta. So this could
> be the reason, too(?)
> 
> Sadly I am to busy right now to investigate further, sorry.
OK. If you have some spare time, enable SCTP again and see if the problem
is related to it...

Best regards
Michael
> 
> Thanks again,
>  Michael
> 
> 
> 
> [1]
> https://lists.freebsd.org/pipermail/freebsd-current/2014-October/052900.html
> https://lists.freebsd.org/pipermail/freebsd-stable/2014-December/081192.html
> 
> [2]
> https://lists.freebsd.org/pipermail/freebsd-current/2018-September/071283.html

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

Re: 12.0-ALPHA6 dumps with 'Fatal double fault'

[Michael Tuexen]

> On 20. Sep 2018, at 17:12, Michael Schmiedgen  wrote:
> 
> 
>> Can you elaborate which port was triggering the fault and which platform you 
>> are using?
>> I would like to reproduce the issue and fix it.
> 
> Port is devel/apr1 and platform is amd64.
Works fine on my side. It would be helpful if you could build a kernel with
debug symbols, reproduce the problem and provide a stack strace.

Since you said that it crashed multiple times makes me wonder if this problem
is related to SCTP in particular or if there is some other generic issue...

Best regards
Michael
> 
> CPU: Intel(R) Xeon(R) CPU E31245 @ 3.30GHz (3300.10-MHz K8-class CPU)
>  Origin="GenuineIntel"  Id=0x206a7  Family=0x6  Model=0x2a  Stepping=7
>  
> Features=0xbfebfbff
> Features2=0x1fbae3ff
>  AMD Features=0x28100800
>  AMD Features2=0x1
>  XSAVE Features=0x1
>  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
>  TSC: P-state invariant, performance statistics
> 
> It crashed multiple times randomly under heavy load when compiling ports. But 
> I
> observed a crash two times exactly in the same place: configure script SCTP 
> test
> in devel/apr1.
> 
> Thanks,
>  Michael

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

Re: 12.0-ALPHA6 dumps with 'Fatal double fault'

[Michael Tuexen]

> On 20. Sep 2018, at 14:18, Michael Schmiedgen  wrote:
> 
> Hi List,
> 
> if compiling ports and configure script checks for SCTP with
> 
> 'checking whether SCTP is supported...'
> 
> 12.0-ALPHA6 dumps core with message:
> 
> Fatal double fault
> rip 0x80b96297 rsp 0xfe00be241bb0 rbp 0xfe00be245490
> rax 0x1 rdx 0x3 rbx 0x7fffd198
> rcx 0x80b9620b rsi 0xf8029eeb0368 rdi 0x4
> r8 0xf801c925c580 r9 0xfe00be2456d4 r10 0x4
> r11 0xfe00be245b80 r12 0x7fffd190 r13 0
> r14 0x1 r15 0x7fffd1a8 rflags 0x10293
> cs 0x20 ss 0x28 ds 0x3b es 0x3b fs 0x13 gs 0x1b
> fsbase 0x8002318d0 gsbase 0x81648a00 kgsbase 0
> cpuid = 0; apic id = 00
> panic: double fault
> cpuid = 0
> 
> I can provide crash dumps if desired, but without debug information.
Can you elaborate which port was triggering the fault and which platform you 
are using?
I would like to reproduce the issue and fix it.

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

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

Re: Panic in efi_get_time() on EPCY system when booting

[Michael Tuexen]

> On 14. Aug 2018, at 17:09, Kyle Evans  wrote:
> 
> On Tue, Aug 14, 2018 at 11:04 AM, Michael Tuexen  wrote:
>> Dear all,
>> 
>> r337761 panics on boot with a GENERIC kernel on a EPYC system:
> 
> Oy. =(
> 
>> [...]
>> panic: mutex pmap not owned at ../../../amd64/amd64/efirt_machdep.c:268
>> [...]
>> 
>> Any idea what is wrong?
>> 
> 
> Ah, this should be fixed by https://reviews.freebsd.org/D16618 --
> immediate workaround is set efi.rt.disabled=1 in loader.conf(5) or at
> loader prompt. Apologies for the hassle.
Hi Kyle,

I can confirm that r337761 + D16618 boots fine.

Thanks for the quick response!

Best regards
Michael
> 
> Thanks,
> 
> Kyle Evans

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

Panic in efi_get_time() on EPCY system when booting

[Michael Tuexen]

Dear all,

r337761 panics on boot with a GENERIC kernel on a EPYC system:

Copyright (c) 1992-2018 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 12.0-ALPHA1 #3 r337761: Tue Aug 14 17:59:05 CEST 2018
tue...@epyc.nplab.de:/usr/home/tuexen/head/sys/amd64/compile/TCP amd64
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 
6.0.1)
WARNING: WITNESS option enabled, expect reduced performance.
VT(efifb): resolution 1024x768
CPU: AMD EPYC 7551P 32-Core Processor(2000.05-MHz K8-class CPU)
  Origin="AuthenticAMD"  Id=0x800f12  Family=0x17  Model=0x1  Stepping=2
  
Features=0x178bfbff
  
Features2=0x7ed8320b
  AMD Features=0x2e500800
  AMD 
Features2=0x35c233ff
  Structured Extended 
Features=0x209c01a9
  XSAVE Features=0xf
  AMD Extended Feature Extensions ID EBX=0x1007
  SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768
  TSC: P-state invariant, performance statistics
real memory  = 137438953472 (131072 MB)
avail memory = 133661786112 (127469 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: < >
FreeBSD/SMP: Multiprocessor System Detected: 64 CPUs
FreeBSD/SMP: 1 package(s) x 4 groups x 2 cache groups x 4 core(s) x 2 hardware 
threads
random: unblocking device.
ioapic0: Changing APIC ID to 128
ioapic1: Changing APIC ID to 129
ioapic2: Changing APIC ID to 130
ioapic3: Changing APIC ID to 131
ioapic4: Changing APIC ID to 132
ioapic0  irqs 0-23 on motherboard
ioapic1  irqs 24-55 on motherboard
ioapic2  irqs 56-87 on motherboard
ioapic3  irqs 88-119 on motherboard
ioapic4  irqs 120-151 on motherboard
Launching APs: 14 6 52 16 28 44 42 36 20 13 37 4 54 15 21 5 55 18 30 8 26 9 29 
58 53 10 56 38 31 11 49 46 22 48 43 12 35 45 41 23 39 51 32 24 27 61 63 33 1 62 
60 7 59 40 34 47 2 3 17 19 50 25 57
Timecounter "TSC" frequency 254700 Hz quality 1000
random: entropy device external interface
netmap: loaded module
[ath_hal] loaded
module_register_init: MOD_LOAD (vesa, 0x81126100, 0) error 19
kbd1 at kbdmux0
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
nexus0
panic: mutex pmap not owned at ../../../amd64/amd64/efirt_machdep.c:268
cpuid = 60
time = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0x826ce810
vpanic() at vpanic+0x1a3/frame 0x826ce870
panic() at panic+0x43/frame 0x826ce8d0
__mtx_assert() at __mtx_assert+0xb4/frame 0x826ce8e0
efi_arch_enter() at efi_arch_enter+0x30/frame 0x826ce910
efi_get_time() at efi_get_time+0xbd/frame 0x826ce960
efirtc_probe() at efirtc_probe+0x17/frame 0x826ce990
device_probe_child() at device_probe_child+0x164/frame 0x826ce9f0
device_probe() at device_probe+0x98/frame 0x826cea20
device_probe_and_attach() at device_probe_and_attach+0x32/frame 
0x826cea50
bus_generic_attach() at bus_generic_attach+0x18/frame 0x826cea70
device_attach() at device_attach+0x3f3/frame 0x826ceab0
device_probe_and_attach() at device_probe_and_attach+0x71/frame 
0x826ceae0
bus_generic_new_pass() at bus_generic_new_pass+0xdd/frame 0x826ceb10
bus_set_pass() at bus_set_pass+0x8c/frame 0x826ceb40
configure() at configure+0x9/frame 0x826ceb50
mi_startup() at mi_startup+0x118/frame 0x826ceb70
btext() at btext+0x2c
KDB: enter: panic
[ thread pid 0 tid 10 ]
Stopped at  kdb_enter+0x3b: movq$0,kdb_why
db> 

Any idea what is wrong?

Best regards
Michael


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

Problem with lastest version of indent

[Michael Tuexen]

Dear all,

the up-to-date indent translates a line like

bla._blub = 1;

into a line like

bla._ blub = 1;

(insert whitespace after _) which breaks C code... Older versions didn't do that

Is this change intended? If yes, is there a command line option to turn it off?

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

Re: svn commit: r336940 - in head/sys: netinet netinet6 [This broke ci.freebsd.org 's FreeBSD-head-mips*-build 's]

[Michael Tuexen]

> On 31. Jul 2018, at 03:44, Mark Millard  wrote:
> 
> https://ci.freebsd.org/job/FreeBSD-head-mips-build/3577/consoleText shows:
> 
> --- tcp_usrreq.o ---
> cc1: warnings being treated as errors
> /usr/src/sys/netinet/tcp_usrreq.c: In function 'tcp_usr_send':
> /usr/src/sys/netinet/tcp_usrreq.c:905: warning: unused variable 'sin' 
> [-Wunused-variable]
> . . .
> --- tcp_usrreq.o ---
> *** [tcp_usrreq.o] Error code 1
> 
> make[2]: stopped in /usr/obj/usr/src/mips.mips/sys/MALTA
> 1 error
> 
> (Note: -r366935 built correctly as #3576 .)
> 
> 
> 
> https://ci.freebsd.org/job/FreeBSD-head-mips64-build/3624/consoleText shows:
> 
> --- tcp_usrreq.o ---
> cc1: warnings being treated as errors
> /usr/src/sys/netinet/tcp_usrreq.c: In function 'tcp_usr_send':
> /usr/src/sys/netinet/tcp_usrreq.c:905: warning: unused variable 'sin' 
> [-Wunused-variable]
> *** [tcp_usrreq.o] Error code 1
> 
> make[2]: stopped in /usr/obj/usr/src/mips.mips64/sys/MALTA64
> 
> (Note: -r366935 built correctly as #3623 .)
Fixed in https://svnweb.freebsd.org/changeset/base/336962

Thanks for the report and sorry for the breakage.

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

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