On Sun, Dec 07, 2014 at 10:37:39PM -0800, William Orr wrote:
> This is a small documentation update for acpiac(4). The implmentation no
> longer seems to poll every 10 seconds, so I've removed it from the manpage.
>
fixed, thanks.
jmc
> Index: share/man/man4/acpiac.4
> ==
On Tue, Dec 09, 2014 at 10:26:13PM +, Alexey Suslikov wrote:
> Jason McIntyre kerhand.co.uk> writes:
>
> > On Tue, Dec 09, 2014 at 10:27:45PM +0200, Alexey Suslikov wrote:
> > > I noticed isapnp(4) and eisa(4) refs in amd64 intro(4) while amd64
> kernel
> > > config doesn't do neither isapnp
On Tue, Dec 09, 2014 at 01:14:16PM -0500, Matt Dainty wrote:
> * Ted Unangst [2014-12-08 13:28:36]:
> > On Mon, Dec 08, 2014 at 11:52, Matt Dainty wrote:
> > > * Jonathan Gray [2014-12-08 08:08:19]:
> > >>
> > >> Well any name that includes gpio that isn't taken should be fine.
> > >
> > > I wen
Sorry...I just realized that I forgot to check for malloc return
values. I need some sleep.
This diff converts relayd from hash32 to siphash. Relayd does not use
the hash function for an actual hash table, but can select a host based
on the hash of the source-address, destination-address and other data.
The key is generated when the hash function is first used (this may
happen in two diff
On Dec 9, 2014, at 9:53 AM, David Higgs wrote:
> On Tue, Dec 9, 2014 at 9:40 AM, Stuart Henderson wrote:
>>
>> I was thinking more that it might be better for sensorsd internally
>> to treat state transitions of "indicator" sensors like it treats
>> status changes, rather than change how the se
//Ciphers list. It is stored after the Session ID.
const unsigned char *ciphers = hello + 44 + sessIDLen;
int ciphersLen = (ciphers[0] << 8) | ciphers[1];
ciphers += 2;
if (ciphersLen) {
const SSL_METHOD *method = SSLv3_method();
int c
On Wednesday 10 December 2014 00:52:44, Antoine Jacoutot wrote:
> I assume we still need this:
> printf 'change paravirt0\ny\n\n0x8\nq\n' | config -ef /bsd
> under Illumos?
Correct
> in summer, I posted some paravirt patches for amd64. In response to the
> comments I received then, I have created some infrastructure to binary
> patch kernel code during boot. In order to get some feedback, I am posting
> the whole paravirt & code patching diff here. Also, KVM users may be
On Mon, Dec 08, 2014 at 12:13:11PM +0100, Martin Pieuchot wrote:
> On 04/12/14(Thu) 00:26, Alexander Bluhm wrote:
> > On Wed, Nov 26, 2014 at 12:58:35PM +0100, Martin Pieuchot wrote:
> > > @@ -761,7 +754,17 @@ report:
> > > error = EDQUOT;
> > > g
Hi,
in summer, I posted some paravirt patches for amd64. In response to the
comments I received then, I have created some infrastructure to binary
patch kernel code during boot. In order to get some feedback, I am posting
the whole paravirt & code patching diff here. Also, KVM users may be
int
On Mon, Dec 08, 2014 at 12:04:58PM +0100, Martin Pieuchot wrote:
> Is it ok?
OK bluhm@
>
> Index: net/pf.c
> ===
> RCS file: /home/ncvs/src/sys/net/pf.c,v
> retrieving revision 1.896
> diff -u -p -r1.896 pf.c
> --- net/pf.c 20 Nov
Jason McIntyre kerhand.co.uk> writes:
> On Tue, Dec 09, 2014 at 10:27:45PM +0200, Alexey Suslikov wrote:
> > I noticed isapnp(4) and eisa(4) refs in amd64 intro(4) while amd64
kernel
> > config doesn't do neither isapnp, nor eisa.
>
> those pages are not MD, so they display for all archs. that'
On Tue, Dec 09, 2014 at 10:27:45PM +0200, Alexey Suslikov wrote:
> Hello tech@.
>
> I noticed isapnp(4) and eisa(4) refs in amd64 intro(4) while amd64 kernel
> config doesn't do neither isapnp, nor eisa.
>
> Looks like a remnant after i386 intro(4).
>
> Cheers,
> Alexey
>
those pages are not M
This diff replaces hash32 by SipHash in the hash table in ospf{,6}d/lsupdate.c.
Seems pretty straightforward...
Index: usr.sbin/ospfd/lsupdate.c
===
RCS file: /cvs/src/usr.sbin/ospfd/lsupdate.c,v
retrieving revision 1.41
diff -u -p -
Hello tech@.
I noticed isapnp(4) and eisa(4) refs in amd64 intro(4) while amd64 kernel
config doesn't do neither isapnp, nor eisa.
Looks like a remnant after i386 intro(4).
Cheers,
Alexey
>
> Dear Tech,
>
> i have a ENDAT 7703 motherboard near my desk,
> the manual point out some instruction to configure the
> watchdog :
>
> //init, select the destination of command...
>
> outportb(0x2e,0x87);
> outportb(0x2e,0x87);
> outportb(0x2e,0x07);
> outportb(0x2f,0x08);
>
> //com
>
> o
On 9 December 2014 at 19:00, Christian Weisgerber wrote:
> On 2014-12-03, Mike Belopuhov wrote:
>
>> bpf aligns data following the datalink header (e.g. ethernet)
>> on the BPF_ALIGNMENT boundary. Since rev1.41 of bpf.h it's
>> uint32_t instead of a long. And also since then almost all
>> packe
* Ted Unangst [2014-12-08 13:28:36]:
> On Mon, Dec 08, 2014 at 11:52, Matt Dainty wrote:
> > * Jonathan Gray [2014-12-08 08:08:19]:
> >>
> >> Well any name that includes gpio that isn't taken should be fine.
> >
> > I went with soekrisgpio(4) as there are longer driver names in the tree,
> > (ac
On 2014-12-03, Mike Belopuhov wrote:
> bpf aligns data following the datalink header (e.g. ethernet)
> on the BPF_ALIGNMENT boundary. Since rev1.41 of bpf.h it's
> uint32_t instead of a long. And also since then almost all
> packets become "unaligned" from the tcpdump perspective and
> require
Dear Tech,
i have a ENDAT 7703 motherboard near my desk,
the manual point out some instruction to configure the
watchdog :
//init, select the destination of command...
outportb(0x2e,0x87);
outportb(0x2e,0x87);
outportb(0x2e,0x07);
outportb(0x2f,0x08);
//com
outportb(0x2e,0x30); //main
outport
Slighty different version, so withdrawal of casts and strtol => strtonum.
I still maintain (SHRT_MAX - 1) as PID_MAX is not exposed to the userland
(@tedu mentioned he planned to increase it,
would it be good to expose it via, for example, sysctl which makes it also
settable ?)
Index: bin/ps/ps.
On Dec 8, 2014, at 6:07 PM, Martin Pieuchot wrote:
> On 08/12/14(Mon) 09:35, David Higgs wrote:
>> On Mon, Dec 8, 2014 at 9:29 AM, Martin Pieuchot
>> wrote:
>> [...]
>>> Now I'd like to finish the transition that started with the import of
>>> upd(4) and move away from the actual 1 reportID = 1
yes, my scenario is:
Alix (i386) with vr0 and vr1.
vr0 connected to my ISP modem as always with:
cat /etc/hostname.vr0
dhcp
So far so go on boot time with #507 snapshot (No
On Tue, Dec 09, 2014 at 13:38, David Carlier wrote:
> -pid = atol(optarg);
> +pid = (pid_t)strtonum(optarg, -1, (SHRT_MAX - 1), &errstr);
> +if (errstr)
> +errx(1, "pid: %s", errstr);
This should definitely use PID_MAX I think. (If that's not ex
> On 2014/12/09 07:37, Brent Cook wrote:
>> If an app calls a function, it should probably check if that function
>> exists during configuration time, rather than inferring if define A
>> exists, function B and C must exist. Especially things that are just
>> protocol constant definitions. If they
On Tue, Dec 9, 2014 at 9:19 AM, Mark Kettenis wrote:
>> Date: Tue, 9 Dec 2014 14:12:20 +
>> From: Stuart Henderson
>>
>> On 2014/12/09 08:37, David Higgs wrote:
>> > Working and non-working dmesgs from the same VM below. Let me know if
>> > any more info is needed. If this is already known,
On Tue, Dec 9, 2014 at 9:40 AM, Stuart Henderson wrote:
> On 2014/12/09 09:36, David Higgs wrote:
>> On Tue, Dec 9, 2014 at 5:02 AM, Stuart Henderson wrote:
>> > On 2014/12/08 15:04, David Higgs wrote:
>> >> As per an earlier thread on misc@, this fixes sensorsd.conf(5)
>> >> parsing of SENSOR_IN
I was playing with afl a few weeks ago and found this. I believe it is
triggered by non-sequential timestamp records, but I didn’t dig into it or run
afl for particularly long. The patch below fixed all the crashes afl had found
up to that point.
The string used doesn’t matter, ‘crmsg’ just n
On 2014/12/09 09:36, David Higgs wrote:
> On Tue, Dec 9, 2014 at 5:02 AM, Stuart Henderson wrote:
> > On 2014/12/08 15:04, David Higgs wrote:
> >> As per an earlier thread on misc@, this fixes sensorsd.conf(5)
> >> parsing of SENSOR_INDICATOR values. Since parsing as integers was both
> >> undocum
On Tue, Dec 9, 2014 at 5:02 AM, Stuart Henderson wrote:
> On 2014/12/08 15:04, David Higgs wrote:
>> As per an earlier thread on misc@, this fixes sensorsd.conf(5)
>> parsing of SENSOR_INDICATOR values. Since parsing as integers was both
>> undocumented and confusing, it is no longer supported. Al
On 2014/12/09 07:37, Brent Cook wrote:
> If an app calls a function, it should probably check if that function
> exists during configuration time, rather than inferring if define A
> exists, function B and C must exist. Especially things that are just
> protocol constant definitions. If they are us
> Date: Tue, 9 Dec 2014 14:12:20 +
> From: Stuart Henderson
>
> On 2014/12/09 08:37, David Higgs wrote:
> > Working and non-working dmesgs from the same VM below. Let me know if
> > any more info is needed. If this is already known, sorry for the
> > noise.
>
> gonzalo@ has seen similar on
On 2014/12/09 08:37, David Higgs wrote:
> Working and non-working dmesgs from the same VM below. Let me know if
> any more info is needed. If this is already known, sorry for the
> noise.
gonzalo@ has seen similar on vr(4) starting recently, but the timing
doesn't quite match yours.
> # does no
Working and non-working dmesgs from the same VM below. Let me know if
any more info is needed. If this is already known, sorry for the
noise.
--david
# does not work
OpenBSD 5.6-current (RAMDISK_CD) #555: Tue Dec 9 00:50:21 MST 2014
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/
Hi all,
I made a small first diff to replace some ato* functions call to strtonum/l
ones ...
Althought not sure about the sudo one because it looks contrib code and
also might appear a bit "overengineered" ... but in case !
Thanks in advance.
Index: bin/ps/ps.c
==
On Tue, Dec 9, 2014 at 6:18 AM, Stuart Henderson wrote:
> On 2014/12/09 12:30, Lukas Tribus wrote:
>> Hi,
>>
>> I'm linking haproxy (current git master) against libressl 2.1.2
>> portable on linux, but seeing 2 issues (not present in previous
>> libressl 2.1.1):
>>
>>
>> Issue number one (not sure
On 2014/12/09 12:30, Lukas Tribus wrote:
> Hi,
>
> I'm linking haproxy (current git master) against libressl 2.1.2
> portable on linux, but seeing 2 issues (not present in previous
> libressl 2.1.1):
>
>
> Issue number one (not sure what happens here):
>
> include/openssl/ssl.h:503:2: error: un
Hi,
I'm linking haproxy (current git master) against libressl 2.1.2
portable on linux, but seeing 2 issues (not present in previous
libressl 2.1.1):
Issue number one (not sure what happens here):
include/openssl/ssl.h:503:2: error: unknown type name ‘uint8_t’
uint8_t *tlsext_ecpointformatlist
On 2014/12/08 15:04, David Higgs wrote:
> As per an earlier thread on misc@, this fixes sensorsd.conf(5)
> parsing of SENSOR_INDICATOR values. Since parsing as integers was both
> undocumented and confusing, it is no longer supported. Also, bail on
> error if the high/low values don’t create a vali
40 matches
Mail list logo
