Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 1 Aug 2005 14:05:02 -0700 (PDT)
From:      dpk <dpk@dpk.net>
To:        freebsd-stable@freebsd.org
Subject:   Re: repeatable crash with 5.4-RELEASE and PAE
Message-ID:  <20050801121231.V64406@shared10.hosting.flyingcroc.net>

next in thread | raw e-mail | index | archive | help
As seen here:

http://groups-beta.google.com/group/mailing.freebsd.stable/browse_thread/thread/ad8029efaa6efe95/8f3269d6819ef0b8?lnk=st&q=panic+vm_pageout+fork_trampoline+fork_exit+freebsd+5.4&rnum=1&hl=en#8f3269d6819ef0b8

If you'd prefer, I can mail this to another list, in case stable isn't
appropriate.

We're seeing exactly the same panic here, with slight changes to the
addresses referenced (phew, I don't have to transcribe it!) Our setup is:

Dual Xeon 3.0Ghz
4 gigs of ram
3ware RAID10 (4 x 400GB)
FreeBSD 5.4-RELEASE-p5

We're running a PAE kernel as well. The main difference between his
kernel and ours is that we're not using acpi due to extremely poor
network performance.

Unfortunately the kernel will not dump core (even with a 16GB swap
device). When I do a 'call doadump', it gives this error:

Dumping 4608MB
twa0: SCSI cmd=0x2a: ERROR (0x3: 0x0100): SGL entry contains zero data:
address=0x0, length=0x10000, cmd=W

The original panic line is:

panic: lockmgr: thread 0xfffffff0, not exclusive lock holder c5f5fa80
unlocking

Here's the lockmgr line from the panic:

lockmgr(c61f5e14,6,c61f5d68,0,eb858a1c) lockmgr+0x421

lockmgr's 2nd argument was 6, LK_RELEASE, and lockmgr's 4th argument, the
thread, was 0, so the panic was caused because a kernel thread was trying
to release a lock for a non-kernel thread. Am I interpreting that
correctly?

'show lockedvnods' reveals:

0xc61f5d68: tag devfs, type VCHR, usecount 4846, writecount 0, refcount
78, flags (VV_OBJBUF), lock type devfs: EXCL (count 1) by 0xc5f5fa80 (pid
8)
	dev da0s1a

pid 8 is 'pagedaemon'.

Any ideas/pointers? I've been going through the source and trying to
figure out what's calling the lockmgr. I keep coming back to spec_write(),
which doesn't appear to be used by any filesystems (unless it's used by
procfs?)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050801121231.V64406>