Date: Tue, 17 Jan 2012 17:13:40 -0500 From: Super Bisquit <superbisquit@gmail.com> To: Milan Obuch <freebsd-ppc@dino.sk> Cc: freebsd-ppc@freebsd.org Subject: Re: Broken nullfs on powerpc Message-ID: <CA%2BWntOvRaKkbvdaTWZmTnXzixm_Grjmg7p5mg5sq-ZZ3tn9AjQ@mail.gmail.com> In-Reply-To: <20120117210108.28d007ec@atom.dino.sk> References: <20120117210108.28d007ec@atom.dino.sk>
next in thread | previous in thread | raw e-mail | index | archive | help
Rebuild your kernel and disable the system from posting lock reversals. Rebuild world and then build the nullfs module (and others) or enable in rc.conf. Have you done these things? On Tue, Jan 17, 2012 at 3:01 PM, Milan Obuch <freebsd-ppc@dino.sk> wrote: > 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 > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BWntOvRaKkbvdaTWZmTnXzixm_Grjmg7p5mg5sq-ZZ3tn9AjQ>