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

[Joe P. <joe...@sn...>]

On Sunday 18 March 2001 11:14 pm, David Paschal wrote:

<....>
> > The final messages you said might be displayed (the 'timer pop message',
> > etc.) didn't occur the two times I obtained the dump.
>
> Thanks for sending that.  It's too bad that the timer-pop doesn't happen
> with debug output turned on, but that might point to a race condition,
> possibly in the ParPort class.  What happens if you run the same test (with
> debug output turned on), then say "deactivate", "nolog", and "activate"?
> Does the timer pop the second time with the debug output turned off?  (The
> deactivate command will print an "exClose" error message, but that's
> normal.)

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.

ptal-mlcd ->

Something else that may be of interest - when attempting to print a text file 
from the command line using ptal-printd, the job doesn't normally get queued 
unless there is already an entry in the queue (from attempting to print 
through kmail, for ex.) . None of the waiting jobs actually print, though.

The same thing happens with printtool. When the ptal-printd queue is empty 
and I click on 'print ascii test page', the job apparently never enters the 
ptal-printd queue. When I click 'print postscript test page', the job enters 
the queue. Once the postscript job is in the queue, clicking on "print ascii 
test page" will add to the queue. None of it is printed, though.


> > When I attempt to print a page through kmail or netscape, the print job
> > apparently enters the queue, but no printing occurs. The kde 'klpq' app
> > lists the print job and displays the message 'ptal-printd is ready and
> > printing'.
>
> I take it you named your print queue "ptal-printd".

That's correct. I also added an alias for it in printtool: 'mlcpp0'


> Is it possible that lpd is in a bad state due to an earlier print failure?
> I ran into this problem while testing ptal-printd recently, and I found
> that I pretty much needed to lprm the job(s) and restart lpd (and possibly
> ptal-printd also, but hopefully that's no longer necessary) in order to get
> things working again.

I don't think that's it.  ptal-printd won't print even after a reboot. I also 
tried restarting lpd.

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.

When I did that, these messages were displayed in one shell, while another 
(shown below) appeared in another shell that I had open:

ptal-mlcd: ERROR at transport/ExMlcCommandChannel.cpp:186, dev=<par:0>, 
pid=1840, errno=11
Reply timer popped on port=0, count=1!
 
ptal-mlcd: ERROR at ExMgr.cpp:783, dev=<par:0>, pid=1840, errno=11
exClose(reason=4202)
 
ptal-mlcd: ERROR at ParPort.cpp:163, dev=<par:0>, pid=1840, errno=11
statusWaitSetClear(event=23) timed out!

In the other shell:

]# ptal-printd(mlc:par:0): ptalChannelWrite returns -1, expected=1022!  
Bit-bucketing rest of print job.

I don't think there were any jobs queued at the time.


> 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.


> How heavily loaded is your system in terms of CPU usage?  It's
> theoretically possible that the combination of a heavily-loaded system and
> a timeout-happy peripheral could break things, although I've never seen
> this in the testing I've done so far.


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.

-- 
Joe