RE: [hpoj-devel] SMP patches?

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

On Tue, 5 Dec 2000, PASCHAL,DAVID (HP-Roseville,ex1) wrote:

> Hi, Robert.  It also sounds like an SMP problem to me.  Another thing you
> could try is to boot the SMP box with the "nosmp" kernel parameter, which
> puts it into UP mode.  I'll attempt to look into the problem in the near
> future, but I'll have to dig through a part of the code I'm not currently
> very familiar with.

I rearranged my whole mini-beowulf at home and hung the printer on an
otherwise mostly idle UP node and the TX busy message has gone away.
A regular printer on my SMP box (which was there before the HP came
home) is working fine.  So I really do suspect an SMP-related problem at
this point.

I'm going to spend some time trying to fix the printer resolution and
gamma problem next.  When I print photos, the gamma is without exception
too dark (which isn't the printer per se, which works "perfectly" on a
color copy process).  Pictures come out looking muddy and dark.  Even at
300dpi, the printer should be able to do much better, especially on the
more expensive smooth finish inkjet photo paper.  I don't know if this
is just an incongruity between the cdj550 postscript translator and this
printer or if it is a real problem with the printer itself, but I assume
the former.

> > Any helpful suggestions beyond that would be appreciated, especially
> > from folks who already know why the transmit while TX busy
> > message might
> > be occurring.  I did already note the new requirement that the printer
> > port be configured EPC (mine was SPP in the bios) and reset it but it
> > made no difference.  I'm guessing that was more for scanner function
> > anyway.  This seems like an overrun failure of the plain old printer
> > device.
> Are you able to scan successfully, particularly at higher resolutions which
> cause more data to be transferred for a longer period of time?  Of course,
> that's in the opposite direction, but even then there are small amounts of
> PC-to-printer data being transferred.

Even on the SMP box I scanned a photograph in a maximum resolution
without interruption or crash, but I didn't try several in a row as it
took so long.  However, the probability of an interrupt coming at the
wrong time is very low.  Presuming that what is occurring is like an
interrupt deadlock on an ethernet channel, when the computer is
receiving flow control is basically coming from the printer because it
is typically much slower than the computer.  When the computer is
sending (especially to a slow device) then it can overrun the transmit
and try to send the next (sk?)buffer if the second processor is idle and
not properly locked out.  I actually had more problems when my SMP box
was nearly idle than I did when I was working it and printing at the
same time.

If/when I get printing to work correctly so that we are set up to print
Christmas pictures and cards and so forth, I'll try turning on debug and
hang the printer back on the SMP box to see what happens.  Of course, if
you think that YOU are unfamiliar with the code... it isn't going to be
too likely that I figure out the deadlock, but miracles have happened
before;-)

   rgb

>
> David
> _______________________________________________
> hpoj-devel mailing list
> hpo...@li...
> http://lists.sourceforge.net/mailman/listinfo/hpoj-devel
>

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