Date: Wed, 26 Apr 2006 17:45:53 +0200 From: Fabian Keil <freebsd-listen@fabiankeil.de> To: Daichi GOTO <daichi@freebsd.org> Cc: freebsd-fs@freebsd.org, freebsd-hackers@freebsd.org, freebsd-current@freebsd.org, ozawa@ongs.co.jp, Kris Kennaway <kris@obsecurity.org> Subject: Re: [ANN] unionfs patchset-11 release Message-ID: <20060426174553.43863486@localhost> In-Reply-To: <20060426170335.40e95f36@localhost> References: <E1F5gbI-000Eea-B7@cs1.cs.huji.ac.il> <43E5D052.3020207@freebsd.org> <43E656C7.8040302@freesbie.org> <43E6D5C8.4050405@freebsd.org> <43E71485.5040901@freesbie.org> <43E73330.8070101@freebsd.org> <43EB4C00.2030101@freebsd.org> <4417DD8D.3050201@freebsd.org> <4433CA53.5050000@freebsd.org> <444E13BA.8050902@freebsd.org> <20060425175553.GA56011@xor.obsecurity.org> <444F663D.9060905@freebsd.org> <20060426151557.3a46dfbd@localhost> <444F8006.6010609@freebsd.org> <20060426170335.40e95f36@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_QW2V0/lsfWnLa0mc26Lg1+/
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Fabian Keil <freebsd-listen@fabiankeil.de> wrote:
> Daichi GOTO <daichi@freebsd.org> wrote:
>=20
> > Fabian Keil wrote:
> > > I got a different panic on
> > > FreeBSD TP51.local 6.1-RC FreeBSD 6.1-RC #22: Wed Apr 26 13:25:57 CES=
T 2006
> > > after mounting an empty directory above /usr/src,
> > > applying a patch and using find's -type f option shortly afterwards
> > > to show the files in the directory on top:=20
> > We tried as follow, but we could not get the same error :(
> > It looks very fine.
> I didn't give you enough information, sorry.
>=20
> What I'm doing is:
>=20
> fk@TP51 ~ $mkdir /tmp/unionfs-src/
> fk@TP51 ~ $mount_unionfs /tmp/unionfs-src /usr/src
> fk@TP51 ~ $cd /usr/src
> fk@TP51 /usr/src $patch -p1 < ~/test/combi.patch
> fk@TP51 /usr/src $find /tmp/unionfs-src/ -type f
> [Panic]
>=20
> ~/test/combi.patch changes about twenty files.
>=20
> I'm not sure if it's important, but /usr was mounted
> readonly and /tmp is a different file system.
>=20
> My kernel has options WITNESS enabled.
>=20
> The last step doesn't seem to be the only way to
> get a problem, I tried the first four steps again
> and umount /usr/src resulted in a reboot.
>=20
> I was running Xorg and didn't get a panic, but I'll
> try again without Xorg, to see if it's the same problem.
OK, I guess it's the same problem:
panic: initiate_write_filepage: dir inum 0 !=3D new 8482
KDB: enter: panic
Locked vnodes
0xc359ddd0: tag syncer, type VNON
usecount 1, writecount 0, refcount 2 mountedhere 0
flags ()
lock type syncer: EXCL (count 1) by thread 0xc334ec00 (pid 41)
0xc393a880: tag ufs, type VDIR =20
usecount 1, writecount 0, refcount 3 mountedhere 0
flags () =20
v_object 0xc3746e70 ref 0 pages 0
lock type ufs: EXCL (count 1) by thread 0xc334ec00 (pid 41)
ino 8469, on dev ad0s3e
exclusive sleep mutex Softdep Lock r =3D 0 (0xc07839c0) locked @ /usr/src/s=
ys/ufs/ffs/ffs_softdep.c:3730
exclusive sleep mutex Giant r =3D 0 (0xc072f640) locked @ /usr/src/sys/kern=
/vfs_subr.c:1608
Locked vnodes
0xc359ddd0: tag syncer, type VNON
usecount 1, writecount 0, refcount 2 mountedhere 0
flags ()
lock type syncer: EXCL (count 1) by thread 0xc334ec00 (pid 41)
0xc393a880: tag ufs, type VDIR
usecount 1, writecount 0, refcount 3 mountedhere 0
flags ()
v_object 0xc3746e70 ref 0 pages 0
lock type ufs: EXCL (count 1) by thread 0xc334ec00 (pid 41)
ino 8469, on dev ad0s3e
panic: from debugger
Uptime: 2m14s
Dumping 511 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 511MB (130656 pages) 495 479 463 447 431 415 399 383 367 351 335=
319 303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) where
#0 doadump () at pcpu.h:165
#1 0xc054a865 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4=
02
#2 0xc054ab27 in panic (fmt=3D0xc06c9423 "from debugger") at /usr/src/sys/=
kern/kern_shutdown.c:558
#3 0xc047f523 in db_panic (addr=3D-1068086451, have_addr=3D0, count=3D-1, =
modif=3D0xd564b8d8 "") at /usr/src/sys/ddb/db_command.c:438
#4 0xc047f49c in db_command (last_cmdp=3D0xc072b3e4, cmd_table=3D0x0, aux_=
cmd_tablep=3D0xc06f28c4, aux_cmd_tablep_end=3D0xc06f28c8)
at /usr/src/sys/ddb/db_command.c:350
#5 0xc047f58d in db_command_loop () at /usr/src/sys/ddb/db_command.c:458
#6 0xc048143d in db_trap (type=3D3, code=3D0) at /usr/src/sys/ddb/db_main.=
c:221
#7 0xc0564dd7 in kdb_trap (type=3D0, code=3D0, tf=3D0xd564ba24) at /usr/sr=
c/sys/kern/subr_kdb.c:473
#8 0xc069e4d2 in trap (frame=3D
{tf_fs =3D -1066532856, tf_es =3D 40, tf_ds =3D -714866648, tf_edi =
=3D 1, tf_esi =3D -1066511478, tf_ebp =3D -714818964, tf_isp =3D -714818992=
, tf_ebx =3D -714818908, tf_edx =3D 0, tf_ecx =3D -1056878592, tf_eax =3D 1=
8, tf_trapno =3D 3, tf_err =3D 0, tf_eip =3D -1068086451, tf_cs =3D 32, tf_=
eflags =3D 642, tf_esp =3D -1066558175, tf_ss =3D -1066564882}) at /usr/src=
/sys/i386/i386/trap.c:593
#9 0xc068feda in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#10 0xc0564b4d in kdb_enter (msg=3D0x12 <Address 0x12 out of bounds>) at cp=
ufunc.h:60
#11 0xc054aabf in panic (fmt=3D0xc06e538a "%s: dir inum %d !=3D new %d") at=
/usr/src/sys/kern/kern_shutdown.c:542
#12 0xc0634021 in initiate_write_filepage (pagedep=3D0xc354bc00, bp=3D0xcd8=
38268) at /usr/src/sys/ufs/ffs/ffs_softdep.c:3834
#13 0xc0633d1c in softdep_disk_io_initiation (bp=3D0xcd838268) at /usr/src/=
sys/ufs/ffs/ffs_softdep.c:3740
#14 0xc063c8c4 in ffs_geom_strategy (bo=3D0xc358aa50, bp=3D0xcd838268) at b=
uf.h:422
#15 0xc0648db7 in ufs_strategy (ap=3D0x12) at /usr/src/sys/ufs/ufs/ufs_vnop=
s.c:1942
#16 0xc06b47c8 in VOP_STRATEGY_APV (vop=3D0xc0719380, a=3D0xd564bb68) at vn=
ode_if.c:1796
#17 0xc059965c in bufstrategy (bo=3D0xc393a940, bp=3D0x12) at vnode_if.h:928
#18 0xc05946e6 in bufwrite (bp=3D0xcd838268) at buf.h:415
#19 0xc0594c31 in bawrite (bp=3D0x12) at buf.h:399
#20 0xc063cb82 in ffs_syncvnode (vp=3D0xc393a880, waitfor=3D3) at /usr/src/=
sys/ufs/ffs/ffs_vnops.c:256
#21 0xc063b753 in ffs_sync (mp=3D0xc352b400, waitfor=3D3, td=3D0xc334ec00) =
at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1143
#22 0xc05a7f42 in sync_fsync (ap=3D0x0) at /usr/src/sys/kern/vfs_subr.c:3086
#23 0xc06b416c in VOP_FSYNC_APV (vop=3D0x12, a=3D0x0) at vnode_if.c:1020
#24 0xc05a59d6 in sync_vnode (bo=3D0xc359de90, td=3D0xc334ec00) at vnode_if=
.h:537
#25 0xc05a5cbf in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1676
Before I got the panic I unmounted the layer above /usr/src
and used mount to show the result. There were perhaps 5 seconds
between umount /usr/src and the panic.
Another thing which could be significant or not:
After my last mail I closed Xorg and tried to reproduce the
panic two times, but couldn't. After a reboot the panic
occurred right after the first attempt.
Fabian
--=20
http://www.fabiankeil.de/
--Sig_QW2V0/lsfWnLa0mc26Lg1+/
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (FreeBSD)
iD8DBQFET5W6jV8GA4rMKUQRAruaAKCjsOc7d6OMCUYtNpGVW4gUFq/9ewCg0G/c
Efjt0etLidIbQQH4bSgQJLg=
=2VXm
-----END PGP SIGNATURE-----
--Sig_QW2V0/lsfWnLa0mc26Lg1+/--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060426174553.43863486>