hpoj-devel — HPOJ development/support list

Re: [hpoj-devel] CVS hpoj code works (mostly)

[<mic...@t-...>]

Am Mittwoch, 21. März 2001 02:49 schrieben Sie:

> Thanks to David for getting this working!  As soon as version 1.0 gets
> released, I can start recommending HP all-in-ones to my linux friends.
1.) Thanks from my side too. I got a G85 from my wife at christmas (I just 
wanted to have a PSC500 - must have been *very* nice last year :-) ) and was 
immedeiatley able to use the box for everything.

2.) Why not recommend them now? The drivers work like a charm.

> An interesting problem, though... when I tried "scanimage --test", the test
> appeared to pass without problem, but the scanner hung and ptal-mlcd died.
> This is a repeatable problem for me.  (The beauty of a user-mode driver is
> that I just restarted it and reset the PSC500 and everything worked fine
> again.)  I haven't tried running it with debugging turned on, but want to
> know if anyone else has seen this problem.

I didn't see it with the 0.7 drivers working here. But another - not really - 
problem is that afer a printout the LCD shows "Printing in progress" - or 
something like this, I'm using the german language, and the quality-LED is 
constantly blinking. The G85 is still useable, so it is only annoying.


-- 
Michael Prix

Re: [hpoj-devel] CVS hpoj code works (mostly)

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

Daniel Gun wrote:
> I checked out and compiled the hpoj cvs code of about March 13 or 14. 
> Everything compiled and installed just fine.  I have the redhat 2.2.17-14
> kernel and am using a PSC500 on the parallel port.
> 
> I was able to scan using sane 1.0.4 and ptal-connect directly.  I scanned a
> few MB images and also a 48MB image, and had no problems.  I was also able
> to print using ptal-connect, though I haven't tried ptal-printd.
Hi, Daniel.  Thanks for the success report.  I'm glad it works well for you.

> Thanks to David for getting this working!
You're quite welcome.  Of course some of the credit should go to my management
for being supportive of my involvement with this project (given that I don't
actually work for the all-in-one division) and for agreeing to GPL the code
that went into ptal-mlcd.

> As soon as version 1.0 gets
> released, I can start recommending HP all-in-ones to my linux friends.
That's certainly my goal.  :-)  What constitutes "version 1.0" to you?
I expect I will be making incremental improvements to the software for
quite some time, so I wasn't planning on bumping the version number to 1.0
any time soon.  Hopefully you'll recommend based on the functionality rather
than the version number.  :-)

> An interesting problem, though... when I tried "scanimage --test", the test
> appeared to pass without problem, but the scanner hung and ptal-mlcd died. 
> This is a repeatable problem for me.
Thanks for noticing that.  I guess I forgot to test with "scanimage --test".
:-)  I think I know what the problem is (a race condition between closing
the scan connection due to the aborted scan and data that's still moving
around in the daemon).  I'll let you know when I check in a fix, which
should be sometime this weekend.

> (The beauty of a user-mode driver is
> that I just restarted it and reset the PSC500 and everything worked fine
> again.)
That's one of several reasons I chose to rewrite the driver in user mode.
It's also much easier for me to debug and maintain.

> I haven't tried running it with debugging turned on, but want to
> know if anyone else has seen this problem.
Interestingly enough, I was able to reproduce this problem with a parallel-
connected R80 but not a USB-connected PSC750, so it makes sense that this
problem would be a race condition, given that USB and parallel have
different timing.  The exit is due to an unhandled signal (SIGPIPE),
although since you downloaded the code I added a handler for this signal
for an unrelated reason, so in my case I saw a bunch of error messages and
debug console resets without the exit (although the scanner still got stuck).

David

Re: [hpoj-devel] no luck with USB

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

Michel Hoche-Mong wrote:
> I'm running a 2.2.18 kernel with an OfficeJet G55 connected via USB,
> and i'm having no luck. I just grabbed the latest CVS update and still
> nothing.
...
> P.S.: i know the INSTALL doc says a 2.2.19 kernel is required, but i didn't 
> see one on kernel.org. did i miss some patches somewhere?

