Date: Mon, 20 Jun 2005 11:09:53 +0100 From: Tony Byrne <freebsd-current@byrnehq.com> To: freebsd-stable@freebsd.org Subject: Re[2]: ATA_DMA errors (and fs corruption!) Message-ID: <67335859.20050620110953@byrnehq.com> In-Reply-To: <8d02aed005061918049c8fd8@mail.gmail.com> References: <8d02aed00506181404642100b9@mail.gmail.com> <42B5DAEA.4040908@nurfuerspam.de> <8d02aed005061918049c8fd8@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello twesky, t> atapci0: <Intel ICH4 UDMA100 controller> port t> 0x1860-0x186f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on t> pci0 t> ata0: channel #0 on atapci0 t> ata1: channel #1 on atapci0 t> The last known good stable version for me was aprox April 25, my next t> cvsup was May 17, but I have problems with 5.4 Release so I assume t> (probably incorrectly) that something changed between April 25 and t> 5.4R. t> I don't exactly recall my shutdown errors, but I did have to restore t> my file systems to get my laptop back to a functioning state. We've been seeing the same problem in a server equipped with an Intel ICH5 controller and SATA Hard Disk. The problems seemed to start after an update in mid-May. We noticed that processes such as our imap server would stall for a few seconds and the console would indicate either a READ_DMA or WRITE_DMA timeout. On two occasions the the disk became detached requiring a reboot. The frequency of these timeouts were such that we couldn't do any work with the server. We didn't have this problem prior to the update. We are tracking RELENG_5, but have now reverted to a May 9th kernel, which doesn't seem to be quite so fussy and has reduced the problem to a handful of timeouts every day. What's bugging me is that this list has been very quiet about this problem. The Intel ICH* controllers must be common in the field and I'm surprised that this problem has gone unnoticed. Of course, there can be hardware reasons for timeouts such as a dying disk or cable, but I think we've eliminated these in our case. The disk works fine when transferred to another machine and the SATA cable works fine when used with another disk (albeit one of smaller capacity) in the server. So we've come to the conclusion that it's the combination of controller, disk and FreeBSD version that holds the key to this. Jun 20 10:20:04 roo kernel: atapci0: <Intel ICH5 SATA150 controller> port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.2 on pci0 Jun 20 10:20:04 roo kernel: ata0: channel #0 on atapci0 Jun 20 10:20:04 roo kernel: ata1: channel #1 on atapci0 ... Jun 20 10:20:04 roo kernel: ad0: 190782MB <WDC WD2000JD-00FYB0/02.05D02> [387621/16/63] at ata0-master SATA150 Jun 20 10:20:04 roo kernel: acd0: CDROM <SAMSUNG CD-ROM SC-152G/C400> at ata1-master PIO4 ... Regards, Tony. -- Tony Byrne
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?67335859.20050620110953>