Red Hat Bugzilla – Bug 131374
Completely unable to print
Last modified: 2007-11-30 17:10:48 EST
Description of problem:
After updating from rawhide to the current RC for CUPS, I am now
unable to print anything - I have had to turn off via
system-config-services cupsd otherwise booting takes upto 5 minutes to
hit the gnome login. When I run system-config-printer, the printer
window appears, but pressing edit causes a lot of disc thrashing
(almost to Windows standards!) and eventually the desktop resets
(nautilus, gnome-panel and all running applications are quit with only
nautilus and gnome-panel restarting).
If I run /etc/init.d/cupsd start, the system locks up requiring a
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start system-config-printer
2. Click on edit for the printer
See the description above
I should be able to print and edit the printer
/var/log/cups/error_log is showing this
I [30/Aug/2004:01:30:23 +0100] Listening to 7f000001:631
I [30/Aug/2004:01:30:23 +0100] Loaded configuration file
I [30/Aug/2004:01:30:23 +0100] Configured for up to 100 clients.
I [30/Aug/2004:01:30:23 +0100] Allowing up to 100 client connections
I [30/Aug/2004:01:30:23 +0100] Full reload is required.
W [30/Aug/2004:01:30:54 +0100] LoadDevices: Backend did not respond
within 30 seconds!
W [30/Aug/2004:01:51:36 +0100] LoadDevices: Backend did not respond
within 30 seconds!
W [30/Aug/2004:02:01:36 +0100] LoadDevices: Backend did not respond
within 30 seconds!
I [30/Aug/2004:02:11:10 +0100] LoadPPDs: Read "/etc/cups/ppds.dat",
I [30/Aug/2004:02:11:11 +0100] LoadPPDs: No new or changed PPDs...
I [30/Aug/2004:02:11:12 +0100] Full reload complete.
I [30/Aug/2004:10:55:00 +0100] Scheduler shutting down normally.
The files in the URL archive demonstrate what happens with cupsd
enabled during boot, disabled during boot (print2.txt) and an strace
-f for system-config-printer
I have checked for duplicate packages for cups and found none. I have
not compiled from source.
I have tried the following
1. Reboot to the 526 kernel
2. Switch off SELinux
3. Install CUPS from source
Moving to the 526 kernel started the cups server, but SELinux stopped
being able to login. Tried without selinux, cups started, but s-c-p
still would not allow me to edit the printer
The fresh install of cups fixed nothing
Switching off SELinux for the 532 and 533 kernels did nothing (boot up
took >5 mins and still unable to edit the printer via scp without much
One thing I have noticed is that none of the usb modules are loaded. I
have now tried the following
both of these were fine and loaded without a problem
this caused the same thrashing of the drive as seen with trying to
edit the printer via scp.
I'm using a HP980cxi over usb.
This makes me wonder if the problem is kernel related rather than
gives an error to say that the module doesn't exist.
You need to avoid using 2.6.8-1.533, since that messes up all sorts of
USB things due to an experimental driver being mistakenly enabled.
Also, please try one thing at a time -- I'm sorry I haven't managed to
get this to yet, because of the imminent freeze, but please be patient
and let me ask you to try things.
I'll need to you uninstall whatever you installed from source. I need
you to have things installed from RPM packages so that I know I'm
looking at the same code this end.
Concerning the long start-up time of cupsd, do you have
gimp-print-cups installed? If so, remove it.
Has the experimental driver been fixed in the current kernel (538)? If
not, I'll go back to 532 and give that a shot, but from memory, that
one suffered from the same problem.
I'll remove the compiled from source cups tonight and gimp-print-cups
as well and let you know how it gets on.
I think it was just 533 that was bad; 534 at least had the bad driver
After pratting about for the past 2 hours post update (darned
module-init-tools being bust!), I've now done the following
1. Removed completely the self compiled version of cups and the rpm of
2. Moved to the 532smp kernel
Boot up went okay. /sbin/modprobe usblp still hammers the HD and fails
to load. /etc/init.d/cups start hammers the disk and even if I close
the terminal window I used to try and start cups, the HD is still
hammered until the entire system grinds to a halt requiring a power reset.
3. Reboot, this time add selinux=0 to the boot command line, still
Still no go. usblp fails to load and cups start kills the machine.
This looks like a kernel issue to me. Leave CUPS out of the equation
altogether for the moment and let's look at the 'modprobe usblp'
After you run that command, what error message do you get? Also, what
does 'dmesg' say?
modprobe usblp gives no error message at all. The hard drive gets
hammered. I've left it for upto 10 minutes incase something happens,
the drive slows down, hammers, stops, hammer, stop, hammer...
The only way to kill the attempt to load is to kill the terminal
window I'm using to load the module in.
I'll need to check what dmesg says.
Created attachment 103387 [details]
dmesg created on boot this morning
Nothing seems to have registered when running /sbin/modprobe usblp - this is
Cups and /sbin/modprobe usblp are working with the current kernel in
rawhide (3rd Sept). s-c-p also seems happy
usb-ehci is still reported as being missing though. Has this vanished?
I do not understand what the word "still" was supposed to mean in the
comment #10. A module "usb-ehci" never existed. It's not even an
alias in modprobe, at least not when I run "modprobe -c| grep hci".
Would the requestor close this bug now?