Description of problem: After upgrading from fc32 to fc33 printing to Samsung ML-2240 stopped working. Test page sometimes prints normally, but sometimes prints error. Printing a PDF does not seem to work at all. Sometimes the printer just flashes, sometimes it prints an error message, but never the actual document. Version-Release number of selected component (if applicable): cups-2.3.3op2-1.fc33.x86_64 How reproducible: Very Steps to Reproduce: 1. Print test page 2. 3. Actual results: Prints something like this: "INTERNAL ERROR - FALSE POSITION : {random number} SYSTEM : h6wsim_snipe/x1_pa_sim LINE : 254 VERSION : SPL 5.07 06-27-2006" Expected results: Print test page Additional info:
Hi Miklos, thank you for reporting the issue! Would you mind telling me how is your printer connected? If it is by USB, it maybe the same problem as https://bugzilla.redhat.com/show_bug.cgi?id=1935318 . In that case, would you mind trying these rpms https://koji.fedoraproject.org/koji/taskinfo?taskID=64422836 and tell me if they works? If the rpms don't help, please follow https://fedoraproject.org/wiki/How_to_debug_printing_problems#My_printer_doesn.27t_print_correctly_or_at_all.2C_but_I_can_see_the_printer_in_print_dialog and provide all information mentioned there. Thank you in advance!
There are testing rpms with longer timeout too https://koji.fedoraproject.org/koji/taskinfo?taskID=64412423 - if the previous rpms don't work, please the link in this comment. The core of the problem for USB appears to be shorter timeout than old Samsung devices can handle, so I'm trying to figure out the shortest timeout possible to support currently broken devices and don't hurdle too much new devices.
(In reply to Zdenek Dohnal from comment #2) > There are testing rpms with longer timeout too > https://koji.fedoraproject.org/koji/taskinfo?taskID=64412423 - if the > previous rpms don't work, please the link in this comment. > > The core of the problem for USB appears to be shorter timeout than old > Samsung devices can handle, so I'm trying to figure out the shortest timeout > possible to support currently broken devices and don't hurdle too much new > devices. Second one seems to be okay. Thanks.
*** This bug has been marked as a duplicate of bug 1935318 ***
Thanks for the confirmation, Miklos!