Hi, Michel.  Sorry about the confusion.  I wrote that more with the future
in mind, since 2.2.19 isn't available yet.  I also mentioned the alternative
of updating just printer.c, and I'll post a "printer.c update kit" on the
hpoj webpage soon.  In the meantime, I have attached the printer.c patch
from the latest 2.2.19 prepatch.  It has the necessary fixes plus some other
changes I haven't tested personally, but it should work OK, since most of it
constitutes an updated backport of functionality that has been floating
around in 2.4 for a while.

David

[hpoj-devel] no luck with USB

[Michel Hoche-M. <ho...@gr...>]

I'm running a 2.2.18 kernel with an OfficeJet G55 connected via USB,
and i'm having no luck. I just grabbed the latest CVS update and still
nothing.

usbcore, usb-uhci, and printer are all loaded, /proc/bus/usb is mounted,
and i have a usb printer device:
crw-rw-r--   1 root     daemon   180,   0 Mar 22 02:20 /dev/usb/lp0


i did:

% /usr/local/sbin/ptal-mlcd usb:0 -device /dev/usb/lp0
% /usr/local/sbin/ptal-printd mlc:usb:0 -like /dev/lp0
% /usr/sbin/lpd

then i try to print to it, an a few seconds later i get:

ptal-mlcd: ERROR at transport/ExMlcCommandChannel.cpp:186, dev=<usb:0>,
pid=19020, errno=11
Reply timer popped on port=0, count=1!

ptal-mlcd: ERROR at ExMgr.cpp:819, dev=<usb:0>, pid=19020, errno=11
exClose(reason=0x3002)


ptal-mlcd: ERROR at transport/ExMlcCommandChannel.cpp:186, dev=<usb:0>,
pid=19020, errno=11
Reply timer popped on port=0, count=1!

ptal-mlcd: ERROR at ExMgr.cpp:819, dev=<usb:0>, pid=19020, errno=11
exClose(reason=0x3002)
ptalChannelOpen(chan=0x0804AF68): provider failed open!
ptal-printd(mlc:usb:0): ptalChannelOpen failed!  Will delay and retry.


I checked via ptal-devid:

% ./ptal-devid mlc:usb:0
ptalMlcDeviceGetDeviceIDString(dev=usb:0): unsuccessful status=13!
ptalDeviceGetDeviceIDString(dev=mlc:usb:0) failed!


Any ideas?

-michel


P.S.: i know the INSTALL doc says a 2.2.19 kernel is required, but i didn't 
see one on kernel.org. did i miss some patches somewhere?

[hpoj-devel] CVS hpoj code works (mostly)

[DG <dg...@um...>]

Another data point:

I checked out and compiled the hpoj cvs code of about March 13 or 14. 
Everything compiled and installed just fine.  I have the redhat 2.2.17-14
kernel and am using a PSC500 on the parallel port.

I was able to scan using sane 1.0.4 and ptal-connect directly.  I scanned a
few MB images and also a 48MB image, and had no problems.  I was also able
to print using ptal-connect, though I haven't tried ptal-printd.

Thanks to David for getting this working!  As soon as version 1.0 gets
released, I can start recommending HP all-in-ones to my linux friends.

An interesting problem, though... when I tried "scanimage --test", the test
appeared to pass without problem, but the scanner hung and ptal-mlcd died. 
This is a repeatable problem for me.  (The beauty of a user-mode driver is
that I just restarted it and reset the PSC500 and everything worked fine
again.)  I haven't tried running it with debugging turned on, but want to
know if anyone else has seen this problem.

