Date: Tue, 17 Jan 2012 21:01:08 +0100 From: Milan Obuch <freebsd-ppc@dino.sk> To: freebsd-ppc@freebsd.org Subject: Broken nullfs on powerpc Message-ID: <20120117210108.28d007ec@atom.dino.sk>
next in thread | raw e-mail | index | archive | help
Hi,
some time ago I noticed nullfs does not work on powerpc. I am using it
regularly on i386 and amd64 systems for various reasons, one of them
being ability to use the same sources for multiple systems, located
in /data/src10 directory as an example, mounting it to usual /usr/src
directory for system build.
This does not work for powerpc. Today I built new freshly csupped
10-CURRENT, after booting it, I am able repeatedly invoke panic with
just
mount_nullfs /data/src10 /usr/src
csup standard-supfile
almost immediatelly. When I do only reading, with
mount_nullfs /data/src10 /usr/src
tar cvf /dev/null /usr/src
no panic occured. This makes me almost sure issue is somewhere on write
path in nullfs code.
In addition, I've got following backtrace trying csup command
lock order reversal:
1st 0xd8744c48 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2658
2nd 0x11744400 dirhash (dirhash)
@ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace:
0xe2372390: at kdb_backtrace+0x4c
0xe2372400: at _witness_debugger+0x3c
0xe2372420: at witness_checkorder+0x94c
0xe2372480: at _sx_xlock+0xa0
0xe23724b0: at ufsdirhash_acquire+0x40
0xe23724d0: at ufsdirhash_add+0x30
0xe2372500: at ufs_direnter+0x6e0
0xe2372580: at ufs_makeinode+0x4ec
0xe23726f0: at ufs_create+0x44
0xe2372710: at VOP_CREATE_APV+0xe0
0xe2372730: at VOP_CREATE_AP+0x20
0xe2372750: at null_bypass+0x12c
0xe2372810: at VOP_CREATE_APV+0xf8
0xe2372830: at vn_open_cred+0x23c
0xe2372930: at vn_open+0x24
0xe2372950: at kern_openat+0x1f0
0xe2372a50: at kern_open+0x34
0xe2372a70: at sys_open+0x28
0xe2372a90: at trap+0x388
0xe2372b60: at powerpc_interrupt+0x108
0xe2372b90: user SC trap by _end+0x41120760: srr1=0xf032
r1=0xff8f7d60 cr=0x48000042 xer=0x20000000 ctr=0x418e5630
panic: mtx_lock() of spin mutex (null)
@ /usr/src/sys/kern/vfs_subr.c:2670 cpuid = 0
KDB: enter: panic
but I have no idea where to go from this. As debugger prompt is
available at this stage, I could look for some additional information,
but need an advice what to look for.
Most probably there is some endianness or 32/64-bit issue here,
however, as amd64 version works for me just fine, I suspect the
former - after all, my test was made on Mac mini, which is G4, 32 bit
big endian processor... I will try to repeat it on G5 PowerMac with
both 32 and 64 bit OS version, but it takes some time to do this.
If anybody has any idea, patch to test, etc. I am ready to work with
as I would really like to have this issue resolved.
Regards,
Milan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120117210108.28d007ec>