Bug 500093 - CUPS only prints blank pages
CUPS only prints blank pages
Product: Fedora
Classification: Fedora
Component: cups (Show other bugs)
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Tim Waugh
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-05-10 18:02 EDT by Mark Bidewell
Modified: 2009-06-17 09:24 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-06-17 09:24:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
troubleshoot.txt (42.43 KB, text/plain)
2009-05-10 18:03 EDT, Mark Bidewell
no flags Details
ML2010.ppd (28.16 KB, application/vnd.cups-ppd)
2009-05-11 21:51 EDT, Mark Bidewell
no flags Details
test.ps (768.77 KB, application/postscript)
2009-05-12 07:24 EDT, Tim Waugh
no flags Details

  None (edit)
Description Mark Bidewell 2009-05-10 18:02:22 EDT
When I attempt to print I get blank sheets of paper from the printer.  The printer is connected via IPP but the server has not changed.  The printer is an ML-2010 using the F11 shipped PPD.
Comment 1 Mark Bidewell 2009-05-10 18:03:00 EDT
Created attachment 343304 [details]
Comment 2 Tim Waugh 2009-05-11 05:23:29 EDT
This message: "/usr/lib/cups/backend/http failed", just seems to be incorrect, so that isn't the problem.

Otherwise that looks like a normal print log.

When you say "the server has not changed", are you using a hardware print server connected to the printer in order to use IPP with it?  Are you able to try a different connection type other than IPP?
Comment 3 Mark Bidewell 2009-05-11 09:20:20 EDT
The server is cupsd running on Kubuntu 9.04.  There are two queues on the server:

1)  Local queue with PPD 
2)  Raw queue for remote systems.

The local queue works fine.  I have had successful prints from windows boxes and F10 to the remote queue.  What other connection type would you suggest?
Comment 4 Tim Waugh 2009-05-11 09:32:09 EDT
Oh, I see.  Can you attach /etc/cups/ppd/ML2010.ppd please?

When you attempted to print a test page, did you get more than one blank page printing?
Comment 5 Mark Bidewell 2009-05-11 09:45:52 EDT
(In reply to comment #4)
> Oh, I see.  Can you attach /etc/cups/ppd/ML2010.ppd please?
> When you attempted to print a test page, did you get more than one blank page
> printing?  

Only one page.  Do you want the F11 PPD the server PPD or both?
Comment 6 Tim Waugh 2009-05-11 10:30:09 EDT
The one being used when blank pages are printed, so the one from the client (F11).
Comment 7 Mark Bidewell 2009-05-11 21:51:33 EDT
Created attachment 343525 [details]

This is the ppd I am using (it is the one currently shipped with F11.
Comment 8 Tim Waugh 2009-05-12 07:24:14 EDT
Created attachment 343567 [details]

Please try printing this file.  It is the PostScript version of the test page.  If this also fails, the problem is on the server side.
Comment 9 Tim Waugh 2009-05-12 07:26:43 EDT
Sorry, getting mixed up with another bug.  If this fails, we'll need to look at the IPP traffic in more detail.

When did printing last work -- were you using Fedora 10 on this machine previously?
Comment 10 Mark Bidewell 2009-05-16 10:42:44 EDT
Before I saw your posts I decided to try using the recommended PPD from here:


On the client which solved the issue.  Strangely even the GDI driver that is shipped now works so either the splix driver did some initialization on which the old driver is piggybacking or the openprinting RPM replaced the default PPD.

Let me know if I should investigate further.
Comment 11 Bug Zapper 2009-06-09 11:37:02 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
Comment 12 Tim Waugh 2009-06-17 09:24:35 EDT
The openprinting RPM does not replace the default PPD, so it must be some sort of firmware/initialisation thing.

However, we can't ship the splix driver due to potential patent problems.

Note You need to log in before you can comment on or make changes to this bug.