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