My suspicion is that the problem tends to occur when the file is read
quickly. When I slowed down my SCSI controller to 3.3 MB/s, reading
the file seemed to be more reliable (hpcdtoppm direct reads worked, but
not cp), and when using the hpcdtoppm program to read it which probably
does processing as it's being read slowing down the input, it reads
reliably.
Hardware System: i486DX50 w/256k Cache, 32 MB RAM, Maxtor MXT-540SL Hard
Drive, Western Digital WD90C31 graphics controller, Adaptec 1742A EISA
SCSI-2 Controller, 14.4K Baud Intel Internal Modem, NEC SCSI CDR-55 CD-ROM
drive.
Operation System:
Original Distribution: Slackware 1.1.0
Kernel's tested: 0.99pl13q and 0.99pl15a
Compiler version: gcc 2.4.5
Experiments:
Step A: Having discovered the problem, I had to get a correct copy of
the file onto my harddisk. I used a Macintosh to read the CD-ROM, and
uploaded one 4MB image file to my PC. I visually verified the image
file viewing it in all five resolutions in xv (on linux).
Step B: To be certain that the visual verification would be sufficient,
I viewed one of the corrupt copied files also using xv, and over half
of the image is bad.
Step C: To be more scientific, I did the copy test again from the CD-ROM.
I mounted the CD-ROM, then using "cp", copied the file to /tmp. I used
gnu "cmp" to compare the files, and it failed on byte 2578530.
At this point the BIOS on the Adaptec card was set to: no parity
(the 0.99pl13q kernel will not boot when parity checking is on, fails
when probing the CD-ROM drive-- could be a problem with the drive),
synch negotiation, 5MB/s transfer speed. The kernel I was using at
this stage was 0.99pl13q.
Step D: I changed one of the BIOS settings. I turned off synch
negotiation. "cp" still generated a corrupt copy, and hpcdtoppm could
not read the file directly. I got a corrupt picture. (no data
on the byte # at which the file becomes corrupt)
Step E: I changed another BIOS setting. I lowered the transfer speed
to 3.3MB/s. I was able to use hpcdtoppm to read the file in correctly.
i.e. hpcdtoppm -5 img0038.pcd | xv -
However, "cp" still generated a corrupt image. (no data on the
byte # at which the file becomes corrupt)
Step F: I tried using "cat" to read the file.
% cat img0038.pcd > /tmp/img0038.pcd.cat
This file also had the correct file size, but became corrupt at a different
point than before, byte 1609729.
Step G: Believing that it might be some sort of caching problem, I upgraded
the kernel to 0.99pl15a, hoping that this had been fixed. Using "cp"
% cp img0038.pcd /tmp/img0038.pcd.cp
It failed again at byte 1609729.
Workaround:
The only workaround I have at the moment is to use hpcdtoppm to read
the file from the CD-ROM.
Conjecture of problem:
I believe that it might be some sort of caching problem either with
the operating system or within the CD-ROM drive. The experiments
imply that the problem has something to do with the rate at which data
is read from the disk.
Final note: I should point out that I have mounted "regular" CD-ROM's
before (e.g. Nascent distribution of linux), and I was able to run
large binaries directly from the CD-ROM drive w/o any problems
(e.g. magic, a program to aid layout out integrated circuits, about
4 MBytes).
---------------
Has any one else encountered this problem? Any help would be appreciated.
Please send me mail at (hen...@eecs.berkeley.edu).
-Henry Chang
--
Henry Chang hen...@ic.Berkeley.EDU
UC Berkeley Graduate Student Berkeley, CA