On 09/04/20(Thu) 22:58, George Koehler wrote:
> On Thu, 9 Apr 2020 20:05:34 +0200
> Martin Pieuchot 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
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
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 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
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
> >
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
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
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
> 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
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=158534549422688=2
One way to move forward and get more information is to run a bulk with
WITNESS on powerpc. In order to
10 matches
Mail list logo