--
Daniel
ZZZ-dgun-ZZZ-@-ZZZ-umpire.com-ZZZ
(Remove the Z-'s to reply)
______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup

Re: [hpoj-devel] more code changes

[Tim W. <tw...@re...>]

On Fri, Mar 23, 2001 at 01:51:40AM -0800, David Paschal wrote:

> Hi, Tim.
>=20
> On a related note, Tim, how familiar are you with using the hardware-assi=
sted
> ECP transfer modes (using the FIFOs)?  I attempted to code support for th=
at
> into my ParPort class but had trouble getting both forward and reverse ECP
> transfers to work.  I'm thinking I may not be turning the bus around
> correctly.=20

There are lots of caveats in the datasheets.  I'm not convinced that
the parport_pc code gets it right either.

> For now I'm doing all of the signalling in software, just the way
> it was done in ieee12844pp.c, but eventually I'd like to start using the
> FIFOs (no DMA or interrupts) to try to improve performance.

Again, this is something that /dev/parport0 can supposedly help with,
but I guess it will be a while before applications do.

Tim.
*/

Re: [hpoj-devel] more code changes

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

Joe Piolunek wrote:
> Printing works now on the 600 if ptal-printd is started without the '-nouel' 
> switch. I don't recall seeing a definition of 'uel'. Does it mean "Unix End 
> Line"? If so, would it have helped to remove the 'fix stair-stepping text' 
> option in printtool?
Hi, Joe.  UEL stands for Universal Exit Language and is part of PJL (Printer
Job Language).  Technically it refers to the specific escape sequence
"<Esc>%-12345X", and it provides a stronger and print-personality-independent
job delimiter than the <Esc>E sequence that gets sent when you tell printtool
to "Send EOF after job to eject page".  In ptal-printd I stretched the
definition a bit with uel1 and uel2 to refer generically to the strings sent
before and after the job.  The problem was that the <Esc>E before the UEL in
uel1 was confusing your printer.  In 0.7 the <Esc>E came second, but I swapped
them recently when I discovered the LaserJet 3200m didn't like that when
printing PostScript.  And as we saw, *that* change didn't go over very well
with your printer, so I took the <Esc>E out of uel1 altogether.  :-)

(regarding manually insmoding all the parport* modules):
> It's too bad there isn't a neater solution. If that's the best one available 
> though, I suppose people won't mind doing it very much.
Unfortunately, it looks like keeping /dev/lpX open doesn't prevent
parport_probe from re-probing that port when it gets reloaded.  Nevertheless,
I'm now leaning more towards this ptal-mlcd-assisted solution, which should
take care of the problem in the vast majority of cases (other than the case
of parport_probe unload and reload, which doesn't seem to happen anyway when
telling printtool to create another print queue).  It also has the added
benefit of preventing somebody else from opening the same /dev/lpX.  One
tradeoff will be that the user has to specify which /dev/lpX to use, in
addition to the I/O port base address(es), with a command line such as:
	ptal-mlcd par:1 -base 0x278 -device /dev/lp2
However, for a single-port box, it should be something pretty simple, like:
	ptal-mlcd par:0 -device /dev/lp0	# -base 0x378 implied.
The other obvious tradeoff will be that the parport*/lp modules will stay
loaded all the time while ptal-mlcd is activated, but this shouldn't be too
big of a problem.  I don't think there's a reliable way to probe for all of
the necessary information (low and high base addresses and /dev/lpX node),
so the user will have to figure this out by looking at /var/log/messages.

I'll try to code this up in the next few days and let people try to break
it.  :-)

David

Re: [hpoj-devel] more code changes

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

Hi, Tim.

Tim Waugh wrote:
> Gotcha.  You can't reserve IO regions from user space, can you?
> 
> Using /dev/parport0, you can try to get exclusive access to the port,
> which will (a) load parport_lowlevel, and (b) make sure no other
> device drivers can touch it.  But that's for 2.4.x only at the moment.
I may look into this at some point if it becomes necessary, but for now I
want to be as kernel-independent as possible.  Any OS/version-specific
features like this would have to be optional and turned on or off by the
configure script, similar to how I detected and worked around the problem
with including <sys/io.h> in C++ code.

> But for the mean time, yes I think opening /dev/lp0 and keeping it
> open is a 'good enough' way to prevent pulled rugs.  It doesn't stop
> the user from doing 'modprobe -r parport_probe; modprobe
> parport_probe', but the user is supposed to be on your side in this
> application I think.
I agree now that I've thought about it some more.

On a related note, Tim, how familiar are you with using the hardware-assisted
ECP transfer modes (using the FIFOs)?  I attempted to code support for that
into my ParPort class but had trouble getting both forward and reverse ECP
transfers to work.  I'm thinking I may not be turning the bus around
correctly.  For now I'm doing all of the signalling in software, just the way
it was done in ieee12844pp.c, but eventually I'd like to start using the
FIFOs (no DMA or interrupts) to try to improve performance.

