Date: Tue, 16 Apr 2002 18:14:44 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: msch@snafu.de Cc: freebsd-current@freebsd.org Subject: Re: ATA errors on recent -current Message-ID: <3CBCCC84.4AFD0E68@mindspring.com> References: <E16xCAf-0005kI-00@smart.eusc.inter.net> <3CBB66DA.F9C94ED0@mindspring.com> <E16xYyx-0002DV-00@smart.eusc.inter.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CBCCC84.4AFD0E68>