Re: [PARPORT] parport_pc_epp_write broken?

From: VOLTZ Stéphane (svoltz@wanadoo.fr)
Date: Sat Aug 10 2002 - 08:10:08 EDT

  • Next message: Brian M. Sutin: "[PARPORT] Backpack on Redhat X.X"

    Tim Waugh wrote:

    >On Fri, Aug 09, 2002 at 03:21:51PM +0200, stef wrote:
    >
    >> I've noticed that my parallel port scanner (umax_pp SANE
    >>backend) has troubles with 2.4.19, but no problem at all with
    >>2.4.18. Both kernels are built with the same .config.
    >>
    >
    >Hm. I can't see any changes between 2.4.18 and 2.4.19 that would
    >affect only EPP hardware transfers (and not software-emulated EPP
    >transfers, which seem to be working fine).
    >
    >> It seems that when doing EPP read (using ppdev) some data are
    >>losts, and some subsequent reads seem to give part of these datas.
    >>
        The bug shows itself when reading 5100*66 bytes in the following
    piece of code:
     
          mode = 1; /* data_reverse */
          rc = ioctl (fd, PPDATADIR, &mode);
    #ifdef PPSETFLAGS
          mode = PP_FASTREAD;
          rc = ioctl (fd, PPSETFLAGS, &mode);
    #endif
          mode = IEEE1284_MODE_EPP | IEEE1284_DATA;
          rc = ioctl (fd, PPSETMODE, &mode);
          rc = read (fd, dest, size - 4);

        It seems that 1024 bytes are read OK, but then there is 671 zeroes,
    then 1024 bytes from
    the scan, 671 zeroes, and so on. All is done within one read. Some other
    tests showed that when
    scan lines are shorter than 1024, there is no trouble, but when longer,
    data is corrupted.

    >
    >Odd. How about when software-emulated EPP is used? (You can use
    >IEEE1284_MODE_EPPSWE instead of IEEE1284_MODE_EPP.)
    >
        Using EPPSWE does not change anything. The problem is stille there.

    >
    >> But the scanner is mostly working doing epp read and write
    >>trough ppdev. I've tried to throw parport code from 2.4.18 into
    >>2.4.19, but it showed the same bug. I'll retry this to check I have
    >>done it right.
    >>
    >
    >Okay. Let me know what you find.
    >

        2.4.19 with parport code from 2.4.18 has still a problem. So must
    not come from there.

        I tried to set parport to EPP only in BIOS, and then things failed
    earlier. Some EPP read failed:

         mode = IEEE1284_MODE_EPP | IEEE1284_DATA;
         rc = ioctl (fd, PPSETMODE, &mode);
         rc = read (fd, &bval, 1);
         value = bval;

        returned a value of -512
     
        In this case, parport was not using an interrupt.
     

        Could it be IRQ related ?

    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 : Sat Aug 10 2002 - 08:23:14 EDT