Re: Completely disable 2D acceleration on Broadwell

On Tue, Dec 01, 2015 at 04:44:39PM +0100, Mark Kettenis wrote: > As tedu@ reported (and some pople on misc@ confirmed) partly disabling > 2D acceleration on Broadwell made X unstable. It really looks like > the alternative BLT path isn't well tested and therefore buggy. So > here is a diff that d

unifdef(1) - in-place editing without backups

unifdef's -M option is like sed's -i option, editing in-place and saving a backup with the supplied extension. Currently, if -M '' is passed: * the original file is copied to the backup filename (i.e. itself) * the temp file is copied to the original filename It therefore has the same behavio

IPsec: remove unimplemented algorithms

pfkeyv2.h has defines for a number of obsolete algorithms we don't and won't implement. These have been mechanically added to ipsecctl and iked. I'd like to remove all traces of these zombies. (SADB_X_AALG_DES designates DES-MAC authentication.) ok? Index: sys/net/pfkeyv2.h ===

ssh-agent: flush stdout before main loop in foreground mode

When ssh-agent is run in foreground mode with -d and stdout is not a terminal, the output including the path to the listening socket and PID may not be written before the main loop begins. Since no further output is written to stdout, this output may never be written. $ ssh-agent -d < /dev/null 2>

Re: pledge dhcpd(8), 1st attempt

On 2015/12/01 21:24, Ricardo Mestre wrote: > Hi tech@ > > This is my first attempt at pledging dhcpd(8), right now I don't have time to > go further, but this is a working diff I having seating at my tree I want to > show you, although tomorrow I intend to get back at it. > > Declare usage() as _

pledge dhcpd(8), 1st attempt

Hi tech@ This is my first attempt at pledging dhcpd(8), right now I don't have time to go further, but this is a working diff I having seating at my tree I want to show you, although tomorrow I intend to get back at it. Declare usage() as __dead since it never returns, hoist up sync_init() since

Re: use m_defrag in fxp

> Date: Tue, 1 Dec 2015 19:30:44 +0100 > From: Claudio Jeker > > Use m_defrag in fxp to make it nicer and simpler. > > works for me with > fxp0 at pci6 dev 6 function 0 "Intel 8255x" rev 0x08, i82559: apic 6 int 21, > address 00:d0:b7:4c:36:c4 > inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4 >

Re: Slow wsmouse down in console

Hi Ulf, I indeed guess there are not much console users these modern days. Personally, my current laptop is so slow in X that I find it convenient to switch back and forth between ttyC[014]. In that regard, I will probably investigate the possibility of sharing the copy-buffer between screens. Wh

Re: use m_defrag in fxp

On Tue, Dec 01, 2015 at 07:30:44PM +0100, Claudio Jeker wrote: > Use m_defrag in fxp to make it nicer and simpler. > > works for me with > fxp0 at pci6 dev 6 function 0 "Intel 8255x" rev 0x08, i82559: apic 6 int 21, > address 00:d0:b7:4c:36:c4 > inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4 >

Re: Simplify rtredirect

On Tue, Dec 01, 2015 at 05:53:47PM +0100, Martin Pieuchot wrote: > The netmask argument is always NULL and the flags are always the same. > RTF_GATEWAY|RTF_HOST routes *are* routes created by redirect. > > I need this simplification to move forward with my rt_mask() cleanup. > > ok? OK bluhm@

Re: ND and rt_ifa_add(9)

On Tue, Dec 01, 2015 at 01:34:15PM +0100, Martin Pieuchot wrote: > Diff below converts two custom uses of rtrequest(9) to rt_ifa_add(9). > These are used to automagically install and remove the RTF_CONNECTED > route obtained from a router advertisement. > > This changes the existing logic a bit to

use m_defrag in fxp

Use m_defrag in fxp to make it nicer and simpler. works for me with fxp0 at pci6 dev 6 function 0 "Intel 8255x" rev 0x08, i82559: apic 6 int 21, address 00:d0:b7:4c:36:c4 inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4 It would be possible to drop the mbuf on error and then the ifq_deq_begin and

Re: inteldrm: HBR2 support for DisplayPort 1.2

On Tue, 1 Dec 2015, Jonathan Gray wrote: > On Tue, Dec 01, 2015 at 07:00:19AM +, Scot Doyle wrote: > > Should we include "INTEL_INFO(dev)->gen >= 8"? There is at least one known > > regression (booting with blank screen) described in commit > > 8749be86a8f0c8a956d20f7d3c768ed6d1e356a1. > > I

Simplify rtredirect

The netmask argument is always NULL and the flags are always the same. RTF_GATEWAY|RTF_HOST routes *are* routes created by redirect. I need this simplification to move forward with my rt_mask() cleanup. ok? Index: net/route.c ===

Completely disable 2D acceleration on Broadwell

As tedu@ reported (and some pople on misc@ confirmed) partly disabling 2D acceleration on Broadwell made X unstable. It really looks like the alternative BLT path isn't well tested and therefore buggy. So here is a diff that disables 2D acceleration completely. Those who don't care about suspend

ND and rt_ifa_add(9)

Diff below converts two custom uses of rtrequest(9) to rt_ifa_add(9). These are used to automagically install and remove the RTF_CONNECTED route obtained from a router advertisement. This changes the existing logic a bit to match the netinet behavior. The route will now be attached to the ``ifa''

Re: serialise if_start calls

> On 1 Dec 2015, at 5:40 AM, Hrvoje Popovski wrote: > > On 30.11.2015. 12:55, David Gwynne wrote: >> this tweaks the guts of if_start so it guarantees that there's only >> ever one call to ifp->if_start running in the system at a time. >> previously this was implicit because it could only be cal

pledge spamd(8) and spamd-setup(8)

Hello tech@! As per Theo's request I'm sending both patches attached below for spamd(8) and spamd-setup(8) in order to pledge them and for spamd(8) I will just transcribe the same text I sent before, but with an addition spotted by himself after I ran a patch on libc. spamd(8): Hoist the sync_in

Re: Backward compat

On Mon, Nov 30, 2015 at 06:16:17PM +0100, Martin Pieuchot wrote: > I'm about to kill rt_mask() and I believe it's not worth keeping this > old backward compatibility. > > Anybody disagree? Ok? OK bluhm@ > > Index: netinet/if_ether.c > ===

Re: lex(1) allocation cleanup

Michael McConville wrote: > Theo de Raadt wrote: > > > > If it is not our own fork -- then stay away from this. It is > > > > pointless putting increasing delta into code which does not run in > > > > risk environments. > > > > > > I thought we had already made that decision based on tedu's recen

Re: move scorefile + pledge for robots(6)

On Tue, Dec 01, 2015 at 03:08:39AM -0500, Ted Unangst wrote: > Theo Buehler wrote: > > Robots has a nicely implemented score file, so I decided not to touch > > it, except for moving to $HOME by default. Needs pledge("getpw") > > because of that. > > I think some combination of $LOGNAME, $USER, a

Re: what approach for TRNG?

Devin Reade wrote: > A while ago a posted a dmesg for a TRNG USB device (the MoonBase Otago > OneRNG) per > . > > I'm looking at adding support for this device but haven't splunked too > mu

Re: move scorefile + pledge for robots(6)

Theo Buehler wrote: > Robots has a nicely implemented score file, so I decided not to touch > it, except for moving to $HOME by default. Needs pledge("getpw") > because of that. I think some combination of $LOGNAME, $USER, and getlogin() should suffice for that. I mean, getlogin() alone should be