Re: SUJ update - new panic - "ffs_copyonwrite: recursive call"
Hi Jeff > I checked in a fix for this at revision 207742. If you can verify that it > works for you it would be appreciated. Sorry for long delay, finally, I've updated to recent sources, looks like no more such panics so far. Will test under more load. > Thanks! > Jeff -- Vladimir B. Grebenschikov v...@fbsd.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update
On Thu, Apr 29, 2010 at 06:37:00PM -1000, Jeff Roberson wrote: > Hello, > > I fixed a few SUJ bugs. If those of you who reported one of the > following bugs could re-test I would greatly appreciate it. > I've noticed that when trying to enable a feature on a mounted filesystem tunefs gives a bogus warning about fsck not having been run because the fs_clean flag is 0. Could we fix the warning so it mentions not being able to run it on a mounted filesystem too? -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update - new panic - "ffs_copyonwrite: recursive call"
On Sun, 2 May 2010, Vladimir Grebenschikov wrote: Hi While 'make buildworld' kgdb /boot/kernel/kernel /var/crash/vmcore.13 GNU gdb 6.1.1 [FreeBSD] Hi Vladimir, I checked in a fix for this at revision 207742. If you can verify that it works for you it would be appreciated. Thanks! Jeff ... #0 0xc056b93c in doadump () (kgdb) bt #0 0xc056b93c in doadump () #1 0xc0489019 in db_fncall () #2 0xc0489411 in db_command () #3 0xc048956a in db_command_loop () #4 0xc048b3ed in db_trap () #5 0xc05985a4 in kdb_trap () #6 0xc06f8b5e in trap () #7 0xc06dd6eb in calltrap () #8 0xc059870a in kdb_enter () #9 0xc056c1d1 in panic () #10 0xc066d602 in ffs_copyonwrite () #11 0xc068742a in ffs_geom_strategy () #12 0xc05d8955 in bufwrite () #13 0xc0686e64 in ffs_bufwrite () #14 0xc067a8a2 in softdep_sync_metadata () #15 0xc068c568 in ffs_syncvnode () #16 0xc0681425 in softdep_prealloc () #17 0xc066592a in ffs_balloc_ufs2 () #18 0xc066a252 in ffs_snapblkfree () #19 0xc065eb9a in ffs_blkfree () #20 0xc0673de0 in freework_freeblock () #21 0xc06797c7 in handle_workitem_freeblocks () #22 0xc0679aaf in process_worklist_item () #23 0xc06821f4 in softdep_process_worklist () #24 0xc0682940 in softdep_flush () #25 0xc0542a00 in fork_exit () #26 0xc06dd760 in fork_trampoline () (kgdb) x/s panicstr 0xc07c2b80: "ffs_copyonwrite: recursive call" (kgdb) -- Vladimir B. Grebenschikov v...@fbsd.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update
On Mon, 3 May 2010, Ed Maste wrote: On Mon, May 03, 2010 at 04:32:37PM -0700, Doug Barton wrote: I also don't want to bikeshed this to death. I imagine that once the feature is stable that users will just twiddle it once and then leave it alone, or it will be set at install time and then not twiddled at all. :) Speaking of which, is there any reason for us not to support enabling SU+J at newfs time? (Other than just needing a clean way to share the code between tunefs and newfs.) The code is actually totally different between the two so it'll essentially have to be rewritten in newfs. tunefs uses libufs and some of the code for manipulating directories that was added to tunefs needs to be moved back into libufs and made more general. However, newfs doesn't use libufs anyway. So it'd have to be converted or you'd just have to re-write journal creation. For now, I think an extra step in the installer is probably easier. Thanks, Jeff -Ed ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update
On Mon, May 03, 2010 at 04:32:37PM -0700, Doug Barton wrote: > I also don't want to bikeshed this to death. I imagine that once the > feature is stable that users will just twiddle it once and then leave it > alone, or it will be set at install time and then not twiddled at all. :) Speaking of which, is there any reason for us not to support enabling SU+J at newfs time? (Other than just needing a clean way to share the code between tunefs and newfs.) -Ed ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update
On 05/03/10 06:19, sth...@nethelp.no wrote: I would vote for decoupling. If I have SU on, then enable journaling, then disable journaling, I would expect SU to still be on. >>> >>> Fully agreed. I see no reason why these sould be coupled. >> >> It does not look like it is a prerequisite to have SU enabled when you >> want to enable SUJ. So I assume SUJ implies SU, and as such I think >> you can agree that it is not easy to determine at disable time of SUJ, >> if the FS was SU before or not. > > If SUJ requires SU then IMHO tunefs should prohibit setting SUJ unless > SU was already enabled, with a nice explanatory error message if needed. I agree, although I think it should be possible to specify both on the same command line. At that point however the user would know what they did, so they should be able to undo it appropriately. I also don't want to bikeshed this to death. I imagine that once the feature is stable that users will just twiddle it once and then leave it alone, or it will be set at install time and then not twiddled at all. :) > Looking at it from a slightly different angle - assume I have a file > system with SU enabled, and I want to experiment with SUJ. So I enable > SUJ. When I'm finished testing, maybe I want to disable SUJ again. I > would be *highly surprised* (badly breaking POLA) if SU was disabled > at the same time. > >> So whatever the consensus is (disabling SUJ does or dosn't enable SU), >> the man page needs to tell what it does. > > Agreed. > > Steinar Haug, Nethelp consulting, sth...@nethelp.no > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update
> >> I would vote for decoupling. If I have SU on, then enable journaling, > >> then disable journaling, I would expect SU to still be on. > > > > Fully agreed. I see no reason why these sould be coupled. > > It does not look like it is a prerequisite to have SU enabled when you > want to enable SUJ. So I assume SUJ implies SU, and as such I think > you can agree that it is not easy to determine at disable time of SUJ, > if the FS was SU before or not. If SUJ requires SU then IMHO tunefs should prohibit setting SUJ unless SU was already enabled, with a nice explanatory error message if needed. Looking at it from a slightly different angle - assume I have a file system with SU enabled, and I want to experiment with SUJ. So I enable SUJ. When I'm finished testing, maybe I want to disable SUJ again. I would be *highly surprised* (badly breaking POLA) if SU was disabled at the same time. > So whatever the consensus is (disabling SUJ does or dosn't enable SU), > the man page needs to tell what it does. Agreed. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update
On May 3, 2010, at 8:04 AM, Alexander Leidinger wrote: > Quoting sth...@nethelp.no (from Sun, 02 May 2010 07:38:57 +0200 (CEST)): > >>> > When you disable journaling it also disables soft-updates. You need to >>> > re-enable it. I could decouple this. It's hard to say which is the POLA. >>> >>> I would vote for decoupling. If I have SU on, then enable journaling, >>> then disable journaling, I would expect SU to still be on. >> >> Fully agreed. I see no reason why these sould be coupled. > > It does not look like it is a prerequisite to have SU enabled when you want > to enable SUJ. So I assume SUJ implies SU, and as such I think you can agree > that it is not easy to determine at disable time of SUJ, if the FS was SU > before or not. How about returning an error message instead of implicitly enabling SU with journaling? Something like "Soft updates must be in use for journaling to be enabled. Please see the -n option." That would keep the actions independent for both enabling and disabling. Just an idea. (Not trying to bike shed...) - Ben___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update
Quoting sth...@nethelp.no (from Sun, 02 May 2010 07:38:57 +0200 (CEST)): > When you disable journaling it also disables soft-updates. You need to > re-enable it. I could decouple this. It's hard to say which is the POLA. I would vote for decoupling. If I have SU on, then enable journaling, then disable journaling, I would expect SU to still be on. Fully agreed. I see no reason why these sould be coupled. It does not look like it is a prerequisite to have SU enabled when you want to enable SUJ. So I assume SUJ implies SU, and as such I think you can agree that it is not easy to determine at disable time of SUJ, if the FS was SU before or not. There may be not much people which run UFS without SU, but for those which do, I'm sure it would be a surprise if they disable SUJ and do not get back to plain UFS without SU. So whatever the consensus is (disabling SUJ does or dosn't enable SU), the man page needs to tell what it does. Bye, Alexander. -- Why you say you no bunny rabbit when you have little powder-puff tail? -- The Tasmanian Devil http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update
I've rev 207213 installed, i will update. > On Sun, 2 May 2010, Fabien Thomas wrote: > >> Hi Jeff, >> >> Before sending the 'bad' part i would like to say that it is very useful and >> save me a lot of time after a crash. >> >> I've updated the ports and there was no more space on the FS. >> It end up with this backtrace (After one reboot the kernel crashed a second >> time with the same backtrace): > > When did you update? I fixed a bug that looked just like this a day or two > ago. > > Thanks, > Jeff > >> >> (kgdb) bt >> #0 doadump () at >> /usr/home/fabient/fabient-sandbox/sys/kern/kern_shutdown.c:245 >> #1 0xc0a1a8fe in boot (howto=260) at >> /usr/home/fabient/fabient-sandbox/sys/kern/kern_shutdown.c:416 >> #2 0xc0a1ad4c in panic (fmt=Could not find the frame base for "panic". >> ) at /usr/home/fabient/fabient-sandbox/sys/kern/kern_shutdown.c:590 >> #3 0xc0d058b3 in remove_from_journal (wk=0xc4b4aa80) at >> /usr/home/fabient/fabient-sandbox/sys/ufs/ffs/ffs_softdep.c:2204 >> #4 0xc0d07ebb in cancel_jaddref (jaddref=0xc4b4aa80, inodedep=0xc46bed00, >> wkhd=0xc46bed5c) >> at /usr/home/fabient/fabient-sandbox/sys/ufs/ffs/ffs_softdep.c:3336 >> #5 0xc0d09401 in softdep_revert_mkdir (dp=0xc46ba6cc, ip=0xc4bba244) >> at /usr/home/fabient/fabient-sandbox/sys/ufs/ffs/ffs_softdep.c:3898 >> #6 0xc0d37c49 in ufs_mkdir (ap=0xc8510b2c) at >> /usr/home/fabient/fabient-sandbox/sys/ufs/ufs/ufs_vnops.c:1973 >> #7 0xc0e7bc6e in VOP_MKDIR_APV (vop=0xc1085ea0, a=0xc8510b2c) at >> vnode_if.c:1534 >> #8 0xc0add64a in VOP_MKDIR (dvp=0xc485e990, vpp=0xc8510bec, cnp=0xc8510c00, >> vap=0xc8510b6c) at vnode_if.h:665 >> #9 0xc0add58f in kern_mkdirat (td=0xc4649720, fd=-100, path=0x804e9a0 >> , >> segflg=UIO_USERSPACE, mode=448) at >> /usr/home/fabient/fabient-sandbox/sys/kern/vfs_syscalls.c:3783 >> #10 0xc0add2fe in kern_mkdir (td=0xc4649720, path=0x804e9a0 > 0x804e9a0 out of bounds>, segflg=UIO_USERSPACE, mode=448) >> at /usr/home/fabient/fabient-sandbox/sys/kern/vfs_syscalls.c:3727 >> #11 0xc0add289 in mkdir (td=0xc4649720, uap=0x0) at >> /usr/home/fabient/fabient-sandbox/sys/kern/vfs_syscalls.c:3706 >> #12 0xc0e5324b in syscall (frame=0xc8510d38) at >> /usr/home/fabient/fabient-sandbox/sys/i386/i386/trap.c:1116 >> #13 0xc0e2b3c0 in Xint0x80_syscall () at >> /usr/home/fabient/fabient-sandbox/sys/i386/i386/exception.s:261 >> #14 0x0033 in ?? () >> Previous frame inner to this frame (corrupt stack?) >> (kgdb) >> >> Regards, >> Fabien >> >> >>> Hello, >>> >>> I fixed a few SUJ bugs. If those of you who reported one of the following >>> bugs could re-test I would greatly appreciate it. >>> >>> 1) panic on gnome start via softdep_cancel_link(). >>> 2) Difficulty setting flags on /. This can only be done from a direct >>> boot into single user but there were problems with tunefs that could lead >>> to the kernel and disk becoming out of sync with filesystem state. >>> 3) Kernel compiles without SOFTUPDATES defined in the config now work. >>> >>> I have had some reports of a hang waiting on journal space with certain >>> types of activity. I have only had this reported twice and I am not able >>> to reproduce no matter how much load I throw at the machine. If you >>> reproduce this please try to get a coredump or minidump. >>> >>> Thanks, >>> Jeff >>> ___ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" >> ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update - new panic - "ffs_copyonwrite: recursive call"
On Sun, 2 May 2010, Vladimir Grebenschikov wrote: Hi While 'make buildworld' This is a problem with snapshots and the journal full condition. I will address it shortly. Thanks, Jeff kgdb /boot/kernel/kernel /var/crash/vmcore.13 GNU gdb 6.1.1 [FreeBSD] ... #0 0xc056b93c in doadump () (kgdb) bt #0 0xc056b93c in doadump () #1 0xc0489019 in db_fncall () #2 0xc0489411 in db_command () #3 0xc048956a in db_command_loop () #4 0xc048b3ed in db_trap () #5 0xc05985a4 in kdb_trap () #6 0xc06f8b5e in trap () #7 0xc06dd6eb in calltrap () #8 0xc059870a in kdb_enter () #9 0xc056c1d1 in panic () #10 0xc066d602 in ffs_copyonwrite () #11 0xc068742a in ffs_geom_strategy () #12 0xc05d8955 in bufwrite () #13 0xc0686e64 in ffs_bufwrite () #14 0xc067a8a2 in softdep_sync_metadata () #15 0xc068c568 in ffs_syncvnode () #16 0xc0681425 in softdep_prealloc () #17 0xc066592a in ffs_balloc_ufs2 () #18 0xc066a252 in ffs_snapblkfree () #19 0xc065eb9a in ffs_blkfree () #20 0xc0673de0 in freework_freeblock () #21 0xc06797c7 in handle_workitem_freeblocks () #22 0xc0679aaf in process_worklist_item () #23 0xc06821f4 in softdep_process_worklist () #24 0xc0682940 in softdep_flush () #25 0xc0542a00 in fork_exit () #26 0xc06dd760 in fork_trampoline () (kgdb) x/s panicstr 0xc07c2b80: "ffs_copyonwrite: recursive call" (kgdb) -- Vladimir B. Grebenschikov v...@fbsd.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update
On Sun, 2 May 2010, Fabien Thomas wrote: Hi Jeff, Before sending the 'bad' part i would like to say that it is very useful and save me a lot of time after a crash. I've updated the ports and there was no more space on the FS. It end up with this backtrace (After one reboot the kernel crashed a second time with the same backtrace): When did you update? I fixed a bug that looked just like this a day or two ago. Thanks, Jeff (kgdb) bt #0 doadump () at /usr/home/fabient/fabient-sandbox/sys/kern/kern_shutdown.c:245 #1 0xc0a1a8fe in boot (howto=260) at /usr/home/fabient/fabient-sandbox/sys/kern/kern_shutdown.c:416 #2 0xc0a1ad4c in panic (fmt=Could not find the frame base for "panic". ) at /usr/home/fabient/fabient-sandbox/sys/kern/kern_shutdown.c:590 #3 0xc0d058b3 in remove_from_journal (wk=0xc4b4aa80) at /usr/home/fabient/fabient-sandbox/sys/ufs/ffs/ffs_softdep.c:2204 #4 0xc0d07ebb in cancel_jaddref (jaddref=0xc4b4aa80, inodedep=0xc46bed00, wkhd=0xc46bed5c) at /usr/home/fabient/fabient-sandbox/sys/ufs/ffs/ffs_softdep.c:3336 #5 0xc0d09401 in softdep_revert_mkdir (dp=0xc46ba6cc, ip=0xc4bba244) at /usr/home/fabient/fabient-sandbox/sys/ufs/ffs/ffs_softdep.c:3898 #6 0xc0d37c49 in ufs_mkdir (ap=0xc8510b2c) at /usr/home/fabient/fabient-sandbox/sys/ufs/ufs/ufs_vnops.c:1973 #7 0xc0e7bc6e in VOP_MKDIR_APV (vop=0xc1085ea0, a=0xc8510b2c) at vnode_if.c:1534 #8 0xc0add64a in VOP_MKDIR (dvp=0xc485e990, vpp=0xc8510bec, cnp=0xc8510c00, vap=0xc8510b6c) at vnode_if.h:665 #9 0xc0add58f in kern_mkdirat (td=0xc4649720, fd=-100, path=0x804e9a0 , segflg=UIO_USERSPACE, mode=448) at /usr/home/fabient/fabient-sandbox/sys/kern/vfs_syscalls.c:3783 #10 0xc0add2fe in kern_mkdir (td=0xc4649720, path=0x804e9a0 , segflg=UIO_USERSPACE, mode=448) at /usr/home/fabient/fabient-sandbox/sys/kern/vfs_syscalls.c:3727 #11 0xc0add289 in mkdir (td=0xc4649720, uap=0x0) at /usr/home/fabient/fabient-sandbox/sys/kern/vfs_syscalls.c:3706 #12 0xc0e5324b in syscall (frame=0xc8510d38) at /usr/home/fabient/fabient-sandbox/sys/i386/i386/trap.c:1116 #13 0xc0e2b3c0 in Xint0x80_syscall () at /usr/home/fabient/fabient-sandbox/sys/i386/i386/exception.s:261 #14 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Regards, Fabien Hello, I fixed a few SUJ bugs. If those of you who reported one of the following bugs could re-test I would greatly appreciate it. 1) panic on gnome start via softdep_cancel_link(). 2) Difficulty setting flags on /. This can only be done from a direct boot into single user but there were problems with tunefs that could lead to the kernel and disk becoming out of sync with filesystem state. 3) Kernel compiles without SOFTUPDATES defined in the config now work. I have had some reports of a hang waiting on journal space with certain types of activity. I have only had this reported twice and I am not able to reproduce no matter how much load I throw at the machine. If you reproduce this please try to get a coredump or minidump. Thanks, Jeff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update
Hi Jeff, Before sending the 'bad' part i would like to say that it is very useful and save me a lot of time after a crash. I've updated the ports and there was no more space on the FS. It end up with this backtrace (After one reboot the kernel crashed a second time with the same backtrace): (kgdb) bt #0 doadump () at /usr/home/fabient/fabient-sandbox/sys/kern/kern_shutdown.c:245 #1 0xc0a1a8fe in boot (howto=260) at /usr/home/fabient/fabient-sandbox/sys/kern/kern_shutdown.c:416 #2 0xc0a1ad4c in panic (fmt=Could not find the frame base for "panic". ) at /usr/home/fabient/fabient-sandbox/sys/kern/kern_shutdown.c:590 #3 0xc0d058b3 in remove_from_journal (wk=0xc4b4aa80) at /usr/home/fabient/fabient-sandbox/sys/ufs/ffs/ffs_softdep.c:2204 #4 0xc0d07ebb in cancel_jaddref (jaddref=0xc4b4aa80, inodedep=0xc46bed00, wkhd=0xc46bed5c) at /usr/home/fabient/fabient-sandbox/sys/ufs/ffs/ffs_softdep.c:3336 #5 0xc0d09401 in softdep_revert_mkdir (dp=0xc46ba6cc, ip=0xc4bba244) at /usr/home/fabient/fabient-sandbox/sys/ufs/ffs/ffs_softdep.c:3898 #6 0xc0d37c49 in ufs_mkdir (ap=0xc8510b2c) at /usr/home/fabient/fabient-sandbox/sys/ufs/ufs/ufs_vnops.c:1973 #7 0xc0e7bc6e in VOP_MKDIR_APV (vop=0xc1085ea0, a=0xc8510b2c) at vnode_if.c:1534 #8 0xc0add64a in VOP_MKDIR (dvp=0xc485e990, vpp=0xc8510bec, cnp=0xc8510c00, vap=0xc8510b6c) at vnode_if.h:665 #9 0xc0add58f in kern_mkdirat (td=0xc4649720, fd=-100, path=0x804e9a0 , segflg=UIO_USERSPACE, mode=448) at /usr/home/fabient/fabient-sandbox/sys/kern/vfs_syscalls.c:3783 #10 0xc0add2fe in kern_mkdir (td=0xc4649720, path=0x804e9a0 , segflg=UIO_USERSPACE, mode=448) at /usr/home/fabient/fabient-sandbox/sys/kern/vfs_syscalls.c:3727 #11 0xc0add289 in mkdir (td=0xc4649720, uap=0x0) at /usr/home/fabient/fabient-sandbox/sys/kern/vfs_syscalls.c:3706 #12 0xc0e5324b in syscall (frame=0xc8510d38) at /usr/home/fabient/fabient-sandbox/sys/i386/i386/trap.c:1116 #13 0xc0e2b3c0 in Xint0x80_syscall () at /usr/home/fabient/fabient-sandbox/sys/i386/i386/exception.s:261 #14 0x0033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Regards, Fabien > Hello, > > I fixed a few SUJ bugs. If those of you who reported one of the following > bugs could re-test I would greatly appreciate it. > > 1) panic on gnome start via softdep_cancel_link(). > 2) Difficulty setting flags on /. This can only be done from a direct boot > into single user but there were problems with tunefs that could lead to the > kernel and disk becoming out of sync with filesystem state. > 3) Kernel compiles without SOFTUPDATES defined in the config now work. > > I have had some reports of a hang waiting on journal space with certain types > of activity. I have only had this reported twice and I am not able to > reproduce no matter how much load I throw at the machine. If you reproduce > this please try to get a coredump or minidump. > > Thanks, > Jeff > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update - new panic - "ffs_copyonwrite: recursive call"
Hi While 'make buildworld' kgdb /boot/kernel/kernel /var/crash/vmcore.13 GNU gdb 6.1.1 [FreeBSD] ... #0 0xc056b93c in doadump () (kgdb) bt #0 0xc056b93c in doadump () #1 0xc0489019 in db_fncall () #2 0xc0489411 in db_command () #3 0xc048956a in db_command_loop () #4 0xc048b3ed in db_trap () #5 0xc05985a4 in kdb_trap () #6 0xc06f8b5e in trap () #7 0xc06dd6eb in calltrap () #8 0xc059870a in kdb_enter () #9 0xc056c1d1 in panic () #10 0xc066d602 in ffs_copyonwrite () #11 0xc068742a in ffs_geom_strategy () #12 0xc05d8955 in bufwrite () #13 0xc0686e64 in ffs_bufwrite () #14 0xc067a8a2 in softdep_sync_metadata () #15 0xc068c568 in ffs_syncvnode () #16 0xc0681425 in softdep_prealloc () #17 0xc066592a in ffs_balloc_ufs2 () #18 0xc066a252 in ffs_snapblkfree () #19 0xc065eb9a in ffs_blkfree () #20 0xc0673de0 in freework_freeblock () #21 0xc06797c7 in handle_workitem_freeblocks () #22 0xc0679aaf in process_worklist_item () #23 0xc06821f4 in softdep_process_worklist () #24 0xc0682940 in softdep_flush () #25 0xc0542a00 in fork_exit () #26 0xc06dd760 in fork_trampoline () (kgdb) x/s panicstr 0xc07c2b80: "ffs_copyonwrite: recursive call" (kgdb) -- Vladimir B. Grebenschikov v...@fbsd.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update
> > When you disable journaling it also disables soft-updates. You need to > > re-enable it. I could decouple this. It's hard to say which is the POLA. > > I would vote for decoupling. If I have SU on, then enable journaling, > then disable journaling, I would expect SU to still be on. Fully agreed. I see no reason why these sould be coupled. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update
On 05/01/10 18:10, Jeff Roberson wrote: > When you disable journaling it also disables soft-updates. You need to > re-enable it. I could decouple this. It's hard to say which is the POLA. I would vote for decoupling. If I have SU on, then enable journaling, then disable journaling, I would expect SU to still be on. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update
On Sunday 02 May 2010 02:16:35 Alan Cox wrote: > Are you running an up to date kernel, specifically, one from today? If > not, please update. Kip committed some fixes throughout the day > yesterday. I was running a kernel from Friday - I've now updated to the latest sources and the panic has disappeared. -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update
On Sat, May 1, 2010 at 5:21 PM, Bruce Cran wrote: > On Thu, Apr 29, 2010 at 06:37:00PM -1000, Jeff Roberson wrote: > > > I fixed a few SUJ bugs. If those of you who reported one of the > > following bugs could re-test I would greatly appreciate it. > > > > I've started seeing a panic "Sleeping thread owns a non-sleepable lock", > though it seems to be occurring both with and without journaling. The > back trace when journaling is disabled is: > > sched_switch > mi_switch > sleepq_wait > _sleep > bwait > bufwait > bufwrite > ffs_balloc_ufs2 > ffs_write > VOP_WRITE_APV > vnode_pager_generic_putpages > VOP_PUTPAGES > vnode_pager_putpages > vm_pageout_flush > vm_object_page_collect_flush > vm_object_page_clean > vfs_msync > sync_fsync > VOP_FSYNC_APV > sync_vnode > sched_sync > fork_exit > fork_trampoline > > I've also noticed that since disabling journaling a full fsck seems to > be occurring on boot; background fsck seems to have been disabled. > > Are you running an up to date kernel, specifically, one from today? If not, please update. Kip committed some fixes throughout the day yesterday. Regards, Alan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update
On Sat, 1 May 2010, Bruce Cran wrote: On Thu, Apr 29, 2010 at 06:37:00PM -1000, Jeff Roberson wrote: I fixed a few SUJ bugs. If those of you who reported one of the following bugs could re-test I would greatly appreciate it. I've started seeing a panic "Sleeping thread owns a non-sleepable lock", though it seems to be occurring both with and without journaling. The back trace when journaling is disabled is: Can you tell me what the lock is? This may be related to recent vm work which went in at the same time. sched_switch mi_switch sleepq_wait _sleep bwait bufwait bufwrite ffs_balloc_ufs2 ffs_write VOP_WRITE_APV vnode_pager_generic_putpages VOP_PUTPAGES vnode_pager_putpages vm_pageout_flush vm_object_page_collect_flush vm_object_page_clean vfs_msync sync_fsync VOP_FSYNC_APV sync_vnode sched_sync fork_exit fork_trampoline I've also noticed that since disabling journaling a full fsck seems to be occurring on boot; background fsck seems to have been disabled. When you disable journaling it also disables soft-updates. You need to re-enable it. I could decouple this. It's hard to say which is the POLA. Thanks, Jeff -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update
On Thu, Apr 29, 2010 at 06:37:00PM -1000, Jeff Roberson wrote: > I fixed a few SUJ bugs. If those of you who reported one of the > following bugs could re-test I would greatly appreciate it. > I've started seeing a panic "Sleeping thread owns a non-sleepable lock", though it seems to be occurring both with and without journaling. The back trace when journaling is disabled is: sched_switch mi_switch sleepq_wait _sleep bwait bufwait bufwrite ffs_balloc_ufs2 ffs_write VOP_WRITE_APV vnode_pager_generic_putpages VOP_PUTPAGES vnode_pager_putpages vm_pageout_flush vm_object_page_collect_flush vm_object_page_clean vfs_msync sync_fsync VOP_FSYNC_APV sync_vnode sched_sync fork_exit fork_trampoline I've also noticed that since disabling journaling a full fsck seems to be occurring on boot; background fsck seems to have been disabled. -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update
Hi > > Ehh, looks like fresh kernel is not too stable, it holds after some time > > of activity. > > > > DDB may be activated, but even 'call cpu_reset' does nothing here. > > > > Looks like it is not related to SUJ, it happens even with SUJ disabled. > Does reverting r207410 + r207412 help ? No, it does not helps, even without this revs system locks hard time-to-time, usually under heavy load (CPU + Disk). For example 'portupgrade -f cups\*' usually makes system to lock. Few times I had working DDB while such lockup, but did not see there anything suspicious. Ideas will be very appreciated. I have SMP i386 system. -- Vladimir B. Grebenschikov v...@fbsd.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update
just a little request # tunefs usage: tunefs [-A] [-a enable | disable] [-e maxbpg] [-f avgfilesize] [-J enable | disable ] [-L volname] [-l enable | disable] [-m minfree] [-N enable | disable] [-n enable | disable] [-o space | time] [-p] [-s avgfpdir] special | filesystem -j is not showing --Buganini ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update
Hi 1h - flight ok -Original Message- From: Kostik Belousov To: Vladimir Grebenschikov Cc: Jeff Roberson , curr...@freebsd.org Subject: Re: SUJ update Date: Fri, 30 Apr 2010 13:49:34 +0300 On Fri, Apr 30, 2010 at 02:43:49PM +0400, Vladimir Grebenschikov wrote: > Hi > > Ehh, looks like fresh kernel is not too stable, it holds after some time > of activity. > > DDB may be activated, but even 'call cpu_reset' does nothing here. > > Looks like it is not related to SUJ, it happens even with SUJ disabled. Does reverting r207410 + r207412 help ? > > > -Original Message- > From: Vladimir Grebenschikov > Reply-to: v...@fbsd.ru > To: Jeff Roberson > Cc: curr...@freebsd.org > Subject: Re: SUJ update > Date: Fri, 30 Apr 2010 13:36:10 +0400 > > Hi > > 1) now works for me (no panics so far) > > -Original Message- > From: Jeff Roberson > To: curr...@freebsd.org > Subject: SUJ update > Date: Thu, 29 Apr 2010 18:37:00 -1000 (HST) > > Hello, > > I fixed a few SUJ bugs. If those of you who reported one of the following > bugs could re-test I would greatly appreciate it. > > 1) panic on gnome start via softdep_cancel_link(). > 2) Difficulty setting flags on /. This can only be done from a direct > boot into single user but there were problems with tunefs that could lead > to the kernel and disk becoming out of sync with filesystem state. > 3) Kernel compiles without SOFTUPDATES defined in the config now work. > > I have had some reports of a hang waiting on journal space with certain > types of activity. I have only had this reported twice and I am not able > to reproduce no matter how much load I throw at the machine. If you > reproduce this please try to get a coredump or minidump. > > Thanks, > Jeff > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > > -- > Vladimir B. Grebenschikov > v...@fbsd.ru > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -- Vladimir B. Grebenschikov v...@fbsd.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update
On 30 April 2010 08:37, Jeff Roberson wrote: > Hello, > > I fixed a few SUJ bugs. If those of you who reported one of the following > bugs could re-test I would greatly appreciate it. > > 1) panic on gnome start via softdep_cancel_link(). > 2) Difficulty setting flags on /. This can only be done from a direct boot > into single user but there were problems with tunefs that could lead to the > kernel and disk becoming out of sync with filesystem state. > 3) Kernel compiles without SOFTUPDATES defined in the config now work. Just finished make universe. Everything is fine (c). Thanks. > > I have had some reports of a hang waiting on journal space with certain > types of activity. I have only had this reported twice and I am not able to > reproduce no matter how much load I throw at the machine. If you reproduce > this please try to get a coredump or minidump. > > Thanks, > Jeff -- wbr, pluknet ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update
On Fri, Apr 30, 2010 at 02:43:49PM +0400, Vladimir Grebenschikov wrote: > Hi > > Ehh, looks like fresh kernel is not too stable, it holds after some time > of activity. > > DDB may be activated, but even 'call cpu_reset' does nothing here. > > Looks like it is not related to SUJ, it happens even with SUJ disabled. Does reverting r207410 + r207412 help ? > > > -Original Message- > From: Vladimir Grebenschikov > Reply-to: v...@fbsd.ru > To: Jeff Roberson > Cc: curr...@freebsd.org > Subject: Re: SUJ update > Date: Fri, 30 Apr 2010 13:36:10 +0400 > > Hi > > 1) now works for me (no panics so far) > > -Original Message- > From: Jeff Roberson > To: curr...@freebsd.org > Subject: SUJ update > Date: Thu, 29 Apr 2010 18:37:00 -1000 (HST) > > Hello, > > I fixed a few SUJ bugs. If those of you who reported one of the following > bugs could re-test I would greatly appreciate it. > > 1) panic on gnome start via softdep_cancel_link(). > 2) Difficulty setting flags on /. This can only be done from a direct > boot into single user but there were problems with tunefs that could lead > to the kernel and disk becoming out of sync with filesystem state. > 3) Kernel compiles without SOFTUPDATES defined in the config now work. > > I have had some reports of a hang waiting on journal space with certain > types of activity. I have only had this reported twice and I am not able > to reproduce no matter how much load I throw at the machine. If you > reproduce this please try to get a coredump or minidump. > > Thanks, > Jeff > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > > > -- > Vladimir B. Grebenschikov > v...@fbsd.ru > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" pgp1e5ntk6ua9.pgp Description: PGP signature
Re: SUJ update
Hi Ehh, looks like fresh kernel is not too stable, it holds after some time of activity. DDB may be activated, but even 'call cpu_reset' does nothing here. Looks like it is not related to SUJ, it happens even with SUJ disabled. -Original Message- From: Vladimir Grebenschikov Reply-to: v...@fbsd.ru To: Jeff Roberson Cc: curr...@freebsd.org Subject: Re: SUJ update Date: Fri, 30 Apr 2010 13:36:10 +0400 Hi 1) now works for me (no panics so far) -Original Message- From: Jeff Roberson To: curr...@freebsd.org Subject: SUJ update Date: Thu, 29 Apr 2010 18:37:00 -1000 (HST) Hello, I fixed a few SUJ bugs. If those of you who reported one of the following bugs could re-test I would greatly appreciate it. 1) panic on gnome start via softdep_cancel_link(). 2) Difficulty setting flags on /. This can only be done from a direct boot into single user but there were problems with tunefs that could lead to the kernel and disk becoming out of sync with filesystem state. 3) Kernel compiles without SOFTUPDATES defined in the config now work. I have had some reports of a hang waiting on journal space with certain types of activity. I have only had this reported twice and I am not able to reproduce no matter how much load I throw at the machine. If you reproduce this please try to get a coredump or minidump. Thanks, Jeff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -- Vladimir B. Grebenschikov v...@fbsd.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: SUJ update
Hi 1) now works for me (no panics so far) -Original Message- From: Jeff Roberson To: curr...@freebsd.org Subject: SUJ update Date: Thu, 29 Apr 2010 18:37:00 -1000 (HST) Hello, I fixed a few SUJ bugs. If those of you who reported one of the following bugs could re-test I would greatly appreciate it. 1) panic on gnome start via softdep_cancel_link(). 2) Difficulty setting flags on /. This can only be done from a direct boot into single user but there were problems with tunefs that could lead to the kernel and disk becoming out of sync with filesystem state. 3) Kernel compiles without SOFTUPDATES defined in the config now work. I have had some reports of a hang waiting on journal space with certain types of activity. I have only had this reported twice and I am not able to reproduce no matter how much load I throw at the machine. If you reproduce this please try to get a coredump or minidump. Thanks, Jeff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" -- Vladimir B. Grebenschikov v...@fbsd.ru ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SUJ update
Hello, I fixed a few SUJ bugs. If those of you who reported one of the following bugs could re-test I would greatly appreciate it. 1) panic on gnome start via softdep_cancel_link(). 2) Difficulty setting flags on /. This can only be done from a direct boot into single user but there were problems with tunefs that could lead to the kernel and disk becoming out of sync with filesystem state. 3) Kernel compiles without SOFTUPDATES defined in the config now work. I have had some reports of a hang waiting on journal space with certain types of activity. I have only had this reported twice and I am not able to reproduce no matter how much load I throw at the machine. If you reproduce this please try to get a coredump or minidump. Thanks, Jeff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
