Date: Sat, 2 Mar 1996 17:22:44 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: jhay@mikom.csir.co.za, terry@lambert.org, freebsd-current@FreeBSD.ORG Subject: Re: rename panics kernel Message-ID: <199603030022.RAA03030@phaeton.artisoft.com> In-Reply-To: <199603021351.AAA07828@godzilla.zeta.org.au> from "Bruce Evans" at Mar 3, 96 00:51:52 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I couldn't duplicate this with my version of -current, but plain -current > on an 8MB system gave: > > panic: vm_fork: u_map allocation failed Side effect of the fork/exec, I think. I haven't tracked it, but it looks like the page recovery is not happeneing for the environment space until the reap? I'd say this isn't really a problem. > and after rebooting it paniced in savecore: > > panic: bremfree: removing a buffer when not on a queue I never use savecore -- sorry. I rememebr something similar to this; is your swap in your /etc/fstab? That idea seems to tickle a memory. > and on a 16MB system the mv script trapped for a null pointer: > > Stopped at _ufs_remove+0x15: movl 0x68(%ecx),%edi > [%ecx = 0; %ecx is ap->a_vp] > > The fix is a side effect of my reordering for single-entry/single-exit > and the semantic changes for the: > > It must be a side effect of something I've changed too :-). In > ufs_rename(), I only changed most of the IN_CHANGE's to IN_MODIFIED. > This stops the directory ctimes from being updated for failed renames. > I don't think this would affect the bug. Hmmm... actually, it could. The allocation would have to rotor the vnodes through a list; if they were not inver LRU allocation order (ie: jumping between two of them, and it doesn), then you could fill up the total number of available vnodes before vclean go to them. This would be a serious border condition that I'd think would be near-impossible to reproduce reliably. Remember the "free vnode isn't" panic kludge I posted? Have you tried that? It may fix this problem as well. The other thing you might want to try is disabling async updates in the FFS code (per the sysctl debug variable)... I don't think that will do it for you, though. If either one of these does it for you, then I've just been lucky in not repeating the panic here. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603030022.RAA03030>