David

Re: [hpoj-devel] more code changes

[Tim W. <tw...@re...>]

On Thu, Mar 22, 2001 at 04:18:21PM -0800, PASCHAL,DAVID (HP-Roseville,ex1) wrote:

> ptal-mlcd accesses the parallel-port registers directly, bypassing the
> kernel parport drivers.  Once ptal-mlcd has initiated communication with the
> peripheral, it is in ECP mode (nSelectIn=1).

Gotcha.  You can't reserve IO regions from user space, can you?

Using /dev/parport0, you can try to get exclusive access to the port,
which will (a) load parport_lowlevel, and (b) make sure no other
device drivers can touch it.  But that's for 2.4.x only at the moment.

But for the mean time, yes I think opening /dev/lp0 and keeping it
open is a 'good enough' way to prevent pulled rugs.  It doesn't stop
the user from doing 'modprobe -r parport_probe; modprobe
parport_probe', but the user is supposed to be on your side in this
application I think.

Tim.
*/

Re: [hpoj-devel] more code changes

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

On Thursday 22 March 2001 05:59 pm, PASCHAL,DAVID (HP-Roseville,ex1) wrote:
> Hi,
>
> Over the last several days I checked in some more ptal-mlcd, ptal-printd,
> and libptal changes, including some bug fixes and minor enhancements.  You
> can do a "cvs update" in your CVS sandboxes to pick up these changes.
>
> First and foremost, I made a change to ptal-printd to the "uel1" string
> sent before the job to try to fix the problem Joe reported on the OfficeJet
> 600. Joe, can you verify that you can now print without using the "-nouel"
> switch?  I still need to verify it on all the models I have.

Printing works now on the 600 if ptal-printd is started without the '-nouel' 
switch. I don't recall seeing a definition of 'uel'. Does it mean "Unix End 
Line"? If so, would it have helped to remove the 'fix stair-stepping text' 
option in printtool?


> I experimented with the interaction between ptal-mlcd and the Linux parport
> drivers.  It seems that parport_pc and parport_probe are the ones that
> break ptal-mlcd when they get insmoded.  Earlier I proposed adding
> something to ptal-mlcd to attempt to open /dev/lpX when communicating with
> a parallel peripheral.  This would cause all of the parport modules to get
> loaded and get their problematic initialization out of the way, and it
> would force parport_pc to stay loaded.  However, there appears to be
> nothing I can do in ptal-mlcd to prevent parport_probe from being unloaded
> and reloaded and causing problems later.  It looks like the most reliable
> solution is to insmod each of these modules at startup such that they won't
> get
> "autocleaned" (unloaded after a timeout) later.  I'd be interested in
> hearing what others think about this solution.

It's too bad there isn't a neater solution. If that's the best one available 
though, I suppose people won't mind doing it very much.

-- 
Joe

RE: [hpoj-devel] more code changes

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

Tim Waugh wrote in response to me:
> > I experimented with the interaction between ptal-mlcd and 
> the Linux parport
> > drivers.  It seems that parport_pc and parport_probe are 
> the ones that break
> > ptal-mlcd when they get insmoded.  Earlier I proposed 
> adding something to
> > ptal-mlcd to attempt to open /dev/lpX when communicating 
> with a parallel
> > peripheral.  This would cause all of the parport modules to 
> get loaded and
> > get their problematic initialization out of the way, and it 
> would force
> > parport_pc to stay loaded.
> 
> Why is the initialization problematic?

ptal-mlcd accesses the parallel-port registers directly, bypassing the
kernel parport drivers.  Once ptal-mlcd has initiated communication with the
peripheral, it is in ECP mode (nSelectIn=1).

parport_pc's initialization routine modifies the registers in an attempt to
detect the port type and to set the registers to a known state.
parport_probe attempts to retrieve a device ID string from the peripheral.
In both cases, the port is returned to compatibility mode (nSelectIn=0),
effectively pulling the rug out from under ptal-mlcd.

