grant@torque.net
Wed, 9 Sep 1998 18:50:26 -0400 (EDT)
> > What you haven't told us is what mode the PARIDE drivers are using
> > and how you have set your parallel port.
>
> I'm afraid I'm ignorant of how to determine what 'mode' the paride drivers
> use. Can you or someone tell me this? Is there a FAQ or web page that
> deals specifically with the details of 'mode' use in the PARIDE suite?
> i.e. I don't know.
You appear to be using an older version of PARIDE that someone packaged
for you. Documentation for the current version can be found at
http://www.torque.net/parport/paride.html
When you load the pd driver with the "verbose=1" option, it will log
various messages which will tell us about the settings of your parallel port
and other useful things. You've never seen these messages, I guess.
That's probably because you are working entirely within X. Try typing
the 'dmesg' command - that should dump out the most recent kernel
log messages - including any messages generated by the pd driver.
Alternatively, your syslog daemon is probably filing them all away for
you in /var/log/messages - or someplace like that.
> > Please report on the CMOS settings for your drive, and also show us
> > the log messages that appear when you load pd with the "verbose=1"
> > option.
>
> I don't know what the CMOS settings for my PP drive are, but believe
> they're set to 'enhanced' PP. Is there a file in linux's /proc I can
> read to determine this without having to reboot the machine and attempting
> to examine the CMOS setting through the bios?
If this is a real problem, rebooting to check the CMOS settings can't be
a terrible hardship, surely ?
> I have not tried the "verbose=1" setting and don't expect it would reveal
> anything since the gzip -t failure errors seem so subtle.
Please don't double guess me - I asked to see that information in order to
try to help you.
> I don't appear to lose bytes...'sum' always returns exactly the correct
> number of bytes for the filesize
It would. To explain the common failure modes consider this sequence fo
hex bytes:
01 02 13 14 25 26 47 48 89 8a fb fc 7d 7e 0f 00
If you copied it to the disk and back and got
11 02 13 14 35 26 47 48 99 8a fb fc 7d 7e 0f 00
That could be a sticky bit once every four bytes. For another possibility
01 02 13 14 25 26 47 8a fb fc 7d 7e 0f 00 ff ff
might be the result of losing a couple of bytes in the middle of the data.
Finally, it is also common to see things like
01 01 02 02 13 13 14 14 25 25 26 26 47 47 48 48
If you can find a small file that was corrupted by being copied to the
disk and back, you can use "cmp -l" to get a full report on the places
where the files differ. It's usually enough to get an idea of what is
happening.
> ufo:/mnt/sparqp# cmp wp8tar.gaz wp8tar.gbz
> wp8tar.gaz wp8tar.gbz differ: char 112031, line 408
>
> I don't see a pattern there other than the crc failing unpredictably.
Well, you need to look at a slightly better report :-) Try -l on cmp.
> Ouch! OK, what's the syntax for increasing the port delay parameter for
> my parallel port when I load pd?
Read the source. Look in the source file of pd.c - I don't have 0.94 to hand,
so I can't be sure of the exact parameters - but they are documented in the
comments at the top of the file.
> > This sort of thing is most often attributable to the parallel port,
> > or cabling. Do you happen to have a switch box in the circuit -
> > or is the drive chained behind something else ?
>
> No switch box...the drive does exist attached to the same PP as the
> printer, but as I explained above, I don't use the printer in linux.
> How do I check to be certain (there's a script file somewhere created when
> I compiled 2.0.34) there's no conflict?
Try disconnecting the printer ?
> I suppose the src will have what version of paride and pd I'm
> using....hope the INFOMAGIC linux developer 6 CD-set I got this July has
> the most recent paride suite.
Not necessarily. The net is your friend. The version numbers are printed
in those messages you don't want to show me ;-)
> No. In fact, e2fsck /dev/pda1 says it's OK. *sigh*
That doesn't mean you had no i/o errors when reading or writing the disk.
If you don't have a console, or check your kernel logs, you won't know :-(
--------------------------------------------------------------------------
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:15 EST