From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 21:05:06 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAE0A106564A for ; Wed, 25 Jan 2012 21:05:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 48C728FC08 for ; Wed, 25 Jan 2012 21:05:05 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q0PL4x1P085600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jan 2012 23:04:59 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q0PL4xms014243; Wed, 25 Jan 2012 23:04:59 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q0PL4xau014242; Wed, 25 Jan 2012 23:04:59 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 25 Jan 2012 23:04:59 +0200 From: Kostik Belousov To: Andreas Tobler Message-ID: <20120125210459.GQ2726@deviant.kiev.zoral.com.ua> References: <20120124183152.40c5c5af@atom.dino.sk> <20120125122123.GK2726@deviant.kiev.zoral.com.ua> <20120125205041.26aeef85@atom.dino.sk> <4F206D6A.3030302@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="s3R87C3fwYeCSZ0b" Content-Disposition: inline In-Reply-To: <4F206D6A.3030302@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Eitan Adler , freebsd-current@freebsd.org, Milan Obuch Subject: Re: nullfs broken on powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 21:05:06 -0000 --s3R87C3fwYeCSZ0b Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 25, 2012 at 10:00:26PM +0100, Andreas Tobler wrote: > On 25.01.12 21:29, Eitan Adler wrote: > >On Wed, Jan 25, 2012 at 2:50 PM, Milan Obuch = =20 > >wrote: > >>On Wed, 25 Jan 2012 14:21:23 +0200 > >>Kostik Belousov wrote: > >> > >>>On Tue, Jan 24, 2012 at 06:31:52PM +0100, Milan Obuch wrote: > >>>>Hi, > >>>> > >> > >>[ snip ] > >> > >>>>This does not work with powerpc for me. With sources csup'ped this > >>>>morning, full system rebuild with GENERIC kernel, it is enough for > >>>>me to issue > >>>> > >>>>mount_nullfs /data/src10 /usr/src > >>>>csup /usr/share/examples/cvsup/standard-supfile > >>>> > >>>>and system panic occurs, with following on system console: > >>>> > >>>>panic: mtx_lock() of spin mutex (null) > >>>>@ /usr/src/sys/kern/vfs_subr.c:2670 cpuid =3D 0 > >>>>KDB: enter: panic > >>>>[ thread pid 1442 tid 100095 ] > >>>>Stopped at 0x40f734: addi r0, r0, 0x0 > >>>>db> > >>>> > >>>>At this point, I am able to interact with system, the question for > >>>>me is what I want to get from it :) I tried bt with following > >>>>result: > >>>> > >>>>Tracing pid 1442 tid 100095 td 0x2d6b000 > >>>>0xe22c26d0: at panic+0x274 > >>>>0xe22c2730: at _mtx_lock_flags+0xc4 > >>>>0xe22c2760: at vgonel+0x330 > >>>>0xe22c27b0: at vrecycle+0x54 > >>>>0xe22c27d0: at null_inactive+0x30 > >>>>0xe22c27f0: at VOP_INACTIVE_APV+0xdc > >>>>0xe22c2810: at vinactive+0x98 > >>>>0xe22c2850: at vputx+0x344 > >>>>0xe22c28a0: at vput+0x18 > >>>>0xe22c28c0: at kern_statat_vnhook+0x108 > >>>>0xe22c29d0: at kern_statat+0x18 > >>>>0xe22c29f0: at kern_lstat+0x2c > >>>>0xe22c2a10: at sys_lstat+0x30 > >>>>0xe22c2a90: at trap+0x388 > >>>>0xe22c2b60: at powerpc_interrupt+0x108 > >>>>0xe22c2b90: user SC trap by _end+0x40d88c70: srr1=3D0xd032 > >>>> r1=3D0xffaf9a70 cr=3D0x28004044 xer=3D0x20000000 > >>>>ctr=3D0x41a0ac40 > >>>>db> > >>>> > >>>>Does this shed any light for someone with more knowledge here? My > >>>>gut feeling is there is some endianness issue at play, the same > >>>>nullfs usage works for me flawlessly on both i386 and amd64 > >>>>systems, so it could not be 32 vs 64 bit issue at least. > >>>> > >>>>At line 2670 of /usr/src/sys/kern/vfs_subr.c I see end of function > >>>>void vgonel(struct vnode *vp) > >>>> > >>>> VI_LOCK(vp); > >>>> vp->v_vnlock =3D&vp->v_lock; > >>>> vp->v_op =3D&dead_vnodeops; > >>>> vp->v_tag =3D "none"; > >>>> vp->v_type =3D VBAD; > >>>>} > >>>> > >>>>so the question seems to be reduced to 'why is vp null?' or is my > >>>>small attempt on analyse flawed... > >> > >>>I do not think that the vp is null. It more look like the *vp memory > >>>was zeroed. This has very low chances of being related to endianess, > >>>and more like a kernel memory corruption. > >>> > >>>Take a dump and print the content of *vp. > >> > >>How could I look into memory? I found page > >>http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-onl= ine-ddb.html > >>and I can see registers (show reg), use x with absolute addresses, but > >>something like 'x vp' tells just 'Symbol not known' - should I somehow > >>load symbol table into memory? But backtrace shows function names... or > >>should I somehow modify GENERIC kernel to include more debugging info? > >>Kernel debugging is a bit new for me, even if I can write simple > >>modification into kernel, but only in some special (and narrow) area of > >>code... > > > >>From ddb write 'call doadump'. Provided you have a proper dump device > >set up in rc.conf it should work. You could then use kgdb from a > >running computer to analyze the dump in more detail. >=20 > This only works if your target is booke, AIM (Apple based machines) do=20 > not have the 'call doadump' implemented yet. It is somewhere on my long= =20 > todo list. FWIW, it is not 'call doadump', it is just 'dump' for some time. I think calling doadump does not work. --s3R87C3fwYeCSZ0b Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk8gbnoACgkQC3+MBN1Mb4icKQCfTcTE4D22DMGCkadCIzIlQTD6 d5EAoKHC/EO/ub3Fbr55HqeOlmkpP74L =q86O -----END PGP SIGNATURE----- --s3R87C3fwYeCSZ0b--