On Mon, May 27 2019, Mike Larkin wrote:
On Mon, May 27, 2019 at 03:53:11AM -0700, Renato Aguiar wrote:
Hi,
The following patch makes Linux guests use kvm-clock by setting
KVM's CPUID
signature on VMM:
By saying the hypervisor is KVM to all guests, does this cause
the guests
to make ot
On Mon, May 27 2019, Pratik Vyas wrote:
* Renato Aguiar [2019-05-27 03:53:11 -0700]:
Hi,
The following patch makes Linux guests use kvm-clock by setting
KVM's CPUID signature on VMM:
I think the right thing is to make linux attach pvclock if it's
on
OpenBSD vmm. You want to send them
Brian Callahan:
> lang/ponyc uses $(shell getconf LONG_BIT) in its Makefile to
> determine whether or not we're on a 64-bit platform.
> However, our getconf(1) doesn't support reporting LONG_BIT.
> This diff enables it. GNU/FreeBSD/DragonFly/MacOS getconf reports
> LONG_BIT, but NetBSD getconf doe
Hi,
On Mon, May 13, 2019 at 09:03:41PM +0200, Claudio Jeker wrote:
> When using a rule forcing the nexthop to a specific address bgpd
> currently does not mark that nexthop as no-modify. In other words
> the default rules for nexthop propagation applies. This means that
> for ebgp it only sends ou
On 5/28/19 7:24 AM, Christian Weisgerber wrote:
Brian Callahan:
lang/ponyc uses $(shell getconf LONG_BIT) in its Makefile to
determine whether or not we're on a 64-bit platform.
However, our getconf(1) doesn't support reporting LONG_BIT.
This diff enables it. GNU/FreeBSD/DragonFly/MacOS getc
On Mon, May 27 2019, Philip Guenther wrote:
> On Mon, May 27, 2019 at 3:43 PM Brian Callahan wrote:
>
>> Below is a small diff in response to some configuration attempts
>> found in ports land.
>> lang/ponyc uses $(shell getconf LONG_BIT) in its Makefile to
>> determine whether or not we're on a
On Tue, May 21, 2019 at 05:59:18PM +0200, Claudio Jeker wrote:
> Hi,
>
> The last refactor of the pfkey handling uncovered an issue deep down in
> the pfkey handling. Some long time ago henning@ added a sleep(1) into
> pfkey_md5sig_establish(). This is now hunting us back because bgpd ends up
> wi
On Tue, May 14, 2019 at 12:37:25AM +0200, Claudio Jeker wrote:
> This diff changes the way communites are stored and modified in bgpd.
> The current implementation was showing that community_*_delete() consumed
> a lot of CPU time because of the way rde_attr was used.
> Communities are extensivly u
On Tue, May 28, 2019 at 01:28:32PM +0200, Job Snijders wrote:
> Hi,
>
> On Mon, May 13, 2019 at 09:03:41PM +0200, Claudio Jeker wrote:
> > When using a rule forcing the nexthop to a specific address bgpd
> > currently does not mark that nexthop as no-modify. In other words
> > the default rules fo
On 5/28/19 8:21 AM, Jeremie Courreges-Anglas wrote:
On Mon, May 27 2019, Philip Guenther wrote:
On Mon, May 27, 2019 at 3:43 PM Brian Callahan wrote:
Below is a small diff in response to some configuration attempts
found in ports land.
lang/ponyc uses $(shell getconf LONG_BIT) in its Makef
On Tue, May 28, 2019 at 05:17:08PM +0200, Claudio Jeker wrote:
> On Tue, May 28, 2019 at 01:28:32PM +0200, Job Snijders wrote:
> > On Mon, May 13, 2019 at 09:03:41PM +0200, Claudio Jeker wrote:
> > > When using a rule forcing the nexthop to a specific address bgpd
> > > currently does not mark that
Hi,
I noticed the following with the reproducable command:
openrsync -av rsync://127.0.0.1/ftp/ a
ktrace:
-> 99882 openrsync CALL close(1249939456)
-> 99882 openrsync RET close -1 errno 9 Bad file descriptor
99882 openrsync CALL kbind(0x7f7f7a50,24,0x281ae61c4bf1563c)
99882 openrs
Hello tech, I'm submitting the following patch for inclusion. The patch
implements a driver for the Keyspan USA-19HS USB-to-serial dongle.
I've used it for a few months now without any problems. Please let me know if
you spot any problems.
Thanks!
diff --git sys/arch/amd64/conf/GENERIC sys/arch/
Hi,
Some feedback inline:
On Tue, 28 May 2019 at 18:42:51 -0400, Cody Cutler wrote:
> Hello tech, I'm submitting the following patch for inclusion. The patch
> implements a driver for the Keyspan USA-19HS USB-to-serial dongle.
>
> I've used it for a few months now without any problems. Please le
On 2019/05/13 07:47, Denis Fondras wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: de...@cvs.openbsd.org 2019/05/13 07:47:36
>
> Modified files:
> usr.sbin/bgpd : rde_update.c
>
> Log message:
> fix export default-route.
>
> OK claudio@
>
I've just been updating some
I have my i8042 device for vmd(8) mostly implemented. It’s only missing a few
commands, but since there are no PS/2 input devices yet, there isn’t very much
in the way of testing I can do beyond ensuring that commands act as they
should.
I have a couple questions about expected behavior, mostl
I noticed that OpenBSD's fscanf doesn't yet support hex float strings,
which are standardized in C99. I am using them in my application (which
I would like to support OpenBSD), since the "%a" format specifier is a
convenient way to preserve the exact floating point value.
strtod already supports p
Hi David,
are you going to commit this?
Remi
On Thu, May 16, 2019 at 11:14:55PM +0200, Remi Locherer wrote:
> On Thu, May 16, 2019 at 09:39:37AM +0200, Sebastian Benoit wrote:
> >
> >
> >
> > Remi Locherer(remi.loche...@relo.ch) on 2019.05.15 23:15:03 +0200:
> > > On Tue, Apr 30, 2019 at 11:
The check if a network is already present is slightly wrong since it does
not check the type. I triggered it with:
network inet static
network 0.0.0.0/0
Fix is trivial.
--
:wq Claudio
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/
19 matches
Mail list logo