root (root@ufo.westsound.com)
Fri, 11 Sep 1998 04:37:26 -0700 (PDT)
reply to: amicus@orcalink.com
Mr. Guenther,
Hi! I've taken some time getting back to you with the results of
further testing because, frankly, I was exhausted from frustration the
past couple of days and I had another pressing project to complete. But I
must say, you really know your PARIDE src and related hardware. I'm
impressed. You may be guessing by now that I had a measure of success
based on your advice and suggestions. Still, I thought I should explain
the route I took to find some relief before posing any new questions.
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.
I finally settled (by process of elimination) on including that string in
loadlin's linux.bat file which I'm attaching for your curiosity. The
latter string did not cure the crc errors generated by the Sparq and/or PP
device. But I did notice the following in the prompts generated during
initialization on bootup of linux:
Sep 10 23:51:18 ufo kernel: Partition check:
Sep 10 23:51:18 ufo kernel: sda: sda1
Sep 10 23:51:18 ufo kernel: sdb: sdb1
Sep 10 23:51:18 ufo kernel: sdc: sdc1
Sep 10 23:51:18 ufo kernel: sdd: sdd1
Sep 10 23:51:18 ufo kernel: sde: sde4
**************************************************************************
I noticed the EPP-32 string remembering your caveat regarding the same
**************************************************************************
Sep 10 23:51:18 ufo kernel: pda: epat 1.01, Shuttle EPAT chip c6 at 0x378,
mode
5 (EPP-32), delay 2
*******************************************
Sep 10 23:51:18 ufo kernel: pda: SyQuest SparQ, master, 1960560 blocks
[957M], (1945/16/63), removable media
Sep 10 23:51:18 ufo kernel: pda: pda1
Sep 10 23:51:18 ufo kernel: hda: hda1 hda2 < hda5 hda6 hda7 >
Sep 10 23:51:18 ufo kernel: hdb: hdb1 hdb2 < hdb5 hdb6 >
Sep 10 23:51:18 ufo kernel: VFS: Mounted root (ext2 filesystem) readonly.
Sep 10 23:51:18 ufo kernel: lp: Driver configured but no interfaces found.
Sep 10 23:51:18 ufo kernel: Rocketport device driver module, version 1.12,
9-Sep-96
Sep 10 23:51:18 ufo kernel: Rocketport controller #0 found at 0x180, 1
AIOPs
Sep 10 23:51:18 ufo kernel: 0 PCI boards found
Mode 5 with the 2 second delay did not cure the errors generated by the
Sparq and/or PP. But 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:
Sep 10 23:59:45 ufo kernel: pda: epat 1.01, Shuttle EPAT chip c6 at 0x378,
mode
3 (EPP-8), delay 2
Sep 10 23:59:45 ufo kernel: pda: SyQuest SparQ, master, 1960560 blocks
[957M], (1945/16/63), removable media
I'm guessing there may be an 'EPP-16' with, possibly, mode 2?
So my next questions is about tuning or optimizing what's available to me,
I guess. Would there be any advantages to an 'EPP-16' over an 'EPP-8' to
me? 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. Would
I be well advised to reformat the drive with any of these changes?
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.)
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?
What were you saying about discovering that EPP-32 was prone to problems
with some makes and brands of PP drives? 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).
I hope my difficulties with this will help others who may not even be
aware yet that they HAVE a problem with the integrity of their data (in
linux) on their Sparq drive. Maybe someone could post this in one of the
newsgroups, although I don't see much there along technical lines of
discussion regarding PP drives....mostly just gripe fests.
I hope this e-mail makes it to you this time. Lemme know so I don't get
too wound up with suspense.
Thanks again.
rem Sample DOS batch file to boot Linux.
rem First, ensure any unwritten disk buffers are flushed:
smartdrv /C
rem Start the LOADLIN process:
c:\loadlin\loadlin c:\loadlin\zimage mount root=/dev/sdc1 ro pd.drive0=0x378,0,0,3,0,0,2,0
N‹§²æìr¸›zǧvf¢–Ú%Š{±¥ªé¢»kz«ž²Ûh®«žÂ+a¶¬Šx%{
+véì¹» ®&ÞŠ{ayº ʇí…éž²Æ
This archive was generated by hypermail 2.0b3 on Wed 30 Dec 1998 - 10:18:16 EST