From owner-freebsd-current Mon Apr 15 5: 9:22 2002 Delivered-To: freebsd-current@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 8B10A37B404; Mon, 15 Apr 2002 05:09:00 -0700 (PDT) Received: from pool0028.cvx21-bradley.dialup.earthlink.net ([209.179.192.28] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16x5Hr-0001mc-00; Mon, 15 Apr 2002 05:08:48 -0700 Message-ID: <3CBAC2B3.7F1CEE04@mindspring.com> Date: Mon, 15 Apr 2002 05:08:19 -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: sos@freebsd.dk Cc: Giorgos Keramidas , Alexander Leidinger , dwcjr@inethouston.net, current@FreeBSD.ORG, sos@FreeBSD.ORG Subject: Re: ATA errors on recent -current References: <200204151157.g3FBvB941309@freebsd.dk> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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 "S=F8ren Schmidt" wrote: > It seems Terry Lambert wrote: > > "S=F8ren Schmidt" wrote: > > > > Is your drive perchance an IBM DTLA? > > > > > > > > It's known to have these problems. > > > > > > Cool! would you like to share where that information is available s= o > > > I can possibly work around the problem ?? > > > > IBM DTLA drives are known to be problematic. If you use that > > in a search engine, it will find numerous references to the > > drive electronics being too slow for sustained access to the > > sectors closes to the spindle. > = > This thread is about tagged queueing problems on IBM drives since they > are the only ones that supports it, it is not specific to the DTLA > series at all, which this thread has already explained. > So Terry, do you have anything to share, or just noise like this ? > = > (I dont care about if the DTLA may have other problems) Sorry; all I can give you is hear-say, which I guess you could consider to be noise, except we confirmed that the problem disk in this case was an IBM drive, which tends to support the theory. On the Linux kernel list, they suggested that the electronics that were too slow near the spindle were too slow at the rim, too, if you used tagged command queueing to increase the host load on the drive to the point that it was always dealing with back-to-back transfers. In other words, you *would* overwhelm the drive at the spindle, and you *could* overwhelm it at the rim, if you did it right, according to the posters. Basically, all I'm doing is repeating some arguments I saw elsewhere, not my personal experience with the beasts. My own personal experience with DTLA drive problems is limited to seeing some data corruption problems, reading the Linux lists, and then repartitioning the disks to not use the area near the spindle, which seemed to fix the problem to the point I could ignore investigating it further, and switch vendors when the in-stock DTLA's ran out. =46rom a strictly "scientific proof" point of view, I might as well have waved a dead chicken over the things, and attributed the non-observation of problems afterward to that. On the other hand, "anything that works is better than anything that doesn't work"... 8-) 8-). For a more "scientific test", downloading the firmware tool and setting the DMA transfer rate down, and checking for problems, would be pretty overwhelming evidence. Personally, I don't have any of the buggers lying around to test with any more. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message