From owner-freebsd-questions@FreeBSD.ORG Mon Jun 21 19:06:43 2004 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B16516A4D7 for ; Mon, 21 Jun 2004 19:06:43 +0000 (GMT) Received: from delivery.infowest.com (delivery.infowest.com [204.17.177.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C4E743D4C for ; Mon, 21 Jun 2004 19:06:43 +0000 (GMT) (envelope-from jedi@infowest.com) Received: from infowest.com (hogwarts.eq.net [209.33.211.132]) by delivery.infowest.com (Postfix) with ESMTP id ED555EAC045; Mon, 21 Jun 2004 13:06:41 -0600 (MDT) Message-ID: <40D731CA.301@infowest.com> Date: Mon, 21 Jun 2004 13:06:50 -0600 From: Kendall Gifford User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-questions@freebsd.org X-Enigmail-Version: 0.81.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: WRITE_DMA UDMA ICRC errors with my ata drive(s)/controller X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2004 19:06:43 -0000 Greetings. I recently upgraded my server from 4.9-RELEASE to 5.2.1-RELEASE and immediately started to get the following error logged whenever there is significant disk activity: ad0: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=137690696 ad0: FAILURE - WRITE_DMA status=51 error=84 LBA=137690696 [there are slight, insignificant variations, of course] Anyhow, the first thing I did was to install and run smartctl (part of the smartmontools package) since both my drives are S.M.A.R.T. enabled. Aside from having the same write dma errors in their internal logs, the drives appear to be fine (all values are well above their threshold). Also, all disk activity that sparked said errors always succeeded as all copied files were uncorrupted. So, I did a little searching online and found that besides the misc. person having this problem and being told to check their drives or cables or ide controllers, I came across the following two threads: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=20040409042611.GA68595_binary.net%40ns.sol.net&rnum=1&prev=/groups%3Fq%3Dfreebsd%2Bwrite_dma%2Budma%2Bicrc%2Berror%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D20040409042611.GA68595_binary.net%2540ns.sol.net%26rnum%3D1 http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=20040414024308.GA6468%40binary.net&rnum=4&prev=/groups%3Fq%3Dfreebsd%2Bwrite_dma%2Budma%2Bicrc%2Berror%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D20040414024308.GA6468%2540binary.net%26rnum%3D4 The first thing I noted was that I am also using a board with the VIA 8235: [dmesg] atapci0: port 0xdc00-0xdc0f at device 17.1 on pci0 And I also have fairly large drives, two Maxtor 120GB drives: [dmesg] ad0: 117246MB [238216/16/63] at ata0-master UDMA133 acd0: CDRW at ata0-slave BIOSPIO ad2: 117246MB [238216/16/63] at ata1-master UDMA133 Also of note is that these two drives worked just fine in UDMA133 mode in my 4.9-RELEASE system. Due to this and the newness of the two drives, the motherboard, and the ATA133 round cables as well as having everything check out in my S.M.A.R.T. test, and the fact that despite these errors, the disk I/O transactions always seem to succeed (as far as I've been able to test) and the system otherwise functions normally even with both drives in UDMA133 mode, I wonder if there is possibly either some hardware bug with the VIA 8235 or some incompatibility between the ata driver in 5.2.1-RELEASE and the VIA 8235 or if someone, after reading my message and the two threads I linked to, has yet another idea? P.S. - Just as was described in the threads above, if I also put my problem drive in PIO mode, I get no more UDMA ICRC errors. P.P.S. - While, for reasons I've describe above, I suspect my hardware is not at fault, I know that I certainly can't guarantee that this is the case since I don't have the resources (a.k.a. extra hardware and time) to swap parts around to verify, for sure, it isn't at fault. -- Kendall Gifford ======================================== WEB: http://kendall.jedis.com/ EMAIL: REPLY TO LIST ========================================