'make -j16 universe' gives SIReset

Marius Strobl marius at alchemy.franken.de
Thu Oct 13 18:42:29 UTC 2011

On Thu, Oct 13, 2011 at 02:56:48PM +1100, Peter Jeremy wrote:
> On 2011-Oct-11 22:55:43 +0200, Marius Strobl <marius at alchemy.franken.de> wrote:
> >> I also ran 6 parallel -j16 buildworlds as a stress test and that was
> >> less successful:
> >> panic: mutex vm object not owned at /usr/src/sys/vm/vm_object.c:281
> >
> >That line should be in vm_object_clear_flag(). The backtrace seems to be
> >incomplete as it doesn't include that function. I'm not sure what to make
> >out of the "VNASSERT failed" and "tag ufs, type VDIR" lines. I guess this
> >could mean that there were two panics at the same time. Does the crashdump
> >provide a better backtrace?
> Unfortunately, I can't get a crashdump because dumpon(8) doesn't like
> my Solaris swap partitions:
> GEOM_PART: Partition 'da0b' not suitable for kernel dumps (wrong type?)
> GEOM_PART: Partition 'da6b' not suitable for kernel dumps (wrong type?)
> No suitable dump device was found.
> I did write a patch for that but took it out during some earlier
> testing to get back to stock code.  It looks like I didn't PR it
> either so I will do that when I get some time.
> I don't understand the panic backtrace either.  Manually running
> "where" gives saner output:
> db> where
> Tracing pid 1299 tid 100640 td 0xfffff8a346e8da40
> panic() at panic+0x20c
> _mtx_assert() at _mtx_assert+0xb0
> vm_object_clear_flag() at vm_object_clear_flag+0x24
> vmtotal() at vmtotal+0xa4
> sysctl_root() at sysctl_root+0x234
> userland_sysctl() at userland_sysctl+0x1cc
> sys___sysctl() at sys___sysctl+0x70
> syscall() at syscall+0x2d8
> -- syscall (202, FreeBSD ELF64, sys___sysctl) %o7=0x10daac --
> userland() at 0x4093c3a8
> user trace: trap %o7=0x10daac
> pc 0x4093c3a8, sp 0x7fdffffcdd1
> pc 0x10dc58, sp 0x7fdffffcea1
> pc 0x1050c0, sp 0x7fdffffcf71
> pc 0x4089c6e0, sp 0x7fdffffd041
> pc 0, sp 0x7fdffffd401
> pc 0x403ab9a0, sp 0x7fdffffd561
> pc 0x104980, sp 0x7fdffffd631
> pc 0x105514, sp 0x7fdffffd751
> pc 0x102790, sp 0x7fdffffe031
> pc 0x4021b014, sp 0x7fdffffe0f1
> done

Hrm, this backtrace seems impossible as vmtotal() explicitly locks
the object before calling vm_object_clear_flag(). A crash dump of
this panic really would be interesting.

> I'm not sure how to access registers in another stack frame so I
> can't find the offending vmobject.  I will need to shutdown that
> box and will do some more digging next week.

I don't think ddb(4) supports accessing registers of another frame,
it however has some VM object debugging support you could play with
if the machine is still running.


More information about the freebsd-sparc64 mailing list