If /dev/lp0 is already open when parport_probe gets loaded, does that
prevent parport_probe from trying to probe on parport0?  If so, then maybe
that would be a good solution after all.  It would also prevent problems
from somebody's trying to open /dev/lp0 while ptal-mlcd is using that port.

David

Re: [hpoj-devel] more code changes

[Tim W. <tw...@re...>]

On Thu, Mar 22, 2001 at 02:59:23PM -0800, PASCHAL,DAVID (HP-Roseville,ex1) wrote:

> I experimented with the interaction between ptal-mlcd and the Linux parport
> drivers.  It seems that parport_pc and parport_probe are the ones that break
> ptal-mlcd when they get insmoded.  Earlier I proposed adding something to
> ptal-mlcd to attempt to open /dev/lpX when communicating with a parallel
> peripheral.  This would cause all of the parport modules to get loaded and
> get their problematic initialization out of the way, and it would force
> parport_pc to stay loaded.

Why is the initialization problematic?

Tim.
*/

[hpoj-devel] more code changes

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

Hi,

Over the last several days I checked in some more ptal-mlcd, ptal-printd,
and libptal changes, including some bug fixes and minor enhancements.  You
can do a "cvs update" in your CVS sandboxes to pick up these changes.

First and foremost, I made a change to ptal-printd to the "uel1" string sent
before the job to try to fix the problem Joe reported on the OfficeJet 600.
Joe, can you verify that you can now print without using the "-nouel"
switch?  I still need to verify it on all the models I have.

Also, I added an optional remote debug console capability to ptal-mlcd.  If
you invoke it with "-remconsole", you can use a command like "ptal-connect
mlc:par:0 -socket -1" to access the console, even if you started ptal-mlcd
in the background (without the "-nofork" switch).  It's best to enable this
for debugging on systems with only trusted users, since any local user (not
just root) can connect to this service.

I experimented with the interaction between ptal-mlcd and the Linux parport
drivers.  It seems that parport_pc and parport_probe are the ones that break
ptal-mlcd when they get insmoded.  Earlier I proposed adding something to
ptal-mlcd to attempt to open /dev/lpX when communicating with a parallel
peripheral.  This would cause all of the parport modules to get loaded and
get their problematic initialization out of the way, and it would force
parport_pc to stay loaded.  However, there appears to be nothing I can do in
ptal-mlcd to prevent parport_probe from being unloaded and reloaded and
causing problems later.  It looks like the most reliable solution is to
insmod each of these modules at startup such that they won't get
"autocleaned" (unloaded after a timeout) later.  I'd be interested in
hearing what others think about this solution.

David

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

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

Joe Piolunek wrote:
> On Tuesday 20 March 2001 07:29 pm, PASCHAL,DAVID (HP-Roseville,ex1) wrote:
> > Hi, Joe.  What happens if you start ptal-printd with the "-nouel" switch? 
> That fixed it.
> 
> With the -noeul switch added, the 600 prints without any apparent problems.
> 
> I just printed a text file from the command line as the first print job. 
> Postscript prints too. Pages in netscape print.
Wonderful!  I'm glad that problem is solved, because I was really starting to
run out of ideas.  :-)  Now I guess I need to go back and try to find a UEL
sequence that works on all models.

> BTW, I changed sys/io.h back and forth to see what the configure script would 
> do. It apparently handled it correctly.
Great.  Thanks for verifying that on your system.

David

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

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

On Tuesday 20 March 2001 07:29 pm, PASCHAL,DAVID (HP-Roseville,ex1) wrote:
> Hi, Joe.  What happens if you start ptal-printd with the "-nouel" switch? 
> I changed the UEL format recently (since 0.7) to fix PostScript printing on
> the LaserJet 3200m, and maybe this change confuses your printer (and causes
> it to bitbucket the job and/or freak out).  If this doesn't work, you could
> also just try the 0.7 version of ptal-printd.c and see if that works any
> better, but of course it lacks the robustness "fixes" I put in that now
> could be suspect.


David:

That fixed it.

With the -noeul switch added, the 600 prints without any apparent problems.

