Date: Tue, 4 Mar 1997 20:57:34 -0500 (EST) From: Thomas David Rivers <ponds!rivers@dg-rtp.dg.com> To: ponds!root.com!dg, ponds!freefall.cdrom.com!freebsd-hackers, ponds!lakes.water.net!rivers, ponds!lambert.org!terry Subject: "dup alloc" - nope - kern/2875 wasn't it. Message-ID: <199703050157.UAA00285@lakes.water.net>
next in thread | raw e-mail | index | archive | help
Well; it's a sad day in Mudville... Unfortunately, when I built from a pristine source base, with only the vfs_subr.c patch; I was able to reproduce my bad inodes.... Seems that the combination of a couple of printf()s in the kernel and that particular splbio()/splx() masks the problem just as my printf()s in disksort did... So, my previous elation was misplaced. Don't misunderstand; I believe the fix needs to be there - it just didn't address my particular problem. I also note that vfs_subr.c, in 2.1.6.1 didn't have any splxxx() calls in it, was a lot of work done in this area for 2.2? Anyway - I'll keep looking for the culprit.... I have the feeling it's something along these lines (a missing splbio(), or an splbio()/splx mis-match.) - But, that's just a guess... By the way; I have noticed that around the time in the newfs when this particular block should be written; the SCSI light goes off, say, for 1/2 second. This seems to be rather large considering that: 1) The length of the buf queue is never greater than 1. 2) The blocks (during the newfs operation) are in ascending order. I wonder why, on a "fixit" shell when nothing else is running, the disk drive pauses like that. It could be related.... - Dave Rivers -
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703050157.UAA00285>