On Fri, Oct 18, 2019 at 01:21:00PM +0000, Lévai, Dániel wrote:
> In light of this information (always appreciate a sneak peek into these low
> level stuff from you guys, btw, appreciate it!), is it fair to assume that if
> I run bsd.sp on this hardware I might just be able to get away without any
> hiccups?
You can try, but this is hard to predict,
-Otto
>
> Dani
>
> --
> Lévai, Dániel
>
> Sent from a mobile, please excuse any formatting errors
>
> -------- Original Message --------
> On Oct 15, 2019, 7:22 AM, Otto Moerbeek wrote:
>
> > On Mon, Oct 14, 2019 at 04:17:53PM +0200, Alexander Bluhm wrote:
> >
> >> On Fri, Oct 11, 2019 at 01:19:02PM +0000, L??vai, D??niel wrote:
> >> > uvm_fault(0xfffffd8124d90960, 0x7f884cecdcf8, 0, 2) -> e
> >> > kernel: page fault trap, code=0
> >> > Stopped at pmap_page_remove+0x210: xchgq %rax,0(%rcx,%rdx,1)
> >>
> >> > ddb{3}> trace
> >> > pmap_page_remove(fffffd[800975](tel:800975)d480) at
> >> > pmap_page_remove+0x210
> >> > uvm_anfree(fffffd8125d62b10) at uvm_anfree+0x36
> >> > amap_wipeout(fffffd8123d95170) at amap_wipeout+0xe5
> >> > uvm_unmap_detach(ffff[800022420](tel:800022420)fe8,0) at
> >> > uvm_unmap_detach+0x90
> >> > sys_munmap(ffff[800022233](tel:800022233)cb8,ffff800022421060,ffff8000224210d0)
> >> > at sys_munmap+0x11d
> >> > syscall(ffff800022421140) at syscall+0x305
> >> > Xsyscall(6,49,109a8d931e10,49,109a58e72150,1099d9b9f000) at
> >> > Xsyscall+0x128
> >> > end of kernel
> >> > end trace frame: 0x109a82dffa50, count: -7
> >>
> >> I see this bug for a while now.
> >>
> >> https://marc.info/?l=openbsd-bugs&m=156399483018833&w=2
> >>
> >> I can trigger it by running /usr/src/regress/lib/libpthread/malloc_duel
> >> for some hours. Moritz Buhl has tried to bisect the problem and
> >> it appears to exists since January 2019. But it is hard to be sure
> >> as reproducing takes a while. It is also unclear whether the change
> >> in behavior is caused by compiler, kernel, libc, libpthread or
> >> malloc_duel. We could not trigger it with OpenBSD 6.4.
> >>
> >> bluhm
> >>
> >
> > There's been a change in malloc_duel to use more threads. Originally
> > it was using 2, now 11. That change was committed in May 2019 (plus a
> > commit to enable the test), so later than Jan 2019. But a userland
> > induced panic is always a bug.
> >
> > -Otto
