cupsd-1.5.0 puts printer into endless processing loop

[gregorr]

Hello,

I used cups-1.3.10 with FreeBSD 8.0 (32bit) together with my laser printer. The printer manufacturer supplied the printer drivers (PPD-files). I have been never facing any problems. Since I upgraded to FreeBSD 9.0 with cups-1.5.0. Installing the same printer drivers, the cups-daemon puts my laserprinter into a permanent processing loop. Because the printer gets the job I assume devfs is configured correctly.

By the way:

%devfs rule show
100 path unlpt* group cups mode 770
200 path ulpt* group cups mode 770
300 path lpt* group cups mode 770
400 path ugen2.2 group cups mode 770
500 path usb/2.2.0 group cups mode 770
600 path usb/2.2.* group cups mode 770
700 path usb* group cups mode 770
800 path ugen* group cups mode 770
%

I did dmesg and the printer is recognized with ugen2.2. I even tried to [cmd=]cat out.pdf >/dev/ulpt0[/cmd] and the command succeeded. The printer started printing.

But printing via cupsd puts the printer into an endless processing loop.

I'll be grateful for any ideas!

 

[tingo]

Does the CUPS web management tool tell you anything?
How about the CUPS log files?

 

[gregorr]

I'am analyzing the file /var/log/cups/error_log right now. I put the cups daemon into debug mode with

cupsctl --debug-logging

Because I've opened a similar thread with the problem on http://www.cups.org.

http://www.cups.org/str.php?L4008

You can find the error log files there. Maybe I should mention that I've upgraded FreeBSD from 32bit to 64bit. I use the Kyocera drivers supplied by Kyocera called "Kyocera_FS-2000D_en.ppd". The ppd-file is just a text describing the printer.

 

[gregorr]

update

For those who are interested in this topic there was an update on:


http://www.cups.org/str.php?L4008

 

[gregorr]

Now my personal thoughts. I see that CUPS uses a postscript filter, taking the file you like to print converting it into postscript and writing it into /dev/ulpt0. In the case of CUPS the filter should be ghostscript. I can imagine that ghostscript can produce a corrupted output file itself or with wrong parameters given by the cups-daemon.

Furthermore I've recognized that cups-1.5 sends a file with postscript level 2 to my printer differently than cups-1.3 that sent a file in postscript level 3. I remind you that the printer works perfectly fine with cups-1.3.