From owner-freebsd-current@FreeBSD.ORG Wed Jan 25 20:29:49 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 8EB6D106566C for ; Wed, 25 Jan 2012 20:29:49 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9844C8FC08 for ; Wed, 25 Jan 2012 20:29:47 +0000 (UTC) Received: by lahj13 with SMTP id j13so312649lah.13 for ; Wed, 25 Jan 2012 12:29:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-gm-message-state:content-type:content-transfer-encoding; bh=HpRNIp3RIFkR3nJ2i3XoYOZUFoYI0u3TMjcKuCadfpM=; b=MkDekKWGUQAF5HMjxODq2UOQ4Lo6cIsi7nMKFbQX3w3Yp6uLzA2sBYHqsARwJDJYXO e4o4/zh8OdM7pIpgfiSzgk02HyNxYQYaNYkqD4SUK2n6sS8s9y0GSJy80ns03DMLzUcJ S80XH0GxKgjjHk4MkyjGQ1oLyHEtEX+zEu/UU= Received: by 10.152.111.229 with SMTP id il5mr7623836lab.19.1327523386112; Wed, 25 Jan 2012 12:29:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.25.196 with HTTP; Wed, 25 Jan 2012 12:29:15 -0800 (PST) In-Reply-To: <20120125205041.26aeef85@atom.dino.sk> References: <20120124183152.40c5c5af@atom.dino.sk> <20120125122123.GK2726@deviant.kiev.zoral.com.ua> <20120125205041.26aeef85@atom.dino.sk> From: Eitan Adler Date: Wed, 25 Jan 2012 15:29:15 -0500 Message-ID: To: Milan Obuch X-Gm-Message-State: ALoCoQlYRX2Cu+iz/5v4Gz0Kb61o5eShGz996mHMSN2Z406z6cubuM/uPrEkneWjsDOUsPqC/yyj Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , 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 20:29:49 -0000 On Wed, Jan 25, 2012 at 2:50 PM, Milan Obuch wrot= e: > 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 =3D 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=3D0xd032 >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 r1=3D0xffaf9a70 cr=3D0x28004= 044 xer=3D0x20000000 >> > ctr=3D0x41a0ac40 >> > 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) >> > >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 VI_LOCK(vp); >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 vp->v_vnlock =3D &vp->v_lock; >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 vp->v_op =3D &dead_vnodeops; >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 vp->v_tag =3D "none"; >> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 vp->v_type =3D 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-onlin= e-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... >From ddb write 'call doadump'. Provided you have a proper dump device set up in rc.conf it should work. You could then use kgdb from a running computer to analyze the dump in more detail. --=20 Eitan Adler