From owner-freebsd-current Tue Apr 16 12:51:40 2002 Delivered-To: freebsd-current@freebsd.org Received: from smart.eusc.inter.net (smart.eusc.inter.net [213.73.101.5]) by hub.freebsd.org (Postfix) with ESMTP id 9727137B404 for ; Tue, 16 Apr 2002 12:51:17 -0700 (PDT) Received: from tc08-n66-182.de.inter.net ([213.73.66.182] helo=there) by smart.eusc.inter.net with smtp (Exim 3.22 #3) id 16xYyx-0002DV-00; Tue, 16 Apr 2002 21:51:16 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Matthias Schuendehuette Reply-To: msch@snafu.de Organization: Micro$oft-free Zone To: Terry Lambert Subject: Re: ATA errors on recent -current Date: Tue, 16 Apr 2002 21:51:13 +0200 X-Mailer: KMail [version 1.3.1] References: <3CBB66DA.F9C94ED0@mindspring.com> In-Reply-To: <3CBB66DA.F9C94ED0@mindspring.com> Cc: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: 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 Hi Terry and you all, 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? 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...??? 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. So far - but still some data: CPU: AMD Duron(tm) processor (801.82-MHz 686-class CPU) real memory = 268369920 (262080K bytes) pcib1: \ at device 1.0 on pci0 /* It's an EPoX 8KTA2 MoBo */ atapci0: port 0xd000-0xd00f \ at device 7.1 on pci0 atapci0: Correcting VIA config for southbridge data corruption bug ad0: 43979MB [89355/16/63] at ata0-master UDMA100 ...and 'atacontrol cap 0 0' says: ATA channel 0, Master, device ad0: ATA/ATAPI revision 5 device model IBM-DTLA-307045 firmware revision TX6OA50C cylinders 16383 heads 16 sectors/track 63 lba supported 90069840 sectors lba48 not supported dma supported overlap not supported Feature Support Enable Value Vendor write cache yes no read ahead yes yes dma queued yes yes 31/1F SMART yes no microcode download no no security yes no power management yes yes advanced power management yes no 0/00 automatic acoustic management yes no 254/FE 128/80 That's it. -- Ciao/BSD - Matthias Matthias Schuendehuette , Berlin (Germany) Powered by FreeBSD 4.5-STABLE To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message