Re: [PARPORT] Explanation of "stuck" FIFO?

From: Greg Nelson (ghn@qtmsys.com)
Date: Tue Feb 29 2000 - 11:35:38 EST

  • Next message: Matthew S. Moore: "[PARPORT] unsupported scsi driver"

    Tim,

    > > Feb 28 14:00:51 linux kernel: parport0: In mode 0x10
    > > Feb 28 14:00:51 linux kernel: parport0: ECP direction: forward
    > > Feb 28 14:00:51 linux kernel: parport0: Using ECP mode
    > > Feb 28 14:00:51 linux kernel: parport0: ECP direction: reverse
    > > Feb 28 14:00:51 linux kernel: parport0: Using ECP mode
    > > Feb 28 14:00:56 linux kernel: parport0: FIFO is stuck
    > > Feb 28 14:00:56 linux kernel: parport0: wrote 0/7 bytes
    > > Feb 28 14:00:56 linux kernel: parport0: Using ECP mode
    > > Feb 28 14:00:56 linux kernel: parport0: wrote 7/7 bytes
    > >
    > > This only occurs
    > > when I've switched from reverse mode (by using read()) to forward mode
    > > (by using write()), and it also seems a little odd that I never get
    > > the "ECP direction: forward" that ought to correspond to the
    >
    > But you do!

    Not exactly. This is trace is from a program which opens the port,
    then reads from it, and then writes to it again before closing. I
    forgot to say that. The "ECP direction: forward" at the beginning of
    the trace is from parport_negotiate(); the "reverse" line is from
    ecp_forward_to_reverse(). When I turn back around to write again is
    where things get stuck, and where I seem to be missing the message
    from ecp_reverse_to_forward(). This could occur if
    parport_wait_peripheral() fails; I haven't tracked down if this is
    what is happening yet.

    > Yes, you have to (a) have ECP enabled in the BIOS and (b) have compiled
    > parport_pc with CONFIG_PARPORT_PC_FIFO. When parport_pc starts up it will
    > say 'using FIFO' or 'using DMA' if it's going to actually use hardware
    > assistance.

    I have ECP enabled, and I am compiling with CONFIG_PARPORT_PC_FIFO. I
    looked back at the traces and it is, in fact, the case that when it
    gets "stuck," it is using DMA, and when it doesn't get stuck, it is
    not using DMA. I'm still trying to understand why the DMA would make
    this difference.

    Greg

    -- 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 : Tue Feb 29 2000 - 11:37:36 EST