Date: Sat, 1 Mar 1997 08:10:13 -0500 (EST) From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> To: ponds!cet.co.jp!michaelh, ponds!lakes.water.net!rivers Cc: ponds!freebsd.org!freebsd-hackers Subject: Re: Another installment of the "dup alloc"/"bad dir" panic problems. Message-ID: <199703011310.IAA10154@lakes.water.net>
next in thread | raw e-mail | index | archive | help
>
> On Fri, 28 Feb 1997, Thomas David Rivers wrote:
>
> > > > It now appears that having the printf()s in disksort() affects the problem
> > > > in a positive manner (that is, I'm not able to demonstrate the previous
> > > > "non-writing" behaviour I had seen; the inode in question is reliably
> > > > filled with zeros.)
>
> The old "printf's makes the problem go away effect". I hate when that
> happens. ;-)
>
> Can you do a gcc -v and show us the flags you use to compile the kernel?
> I missed these, in case you've already posted them.
Good idea - I'll have to dig this up.
To explain more, I'm using a boot floppy image made with the "release" target
of the standard makefiles. So, this is a BOOTMFS kernel. What I do
is change a kernel file (usually adding printf()s) and then "make release".
Boot from the resulting floppy image; insert a fixit floppy and then
start up newfs's to test things... [rather involved; but the file system
that gives me the reliable reproduction happens to be the root one
on my test machine...]
Here's an example of one of the kernel compiles that results from
that (chopped up to fit 80 columns):
cc -c -O -W -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit
-nostdinc -I. -I../.. -I../../sys -I../../../include -DBOOTMFS
-DI586_CPU -DI486_CPU -DI386_CPU -DMFS_ROOT=1450 -DUSERCONFIG_BOOT
-DMAXCONS=4 -DNFS_NOSERVER -DMFS -DATAPI -DVISUAL_USERCONFIG
-DUSERCONFIG -DUCONSOLE -DBOUNCE_BUFFERS -DSCSI_DELAY=15
-DCOMPAT_43 -DCD9660 -DMSDOSFS -DNFS -DFFS -DINET
-DMATH_EMULATE -DKERNEL -Di386 -DLOAD_ADDRESS=0xF0100000
../../i386/i386/trap.c
However, I was skeptical myself. So; I removed *every* printf()
from my sources (retrieving the original sources) and remade my kernel.
This resulted in a kernel that would demonstrate the problem; and,
of course, has gcc flags as you see above. This means I can rebuild
a kernel that fails, and, to some extent, indicates my build process is
consistent. My next idea is to add the printf()s back, one-at-a-time, to
see which one (or combinations) mask the problem.
I have a difficult time believing that slowing down disksort()
(especially since this isn't an appreciable slow-down) does anything.
But, it would add delay to it's calling routine (in this case, the
SCSI driver) which may be significant.... But, again, this happens
with SCSI and IDE, so I'm guessing the problem lies outside of the
low-level drivers and is to be found at some common level (which is
what lead me to the shared disksort() routine.) Because of this
commonality, I'm betting it's something in /sys/ufs/ufs - which is where
I'm investigating... (well, blindly stumbling.)
>
> Regards,
>
>
> Mike
- Dave Rivers -
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703011310.IAA10154>