Re: Kernel Panic on 6.2 amd64 when run0 RT3070 based device is attached during boot

Last tests shows that 6.2amd64 system goes reboot in a random manner with run0 driver is loaded. Reboots mainly caused when data is transferred other run0 device but absolutely sporadically. No dmesg messages provided with these reboots. It has been tested on two different laptops with the same

Re: Zap PF_TRANS_ALTQ

On Fri, Jan 19, 2018 at 02:18:08PM -0700, Theo de Raadt wrote: > > > On Fri, Jan 19, 2018 at 08:24:23PM +, Stuart Henderson wrote: > > > > To be honest though, unless it's in the way of something, I'm not sure > > > > it's > > > > worth removing. > > > > > > If those constatns are in ports

Re: snmpd trap.c uninitialized variable

On Sat, Jan 20 2018, Rob Pierce wrote: > The pid_t confused me, but I believe this is correct - i.e. referring to the > packet id as oppose to a process id. > > Comments? Ok? Makes sense, ok. Would you mind converting the %zd to %zu, while here? > Index: trap.c >

Re: tcp reaper timeout

On Sat, Jan 20, 2018 at 15:17 +0100, Alexander Bluhm wrote: > Hi, > Hi, While I'm not against making all TCP timeouts look similar, I'd like to understand if there's any other reason to do it other than "consistency". > The tcp reaper timeout is still imlemented as soft timeout. So it > can

snmpd trap.c uninitialized variable

The pid_t confused me, but I believe this is correct - i.e. referring to the packet id as oppose to a process id. Comments? Ok? Index: trap.c === RCS file: /cvs/src/usr.sbin/snmpd/trap.c,v retrieving revision 1.29 diff -u -p -r1.29

Re: inteldrm(4) tests needed

On Mon, Jan 15, 2018 at 01:02 +0100, Mark Kettenis wrote: > The diff below adopts more of the Linux code to manage i2c > transactions on hardware supported by inteldrm(4). The i2c stuff is > reponsible for detecting panels and monitors, so it is somewhat > important that this works right. And

Re: disabled code in ksh tree.c

On Tue, Jan 16, 2018 at 04:29:59PM +0100, Jeremie Courreges-Anglas wrote: > On Mon, Jan 15 2018, "Michael W. Bombardieri" wrote: > > On Sun, Jan 14, 2018 at 05:47:43PM +0100, Jeremie Courreges-Anglas wrote: > >> On Sun, Jan 14 2018, Anton Lindqvist wrote: > >> >

tcp reaper timeout

Hi, The tcp reaper timeout is still imlemented as soft timeout. So it can run while net lock is held by others and it is not synchronized with the other tcp timeouts. Convert it to an ordinary tcp timeout so it is scheduled on the same timeout thread. It grabs the net lock to make sure that

Re: fix xserver build with clang on armv7

On Sat, Jan 20, 2018 at 10:50:58PM +1100, Jonathan Gray wrote: > On Sat, Jan 20, 2018 at 11:19:22AM +0100, Matthieu Herrb wrote: > > Hi, > > > > I'm not sure if the __VFP_FP__ section below was still useful for gcc > > builds, at lead it doesn't build and doesn't look needed with clang > > (the

Re: fix xserver build with clang on armv7

On Sat, Jan 20 2018, Jonathan Gray wrote: > On Sat, Jan 20, 2018 at 11:19:22AM +0100, Matthieu Herrb wrote: >> Hi, >> >> I'm not sure if the __VFP_FP__ section below was still useful for gcc >> builds, at lead it doesn't build and doesn't look needed with clang >> (the functions

Re: fix xserver build with clang on armv7

On Sat, Jan 20, 2018 at 11:19:22AM +0100, Matthieu Herrb wrote: > Hi, > > I'm not sure if the __VFP_FP__ section below was still useful for gcc > builds, at lead it doesn't build and doesn't look needed with clang > (the functions are all provied by libcompiler_rt, which is included). > > ok ?

fix xserver build with clang on armv7

Hi, I'm not sure if the __VFP_FP__ section below was still useful for gcc builds, at lead it doesn't build and doesn't look needed with clang (the functions are all provied by libcompiler_rt, which is included). ok ? Index: hw/xfree86/os-support/bsd/arm_video.c

[patch] resolv.h lacked definition for in{6}_addr

found via GNU autoconf and its AC_CHECK_HEADERS Kudos go to . As workaround, I am going to change my configure script to use AC_HEADER_RESOLV. --- src/include/resolv.h +++ src/include/resolv.h @@ -92,2 +92,3 @@ #include +#include #include