On Fri, Sep 23, 2016 at 09:33:36PM +0200, Jaromír Dole?ek wrote: > Hey Maxime, > > Seems the KASSERTs() are too aggressive, or there is some other bug. > > I can trigger the kassert by simply attaching to rump_ffs, setting a > breakpoint and continuing, i.e: > > > rump_ffs -o log ./ffs ./mnt > > gdb rump_ffs > ... > (gdb) attach RUMP_PID > (gdb) break ffs_truncate > Breakpoint 1 at 0xad0b951f: file > /usr/home/dolecek/netbsd/sys/rump/fs/lib/libffs/../../../../ufs/ffs/ffs_inode.c, > line 210. > (gdb) cont > panic: kernel diagnostic assetion "onfault == kcopy_fault || rcr2() < > VM_MAXUSER_ADDRESS" failed: file "../../../../arch/i386/i386/trap.c", > line 358 > > Could you please look at it? > > I'll disable the KASSERT() in my local tree, so that I'll be able to > develop. But would be good idea to check what so special that gdb is > doing that it trips over.
This anita test run: http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/i386/201609171110Z_anita.txt also triggered the KASSERT(). As it didn't happen with newer builds I assumed it has been fixed, but maybe it's just that it's not 100% reproductible in this context. -- Manuel Bouyer <bou...@antioche.eu.org> NetBSD: 26 ans d'experience feront toujours la difference --