Resolved this issue by lowering and creating custom DPI values.
Default DPI from foomatic postcript PPDs is usually 600 DPI or 1200 DPI.
Ghostscript `pdftops` and `gs` both take a long time converting high DPI
values. The 600 DPI also creates a large postscript file which in turn
are slow over
There's a new bug for precise (ubuntu 12.04):
https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/668800
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/463059
Title:
Process 'gs' begins
precise pangolin affected too (wasn't the case in natty).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/463059
Title:
Process 'gs' begins taking 100% CPU and loading up vast amounts of RAM
To
The foomatic-rip fix makes Ghostscript not being used and so works
around a Ghostscript bug, bug 668800. In addition the Cairo bug 680628
makes the problem even worse. So if you have still problems, please
discuss them in these bug reports.
--
Process 'gs' begins taking 100% CPU and loading up
If there are still problems with high resource consumption by
Ghostscript, see bug 668800.
--
Process 'gs' begins taking 100% CPU and loading up vast amounts of RAM
https://bugs.launchpad.net/bugs/463059
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Today I hit jackpot again, having a D630 trying to print a PDF file with
Evince to a HP Laserjet 3600 with 10.04. GS took one core to 100%,
making system unresponsive again, it's hard to kill the basterd then ;)
Strange, I am printing PDF files for quite some time, why now, all of a
sudden, this
The problem is Evince.
I am currently using Lucid Lynx with HP PSC 1200 and replacing Evince with
Acroread prints at usual speed much faster than Evince.
Evince is version 2.30.1-0ubuntu1
--
Process 'gs' begins taking 100% CPU and loading up vast amounts of RAM
twowheeler, your problem is not the foomatic-filters bug reported by the
original poster. The Ghostscript command line which you have posted in
your comment is of the pstopdf CUPS filter.
Please report a new bug (package cups) and tell also how you
configured your printer on the Windows client.
Don't know if this deserves its own bug or not, but the fix here does
not do the whole job for me. I have the new foomatic-filters
(4.0.3-0ubuntu2.1) installed but still get the behavior described above
when printing from windows. Set up is as follows -
A karmic desktop (P4, 2.4GHz, 1GB ram)
This bug was fixed in the package foomatic-filters - 4.0.3-0ubuntu2.1
---
foomatic-filters (4.0.3-0ubuntu2.1) karmic-proposed; urgency=low
* debian/patches/10_foomatic-rip-use-poppler-pdftops-with-cups.patch:
CUPS manipulates $PATH when calling filters and this makes
Tybion, thank you very much, we will include the fix in the automatic
updates for everyone soon.
** Tags added: verification-done
** Tags removed: verification-needed
--
Process 'gs' begins taking 100% CPU and loading up vast amounts of RAM
https://bugs.launchpad.net/bugs/463059
You received
The fixed foomatic-filters package fixes also bug 325232.
--
Process 'gs' begins taking 100% CPU and loading up vast amounts of RAM
https://bugs.launchpad.net/bugs/463059
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
Further testing ...
I attached Lab01.pdf above.
Steps followed ..
da...@thich:~$ cupsctl LogLevel=debug
da...@thich:~$ cupsctl LogDebugHistory=99
da...@thich:~$ sudo /etc/init.d/cups restart
* Restarting Common Unix Printing System: cupsd [ OK ]
da...@thich:~$
By testing with a similar driver (foo2zjs on the HP LaserJet 1020) I
could see how the problem got caused. The driver requires incoming PDF
being converted to PostScript and instead of using the desired call of
Poppler's pdftops it used an awkward Ghostscript call which is only
supported as a
Also some proprietary (manufacturer-supplied) drivers using foomatic-rip
can have this problem and the fix in foomatic-filters will solve it.
** Also affects: foomatic-filters (Ubuntu Karmic)
Importance: Undecided
Status: New
** Changed in: foomatic-filters (Ubuntu Karmic)
** Changed in: foomatic-filters (Ubuntu)
Status: In Progress = Fix Committed
--
Process 'gs' begins taking 100% CPU and loading up vast amounts of RAM on CUPS
restart
https://bugs.launchpad.net/bugs/463059
You received this bug notification because you are a member of Ubuntu
Bugs, which
This bug was fixed in the package foomatic-filters - 4.0.3-0ubuntu3
---
foomatic-filters (4.0.3-0ubuntu3) lucid; urgency=low
* debian/patches/10_foomatic-rip-use-poppler-pdftops-with-cups.patch:
CUPS manipulates $PATH when calling filters and this makes foomatic-rip
calling
Everyone who wants to test the fixed foomatic-filters in Lucid, please
test with the next daily live CD or update your Lucid as soon as the
fixed foomatic-filters package mentioned above hits the mirrors.
--
Process 'gs' begins taking 100% CPU and loading up vast amounts of RAM on CUPS
restart
Uploaded SRU for Karmic to -proposed, package is waiting for appreoval.
debdiff of the changes is attached.
** Patch added: debdiff with the foomatic-filters fix for Karmic
http://launchpadlibrarian.net/38663178/foomatic-filters_4.0.3-0ubuntu2_4.0.3-0ubuntu2.1.debdiff
** Changed in:
** Summary changed:
- Process 'gs' begins taking 100% CPU and loading up vast amounts of RAM on
CUPS restart
+ Process 'gs' begins taking 100% CPU and loading up vast amounts of RAM
--
Process 'gs' begins taking 100% CPU and loading up vast amounts of RAM
https://bugs.launchpad.net/bugs/463059
** Branch linked: lp:ubuntu/foomatic-filters
--
Process 'gs' begins taking 100% CPU and loading up vast amounts of RAM
https://bugs.launchpad.net/bugs/463059
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
Accepted foomatic-filters into karmic-proposed, the package will build
now and be available in a few hours. Please test and give feedback here.
See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you in advance!
** Tags added:
** Branch linked: lp:ubuntu/karmic-proposed/foomatic-filters
--
Process 'gs' begins taking 100% CPU and loading up vast amounts of RAM
https://bugs.launchpad.net/bugs/463059
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
Brilliant !
I applied the 'foomatic-filters' patch in Karmic-proposed.
Earlier test in Karmic - 2 mins, 45 secs from clicking 'Print' button to job
leaving queue (and CPU dropping)
Test with proposed patch - 1 minute from clicking 'Print' button to job leaving
queue
ie. 2.75 times faster
Thanks.
Also tested job described on Nov 15 (on different but similar powered PC) -
'One PDF has 6 pages - each page displays 6 ppt slides - ie. the PDF has been
created from a PPT that has 31-36 slides.
It took 12 minutes to print these 6 pages'
This job now takes 1 minute 20 secs - 9 times faster.
--
Everyone who has this problem please, I need the following information:
1. The file you tried to print. If you did not supply it yet, please
attach it to the bug report. If the problem occurs for you directly
after boot, please you have a file from the last session still in the
print queue. You
Till, thanks for that.
I have downloaded the Lucid Alpha nightly desktop ISO build from Jan 28th and
installed it.
(This has taken a while because this is unstable on my PC - the graphical
session keeps hanging)
I printed out the attached PDF to a Samsung CLP-300 (using monochrome,
Everyone who is using the pxlmono or pxlcolor driver of Ghostscript
(PCL-XL/PCL-6 drivers), please try a live CD of Lucid as to these
drivers several fixes were applied recently. Please tell whether the
fixed Ghostscript in Lucid solves the problem.
--
Process 'gs' begins taking 100% CPU and
Same issue with me, sending a pdf or ps to a printer on a headless
server.
* Problem also occurs if scp'ing files and printing locally (i.e. lpr
filename.pdf) - when leaving it (10 mins for a 3-page pdf on a 700MHz
processor, it eventually came out).
* Print queue is empty
Till Kamppeter: Is
I'm not even printing anything. I just turned the computer on, and had a
processor at 100%. Ubuntu 9.10, fresh install, 32-bit.
--
Process 'gs' begins taking 100% CPU and loading up vast amounts of RAM on CUPS
restart
https://bugs.launchpad.net/bugs/463059
You received this bug notification
Super_merlin -
Check your print queues - there is a good chance you have an old .PDF job in a
print queue from a previous session.
--
Process 'gs' begins taking 100% CPU and loading up vast amounts of RAM on CUPS
restart
https://bugs.launchpad.net/bugs/463059
You received this bug notification
same problem, my system:
Ubuntu 9.10 (KK) 64 bits, fresh installation. Printer HP Deskjet D2460
Eons to print a PDF
Thanks in advance
David
--
Process 'gs' begins taking 100% CPU and loading up vast amounts of RAM on CUPS
restart
https://bugs.launchpad.net/bugs/463059
You received this bug
Affects me as well, printing a PDF takes for ages, often more then 20
minutes, at times it seems hours (i print another way, say, give the pdf
to a friend, and sometime in the afternoon my document get's printed)
...
one core of the cpu get's totally hogged
printer is a network printer, lexmark
forgot to mention, ubuntu 9.10, fresh install
--
Process 'gs' begins taking 100% CPU and loading up vast amounts of RAM on CUPS
restart
https://bugs.launchpad.net/bugs/463059
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
In the last days the pxlmono driver in Ghostscript (the one which you
are using) got vastly improved. I have applied the appropriate patches
to the Ghostscript of Lucid. Please try a live CD of Lucid Alpha 1. Does
printing go faster with it?
** Changed in: ghostscript (Ubuntu)
Status: New
ubuntu 9.10 - 64 bit - Same problem when trying to print PDF on a
network Canon printer,
--
Process 'gs' begins taking 100% CPU and loading up vast amounts of RAM on CUPS
restart
https://bugs.launchpad.net/bugs/463059
You received this bug notification because you are a member of Ubuntu
Bugs,
I have Ubuntu 9.10 freshly installed, yet i have the problem of gs and
pdftotext taking up huge amount of CPU while downloading a bunch of pdf
files using Transmission torrent client.
--
Process 'gs' begins taking 100% CPU and loading up vast amounts of RAM on CUPS
restart
i have installed fresh 9.10 but the problem seem to me. CPU 2.10 ghz.
2048 mb ram.
--
Process 'gs' begins taking 100% CPU and loading up vast amounts of RAM on CUPS
restart
https://bugs.launchpad.net/bugs/463059
You received this bug notification because you are a member of Ubuntu
Bugs, which
Same problem my PC - single core Pentium 4 flat-lining until I kill the
gs process.
lp2376 19.0 42.6 479544 438124 ? R10:46 0:06 gs -q
-sstdout=%stderr -sDEVICE=pswrite -sOutputFile=- -dBATCH -dNOPAUSE
-dPARANOIDSAFER /var/spool/cups/tmp/foomatic-HHY4yi
Printer is CLP-300
I have found out that the gs process was flat-lining the CPU because there were
a number of PDF jobs in the print queue.
These PDFs are converted Powerpoint slides and seem to be printed very
inefficiently.
One PDF has 6 pages - each page displays 6 ppt slides - ie. the PDF has been
created
The problem seems to be connected to the upgrade of Ubuntu 9.04 to
Ubuntu 9.10. The process gs behaves on my computers completely normal if
Ubuntu 9.10 is fresh installed. So the problem does not anymore occur on
my computers.
--
Process 'gs' begins taking 100% CPU and loading up vast amounts of
This kind of problem also occurred on two of my PCs. Both are connected
to a Brother 2140 using a Raw-Socket.
The problem is the following: When I start to print a pdf (400kB) using
evince the CPU usage of gs goes to 100% on one core and when the usage
is reduced my memory will be blown up
42 matches
Mail list logo
