From owner-aic7xxx Tue Mar 12 7: 1:41 2002 Delivered-To: aic7xxx@freebsd.org Received: from cleveland.lug.net (shell.cleveland.lug.net [207.166.193.105]) by hub.freebsd.org (Postfix) with ESMTP id EE74737BE55 for ; Tue, 12 Mar 2002 06:53:08 -0800 (PST) Received: from localhost (ken@localhost) by cleveland.lug.net (8.11.2/8.11.2) with ESMTP id g2CEqFk32326; Tue, 12 Mar 2002 09:52:21 -0500 Date: Tue, 12 Mar 2002 09:52:15 -0500 (EST) From: kf To: "J. Hart" Cc: Subject: AMD??? (was Re: file corruption on tape reload) In-Reply-To: <3C8DDC7C.C8B6066B@atr.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aic7xxx@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org There's been some discussion on this list recently about AMD Athlon CPUs. Of course there are a lot of variables, even in your tightly controlled scenario, but this kind of problem is the kind consistent with primary storage instability issues associated with the standard (pre-XP) Athlons. Does this machine have an AGP video card? Do you include the append="mem=nopentium" statement in /etc/lilo.conf? kf On Tue, 12 Mar 2002, J. Hart wrote: = = I have been having difficulty making a good tape backup recently. I use = the following command to back up a directory : = = tar cvM -f /dev/st0 2>&1 aminet | tee log = = I reload that into a seperate directory using the following command : = = tar xvM -f /dev/st0 2>&1 | tee log = = When I compare the original with the reloaded backup, I find that one of = the files in the reloaded version is corrupted. It turns out that a contiguous = block of exactly 4096 bytes is corrupt. If I reload the same backup tapes = again, the corruption shows up at a different point in a different file, but the = corruption still involves a block of exactly 4096 bytes. = = I had previously used this same tape drive on an older machine running = Slackware 4 and a stock kernel until very recently, and it worked perfectly = there. I am using the exact same model under RedHat 6.2 and the 2.2.16 kernel = on another machine, and that works perfectly. I have tried changing tapes and = cleaning the drive tape path, with no effect on the problem. I have also tried = upgrading the kernel to the most recent version available at the time (then = 2.4.16) to no avail. I then tried rebuilding the kernel to use "aic7xxx_old" = support, also with no change in the problem. There is no indication of any = error in any of the logs I have checked (dmesg, /var/log/messages). = = Does anyone have any idea on what I should be looking at here ? = = My setup is as follows : = = CPU : 900mhz Athlon = motherboard : ASYS-A7V = linux distribution : Slackware 8 = kernel : 2.4.16 = scsi controller : AHA-2940AU = scsi drivers tried : aic7xxx = : aic7xxx_old (after kernel rebuild) = hard disk : ATA100 IBM-DTLA-307045 45gb = tar version : tar (GNU tar) 1.13.25 = tape drive: = Vendor: WangDAT Model: Model 3400DX Rev: 5.0d = Type: Sequential-Access ANSI SCSI revision: 02 = = = Regards, = = J. Hart = = To Unsubscribe: send mail to majordomo@FreeBSD.org = with "unsubscribe aic7xxx" in the body of the message = -- Cleveland Linux Users Group http://cleveland.lug.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe aic7xxx" in the body of the message