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

From: Tim Waugh (
Date: Mon Nov 19 2001 - 08:58:14 EST

  • Next message: Tom Badran: "[PARPORT] ppSCSI"

    Simon Krix has reported another instance of what seems to be this
    problem, over on libieee1284-list. The archive is at, 'Subject: The Next Bug.'.
    Here's the description:

      "The next problem I had was sending packets of data to the scanner
      with a DMA-enabled parport_pc.o (as before, using libieee1284's
      ppdev interface). It seemed to send corrupt data. Instead of 0xec 20
      00 00 00 00 00 00 I was seeing something that looked a lot like 0x20
      00 00 00 00 00 00 ec. This might have been an off-by-one error when
      stepping though the buffer, as the byte after the end of the buffer
      is likely to also be ec - but I didn't find the problem. I solved it
      by loading parport_pc.o without a DMA channel (I'll have to verify
      that the DMA channel is still right, I can't trust my motherboard to
      leave it alone). I also had this error in the kernel log (not a
      debug kernel):

      parport0: BUSY timeout (-4) in compat_write_block_pio"

    The BUSY timeout business might or might not be related; it happens
    after the actual data transfer I think.


    On Tue, Sep 11, 2001 at 05:49:57PM -0400, Dave Strauss wrote:

    > On Mon, 10 Sep 2001 22:37:32 +0100, Philip Blundell <> 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.
    > >
    > I'm also slightly suspicious of the hardware, but unfortunately
    > I've only got the one machine that has DMA and is running a 2.4.x
    > kernel. The only other 2.4.x machine I have access to at the
    > moment doesn't have DMA.
    > I'll try the buf dump when I get a chance.
    > -- Dave Strauss
    > -- To unsubscribe, send mail to: --
    > -- with the single word "unsubscribe" in the body of the message. --

    -- To unsubscribe, send mail to: --
    -- with the single word "unsubscribe" in the body of the message. --

    This archive was generated by hypermail 2b29 : Mon Nov 19 2001 - 09:00:43 EST