laser-lovers@ucbvax.berkeley.edu.UUCP (01/24/86)
> We have a Canon Imagen 8/300 laser printer hooked up to SUN-2's > via Ethernet. We use these to print out graphs and binary images. > (halftones). The problem we have is that every time we send a > large image to be printed out to the Imagen, other smaller jobs > entered on the queue at a similar time myteriously get lost ! > i.e. they never print out ! > > Does anybody know what causes this ? Has anybody had a similar problem ? Let me answer this one. The problem is that there is a bug in the 4.2 spooler that Imagen has been distributing. Application support knows about the bug, and it has been fixed in the latest spooler distribution tapes (v2.2). When the spooler attempts to open a tcp connection to the printer, it executes a loop something like this: s = socket(...); for (;;) { if ( connect(s, printerid) < 0 ) { if ( errno == TIMEOUT || errno == REFUSED ) { sleep(60); continue; else { send message to a log file that is destroyed immediately (!) die. } } /* connection is open */ send_file_to_printer. break; } The problem is that connect destroys the socket with which it was called when it fails, such that future calls to connect return immediately complaining of an invalid socket. This causes a message to be logged and the spooler to abort the job. As luck would have it, the message is logged to a log file that is destroyed between print jobs, so it only exists on the system for about 1 second (!). The bug isn't mine (I didn't write this code), but a perusal of the relevant documentation for connect(II) would not lead one to believe that this is the true behavior of the connect call. The fix is to move the socket call into the loop and explicitly close the socket each time a connect fails: for (;;) { moved----> s = socket(...); if ( connect(s, printerid) < 0 ) { if ( errno == TIMEOUT || errno == REFUSED ) { new------> close(s); sleep(60); continue; else { send message to a log file that is destroyed immediately (!) die. } } /* connection is open */ send_file_to_printer. break; } In practise, there are several lines around the socket call that must be moved, but the change is straightforward (if it isn't clear from the above, contact application support at Imagen - (408)986-9400). By the way, you may wonder why this bug was only being exercised when the printer was processing large jobs. The printer only accepts one TCP connection at a time. The probability of hitting the printer while it is communicating with someone else is higher when the printer is receiving data for minutes at a time. - Geof Cooper Imagen
phil@RICE.EDU (William LeFebvre) (01/24/86)
> By the way, you may wonder why this bug was only being exercised when > the printer was processing large jobs. The printer only accepts one > TCP connection at a time. The probability of hitting the printer while > it is communicating with someone else is higher when the printer > is receiving data for minutes at a time. We also experienced this same behavior when the printer was out of paper for an extended period of time. And also, if I remember correctly, when someone kept the printer in manual feed for a long period of time. I complained about this problem to Imagen a L-O-N-G time ago. I'm glad that I finally have a fix! William LeFebvre Department of Computer Science Rice University <phil@Rice.edu>
mrose%NRTC@USC-ECL.ARPA (Marshall Rose) (01/30/86)
Sigh. Back in May, 1985, after struggling with that and about 10
other bugs, I sent Imagen back a tape with their 4.2BSD distribution
*fixed*. I got back a nice call regarding it and I had thought that
the fixes were going to be incorporated into a future release.
I do not have the facilities here to distribute the fixes, nor do I
want to get entangled in that. So, maybe someone at Imagen will
dig up the letter and tape and take a look at it.
I like the idea of putting laser printers on ethernets and
scattering 'em around. With the right fixes installed, everything
works real smoothly.
/mtr