Re: Fix acpibtn(4) LID sensor

> Date: Wed, 6 Jan 2016 10:05:48 +0100 > From: Martin Pieuchot > > My x220 never generates an event when the LID opens. So after > suspending by closing the lid the corresponding sensors will always > report a closed lid: > > $ sysctl hw.sensors.acpibtn0 >

Re: remove language catalogs from vi

On Wed, Jan 06, 2016 at 12:57:06AM +0100, Ingo Schwarze wrote: > Hmpf, i hit "send" too early. > > Ingo Schwarze wrote on Wed, Jan 06, 2016 at 12:50:16AM +0100: > > > If millert@, bentley@, or tb@ wants to commit this, it's OK schwarze@. > > If, against all odds, anything should break, i'm

Fix acpibtn(4) LID sensor

My x220 never generates an event when the LID opens. So after suspending by closing the lid the corresponding sensors will always report a closed lid: $ sysctl hw.sensors.acpibtn0 hw.sensors.acpibtn0.indicator0=Off (lid open) This confuses programs like upowerd(8) used at least by GNOME which

Re: Fix acpibtn(4) LID sensor

> Date: Wed, 6 Jan 2016 01:16:38 -0800 > From: Mike Larkin > > On Wed, Jan 06, 2016 at 10:05:48AM +0100, Martin Pieuchot wrote: > > My x220 never generates an event when the LID opens. So after > > suspending by closing the lid the corresponding sensors will always > >

Re: Fix acpibtn(4) LID sensor

On Wed, Jan 06, 2016 at 10:33:58AM +0100, Mark Kettenis wrote: > > Date: Wed, 6 Jan 2016 01:16:38 -0800 > > From: Mike Larkin > > > > On Wed, Jan 06, 2016 at 10:05:48AM +0100, Martin Pieuchot wrote: > > > My x220 never generates an event when the LID opens. So after > > >

Putting more consistency on SYNOPSIS in section 5 (was: mention /etc/doas.conf instead of plain doas.conf)

2016-01-01 2:39 GMT+03:00 Amit Kulkarni : > I just switched from sudo to doas and was stumped by this. > > The doas code expects doas.conf in /etc yet the manpage does not explicitly > make that clear. I added a SYNOPSIS like in "man login.conf". While mdoc(7) says that

Re: mention /etc/doas.conf instead of plain doas.conf

2016-01-01 2:39 GMT+03:00 Amit Kulkarni : > I just switched from sudo to doas and was stumped by this. > > The doas code expects doas.conf in /etc yet the manpage does not explicitly > make that clear. I added a SYNOPSIS like in "man login.conf". > > Thanks > > Index:

Re: Xen virtual network (Netfront) driver

On Wed, Jan 06, 2016 at 16:37 +0100, Mike Belopuhov wrote: > There's still stuff to do, but it receives and transmits reliably > (at least on modern Xen) so I'd like to get it in. Man page will > follow. > > OK? > Just noticed that a couple of debug printfs have sneaked in. I'm not going to

Xen virtual network (Netfront) driver

There's still stuff to do, but it receives and transmits reliably (at least on modern Xen) so I'd like to get it in. Man page will follow. OK? diff --git sys/arch/amd64/conf/GENERIC sys/arch/amd64/conf/GENERIC index fca4459..77e07cc 100644 --- sys/arch/amd64/conf/GENERIC +++

Re: Putting more consistency on SYNOPSIS in section 5 (was: mention /etc/doas.conf instead of plain doas.conf)

On Wed, Jan 06, 2016 at 04:41:13PM +0300, Vadim Zhukov wrote: > 2016-01-01 2:39 GMT+03:00 Amit Kulkarni : > > I just switched from sudo to doas and was stumped by this. > > > > The doas code expects doas.conf in /etc yet the manpage does not explicitly > > make that clear. I

Re: Xen virtual network (Netfront) driver

On Wed, Jan 06, 2016 at 04:37:36PM +0100, Mike Belopuhov wrote: > There's still stuff to do, but it receives and transmits reliably > (at least on modern Xen) so I'd like to get it in. Man page will > follow. > > OK? > I can see it works now and as mentioned in icb: I just had the first

Re: npppd: simplify and lock down priv_open()

On Fri, 01 Jan 2016 10:55:14 -0800, Philip Guenther wrote: > Finally got back to this; this diff should fix open(O_NONBLOCK) of bpf, > tun, and tap devices. The bikeshed question is whether this should use > O_NONBLOCK or FNONBLOCK... OK millert@ though I would have used FNONBLOCK. - todd

Re: Xen virtual network (Netfront) driver

On Wed, 6 Jan 2016, Mike Belopuhov wrote: > There's still stuff to do, but it receives and transmits reliably > (at least on modern Xen) so I'd like to get it in. Man page will > follow. I only had a quick glance at the code, but I have one comment about your use of memory barriers. The

Allow custom signify key in install.sub

Hello tech, The attached patch adds an autoinstall question to install.sub that lets the user specify a custom signify key for the SHA256.sig file. I like to track -stable for a bunch of my servers, and it's convenient to make a release and use autoinstall with bsd.rd to keep up to date. I

Re: onerng(4): new TRNG device

Second submission, based on feedback from mpi@ and @deraadt. * match is now on the device level * attach now looks for interfaces by index (and verifies it gets the right ones) since it can no longer iterate over the device array * added missing failure check * fixed incorrect failure check *

Re: ipmi(4) - Stop watchdog internal timer properly

Reflected kettenis@'s comments: - Initialize sc_wdog_period before use. - Define less stupid register names. * When stopping wdog, not only disabling reboot, but also stop timer. diff --git a/sys/dev/ipmi.c b/sys/dev/ipmi.c index c837234..d579987 100644 --- a/sys/dev/ipmi.c +++ b/sys/dev/ipmi.c

Re: ipmi(4) - Don't check threshold erroneously

Update: - Better log message - Exclude "read disabled sensor" part * Correct sensor threashold handling by properly checking response of Get Sensor Reading Command. diff --git a/sys/dev/ipmi.c b/sys/dev/ipmi.c index d579987..5895347 100644 --- a/sys/dev/ipmi.c +++ b/sys/dev/ipmi.c @@ -175,7

Re: Get PCI resources from ACPI

Hi team, On Thu, Dec 31, 2015 at 10:05 PM, Philip Guenther wrote: > On Wed, 30 Dec 2015, Mark Kettenis wrote: > ... >> Updated diff. Once again the ACPI standard is ambiguous and/or violated >> by the hardware vendors. This should fix at least the ports Dell r620 >> that

Re: ifconfig format bug

On Wed, Jan 06, 2016 at 01:59:41PM -0500, Ted Unangst wrote: > ifconfig.c: In function 'print_media_word': > ifconfig.c:2776: error: format '%d' expects type > 'int', but argument 2 has type 'long long unsigned int' > > maybe a cast to int is ok? but if there's no harm in printing the > whole

initialize A-MPDU params in htcap element

I forgot about initializing the A-MPDU parameters field in HT capability elements. This field specifies the max size of A-MPDU, and the spacing of A-MPDU subframes. Spacing is currently set to zero which means 'no restricition', but intel wireless devices need at least 4 microseconds of slack

ifconfig format bug

ifconfig.c: In function 'print_media_word': ifconfig.c:2776: error: format '%d' expects type 'int', but argument 2 has type 'long long unsigned int' maybe a cast to int is ok? but if there's no harm in printing the whole thing, i believe that's safer. Index: ifconfig.c