Date: Mon, 15 Apr 2002 15:18:50 +0200 (CEST) From: Søren Schmidt <sos@freebsd.dk> To: Terry Lambert <tlambert2@mindspring.com> Cc: Giorgos Keramidas <keramida@ceid.upatras.gr>, Alexander Leidinger <Alexander@Leidinger.net>, dwcjr@inethouston.net, current@FreeBSD.ORG, sos@FreeBSD.ORG Subject: Re: ATA errors on recent -current Message-ID: <200204151318.g3FDIoL43045@freebsd.dk> In-Reply-To: <3CBACD5A.92900331@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
It seems Terry Lambert wrote: > "Søren Schmidt" wrote: > > > 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. > > > > Why on earth would you do that ? (hint man atacontrol) > > > > Besides I dont see this as any evidence at all, but thats another matter... > > If it fixes the problem, then the problem is most likely related > to what firmware setting the tool changes. AFAIK it only set the maximum DMA speed the drive will allow, that you can do with atacontrol as well... > Obviously, turning off tagged commands works, according to at least > one person who is reporting the problem. Again that has *nothing* to do with the DTLA drives and DMA speed and the phase of the moon... But it shows (as we already know) that using tags on any drive that supports it, can fail on some systems. > I wonder if limiting outstanding tagged commands to less than the > number advertised by the drive would also work... can't be worse > than the initialization reordering patch that failed (e.g the > worst case is it still has the problems). A lot safer than banging > bits in the firmware, I'm sure, though... > > Limiting the outstanding tagged commands to less than the advertised > amount would actually be my first choice of a hack for a software > workaround. Thats not the problem either, the problem is that I apparently changed some subtle bits that make it fail on some systems, regardless of controller and disk type, but which is marginal enough that I cant reproduce the problem here in the lab... -Søren 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?200204151318.g3FDIoL43045>