From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 19:50:51 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 01642106566B for ; Wed, 25 Jan 2012 19:50:51 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from loki.netlab.sk (ns3.netlab.sk [84.245.65.11]) by mx1.freebsd.org (Postfix) with ESMTP id A8EF68FC08 for ; Wed, 25 Jan 2012 19:50:50 +0000 (UTC) Received: from atom.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by loki.netlab.sk with ESMTPSA; Wed, 25 Jan 2012 20:48:29 +0100 id 00033C37.4F205C8D.000135DD Date: Wed, 25 Jan 2012 20:50:41 +0100 From: Milan Obuch To: Kostik Belousov Message-ID: <20120125205041.26aeef85@atom.dino.sk> In-Reply-To: <20120125122123.GK2726@deviant.kiev.zoral.com.ua> References: <20120124183152.40c5c5af@atom.dino.sk> <20120125122123.GK2726@deviant.kiev.zoral.com.ua> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEX+/v7++v6YOTrq8PCcuIX989UvOSj++v0BNCbpAAAAB3RJTUUHsQwfFzs7RBhzUQAAAhJJREFUOI1dU8GOqzAMNKIoV1bvwD1i0ysqrHplIdBrVSX7ATSbd03VVvn9tQNtQy0hjAdn7LED4AAcPtWm9RV+MPSfxhBLx9ajd6X/ngB6/mTwnRSZua7i7Ca+0ctZKo4Qmz+JY13X6I3nFZBxIYW1PbgfQ5RP8g0XlltEWGf3cV03joYpRnFbvYDKbXjZlXyyhEZA4lI+cN3NaVXE4VKjSwTExO10eTEkkJVqIAD5z0nUBQJluQDRSQjcrBiHAJxZlAH5CUMBMC7OcJ4LMQNnxhZ1HYPscMc6J4UlWRMNwzOpCcAHKSICd1EDn83abdREIbXsHkD1OinP1aCUCOEVRaa1lMcvywUWdYgk13JQUpYNKmvXQ8Kw5ML9YI5h8SakctBc7E/IYuLhYd/zZIk+1gM1vNweQBvHE0j+oYah3sMqAytQYlZk6+ANaaawJdu3OFzYGMZ3iGpa3qMlq9ZH0VZTgrCtw/ngdYkEIIpSbP1bWQAdFdX9vocBdkH2qVjVmuMu3gI5rjs814EUdrCZgWlPaxZZ3RiLFUtr+ud0PXwp2dnQSNXgePt6AZpBj6UMJ7VQkzN4utVeaSW1Dhn/kblGrKeMvNGnzwX4zuEDarYz1KdPtR60Gul0Gued+515SJXhCsl+Tx/3kY/UDvicPll9mfu50t3tvQ/thZpJYgeuwdSKNJ6tCD98MCgoxLDaPxbwqqwPWaWiAAAAAElFTkSuQmCC X-Face: ak5rwz4-aUa>hPFZlcg,bXxn.(TN}e9DGFrKU\.i_'B[&5=pAd9o"j)5VSUYW:BRQG#^42Ev$Il|; Ztn=,C X-Operating-System: FreeBSD/amd64 8.2-STABLE Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org 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 19:50:51 -0000 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 = 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... > 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-online-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... Regards, Milan