> On 27. Oct 2024, at 17:38, Gleb Smirnoff wrote:
>
> Hi,
>
> I just got this panic on my desktop running latest stabweek snapshot.
>
> panic: tcp_do_segment: sent too much
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2c/frame 0xfe0209deb440
> kdb_backtrace() at kdb_backtrace+0x46/f
> 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
> 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: lin
> 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 t
ng_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 buildw
ib/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}
>>
>>
xists(${_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/freebs
> 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
> f
> 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 becau
> 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
> 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 tc
> 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"
; /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
> 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
> 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
> 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, th
> 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 r
> 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
> 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---
> __
> 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
> 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,
> 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 1
> 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 20
> 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:
> 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
>
> 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=a8b70cf26030d68631200619
> 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/neti
> 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/neti
> 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_NA
NERIC
>>
>> 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 --
; 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 ---
>
-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 /
> 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 u
> 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
> 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.ine
ad_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=r
> 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/s
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
> 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_veg
> 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 "nodev
> 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
>>
> 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 u
> 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.
>
> 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.
Howev
> 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 co
> 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 mon
> 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
> 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
;> 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
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
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
> 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
> 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 i
> 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
>
> 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
l 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 ch
> 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
> 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 dropp
> 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
> 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
> ___
> 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 actual
> 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
>&
> 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 t
> 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 give
> 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 give
> 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. J
> 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
>&g
> 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 destina
t 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:
> >
&g
> 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
>> m
> 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
>> m
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);
}
O
> 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
t 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:
> 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 det
ic 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 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
y 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
> 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 alg
> 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 ...
> 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,
> 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: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
> 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
> 0xfd00318804
> 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
> 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
> 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.
>
>
> 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.
>&g
> 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:
>
> 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 int
> 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
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 -
> 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
> +.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 `G
> 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:
>>>
>>>
>>>>
> 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 i
> 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
> 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 o
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
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
___
1 - 100 of 137 matches
Mail list logo
