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

From: Dave Strauss (D.Strauss@motorola.com)
Date: Fri Sep 07 2001 - 15:54:52 EDT

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

    On Fri, 07 Sep 2001 19:49:42 +0100, Philip Blundell <philb@gnu.org> wrote:
    >
    > >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?
    >
    > Well, it's all a bit hairy, particularly the stuff using "test
    > mode" to figure out how many bytes were in the FIFO. Theoretically
    > I think it should cope with the printer suddenly going un-busy at a
    > bad time. If your delay is always 35 seconds long then it seems
    > unlikely that it's caused by a byte being read in unexpectedly.
    >
    > Do you know what chip your parallel port uses?
    >
    > If you have any way to find out, it would be useful to know exactly what the
    > bad data the printer is seeing is -- whether it's a data byte being
    > duplicated, or random garbage being inserted in the middle.
    >
    > p.
    >
    >

    Here's an example of what the printer sees. The printer is expecting
    a repeating pattern of "123456789\n", and when it sees something
    different it dumps the byte it received, what it expected, then
    some context (up to 15 bytes before, the offending byte, then up
    to 15 bytes after if they are available). It also prints the
    current byte count.

    After an error it tries to re-synch with the test pattern; hence the
    "Starting download ..." messages.

    At the end (when it gets the end marker) it prints the total count
    of bytes received. The total should be 5041228.

     - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

    Starting download ...
    ***** 668438: 30 should be 31
    ******
    39,30,0a,31,32,33,34,35,36,37,38,39,30,0a,30
    30 <===
    0a,31,32,33,34,35,36,37,38,39,30,0a,31,32,33
    ******

    ***** 668439: 0a should be 31
    ******
    30,0a,31,32,33,34,35,36,37,38,39,30,0a,30,0a
    0a <===
    31,32,33,34,35,36,37,38,39,30,0a,31,32,33,34
    ******

    ***** 668470: 0a should be 39
    ******
    36,37,38,39,30,0a,31,32,33,34,35,36,37,38,0a
    0a <===
    31,32,33,34,35,36,37,38,39,30,0a,31,32,33,34
    ******
    Starting download ...

    ***** 668471: 0a should be 31
    ******
    0a,
    0a <===
    31,32,33,34,35,36,37,38,39,30,0a,31,32,33,34,******

    all downloads so far: 5041229

     - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

    It looks like the first error was a repeat of "0" followed by
    an extra newline. The second error looks like a missing "9".

    -- 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 - 15:57:35 EDT