Re: [hpoj-devel] 2.4.0 kernel issues

[<pa...@rc...>]

Hi, Burkhard.

> in order to find a starting point for debugging the modules on a
> 2.4 kernel I loaded the modules with debugging fully turned on
> and ran "scanimage --test". While on 2.2.14 the scan completes
> smoothly I see that on a 2.4 kernel after while only 0 nibbles 
> are read back from the parport. David, if you think you can
> help me interpret that debug log, please give me a note. (About
> 65k data - sorry, I was unsure, which debug levels I could 
> turn off).
Sure, go ahead and send to me (pa...@rc..., not to the mailing list)
the debug output, both from 2.2.x and 2.4.x.  Hopefully I can shed some
light from the protocol standpoint where things are going wrong.  However,
if you're using syslog to capture the output (I don't know of any other way),
there exists the possibility of lost or corrupted messages when the messages
are generated too quickly, so the results may be inconclusive.

> Since the underlying parport and its interface have changed
> quite a bit from 2.2 to 2.4 I suspect that the premature
> link close seen on a 2.4 kernel being caused by some now
> improper handshaking.
Once the peripheral has been detected, all the parallel-port handshaking is
initiated by ieee12844pp, using functions provided by parport to read and
write the registers that map to the control, status, and data lines.  I
doubt a kernel change could break this.  It would be more likely that
something changed about the way the kernel lets drivers (such as ieee12844pp)
poll for a little while, release the CPU, and get rescheduled to poll some
more later.

> If have noticed that some parts of
> the lp driver have been rewritten. Any comments?
lp is simply another client of parport and is not used by ieee12844pp.
However, it might be helpful to study the changes in lp, because that might
point out what needs to be changed for ieee12844pp, which uses more
complicated signalling than lp but still faces the same issues about needing
to poll for a while, delay, poll some more, etc.

David