panic on fresh -CURRENT

[Konstantin Belousov]

On Sun, May 11, 2014 at 10:53:59PM +0200, Michael Moll wrote:
> Hi,
> 
> On Sun, May 11, 2014 at 08:26:23PM +0300, Konstantin Belousov wrote:
> > Please try the following patch, it slightly modernizes the tsb page free
> > sequence to the current VM KPI, and also adds assertions which reflect
> > my understanding of the correct state of the tsb object and pages.
> > The patch is not a fix, it only should somewhat improve debugging.
> > And yes, enable INVARIANTS.
> 
> OK, I'm now at r265844 + your patch and enabled INVARIANTS. However,
> the initial panic is not reproducible anymore, but I get different
> ones and can't get hold of a dump, there are quite some messages
> "cheetah_ipi_single: couldn't send IPI to module 0x1" after the panics.
This is somewhat consistent, in fact, with the panics, see below.

> panic: vm_page_alloc: page 0xfffff800f99164a0 is wired
So this looks as if the mishandling of the wire_count just moved to some
other pages, in this case, the freed pages got their wire_count corrupted
(incremented ?).

> panic: vm_page_alloc: page 0xfffff800fd9c4a60 has unexpected queue 1
But this case is more interesting, since now a field of struct vm_page
other than wire_count seems to be corrupted, with the same value '1'.

What was the last working kernel revision for you ?  I do not know MD
sparc64 code, might be, you could move forward with bisect.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20140512/129ffd66/attachment.sig>