* sven falempin sven.falem...@gmail.com [2014-12-10 12:32:15]:
On Wed, Dec 10, 2014 at 9:31 AM, Stuart Henderson st...@openbsd.org wrote:
On 2014/12/10 09:15, sven falempin wrote:
http://lxr.free-electrons.com/source/drivers/hwmon/nct6775.c
https://github.com/groeck/nct6775
So i guess
i think this page fault is triggered by jenkins
during resume.
login: kernel: page fault trap, code=0
Stopped at in_selectsrc+0xd8: movl 0xf0(%esi),%ebx
ddb{0} trace
in_selectsrc(f617cdc8,d80b6714,d35d9270,d8cfac44,d8cfac34) at in_selectsrc+0xd8
Date: Thu, 11 Dec 2014 05:08:11 -0500
From: Matt Dainty m...@bodgit-n-scarper.com
* sven falempin sven.falem...@gmail.com [2014-12-10 12:32:15]:
On Wed, Dec 10, 2014 at 9:31 AM, Stuart Henderson st...@openbsd.org wrote:
On 2014/12/10 09:15, sven falempin wrote:
On 11/12/14(Thu) 11:31, frantisek holop wrote:
i think this page fault is triggered by jenkins
during resume.
login: kernel: page fault trap, code=0
Stopped at in_selectsrc+0xd8: movl 0xf0(%esi),%ebx
ddb{0} trace
in_selectsrc(f617cdc8,d80b6714,d35d9270,d8cfac44,d8cfac34) at
On Wed, Dec 10, 2014 at 12:32:02AM +0100, Stefan Fritsch wrote:
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
Martin Pieuchot, 11 Dec 2014 11:59:
On 11/12/14(Thu) 11:31, frantisek holop wrote:
i think this page fault is triggered by jenkins
during resume.
login: kernel: page fault trap, code=0
Stopped at in_selectsrc+0xd8: movl 0xf0(%esi),%ebx
ddb{0} trace
On 09/12/14(Tue) 10:57, David Higgs wrote:
On Dec 8, 2014, at 6:07 PM, Martin Pieuchot mpieuc...@nolizard.org wrote:
On 08/12/14(Mon) 09:35, David Higgs wrote:
On Mon, Dec 8, 2014 at 9:29 AM, Martin Pieuchot mpieuc...@nolizard.org
wrote:
[...]
Now I'd like to finish the transition
Date: Thu, 11 Dec 2014 12:22:56 +0100
From: Martin Pieuchot mpieuc...@nolizard.org
Index: ucycom.c
===
RCS file: /home/ncvs/src/sys/dev/usb/ucycom.c,v
retrieving revision 1.29
diff -u -p -r1.29 ucycom.c
--- ucycom.c 12 Jul
Hello,
For the historic reasons there is a significant amount of duplicated
functionality.
For example one can use openssl rsa/dsa/ec to create/modify private/public keys
or it's possible to just use a generic openssl genpkey/pkey interface. I'd like
to suggest to clean up the first set of
On 11/12/14(Thu) 12:48, Mark Kettenis wrote:
Date: Thu, 11 Dec 2014 12:22:56 +0100
From: Martin Pieuchot mpieuc...@nolizard.org
Index: ucycom.c
===
RCS file: /home/ncvs/src/sys/dev/usb/ucycom.c,v
retrieving revision
On 2014/12/11 16:08, Dmitry Eremin-Solenikov wrote:
Hello,
For the historic reasons there is a significant amount of duplicated
functionality.
For example one can use openssl rsa/dsa/ec to create/modify private/public
keys
or it's possible to just use a generic openssl genpkey/pkey
Many Lolz.. Lukas you just made my day..
They've been misused that way, and more than once, by more than one
project. This is why we really want it to be just a string, and
strongly discourage people from using it in the way it has been
abused.
... we could always change it so the
Thank you all,
I grep(ed) -r NCT6 in sys and didn't find wbsio, I guess those
christmass holydays will be much welcome !
Does the wbsio detect the watchdog in the apu card ?
On Thu, Dec 11, 2014 at 5:56 AM, Mark Kettenis mark.kette...@xs4all.nl wrote:
Date: Thu, 11 Dec 2014 05:08:11 -0500
2014-12-11 15:40 GMT+03:00 Stuart Henderson st...@openbsd.org:
On 2014/12/11 16:08, Dmitry Eremin-Solenikov wrote:
Hello,
For the historic reasons there is a significant amount of duplicated
functionality.
For example one can use openssl rsa/dsa/ec to create/modify private/public
keys
or
On 2014/12/11 07:41, sven falempin wrote:
Thank you all,
I grep(ed) -r NCT6 in sys and didn't find wbsio, I guess those
christmass holydays will be much welcome !
Does the wbsio detect the watchdog in the apu card ?
No, as the manual says, Only the hardware monitoring function is
On 2014/12/11 16:42, Dmitry Eremin-Solenikov wrote:
2014-12-11 15:40 GMT+03:00 Stuart Henderson st...@openbsd.org:
On 2014/12/11 16:08, Dmitry Eremin-Solenikov wrote:
Hello,
For the historic reasons there is a significant amount of duplicated
functionality.
For example one can use
Hi all,
I've just noticed one more page in need of 5.5 - 5.6 update - diff
below.
Regards,
Raf
Index: www/stable.html
===
RCS file: /cvs/www/stable.html,v
retrieving revision 1.36
diff -u -p -r1.36 stable.html
--- www/stable.html
On 11/12/14(Thu) 12:37, frantisek holop wrote:
login: kernel: page fault trap, code=0
Stopped at in_selectsrc+0xd8: movl 0xf0(%esi),%ebx
ddb{0} trace
in_selectsrc(f617cdc8,d80b6714,d35d9270,d8cfac44,d8cfac34) at
in_selectsrc+0xd8
On Thu, Dec 11, 2014 at 6:41 AM, Lukas Tribus luky...@hotmail.com wrote:
Many Lolz.. Lukas you just made my day..
They've been misused that way, and more than once, by more than one
project. This is why we really want it to be just a string, and
strongly discourage people from using it in
Previously, they were all using the portable package version, rather
than the individual library versions. openssl(1)'s pc file represents
the LibreSSL-portable release however.
$ pkg-config --modversion libtls
1:0:0
$ pkg-config --modversion openssl
2.1.2
$ pkg-config --modversion libssl
30:0:0
Short answer Dmitry: No.
Doing so doesn't solve a real problem, and creates many others. Sure
we might not like it ourselves and would never build new software this
way, but removing this legacy at this stage would only break things
for no benefit. (We're very happy to break things when there is
To reduce reliance on this string, and to make it more consistently
correct between LibreSSL-portable releases, reduce OPENSSL_VERSION_TEXT
to say the bare minimum.
There are better, more portable and consistent mechanisms for
determining the installed versions of packages, such as the OS package
On Wed, Dec 10, 2014 at 06:15:04PM +0200, Kaspars Bankovskis wrote:
allocbuf was removed in 1.88 of sys/kern/vfs_bio.c
but not from manpages
fixed, but couple of comments inline:
Index: distrib/sets/lists/comp/mi
===
RCS
On Wed, Dec 10, 2014 at 12:21:21PM +0200, Kaspars Bankovskis wrote:
Index: vfs_bio.c
===
RCS file: /cvs/src/sys/kern/vfs_bio.c,v
retrieving revision 1.163
diff -u -p -r1.163 vfs_bio.c
--- vfs_bio.c 8 Oct 2014 07:33:14 -
On Thu, Dec 11, 2014 at 02:31:32PM +, Jason McIntyre wrote:
fixed, but couple of comments inline:
OK, thanks for corrections, will keep in mind.
On Thu, Dec 11, 2014 at 6:51 AM, Stuart Henderson st...@openbsd.org wrote:
On 2014/12/11 16:42, Dmitry Eremin-Solenikov wrote:
2014-12-11 15:40 GMT+03:00 Stuart Henderson st...@openbsd.org:
On 2014/12/11 16:08, Dmitry Eremin-Solenikov wrote:
Hello,
For the historic reasons there is a
Date: Thu, 11 Dec 2014 08:15:06 -0600
From: Brent Cook bust...@gmail.com
To reduce reliance on this string, and to make it more consistently
correct between LibreSSL-portable releases, reduce OPENSSL_VERSION_TEXT
to say the bare minimum.
There are better, more portable and consistent
Absolutely yes.
On Thu, Dec 11, 2014 at 7:15 AM, Brent Cook bust...@gmail.com wrote:
To reduce reliance on this string, and to make it more consistently
correct between LibreSSL-portable releases, reduce OPENSSL_VERSION_TEXT
to say the bare minimum.
There are better, more portable and
likely whatever we change it to print. but we should catch that.
On Thu, Dec 11, 2014 at 8:34 AM, Mark Kettenis mark.kette...@xs4all.nl wrote:
Date: Thu, 11 Dec 2014 08:15:06 -0600
From: Brent Cook bust...@gmail.com
To reduce reliance on this string, and to make it more consistently
correct
i.e. if we want the openssl command to report someting specific we
put it in there, not a globally visible string that will be used for
the wrong things.
On Thu, Dec 11, 2014 at 8:37 AM, Bob Beck b...@openbsd.org wrote:
likely whatever we change it to print. but we should catch that.
On Thu,
On 11 December 2014 at 14:16, Martin Pieuchot mpieuc...@nolizard.org wrote:
On 11/12/14(Thu) 12:37, frantisek holop wrote:
login: kernel: page fault trap, code=0
Stopped at in_selectsrc+0xd8: movl 0xf0(%esi),%ebx
ddb{0} trace
From: Bob Beck b...@openbsd.org
Date: Thu, 11 Dec 2014 08:39:15 -0700
i.e. if we want the openssl command to report someting specific we
put it in there, not a globally visible string that will be used for
the wrong things.
I think you guys are trying to hard to prevent people to shoot
On Thu, Dec 11, 2014 at 6:22 AM, Martin Pieuchot mpieuc...@nolizard.org wrote:
Thanks for all your comments. I though a bit more about this change and
decided to:
- Simply return the number of bytes written/read upon success and -1
otherwise (à la read/write). This allows us to remove
On Thursday 11 December 2014 22:20:06, Jonathan Gray wrote:
On Wed, Dec 10, 2014 at 12:32:02AM +0100, Stefan Fritsch wrote:
For the codepatching part, the most interesting files are
codepatch.c and codepatch.h. In copy.S and cpu.c, I convert the
code patching already done for SMAP to the
Hi,
I'm encountering system crash during boot with latest snapshot. Turns
out that it works fine when I disable skgpio through UKC.
Try this.
Index: skgpio.c
===
RCS file: /cvs/src/sys/dev/isa/skgpio.c,v
retrieving revision
On Thu, Dec 11, 2014 at 08:21:12PM +, Miod Vallat wrote:
Hi,
I'm encountering system crash during boot with latest snapshot. Turns
out that it works fine when I disable skgpio through UKC.
Try this.
Okay tobias@, too. ;)
The system boots nicely again, thanks!
Stefan Fritsch sf at sfritsch.de writes:
--- a/sys/arch/amd64/include/specialreg.h
+++ b/sys/arch/amd64/include/specialreg.h
at at -158,6 +158,7 at at
#define CPUIDECX_AVX0x1000 /* Advanced Vector Extensions
*/
#define CPUIDECX_F16C 0x2000 /* 16bit
From: Alexey Suslikov alexey.susli...@gmail.com
Date: Thu, 11 Dec 2014 20:51:14 + (UTC)
Stefan Fritsch sf at sfritsch.de writes:
--- a/sys/arch/amd64/include/specialreg.h
+++ b/sys/arch/amd64/include/specialreg.h
at at -158,6 +158,7 at at
#defineCPUIDECX_AVX
From: Alexey Suslikov alexey.susli...@gmail.com
Date: Thu, 11 Dec 2014 20:51:14 + (UTC)
Stefan Fritsch sf at sfritsch.de writes:
--- a/sys/arch/amd64/include/specialreg.h
+++ b/sys/arch/amd64/include/specialreg.h
at at -158,6 +158,7 at at
#define CPUIDECX_AVX
I'm wondering what reception this will get. It feeds TCP/UDP port
numbers into the hash for trunk(4) load balancing, so connections
between a single pair of hosts will get distributed across NICs.
Taken from FreeBSD r232629, they also added SIOC[CS]LAGGHASH ioctls
so that the hash type can be
Now that my upd(4) is working (thanks to all involved), I’m looking to improve
behavior a bit. Let’s add some state transitions to the sensors.
Feedback is welcome.
--david
## before
[vm@vm usb]$ sysctl hw.sensors.upd0
hw.sensors.upd0.indicator0=Off (Charging), OK
First, I think the BatteryPresent check has a signedness problem. Second, I
think that it should check for sensor validity too, so it doesn’t use stale
values if BatteryPresent somehow goes straight from present to invalid.
This diff should fix both things, in theory. Compiled and running
Has anyone given any thought to the impact of 1300+ software
packages using the practice of
srand(time(NULL));
in an increasingly NTP-syncronized world?
From the code I've been reading, I am certain some folk have looked
into it.
In all of these code blocks are a well-known piece of information
(same time on your machine as everywhere else) is being used to seed a
deterministic number generator.
At some later point, deterministic numbers are taken out using rand(),
random(), drand48(), lrand48(), mrand48(), or srand48(),
On 12 Dec 2014, at 5:02, Theo de Raadt wrote:
In all of these code blocks are a well-known piece of information
(same time on your machine as everywhere else) is being used to seed a
deterministic number generator.
At some later point, deterministic numbers are taken out using rand(),
On 12 Dec 2014, at 5:02, Theo de Raadt wrote:
In all of these code blocks are a well-known piece of information
(same time on your machine as everywhere else) is being used to seed a
deterministic number generator.
At some later point, deterministic numbers are taken out using rand(),
On 12 Dec 2014, at 5:43, Theo de Raadt wrote:
On 12 Dec 2014, at 5:02, Theo de Raadt wrote:
In all of these code blocks are a well-known piece of information
(same time on your machine as everywhere else) is being used to seed a
deterministic number generator.
At some later point,
On 11 December 2014 at 21:43, Theo de Raadt dera...@cvs.openbsd.org wrote:
On 12 Dec 2014, at 5:02, Theo de Raadt wrote:
In all of these code blocks are a well-known piece of information
(same time on your machine as everywhere else) is being used to seed a
deterministic number
There are libraries available which provide arc4random() on Linux, so
maybe you find an upstream software provider who is willing to create
a dependency on such a library on Linux.
Lots of software is doing precisely that, so don't be afraid.
Thank you. Are there any specific good
On Thu, Dec 11, 2014 at 09:52:46PM -0800, Eugene Yunak wrote:
Thank you. Are there any specific good libraries you know of?
--
The best the little guy can do is what
the little guy does right
LibreSSL :-)
-Bryan.
On Thu, Dec 11, 2014 at 09:52:46PM -0800, Eugene Yunak wrote:
Thank you. Are there any specific good libraries you know of?
LibreSSL :-)
Indeed, if a system has LibreSSL, you will find the arc4random
family in -lcrypto.
51 matches
Mail list logo
