1

When I reboot, a queued print job will get printed, after that jobs don't print with the following message: processing since "Waiting for printer to become available."

Also, when I run the vanilla ubuntu kernel printing works fine.

No idea where to start on this one -- Tried to do all the obvious like google, cups debug logs, syslog. Read through the bugs filed against this package and didn't see anything likely, but could have missed it. Need some direction on how to proceed/which subsystem to focus on: cupd config or usb or ppds or kernel or ...?

I accidentally discovered that when I run the latest vanilla ubuntu kernel printing works fine. (https://wiki.ubuntu.com/Kernel/MainlineBuilds) Because of this I have hesitated to start trying different print drivers, cups configs, etc, since a different kernel fixes the problem. I would rather keep the Ubuntu kernel in place, since rolling my own kernel is going to break a lot of random stuff.

I went through the steps at https://wiki.ubuntu.com/DebuggingPrintingProblems nothing changed.

Cups has always been a bit of a black box to me, so with some pointers on which diagnostics to run, I should be able to get this sorted. I set cups loglevel to debug, and it does spew a lot of stuff. One line looked interesting as it contained the string "failed": FindDeviceById failed: org.freedesktop.ColorManager.NotFound:device id 'cups-HL-2040-series' does not exist

Not sure what this means, or how it relates to my intermittent problem.

# uname -r
3.16.0-28-lowlatency

Printer info:

HL-2040-series  Brother HL-2040 series Brother HL-2040 Foomatic/hl1250 (recommended)


# lsmod | grep usb
usblp                  18756  0
btusb                  32448  0
bluetooth             446374  22 bnep,btusb,rfcomm

# lpinfo -v
network socket
direct parallel:/dev/lp0
network ipp
network lpd
network http
network https
direct hp
network ipps
direct usb://Unknown/Printer
network ipp14
serial serial:/dev/ttyS0?baud=115200
serial serial:/dev/ttyS1?baud=115200
network smb
direct hpfax

Update: I found the failure, and why the grepping for "failed" didn't work. Should have grepped for "Failed". Job 61 printed fine, but google shows there are others out there who have addressed this, some as far back as 2010, so maybe this is a recent kernel bug regression.

D [19/Dec/2014:09:57:57 -0800] [Job 62] Switching USB device configuration: 0 -> 1 D [19/Dec/2014:09:57:57 -0800] cupsd is not idle any more, canceling shutdown. D [19/Dec/2014:09:57:57 -0800] [Job 62] Failed to set configuration 1 for 04f9:0028 D [19/Dec/2014:09:57:57 -0800] [Job 62] STATE: -connecting-to-device D [19/Dec/2014:09:57:57 -0800] cupsdMarkDirty(---J-) D [19/Dec/2014:09:57:57 -0800] cupsdSetBusyState: newbusy="Printing jobs and dirty files", busy="Dirty files" D [19/Dec/2014:09:57:57 -0800] Discarding unused printer-state-changed event... D [19/Dec/2014:09:57:57 -0800] cupsd is not idle any more, canceling shutdown. D [19/Dec/2014:09:57:57 -0800] cupsd is not idle any more, canceling shutdown. D [19/Dec/2014:09:57:57 -0800] [Job 62] Failed to re-attach "usblp" kernel module to 04f9:0028

1 Answer 1

3

Seems to have been a flakey cable. Why it would reliably print once, then choke after a power cycle, seems illogical. But a cable swap fixed this issue.

Hope this helps to remind the next person to check over the hardware before going medieval on the error logs...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .