Date: Tue, 24 Jan 2012 18:31:52 +0100 From: Milan Obuch <freebsd-current@dino.sk> To: freebsd-current@freebsd.org Subject: nullfs broken on powerpc Message-ID: <20120124183152.40c5c5af@atom.dino.sk>
next in thread | raw e-mail | index | archive | help
Hi,
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.
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).
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 = 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=0xd032
r1=0xffaf9a70 cr=0x28004044 xer=0x20000000 ctr=0x41a0ac40
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 = &vp->v_lock;
vp->v_op = &dead_vnodeops;
vp->v_tag = "none";
vp->v_type = VBAD;
}
so the question seems to be reduced to 'why is vp null?' or is my small
attempt on analyse flawed...
Regards,
Milan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120124183152.40c5c5af>