Re: request for test: mfii

2016-10-25 Thread YASUOKA Masahiko
On Wed, 26 Oct 2016 10:26:19 +1100 Jonathan Gray wrote: > On Tue, Oct 25, 2016 at 05:29:55PM +0900, YASUOKA Masahiko wrote: >> I'm working on making mfii(4) bio(4) capable. >> >> If you have a machine which has mfii(4), I'd like you to test the diff >> following. (It might be

Re: request for test: mfii

2016-10-25 Thread Jonathan Gray
On Tue, Oct 25, 2016 at 05:29:55PM +0900, YASUOKA Masahiko wrote: > Hi, > > I'm working on making mfii(4) bio(4) capable. > > If you have a machine which has mfii(4), I'd like you to test the diff > following. (It might be risky for production machines for this > moment.) > > After the diff

Re: aml_rdpciaddr is busted

2016-10-25 Thread Mark Kettenis
> Date: Wed, 19 Oct 2016 21:51:47 +0200 (CEST) > From: Mark Kettenis > > The bus number it reports will be totally bogus for devices behind PCI > bridges. As a consequence AML will peek and poke at registers of the > wrong device. This is what caused the suspend issues

simplify vxlan_lookup return value handling

2016-10-25 Thread Mike Belopuhov
After my previous commit to the vxlan(4) driver it can no longer return -1 making this code path obsolete. OK to remove it? diff --git sys/netinet/udp_usrreq.c sys/netinet/udp_usrreq.c index 60a7bdf..fc5e866 100644 --- sys/netinet/udp_usrreq.c +++ sys/netinet/udp_usrreq.c @@ -388,17 +388,12 @@

pfctl skip invalid broadcast

2016-10-25 Thread Alexander Bluhm
Hi, On my test machine I have added a vether0 with a /32 IPv4 address. Since then the regress/sbin/pfctl pfi2 test fails. vether0: flags=8843 mtu 1500 ... inet 10.188.80.21 netmask 0x The test basically does this: echo

Re: kernel without inet6

2016-10-25 Thread Mike Belopuhov
On 25 October 2016 at 16:43, Alexander Bluhm wrote: > Hi, > > Make kernel without INET6 compile again. > > ok? > > bluhm > Sure, OK mikeb

kernel without inet6

2016-10-25 Thread Alexander Bluhm
Hi, Make kernel without INET6 compile again. ok? bluhm Index: net/if_vxlan.c === RCS file: /data/mirror/openbsd/cvs/src/sys/net/if_vxlan.c,v retrieving revision 1.50 diff -u -p -r1.50 if_vxlan.c --- net/if_vxlan.c 14 Oct 2016

video(1): maintain image aspect ratio

2016-10-25 Thread Dmitrij D. Czarkoff
Hi! Another thing that bothered me about video(1) from Xenocara is that it does not maintain frame aspect ratio. The diff below adds panning to maintain aspect ratio after resize. Comments? OKs? -- Dmitrij D. Czarkoff Index: video.c

Re: add in6 multicast support to vxlan(4) ; question on mbufs

2016-10-25 Thread Mike Belopuhov
On Tue, Oct 11, 2016 at 20:41 +1000, David Gwynne wrote: > On Tue, Oct 11, 2016 at 12:06:46AM +0200, Mike Belopuhov wrote: > > On Fri, Oct 07, 2016 at 20:48 +1000, David Gwynne wrote: > > > On Thu, Oct 06, 2016 at 12:13:20PM +0200, Mike Belopuhov wrote: > > > > m_pullup will always get a new mbuf

request for test: mfii

2016-10-25 Thread YASUOKA Masahiko
Hi, I'm working on making mfii(4) bio(4) capable. If you have a machine which has mfii(4), I'd like you to test the diff following. (It might be risky for production machines for this moment.) After the diff applied, bioctl(8) against the disk (eg. sd0) starts working and also "sysctl

Re: CVS: cvs.openbsd.org: xenocara - pledge update for xterm

2016-10-25 Thread Sebastien Marie
On Mon, Oct 24, 2016 at 01:31:35PM -0600, Matthieu Herrb wrote: > CVSROOT: /cvs > Module name: xenocara > Changes by: matth...@cvs.openbsd.org2016/10/24 13:31:35 > > Modified files: > app/xterm : Makefile xterm.man xtermcfg.h > > Log message: > Disable Tektronics 4014

Re: network performance fun

2016-10-25 Thread Mike Belopuhov
On 25 October 2016 at 08:25, Mike Belopuhov wrote: > On 25 October 2016 at 02:34, David Gwynne wrote: >>> I see. I will double check this tomorrow but your approach >>> looks solid. >> >> it's obviously an interaction between intel nics that do not align

Re: network performance fun

2016-10-25 Thread Mike Belopuhov
On 25 October 2016 at 02:34, David Gwynne wrote: >> I see. I will double check this tomorrow but your approach >> looks solid. > > it's obviously an interaction between intel nics that do not align > their ethernet headers correctly, and the M_PREPEND which i just > changed