[hpoj-devel] SMP patches?

[Robert G. B. <rg...@ph...>]

Dear List Persons:

I greet you!  I just got a OJ G55 for the home to print photos and so
forth on.  It hangs on a dual Celeron (Abit BP6 motherboard) running RH
linux 6.2 with the 2.2.16-3smp kernel.  I diligently searched and found
the hpoj site and 0.6 drivers, compiled them, and they work -- sort of.

The most common problem I have produces the following message:

Nov 29 08:51:37 lucifer kernel: mlcpp0: mlcpp_transmit while TX busy
Nov 29 08:59:19 lucifer kernel: mlcpp0: mlcpp_transmit while TX busy

This seems to trash a tiny but critical part of the stream, and kicks
the printer off of printing e.g. a full color picture into printing all
the associated ASCII, whereupon I scrabble for the cancel button.  To
recover I minimally have to restart the printer daemon and sometimes
have to unload and reload the ieee12844 modules as well.

Searching the hpoj-devel list archives, I learned that there has been a
patch proposed for smp systems because of deadlock issues resulting from
a non-smp-safe bottom half handler.  I looked for the patch as best I
could on the website, but found nothing.

Could someone provide me directions to the patch?

I have a bit of kernel module and smp expertise myself (at least enough
to know what a "bottom half handler" is:-) and can possibly even help
intelligently in the event that the patch doesn't fix my problem(s).

Note that it does seem like a deadlock issue because it doesn't always
happen -- I can print as many as a couple of pictures "perfectly" (see
below) and then lose it in the third.  Before I saw the possibility of
an SMP problem I was suspecting a handshaking problem or an overrun
problem -- it is that kind of thing.

Now regarding "perfectly".  I'm using the cdj550 filter, but results on
photographs leave a great deal to be desired.  I feel like I'm getting
at most a tiny fraction of the printer's potential resolution.  This is
especially visible comparing the results of copying a photograph using
the printer's copy function and the results of scanning it into sane at
full resolution and trying to print that.  It also, however, shows up in
e.g. TIFF's and hi-res jpegs printed from images from our 3.3. Mpixel
camera.

Again diligently searching the web I see that there is an "hpdj" driver
for postscript that is being developed that speaks pcl3+ and that might
produce superior results on the G55 or other OfficeJets.

Are there any remarks on this?  Am I doing things correctly/incorrectly?
I'm using the printcap "formula" suggested for Red Hat in the hpoj
documents and it "works" (except for the aforementioned smp problem) but
never at anything close to even 600x600 dpi, let alone the 2400x1200 the
printer is nominally capable of.

Thanks,

   rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rg...@ph...