On Thu, May 01, 2003 at 10:41:13PM +0100, Patrick Welche wrote:
> On Tue, Apr 29, 2003 at 08:55:48PM +0200, Manuel Bouyer wrote:
> > On Tue, Apr 29, 2003 at 09:31:54AM +0100, Patrick Welche wrote:
> > > I just replace the kernel with an old one, and have done another
> > > 3 successful make releases on that machine, so I really can't
> > > believe it's the disks which are at fault.. (With a new kernel
> > > the disklabel of one of the disks was even changed(!)) The best
> > > I can think of is that maybe the new ahc driver reorders commands
> > > more agressively? Is it possible? Does it expect the "yes I've
> > > written it" from the disk to be true?
> > 
> > 
> > No, the driver itself shouldn't reorder the commands. The drive may.
> > 
> > > 
> > > Anyway, I'll try switching off write-back to see if that improves
> > > things, and then try switching off tagged queueing.
> > 
> > This would be a good test. I played a bit on sparc64, with 2
> > disks connected and couldn't reproduce the problem. But I only have a
> > plain 2940UW, which also worked fine with the old driver.
> > 
> > > I'm assuming
> > > it's safe to install a new fsck binary with an old (16th April)
> > > kernel to help patch up the disks after they have been messed up
> > > by the new kernel..
> > 
> > It should.
> 
> And switching off write-back cache so far seems to have cured things..
> 
> The story is:
> 
> ahc  write-back cache      tagged queueing      state
> old       enabled             enabled           rock solid 24/7
> new       enabled             enabled           creates corrupt files/fsck :(
> new       disabled            enabled           make release succeeded
> 
> So was I just lucky before?

I'm not sure how tagged queing was used by the old ahc driver. Maybe the
new one push the drive harder.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 24 ans d'experience feront toujours la difference
--