Date: Sat, 29 Dec 2001 20:59:21 +0000 From: ian j hart <ianjhart@ntlworld.com> To: Bill Moran <wmoran@potentialtech.com> Cc: Eugene Grosbein <eugen@grosbein.pp.ru>, Blaz Zupan <blaz@si.freebsd.org>, qa@freebsd.org, stable@freebsd.org Subject: Re: 4.5-PRERELEASE (25 Dec) and IBM IC35L040AVER07-0 Message-ID: <3C2E2EA9.5FADADC@ntlworld.com> References: <3C2D5F07.C1001711@svzserv.kemerovo.su> <20011229091038.F81588-100000@titanic.medinet.si> <20011230001554.A457@grosbein.pp.ru> <3C2E179F.9020108@potentialtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bill Moran wrote: > > Eugene Grosbein wrote: > > On Sat, Dec 29, 2001 at 09:11:07AM +0100, Blaz Zupan wrote: > > > > > >>>You do not use tags, do you? > >>> > >>The default is off I believe and I have not explicitely turned them on, so > >>yes, I'm not using them. > >> > > > > Those errors were 100% reproducible. > > Now I've commented out 'hw.ata.tags=1' from /boot/loader.conf > > and all errors have disappeared. > > > > I still wonder if it software or hardware incompatibility. > > So do I. See http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/29045 > Nobody responded to my last post on this pr, and I have no idea > where to go from here without direction. This level of technical > debugging is quite beyond me at this time. But the problem still > exists, it happened again earlier this week (even with the drives > throttled to ata33). What kind of HDD are you using? Personally, > I suspect HW problems, and I seem to recall a few months ago, > someone else with IBM HDDs complaining about the same thing. Have > there been any patches to the ata code that could affect this? If > so, I'll update this machine and see if it continues to be a problem. > > -- > Bill Moran > Potential Technology > http://www.potentialtech.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message From the pr <quote> 4) IBM is serious when they say the 80 conductor cable can't be longer than 18" (the one I had was a few inches longer) </quote> <quote> I reconnected the 80 conductor cable earlier today, and intentionally recreated the problem so that I could do the hex diff procedure you describe. Here's what happened: 1. Did a find | md5 like you described in previous messages 2. Started a "make world" process and then started another find | md5 running simultaneously. 3. Once I had two files full of md5 checksums, I ran a diff to find out what files had become victums of corruption. 4. I used the diff to pick files to run the hex dump on. I had original files on another server, safe from any possible corruption. The problem is: no differences were found between the two files. Put in plain english, I have two files that *should* be identical, but the md5 checksums differ, however, the hd/diff procedure above shows no differences. </quote> 1 Cable length was definately an issue for me (40 way cable, VIA ATA33 with UDMA 66 drives). I would trust IBM on this one. [stable archive 08/07/01 VIA 82C586 UDMA ICRC errors] 2 Get the latest BIOS and firmware. 3 The MD5 thing rings bells. I "ghost" Win95 clients using FreeBSD. make bootable DOS partition install FreeBSD on the remaining disk ftp the clone tarball extract to the DOS partition Due to working with old and cheap hardware I MD5 the clone and test after downloading. I had a number of systems which would not cooperate. I changed CPU, memory, HDD and network cards, all to no avail. I even wrote a script to fill the drive with large files (100Mb of 0xE5) and then MD5 them. Trying to find suspect sectors. I got the same result as you did. Different MD5s for identical files. Then I turned off UDMA with sysctl. IIRC this was a pc-chips BX pro. 4 There's a tool to set the mode of the drive. Worth a try. -- ian j hart To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C2E2EA9.5FADADC>