On Mon, Jun 17, 2013 at 3:22 PM, Ryan Slack wrote:
> Hosting a voip server behind OpenBSD with the following pf.conf file
> led to some surprising behaviour:
>
> voice_if = em0
> data_if= vr0
> ext_if = vr3
> PBX = "192.168.234.200"
> voip_ports = "1:4"
> table persist { }
> match ou
> > > - p->p_sigmask = mask &~ sigcantmask;
> > > + p->p_sigmask = mask;
>
> On the right architecture where a word store isn't atomic enough and
> with the right compiler that decides to put p_sigmask on an address
> ending with 0xFFF with 4k-sized pages, we have two problems alre
On 19 June 2013 20:20, Reyk Floeter wrote:
> On Wed, Jun 19, 2013 at 08:00:01PM +0200, Reyk Floeter wrote:
>> OK?
>>
>
> I forgot the in6_pcblookup_listen() case, updated diff below.
>
> Reyk
>
it boils down to the pcb lookup magic as i thought; ok mikeb.
On Wed, Jun 19, 2013 at 08:00:01PM +0200, Reyk Floeter wrote:
> OK?
>
I forgot the in6_pcblookup_listen() case, updated diff below.
Reyk
Index: sys/netinet/in_pcb.c
===
RCS file: /cvs/src/sys/netinet/in_pcb.c,v
retrieving revision
Hi,
divert-to currently only works with sockets listening on a specific
address, but not any (0.0.0.0 / ::).
For example, if you do "pass in ... divert-to 127.0.0.1 port 1234",
the userland proxy currently has bind its socket to 127.0.0.1, and not
0.0.0.0. The attached diff attempts to fix it an
Hi,
since we introduced divert-to, we converted most userland proxies and
relays to use this new interface instead of rdr-to. spamd is still
missing and should switch to divert-to as well.
divert-to has many advantages over rdr-to for proxies. For example,
it is much easier to use (most of the a
On Wed, Jun 19, 2013 at 14:19, Marc Espie wrote:
> On Wed, Jun 19, 2013 at 01:40:19PM +0200, Martin Pelikan wrote:
>> > If you're right that atomic_{clear,set}bits_int is correct and
>> > sufficient and actually faster, then all dynamic executables would
>> > benefit from this speedup (sigprocmask
On Wed, Jun 19, 2013 at 01:40:19PM +0200, Martin Pelikan wrote:
> > If you're right that atomic_{clear,set}bits_int is correct and
> > sufficient and actually faster, then all dynamic executables would
> > benefit from this speedup (sigprocmask is used in ld.so(1)).
>
> Since on i386 GENERIC these
> If you're right that atomic_{clear,set}bits_int is correct and
> sufficient and actually faster, then all dynamic executables would
> benefit from this speedup (sigprocmask is used in ld.so(1)).
Since on i386 GENERIC these atomic_* things don't emit the LOCK prefix,
performance shouldn't be an i
Martin Pelikan writes:
> Hi!
>
> Recently, I had to unleash my crappy Atom and decided to run OpenBSD on it.
> Then I became irritated with the performance of most X11 applications, and
> started poking around:
> - libfreetype.so is quite common
> - it does setjmp (disguised as ft_setjmp) quite
Martin Pelikan gmail.com> writes:
> and ran it on my pointless Atom N270 (two threads, one core from 1980s)
Not such a pointless for me since I have one too. Btw, a while ago
vendors built a *lot* of netbooks on N270.
Hi!
Recently, I had to unleash my crappy Atom and decided to run OpenBSD on it.
Then I became irritated with the performance of most X11 applications, and
started poking around:
- libfreetype.so is quite common
- it does setjmp (disguised as ft_setjmp) quite a lot
- setjmp needs to do sigprocma
Hi!
On a machine the system temperature sensor shows e.g. 33 which is ok.
But on sysctl hw.sensors the status is CRITICAL.
I've read the IPMI specs and i think this is because ipmi_test_threshold ignores
the fact, that some sensors have a signed value and threshold.
In my case the lower thresholds
13 matches
Mail list logo
