Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Apr 2002 21:51:13 +0200
From:      Matthias Schuendehuette <msch@snafu.de>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        freebsd-current@freebsd.org
Subject:   Re: ATA errors on recent -current
Message-ID:  <E16xYyx-0002DV-00@smart.eusc.inter.net>
In-Reply-To: <3CBB66DA.F9C94ED0@mindspring.com>
References:  <E16xCAf-0005kI-00@smart.eusc.inter.net> <3CBB66DA.F9C94ED0@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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: <VIA 8363 (Apollo KT133) PCI-PCI (AGP) bridge> \
	at device 1.0 on pci0
/* It's an EPoX 8KTA2 MoBo */
atapci0: <VIA 82C686 ATA100 controller> port 0xd000-0xd00f \
	at device 7.1 on pci0
atapci0: Correcting VIA config for southbridge data corruption bug
ad0: 43979MB <IBM-DTLA-307045> [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	<msch@snafu.de>, 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E16xYyx-0002DV-00>