RE: [hpoj-devel] Re: ptal-mlcd debug message dump

[PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...>]

Hi, Joe.

Joe Piolunek wrote:
> When I ran the same test (getting the dump) and then typed
> deactivate
> nolog
> activate 
> 
> This is the message that appears:
> 
> ptal-mlcd ->activate
> exActivate returns 1.
Good, that's normal.

> Even after failing to print with ptal-printd , the officejet 
> will print using 
> the standard redhat printing system. That will cause the 
> parport-related 
> modules to be loaded, so before trying again to print with 
> ptal-printd, I 
> rmmod them.
> 
> The only time I've seen the 'timer pop' message is when 
> attempting to print 
> with ptal-printd, (or maybe just having it loaded) then 
> printing with the 
> regular redhat system.
...
> > Instead of trying to print, try invoking "ptal-connect 
> mlc:par:0 -socket
> > 6". This will connect to the echo service on the 
> peripheral, and each line
> > of text you type should be echoed back.  Does this work at least?
> 
> That works.

Since you can activate ptal-mlcd and use the echo service without any
problems, it sounds like something in the printing system is interfering
with ptal-mlcd's access to the parallel port, especially since you have
another printer connected to another parallel port.  It's quite possible
that the parport* and lp kernel modules are getting loaded by printtool
and/or lpd, and their initialization routines would most likely break
ptal-printd.  I have seen these modules get loaded automatically by
printtool, especially when adding a new queue, so it can tell you which
parallel ports have a peripheral attached.

There's one other thing you can try to keep the kernel modules from breaking
ptal-mlcd.  In one window, issue the command "cat >/dev/lp1", using the
/dev/lpX that corresponds to your OfficeJet.  That should get the modules
loaded and the interference out of the way.  Then restart ptal-mlcd,
ptal-printd, and lpd and try to print again.  If this works, then I'll add a
command-line option to ptal-mlcd to handle this automatically, because I
suspect others will run into the same problem.

In case you haven't already tried this, it would also be interesting to try
printing without lpd by sending a text file directly to
"/dev/ptal-printd/mlc_par_0".  Of course, you'll need to make sure it has
DOS-formatted line endings (CR-LF) to avoid the stair-step effect.

> It's loaded with internal hardware, but the cpu usage isn't 
> normally very 
> high. It's not an active server, just a single-user desktop 
> machine. The cpu 
> is a p233 MMX, 64M ram. 'top' shows the biggest cpu hog is 
> the kde sound 
> server 'artsd', but I disabled that to see if it would ease 
> the load enough. 
> It didn't make any difference. Printing an email from kmail, 
> though, does 
> cause the cpu to hit 100% for a few seconds, as shown by xosview.
ptal-mlcd does tend to use a lot of CPU time, sometimes approaching 100%
when it's actively printing or scanning.  One of the things on my TODO list
is to dynamically adjust the reverse (peripheral-to-host) data poll rate so
that it won't poll as often when idle.

David