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