OK, I've finally gottem back to this issue, or rather issues, again.
To recap: I have seen several problems when trying to get the lp
driver to send data to a printer in ECP mode. At least some of the
problems require rewriting parts of lp.c, and some of the problems are
related to code in parport_pc which runs only if the parport driver is
built with CONFIG_PARPORT_PC_FIFO (which is not the default for the
Redhat 7.1 distribution).
I'd like here to address one of the problems in parport_pc: garbage
data when the DMA-assisted compatibility mode code is used. This is
currently the biggest stumbling block I have to using ECP-enabled
parallel port code.
The problem only shows up when I download a lot of data in
compatibility mode to a printer which at some point stops accepting
data for an extended period. When this occurs, I get corrupted data
at the printer. I also see some timeout messages on the host PC:
DMA write timed out
parport0: FIFO is stuck
parport0: BUSY timeout (1) in compat_write_block_pio
DMA write timed out
In order to get more information about the problem, I installed a
special diagnostic program on the printer (*) which does the following:
(1) Wait for a "start pattern" marker on the parallel port
(2) Read data, check for 11-byte "test pattern".
(3) repeat step 2 until either error in pattern or "end pattern" marker
(4) Dump statistics
This test runs with no problem downloading
I then modified the diagnostic to add a 35 second delay after a random
number (in this case 221397) of bytes were downloaded. When I made
this change, I started seeing the timeout messages and started seeing
errors in the test pattern.
The statistics indicate that when there is an error, the printer
receives either one or two bytes more than the PC thinks it sent.
Also, there is a correlation between the timeouts on the host and the
errors at the printer, but it's not 1-to-1; that is, every time I get
errors at the printer I see a timeout at the host, but sometimes I see
a timeout at the host without errors at the printer.
I'm thinking that this indicates some sort of race condition in the
DMA-assisted compatibility mode code, and I'm hoping that someone who
knows the code better than I do will see this and recognize where it
could be. Things that come to (my) mind are, for example: the code
assumes when it resets various counts after a timeout that the FIFO is
full -- what if the printer just happens to read a byte after the
timeout occurs? Can this happen?
If anyone has any ideas of things to try, I would be happy do so.
Thanks.
-- Dave Strauss
(*) - Professional driver, closed course. Do not try this at home!
On Wed, 29 Aug 2001 17:12:18 -0400, Dave Strauss wrote:
>
> On Wed, 29 Aug 2001 21:46:38 +0100, Philip Blundell <philb@gnu.org> wrote:
> >
> > [ ... ]
> >
> > >Beyond that, has anyone seen any similar problems? Any ideas for things
> > >to try?
> >
> > I haven't heard of similar problems, but I suspect the DMA-assisted
> > compatibility mode stuff hasn't seen all that much testing.
> >
> > What kind of failure are you seeing -- is it just the same sort of
> > non-specific corruption you were getting in the software ECP case?
> >
> > p.
> >
>
> Yes, just general corruption. I've got multi-megabytes of data and
> it's hard to tell where the problem is. One possible clue is that
> in both cases the printer tends to accept data in chunks which are
> not related to the size of the DMA or any other buffers on the host.
> Hence I get messages like this (from dmesg):
>
> DMA write timed out
> parport0: FIFO is stuck
> parport0: BUSY timeout (1) in compat_write_block_pio
> DMA write timed out
> etc.
>
> Maybe there's a problem when the transfer is restarted. And maybe
> the hardware on my PC is just messed up.
>
> -- Dave Strauss
>
-- 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 2b29 : Fri Sep 07 2001 - 12:38:27 EDT