hpoj-devel

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

Re: [hpoj-devel] 2.4.0 kernel issues

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

> BTW: David, I have to admit that I don't know very much about the 
> IEEE1284.4 protocol (I am familiar with SPP parports though). Could 
> you suggest a (desirably concise) source for reading?
Hi, Burkhard.  Despite the name, the hpoj software doesn't actually
implement the IEEE 1284.4 transport protocol.  It only implements HP's
MLC protocol, on which 1284.4 is based.  There's a link to the latest
1284.4 draft on the webpage (under "useful links"); you might want to
save a copy of it in case it goes away.  I'll send you and Damcha a
copy of the MLC spec.

IEEE 1284-1994 ("IEEE Standard Signaling Method for a Bidirectional
Parallel Peripheral Interface for Personal Computers") may be ordered
in hardcopy form from the IEEE.  For that matter, you may be able to order
1284.4 as well by now.  It was supposed to have been finished a long time
ago.

All I see in your 2.4 debug output is an open of the scan channel immediately
followed by a close.  I assume this output corresponds to the SANE+PTAL
output you sent on September 20.  In that case, we saw a successful open,
and the write() of two bytes (the SCL "Esc-E" reset command) failed (returned
-1), so the SANE backend had no choice but to give up and close the channel.
I would suggest examining the code path taken by writes (see mlc_sendmsg()).
Perhaps there's a mismatch in the mlc_proto_ops structure.  You could also
try hacking the PTAL_LOG_DEBUG statement around line 884 of ptal/ptal.c so
it also prints the value of errno.

Looking back at Damcha's original message reporting compile problems with
2.4, there were warnings about initializing mlc_proto_ops:
> ieee12844.c:1541: warning: initialization from incompatible pointer type
> ieee12844.c:1542: warning: initialization from incompatible pointer type
> ieee12844.c:1545: warning: initialization from incompatible pointer type
> ieee12844.c:1547: warning: excess elements in struct initializer
> ieee12844.c:1547: warning: (near initialization for `mlc_proto_ops')
Line 1542 is for mlc_sendmsg and 1543 is for mlc_recvmsg, so it's obviously
a mismatch in this table that's causing writes to fail.

David

Re: [hpoj-devel] 2.4.0 kernel issues

[Burkhard K. <bu...@bu...>]

David Paschal
> 
> All I see in your 2.4 debug output is an open of the scan channel immediately
> followed by a close.  I assume this output corresponds to the SANE+PTAL
> output you sent on September 20.  In that case, we saw a successful open,
> and the write() of two bytes (the SCL "Esc-E" reset command) failed (returned
> -1), so the SANE backend had no choice but to give up and close the channel.
> I would suggest examining the code path taken by writes (see mlc_sendmsg()).
> Perhaps there's a mismatch in the mlc_proto_ops structure.  You could also
> try hacking the PTAL_LOG_DEBUG statement around line 884 of ptal/ptal.c so
> it also prints the value of errno.
> 
> Looking back at Damcha's original message reporting compile problems with
> 2.4, there were warnings about initializing mlc_proto_ops:
> > ieee12844.c:1541: warning: initialization from incompatible pointer type
> > ieee12844.c:1542: warning: initialization from incompatible pointer type
> > ieee12844.c:1545: warning: initialization from incompatible pointer type
> > ieee12844.c:1547: warning: excess elements in struct initializer
> > ieee12844.c:1547: warning: (near initialization for `mlc_proto_ops')
> Line 1542 is for mlc_sendmsg and 1543 is for mlc_recvmsg, so it's obviously
> a mismatch in this table that's causing writes to fail.
That would be too easy. As I wrote in my posting accompanying my patch
I have already taken care of that. After applying my patch, the module
compiles without any such warnings. I just double checked, all pointer
assignments to the mlc_proto_ops structure are in alignment with 
the definition of this structure in net.h.

Burkhard

-- 
Burkhard Kohl			Tel/FAX: +49 30 698 15 905
Melchiorstr. 8			bu...@bu...
10179 Berlin			

Re: [hpoj-devel] 2.4.0 kernel issues

[damcha <da...@cy...>]

Hello all,

Sorry I've been silent for a few days, but I experienced a major disk crash,
and had to change my HD and reinstall my system...
Almost everything is in place now, and as soon as I can I'll spend a a bit of
my time working on the project.

Damcha

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d--(+) s: a-- C++ UL+++ P+>++ L+++ E(+) W++ N+ o? K- w-- O? M V?
PS++ PE- Y+ PGP t+ 5 X++ R(+) tv-(+) b+ DI D++ G e+++ h--- r++ y+++*
------END GEEK CODE BLOCK------
					 See http://www.geekcode.com

Re: [hpoj-devel] 2.4.0 kernel issues

[Burkhard K. <bu...@bu...>]

David Paschal
> All I see in your 2.4 debug output is an open of the scan channel immediately
> followed by a close.  I assume this output corresponds to the SANE+PTAL
> output you sent on September 20.  In that case, we saw a successful open,
> and the write() of two bytes (the SCL "Esc-E" reset command) failed (returned
> -1), so the SANE backend had no choice but to give up and close the channel.
> I would suggest examining the code path taken by writes (see mlc_sendmsg()).

David, that set me onto the right track. The culprit was an old bug in
mlc_sendmsg which just happened to remain silent with 2.2 kernel version
because no flag in msghdr->flags was set from the socket layer:

    int nonblock = msg->msg_flags & MSG_DONTWAIT;

    /* XXX currently does not work with poll() */
    nonblock = 0;

    if (debug & 0x02)
        printk ("mlc_sendmsg: %p credit=%d\n", sock, so->mycredit);
    if (msg->msg_flags & ~MSG_DONTWAIT) 
                         ^^^^^^^^^^^^^^
        return = -EOPNOTSUPP;

The code checked for the supplement of MSG_DONTWAIT instead of the
flag itself. As long as no flag was set, all worked well but as 
soon as any flag besides MSG_DONTWAIT is set, the call will fail with
an error return of -95, which is -EOPNOTSUPP. That's exactly 
what happend with a 2.4.0-test kernel, msg_flags was set to 
MSG_EOR, thus revealing this bug.

I' ll be posting my patch seperately, asking everybody with 
a 2.4 kernel to test it out.

I see a lot of "already open" messages from the ptal layer - maybe
we have other problems as well, but "scanimage --test" runs on my 
box now successfully.

BTW: in ieee12844/Makefile.in the "cp" expression to move kernel
modules to the appropriate location was commented out. Was this
done for any particular purpose? I am asking because it meant
that the modules had to be installed by hand.

Burkhard
-- 
Burkhard Kohl			buk at/auf buks.ipn.de

Re: [hpoj-devel] 2.4.0 kernel issues

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

Hi, Burkhard.

> I see a lot of "already open" messages from the ptal layer - maybe
> we have other problems as well, but "scanimage --test" runs on my 
> box now successfully.
That's normal, due to the somewhat underhanded method I had to use to
make the SANE HP backend work with PTAL.

> BTW: in ieee12844/Makefile.in the "cp" expression to move kernel
> modules to the appropriate location was commented out. Was this
> done for any particular purpose? I am asking because it meant
> that the modules had to be installed by hand.
That part is left over from the previous maintainers.  The new
"make install" I added to the top-level directory doesn't even invoke
makefiles in subdirectories.  By default, it installs the modules under
/usr/local/lib, which doesn't help make it accessible to modprobe.
Based on John Chmielewski's message from September 13, it sounds like it
could be moved to (or possibly symlinked in) /lib/modules/misc, but there's
still the problem that modprobe doesn't detect that ieee12844pp.o depends
on parport_probe, not just parport and parport_pc.  My idea was to add a
dummy function in ieee12844pp.c which never got called but which made a
reference to a function in parport_probe (for example, parport_probe()).
Since you're working on this code at the moment could you try this out and
let me know if it fixes the problem (or I can try it myself later).

David

Re: [hpoj-devel] 2.4.0 kernel issues

[damcha <da...@cy...>]

Hello, 

> could be moved to (or possibly symlinked in) /lib/modules/misc, but there's

Btw, the path for the modules in 2.4 would be
/lib/modules/2.4.0-test8/kernel/drivers/parport/ I suppose (misc doesn't exist any more).

Damcha

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d--(+) s: a-- C++ UL+++ P+>++ L+++ E(+) W++ N+ o? K- w-- O? M V?
PS++ PE- Y+ PGP t+ 5 X++ R(+) tv-(+) b+ DI D++ G e+++ h--- r++ y+++*
------END GEEK CODE BLOCK------
					 See http://www.geekcode.com

Re: [hpoj-devel] 2.4.0 kernel issues

[Burkhard K. <bu...@bu...>]

David Paschal
> Hi, Burkhard.
> 
> > BTW: in ieee12844/Makefile.in the "cp" expression to move kernel
> > modules to the appropriate location was commented out. Was this
> > done for any particular purpose? I am asking because it meant
> > that the modules had to be installed by hand.
> That part is left over from the previous maintainers.  The new
> "make install" I added to the top-level directory doesn't even invoke
> makefiles in subdirectories.  By default, it installs the modules under
> /usr/local/lib, which doesn't help make it accessible to modprobe.
> Based on John Chmielewski's message from September 13, it sounds like it
> could be moved to (or possibly symlinked in) /lib/modules/misc, but there's
> still the problem that modprobe doesn't detect that ieee12844pp.o depends
> on parport_probe, not just parport and parport_pc.  My idea was to add a
> dummy function in ieee12844pp.c which never got called but which made a
> reference to a function in parport_probe (for example, parport_probe()).
> Since you're working on this code at the moment could you try this out and
> let me know if it fixes the problem (or I can try it myself later).
parport_probe no longer exist in the 2.4 kernel, so there it will 
be some other candidate. This issue should be resolved with the use 
of the new parport_driver_register interface. So it will be a mixed
(kernel version dependant) solution.

Burkhard
-- 
Burkhard Kohl			bu...@bu...

Re: [hpoj-devel] 2.4.0 kernel issues

[John L. C. <jl...@cf...>]

On Tue, Sep 26, 2000 at 12:12:29AM -0700, David Paschal wrote:

<snip><snip><snip>

> That part is left over from the previous maintainers.  The new
> "make install" I added to the top-level directory doesn't even invoke
> makefiles in subdirectories.  By default, it installs the modules under
> /usr/local/lib, which doesn't help make it accessible to modprobe.
> Based on John Chmielewski's message from September 13, it sounds like it
> could be moved to (or possibly symlinked in) /lib/modules/misc, but there's
> still the problem that modprobe doesn't detect that ieee12844pp.o depends
> on parport_probe, not just parport and parport_pc.  My idea was to add a
> dummy function in ieee12844pp.c which never got called but which made a
> reference to a function in parport_probe (for example, parport_probe()).
> Since you're working on this code at the moment could you try this out and
> let me know if it fixes the problem (or I can try it myself later).

If you do a modprobe -c, you will see the directories that are searched
for modules.  Besides directories under specific kernel versions, modprobe
will also search specific directories under /lib/modules, if they exist.
So I created /lib/modules/misc and moved the ieee12844 modules there.  I
would like to see the modules installed there instead of /usr/local/lib.

Burkhard Kohl sent a message to this list explaining how to set up
conf.modules, as a workaround, so the modules load.  I modified it
into two lines:
	above parport parport_pc
	below ieee12844 parport_probe


John Chmielewski

[hpoj-devel] parport_lowlevel/parport_probe module handling

[Burkhard K. <bu...@bu...>]

David Paschal
> Based on John Chmielewski's message from September 13, it sounds like it
> could be moved to (or possibly symlinked in) /lib/modules/misc, but there's
> still the problem that modprobe doesn't detect that ieee12844pp.o depends
> on parport_probe, not just parport and parport_pc.  My idea was to add a
> dummy function in ieee12844pp.c which never got called but which made a
> reference to a function in parport_probe (for example, parport_probe()).
> Since you're working on this code at the moment could you try this out and
> let me know if it fixes the problem (or I can try it myself later).

David, 

I have investigated that issue and to my surprise I found the following
lines in drivers/misc/parport_share.c:

/* Return a list of all the ports we know about. */
struct parport *parport_enumerate(void)
{
#ifdef CONFIG_KMOD
    if (portlist == NULL) {
        request_module("parport_lowlevel");
#ifdef CONFIG_PNP_PARPORT_MODULE
        request_module("parport_probe");
#endif /* CONFIG_PNP_PARPORT_MODULE */
    }
#endif /* CONFIG_KMOD */
    return portlist;
}

Thus, if "Kernel module loader" in "Loadable Module Support" and 
"Auto-probe for parallel devices" in "Plug and Play support" are
enabled parport_probe will be inserted by kmod automagically.
(A lsmod listing should mark parport_probe as "autoclean").

I have tested this with all parport relevant lines in modules.conf
commented out. After loading "parport.o" and "ieee12844.o" an
	insmod ieee12844pp.o 
loads "parport_pc.o" and "parport_probe.o"

I also looked into parport_probe.o and found that it only contains
a hook for the real probing function like "parport_probe_one".

Under 2.4 the situation is handled by the "parport_register_driver"
function which installs a lowlevel driver if not already present.

Burkhard
-- 
Burkhard Kohl			bu...@bu...

Re: [hpoj-devel] 2.4.0 kernel issues

[Burkhard K. <bu...@bu...>]

David Paschal
> Hi, Burkhard.
> 
> > 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.

That's the point I wanted to indicate. I guess lp is the first source 
to start adapting the ieee12844pp module to the new kernel.

BTW: David, I have to admit that I don't know very much about the 
IEEE1284.4 protocol (I am familiar with SPP parports though). Could 
you suggest a (desirably concise) source for reading?

Burkhard
-- 
Burkhard Kohl			bu...@bu...