I’ve got a PineBook Pro, but haven’t managed to install OpenBSD on it. The
networking on the linux that came installed on it cannot connect to openbsd.org
or github.com (connection times our) so I haven’t managed to make an installer
SD I can run on it. I *can* connect to those domains from my i
On Thu, Apr 23 2020, Stefan Sperling wrote:
> I have observed a uvm fault in ieee80211_mira_probe_timeout_up() while
> testing with iwm(4) and tcpbench:
>
> void
> ieee80211_mira_probe_timeout_up(void *arg)
> {
> struct ieee80211_mira_node *mn = arg;
> int s;
>
> s = splnet();
>
On Thu, Apr 23, 2020 at 07:31:37PM +0100, Ricardo Mestre wrote:
> Hi,
>
> This one looks like a typo and might cause a double free.
>
> CID 1492713
>
> OK?
ok jmatthew@
>
> Index: if_mcx.c
> ===
> RCS file: /cvs/src/sys/dev/pci/i
I was reading the thread about STAILQ and SIMPLEQ and thought it was
interesting, so I then read a little about sys/queue.h and search.h
I noticed an error in insque.3:
https://man.openbsd.org/insque.3
The words "next" and "previous" are swapped, as it is the first
pointer that points to the next e
I put this in at some point since I couldn't get the eMMC on my
firefly-rk3399 working otherwise. But its eMMC died and on my
rockpro64 and rk3399-q7 boards things work very well without it. On
the latter board it even makes things a bit speedier: the raw read
performance goes up from 35 MB/s to
On Thu, Apr 23, 2020 at 10:34:39AM -0600, Theo de Raadt wrote:
> It says the keyword gets parsed, but then does performs no action.
>
> But that is different from not parsing it.
>
> Additionally, this explains an option which other systems support, and
> by explaining it this way, it is also exp
Hi,
This one looks like a typo and might cause a double free.
CID 1492713
OK?
Index: if_mcx.c
===
RCS file: /cvs/src/sys/dev/pci/if_mcx.c,v
retrieving revision 1.43
diff -u -p -u -r1.43 if_mcx.c
--- if_mcx.c21 Apr 2020 05:49:25
On Thu, Apr 23, 2020 at 06:08:02PM +0100, Stuart Henderson wrote:
> We could use it in the sample config too. OK?
OK. Lets burn down the bad v4 vs v6 groups :)
> Index: bgpd.conf
> ===
> RCS file: /cvs/src/etc/examples/bgpd.conf,v
>
We could use it in the sample config too. OK?
Index: bgpd.conf
===
RCS file: /cvs/src/etc/examples/bgpd.conf,v
retrieving revision 1.18
diff -u -p -r1.18 bgpd.conf
--- bgpd.conf 16 Feb 2020 20:02:21 - 1.18
+++ bgpd.conf 2
On Thu, Apr 23, 2020 at 06:31:12PM +0200, Jeremie Courreges-Anglas wrote:
> On Thu, Apr 23 2020, Jason McIntyre wrote:
> > On Thu, Apr 23, 2020 at 05:17:08PM +0200, Solene Rapenne wrote:
> >> Is there a reason to keep this part in resolv.conf(5) about an option
> >> doing nothing?
> >>
> >> > opt
On 23/04/2020 16:18, Todd C. Miller wrote:
On Thu, 23 Apr 2020 14:40:15 +0200, Denis Fondras wrote:
I don't know if it is useful to anyone else but it is required by lsquic, a
library that implements QUIC / HTTP3.
sniproxy port also uses STAILQ_*, there is a patch in the port for the
imp
On 2020/04/23 10:31, Theo de Raadt wrote:
> Todd C. Miller wrote:
>
> > On Thu, 23 Apr 2020 08:41:05 -0600, "Theo de Raadt" wrote:
> >
> > > My questions boil down to:
> > >
> > > 1) When are too many APIs too may? (It seems there is some agreement
> > > already)
> > >
> > > 2) Is STAILQ more u
On Thu, Apr 23, 2020 at 10:31:53AM -0600, Theo de Raadt wrote:
> I would be happy wit such unification.
>
> Are there any objectors?
>
> (finishing this might need to be put off for about a month, tho)
>
I am currently building base with a diff that converts SIMPLEQ_* to STAILQ_*
It says the keyword gets parsed, but then does performs no action.
But that is different from not parsing it.
Additionally, this explains an option which other systems support, and
by explaining it this way, it is also explaining our behaviour in case
of inet6 vs inet4 conditions.
So... I think
On Thu, Apr 23 2020, Jason McIntyre wrote:
> On Thu, Apr 23, 2020 at 05:17:08PM +0200, Solene Rapenne wrote:
>> Is there a reason to keep this part in resolv.conf(5) about an option
>> doing nothing?
>>
>> > options inet6
>> > Enables support for IPv6-only applications, by setting RES_USE_INET6
>
Todd C. Miller wrote:
> On Thu, 23 Apr 2020 08:41:05 -0600, "Theo de Raadt" wrote:
>
> > My questions boil down to:
> >
> > 1) When are too many APIs too may? (It seems there is some agreement
> > already)
> >
> > 2) Is STAILQ more ubiqitous? (I suspect so)
>
> STAILQ is supported by: FreeBSD,
On Thu, 23 Apr 2020 08:41:05 -0600, "Theo de Raadt" wrote:
> My questions boil down to:
>
> 1) When are too many APIs too may? (It seems there is some agreement already)
>
> 2) Is STAILQ more ubiqitous? (I suspect so)
STAILQ is supported by: FreeBSD, macOS, NetBSD, Solaris, Linux (via libbsd)
SIM
On Thu, Apr 23, 2020 at 05:17:08PM +0200, Solene Rapenne wrote:
> Is there a reason to keep this part in resolv.conf(5) about an option
> doing nothing?
>
> > options inet6
> > Enables support for IPv6-only applications, by setting RES_USE_INET6
> > in _res.options (see res_init(3)). On OpenBSD th
Is there a reason to keep this part in resolv.conf(5) about an option
doing nothing?
> options inet6
> Enables support for IPv6-only applications, by setting RES_USE_INET6
> in _res.options (see res_init(3)). On OpenBSD this option does
> nothing.
If we can remove it, here is the diff.
Index: re
Todd C. Miller wrote:
> On Thu, 23 Apr 2020 08:35:38 -0600, "Theo de Raadt" wrote:
>
> > SIMPLEQ arrived in 1997. Didn't it go to other systems? Did others
> > invent STAIL on their own?
>
> FreeBSD added STAILQ (along with SLIST) in 1996.
My questions boil down to:
1) When are too many API
On Thu, 23 Apr 2020 08:35:38 -0600, "Theo de Raadt" wrote:
> SIMPLEQ arrived in 1997. Didn't it go to other systems? Did others
> invent STAIL on their own?
FreeBSD added STAILQ (along with SLIST) in 1996.
- todd
Denis Fondras wrote:
> On Thu, Apr 23, 2020 at 08:18:16AM -0600, Todd C. Miller wrote:
> > Singly-linked tail queues are functionally equivalent to the "simple
> > queues" we already have. Do we really need two implementations of
> > what are effectively the same thing or should we just define S
On Thu, Apr 23, 2020 at 08:18:16AM -0600, Todd C. Miller wrote:
> Singly-linked tail queues are functionally equivalent to the "simple
> queues" we already have. Do we really need two implementations of
> what are effectively the same thing or should we just define STAIL_*
> in terms of SIMPLEQ_*
On Thu, 23 Apr 2020 14:40:15 +0200, Denis Fondras wrote:
> I don't know if it is useful to anyone else but it is required by lsquic, a
> library that implements QUIC / HTTP3.
Singly-linked tail queues are functionally equivalent to the "simple
queues" we already have. Do we really need two imple
Stefan Sperling - Fri, 17 April 2020 at 16:03:30
> This applies on top of a previous diff I sent, the one to make use of
> the entire firmware retry table.
I have contacted Stefan privately about a seemingly different issue (and
i wasn't sure it was a bug to begin with) and after he recommended
tr
reads ok
Claudio Jeker(cje...@diehard.n-r-g.com) on 2020.04.23 10:04:15 +0200:
> local-address is one of those values that need to be set in some cases but
> is not very flexible to use. This diff tries to change this a bit.
>
> It allows to set the local-address for both IPv4 and IPv6 at the sam
I don't know if it is useful to anyone else but it is required by lsquic, a
library that implements QUIC / HTTP3.
Index: share/man/man3/queue.3
===
RCS file: /cvs/src/share/man/man3/queue.3,v
retrieving revision 1.66
diff -u -p -r1.66
The diff below adds "pinctrl" support for the various Raspberry Pi
models. This allows OpenBSD to control the function of pins on the
SoC (and as a result the function of some of the pins on the extension
header). This is important when the firmware doesn't configure this
pins already for us. Th
observed no issue, still running w/ your diff
April 23, 2020 1:10 PM, "Eric Faurot" wrote:
> On Tue, Apr 21, 2020 at 07:08:48AM +, gil...@poolp.org wrote:
>
>> April 21, 2020 4:28 AM, "Todd C. Miller" wrote:
>>
>> On Mon, 20 Apr 2020 15:01:31 +0200, Eric Faurot wrote:
>>
>> There has bee
Hey,
i let this patch run on one of our mailservers and it worked as
expected. I did not notice any issues with it. But that server has a low
volume of mails (around 8000 a day), so it is probobly not that helpful
for you.
Greetings
Leo
Am 21.04.2020 um 04:28 schrieb Todd C. Miller:
This lo
On Tue, Apr 21, 2020 at 07:08:48AM +, gil...@poolp.org wrote:
> April 21, 2020 4:28 AM, "Todd C. Miller" wrote:
>
> > On Mon, 20 Apr 2020 15:01:31 +0200, Eric Faurot wrote:
> >
> >> There has been a discussion a while ago about the issue of trailing CR
> >> in smtp lines (https://marc.info/?
I have observed a uvm fault in ieee80211_mira_probe_timeout_up() while
testing with iwm(4) and tcpbench:
void
ieee80211_mira_probe_timeout_up(void *arg)
{
struct ieee80211_mira_node *mn = arg;
int s;
s = splnet();
mn->probe_timer_expired[IEEE80211_MIRA_PROBE_TO_UP]
local-address is one of those values that need to be set in some cases but
is not very flexible to use. This diff tries to change this a bit.
It allows to set the local-address for both IPv4 and IPv6 at the same time
and also allows to unset a previously set local-address. For example:
group IBGP
33 matches
Mail list logo