On Mon, 10 Sep 2001 22:37:32 +0100, Philip Blundell <philb@gnu.org> wrote:
>
> >I think at least for now I think I'm just going to turn DMA off. I'm
> >still open to trying other experiments, though, if anybody wants to
> >suggest something.
>
> I guess it would be instructive to know how the corruptions
> correspond to invocations of parport_pc_fifo_write_block_dma. If
> you feel like hacking that function around a bit, how about adding
> a flag that gets set when the "DMA write timed out" condition
> happens; if the flag is set on entry to the function, dump out the
> first few bytes in `buf' to the console and clear the flag again.
>
> I'm slightly suspicious that there might be a hardware flaw in either
> your DMA controller or your parallel port. If you have another
> computer with a different chipset available, it would be interesting
> to know whether you can make the same thing happen.
>
> [ ... ]
>
> p.
>
OK, I've done this and actually gone a little farther -- because I'm
expecting a particular pattern I was able to verify the entire
contents of the DMA buffers. Everything looks good. I was also
able to verify that the problems at the printer end happen at the
point (at the same byte number into the pattern) where the DMA
times out and parport_pc driver has to count the number of bytes
which remain in the FIFO. This is, of course, the same code which
is used in the non-DMA (PIO) case.
-- 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 : Thu Sep 13 2001 - 15:56:51 EDT