Re: [PARPORT] ppdev hangs on read

From: stef (svoltz@wanadoo.fr)
Date: Thu Nov 07 2002 - 16:01:59 EST

  • Next message: Dan Hatton: "[PARPORT] pd loading: end user help request"

    On Mon, Nov 04, 2002 at 10:54:51AM +0000, Tim Waugh wrote:
    > On Mon, Nov 04, 2002 at 08:08:36AM +0100, stef wrote:
    >
    > Why is there no 'pp_read data got 0 bytes' message at '!!!'? Also we
    > need to know what happens after the first loop when O_NONBLOCK is not
    > set. Are we looping in pp_read or somewhere else?
    >
    > Tim.
    > */

            I moved a printk within pp_read just after the parport read. I get
    the same messages with or without O_NONBLOCK:

    Nov 7 18:32:35 xxxx kernel: parport_pc_epp_read_data(1) called
    Nov 7 18:32:35 xxxx kernel: parport_pc_epp_read_data timeout
    Nov 7 18:32:35 xxxx kernel: parport_pc_epp_read_data return 0 bytes

            but when O_NONBLOCK is set, we leave the loop with -EAGAIN. In the other
    case, we loop and get a time out each time, so we never leave pp_read.
            I added a check to read() and write in my scanner backend:

          breg = (unsigned char) (reg);
          mode = IEEE1284_MODE_EPP | IEEE1284_ADDR;
          rc = ioctl (fd, PPSETMODE, &mode);
          if (rc)
            DBG (0, "ppdev ioctl returned <%s> (%s:%d)\n", strerror (errno),
                 __FILE__, __LINE__);
          rc = write (fd, &breg, 1);
          if (rc != 1)
            DBG (0, "ppdev short write (%s:%d)\n", __FILE__, __LINE__);

          mode = 1; /* data_reverse */
          rc = ioctl (fd, PPDATADIR, &mode);

          mode = IEEE1284_MODE_EPP | IEEE1284_DATA;
          rc = ioctl (fd, PPSETMODE, &mode);
          if (rc)
            DBG (0, "ppdev ioctl returned <%s> (%s:%d)\n", strerror (errno),
                 __FILE__, __LINE__);
          rc = read (fd, &bval, 1);
          if (rc != 1)
            DBG (0, "ppdev short read (%s:%d)\n", __FILE__, __LINE__);
          value = bval;

            and with O_NONBLOCK, I got 'short read' messages as expected, but
    also 'short write' messages just before a 'short read' due to the time-out.
    I'm wondering if a failing write could be the cause of the tiemout in read.

            I still have to run it on 2.4.18 to see if the problem was here for
    long but was just unoticed.

    Regards,
            Stef

    -- 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 : Thu Nov 07 2002 - 16:04:00 EST