grant@torque.net
Sat, 12 Sep 1998 13:01:23 -0400 (EDT)
> After your comments regarding the cmp -l evaluations, I undertook the task
> of somehow getting the pd.drive0=0x378,0,0,3,0,0,2,0 string into my boot
> sequence. Actually, I started with pd.drive0=0x378,0,0,5,0,0,3,0 after
> spending hours compiling and attempting to create rescue disks and lilo
> configurations that would work from anywhere beside the 'mbr' on my HD.
This would all have been so much easier for you if you used modules.
> I discovered substituting
>
> pd.drive0=0x378,0,0,3,0,0,2,0
>
> did effectively remedy and remove the errors returned by the Sparq and/or
> PP when copying wp8tar.gz to the Sparq drive. However, I noticed the
> following upon initialization with that substitution:
>
> pda: epat 1.01, Shuttle EPAT chip c6 at 0x378, mode 3 (EPP-8), delay 2
>
> I'm guessing there may be an 'EPP-16' with, possibly, mode 2?
Don't guess. Read the source. EPP-16 is mode 4 in the epat driver.
> Would there be any advantages to an 'EPP-16' over an 'EPP-8' to me?
EPP-16 ought to be slightly faster than EPP-8, and usually is. The only
way to know for sure is to some benchmarking.
> I could try reducing the time delay now although I'm wondering if the
> delay only affects the time the drive waits before initiating a transfer,
> or whether it affects the rate of transfer throughout the process.
The delay parameter slows down every access to the parallel port. There
is no way, other than experimentation, to know if you can reduce the port
delay in mode 3. Try it, do a few copies and see if (a) you get a significant
performance improvement, and (b) if there is any data corruption.
The problem that you are seeing is rare. We know it exists, that's why the
tuning parameters are there. But, most modern parallel ports work happily
with delay 0 in EPP-32 mode and achieve nearly 500KB/s transfer rates.
> Would I be well advised to reformat the drive with any of these changes?
"reformatting" will only repair filesystem errors. You should be concerned
about the integrity of the data on your disk(s), so rewriting the files
is probably a good idea.
> Finally, is this indicative of a flakey drive or PP? Should I try to
> return the Sparq for a replacement or seek a differnt momboard? (The PP
> is built into the motherboard.)
I believe you said in some other posting that you have other parallel port
devices. If this problem occurs only with the SparQ, then I would suspect it.
The only rational explanation for the specific single bit errors that you
were seeing is noise on the cable. This could be caused by a "cold solder"
joint in one of the connectors, or a bad capacitor in the damping circuits
at either end of the cable. You are on your own to try to diagnose
exactly where the problem is happening.
> Are other brands (IOmega?) of PP drives with removable media less prone to
> this kind of bug? I don't remember this kind of problem when I was using
> a 486 board (AMDx86-133) with the PP built-in. Perhaps the speed of this
> CPU (AMDk86-200 w/MMX) is trying to push the PP too fast? Do you think it
> would do any good to contact Syquest and advise them of this problem, or
> are they going to be around long enough to care?
You have some marginal hardware. Figure out which bit it is before
complaining.
> What were you saying about discovering that EPP-32 was prone to problems
> with some makes and brands of PP drives?
I believe I was referring to the parallel ports themselves, but a similar
observation could be made for some of the drive-side adapters. This is
low-end technology, problems happen.
> I'm feeling less eager to
> purchase PP drives in the future and may try to stick with scsi, ide,
> and/or USB drives (when they're available and linux supports them).
That's your choice, of course. But, I can tell you that I've seen
much more serious problems with SCSI and IDE devices. You cannot
generalise from a single instance of flaky behaviour and condemn the
entire class of devices.
--------------------------------------------------------------------------
Grant R. Guenther grant@torque.net
--------------------------------------------------------------------------
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Wed 30 Dec 1998 - 10:18:17 EST