Re: kernel/1983: System freeze with db3

[Thierry Deval <TDeval_(_at_)_PrimeOBJ_(_dot_)_COM>]

Hi,

Thanks to Craig's test program, I was able to trace down the apparition 
of the kernel bug. It happened with a change on /sys/kern/vfs_bio.c from 
1.33 to 1.34 on 13th of april 2001.

Unfortunately, I don't understand what happens in getnewbuf at that 
stage (well getnewbuf is quite straightforward, but there is something 
wrong between vfs_bio and vfs_sync...)

To test this, I checked out the kernel sources -D "2001-04-14" and 
updated /sys/kern/vfs_bio.c back to 1.33. That kernel passes db3test 
succesfully. But, at the moment, it appears really difficult to bring 
back vfs_bio-1.33 to current, because too many things changed with vfs 
since then (isn't it, Art ?)

I tried to add some debugging code to vfs_bio, but the only thing I see 
is a possible connection with a second invocation of speedup_syncer() 
during the test...

I've no more clue :-(

T.


On Friday, August 3, 2001, at 11:13 , Craig J Copi wrote:

> Thierry Deval writes:
> > The freeze doesn't depend on softdep (which had been updated not so 
> > long
> > ago), raidframe (appears both with or without) nor disk type (IDE/SCSI
> > are hit, didn't try with NFS)
>
> I did try it with NFS and it didn't freeze.  I didn't test this
> exhaustively, maybe with a larger lk_max it would.  Maybe NFS is
> "slow enough" to not trigger some race condition.  I didn't try it
> with any other filesystem (ext2fs or mfs) so I don't know if this is
> a vfs problem or a ffs specific problem.
>
> 	Craig