I just printed a text file from the command line as the first print job. 
Postscript prints too. Pages in netscape print.

BTW, I changed sys/io.h back and forth to see what the configure script would 
do. It apparently handled it correctly.


-- 
Joe

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

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

Hi, Joe.  What happens if you start ptal-printd with the "-nouel" switch?  I
changed the UEL format recently (since 0.7) to fix PostScript printing on
the LaserJet 3200m, and maybe this change confuses your printer (and causes
it to bitbucket the job and/or freak out).  If this doesn't work, you could
also just try the 0.7 version of ptal-printd.c and see if that works any
better, but of course it lacks the robustness "fixes" I put in that now
could be suspect.

David

Joe Piolunek wrote:
> 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!
...
> I just noticed that when attempting to print with ptal-mlcd, 
> instead of 
> totally ignoring the print request, the 600's LCD screen 
> shows the message "0 
> pages printed". So far, that's the only response I've seen 
> from the printer. 
> It appears a few seconds after attempting to print a 
> postscript file from the 
> command line. The message doesn't seem to appear again until 
> the daemons are 
> restarted.

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 just noticed that when attempting to print with ptal-mlcd, instead of 
totally ignoring the print request, the 600's LCD screen shows the message "0 
pages printed". So far, that's the only response I've seen from the printer. 
It appears a few seconds after attempting to print a postscript file from the 
command line. The message doesn't seem to appear again until the daemons are 
restarted.

-- 
Joe

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

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

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

Re: [hpoj-devel] new "ptal-mlcd" I/O driver checked into CVS

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

On Monday 19 March 2001 03:11 am, Alexander Zimmermann wrote:
> On 17 Mar, Joe Piolunek wrote:
> > Has anyone yet been able to use gcc-2.95.2 sucessfully with the new code
> > in CVS?
>
> Yes, I compiled with gcc-2.95.2 and everything works.
>
> > ptal-mlcd: ERROR at transport/ExMlcCommandChannel.cpp:186, dev=<par:0>,
> > pid=939, errno=11
>
> I got similar error messages when I tried ptal-printd the first time, as
> I liked to test it, before installing it all. But in this case the
> runtime linker used the obsolete libptal-libraries from the prior
> installation instead of the new from CVS build.
>
> Or in short word's: make sure you're using the right libptal-libraries.

Thanks for the reply, Alexander. That isn't the problem, though. I removed 
the previous installation before installing the new one.

-- 
Joe

Re: [hpoj-devel] new "ptal-mlcd" I/O driver checked into CVS

[Alexander Z. <Ale...@fm...>]

On 17 Mar, Joe Piolunek wrote: 
> Has anyone yet been able to use gcc-2.95.2 sucessfully with the new code in 
> CVS?

Yes, I compiled with gcc-2.95.2 and everything works.

> ptal-mlcd: ERROR at transport/ExMlcCommandChannel.cpp:186, dev=<par:0>, 
> pid=939, errno=11

I got similar error messages when I tried ptal-printd the first time, as
I liked to test it, before installing it all. But in this case the
runtime linker used the obsolete libptal-libraries from the prior
installation instead of the new from CVS build.

Or in short word's: make sure you're using the right libptal-libraries.
-- 
Ale...@fm... / Girls who throw themselves at
http://www.fmi.uni-passau.de/~zimmerma/ men, are actually taking very
for PGP public key finger            / careful aim. 
zim...@yo...     / 

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

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

Hi, Joe.

Joe Piolunek wrote:
> I've attached the ptal-mlcd dump you asked for. 
> 
> I hadn't started ptal-printd at the time of the test.
> 'lsmod' showed none of the parport-related modules loaded.
> 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 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".

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.

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?

> I rebuilt the hpoj package with the new redhat kernel-2.2.17-14 I just 
> installed (from RPM), but the results are the same as with my older homebuilt 
> 2.2.16 kernel.
I would expect that.

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.

David

Re: [hpoj-devel] new "ptal-mlcd" I/O driver checked into CVS

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

