Date: Thu, 11 Aug 2005 00:46:04 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@FreeBSD.ORG> To: Karl Denninger <karl@denninger.net> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599 Message-ID: <C7F80208-EF4B-41A1-96FC-024BCA0EBCC3@FreeBSD.ORG> In-Reply-To: <20050810205101.GA17483@FS.denninger.net> References: <42F9009E.3030601@mac.com> <42F9609E.1010207@goldsword.com> <20050810023111.GA2913@FS.denninger.net> <20050810024618.GA8198@drjekyll.mkbuelow.net> <6.2.1.2.0.20050810081251.05298ff0@64.7.153.2> <20050810133159.GA10150@FS.denninger.net> <6.2.1.2.0.20050810094204.06c46098@64.7.153.2> <20050810144148.GB10150@FS.denninger.net> <790a9fff0508100844a7e5435@mail.gmail.com> <4A1BF8DF-EC50-4067-A69B-84D9BE5B22C7@FreeBSD.ORG> <20050810205101.GA17483@FS.denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/08/2005, at 22:51, Karl Denninger wrote: >> >> Since I came in late in this, I need to know what kind of controller >> we are talking about, and if the problem is still present in 6.0. >> I plan to backport ATA from 6.0 to 5-stable when it has settled, so >> 6.0 is the one and only (pre)release to test with and get back to me >> with the result. >> >> - S?ren >> > > 6.0 BETA1 AND 5.4 BOTH fail with the SiI 3112 chipsets. Reliably. > I have two controllers here that are from different manufacturers =20 > and both > exhibit the same problem. The SAME disks (two different =20 > manufacturers - > hitachi and maxtor) on a motherboard ICH5 adapter work perfectly, > smartmontools says all 4 (I have two examples of each) are healthy, =20= > and > both ALSO work perfectly on and are declared healthy by a 3ware 8502's > internal diags and operating kernel (smartmontools won't talk to =20 > them on > the 8502.) > > This is the subject of the PR I filed back in February. > > Again, if you want either a controller shipped to you OR access to a > development machine (e.g. ssh in and play) which has the suspect > configuration on it, the latter of which is probably the best =20 > option (since > making it fail is simple) I'm willing to provide either - my only =20 > caveat is > that if I send hardware I want it back when you're done, and I =20 > believe its > reasonable to expect that 6.0 will get HELD in its release cycle =20 > until this > is resolved. I have plenty of the sii3112's around, so thats not needed, however =20 I've not managed to get ahold of a machine in which it fails reliably =20= with ATA as is in 6.0. > The latter offer (ssh access) has been on the table for several =20 > months. The > former I just put on the table as I threw up my hands and bought a =20 > 3ware > card - which means I now have TWO of the suspect cards and need =20 > only one > for my own testing (in the sandbox) > > I'm willing to go WELL out of my way to make it possible for this =20 > to get > fixed, since there appears to be an issue with access to hardware that > breaks reliably. However, I, and others, would like to know that =20 > we're > going to see the problem get resolved. I've already gone WAY out of my way to try to support the sii3112, =20 and I'm not inclined to waste more of my precious spare time on it. =20 However, if it really is that important to enough people to try to =20 workaround the silicon bugs (which very likely isn't possible), get =20 together and get me failing HW on my desk and time to work on it. > Again - this is hardware that is STABLE and works under 4.x - in =20 > the case of > my specific configuration I ran under 4.x for over a year without a =20= > single > incident. With 5.4 and 6.0-BETA I can kill it inside of 2 minutes =20 > with > nothing more complicated than a "make -j4 buildworld". First. you cannot by any degree of the word call the sii3112 for =20 STABLE hardware, its broken beyond repair or workarounds, and even =20 the supplier acknowledges that fact. Second, you cannot possibly have used gmirror (as in the PR) on 4.x =20 so what was the config back then ? Third, please get gmirror out of the loop (use atacontrol to create a =20= mirror if need be) and let me know if that changes anything. Forth, another thing to try is fumbling with BIOS settings, some =20 setups has been reported to start working when PCI timings is changed =20= YMMV.. - S=F8ren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C7F80208-EF4B-41A1-96FC-024BCA0EBCC3>