hpoj-devel

[hpoj-devel] Laserjet 1220 hangs on the second job - possible cause

[Tomasz M. <tm...@du...>]

I have the same problem as the one mentioned at the end of the
message:

http://sourceforge.net/mailarchive/message.php?msg_id=2306606

The difference is that the problem happens almost always on my
system. After I print one job and I send another one, the printer
usually hangs as described in the mentioned message. I suspect that
this is caused by a race condition, so whether the printer hangs or
not may depend on computer speed, CPU load etc.

I have Intel Pentium III 800 MHz CPU running Debian Woody. I use CUPS
as a spooler. I have HP Laserjet 1220 connected via USB.

When I investigated the problem, I was using sources from CVS.
I was printing files using ptal-print this way:

ptal-print <test.prn

where test.prn was a CUPS output for some postscript file. I tried it
also with Windows drivers output.

The suspected race condition goes as follows:

- ptal-print sends the job, job data are buffered waiting for ptal-mlcd
  to receive them
- after sending all the data, ptal-print closes a socket and exits
- ptal-mlcd receives part of the job data
- as ptal-mlcd has some reverse data from the previous job (it ended
  with @PJL ECHO EOJ), it tries to send it to ptal-print
- the connection to ptal-print is broken, so ptal-mlcd receives
  SIGPIPE, write failes and (in ExMgr::sessionServiceOutput) it
  duplicates the /dev/null file descriptor in place of the session
  socket
- ptal-mlcd hits EOF on /dev/null when trying to receive the rest of
  the job and the printer does not receive the entire job

I have been redirecting data read in ExMgr::pullForwardData to a file
and the second job was in fact truncated there.

I commented out nullDup call in ExMgr::sessionServiceOutput and
everything started to work fine. I have not yet written a more elegant
solution, but it seems that after a failed write to a session socket,
ptal-mlcd should continue to read from the socket, but drop buffers
waiting to be written to it and all the buffers that will be added to
pReverseBdrQueue later.

Tomasz Malesinski

Re: [hpoj-devel] Laserjet 1220 hangs on the second job - possible cause

[Cory M. <cor...@hp...>]

Thx for your effort on this... I have forwarded your suggestions on to
the developers.

Cory
hp linux printing team

On Thu, 2004-08-05 at 16:17, Tomasz Malesinski wrote:
> I have the same problem as the one mentioned at the end of the
> message:
> 
> http://sourceforge.net/mailarchive/message.php?msg_id=2306606
> 
> The difference is that the problem happens almost always on my
> system. After I print one job and I send another one, the printer
> usually hangs as described in the mentioned message. I suspect that
> this is caused by a race condition, so whether the printer hangs or
> not may depend on computer speed, CPU load etc.
> 
> I have Intel Pentium III 800 MHz CPU running Debian Woody. I use CUPS
> as a spooler. I have HP Laserjet 1220 connected via USB.
> 
> When I investigated the problem, I was using sources from CVS.
> I was printing files using ptal-print this way:
> 
> ptal-print <test.prn
> 
> where test.prn was a CUPS output for some postscript file. I tried it
> also with Windows drivers output.
> 
> The suspected race condition goes as follows:
> 
> - ptal-print sends the job, job data are buffered waiting for ptal-mlcd
>   to receive them
> - after sending all the data, ptal-print closes a socket and exits
> - ptal-mlcd receives part of the job data
> - as ptal-mlcd has some reverse data from the previous job (it ended
>   with @PJL ECHO EOJ), it tries to send it to ptal-print
> - the connection to ptal-print is broken, so ptal-mlcd receives
>   SIGPIPE, write failes and (in ExMgr::sessionServiceOutput) it
>   duplicates the /dev/null file descriptor in place of the session
>   socket
> - ptal-mlcd hits EOF on /dev/null when trying to receive the rest of
>   the job and the printer does not receive the entire job
> 
> I have been redirecting data read in ExMgr::pullForwardData to a file
> and the second job was in fact truncated there.
> 
> I commented out nullDup call in ExMgr::sessionServiceOutput and
> everything started to work fine. I have not yet written a more elegant
> solution, but it seems that after a failed write to a session socket,
> ptal-mlcd should continue to read from the socket, but drop buffers
> waiting to be written to it and all the buffers that will be added to
> pReverseBdrQueue later.
> 
> Tomasz Malesinski
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technology
> Group. Come see the changes on the new OSTG site. www.ostg.com
> 
> _______________________________________________
> hpoj-devel mailing list
> hpo...@li...
> https://lists.sourceforge.net/lists/listinfo/hpoj-devel

Re: [hpoj-devel] Laserjet 1220 hangs on the second job - possible cause

[Tomasz M. <tm...@du...>]

On Fri, Aug 06, 2004 at 01:17:27AM +0200, Tomasz Malesinski wrote:
> I commented out nullDup call in ExMgr::sessionServiceOutput and
> everything started to work fine. I have not yet written a more elegant
> solution, but it seems that after a failed write to a session socket,
> ptal-mlcd should continue to read from the socket, but drop buffers
> waiting to be written to it and all the buffers that will be added to
> pReverseBdrQueue later.

Here is a patch that works for me:

diff -ur hpoj/mlcd/ExMgr.cpp hpoj.1/mlcd/ExMgr.cpp
--- hpoj/mlcd/ExMgr.cpp	Tue Nov  4 02:03:18 2003
+++ hpoj.1/mlcd/ExMgr.cpp	Sat Aug  7 15:18:40 2004
@@ -1365,6 +1365,7 @@
 		session[scd].scdlink=ERROR;
 		session[scd].pmlTrapsRegistered=0;
 		session[scd].bitbucketSocket=0;
+		session[scd].outBitbucketSocket=0;
 		if (oldState==SESSION_STATE_STARTUP) break;
 		if (session[scd].pCommandBdr) {
 			forwardDataResponse(scd,session[scd].pCommandBdr,
@@ -2308,6 +2309,15 @@
 	LOG_ASSERT(pBdr,cEXBP,0,0);
 	LOG_ASSERT(status==MLCD_STATUS_SUCCESSFUL,cEXBP,0,0);
 
+	if (session[scd].outBitbucketSocket) {
+		while (pBdr) {
+			next=pBdr->getNext();
+			pBdr->returnBuffer();
+			pBdr=next;
+		}
+		return;
+	}
+
 	if (session[scd].state==SESSION_STATE_OPEN_PENDING) {
 		if (scd>=FIRST_TRANSPORT_SESSION &&
 		    scd<=LAST_TRANSPORT_SESSION) {
@@ -2357,7 +2367,10 @@
 			data=pBdr->getStartAddress()+pBdr->getDataOffset();
 			r=sessionWrite(scd,data,datalen);
 			if (r<0) {
-				nullDup(session[scd].fd);
+				session[scd].outBitbucketSocket = 1;
+				session[scd].pReverseBdrQueue->empty();
+				fdRegister(session[scd].fd,0,-1);
+				break;
 			} else if (r!=datalen) {
 				pBdr->unprependData(r);
 				break;
diff -ur hpoj/mlcd/ExMgr.h hpoj.1/mlcd/ExMgr.h
--- hpoj/mlcd/ExMgr.h	Tue Nov  4 02:03:18 2003
+++ hpoj.1/mlcd/ExMgr.h	Sat Aug  7 15:04:02 2004
@@ -834,6 +834,7 @@
 		ExBdr *pCommandBdr;
 		int pmlTrapsRegistered;
 		int bitbucketSocket;
+		int outBitbucketSocket;
 	} session[MAX_SESSIONS];
     protected:
 #ifdef JD_DEBUGLITE