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

From: Dave Strauss (D.Strauss@motorola.com)
Date: Mon Nov 19 2001 - 18:04:43 EST

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

    It would be interesting to find out what hardware he's using.
    In any case it sounds exactly like the problem I have -- the
    hardware messes up if the mode is changed while the FIFO is
    not empty.

    -- Dave Strauss

    On Mon, 19 Nov 2001 13:58:14 +0000, Tim Waugh <twaugh@redhat.com> wrote:
    >
    > Simon Krix has reported another instance of what seems to be this
    > problem, over on libieee1284-list. The archive is at
    > sourceforge.net/projects/libieee1284, '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.
    >
    > Tim.
    > */
    >
    > On Tue, Sep 11, 2001 at 05:49:57PM -0400, Dave Strauss wrote:
    >
    > > On Mon, 10 Sep 2001 22:37:32 +0100, Philip Blundell <philb@gnu.org> wrote:
    > > > =20
    > > > >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.
    > > > =20
    > > > 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.
    > > > =20
    > > > 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.
    > > > =20
    > > > p.
    > > > =20
    > >=20
    > > 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.
    > >=20
    > > I'll try the buf dump when I get a chance.
    > >=20
    > > -- Dave Strauss
    > >=20
    > > -- To unsubscribe, send mail to: linux-parport-request@torque.net --
    > > -- with the single word "unsubscribe" in the body of the message. --
    >
    > --5KxTQ9fdN6Op3ksq
    > Content-Type: application/pgp-signature
    > Content-Disposition: inline
    >
    > -----BEGIN PGP SIGNATURE-----
    > Version: GnuPG v1.0.6 (GNU/Linux)
    > Comment: For info see http://www.gnupg.org
    >
    > iD8DBQE7+Q/1yaXy9qA00+cRAuTxAJ4pVngZQuXLMblsWxejbOh1Mu/K6wCdE17i
    > mNiqvZzb2CNNLB+i9EcKgxg=
    > =aNZp
    > -----END PGP SIGNATURE-----
    >
    > --5KxTQ9fdN6Op3ksq--
    >

    -- 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 : Mon Nov 19 2001 - 18:09:03 EST