I have hplj1100 and check net-print/hplip-3.11.1/3a When I print some I have 100% cpu usage. strace show a lot of: ... ioctl(6, PPFCONTROL, 0x7fff72b78cd0) = 0 ioctl(6, PPRSTATUS, 0x7fff72b78c80) = 0 ioctl(6, PPFCONTROL, 0x7fff72b78cd0) = 0 ioctl(6, PPRSTATUS, 0x7fff72b78c80) = 0 ioctl(6, PPWDATA, 0x7fff72b78cff) = 0 ioctl(6, PPFCONTROL, 0x7fff72b78cd0) = 0 ... $ wc -l delme/hp.trace.log 7519734 delme/hp.trace.log $ fgrep -v ioctl delme/hp.trace.log|wc -l 193 I believe it's a bug. Reproducible: Always
Found two "while (1)" in hplip-3.11.3a/io/hpmud/pp.c with ioctl inside for parallel port. I believe it too fast for lpt.
Please post your `emerge --info' too.
Created attachment 268517 [details] emerge --info
I don't own a parallel port printer but you can try patching io/hpmud/pp.c by setting higher values for the while loops and test if this fixes the problem. This is no ebuild problem and I can not fix it so I would like to ask if you can open a bug upstream at https://bugs.launchpad.net/hplip and report the bug number here.
https://bugs.launchpad.net/hplip/+bug/750796
Created attachment 299791 [details, diff] patch by Daniel Gnoutcheff From the upstream bug: ----------------------------- Daniel Gnoutcheff (gnoutchd) wrote on 2011-07-14: #15 hplip-fast-pp.patch (21.3 KiB, text/plain) The parallel port code is quite CPU intensive. That, I think, is what we're seeing here. On my (admittedly rather old) system, the CPU is the bottleneck for parallel port I/O, and it's a very severe bottleneck indeed. Trying to scan something with an OfficeJet R80 takes so long that it is unusable. The problem is that, for reasons that aren't clear to me, HPLIP implements ECP in userspace via ppdev ioctls. Because of this, we make something like 5-10 system calls for every byte sent over the wire. That's a staggeringly huge overhead, and I don't think it's necessary. The Linux parallel port subsystem already has IEEE1284 support, and since that code lives in kernel space, it avoids the huge syscall overhead. ppdev allows us to use this code via the usual read/write functions. I've attached a patch that makes hplip use ppdev reads and writes. I've successfully tested this against the aforementioned OfficeJet, and it massively reduces CPU usage (and dramatically improves scan speed). As a nice side-effect, the code is shortened by 389 lines. I've seen some comments suggesting that ppdev read and writes are less reliable than what we do now. Having looked at the source code of the Linux parallel port subsystem, I'm not sure how this could be the case. By default, the parport code implements ECP via software emulation, just like hplip does now. Indeed, The code does include some support for hardware acceleration, but on PC's at least, this support is disabled by default.
+*hplip-3.11.12-r2 (25 Jan 2012) + + 25 Jan 2012; Daniel Pielmeier <billie@gentoo.org> +hplip-3.11.12-r2.ebuild, + +files/hplip-3.11.12-fast-pp.patch: + Fix bug #361847. Thanks to ungift-ed for the report, Daniel Gnoutcheff for + the patch provided at the upstream bug and Andreas K. Hüttel for reminding + me about the patch.
