[813] in linux-scsi channel archive
Re: SCSI tape errors with 2.0 kernels
daemon@ATHENA.MIT.EDU (Brian Topping)
Fri Oct 18 02:53:05 1996
Date: Thu, 17 Oct 1996 23:48:44 -0700
From: Brian Topping <topping@mauswerks.com>
To: linux-scsi@vger.rutgers.edu, ncr53c810@cs.colorado.edu,
linux-kernel@vger.rutgers.edu
CC: wperkins@us.net, groudier@club-internet.fr
Hi all,
I am hitting this problem too. Systems with problems are 133MHz
Pentium, 100MHz Pentium, both running ncr53c7,8xx driver on Asus NCR
boards. I have tested a few permutations of driver feature flags down
to bare minimum (async only, slow SCSI clock, no disconnect). I know
the termination is right on because the drive chain blows curd in 10MHz
SCSI with bad termination.
I am running this with a HP1533A drive, and have tested the drive,
cable, and terminator on a NT 4.0 box also running an Asus NCR card. No
problems.
I'm kind of bumming about this, because don't you pretty much have to
have a SCSI analyzer to track this kind of thing? If anyone in the SF
Bay Area wants to get together on this (and has the bus analyzer with
requisite operating skills), I don't know a thing about the driver, but
it sure will be a trip learning about it ;)
-B
William M. Perkins wrote:
>
> Okay. Now where we left off last was that I was going to try the
> 2.0.1 kernel without the st.c patch included with patch-2.0.1.gz.
> This is using the ncr53c7,8xx driver. I did not try it with the
> BSD NCR driver. I ran out of time for this week. the 2.0.1 kernel
> without the st.c patch produced an error free cpio created half-GB
> tape on my Wangtek 5525ES. I than patched the kernel up to 2.0.3
> and re-tested. I got one cpio crc error.
>
> >cpio: /usr/i486-linuxaout/lib/libX11.so.3.1.0: checksum error
> > (0x1f0ceff, should be 0x1f0d1b5)
>
> I loaded the bad file back from tape and received the crc error
> with the same compared CRC values.
>
> > $ cpio -iBdmrH crc -I /dev/tape /usr/i486-linuxaout/lib/libX11.so.3.1.0
> > rename /usr/i486-linuxaout/lib/libX11.so.3.1.0 -> bad-file
> > cpio: bad-file: checksum error (0x1f0ceff, should be 0x1f0d1b5)
>
> I than compared the bad file with the original:
>
> > $ cmp -l /usr/i486-linuxaout/lib/libX11.so.3.1.0 bad-file
> > 206945 337 0
> > 206946 340 15
> > 206947 200 40
> > 206948 344 100
>
> The consistent trait of these errors is that there are four, sometimes
> three, byte compare errors in a row. In this case the compared bytes
> in the bad file had values greater than zero. When I was seeing the
> errors before in four adjacent bytes, they were generally nulls. I
> do not know what that change is due too, and I still do not know what
> component of the kernel code may be producing these CRC errors.
>
> The 2.0.0 kernel with the ncr53c7,8xx driver still creates consistent
> system backup tapes. Most likely only because I check each tape that
> is created. Leaving out the st.c patch for 2.0.1 seemed to work, but
> the 2.0.3 without the same patch appears to produce crc errors. More
> testing is needed.
>
> Gerard, I am sorry that I have not found the time to check this problem
> out more thoroughly with the BSD ncr SCSI driver. I was going to do so
> with the 2.0.3 kernel, since that kernel has your driver included as
> part of the kernel distribution, but a weekend is too short a period of
> time to try compiling five kernels and dumping/checking five cpio tapes.
> There is also the matter of other things that need to be done around the
> house. :-(
>
> Hopefully I can complete this next weekend.
>
> Bill
>
> --
> William M. Perkins Internet - wperkins@us.net
> The Greenwood or - bill@pooh.grnwood.richmond.us.net
> Commodore and Escom are dead. Long live the Amiga! (AmigaOS/Linux)
