Messages in this thread |  | | Date | Thu, 17 Oct 1996 23:48:44 -0700 | From | Brian Topping <> | Subject | Re: 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 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)
|  |