Matthias Schuendehuette wrote:
> On Tuesday, 16. April 2002 01:48 you wrote:
> > [...]
> > As I said: it could be drive settings unrelated to the code
> > itself being correct.  I've given three suggestions to verify
> > this, one way or the other:
> >
> > 1)    Control the drive DMA speed down
> >
> > 2)    Pretend the maximum tagged command queue depth is
> >       smaller than it is
> >
> > 3)    Toggle the write caching on the drive
> I used 'atacontrol' to read the number of tags allowed: it is 31
> (0x1F). Perhaps Soren could tell me how to force it to, say, 0x10?

You have to modify the source code in ~line 180 of /sys/dev/ata/ata-disk.c.

> Then I tried various combinations of UDMA100/66/33 and wc=0/1 - it
> nearly doesn't change anything. If WC was enabled, I saw errors
> concerning tags 0 *and* 1, whereas without write caching only tag=0 was
> mentioned. I should say that my simple test was a 'tar cvf /dev/null
> /usr/ports' with /usr/ports on an ATA-partition. Why *Write*Caching has
> any influence here...???

I rather expected you to have *more* problems with write caching
than without, not the other way around.  I can't explain this.

> What was consistent thru all test was, that the disk operates quite
> some time until the error occures the first time. After that, it is not
> possible to access the disk in UDMA-Mode any more, regardeless *which*
> UDMA-Mode it is. 'Quite some time' means approx. 50% of /usr/ports in
> the above mentioned 'test'.
> After the first switch to PIO4, I umounted the filesystem and switched
> back to UDMA33 for instance - I couldn't even *mount* the filesystem
> again!
> But w/o Tagged Queuing the disk operates flawlessly, so I'm a bit in
> doubt, if the errors with WD-disks have the same source... but may be.

My hunch, which is why I suggested decreasing the number of
tags seen by the driver, is that the tagged queues are over
used, and this locks the disk up.  My best guess is an off-by-one
or an exceptional condition handler that was not an issue until
recently, because of a FreeBSD interrupt architecture change
having nothing to do with the driver itself (i.e. the reason it
only happens under load, and didn't happen under the same load,

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to