On Sun, May 10, 2020 at 12:02:19AM +0300, Andriy Gapon wrote:
> On 09/05/2020 23:47, Konstantin Belousov wrote:
> > Might be not, might be it would help due to pmap_delayed_invl_genp().
> > But I would more worry about this 'already started' issue, because
> > this must not happen. Can you remove
On 09/05/2020 23:47, Konstantin Belousov wrote:
> Might be not, might be it would help due to pmap_delayed_invl_genp().
> But I would more worry about this 'already started' issue, because
> this must not happen. Can you remove the assert from the macro and
> provide backtrace of 'DI already start
On Sat, May 09, 2020 at 11:33:40PM +0300, Andriy Gapon wrote:
> On 09/05/2020 19:50, Konstantin Belousov wrote:
> > On Sat, May 09, 2020 at 07:16:27PM +0300, Andriy Gapon wrote:
> >> On 09/05/2020 19:13, Konstantin Belousov wrote:
> >>> On Sat, May 09, 2020 at 06:52:24PM +0300, Andriy Gapon wrote:
On 09/05/2020 19:50, Konstantin Belousov wrote:
> On Sat, May 09, 2020 at 07:16:27PM +0300, Andriy Gapon wrote:
>> On 09/05/2020 19:13, Konstantin Belousov wrote:
>>> On Sat, May 09, 2020 at 06:52:24PM +0300, Andriy Gapon wrote:
On 08/05/2020 19:15, Konstantin Belousov wrote:
> On Fri, May
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 modu
Hi Michael,
with a kernel config which includes
include GENERIC
options RATELIMIT
options TCPHPTS
applied, I could successfully use
net.inet.tcp.functions_default=bbr
to switch the TCP stack.
Thanks for the fast help,
Gordon
> Am 09.05.2020 um 16:25 schrieb Gordon Bergling :
>
> Hi Michael,
> 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 me
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
On Sat, May 09, 2020 at 07:16:27PM +0300, Andriy Gapon wrote:
> On 09/05/2020 19:13, Konstantin Belousov wrote:
> > On Sat, May 09, 2020 at 06:52:24PM +0300, Andriy Gapon wrote:
> >> On 08/05/2020 19:15, Konstantin Belousov wrote:
> >>> On Fri, May 08, 2020 at 06:53:24PM +0300, Andriy Gapon 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.
kldload: an error occurred while loading module tcp_rack.ko. Please check
dmesg(8) for more details.
dmesg shows:
KLD tcp_bbr.ko: depends on tcphpts - not availabl
On 09/05/2020 19:13, Konstantin Belousov wrote:
> On Sat, May 09, 2020 at 06:52:24PM +0300, Andriy Gapon wrote:
>> On 08/05/2020 19:15, Konstantin Belousov wrote:
>>> On Fri, May 08, 2020 at 06:53:24PM +0300, Andriy Gapon wrote:
I have a reproducible panic with a custom kernel without opt
On Sat, May 09, 2020 at 06:52:24PM +0300, Andriy Gapon wrote:
> On 08/05/2020 19:15, Konstantin Belousov wrote:
> > On Fri, May 08, 2020 at 06:53:24PM +0300, Andriy Gapon wrote:
> >>
> >> I have a reproducible panic with a custom kernel without option NUMA while
> >> using
> >> amdgpu driver from
On 08/05/2020 19:15, Konstantin Belousov wrote:
> On Fri, May 08, 2020 at 06:53:24PM +0300, Andriy Gapon wrote:
>>
>> I have a reproducible panic with a custom kernel without option NUMA while
>> using
>> amdgpu driver from linuxkpi-based drm:
>>
>> panic: address 41ec0 beyond the last segment
> 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 bui
I run the latest current and I have the following packages
installed>xf86-input-keyboard-1.9.0_4
xf86-input-libinput-0.28.2_1
xf86-input-mouse-1.9.3_3 Should I keep all of them or may I keep
xf86-input-libinputThank youFilippo
___
freebsd-current@fre
> 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
On Sat, May 09, 2020 at 02:18:51PM +0200, 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.
>
> kldload: an error occurred while loading module tcp_rack.ko. Please check
> dmesg(8) for
Dimitry Andric writes:
> /usr/src/contrib/llvm-project/clang/lib/Basic/SourceManager.cpp:1228:10:
> fatal error: 'emmintrin.h' file not found
> #include
> ^
> ...
> > In file included from
> /usr/src/contrib/llvm-project/clang/lib/Basic/SourceManag
On 9 May 2020, at 05:10, Robert Huff wrote:
>
> Chris writes:
>>> "make buildowrld" fails with:
...
/usr/src/contrib/llvm-project/clang/lib/Basic/SourceManager.cpp:1228:10:
fatal error: 'emmintrin.h' file not found
#include
^
...
> In file included fr
[I caused nfsd to having things shifted in mmeory some to
see it it tracked content vs. page boundary for where the
zeros stop. Non-nfsd examples omitted.]
> . . .
>> nfsd hit an assert, failing ret == sz_size2index_compute(size)
>
> [Correction: That should have referenced sz_index2size_lookup(i
20 matches
Mail list logo
