Re: [PARPORT] ECP mode transfers in 2.4.x kernels

From: Dave Strauss (D.Strauss@motorola.com)
Date: Fri Sep 07 2001 - 12:34:16 EDT

  • Next message: Dave Strauss: "Re: [PARPORT] ECP mode transfers in 2.4.x kernels"

    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