Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Jan 2012 14:21:23 +0200
From:      Kostik Belousov <kostikbel@gmail.com>
To:        Milan Obuch <freebsd-current@dino.sk>
Cc:        freebsd-current@freebsd.org
Subject:   Re: nullfs broken on powerpc
Message-ID:  <20120125122123.GK2726@deviant.kiev.zoral.com.ua>
In-Reply-To: <20120124183152.40c5c5af@atom.dino.sk>
References:  <20120124183152.40c5c5af@atom.dino.sk>

next in thread | previous in thread | raw e-mail | index | archive | help

--XjbSsFHOHxvQpKib
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 24, 2012 at 06:31:52PM +0100, Milan Obuch wrote:
> Hi,
>=20
> as I succesfully installed FreeBSD on Mac Mini (older powerpc model
> with G4 CPU) I tried to use mount_nullfs to share some files for more
> systems. I use this method for years on i386 and amd64 platforms for
> years now to share sources and other files.
>=20
> Basically I want to have small system specific slice/partition and
> large shared data area. System sources are in shared area as well as
> some working area (think /usr/src and /usr/obj directories).
>=20
> 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
>=20
> mount_nullfs /data/src10 /usr/src
> csup /usr/share/examples/cvsup/standard-supfile
>=20
> and system panic occurs, with following on system console:
>=20
> 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>
>=20
> 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:
>=20
> 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=3D0x41a0=
ac40
> db>
>=20
> 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.
>=20
> At line 2670 of /usr/src/sys/kern/vfs_subr.c I see end of function void
> vgonel(struct vnode *vp)
>=20
>         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;
> }
>=20
> 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.

--XjbSsFHOHxvQpKib
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)

iEYEARECAAYFAk8f88MACgkQC3+MBN1Mb4jF9ACglY79BRneKuX5dxLV26n2/++I
NRQAoJbr1nQriIq85GZq1uscg0pdKKqe
=oWbS
-----END PGP SIGNATURE-----

--XjbSsFHOHxvQpKib--



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