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

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

On Monday 19 March 2001 07:08 pm, PASCHAL,DAVID (HP-Roseville,ex1) wrote:

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

I've been watching the output from 'lsmod'. Whether or not the lp/parport 
modules are loaded, printing fails.

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

That did cause the lp/parport modules to load, but it didn't solve the 
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 wouldn't work, even after a ptal-mlcd / ptal-printd / lpd restart. I 
didn't try to prevent the stair-step effect. I didn't think it would matter 
in this case (just a test).

The ptal-printd queue really doesn't like to accept text as the first print 
job. Sometimes postscript isn't accepted either. Printing a web page from 
netscape sometimes won't create a first entry in the queue, even after 
reloading the page. It appears that once there is a first entry, subsequent 
jobs can be more reliably added.

This is just a guess, but could one of the daemons be bit-bucketing the job 
inappropriately at times?

When attempting to print to the ptal-printd queue from netscape, this error 
message often appears. When it does, it repeats every 30 seconds, until 
ptal-printd is killed.
 
]# ptalChannelOpen(chan=0x0804AF60): provider failed open!
ptal-printd(mlc:par:0): ptalChannelOpen failed!  Will delay and retry.
ptalChannelOpen(chan=0x0804AF60): provider failed open!

-- 
Joe