I have two printers that have stopped accepting jobs via their USB subsystem. CUPS sees the printer USB ports, has been able to send jobs to them in the past, but can't talk to them:

cas@odysseus:to-print> lpstat -a | tail -4
samsung-ml2010 not accepting print requests since Sat 04 Oct 2014 07:09:05 AM CEST -
        reason unknown
sharp-al1035 not accepting print requests since Mon 06 Oct 2014 11:14:09 AM CEST -
        reason unknown

Calling Samsung's hotline first gave me a reference to a "service partner" who says they have stopped being a service partner, too much trouble for the income associated with USB subsystem problems. Second call gives a service partner who says it is cheaper to buy a new printer than fix a USB subsystem problem. I have not tried to talk to Sharp yet.

Probably there each reason has its own particular reason for why it won't talk CUPS and the printers cannot be made to work via USB. Can any further information about the problem be divulged using the CUPS side, though?

  • Just curious. What does lsusb -v return? In addition, did you install this printer via CUPS web interface in the first place? – gacanepa Oct 10 '14 at 19:46
  • IIRC, lsusb recognised that there was a USB device there for the Samsung printer but could not poll it. The printer failed to behave coherently with two flavours of Linux machine, Win7, Win8.1, OSX10.6 and OSX10.9, and caused the Samsung unified printer architecture debugging suite to crash on every machine that would run it. It was the Linux behaviour that led the 2nd Samsung service partner to be confident that it was clearly a USB subsystem problem. But I'm interested in a general approach to gathering diagnostics on USB printers that fail. – Charles Stewart Nov 4 '14 at 15:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.