Tasses travail bloqué à: traitement depuis ... "En attente de la disponibilité de l’imprimante."
Lorsque je redémarre, un travail d'impression en file d'attente est imprimé. Après cela, les travaux ne s'impriment pas avec le message suivant: traitement depuis "En attente de la disponibilité de l'imprimante."
En outre, lorsque je lance l'impression du noyau ubuntu vanille, cela fonctionne bien.
Aucune idée par où commencer sur celui-ci - J'ai essayé de faire toutes les choses évidentes comme Google, les journaux de débogage de cups, Syslog. Lisez les bogues enregistrés contre ce paquet et ne voyez rien qui puisse probablement, mais aurait pu le manquer. Vous avez besoin d’indications sur la façon de procéder/sur quel sous-système sur lequel vous concentrer: cupd config ou usb ou ppds ou kernel ou ...?
J'ai accidentellement découvert que lorsque je lance la dernière impression du noyau Vanilla ubuntu, cela fonctionne bien. ( https://wiki.ubuntu.com/Kernel/MainlineBuilds ) Pour cette raison, j'ai hésité à essayer différents pilotes d'impression, configurations de gobelets, etc., car un noyau différent corrige le problème. Je préférerais garder le noyau Ubuntu en place, car le lancement de mon propre noyau va casser beaucoup de choses aléatoires.
Je suis passé par les étapes sur https://wiki.ubuntu.com/DebuggingPrintingProblems rien n'a changé.
Les tasses ont toujours été un peu une boîte noire pour moi, donc avec quelques indications sur lesquelles des diagnostics doivent être exécutés, je devrais être capable de résoudre ce problème. Je règle les gobelets loglevel pour déboguer, et cela crache beaucoup de choses. Une ligne semblait intéressante car elle contenait la chaîne "failed": FindDeviceById a échoué: org.freedesktop.ColorManager.NotFound: l'ID de périphérique 'cups-HL-2040-series' n'existe pas
Je ne sais pas ce que cela signifie ni comment cela se rapporte à mon problème intermittent.
# uname -r
3.16.0-28-lowlatency
Informations sur l'imprimante:
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
Mise à jour: j'ai trouvé l'échec et pourquoi la recherche de "échec" n'a pas fonctionné. Aurait dû être reconnu pour "Echec". Le travail 61 a bien été imprimé, mais Google indique qu'il y en a d'autres qui ont déjà abordé cette question, dont certains remontent à 2010, alors c'est peut-être une régression récente du noyau.
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
Semble avoir été un câble floconneux. Pourquoi il serait fiable imprimer une fois, puis étouffer après un cycle d'alimentation, semble illogique. Mais un échange de câble a résolu ce problème.
J'espère que cela aidera à rappeler à la prochaine personne de vérifier le matériel avant de passer au moyen-âge sur les journaux des erreurs ...