Joe Piolunek wrote:
> The package I got from CVS on Mar. 14 builds without errors, but I can't seem 
> to get it to print
...
> Here are some of the messages that appeared on the command line at one point. 
> I'm not sure what I was doing when they appeared (possibly trying to print), 
> but maybe they'll mean something to you. Sorry if it doesn't help.
> 
> ]$
> ptal-mlcd: ERROR at transport/ExMlcCommandChannel.cpp:186, dev=<par:0>, 
> pid=939, errno=11
> Reply timer popped on port=0, count=1!
> 
> ptal-mlcd: ERROR at ExMgr.cpp:783, dev=<par:0>, pid=939, errno=11
> exClose(reason=4202)
> 
> ptal-mlcd: ERROR at ParPort.cpp:163, dev=<par:0>, pid=939, errno=11
> statusWaitSetClear(event=23) timed out!
> ]$
Hi, Joe.  The reply timer pop probably happened 15 seconds after the first
connection attempt was made to start up MLC, and indicates that there's some
problem receiving a reply to an MLC command, probably due to a communication
error.  Please try the following test:

- Run "script" in order to capture the following output.
- Invoke ptal-mlcd as you normally do, but append the "-nofork" switch to
  the command line.  This will bring up a debug console.
- Issue the command "log" to turn on debug logging.
- Issue the command "activate" to start the MLC conversation with the
  peripheral.
- As soon as the initial log messages stop, issue the command "dump" to
  display all the internal state.
- After about 15 seconds, you'll probably get some more log messages
  including the reply timer pop message.
- Ctrl-C out of ptal-mlcd, Ctrl-D out of "script", and mail me the output.
  This will enable me to see how far it got before the error happened.

> The install/print-howto instructions do seem like they could be simplified.
OK, I'll look into that at some point.

Thanks,
David

Re: [hpoj-devel] new "ptal-mlcd" I/O driver checked into CVS

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

On Tuesday 13 March 2001 04:03 am, David Paschal wrote:

<...>
> > I haven't tried to install or test the package yet. I'll probably wait
> > until the io.h work-around arrives.
>
> I just checked it into CVS.  Please do a "cvs update" and try it now.
>
> I decided to go with the C wrapper workaround method.  It's only enabled
> when necessary, to avoid a performance penalty (however small) when the
> workaround isn't needed.  If you're interested, you can try running the
> configure script with either the original or "fixed" version of io.h and
> see that configure enables or disables the workaround as necessary.  On my
> system, I simulated the problem by adding the following three lines to
> create a "broken" version: #ifdef __cplusplus
> #error Simulating broken C++ compiler
> #endif

David:

The package I got from CVS on Mar. 14 builds without errors, but I can't seem 
to get it to print. The section below seems to indicate that it is working in 
some fashon.

[root@tumbleweed joe]# /usr/local/sbin/ptal-mlcd par:0 -base 0x378
[root@tumbleweed joe]# /usr/local/sbin/ptal-printd mlc:par:0 -like /dev/lp0

[root@tumbleweed joe]# pidof ptal-printd ptal-mlcd
1124 1122

[root@tumbleweed joe]# ptal-devid mlc:par:0
MFG:Hewlett-Packard;MDL:OfficeJet Series 
600;CMD:MLC,PCL,PML;CLASS:PRINTER;REV:4.03b;


I may just be overlooking something, but with the earlier build problem due 
to compiler differences, this may have a similar cause.

Has anyone yet been able to use gcc-2.95.2 sucessfully with the new code in 
CVS?

Here are some of the messages that appeared on the command line at one point. 
I'm not sure what I was doing when they appeared (possibly trying to print), 
but maybe they'll mean something to you. Sorry if it doesn't help.

]$
ptal-mlcd: ERROR at transport/ExMlcCommandChannel.cpp:186, dev=<par:0>, 
pid=939, errno=11
Reply timer popped on port=0, count=1!

ptal-mlcd: ERROR at ExMgr.cpp:783, dev=<par:0>, pid=939, errno=11
exClose(reason=4202)

ptal-mlcd: ERROR at ParPort.cpp:163, dev=<par:0>, pid=939, errno=11
statusWaitSetClear(event=23) timed out!
]$


The install/print-howto instructions do seem like they could be simplified.


-- 
Joe