On Thu, Apr 09, 2020 at 10:58:29PM -0400, George Koehler wrote:
> In the trace, #0 and #1 are wrong, but the rest of the trace looks
> good enough for WITNESS. I added an artificial lock order reversal to
> ums(4) for WITNESS to catch. I got this trace,
>
> #0 0xe4d764
> #1 witness_c
On Thu, 9 Apr 2020 20:05:34 +0200
Martin Pieuchot wrote:
> +void
> +stacktrace_save_at(struct stacktrace *st, unsigned int skip)
> +{
> + vaddr_t lr, sp, lastsp;
> +
> + sp = (vaddr_t)__builtin_frame_address(0);
> + if (!INKERNEL(sp) && !ININTSTK(sp))
> + return;
On Wed, 01 Apr 2020 13:47:58 +0200
phi...@warpmail.net (Philip K.) wrote:
> George Koehler writes:
>
> > C-x C-j doesn't work for me: it does show the dired buffer, but
> > doesn't jump to the file that I was editing.
>
> Looks like that was because I called gotofile before showbuffer. I
> chan
On 2020/04/09 20:13, Theo Buehler wrote:
> On Thu, Apr 09, 2020 at 05:56:55PM +0100, Stuart Henderson wrote:
> > Not new - this happened somewhere between 6.5 and 6.6 - but some
> > certificates are now showing up with bad serial numbers in "openssl x509".
> > Example below, a few other certs are a
On Thu, Apr 09, 2020 at 05:56:55PM +0100, Stuart Henderson wrote:
> Not new - this happened somewhere between 6.5 and 6.6 - but some
> certificates are now showing up with bad serial numbers in "openssl x509".
> Example below, a few other certs are affected.
>
> From the current /etc/ssl/cert.pem,
On 09/04/20(Thu) 15:57, Peter J. Philipp wrote:
> On Thu, Apr 09, 2020 at 01:08:12PM +0200, Martin Pieuchot wrote:
> > On 09/04/20(Thu) 12:20, Peter J. Philipp wrote:
> > > It's April 9th for me, so no chance for April 1st things. Both patches
> > > didn't
> > > boot (they loaded on ofwboot thoug
Syncing from Mozilla's CA list.
Added:
/C=EE/O=AS Sertifitseerimiskeskus/CN=EE Certification Centre Root
CA/emailAddress=p...@sk.ee
/C=IN/OU=emSign PKI/O=eMudhra Technologies Limited/CN=emSign ECC Root CA - G3
/C=IN/OU=emSign PKI/O=eMudhra Technologies Limited/CN=emSign Root CA - G1
/C=US/O=Entru
Not new - this happened somewhere between 6.5 and 6.6 - but some
certificates are now showing up with bad serial numbers in "openssl x509".
Example below, a few other certs are affected.
>From the current /etc/ssl/cert.pem, these are the ones showing the same:
-Serial Number: 118068224848
Our make (bsd make) has "alternate" dependency operators :: and !
Twenty years ago, we made it so that ambiguous constructs like
File::Find.3p: File/Find.pm
would no longer be ambiguous thanks to the added space.
Now, I believe that ! should be trumped by : if both are present in the
same line
> Thanks for pointing this out. As discussed with deraadt@ it's probably
> not a good idea to mimic too closely the algorithm in the kernel.
If the accounting in find is byte-for-byte accurate, it will be fragile.
It may be better if find consistantly undershoots when estimating.
On Thu, Apr 09 2020, Marc Espie wrote:
> On Thu, Apr 09, 2020 at 02:44:14PM +0200, Jeremie Courreges-Anglas wrote:
>> On Thu, Apr 09 2020, Jeremie Courreges-Anglas wrote:
>> > find(1) uses ARG_MAX to compute the maximum space it can pass to
>> > execve(2). This doesn't fly if userland and the ke
On 09/04/20(Thu) 20:07, Vitaliy Makkoveev wrote:
> usb_detach_wait() will simply wait usb_detach_wakeup() for 60 sec. So
> ugen_detach() will continue to destroy device context before threads
> finish their io.
Is it a theory or is it a fact? If it's a theory how can one be sure
the proposed chan
usb_detach_wait() will simply wait usb_detach_wakeup() for 60 sec. So
ugen_detach() will continue to destroy device context before threads
finish their io.
Index: sys/dev/usb/ugen.c
===
RCS file: /cvs/src/sys/dev/usb/ugen.c,v
retrievi
On Thu, Apr 09, 2020 at 01:08:12PM +0200, Martin Pieuchot wrote:
> On 09/04/20(Thu) 12:20, Peter J. Philipp wrote:
> > It's April 9th for me, so no chance for April 1st things. Both patches
> > didn't
> > boot (they loaded on ofwboot though) for me. I assume you wanted me to
> > enable
> > WITN
On Thu, Apr 09, 2020 at 02:44:14PM +0200, Jeremie Courreges-Anglas wrote:
> On Thu, Apr 09 2020, Jeremie Courreges-Anglas wrote:
> > find(1) uses ARG_MAX to compute the maximum space it can pass to
> > execve(2). This doesn't fly if userland and the kernel don't agree, as
> > noticed by some afte
On Thu, 09 Apr 2020 14:44:14 +0200, Jeremie Courreges-Anglas wrote:
> Right now we don't account for the space used by the environment.
> We get lucky either because of the 5000 max args limit or because
> environment size usually fits in the 4096 bytes safety net.
>
> The diff below uses the same
On Thu, Apr 09 2020, Jeremie Courreges-Anglas wrote:
> find(1) uses ARG_MAX to compute the maximum space it can pass to
> execve(2). This doesn't fly if userland and the kernel don't agree, as
> noticed by some after the recent ARG_MAX bump.
>
> --8<--
> ritchie /usr/src/usr.bin/find$ obj/find /u
On 09/04/20(Thu) 12:20, Peter J. Philipp wrote:
> It's April 9th for me, so no chance for April 1st things. Both patches didn't
> boot (they loaded on ofwboot though) for me. I assume you wanted me to enable
> WITNESS option which I did. The kernel did not print anything so it must have
> done s
It's April 9th for me, so no chance for April 1st things. Both patches didn't
boot (they loaded on ofwboot though) for me. I assume you wanted me to enable
WITNESS option which I did. The kernel did not print anything so it must have
done something before openfirmware...
I'm going to check out
Is this information already present somehow? I might not know how to
read it. If it isn't, I'd like to include it to help debugging socket
issues as currently brought up by procter@.
Ok?
Index: kern/uipc_socket.c
===
RCS file: /cvs
On 09/04/20(Thu) 10:53, Mark Kettenis wrote:
> > Date: Thu, 9 Apr 2020 10:01:09 +0200
> > From: Martin Pieuchot
> > [...]
> > + lastsp = sp;
> > + sp = *(vaddr_t *)sp;
> > +
> > + if ((sp == 0) || (sp <= lastsp))
> > + break;
>
> I think checking th
> Date: Thu, 9 Apr 2020 10:01:09 +0200
> From: Martin Pieuchot
> Cc: c...@openbsd.org
> Content-Type: text/plain; charset=utf-8
> Content-Disposition: inline
>
> cwen@ reported that GENERIC.MP on powerpc exposes a bug under high load
> which seems to always involve unlocking a rwlock and UVM swap
This diff skips MiRA's event-based probing trigger if we're already
at the minimum or maximum rate of our current rateset.
As of this commit on March 5:
https://marc.info/?l=openbsd-cvs&m=158340898502913&w=2
if we're beginning a probe because of a throughput measurement change event
we cancel the
cwen@ reported that GENERIC.MP on powerpc exposes a bug under high load
which seems to always involve unlocking a rwlock and UVM swapping:
https://marc.info/?l=openbsd-bugs&m=158534549422688&w=2
One way to move forward and get more information is to run a bulk with
WITNESS on powerpc. In order
This seems to be a more accurate interpretation of the MiRA paper (a link
to paper can be found at the top of the ieee80211_mira.h header file).
I see a slight stabilization of Tx throughput with the change.
MiRA's rate probe interval is computed based on the number of frames sent,
and perhaps los
Hi,
While code-reading the riscv64 port (which leans on some arm64 code), I have
found a small gotcha in /sys/arch/arm64/dev/mainbus.c. The patch is self
explanatory and leans on the fix from simplebus.c line 210.
Index: mainbus.c
26 matches
Mail list logo
