For what it's worth, the same HW and system runs fine since we've switched to bsd.sp. Well, the performance is not ideal, but at least it's stable :)
Dani ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, 18 October 2019 17:39, Otto Moerbeek <[email protected]> wrote: > 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(fffffd800975d480) at pmap_page_remove+0x210 > > > > > uvm_anfree(fffffd8125d62b10) at uvm_anfree+0x36 > > > > > amap_wipeout(fffffd8123d95170) at amap_wipeout+0xe5 > > > > > uvm_unmap_detach(ffff800022420fe8,0) at uvm_unmap_detach+0x90 > > > > > sys_munmap(ffff800022233cb8,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
