From owner-freebsd-current Tue Apr 16 18:15:20 2002 Delivered-To: freebsd-current@freebsd.org Received: from falcon.prod.itd.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by hub.freebsd.org (Postfix) with ESMTP id ADDF137B416 for ; Tue, 16 Apr 2002 18:15:14 -0700 (PDT) Received: from pool0108.cvx40-bradley.dialup.earthlink.net ([216.244.42.108] helo=mindspring.com) by falcon.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16xe2Q-0006k7-00; Tue, 16 Apr 2002 18:15:11 -0700 Message-ID: <3CBCCC84.4AFD0E68@mindspring.com> Date: Tue, 16 Apr 2002 18:14:44 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: msch@snafu.de Cc: freebsd-current@freebsd.org Subject: Re: ATA errors on recent -current References: <3CBB66DA.F9C94ED0@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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, before). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message