Description of problem: Since moving from F19 32-bit to F21 x86_64 and moving my cups config (printers.conf, etc) over my old laser on a (real!) parallel port is very slow to print. The printer "data" light flashes for about 3-4 minutes and the whole time top shows a ps called "parallel" (/usr/lib/cups/backend/parallel) taking 100% CPU. In F19 the printer would print that page in about 15s. It only seems to have this bug when printing heavy graphics. A single PDF page is enough. Printing a text file with lpr does *not* cause this problem. This bug sounds exactly like 2012 bugs that supposedly were fixed upstream (fixed ages ago): https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/936647 http://forum.siduction.org/index.php?topic=1962.0 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659736 Maybe a regression? Or maybe something with my config? Version-Release number of selected component (if applicable): cups-filters-1.0.58-1.fc21.x86_64 cups-1.7.5-13.fc21.x86_64 kernel-3.17.7-300.fc21.x86_64 How reproducible: Always. Steps to Reproduce: 1. print an image/pdf to parallel printer 2. 3. Actual results: Takes 3-4 mins. Then prints fine. parallel takes 100% cpu. Expected results: Print in about 15s with lower cpu load. Additional info: from printers.conf: <DefaultPrinter laser> UUID urn:uuid:e59b6a1e-0bb4-3cde-68b3-57c200f2aec9 Info laser MakeModel Brother HL-660 Foomatic/hpijs (recommended) DeviceURI parallel:/dev/lp0 State Idle StateTime 1419461418 Reason ;marker-supply-low-warning Type 8433684 Accepting Yes Shared Yes JobSheets none none QuotaPeriod 0 PageLimit 0 KLimit 0 OpPolicy default ErrorPolicy stop-printer </Printer>
Quick update: I actually went to fetch the printout and it was printing a tiny corner of the pdf blown up, so I think it was sending a massive amount of data to my printer but telling it to just print one corner. I was using qpdfview to print a 1-page PDF (I don't usually use qpdfview). I tried printing the same 1-page pdf with the command line: lpr -Plaser -o fit-to-page /tmp/foo.pdf And it took exactly 30s of 100% parallel cpu usage before parallel stopped and the printer printed. That is much less egregious than my previous report of 3-4 mins, and it is possibly acceptable. However, it strikes me as odd that a 400k 1-page PDF should take 30s to process in cups before the printer even starts to print, when in F19 it would take 15s max. This isn't a horribly slow computer, it's a core2 quad 2.4G. If this is cpu load and slowness is normal behavior now, please close this bug. If not, I can help to solve it.
When you set a print going, take a note of the 'parallel' process ID and let's see what it's up to: strace -ttp $PID 2>&1 | tee /tmp/parallel-strace Could you please attach the resulting /tmp/parallel-strace please using the 'Add an attrachment' link above?
Sure. See attached in a minute. It's actually not too slow now. Still about 30s but I tried some other PDF files that didn't contain as many graphics and they print much faster (like my text file test did). So it may just be this one graphic-heavy 1-page PDF file. It appears to simply be doing select/write to get the data out. This gets me thinking, perhaps the new kernel isn't obeying my BIOS parallel port settings (DMA, etc). High CPU on ancient style I/O would be "normal". I'm not sure how to check kernel parallel port settings but I will look into it now. I just don't recall the 100% cpu usage when printing before, but I may not have noticed it? If this isn't a bug, my apologies.
Created attachment 978069 [details] output of strace on parallel ps during 100% CPU usage
Ah, yes indeed linux has set my port to crappy I/O: #cat /proc/sys/dev/parport/parport0/{modes,irq,dma} PCSPP,TRISTATE 7 -1 I'm attempting to figure out how to override these to get ECP,DMA,TRISTATE If this turns out to be a problem just with my config (I must reboot to check BIOS I guess) I apologize and will report back. If this is the kernel detecting the wrong settings (whereas it didn't in F19) I'll let you know.
(I've changed component/summary to reflect the new knowledge.) Confirmed, my BIOS was/is set to ECP mode. Linux kernel parport_pc module is detecting this as SPP only, with an IRQ but no DMA. Interestingly, if I set the BIOS to EPP, linux detects the EPP (IRQ but no DMA), but the print speed (parallel 100% process execution time) stays exactly the same and no change to cpu usage. See the output at bottom. I'm nearly positive (though not 100%) that my previous Fedora 19 32-bit did not consume 100% CPU or take as long to print. I could be wrong. For sure the SPP is what is causing the slow print. A DMA-based ECP would not take 100% CPU. So my problem is linux parallel port setting detection on my hardware. It is a 2008-era Intel D975XBX2 board with Q6600 CPU. Is this something that is supposed to work or something that is kind of abandoned in the kernel? I know parallel ports are obsolete, but I like to use all the old lasers I have sitting around, and my 2008 board was one of the last to have built-in backplate parallel. Interestingly, dmidecode doesn't show the parallel port as it does on other machines, though it has a lot of "unknown" entries it can't figure out. I tried overriding the parport options in modprobe when the BIOS was in ECP mode, and I can get it to say there is DMA, but I can't get it to say there is ECP. And the speed/cpu stays exactly the same, and this time nothing prints (no data sent to printer), so obviously I'm foobaring something by doing that. If parallel support is deprecated then I can live with the slowness. I don't print to these printers much. It could also be a bug in the firmware/hardware of my motherboard, though Intel usually does an OK job. If anyone cares to work on this, I can compile & test stuff. Otherwise it's not that important. bios set to ECP: Jan 10 01:48:08 pog kernel: [ 24.355026] parport_pc 00:05: reported by Plug and Play ACPI Jan 10 01:48:08 pog kernel: [ 24.355083] parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE] Jan 10 01:48:08 pog kernel: [ 24.368254] parport0: Legacy device ==> autoprobe <== MODEL:Brother HL-660 series; MANUFACTURER:; COMMAND SET:PCL4; ==> base-addr <== 888 1912 ==> dma <== -1 ==> irq <== 7 ==> modes <== PCSPP,TRISTATE bios set to EPP: Jan 10 01:19:19 pog kernel: [ 24.896713] parport_pc 00:05: reported by Plug and Play ACPI Jan 10 01:19:19 pog kernel: [ 24.896739] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE,EPP] Jan 10 01:19:19 pog kernel: [ 24.910149] parport0: Legacy device ==> autoprobe <== MODEL:Brother HL-660 series; MANUFACTURER:; COMMAND SET:PCL4; ==> base-addr <== 888 0 ==> dma <== -1 ==> irq <== 7 ==> modes <== PCSPP,TRISTATE,EPP
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 21 kernel bugs. Fedora 21 has now been rebased to 3.18.3-201.fc21. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
Bug persists in kernel-3.18.3-201.fc21.x86_64
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 21 kernel bugs. Fedora 21 has now been rebased to 3.19.5-200.fc21. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 22, and are still experiencing this issue, please change the version to Fedora 22. If you experience different issues, please open a new bug report for those.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Bug persists in Fedora 22 4.2.6-200.fc22.x86_64 Printing a single page of full-page-picture PDF causes parallel process to run for 33s at 100% CPU. But over time I've come to believe (without evidence though) that there's a bug on the board/BIOS that is breaking ECP. I'm going to test 1 more system to see what its parallel looks like, and how it behaves with my printer, and it that one works fine I'll just close as a hardware problem.
I moved the printer in question to my other server (right next to it), call it #2, and ensured that server had ECP enabled. My tests showed the kernel understood this motherboard and parallel port: it had DMA set to 1. Doing a print test it still took about 30s to print, but the CPU load was 2% the whole time. So server #2 is working fine and this bug does not present. So it's just my server #1 board. I'm not sure what to do now. If someone wants to help me do some tests/patches on the kernel to see why it's not detecting DMA properly on my board, I will be glad to help. This problem seems specific to my board model. At this stage it could be either a hardware BIOS bug, or a kernel detection bug. If it's a hw bug, perhaps the kernel could add a hw bug/workaround override to make DMA work anyway. I'll leave this open for now.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.