Date: Sun, 11 May 2014 20:26:23 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Michael Moll <kvedulv@kvedulv.de> Cc: freebsd-sparc64@freebsd.org Subject: Re: panic on fresh -CURRENT Message-ID: <20140511172622.GA74331@kib.kiev.ua> In-Reply-To: <20140511073743.GA38923@darkthrone.kvedulv.de> References: <20140510213824.GA23740@darkthrone.kvedulv.de> <20140510215647.GU74331@kib.kiev.ua> <20140511073743.GA38923@darkthrone.kvedulv.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--IlmwW192PJ8CjiJ7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, May 11, 2014 at 09:37:43AM +0200, Michael Moll wrote:
> Hi,
>=20
> On Sun, May 11, 2014 at 12:56:47AM +0300, Konstantin Belousov wrote:
> > Still, does it work if you revert the r265843 ?
>=20
> Leads to the same panic.
>=20
> > Do you have INVARIANTS defined in your kernel config ?
>=20
> No. But would be no problem, if it helps to track down the problem.
>=20
> > Do you have vmcore from the panic ? If yes, please load it
> > in kgdb and do p *(struct vm_page *)0xfffff800fc480870.
>=20
> Sure, here we go:
>=20
> panic: vm_page_free: freeing wired page 0xfffff800fb7f6d98
> cpuid =3D 0
> KDB: stack backtrace:
> panic() at panic+0x1d4
> vm_page_free_toq() at vm_page_free_toq+0xa0
> vm_page_free_zero() at vm_page_free_zero+0x10
> pmap_release() at pmap_release+0xe4
> vmspace_exit() at vmspace_exit+0x104
> exit1() at exit1+0x6d4
> sigexit() at sigexit+0xb94
> postsig() at postsig+0x194
> ast() at ast+0x44c
> -- syscall (7, FreeBSD ELF64, sys_wait4) %o7=3D0x1027e8 --
> userland() at 0x156484
> user trace: trap %o7=3D0x1027e8
> pc 0x156484, sp 0x7fdffffd501
> panic: trap: fast data access mmu miss (kernel)
> cpuid =3D 0
> KDB: enter: panic
>=20
> [...]
> (kgdb) p *(struct vm_page *)0xfffff800fb7f6d98
> $1 =3D {plinks =3D {q =3D {tqe_next =3D 0xfffff800fb7f6e10, tqe_prev =3D =
0xfffff800fb7f6ca8}, s =3D {ss =3D {sle_next =3D 0xfffff800fb7f6e10}, pv =
=3D 0xfffff800fb7f6ca8}, memguard =3D {
> p =3D 18446735281835961872, v =3D 18446735281835961512}}, listq =3D=
{tqe_next =3D 0xfffff800fb7f6e10, tqe_prev =3D 0xfffff80013644248}, object=
=3D 0x0, pindex =3D 9,=20
> phys_addr =3D 3448094720, md =3D {tte_list =3D {tqh_first =3D 0xec36f1e=
0, tqh_last =3D 0xec36f1f0}, pmap =3D 0x0, colors =3D {0, 0}, color =3D 0},=
wire_count =3D 4294967295,=20
> busy_lock =3D 1, hold_count =3D 0, flags =3D 8, aflags =3D 0 '\0', ofla=
gs =3D 0 '\0', queue =3D 255 '???', segind =3D 0 '\0', order =3D 12 '\f', p=
ool =3D 0 '\0', act_count =3D 9 '\t',=20
> valid =3D 0, dirty =3D 0}
There are two things wrong with the page. One, the obvious issue,
is that wire_count is -1, i.e. the manual decrement underflown.
The other issue is that the page is not marked as unmanaged, which
is quite strange.
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.
diff --git a/sys/sparc64/sparc64/pmap.c b/sys/sparc64/sparc64/pmap.c
index 28fcb1f..eb3582e 100644
--- a/sys/sparc64/sparc64/pmap.c
+++ b/sys/sparc64/sparc64/pmap.c
@@ -1226,9 +1226,14 @@ pmap_pinit(pmap_t pm)
CPU_ZERO(&pm->pm_active);
=20
VM_OBJECT_WLOCK(pm->pm_tsb_obj);
+ KASSERT(pm->pm_tsb_obj->resident_page_count =3D=3D 0,
+ ("tsb_obj %p rpc %d", pm->pm_tsb_obj,
+ pm->pm_tsb_obj->resident_page_count));
for (i =3D 0; i < TSB_PAGES; i++) {
m =3D vm_page_grab(pm->pm_tsb_obj, i, VM_ALLOC_NOBUSY |
VM_ALLOC_WIRED | VM_ALLOC_ZERO);
+ KASSERT(m->wire_count =3D=3D 1, ("tsb_obj %p m %p wc %u",
+ pm->pm_tsb_obj, m, m->wire_count));
m->valid =3D VM_PAGE_BITS_ALL;
m->md.pmap =3D pm;
ma[i] =3D m;
@@ -1289,11 +1294,13 @@ pmap_release(pmap_t pm)
obj =3D pm->pm_tsb_obj;
VM_OBJECT_WLOCK(obj);
KASSERT(obj->ref_count =3D=3D 1, ("pmap_release: tsbobj ref count !=3D 1"=
));
+ KASSERT(pm->pm_tsb_obj->resident_page_count =3D=3D TSB_PAGES,
+ ("tsb_obj %p rpc %d", pm->pm_tsb_obj,
+ pm->pm_tsb_obj->resident_page_count));
while (!TAILQ_EMPTY(&obj->memq)) {
m =3D TAILQ_FIRST(&obj->memq);
m->md.pmap =3D NULL;
- m->wire_count--;
- atomic_subtract_int(&vm_cnt.v_wire_count, 1);
+ vm_page_unwire(m, 0);
vm_page_free_zero(m);
}
VM_OBJECT_WUNLOCK(obj);
--IlmwW192PJ8CjiJ7
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)
iQIcBAEBAgAGBQJTb7K+AAoJEJDCuSvBvK1BZz4P/janl6w6rjxPyHYr5E6sJISv
4iv3Wt2Ws4jIhHmC1PMA9QhF1rzddHPOL8lZlU1IIwSogFSTMUzjvn5fbODL7Vb/
zQ9QTIamHQ5oDlXM+8Jnp+dQAaSqehuv/r4uBwLeWXAQVfjvCIGv7u7706+PKllA
aGcjr07yVAUhYLIGnP7GiT/B3MuPJSf6RZh+pq6T6Q+npw588bCLIvbVYH+tRypy
bQtASWpQA/qwO39DLf0c0lfMxh4/et7ZRXSQNWnuetC5dQ2yx9rT26Jhjf+dp0DD
zBEkWc8fyYoJIRAsjYx5ke0ZfX+7KQrgJkRZ7Iq12yQrAZeafOC+CPFXyEWbfYLr
04S1CtdCdiDMcehgLaWWsvsv+TpU04U8cyteXroctuxDZBmpoV4XOF2CPaVBwy8a
+TDC2rtf5bZ67PwMCDfPVgOWKLLmvFLFF/mTcSb27++YVpmVOruFBpcSBqczc9wR
Kcie+fiOyXmZ8IE3vXswQAA+ycqKxXiG92gY5SzEEVFzWbQTJsdF9VUoQfYleDPO
xq/r5l5erWnbq27IEytCbpe+sq70UOuJTp3tTA/fV1MTy4qQr5WVjL3wrO8jyIin
V41Bqmb1ty59XOXnrTq8uasOhBT0QSCDgeb9rb4Y6dKuCZAAeOiC+OaTLFYI4BSZ
xBTZFfTx29tIo+C0n79m
=STh8
-----END PGP SIGNATURE-----
--IlmwW192PJ8CjiJ7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140511172622.GA74331>