Yes, this is today without resetting the interface:
#netstat -ie
NameMtu Network Address Ipkts IerrsOpkts
Oerrs Colls
em0 1500XX:XX:XX:XX:XX:XX 5351463 1868 3016695
0 0
em0 1500 XX:XX:XX:XX XX:XX:XX:XX:XX:XX 5351463 1868 3016695
0
are there any config options on the switch site relating to flow control you
can try turning off? are there any counters for pause frames on the switch side
too?
dlg
> On 12 Jun 2020, at 12:16 pm, Gabri Tofano wrote:
>
> Apparently it is not:
>
> #ifconfig em0 hwfeatures
> em0: flags=808843
On Fri, Jun 12, 2020 at 12:13:42AM +0200, Mark Schneider wrote:
> Hello
>
>
> Even the 640FLR-SFP28 network adapter is listed in the "pcidump -v" output
> on OpenBSD 6.7 there are no entries for it's interfaces in the output of
> "ifconfig -a"
>
> #
Is flow control enabled? Can you try disabling rxpause and txpause?
> On 12 Jun 2020, at 10:36 am, Gabri Tofano wrote:
>
> Yes, this is today without resetting the interface:
>
> #netstat -ie
> NameMtu Network Address Ipkts IerrsOpkts Oerrs
> Colls
> em0 1500
Is it consistently Ierrs?
dlg
> On 11 Jun 2020, at 10:14 pm, Gabri Tofano wrote:
>
> #netstat -id
> NameMtu Network Address Ipkts IdropOpkts Odrop
> Colls
> em0 1500XX:XX:XX:XX:XX:XX 266894 0 202813 0 > 0
> em0 1500 XX.XX.XX.XX
> Date: Thu, 11 Jun 2020 19:35:48 +0100
> From: Stuart Henderson
>
> And this, I was resizing a mupdf window at the time.
Should already be fixed. See jsg's commit eralier today.
> uvm_fault(0xfd87039e5890, 0x58, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped at
And this, I was resizing a mupdf window at the time.
uvm_fault(0xfd87039e5890, 0x58, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at intel_partial_pages+0xf4: movq0x58,%rsi
ddb{0}> ps /o
TIDPIDUID PRFLAGS PFLAGS CPU COMMAND
98313 29118 1000
Hi Klemens,
Klemens Nanni wrote on Thu, Jun 11, 2020 at 06:32:46PM +0200:
> On Thu, Jun 11, 2020 at 06:03:20PM +0200, Ingo Schwarze wrote:
>> Indeed, i came up with exactly the same diff and had already
>> written this commit message, but was still testing:
>>
>> Fix a regression in rev.
Ingo Schwarze wrote:
> Hi,
>
> Theo de Raadt wrote on Thu, Jun 11, 2020 at 10:12:47AM -0600:
> > Romero Perez, Abel wrote:
>
> >> I suggest only to have a look into better measures of security by
> >> researching optimization flags, to find an equilibrium of optimization
> >> and security.
>
Hi,
Theo de Raadt wrote on Thu, Jun 11, 2020 at 10:12:47AM -0600:
> Romero Perez, Abel wrote:
>> I suggest only to have a look into better measures of security by
>> researching optimization flags, to find an equilibrium of optimization
>> and security.
> Romero, that is bullshit.
However,
On Thu, Jun 11, 2020 at 06:03:20PM +0200, Ingo Schwarze wrote:
> Indeed, i came up with exactly the same diff and had already
> written this commit message, but was still testing:
>
> Fix a regression in rev. 1.238 (2019/07/26):
> Pass the right object to html_reset() or it will crash
>
On Thu, Jun 11, 2020 at 05:07:17PM +0200, Otto Moerbeek wrote:
> This fixes it for me,
This looks like a simple mistake introduced back in main.c r1.222:
date: 2019/03/03 13:01:47; author: schwarze; state: Exp; lines: +3
-1;
Reset HTML formatter state, in particular the
#netstat -id
NameMtu Network Address Ipkts IdropOpkts
Odrop Colls
em0 1500XX:XX:XX:XX:XX:XX 266894 0 202813
0 0
em0 1500 XX.XX.XX.XX XX:XX:XX:XX:XX:XX 266894 0 202813
0 0
em1 1500XX:XX:XX:XX:XX:XX 170280
Romero Pérez, Abel wrote:
> Yes, thank you.
>
> I suggest only to have a look into better measures of security by
> researching optimization flags, to find an equilibrium of optimization
> and security.
Romero, that is bullshit.
Yes, thank you.
I suggest only to have a look into better measures of security by
researching optimization flags, to find an equilibrium of optimization
and security.
But I said to forget it because it was hard to explain.
On 2020-06-11 18:06, Theo de Raadt wrote:
Otto Moerbeek wrote:
Otto Moerbeek wrote:
> On Thu, Jun 11, 2020 at 05:15:28PM +0200, Romero Pérez, Abel wrote:
>
> >
> >
> > On 2020-06-11 17:07, Otto Moerbeek wrote:
> > > On Thu, Jun 11, 2020 at 04:53:25PM +0200, Romero Pérez, Abel wrote:
> > >
> > > >
> > > >
> > > > On 2020-06-11 16:45, Klemens Nanni
Hi Otto,
Otto Moerbeek wrote on Thu, Jun 11, 2020 at 05:07:17PM +0200:
> This fixes it for me,
Indeed, i came up with exactly the same diff and had already
written this commit message, but was still testing:
Fix a regression in rev. 1.238 (2019/07/26):
Pass the right object to html_reset()
On Thu, Jun 11, 2020 at 05:15:28PM +0200, Romero Pérez, Abel wrote:
>
>
> On 2020-06-11 17:07, Otto Moerbeek wrote:
> > On Thu, Jun 11, 2020 at 04:53:25PM +0200, Romero Pérez, Abel wrote:
> >
> > >
> > >
> > > On 2020-06-11 16:45, Klemens Nanni wrote:
> > > > On Thu, Jun 11, 2020 at
On 2020-06-11 17:07, Otto Moerbeek wrote:
On Thu, Jun 11, 2020 at 04:53:25PM +0200, Romero Pérez, Abel wrote:
On 2020-06-11 16:45, Klemens Nanni wrote:
On Thu, Jun 11, 2020 at 03:59:09PM +0200, Otto Moerbeek wrote:
This already trips the bug;
man -T html -c pfctl id
No need
On Thu, Jun 11, 2020 at 04:53:25PM +0200, Romero Pérez, Abel wrote:
>
>
> On 2020-06-11 16:45, Klemens Nanni wrote:
> > On Thu, Jun 11, 2020 at 03:59:09PM +0200, Otto Moerbeek wrote:
> > > This already trips the bug;
> > >
> > > man -T html -c pfctl id
> > >
> > > No need for a custom man
On 2020-06-11 16:45, Klemens Nanni wrote:
On Thu, Jun 11, 2020 at 03:59:09PM +0200, Otto Moerbeek wrote:
This already trips the bug;
man -T html -c pfctl id
No need for a custom man function. No clue yet why.
This is in mandoc's HTML parser, but only happens for multiple manuals
On Thu, Jun 11, 2020 at 03:59:09PM +0200, Otto Moerbeek wrote:
> This already trips the bug;
>
> man -T html -c pfctl id
>
> No need for a custom man function. No clue yet why.
This is in mandoc's HTML parser, but only happens for multiple manuals
in html.c:html_reset_internal():
164
On 2020-06-11 15:59, Otto Moerbeek wrote:
On Thu, Jun 11, 2020 at 03:15:55PM +0200, Romero Pérez, Abel wrote:
I've got a: man(13835) in free(): bogus pointer (double free?) 0x22c43c2813b
To check please, add the following function to .kshrc and run . ./.kshrc:
function man {
set -A
On Thu, Jun 11, 2020 at 03:15:55PM +0200, Romero Pérez, Abel wrote:
> I've got a: man(13835) in free(): bogus pointer (double free?) 0x22c43c2813b
>
> To check please, add the following function to .kshrc and run . ./.kshrc:
>
>
> function man {
> set -A array "$@"
> tag=${array[$#-1]}
I came back to a machine which had died with a uvm_fault in i915_request_create.
traces/sh reg/ps/disassembly of the function/dmesg below.
It's not a GENERIC kernel but I'll send the information anyway because
the changes don't seem especially likely to be implicated. Kernel is
GENERIC.MP +
On Thu, 11 Jun 2020 06:09:02 -0600
Todd C. Miller wrote:
> This should be fixed by the commit I just made to awk/lib.c.
> The strlcpy() length parameter was incorrect.
>
> - todd
I can confirm that with the neofetch test case, thanks a lot!
On 2020/06/11 05:59, Todd C. Miller wrote:
> On Thu, 11 Jun 2020 12:36:27 +0100, Stuart Henderson wrote:
>
> > This "fixes" it ...
> >
> > I think the most sensible approach for now is the backout diff
> > in my previous mail. Any OKs for that?
>
> The strlcpy() is wrong now that inputFS is a
On Thu, 11 Jun 2020 12:36:27 +0100, Stuart Henderson wrote:
> This "fixes" it ...
>
> I think the most sensible approach for now is the backout diff
> in my previous mail. Any OKs for that?
The strlcpy() is wrong now that inputFS is a pointer.
It should be:
strlcpy(inputFS, *FS,
The Ifail and Ofail columns are a sum of queue drops and errors. Could you run
that netstat command with -d and -e so we can see the drops and errors
separately?
Cheers,
dlg
> On 11 Jun 2020, at 2:21 pm, Gabri Tofano wrote:
>
> After extensive testing the latency spikes shown up again:
>
>
On 2020/06/11 12:23, Stuart Henderson wrote:
> On 2020/06/11 12:07, Stuart Henderson wrote:
> > On 2020/06/11 12:05, Stuart Henderson wrote:
> > > I am going to start a ports build with the January 5 version, i.e. the
> > > following backout:
> >
> > This backout fixes neofetch (the problem found
On 2020/06/11 12:07, Stuart Henderson wrote:
> On 2020/06/11 12:05, Stuart Henderson wrote:
> > I am going to start a ports build with the January 5 version, i.e. the
> > following backout:
>
> This backout fixes neofetch (the problem found by cwen) as well.
>
The upstream version from
On Thu, 11 Jun 2020 11:50:48 +0100
Stuart Henderson wrote:
> On 2020/06/11 11:48, Charlene Wendling wrote:
> > >Synopsis: FS pattern separation issue
> > >Category: awk
> > >Environment:
> > System : OpenBSD 6.7
> > Details : OpenBSD 6.7-current (GENERIC.MP) #258: Wed
> >
On 2020/06/11 12:05, Stuart Henderson wrote:
> I am going to start a ports build with the January 5 version, i.e. the
> following backout:
This backout fixes neofetch (the problem found by cwen) as well.
See attached test case extracted from libgpg-error, it fails on i386
but works on amd64. (ports/lang/gcc failed too, I forgot to save the build
directory).
TZ=GMT cvs up -D '2020/06/10 21:05:00'
January 5, 2020
works as expected
TZ=GMT cvs up -D '2020/06/10 21:05:10'
January 31, 2020
building
On Thu, Jun 11, 2020 at 11:07:11AM +0100, Laurence Tratt wrote:
> The recent DRM update has fixed one long-ish-standing bug for me where Xorg
> sometimes would get stuck while executing Xsession (I could never work out
> why) which is really good!
>
> However I've now had the following kernel
> Date: Thu, 11 Jun 2020 11:07:11 +0100
> From: Laurence Tratt
>
> The recent DRM update has fixed one long-ish-standing bug for me where Xorg
> sometimes would get stuck while executing Xsession (I could never work out
> why) which is really good!
>
> However I've now had the following kernel
On 2020/06/11 11:48, Charlene Wendling wrote:
> >Synopsis:FS pattern separation issue
> >Category:awk
> >Environment:
> System : OpenBSD 6.7
> Details : OpenBSD 6.7-current (GENERIC.MP) #258: Wed Jun 10
> 20:46:20 MDT 2020
>
The recent DRM update has fixed one long-ish-standing bug for me where Xorg
sometimes would get stuck while executing Xsession (I could never work out
why) which is really good!
However I've now had the following kernel panic several times:
kernel: page fault trap, code=0
Stopped at
Hi Gerhard,
Today I added Your patches to 6.7-stable and moved back LTE modem to USB 3.0.
So, just waiting for… nothing or kernel panic. I’ll let you know.
> On 8 Jun 2020, at 19:13, Patrick Wildt wrote:
>
> On Mon, Jun 08, 2020 at 05:31:44PM +0200, Gerhard Roth wrote:
>> On 2020-05-25
After extensive testing the latency spikes shown up again:
To the inside interface of the firewall:
Reply from 172.16.200.1: bytes=32 time<1ms TTL=254
Reply from 172.16.200.1: bytes=32 time<1ms TTL=254
Reply from 172.16.200.1: bytes=32 time<1ms TTL=254
Reply from 172.16.200.1: bytes=32 time<1ms
40 matches
Mail list logo
