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 naddy@ told me about.
>
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
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
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 +175
I have seen a proposal like this before, and I do not like the
direction this goes. If you are building your own release, you can
maintain your own pub keys as M's in your build tree. Then other
users are not being forced to see another question at install time.
> The attached patch adds an auto
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 alrea
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 thin
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
===
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
betw
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 contact
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 membar_
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 added a SYNOPSIS like i
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
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 comm
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
+++ sys/arch/amd64/conf/
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
> > > suspending by closing t
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 section 5 manuals do not ne
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: doas.conf.5
>
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 around
> 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
> > report a closed lid:
> >
> 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
> hw.sensors.acpibtn0.indicator0=Off (li
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
> report a closed lid:
>
> $ sysctl hw.sensors.acpibtn0
> hw.sensors.acpibtn0.indicator0=Off (lid
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 th
23 matches
Mail list logo
