root (root@ufo.westsound.com)
Sat, 12 Sep 1998 01:11:25 -0700 (PDT)
reply to: amicus@orcalink.com
On Sat, 12 Sep 1998, David Campbell wrote:
>
> Do you have access to a second machine to test the drive. There
> are a number of IO chipsets which are known to cause problems:
>
> a) Early WinBond chipsets have bad EPP timing
> b) Some "beta" NatSemi IO chipsets have broken EPP.
>
> The "beta" NatSemi chipsets were released for testing/development purposes
> but found there way into some mainboards. Very few and far between.
> WinBond have fixed their problems about a year ago (can not confirm this).
>
> > 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.
>
> Iomega with their drivers keep an eye out for "buggy" chipsets and use PS2
> mode when they are found (from verbal conversation with Iomega driver
> developer).
OK, but what is the PS2 mode? Are you referring to this in the linux
environment? Grant mentioned that Syquest's drivers take advantage of
some DOS idiosyncracies to adjust the timing but the linux side doesn't
have the same options to do so and must make a best guess. If Iomega has
drivers that monitor for "buggy" chipsets, why can't the PARIDE suite
follow suit?
>
> > Perhaps the speed of this CPU (AMDk86-200 w/MMX) is trying to push
> > the PP too fast?
>
> This is a mainboard issue since the board has something like three different
> bus speeds (CPU, PCI and ISA). The PCI <=> ISA bridge on some mainboards
> is known to flakey when doing 32 bit IO. What happens is that the correct
> amount of data is transfered but some of the bytes are replicated and overwrite
> other bytes. eg:
That resembles in some fashion what I'm witnessing in my linux setup.
When I ran cmp -l tests of my Sparq drive filenames against the source, 3
fields with values like 134572 157 177 were returned. Grant pointed
out that this appeared to indicate a 'sticky' bit (2nd and 3rd fields only
differed for the middle digit) and typically the number of crc errors
returned was less than 10 for something like a 38 meg file. But this was
while my PARIDE parameters were invoked in mode 5. (EPP-32) Changing
those parameters to mode 3 (EPP-8) during bootup appeared to eliminate the
crc errors the Sparq drive was returning just often enough to corrupt
important data files although most often not smaller files. Hopefully
this problem ONLY appears in linux and not other operating systems for the
PP Sparq drive. I'm wondering if I need to reformat my Sparq cart in
linux after changing from EPP-32 to EPP-8 for it. What are the downsides
of my change? Is this serious enough for me to try to return the
motherboard and/or purchase a different one? Somewhere, a list of 'safe'
momboards, especially for linux and issues like this should be maintained.
>
> Drive ParPort ISA Bus PCI Bus
> ABCD => ABCD => ABCD => ABBD
>
> Trouble is that not many devices on the ISA bus expect 32 bit IO, the only
> device that would regularly use 32 bit IO would be IDE (which now hangs
> off the PCI bus).
>
> Without reading Grant's mind I do not know if the PARIDE driver complains
> if the device returns different amount of data than expected.
> eg: 511 or 513 bytes when 512 expected.
When I experienced these errors, the filesize always appeared to match the
source, but the crc value returned (sum) did not.
>
> SCSI complains bitterly since the last byte is the status byte. The mid-level
> driver will only allow something like 10 possible answers. Any other and the
> kernel panics (I know from experience :-).
>
> > 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).
>
> My tests shows that most hardware throttle the ISA bus to 1.0E+6 accesses
> per seconds (asm loop polling a single port). This puts an upper limit of
> arround 1MB/sec through a parallel port. This would be considered a
> "poor" drive by IDE or SCSI standards.
I've noticed something of that order as well. My Sparq is typically only
20% as fast transferring/reading/writing files as my IDE or SCSI drives.
I was willing to accept this limitation in favor of the PP portability and
ease of backing up to a removable media drive. But if I'm going to have
to speculate about the data integrity, then there's a pronounced shift
against the Sparq or any PP drive.
>
> The one thing about parallel ports is that nearly every machine has one.
> (Although not every parallel port is equal)
>
> > 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 will join the gripe fest when *every* PC comes with an external SCSI
> connector (or maybe even USB). Until then every PC will still have a
> parallel port.
>
> David Campbell
> =======================================================
Thanks for your comments and insight, Dave.
-- 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:16 EST