Date: Tue, 11 Feb 1997 07:14:20 -0500 (EST) From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> To: ponds!critter.dk.tfs.com!phk Cc: ponds!freebsd.org!dg, ponds!freebsd.org!hackers, ponds!freebsd.org!joerg Subject: Re: daily panics, ffs_valloc: dup alloc - Good news! Message-ID: <199702111214.HAA02075@lakes.water.net>
next in thread | raw e-mail | index | archive | help
Poul-Henning writes: > > In message <199702101504.KAA26752@lakes.water.net>, Thomas David Rivers writes: > >> > >> > I'll try getting it with a fixit floppy. > >> > >> please, it's rather crucial for debugging this. > > > > > > Ok - here you go. > > Thanks a lot. > > > 3) Then, I ifconfig'd ed0; grabbed a working dumpfs and > > go this output. > > I notice that the cgmask is 0xffffffff; so I _think_ > > this file system would have the same problems. > > (ignore the time there; I haven't got the CMOS clock set right.) > > I still can't see how you can possibly have reached the conclusion > that cgmask is the cause of this (as oposed to some other magic somewhere > in the code)... Well; given your statement that 0xffffffff is the correct cgmask - I'd have to retract my assertion. It was simply the only "strange-looking" thing I stumbled into when I was determining just how the disk block offset was calculated. I'm no filesystem guru; I do compilers :-) However; I'm certain that the problem is disk block calculation, somewhere. Since the panic occurs in ffs_alloc.c:ffs_vget(), on a brand new file system; on the first allocation of an inode that just happens to be the same as the # inodes/group. We do the malloc(), bzero() of this data; then the bread() and we're toast. Did the dumpfs I sent you point to any strangeness? - Dave Rivers -
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702111214.HAA02075>