[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: kernel/1983: System freeze with db3


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 :-(


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.