On Tue, 02 Feb 2021 17:51:35 +0100
Bastien Durel wrote:
> PS: is 1kΩ enough ? I don't know if it's actually "high value"
Well, "high value" is a relative term. In this case we're dealing with
CMOS inputs which are quite high in impedance.
1kΩ might be "high" if we were talking TTL. I'd be
On Fri, Jul 23, 2021 at 07:29:21PM +, Alex Beakes wrote:
> (this is my first time mailing a mailing list, getting into BSD, long time
> linux user; sorry if I got anything wrong.)
>
> Using a lenovo T14s gen2 intel, intel wifi chip isn't working, looks like the
> device isn't being
(this is my first time mailing a mailing list, getting into BSD, long time
linux user; sorry if I got anything wrong.)
Using a lenovo T14s gen2 intel, intel wifi chip isn't working, looks like the
device isn't being recognized.
Maybe there is already a driver, but the device isn't in the
I am attempting to prioritize traffic from a particular host. I have the
following queue definitions, with this match rule:
queue rootq on $ext_if bandwidth 13M max 13M
queue file1_bak parent rootq bandwidth 10M min 8M qlimit 1024
queue std parent rootq bandwidth 3M min 2M default qlimit 1024
Otto Moerbeek wrote:
> yeah, MALLOC_STATS is not well maintained...
What's the relation between the MALLOC_STATS code currently in -stable,
and the code in your mdump [0] project? Are you experimenting with
different approaches?
BTW, thanks for your work on this.
0:
Omar Polo wrote:
> not tried, but compiles :)
Your patch made it compile for me too. With that change I was able to
run through the steps in https://www.drijf.net/malloc/ and detect memory
leaks! Thank you.
What's the process to get your change applied to -current? Should it be
submitted to the
Omar Polo wrote:
> There's a built-in mechanisms to check for memory leaks:
>
> https://www.drijf.net/malloc/
>
> don't know if it still applies, I tried only once and was like a couple
> of years ago (if not more).
Thanks for the tip, Omar. I just tried compiling malloc.c with
On 2021/07/23 11:13, Christopher Sean Hilton wrote:
> On Fri, Jul 23, 2021 at 10:04:25AM -, Stuart Henderson wrote:
> > On 2021-07-22, Sebastian Benoit wrote:
>
> [ ...snip ]
>
> > >
> > > The IO paths of those Atoms are slow. Disk IO is also lacking.
> >
> > The D525, yes.
> >
> > The
On Fri, Jul 23, 2021 at 11:54:38AM -0500, Joe Nelson wrote:
> Otto Moerbeek wrote:
> > yeah, MALLOC_STATS is not well maintained...
>
> What's the relation between the MALLOC_STATS code currently in -stable,
> and the code in your mdump [0] project? Are you experimenting with
> different
I'll take care.
Joe Nelson schreef op 23 juli 2021 18:36:04 CEST:
>Omar Polo wrote:
>> not tried, but compiles :)
>
>Your patch made it compile for me too. With that change I was able to
>run through the steps in https://www.drijf.net/malloc/ and detect
>memory
>leaks! Thank you.
>
>What's the
On Fri, Jul 23, 2021 at 11:19:35AM -0400, Chris Hilton wrote:
> On Thu, Jul 22, 2021 at 08:24:25PM +0200, Sebastian Benoit wrote:
> [ ...snip]
>
> >
> > If you can get the later generation Xeon-D machines with similar form
> > factor. Much better hardware.
> >
>
> So, I'm running the Atom
I have a running openbsd installation on hetzner without problems.
IIRC had bought a server with one of the default Linux distributions, webt to
server settings and there somehow mounted the openbsd iso and follow the
regular openbsd install on the virtual console.
It's the regular installation
On Fri, Jul 23, 2021 at 06:02:08PM +0200, Omar Polo wrote:
>
> Joe Nelson writes:
>
> > Omar Polo wrote:
> >> There's a built-in mechanisms to check for memory leaks:
> >>
> >>https://www.drijf.net/malloc/
> >>
> >> don't know if it still applies, I tried only once and was like a couple
Joe Nelson writes:
> Omar Polo wrote:
>> There's a built-in mechanisms to check for memory leaks:
>>
>> https://www.drijf.net/malloc/
>>
>> don't know if it still applies, I tried only once and was like a couple
>> of years ago (if not more).
>
> Thanks for the tip, Omar. I just tried
On Thu, Jul 22, 2021 at 08:24:25PM +0200, Sebastian Benoit wrote:
[ ...snip]
>
> If you can get the later generation Xeon-D machines with similar form
> factor. Much better hardware.
>
So, I'm running the Atom machines because of power concerns. I'm not
familiar with the Xeon-D line of
On Fri, Jul 23, 2021 at 10:04:25AM -, Stuart Henderson wrote:
> On 2021-07-22, Sebastian Benoit wrote:
[ ...snip ]
> >
> > The IO paths of those Atoms are slow. Disk IO is also lacking.
>
> The D525, yes.
>
> The C2758 should cope with much more than 650-700Mb/s though maybe
> not with
On 2021-07-22, Cand Tec wrote:
> I've a few openbsd 6.8 installations running as a FW/router/vpn at some
> client offices. No problems, It just works!
> I would like to use openbsd 6.9 on x86 HW (either lanner device or dell
> rack mount svr) at this new client (mining industry). They're however
On Fri, 2021-07-23 at 08:21 +0200, Harald Dunkel wrote:
> Deutsche Telekom gives me a new /56 prefix for my internal net and
> a new /64 prefix for the external connection on every reboot of my
> modem. The old internal prefix is not routed anymore. Question is,
> how can I tell pf to use the new
On 2021-07-22, Sebastian Benoit wrote:
> Christopher Sean Hilton(ch...@vindaloo.com) on 2021.07.21 14:20:58 -0400:
>> I have a packet filtering bridge running on PF and OpenBSD 6.8. My
>> hardware is a SuperMicro Atom D525 service with dual Intel Gigabit
>> Nics. I've added a second dual Intel
On 22.7.2021. 16:33, Matthias Schmidt wrote:
> Hi,
>
> * Hrvoje Popovski wrote:
>> Hi all,
>>
>> I'm thinking of getting Hetzner cloud server and install OpenBSD stable
>> on it...
>>
>> Does anyone have experience with it? Is it complicated to install
>> OpenBSD on it? And of course, is it
On 2021-07-21, David Higgs wrote:
> I was looking into how to configure unwind for my needs, and found
> significant discrepancies between /etc/examples/unwind.conf and the
> unwind.conf(5) manual. Namely, the example file had lots of captive portal
> info, while the manual made no mention of
Hi folks,
Deutsche Telekom gives me a new /56 prefix for my internal net and
a new /64 prefix for the external connection on every reboot of my
modem. The old internal prefix is not routed anymore. Question is,
how can I tell pf to use the new prefix?
There are a few constants in my pf.conf
22 matches
Mail list logo
