On Wed, Oct 23, 2002 at 07:16:10AM +0200, stef wrote:
> The are also a few lines changed in parport_pc.c regard non
> blocking read changes. Would it be an interesting test to back out
> these changes, or will this fail due changes in timeout handling ?
By all means, but I don't think that they affect EPP operations. The
most useful test would be to put printks in at various places starting
at ppdev.c so we can find out what read functions are returning what
and why.
The fact that setting O_NONBLOCK causes it to start working means that
something isn't working right. The loop in ppdev.c is:
1. mark the device's timeout as 'never' if O_NONBLOCK is set
2. call parport_read
3. if we got bytes, stop
4. if O_NONBLOCK is set, stop
5. loop to step 2
The parport_read function just calls the appropriate read function in
the low-level driver (parport_pc in this case, which falls back on
ieee1284_ops if there's no hardware EPP support).
And parport_pc's read functions for EPP didn't have any changes for
O_NONBLOCK. And neither did ieee1284_ops.
Can someone try actually turning on all the DEBUG macros in the
parport code and adding printks to things like ppdev.c, parport_pc.c
and ieee1284_ops.c around EPP read code path, so we can actually see
what's going on?
Tim.
*/
-- 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 : Wed Oct 23 2002 - 05:08:11 EDT