use DRM_IOCTL_GET_PCIINFO in libdrm

2016-11-19 Thread Jonathan Gray
Support libdrm functions required for Mesa versions >= 13. On linux this information is pulled out of a psuedo filesystem, here the new DRM_IOCTL_GET_PCIINFO ioctl is used for the same. Only primary drm nodes are handled, render and control nodes which we don't have aren't. This also only

Re: ospfd - add metric and type to print_redistribute

2016-11-19 Thread Stuart Henderson
On 2016/11/19 10:06, Remi Locherer wrote: > Hi, > > In the output of ospfd -nv I miss metric and type for the redistribute > statement. The below patch adds this. OK with me. This prints the values when they're at defaults as well, but I don't think that is a problem.

add a new DRM_IOCTL_GET_PCIINFO ioctl

2016-11-19 Thread Jonathan Gray
To pull pci information from the kernel for drm devices we need a common drm ioctl. This is a requirement for implementing functions in libdrm which are used by Mesa >= 13. To not clash with drm headers this is added via pciio.h at kettenis' suggestion. The ioctl number reuses that of

ospfd - add metric and type to print_redistribute

2016-11-19 Thread Remi Locherer
Hi, In the output of ospfd -nv I miss metric and type for the redistribute statement. The below patch adds this. Sample output: remi@mistral:..in/ospfd% doas obj/ospfd -nv WARNING: IP forwarding NOT enabled, running as stub router router-id 10.10.10.1 fib-update yes rfc1583compat yes stub

Re: ospfd - add metric and type to print_redistribute

2016-11-19 Thread Claudio Jeker
On Sat, Nov 19, 2016 at 11:38:56AM +, Stuart Henderson wrote: > On 2016/11/19 10:06, Remi Locherer wrote: > > Hi, > > > > In the output of ospfd -nv I miss metric and type for the redistribute > > statement. The below patch adds this. > > OK with me. This prints the values when they're at

Re: Looking for iwn testers (was: Re: add MCS support to radiotap)

2016-11-19 Thread Stefan Sperling
On Sat, Oct 29, 2016 at 01:13:47PM +0200, Stefan Sperling wrote: > On Sat, Oct 08, 2016 at 07:34:55PM +0200, Mark Kettenis wrote: > > > The addition might need to be tested on a 1TR1 and 2T3R setups. I can > > > test the latter, but I have no hardware to test the former. > > > > FWIW, this seems

Re: pf af-to route output

2016-11-19 Thread Alexandr Nedvedicky
Hello, > The !r->rt case is only used by af-to. pf_route6() calls ip6_output() > to do the work while pf_route() has some custom implementation for > that. It is simpler to call ip_output() or ip6_output() from > pf_test() directly. It looks good to me. I'm O.K. with change. regards sasha

make tcpdump indicate basic rates

2016-11-19 Thread Stefan Sperling
ok? Index: print-802_11.c === RCS file: /cvs/src/usr.sbin/tcpdump/print-802_11.c,v retrieving revision 1.34 diff -u -p -r1.34 print-802_11.c --- print-802_11.c 8 Oct 2016 14:45:11 - 1.34 +++ print-802_11.c 19 Nov

reduce iwm's RTS retry limit

2016-11-19 Thread Stefan Sperling
The RTS retry limit we inherited from Linux seems insanely high. It seems to be the cause for "bursty" pings and high latency for smaller packets while larger packets from TCP streams are stuck in the Tx queue: 64 bytes from 192.168.1.12: icmp_seq=84 ttl=251 time=380.203 ms 64 bytes from

Re: pf af-to route output

2016-11-19 Thread Richard Procter
On Mon, 14 Nov 2016, Alexander Bluhm wrote: > Hi, > > The !r->rt case is only used by af-to. pf_route6() calls ip6_output() > to do the work while pf_route() has some custom implementation for > that. It is simpler to call ip_output() or ip6_output() from > pf_test() directly. > > ok? Note,

Re: pine64: working bootloader

2016-11-19 Thread Jonathan Gray
On Thu, Nov 17, 2016 at 04:25:14AM -0500, Ian Sutton wrote: > (resending as list seemed to eat my last mail) > > Hi, > > I've got a natively-built bootloader working on the pine64 boards > generously donated to the foundation. Simply dd(1) the following image > directly to a uSD card, insert it,

[PATCH] pf: fold pf_headers into pf_pdesc

2016-11-19 Thread Richard Procter
Hi, This patch folds pf_headers into pf_pdesc, and eliminates pf_pdesc's header pointers. It's mostly mechanical except for strengthening a guard in pf_socket_lookup(). I've an OK from bluhm@ but to give others a heads-up I won't commit for another 48 hours. +ve removes the header buffer