Date: Sun, 3 Feb 2008 13:06:16 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Dmitry Morozovsky <marck@rinet.ru> Cc: freebsd-stable@freebsd.org, sos@freebsd.org Subject: Re: 7.0-PRE/amd64 crash with Promise TX4 and eSATA disk Message-ID: <20080203110616.GJ57756@deviant.kiev.zoral.com.ua> In-Reply-To: <20080203120136.B28725@woozle.rinet.ru> References: <20080203030205.T28725@woozle.rinet.ru> <20080203065502.GH57756@deviant.kiev.zoral.com.ua> <20080203120136.B28725@woozle.rinet.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
--uSiDmGZtMrYHxQQN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Feb 03, 2008 at 12:05:44PM +0300, Dmitry Morozovsky wrote:
> On Sun, 3 Feb 2008, Kostik Belousov wrote:
>=20
> KB> Di you have the UFS volume mounted from the eSATA drive ? If yes, the=
n the
> KB> panic is the natural consequence of the device disappearing from unde=
r the
> KB> UFS. If not, and fault address 0x3020e0b30 looks suspicious, it could=
mean
> KB> some kernel memory corruption.
>=20
> yes, there is (were) UFS2 on eSATA.
>=20
> KB> Anyway, it would be interesting to look at the vnode vp content fro=
m the
> KB> frame #10, and to lookup the mount point together with a device it =
comes
> KB> from.
>=20
> (kgdb) fr 10
> #10 0xffffffff8029dcf3 in vn_stat (vp=3D0xffffff004728b9b0,=20
> sb=3D0xffffffffd79f79f0, active_cred=3DVariable "active_cred" is not avai=
lable.
> ) at vnode_if.h:286
> 286 vnode_if.h: No such file or directory.
> in vnode_if.h
> (kgdb) p vp
> $1 =3D (struct vnode *) 0xffffff004728b9b0
> (kgdb) p *vp
> $2 =3D {v_type =3D VDIR, v_tag =3D 0xffffffff8039319c "ufs", v_op =3D=20
> 0xffffffff804e98e0, v_data =3D 0xffffff003fab0480, v_mount =3D 0xffffff00=
050dc650,=20
The *v_mount and *(struct ufs_mount *)(v_mount->mnt_data) content shall
be enough to confirm that vnode comes from the lost partition.
> v_nmntvnodes =3D {
> tqe_next =3D 0xffffff004728bba0, tqe_prev =3D 0xffffff004728f218}, v_=
un =3D=20
> {vu_mount =3D 0x0, vu_socket =3D 0x0, vu_cdev =3D 0x0, vu_fifoinfo =3D 0x=
0}, v_hashlist=20
> =3D {le_next =3D 0x0,=20
> le_prev =3D 0xffffffff808c10e0}, v_hash =3D 215211, v_cache_src =3D {=
lh_first =3D=20
> 0xffffff003f4d5000}, v_cache_dst =3D {tqh_first =3D 0xffffff0026fcca90, t=
qh_last =3D=20
> 0xffffff0026fccab0},=20
> v_dd =3D 0xffffff00470a49b0, v_cstart =3D 0, v_lasta =3D 0, v_lastw =3D=
0, v_clen =3D=20
> 0, v_lock =3D {lk_object =3D {lo_name =3D 0xffffffff8039319c "ufs", lo_ty=
pe =3D=20
> 0xffffffff8039319c "ufs",=20
> lo_flags =3D 70844416, lo_witness_data =3D {lod_list =3D {stqe_next=
=3D 0x0},=20
> lod_witness =3D 0x0}}, lk_interlock =3D 0xffffffff80514730, lk_flags =3D =
262208,=20
> lk_sharecount =3D 0,=20
> lk_waitcount =3D 0, lk_exclusivecount =3D 1, lk_prio =3D 80, lk_timo =
=3D 51,=20
> lk_lockholder =3D 0xffffff000179c340, lk_newlock =3D 0x0}, v_interlock =
=3D=20
> {lock_object =3D {
> lo_name =3D 0xffffffff8039e4da "vnode interlock", lo_type =3D=20
> 0xffffffff8039e4da "vnode interlock", lo_flags =3D 16973824, lo_witness_d=
ata =3D=20
> {lod_list =3D {stqe_next =3D 0x0},=20
> lod_witness =3D 0x0}}, mtx_lock =3D 4, mtx_recurse =3D 0}, v_vnlo=
ck =3D=20
> 0xffffff004728ba48, v_holdcnt =3D 3, v_usecount =3D 2, v_iflag =3D 0, v_v=
flag =3D 0,=20
> v_writecount =3D 0,=20
> v_freelist =3D {tqe_next =3D 0x0, tqe_prev =3D 0xffffff004728b900}, v_b=
ufobj =3D=20
> {bo_mtx =3D 0xffffff004728ba98, bo_clean =3D {bv_hd =3D {tqh_first =3D 0x=
0, tqh_last =3D=20
> 0xffffff004728bb08},=20
> bv_root =3D 0x0, bv_cnt =3D 0}, bo_dirty =3D {bv_hd =3D {tqh_first =
=3D 0x0,=20
> tqh_last =3D 0xffffff004728bb28}, bv_root =3D 0x0, bv_cnt =3D 0}, bo_numo=
utput =3D 0,=20
> bo_flag =3D 0,=20
> bo_ops =3D 0xffffffff804dd3e0, bo_bsize =3D 65536, bo_object =3D=20
> 0xffffff0047994680, bo_synclist =3D {le_next =3D 0x0, le_prev =3D 0x0}, b=
o_private =3D=20
> 0xffffff004728b9b0,=20
> __bo_vnode =3D 0xffffff004728b9b0}, v_pollinfo =3D 0x0, v_label =3D 0=
x0}
>=20
>=20
> I think tere are at least two problems here:
> - panic when non-essential UFS mounted partition disappears
Unfortunately, FreeBSD has no concept of the unessential mount; I wish
the mount option onerror=3Dnopanic too :).
> - particular disappearing eSATA drive from eSATA channel of TX4. Relevant=
error=20
> messages are
This looks more like the hardware problem, and it only induced the known
kernel deficiency.
>=20
> Feb 2 19:29:18 <kern.crit> hamster kernel: ata7: reiniting channel ..
> Feb 2 19:29:18 <kern.crit> hamster kernel: ata7: SATA connect time=3D0ms
> Feb 2 19:29:18 <kern.crit> hamster kernel: ata7: reset tp1 mask=3D01 ost=
at0=3Dd0=20
> ostat1=3D00
> Feb 2 19:29:18 <kern.crit> hamster kernel: ata7: stat0=3D0xd0 err=3D0x00=
lsb=3D0x36=20
> msb=3D0x72
> Feb 2 19:29:26 <kern.crit> hamster last message repeated 87 times
> Feb 2 19:29:27 <kern.crit> hamster kernel:=20
> Feb 2 19:29:27 <kern.crit> hamster kernel: ata7: stat0=3D0xd0 err=3D0x00=
lsb=3D0x36=20
> msb=3D0x72
> Feb 2 19:29:49 <kern.crit> hamster last message repeated 221 times
> Feb 2 19:29:49 <kern.crit> hamster kernel: ata7: reset tp2 stat0=3Dd0 st=
at1=3D00=20
> devices=3D0x0
> Feb 2 19:29:49 <kern.crit> hamster kernel: ad14: FAILURE - device detach=
ed
> Feb 2 19:29:49 <kern.crit> hamster kernel: ad1g4_:v fdse_tdaocnhee(d):
> Feb 2 19:29:49 <kern.crit> hamster kernel: ad14a[aRtEaA7D:( orfefisneitt=
=3D=20
> d1o2n4e0 9.1.43
> Feb 2 19:29:49 <kern.crit> hamster kernel: 2960, length=3D131072)]error =
=3D 6
> Feb 2 19:29:49 <kern.crit> hamster kernel:=20
> g_vfs_done():ad14a[READ(offset=3D124091564032, length=3D131072)]error =3D=
6
> Feb 2 19:29:49 <kern.crit> hamster kernel:=20
> g_vfs_done():ad14a[READ(offset=3D124091695104, length=3D131072)]error =3D=
6
>=20
> ... and zillion of g_vfs_gone after.
>=20
> Sincerely,
> D.Marck [DM5020, MCK-RIPE, DM3-RIPN]
> [ FreeBSD committer: marck@FreeBSD.org ]
> ------------------------------------------------------------------------
> *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru ***
> ------------------------------------------------------------------------
--uSiDmGZtMrYHxQQN
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (FreeBSD)
iEYEARECAAYFAkeloCgACgkQC3+MBN1Mb4iBqwCeJlkEFSY02Zzf02t0mZHcZBet
vr8AmQGzal5N7choXcqvgGV1Ookatwbn
=7nI0
-----END PGP SIGNATURE-----
--uSiDmGZtMrYHxQQN--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080203110616.GJ57756>