[lkml]   [1996]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: SCSI tape errors with 2.0 kernels
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

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 ;)


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/ 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/
> > rename /usr/i486-linuxaout/lib/ -> 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/ 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 -
> The Greenwood or -
> Commodore and Escom are dead. Long live the Amiga! (AmigaOS/Linux)

 \ /
  Last update: 2005-03-22 13:37    [W:0.027 / U:1.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site