[PARPORT] problems with pg on a Multia

Fri, 9 Oct 1998 08:54:12 -0400 (EDT)

First, please check your mail configuration - this message arrived at
the list server with several of the message headers missing. There
was no "To:" line and no "Subject:" header.

> I was trying to figure out why my HP cd-rw was having problems under
> linux on my little alpha multia. cdrecord sees the device, will eject the
> drawer, identify it properly, etc. However, when I ran cdrecord -dummy
> /home/xeno/blah.img cdrecord hits the device, tries a dummy write, and
> promptly segfaults after about 4 seconds. -vV on the command line
> shows lots of timeouts.

It's very hard to analyse reports like this. Please repeat your experiment
but this time make sure that your kernel messages are being logged
properly and then load pg with the "verbose=2" option. Send me _all_
the pg messages from the initial detection messages up to the first
error reports.

> This made me think that maybe, just maybe, the parallel port was to
> blame. Diligent net search showed a lack of information about anything on
> the multia regarding parallel ports with the exception that they came
> equipped with them (duh). However, when running insmod pg I see that the
> port is identified as SPP and is running in mode 1.

A year or so back, I worked with someone who had a SyQuest EZ device
and was trying to use it on an Alpha UDB. The parallel port was
completely incapable of working. It seemed that if more than a certain
number of data bits were ones, one of the control lines would "buzz".
The effect was that the EPAT controller would appear to skip several bytes
immediately following any "ff" or similar byte. Almost certainly
this was a power problem - the parallel port chip simply couldn't
drive the load reliably. This only affected writing, as I recall,
reading the parallel port doesn't stress the line drivers.

Perhaps the Multia has a similarly crappy parallel port chip.

> I've tried setting the delay to 0 on pg and using a speed of 0 when
> writing, and I still get segfaults. Note that I can mount the device with
> pcd when I need to, and read from it just fine.

This is interesting, are you sure you are getting all the data correctly ?
If so, it lends some credence to the bad parallel port hypothesis.
Try reading a largish file on this setup - and on some other drive.
Use cksum to see if they are actually the same ...

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:32 EST