On Wed, 22 May 2019 at 23:06, Stuart Henderson wrote:
[...]
> vmxnet3 suffers kernel panics under some conditions, e1000 is rock solid
> for me.
Any known similarities in regards of vio -- VirtIO network device
(bhyve, KVM, QEMU, and VirtualBox)?
--
End of message. Next message?
On Tue, 30 Apr 2019 at 15:24, mabi wrote:
[...]
> Is this safe? or could there be any incompatibilities in carp/pfsync which
> would prevent me to do that upgrade in two steps while keeping everything
> online?
CARP should be of no worries at all and PF state table's sync is
easily verified.
On Sun, 28 Apr 2019 at 02:43, Thomas Frohwein wrote:
>
> On Sun, Apr 28, 2019 at 02:07:44AM +0700, Igor Podlesny wrote:
> [...]
> > Looks like decision made aren't subjects of discussing(?) Well, why
> > the hell you have those mail lists then(?) :)
>
> Igor:
&
On Sun, 28 Apr 2019 at 00:59, wrote:
[...]
> >
> > Oh, those hypocrite wankers here and there..
>
> If you actually read the code (I know, right? Who DOES that?) you'll see how
> omalloc_init perfectly embarrasses you. In 6.4 it would read the symlink,
> then checked the environment, and then
On Sat, 27 Apr 2019 at 17:55, Stuart Henderson wrote:
[...]
> It is not true. They don't have *wide* support but there is some
> supported hw. If someone wants to change this, I suggest adding acpi
> watchdog support would give the best return for time spent.
Got it.
> Also I don't see what
On Sat, 27 Apr 2019 at 20:38, Vincent Legoll wrote:
>
> On Sat, Apr 27, 2019 at 3:32 PM Igor Podlesny wrote:
> > On Sat, 27 Apr 2019 at 18:09, Marc Espie wrote:
> > > Man, you have some really strange delusions about how to harden things.
> >
> > % man malloc.c
On Sat, 27 Apr 2019 at 18:09, Marc Espie wrote:
>
> On Sat, Apr 27, 2019 at 12:34:01PM +0700, Igor Podlesny wrote:
> > On Sat, 27 Apr 2019 at 12:26, Sebastien Marie wrote:
> > > On Sat, Apr 27, 2019 at 12:17:21PM +0700, Igor Podlesny wrote:
> > > > Previously use
On Sat, 27 Apr 2019 at 12:55, Theo de Raadt wrote:
> Igor Podlesny wrote:
> > On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley wrote:
> > > You didn't check the manpage.
> >
> > you didn't think it over.
> > https://www.mail-archive.com/misc@openbsd.org/m
> > Wrong. Environment is easy to be changed by any non-privileged process.
> > OTOH, root owned /etc/malloc.conf is not.
>
> Back then, when both /etc/malloc.conf and MALLOC_OPTIONS were set, which
> did a program prefer?
I'm more concerned with cleared up environment other than changed
On Sat, 27 Apr 2019 at 12:46, Theo de Raadt wrote:
> Igor Podlesny wrote:
> > On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley wrote:
> > > You didn't check the manpage.
> > you didn't think it over.
> > https://www.mail-archive.com/misc@openbsd.org/msg167012
On Sat, 27 Apr 2019 at 12:37, Anthony J. Bentley wrote:
>
> You didn't check the manpage.
you didn't think it over.
https://www.mail-archive.com/misc@openbsd.org/msg167012.html
--
End of message. Next message?
On Sat, 27 Apr 2019 at 12:26, Sebastien Marie wrote:
> On Sat, Apr 27, 2019 at 12:17:21PM +0700, Igor Podlesny wrote:
> > Previously users could have different behaviour of malloc simultaneously:
> > one in
> > global FS, others in chroots. Say, in global it could be more r
On Sat, 27 Apr 2019 at 12:12, Theo de Raadt wrote:
> Igor Podlesny wrote:
[...]
> > 1) Is it true that more or less fresh OpenBSD generic kernels come with
> > no support of any watchdog hw?
> No.
I see.
> > 2) I heard that kernel modules were intentionally rid of in O
Previously users could have different behaviour of malloc simultaneously: one in
global FS, others in chroots. Say, in global it could be more relaxed
with lesser
performance impact and in some chroots more drastic, at contrary. With
6.5 it's not
possible anymore, is it really so? This change has
On Fri, 26 Apr 2019 at 22:58, Stuart Henderson wrote:
> On 2019-04-26, Igor Podlesny wrote:
> > Or would kernel's recompiling be needed anyways?
[...]
> Recompiling would be needed.
>
> If you want to try it, see faq 5 about fetching the source tree,
> add "ichwdt* a
Or would kernel's recompiling be needed anyways?
Moreover, I'm actually interested in intersection of watchdogs
provided by KVM and
supported by OpenBSD (as KVM's guest). At least as to KVM's it's gonna
be a short list:
1) i6300esb (PCI)
2) ib700 (ISA)
Attempt with 1st item shows its driver
On Thu, 17 Jan 2019 at 23:24, Bruno Dantas wrote:
[...]
> pass out proto {tcp udp} to any port 22022 route-to athn0
>
> and this:
>
> pass out proto {tcp udp} to any port 22022 route-to \
> $athn0_gateway
>
> But both result in ssh authentication attempts to hang at
> "debug1: Connecting
On Thu, 10 Jan 2019 at 21:11, Remi Locherer wrote:
[...]
> I can reproduce it. Interestingly it only sends out the wrong type when
> the "depend on" interfac (carp1 in your example) is down or in backup
> state and the configured type is 2.
That's an irony for real! -- Type 1 is "heavier" than
On Thu, 10 Jan 2019 at 01:21, Remi Locherer wrote:
[...]
>
> It is not intended. I'll look into it.
I see, thank you. BTW, if-when it's fixed would such a fix be brought
within standard syspatch update process or
what would it be otherwise?
Can you also explain why Type 1 has been chosen as
Hi!
My tests show that OpenOSPFD "depend on" feature forces "type 1"
overriding explicitly specified "type 2". For example this statement
can be used:
redistribute 0.0.0.0/0 set { type 2 } depend on carp1
(or keyword "default" can be used instead of prefix.)
Is it an intended behaviour or it's
20 matches
Mail list logo
