[ANN] unionfs patchset-11 release
It is my pleasure and honor to announce the availability of the unionfs patchset-11. Patchset-11: For 7-current http://people.freebsd.org/~daichi/unionfs/unionfs-p11.diff For 6.x http://people.freebsd.org/~daichi/unionfs/unionfs6-p11.diff Changes in unionfs-p11.diff - Changed a few implementations around the lock/unlock mechanism. Because of this, you can use both the unionfs and the nullfs together without LK_CANRECURSE. - Fixed a bug that sometimes does not unlock if it cannot create shadow file. The documents of those unionfs patches: http://people.freebsd.org/~daichi/unionfs/ (English) http://people.freebsd.org/~daichi/unionfs/index-ja.html (Japanese) Heads Up: Fabian Keil gave me a good patch to fix my broken English. Above English text is good rather than pre one. Heads Up: Above English text contains some Japanese text. If you are interested in translating the Japanese text into English, please do it and send it to me. ATTENTION: If someone knows the details of vnode's lock status via VOP_GETWRITEMOUNT, Please teach us (daichi, ozawa). We want to know the details. Thanks -- Daichi GOTO, http://people.freebsd.org/~daichi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [ANN] unionfs patchset-11 release
On Tue, 25 Apr 2006, Daichi GOTO wrote: Changes in unionfs-p11.diff - Changed a few implementations around the lock/unlock mechanism. Because of this, you can use both the unionfs and the nullfs together without LK_CANRECURSE. - Fixed a bug that sometimes does not unlock if it cannot create shadow file. First off, thanks again for working on this! If someone knows the details of vnode's lock status via VOP_GETWRITEMOUNT, Please teach us (daichi, ozawa). We want to know the details. Basically, file systems supporting full file system snapshots (UFS) provide a mechanism to "lock out" writers before they enter VFS so that they don't end up holding write locks for long periods, leading to deadlock. vn_start_write() is called to notify the file system that a thread is about to enter the file system for a write, and vn_write_finished() is called to notify the file system it is done. In effect, it's a giant reader-writer lock, which allows multiple readers and multipler writers, except during snapshot generation, when it blocks new writers until the snapshot is generated. In general, you'll notice two sorts of logic around calls to vn_start_write(): a first set, where vn_start_write() is called once holding a vnode reference, is acquired, and then things continue as normal, with a final vn_finished_write() call at the end. In this situation, vnode locks are acquired after the vn_start_write() call, but vnode references are held before (since vn_start_write() takes a vnode so that it can find the file system). The other circumstance is where vnode locks may already be held, in which case a non-sleeping acquire is performed, since in effect this is a violation of lock order. If it fails, the vnode lock is released, the reference is acquired, and then the whole operation is restarted so that we can try again to acquire the vnode lock under circumstances where file system snapshot lock can be safely acquired. So basically, it has deadlock detection and recovery logic. The V_XSLEEP lock basically says "Sleep until the snapshot lock would be available, then return", which loops back so we can re-try the acquires. So according to the above, the file system snapshot lock is *before* the vnode locks in the lock order, although in practice we acquire in any order as long as it won't lead to deadlock (in which case we recover). The logic here is a little shaky in practice -- among other things, it looks like potentially the mount point could go away during the call to vn_start_write() once the vnode is released in the deadlock detection code, but in practice this probably never happens. Notice that the above is all couched in terms of a single file system, not stacking. This is probably because it was all written with UFS and not stacking in mind. Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [ANN] unionfs patchset-11 release
Hi Goto-san, From: Daichi GOTO Date: Tue, 25 Apr 2006 21:19:06 +0900 ::It is my pleasure and honor to announce the availability of ::the unionfs patchset-11. :: Heads Up: Above English text contains some Japanese text. :: If you are interested in translating the Japanese :: text into English, please do it and send it to me. How about this? =-- On creating a hardlink, due to VOP_GETWRITEMOUNT() called right after lookup(), if only files exist in the underlying filesystem, VOP_GETWRITEMOUNT() cannot be process on the vnode for the layer above. Thus creating hardlink fails. A complete fix is to change VOP_GETWRITEMOUNT() to create a shadowfile, but its not possible due to the fact that, locking status of vnode passed as argument to VOP_GETWRITEMOUNT() is not stable. In the current kernel code base, filesystems using vop_stdgetwritemount() simply aquire mount point vnode, thus using vnode for directory above seems to suffice and used for the current implementation. But this logic cannot be considered safe and may cause problems in the future. Also, when mounting a directory containing multiple mount points using unionfs, becomes evil. Thus, it is dangerous to mount directories containing multiple mount points, using the current implementation of unionfs. =-- Hope this helps, Haro =-- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Internet Solution Dept., KGT Inc. /|\ |_| |_|_| 2-8-8 Shinjuku Shinjuku-ku Tokyo 160-0022, Japan Tel: +81-3-3225-0767 Fax: +81-3-3225-0740 Email: haro-at-kgt.co.jp ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [ANN] unionfs patchset-11 release
On Tue, Apr 25, 2006 at 09:19:06PM +0900, Daichi GOTO wrote: > It is my pleasure and honor to announce the availability of > the unionfs patchset-11. > > Patchset-11: >For 7-current > http://people.freebsd.org/~daichi/unionfs/unionfs-p11.diff > >For 6.x > http://people.freebsd.org/~daichi/unionfs/unionfs6-p11.diff > >Changes in unionfs-p11.diff > - Changed a few implementations around the lock/unlock >mechanism. Because of this, you can use both the unionfs >and the nullfs together without LK_CANRECURSE. > - Fixed a bug that sometimes does not unlock if it cannot >create shadow file. I still get a panic immediately upon use: KDB: stack backtrace: vfs_badlock(cdef7540,ee22b9c4,c07a60e0,cdef7540,0) at vfs_badlock+0x76 assert_vop_locked(cdef7540,c0765a3d,220,cdef7540,d12ed380) at assert_vop_locked+0x60 VOP_OPEN_APV(c077acc0,ee22ba1c,d0456c28,0,c68a2510) at VOP_OPEN_APV+0x87 union_open(ee22ba74,c0765a3d,ee22bbfc,47ec,cdf1a690) at union_open+0xa2 VOP_OPEN_APV(c077b6a0,ee22ba74,c07a5f60,cdf1a690,1) at VOP_OPEN_APV+0x94 exec_check_permissions(ee22bba8,0,c073c75f,143,d1921000) at exec_check_permissions+0x107 kern_execve(c68a2510,ee22bc60,0,bfbfe910,bfbfea0c,e87b9000,e87b9000,e87b9038,e87b94e9,e87f9000,3fb17,4,39) at kern_execve+0x214 execve(c68a2510,ee22bd04,c,ee22bd38,3) at execve+0x52 syscall(3b,3b,3b,bfbfe90c,bfbfecc7) at syscall+0x163 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (59, FreeBSD ELF32, execve), eip = 0x280d493b, esp = 0xbfbfe37c, ebp = 0xbfbfe828 --- VOP_OPEN: 0xcdef7540 is not locked but should be db> show lockedvnods Locked vnodes 0xd0456bd0: tag ufs, type VREG usecount 1, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xcf9c1960 ref 0 pages 5 lock type ufs: EXCL (count 1) by thread 0xc68a2510 (pid 5593)#0 0xc053248e at lockmgr+0x573 #1 0xc059f9d4 at vop_stdlock+0x32 #2 0xc071541a at VOP_LOCK_APV+0x76 #3 0xc0681146 at ffs_lock+0x19 #4 0xc071541a at VOP_LOCK_APV+0x76 #5 0xc04ff967 at union_lock+0xda #6 0xc071541a at VOP_LOCK_APV+0x76 #7 0xc05b793a at vn_lock+0x67 #8 0xc05ab84b at vget+0x77 #9 0xc04fab14 at union_nodeget+0x682 #10 0xc04fd98a at union_lookup+0x5e6 #11 0xc0712034 at VOP_LOOKUP_APV+0x76 #12 0xc05a1588 at lookup+0x343 #13 0xc05a21f3 at namei+0x330 #14 0xc0522983 at kern_execve+0x1e4 #15 0xc05236ee at execve+0x52 #16 0xc06fc295 at syscall+0x163 #17 0xc06e5fdf at Xint0x80_syscall+0x1f ino 2805716, on dev da0s1e 0xcdf1a690: tag unionfs, type VREG usecount 1, writecount 0, refcount 1 mountedhere 0 flags (VV_TEXT) v_object 0xcf9544b0 ref 0 pages 5 lock type ufs: EXCL (count 1) by thread 0xc68a2510 (pid 5593)#0 0xc053248e at lockmgr+0x573 #1 0xc059f9d4 at vop_stdlock+0x32 #2 0xc071541a at VOP_LOCK_APV+0x76 #3 0xc0681146 at ffs_lock+0x19 #4 0xc071541a at VOP_LOCK_APV+0x76 #5 0xc04ff967 at union_lock+0xda #6 0xc071541a at VOP_LOCK_APV+0x76 #7 0xc05b793a at vn_lock+0x67 #8 0xc05ab84b at vget+0x77 #9 0xc04fab14 at union_nodeget+0x682 #10 0xc04fd98a at union_lookup+0x5e6 #11 0xc0712034 at VOP_LOOKUP_APV+0x76 #12 0xc05a1588 at lookup+0x343 #13 0xc05a21f3 at namei+0x330 #14 0xc0522983 at kern_execve+0x1e4 #15 0xc05236ee at execve+0x52 #16 0xc06fc295 at syscall+0x163 #17 0xc06e5fdf at Xint0x80_syscall+0x1f union_vp=0xcdf1a690, uppervp=0xd0456bd0, lowervp=0xcdef7540 union: upper 0xd0456bd0: tag ufs, type VREG usecount 1, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xcf9c1960 ref 0 pages 5 lock type ufs: EXCL (count 1) by thread 0xc68a2510 (pid 5593)#0 0xc053248e at lockmgr+0x573 #1 0xc059f9d4 at vop_stdlock+0x32 #2 0xc071541a at VOP_LOCK_APV+0x76 #3 0xc0681146 at ffs_lock+0x19 #4 0xc071541a at VOP_LOCK_APV+0x76 #5 0xc04ff967 at union_lock+0xda #6 0xc071541a at VOP_LOCK_APV+0x76 #7 0xc05b793a at vn_lock+0x67 #8 0xc05ab84b at vget+0x77 #9 0xc04fab14 at union_nodeget+0x682 #10 0xc04fd98a at union_lookup+0x5e6 #11 0xc0712034 at VOP_LOOKUP_APV+0x76 #12 0xc05a1588 at lookup+0x343 #13 0xc05a21f3 at namei+0x330 #14 0xc0522983 at kern_execve+0x1e4 #15 0xc05236ee at execve+0x52 #16 0xc06fc295 at syscall+0x163 #17 0xc06e5fdf at Xint0x80_syscall+0x1f ino 2805716, on dev da0s1e union: lower 0xcdef7540: tag null, type VREG usecount 1, writecount 0, refcount 1 mountedhere 0 flags () v_object 0xcf9544b0 ref 0 pages 5 #0 0xc053248e at lockmgr+0x573 #1 0xc059f9d4 at vop_stdlock+0x32 #2 0xc071541a at VOP_LOCK_APV+0x76 #3 0xc0681146 at ffs_lock+0x19 #4 0xc071541a at VOP_LOCK_APV+0x76 #5 0xc05b793a at vn_lock+0x67 #6 0xc05ab84b at vget+0x77 #7 0xc059c93c at cache_lookup+0xe7 #8 0xc059d28f at vfs_cache_lookup+0xad #9 0xc0712034 at VOP_LOOKUP_APV+0x76 #10 0xc04f50a1 at null_lookup+0x6c #11 0xc0712034 at VOP_LOOKUP_APV+0x76 #12 0xc04fd762 at union_lookup+0x3be #13 0xc0712034 at VOP_LOOKUP_APV+0x76 #14 0xc05a1588 at lookup+0x343 #15 0xc05a21f3 at namei+0x330 #16 0xc0522983 at kern_execve+0x1e4 #17 0xc05236ee at execve+0x52 vp=0
Re: [ANN] unionfs patchset-11 release
Kris Kennaway wrote: > I still get a panic immediately upon use: OKey. Maybe we fixed your panic. Please try attached file as /usr/src/sys/fs/unionfs/union_vnops.c :) -- Daichi GOTO, http://people.freebsd.org/~daichi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [ANN] unionfs patchset-11 release
Robert Watson wrote: If someone knows the details of vnode's lock status via VOP_GETWRITEMOUNT, Please teach us (daichi, ozawa). We want to know the details. Basically, file systems supporting full file system snapshots (UFS) Oh thanks rwatson! It is very useful. Thank you very much :) -- Daichi GOTO, http://people.freebsd.org/~daichi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [ANN] unionfs patchset-11 release
Munehiro Matsuda wrote: How about this? Great! I just updated site. Thanks Matsuda-san :) http://people.freebsd.org/~daichi/unionfs/ -- Daichi GOTO, http://people.freebsd.org/~daichi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [ANN] unionfs patchset-11 release
Fabian Keil wrote: Looks like the attachment was filtered. I got a different panic on FreeBSD TP51.local 6.1-RC FreeBSD 6.1-RC #22: Wed Apr 26 13:25:57 CEST 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: M... We tried as follow, but we could not get the same error :( It looks very fine. # cd /usr/ # mkdir hoge # mount_unionfs -c transparent -o noatime /usr/hoge /usr/src # cd src # find . -type f &; find . -type f &; find . -type f & # cd /usr/ # umount /usr/src # rm -r hoge # mkdir hoge # mount_unionfs -c transparent /usr/hoge /usr/src # cd src # find . -type f &; find . -type f &; find . -type f & What do you make of it? -- Daichi GOTO, http://people.freebsd.org/~daichi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [ANN] unionfs patchset-11 release
Daichi GOTO <[EMAIL PROTECTED]> wrote: > Fabian Keil wrote: > > Looks like the attachment was filtered. > > > > I got a different panic on > > FreeBSD TP51.local 6.1-RC FreeBSD 6.1-RC #22: Wed Apr 26 13:25:57 CEST 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: > > M... > > We tried as follow, but we could not get the same error :( > It looks very fine. > > # cd /usr/ > # mkdir hoge > # mount_unionfs -c transparent -o noatime /usr/hoge /usr/src > # cd src > # find . -type f &; find . -type f &; find . -type f & > # cd /usr/ > # umount /usr/src > # rm -r hoge > # mkdir hoge > # mount_unionfs -c transparent /usr/hoge /usr/src > # cd src > # find . -type f &; find . -type f &; find . -type f & > > What do you make of it? I didn't give you enough information, sorry. What I'm doing is: [EMAIL PROTECTED] ~ $mkdir /tmp/unionfs-src/ [EMAIL PROTECTED] ~ $mount_unionfs /tmp/unionfs-src /usr/src [EMAIL PROTECTED] ~ $cd /usr/src [EMAIL PROTECTED] /usr/src $patch -p1 < ~/test/combi.patch [EMAIL PROTECTED] /usr/src $find /tmp/unionfs-src/ -type f [Panic] ~/test/combi.patch changes about twenty files. I'm not sure if it's important, but /usr was mounted readonly and /tmp is a different file system. My kernel has options WITNESS enabled. 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. 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. Fabian -- http://www.fabiankeil.de/ signature.asc Description: PGP signature
Re: [ANN] unionfs patchset-11 release
Fabian Keil <[EMAIL PROTECTED]> wrote:
> Daichi GOTO <[EMAIL PROTECTED]> wrote:
>
> > 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 CEST
> > > 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:
> > We tried as follow, but we could not get the same error :(
> > It looks very fine.
> I didn't give you enough information, sorry.
>
> What I'm doing is:
>
> [EMAIL PROTECTED] ~ $mkdir /tmp/unionfs-src/
> [EMAIL PROTECTED] ~ $mount_unionfs /tmp/unionfs-src /usr/src
> [EMAIL PROTECTED] ~ $cd /usr/src
> [EMAIL PROTECTED] /usr/src $patch -p1 < ~/test/combi.patch
> [EMAIL PROTECTED] /usr/src $find /tmp/unionfs-src/ -type f
> [Panic]
>
> ~/test/combi.patch changes about twenty files.
>
> I'm not sure if it's important, but /usr was mounted
> readonly and /tmp is a different file system.
>
> My kernel has options WITNESS enabled.
>
> 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.
>
> 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 != 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
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
exclusive sleep mutex Softdep Lock r = 0 (0xc07839c0) locked @
/usr/src/sys/ufs/ffs/ffs_softdep.c:3730
exclusive sleep mutex Giant r = 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=260) at /usr/src/sys/kern/kern_shutdown.c:402
#2 0xc054ab27 in panic (fmt=0xc06c9423 "from debugger") at
/usr/src/sys/kern/kern_shutdown.c:558
#3 0xc047f523 in db_panic (addr=-1068086451, have_addr=0, count=-1,
modif=0xd564b8d8 "") at /usr/src/sys/ddb/db_command.c:438
#4 0xc047f49c in db_command (last_cmdp=0xc072b3e4, cmd_table=0x0,
aux_cmd_tablep=0xc06f28c4, aux_cmd_tablep_end=0xc06f28c8)
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=3, code=0) at /usr/src/sys/ddb/db_main.c:221
#7 0xc0564dd7 in kdb_trap (type=0, code=0, tf=0xd564ba24) at
/usr/src/sys/kern/subr_kdb.c:473
#8 0xc069e4d2 in trap (frame=
{tf_fs = -1066532856, tf_es = 40, tf_ds = -714866648, tf_edi = 1, tf_esi
= -1066511478, tf_ebp = -714818964, tf_isp = -714818992, tf_ebx = -714818908,
tf_edx = 0, tf_ecx = -1056878592, tf_eax = 18, tf_trapno = 3, tf_err = 0,
tf_eip = -1068086451, tf_cs = 32, tf_eflags = 642, tf_esp = -1066558175, tf_ss
= -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=0x12 ) at
cpufunc.h:60
#11 0xc054aabf in panic (fmt=0xc06e538a "%s: dir inum %d != new %d") at
/usr/src/sys/kern/kern_shutdown.c:542
#12 0xc0634021 in initiate_write_filepage (pagedep=0xc354bc00, bp=0xcd838268)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:3834
#13 0xc0633d1c in softdep_disk_io_initiation (bp=0xcd838268) at
/usr/src/sys/ufs/ffs/ffs_softdep.c:3740
#14 0xc063c8c4 in ffs_geom_strategy (bo=0xc358aa50, bp=0xcd838268) at buf.h:422
#15 0xc0648db7 in ufs_strategy (ap=0x12) at
/usr/src/sys/ufs/ufs/ufs_vnops.c:1942
#16 0xc06b47c8 in VOP_STRATEGY_APV (vop=0xc0719380, a=0xd564bb68) at
vnode_if.c:1796
#17 0xc059965c in bufstrategy (bo=0xc393a940, bp=0x12) at vnode_if.h:928
#18 0xc05946e6 in bufwrite (bp=0xcd838268) at buf.h:415
#19 0xc0594c31 in bawrite (bp=0x12) at buf.h:399
#20 0xc063cb82 in ffs_syncvnode (vp=0xc393a880, waitfor=3) at
/usr/src/sys/ufs/ffs/ffs_vnops.c:256
#21 0xc063b753 in ffs_sync
Re: [ANN] unionfs patchset-11 release
Fabian Keil <[EMAIL PROTECTED]> wrote: > Fabian Keil <[EMAIL PROTECTED]> wrote: > > > Daichi GOTO <[EMAIL PROTECTED]> wrote: > > > > > Fabian Keil wrote: > > What I'm doing is: > > > > [EMAIL PROTECTED] ~ $mkdir /tmp/unionfs-src/ > > [EMAIL PROTECTED] ~ $mount_unionfs /tmp/unionfs-src /usr/src > > [EMAIL PROTECTED] ~ $cd /usr/src > > [EMAIL PROTECTED] /usr/src $patch -p1 < ~/test/combi.patch > > [EMAIL PROTECTED] /usr/src $find /tmp/unionfs-src/ -type f > > [Panic] > > > > ~/test/combi.patch changes about twenty files. Not exactly: [EMAIL PROTECTED] ~ $grep +++ ~/test/combi.patch | wc -l 38 > > I'm not sure if it's important, but /usr was mounted > > readonly and /tmp is a different file system. I got the same panic with /usr mounted rewritable and both directories on the same file system this time. Running patch -p1 < ~/test/combi.patch seems to be enough to trigger the panic. I tried three runs with a smaller patch (unionfs6-p11.diff) without panic, I then took the bigger patch again and a few seconds later the system panicked. > 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. I'm not sure anymore if I used the same patch the first times. Fabian -- http://www.fabiankeil.de/ signature.asc Description: PGP signature
