hp1300 printer takes forever (3 min) to print each pdf page

[William Unruh]

I have an HP 1300 printer attached to a Mageia 3 machine
(cups-1.5.4-9.2.mga3) Since installing Mageia 3 the printing time for a
pdf file has become horrible-- the last one I timed at 3.5 min for a not
particularly complicated pdf page.
It looks like it is a problem with the transfer of the file to the
printer,

Here is the output of ps auxww |grep '^lp'

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
lp 32358 0.0 0.0 7364 1968 ? S 12:41 0:00 hp1300 465 root yvr-yyz-aug14-pat-boarding.pdf 1 finishings=3 number-up=1 job-uuid=urn:uuid:5c34025b-ccfe-3d19-7cef-4318571c835c job-originating-host-name=localhost time-at-creation=1407786064 time-at-processing=1407786064 /var/spool/cups/d00465-001
lp 32359 0.0 0.0 34976 1508 ? Sl 12:41 0:00 hp:/usb/hp_LaserJet_1300?serial=00CNBB086147 465 root yvr-yyz-aug14-pat-boarding.pdf 1 finishings=3 number-up=1 job-uuid=urn:uuid:5c34025b-ccfe-3d19-7cef-4318571c835c job-originating-host-name=localhost time-at-creation=1407786064 time-at-processing=1407786064
lp 32362 1.2 1.7 43436 36792 ? S 12:41 0:00 pdftops -level2 -origpagesizes /var/spool/cups/d00465-001 -
lp 32363 0.0 0.0 10668 2020 ? S 12:41 0:00 hp1300 465 root yvr-yyz-aug14-pat-boarding.pdf 1 finishings=3 number-up=1 job-uuid=urn:uuid:5c34025b-ccfe-3d19-7cef-4318571c835c job-originating-host-name=localhost time-at-creation=1407786064 time-at-processing=1407786064


Ie, pdftops seems to be taking a looooong time. and even after that the
printer takes a long time. (the above ps was after about 1.5min after I
had started the printing.

If I run pdftops directly on the file, it takes about 2 sec, and
produces at 2.8MB ps file.

If I feed that ps file directly to the printer that also appears to take
a long time.

[mike]

I had a similar problem with a laserjet 4mp in windows.
Turns out that the newer drivers cause the issue.
Changing the printer type to straight laserjet fixed the problem.

A clue is a clue, no matter what OS it comes from...unless you're
youknowwho and just wanna be bitchy.

[Michael Murphy]

I had the same problem with a laserjet 1200 when using the postscript
driver. Once I changed the configuration to use the CUPS+Gutenprint
driver, printing was almost instant.

--
Michael

[William Unruh]

I tried changing to Cups+Gutenprint. It certainly cleared out of the
cups printsystem/que very quickly. But it is still taking a long time to
print. Perhaps it is internal processing of the printer, rather than
anything the OS can do.
How do I determine that? As far as I can see there is no option or
command that says how much data was sent over the usb bus, so I cannot
see if the whole file was sent. I do not even know how to determine how
much memory is on the printer.

[mike]

I expect that if you plug it into a windows system, you'll probably get
a GUI that tells you everything you want to know. Also will tell you
if the printer is at fault or it's the linux driver.

IN my case, I futzed with the printer for a long time. Monitored the
parallel port and determined that the data rate was fast as could be
expected. I surmise that the difference was that the older driver
expected the computer to do the postscript conversion while the newer
one used the printer's post script functions...but as soon as I got it
working, I lost interest in determining the root cause.

[Robert Newson]

On 11/08/14 22:39, William Unruh wrote:
> I have an HP 1300 printer attached to a Mageia 3 machine
> (cups-1.5.4-9.2.mga3) Since installing Mageia 3 the printing time for a
> pdf file has become horrible-- the last one I timed at 3.5 min for a not
> particularly complicated pdf page.
> It looks like it is a problem with the transfer of the file to the
> printer,

What was your previous OS?

It could be an driver compile option that the new kernel has on/off by
default which a previous kernel didn't have/had the opposite state - I
had a similar problem with printing [anything]:

Could be the "physical" output [driver] stage of the process (I think
you're using a USB printer, but my experience may be appropriate):
running a DMP on the parallel port of a Mageia 2 system it used to print
V.....E......R......Y.... slowly, printing a line at a time with a 3
second delay or so between each line - a page printer would appear to go
to sleep for ages before finally outputting the page - whereas before I
installed Mageia 2 I had no problems with output. I finally found out
it was the parport driver - being compiled with an experimental DMA (I
think) option; by re-compiling the module without the option, the
printer acted normally and printed at proper speeds.

I did report a "bug" about this asking that/if the supplied kernel could
be compiled without the experimental option but never heard any more
other than the "bug" was being closed due to end-of-life of mageia 2.

[Michael Murphy]

I don't have your printer, but there should be some combination of
button presses that result in a printout of the printer's settings and
memory. You might google for the user guide. As part of my solution to
printing problems on the HP 1200, in addition to changing the driver, I
boosted the memory to max.

[Rikishi42]

With a printer like that, go for a Pcl driver, allways.
Same for the older Laserjet (up to 4050)

Of course, you might have other problems, but give it a try.


--
When in doubt, use brute force.
-- Ken Thompson

[Thad Floryan]

On 8/12/2014 1:41 PM, Rikishi42 wrote:
> On 2014-08-11, William Unruh <un...@invalid.ca> wrote:
>> I have an HP 1300 printer attached to a Mageia 3 machine

>> (cups-1.5.4-9.2.mga3) [...]
>> [...]

>
> With a printer like that, go for a Pcl driver, allways.

That may be true for the 1300. Though I have PCL5 and PCL6
"drivers" for all my printers, I use PostScript exclusively.

> Same for the older Laserjet (up to 4050)

But NOT INCLUDING the 4050 -- the 4050 has a 100% perfect
PostScript implementation and that's how I've operated mine
since the early 1990s on SunOS and Solaris and Linux, and it
still works fine today though it is slower (even with the
maximum RAM installed) than others I have on my LAN such as a
LaserJet P2015dn and a LaserJet PRO 400 M401dne. The P2015dn
has an occasional glitch with PostScript (perhaps once a year)
and I haven't found any PostScript flaws in the M401dne yet.

Though this picture is about 4-5 years old, you can see my
4050n in the background and the P2015dn to the left of the
monitor -- I need to do a new picture including the M401dne
and all the new desktop systems since then:

http://thadlabs.com/PIX/Thad_desk.jpg 195kB

The trick is to get the proper drivers which may or may not be
found at HP's site but are very likely in the HPLIP tarball.

For example, I only needed to extract and setup in CUPS the
hp-laserjet_400_m401dne-ps.ppd file for /etc/cups/ppd/ and
the hpps file for /usr/lib/cups/filter last month and the
M401dne works perfectly on everything from my Red Hat 9 box
(2003) to CentOS 6.

grep'ing the tvf listing from the HPLIP tarball for '1300'
finds these 14 entries:

3461 Jun 2 23:33 hp-deskjet_d1300_series.ppd.gz
3199 Jun 2 23:33 hp-laserjet_1300-pcl3.ppd.gz
3197 Jun 2 23:33 hp-laserjet_1300n-pcl3.ppd.gz
3200 Jun 2 23:33 hp-laserjet_1300xi-pcl3.ppd.gz
3555 Jun 2 23:33 hp-psc_1300_series.ppd.gz
3613 Jun 2 23:33 hp-deskjet_d1300_series-hpijs.ppd.gz
3605 Jun 2 23:33 hp-laserjet_1300-hpijs-pcl3.ppd.gz
3602 Jun 2 23:33 hp-laserjet_1300n-hpijs-pcl3.ppd.gz
3604 Jun 2 23:33 hp-laserjet_1300xi-hpijs-pcl3.ppd.gz
3755 Jun 2 23:33 hp-psc_1300_series-hpijs.ppd.gz
13500 Jun 2 23:33 hp-designjet_t1300_postscript-ps.ppd.gz
20308 Jun 2 23:33 hp-laserjet_1300-ps.ppd.gz
20309 Jun 2 23:33 hp-laserjet_1300n-ps.ppd.gz
20310 Jun 2 23:33 hp-laserjet_1300xi-ps.ppd.gz

PCL3 is ancient, released in 1984 (30 years ago) with the first
LaserJet, per:

http://en.wikipedia.org/wiki/Printer_Command_Language

HPLIP is here:

http://sourceforge.net/p/hplip/news/2013/02/hplip-3132-public-release/

where I found the following in the release notes:

HPLIP 3.13.2 - This release has the following changes:
Added Support for the Following New Printers:

- HP Officejet Pro X451dw Printer
- HP Officejet Pro X451dn Printer
- HP Officejet Pro X476dn MFP
- HP Officejet Pro X476dw MFP
- HP Officejet Pro X551dn Printer
- HP Officejet Pro X551dw Printer
- HP Officejet Pro X576dn MFP
- HP Officejet Pro X576dw MFP
- HP Officejet 7110 Wide Format ePrinter
- HP LaserJet 400 M401dne

Thad

[Doug Laidlaw]

On Tue, 12 Aug 2014 08:22:55 +0100
Robert Newson <noth...@bullet3.fsnet.oc.ku> wrote:

> On 11/08/14 22:39, William Unruh wrote:
> > I have an HP 1300 printer attached to a Mageia 3 machine
> > (cups-1.5.4-9.2.mga3) Since installing Mageia 3 the printing time
> > for a pdf file has become horrible-- the last one I timed at 3.5
> > min for a not particularly complicated pdf page.
> > It looks like it is a problem with the transfer of the file to the
> > printer,
> What was your previous OS?
>
>

> I did report a "bug" about this asking that/if the supplied kernel
> could be compiled without the experimental option but never heard any
> more other than the "bug" was being closed due to end-of-life of
> mageia 2.

You are both living in the dinosaur age. A bug report wouldn't be
looked at.

I have CUPS-1.7 on Mga4. I agree that pdf2ps seems to send my CPU to 100%.
I have a Brother MFC. It prints out a Web page slowly and takes a long time
to eject the last page. Then it writes the universal message "Please Wait"
while it polishes its nails. Printing is a lot faster generally if something
holds up the printer, but the data keeps coming into it.

[William Unruh]

Yes. I discovered it has 64MB of memory, which should sure be enough for
a 2MB ps file. So I have no idea what is taking forever.


>

[Rikishi42]

On 2014-08-13, Thad Floryan <th...@thadlabs.com> wrote:
> On 8/12/2014 1:41 PM, Rikishi42 wrote:
>> On 2014-08-11, William Unruh <un...@invalid.ca> wrote:
>>> I have an HP 1300 printer attached to a Mageia 3 machine
>>> (cups-1.5.4-9.2.mga3) [...]
>>> [...]
>>
>> With a printer like that, go for a Pcl driver, allways.
>
> That may be true for the 1300. Though I have PCL5 and PCL6
> "drivers" for all my printers, I use PostScript exclusively.
>
>> Same for the older Laserjet (up to 4050)
>
> But NOT INCLUDING the 4050 -- the 4050 has a 100% perfect
> PostScript implementation and that's how I've operated mine
> since the early 1990s on SunOS and Solaris and Linux, and it
> still works fine today though it is slower (even with the
> maximum RAM installed) than others I have on my LAN such as a
> LaserJet P2015dn and a LaserJet PRO 400 M401dne. The P2015dn
> has an occasional glitch with PostScript (perhaps once a year)
> and I haven't found any PostScript flaws in the M401dne yet.

I wasn't referring to glitches or poor support, they've allways worked well
in my case. But it's a little about speed and mainly about RAM. If a
printer only has 4 MB, it's just not fit for PostScript. Some pages will
get trough, but not all. At work, we've junked a load of 4050 (and even
4100) Laserjets. They were still working fine with Pcl, but for some reason
we had to switch to PS and some print jobs are just to heavy.


Well, better for me. I'll pick a good working 4050 or 4100 to replace the
4000 I've been using for years now, which is showing pale spots on some
parts of the page.

> PCL3 is ancient, released in 1984 (30 years ago) with the first
> LaserJet, per:

I know, I was there. Laserjet and Laserjet II.
Crap, I'm getting old... :-)

[Michael Murphy]

On Wed, 13 Aug 2014 17:05:45 +0000 (UTC)

Yeah, 64MB is what I have, too. Yours is a higher end version of the
printer I have so the performance should be comparable or better. You
might play with the pxlmono driver to see if that changes anything for
the better. You might also check at
<http://www.openprinting.org/printer/HP/HP-LaserJet_1300> to see if
information gleaned there helps you to arrive at a solution. Good
luck.



--
Michael

[Thad Floryan]

On 8/11/2014 2:39 PM, William Unruh wrote:

> I have an HP 1300 printer attached to a Mageia 3 machine
> (cups-1.5.4-9.2.mga3) Since installing Mageia 3 the printing time for a
> pdf file has become horrible-- the last one I timed at 3.5 min for a not
> particularly complicated pdf page.
> It looks like it is a problem with the transfer of the file to the
> printer,

> [...]

If you're printing a PDF to a printer that old, "something" has to
convert it to PostScript and that "something" might be the holdup.

How large is the PDF? If you could put it on a site for download
I could run some tests since my LaserJet PRO 400 M401dne can print
PDFs directly that are ftp'd to it and I could also test the PDF
to PostScript conversion using various PDF readers. I could also
test that PDF with my P2015dn and 4050n and also from various Linux
and Solaris systems.

The newest PDF reader/editor/signer/writer I've been using on my
CentOS 6 system is this one:

https://www.cabaret-solutions.com/

Despite that page being in German (which is relatively easy for me
to read), its scripting tutorial is in English (99 pages, 2MB):

https://www.cabaret-solutions.com/system/files/CABAReT%20Stage%20Scripting%20Tutorial.pdf

Thad

[Thad Floryan]

On 8/13/2014 9:22 PM, Thad Floryan wrote:
> On 8/11/2014 2:39 PM, William Unruh wrote:
>> I have an HP 1300 printer attached to a Mageia 3 machine
>> (cups-1.5.4-9.2.mga3) Since installing Mageia 3 the printing time for a
>> pdf file has become horrible-- the last one I timed at 3.5 min for a not
>> particularly complicated pdf page.
>> It looks like it is a problem with the transfer of the file to the
>> printer,
>> [...]

> [...]

Hmmm, "8/11/2014" is a Monday per:

$ cal
August 2014
Su Mo Tu We Th Fr Sa
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

so you didn't experience the "Tuesday" bug:

https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161/comments/28

:-)

Thad

[Doug Laidlaw]

On Wed, 13 Aug 2014 11:17:13 +1000
Doug Laidlaw <laid...@hotkey.net.au> wrote:

> I have CUPS-1.7 on Mga4. I agree that pdf2ps seems to send my CPU to
> 100%. I have a Brother MFC. It prints out a Web page slowly and
> takes a long time to eject the last page. Then it writes the
> universal message "Please Wait" while it polishes its nails.
> Printing is a lot faster generally if something holds up the printer,
> but the data keeps coming into it.

I just noticed today that my printer was just as slow on Win7, with
the latest driver installed. Maybe Cups isn't the culprit. The
bottleneck seems to be in the USB department.

[Doug Laidlaw]

Perhaps I should re-phrase that. I just switched the printer to a
wireless network connection, and printing a test page was just as
slow. Yet printing by wireless from my wife's laptops (the old
boat-anchor with WinXP and the brand new Win8.1) has always been fast
(subject to network delays.)

My MFC is intended to be an office workhorse, basically a fax machine
with printing, scanning and photo printing thrown in. It isn't
designed to be primarily a printer. It is probably of no help to the
OP.

[William Unruh]

Not sure. I do not do Windows. But this slowdown came with the
intallation of Mageia 3 rather than Mandrake 2010 that the system was
running before. Ie, something has happened in the newer versions of it
seems all operating systems. This does not seem a hardware since that
has not changed. I do not know if everyone has changed their usb
drivers? or if the postscript sent to the printers has changed so that
the printer is much more confused and takes far longer to interpret the
postscript.

Note that as far as I can see, when I changed from the postscript driver
to cups+gutenprint, the file is cleared out from the printing queue far
far faster ( a second or two) but it still takes a long time to print. I
assume that the material has gone over the usb to the printer, but I
have no idea how to test that. If so, it means that it is somehow inthe
internal interpretation of the postscript in the printer that is so so
slow.

[Robert Newson]

On 19/08/14 19:55, William Unruh wrote:
> On 2014-08-19, Doug Laidlaw <laid...@hotkey.net.au> wrote:
>> On Wed, 20 Aug 2014 00:04:15 +1000
>> Doug Laidlaw <laid...@hotkey.net.au> wrote:
>>

...

> Not sure. I do not do Windows. But this slowdown came with the
> intallation of Mageia 3 rather than Mandrake 2010 that the system was
> running before. Ie, something has happened in the newer versions of it
> seems all operating systems. This does not seem a hardware since that
> has not changed. I do not know if everyone has changed their usb
> drivers? or if the postscript sent to the printers has changed so that
> the printer is much more confused and takes far longer to interpret the
> postscript.

It was when changing Mandrake to Mageia that had the same problem; for
me it was with parport (the parallel port driver) being compiled with an
experimental option which caused it to run v...e....r...y slowly.
Recompiled without that option set and it flew along (just like before).
This was actually a well known issue with the driver.

> Note that as far as I can see, when I changed from the postscript driver
> to cups+gutenprint, the file is cleared out from the printing queue far
> far faster ( a second or two) but it still takes a long time to print. I
> assume that the material has gone over the usb to the printer, but I
> have no idea how to test that. If so, it means that it is somehow inthe
> internal interpretation of the postscript in the printer that is so so
> slow.

My suspicion rests with the usb driver struggling for some reason to
send the data to the printer, ie the material has not gone over to the
printer very fast but is taking a leisurely stroll to get to the
printer. Once the printer gets the data it is probably doing a sterling
job of rendering it. Remember most printers are page printers and
require the full page to be sent to it before any output will occur.

This may sound silly but to test the usb [printer] driver:

1) Have you tried sending a single blank page to the printer to print.
How long did that take?

2) (Do (1) if not already done.) Now try printing a blank page except
for one line containing, say, 11 characters (eg: Hello world) and time
how long it takes

3) Now try printing a blank page except for one line containing 59
characters (eg Hello world Hello world Hello world Hello world Hello
world) and timing how long that takes to print.

The timings need to be done to seconds.

With a page printer, there is quite a lot of data that gets sent to just
output a blank page - the first test provides a base time; the second
and third tests above add to this. It may be necessary to repeat each
test two or three times as there are quite a few processes involved in
printing and allows for an average time to be calculated and obviously
exceptional times to be ignored (eg the first try may be loading drivers
which subsequent times won't need to do and so the first try could be
longer).

It is important that (2) and (3) are such that the characters are on a
single line as it should generate output to the printer which differs
only in 48 characters - it should print in the same time, but if there
is a significant delay in sending the longer line, then the problem is
definitely the usb driver.

[William Unruh]

Certainly that is one possible issue. It is interesting that if I send
over a pdf or ps file to be printed it takes forever, but if I send a
text file it happens very fast. Of course it could be that each page of
the text file, translated to ps is very small, so the transfer seems
fast. This was why I wanted to have some way of monitoring the usb port
to see how much data was transfered as a function of time.

>
> This may sound silly but to test the usb [printer] driver:
>
> 1) Have you tried sending a single blank page to the printer to print.
> How long did that take?

As I said, a page of text (say this email) prints fast.

It is when I send some pdf page ( which expands out to a few MB of ps)
that things get very slow.

[Robert Newson]

On 20/08/14 17:40, William Unruh wrote:
> On 2014-08-20, Robert Newson <noth...@bullet3.fsnet.oc.ku> wrote:
>> On 19/08/14 19:55, William Unruh wrote:
>>> On 2014-08-19, Doug Laidlaw <laid...@hotkey.net.au> wrote:
>>>> On Wed, 20 Aug 2014 00:04:15 +1000
>>>> Doug Laidlaw <laid...@hotkey.net.au> wrote:
>>>>
>> ...

...

>> My suspicion rests with the usb driver struggling for some reason to
>> send the data to the printer, ie the material has not gone over to the
>> printer very fast but is taking a leisurely stroll to get to the
>> printer. Once the printer gets the data it is probably doing a sterling
>> job of rendering it. Remember most printers are page printers and
>> require the full page to be sent to it before any output will occur.
>
> Certainly that is one possible issue. It is interesting that if I send
> over a pdf or ps file to be printed it takes forever, but if I send a
> text file it happens very fast. Of course it could be that each page of
> the text file, translated to ps is very small, so the transfer seems
> fast. This was why I wanted to have some way of monitoring the usb port
> to see how much data was transfered as a function of time.

A fast text file would seem to rule out the usb driver as the bottleneck
(my parallel dot matrix printer was slow with plain ASCII sent straight
to it which is why I knew it was the parport driver)

I've been told that hp printers use their own protocol for talking to
the computer which means the backend of the CUPS system which sends the
file may be the bottleneck.

[William Unruh]

On 2014-08-20, Robert Newson <noth...@bullet3.fsnet.oc.ku> wrote:
> On 20/08/14 17:40, William Unruh wrote:
>> On 2014-08-20, Robert Newson <noth...@bullet3.fsnet.oc.ku> wrote:
>>> On 19/08/14 19:55, William Unruh wrote:
>>>> On 2014-08-19, Doug Laidlaw <laid...@hotkey.net.au> wrote:
>>>>> On Wed, 20 Aug 2014 00:04:15 +1000
>>>>> Doug Laidlaw <laid...@hotkey.net.au> wrote:
>>>>>
>>> ...
> ...
>>> My suspicion rests with the usb driver struggling for some reason to
>>> send the data to the printer, ie the material has not gone over to the
>>> printer very fast but is taking a leisurely stroll to get to the
>>> printer. Once the printer gets the data it is probably doing a sterling
>>> job of rendering it. Remember most printers are page printers and
>>> require the full page to be sent to it before any output will occur.
>>
>> Certainly that is one possible issue. It is interesting that if I send
>> over a pdf or ps file to be printed it takes forever, but if I send a
>> text file it happens very fast. Of course it could be that each page of
>> the text file, translated to ps is very small, so the transfer seems
>> fast. This was why I wanted to have some way of monitoring the usb port
>> to see how much data was transfered as a function of time.
> A fast text file would seem to rule out the usb driver as the bottleneck
> (my parallel dot matrix printer was slow with plain ASCII sent straight
> to it which is why I knew it was the parport driver)

It could still be the usb, since the problematic files have ps files of
a few MB which a text file produces a ps file much much smaller.

Again, is there anyway to watch what is going down the usb line, like it
is for networks (eg see how many bytes have gone down the usb line.)

[Jasen Betts]

On 2014-08-20, William Unruh <un...@invalid.ca> wrote:
> On 2014-08-20, Robert Newson <noth...@bullet3.fsnet.oc.ku> wrote:
>> On 19/08/14 19:55, William Unruh wrote:

> Certainly that is one possible issue. It is interesting that if I send
> over a pdf or ps file to be printed it takes forever, but if I send a
> text file it happens very fast. Of course it could be that each page of
> the text file, translated to ps is very small, so the transfer seems
> fast. This was why I wanted to have some way of monitoring the usb port
> to see how much data was transfered as a function of time.

you can probably measure that electrically,

> As I said, a page of text (say this email) prints fast.
>
> It is when I send some pdf page ( which expands out to a few MB of ps)
> that things get very slow.

a large amount of PS is likely both slow to transfer and slow to process
in the printer.

look into how the CUPS printer driver works, there's probably a
point where you can monitor the traffic

--
umop apisdn


--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[William Unruh]

On 2014-08-23, Jasen Betts <ja...@xnet.co.nz> wrote:
> On 2014-08-20, William Unruh <un...@invalid.ca> wrote:
>> On 2014-08-20, Robert Newson <noth...@bullet3.fsnet.oc.ku> wrote:
>>> On 19/08/14 19:55, William Unruh wrote:
>
>> Certainly that is one possible issue. It is interesting that if I send
>> over a pdf or ps file to be printed it takes forever, but if I send a
>> text file it happens very fast. Of course it could be that each page of
>> the text file, translated to ps is very small, so the transfer seems
>> fast. This was why I wanted to have some way of monitoring the usb port
>> to see how much data was transfered as a function of time.
>
> you can probably measure that electrically,

Wonderful. Since linux transfers bytes over the usb bus, linux "knows"
how much is transfered. But is there anything that keeps track of it (eg
network transfers ARE kept track of and you can query the system as to
how manybytes were tranfered over the net).

>
>> As I said, a page of text (say this email) prints fast.
>>
>> It is when I send some pdf page ( which expands out to a few MB of ps)
>> that things get very slow.
>
> a large amount of PS is likely both slow to transfer and slow to process
> in the printer.

But that should not have changed between Mandriva and Mageia.

[Bit Twister]

On Sat, 23 Aug 2014 12:33:05 +0000 (UTC), William Unruh wrote:

> Wonderful. Since linux transfers bytes over the usb bus,

I wonder if you have a module loading order problem.
To check, grep your message log for uhci_hcd. If using journald, the
command would be journalctl | grep uhci_hcd
You should see a Warning string if you have that problem.

[William Unruh]

Hmm. I do have


Jul 24 20:11:11 wormhole kernel: Warning! ehci_hcd should always be
loaded before uhci_hcd and ohci_hcd, not after

which seemes to have occured at the last boot. Is that what you mean?
How do you alter the ordering of those things.

And why would this warning occur with
/etc/modprobe.conf having


install usb-interface /sbin/modprobe ehci_hcd; /sbin/modprobe ehci_pci;
/sbin/modprobe uhci_hcd; /bin/true

[Bit Twister]

On Sat, 23 Aug 2014 20:38:24 +0000 (UTC), William Unruh wrote:
> On 2014-08-23, Bit Twister <BitTw...@mouse-potato.com> wrote:
>> On Sat, 23 Aug 2014 12:33:05 +0000 (UTC), William Unruh wrote:
>>
>>> Wonderful. Since linux transfers bytes over the usb bus,
>>
>> I wonder if you have a module loading order problem.
>> To check, grep your message log for uhci_hcd. If using journald, the
>> command would be journalctl | grep uhci_hcd
>> You should see a Warning string if you have that problem.
>>
>
> Hmm. I do have
>
>
> Jul 24 20:11:11 wormhole kernel: Warning! ehci_hcd should always be
> loaded before uhci_hcd and ohci_hcd, not after
>
> which seemes to have occured at the last boot. Is that what you mean?

Yup.

> How do you alter the ordering of those things.

That depends on distribution and release of distribution.

> And why would this warning occur with
> /etc/modprobe.conf having
>
> install usb-interface /sbin/modprobe ehci_hcd; /sbin/modprobe ehci_pci;
> /sbin/modprobe uhci_hcd; /bin/true

Again that depends on distribution and release of distribution.

Snippet from mine has
install usb-interface /sbin/modprobe ohci_hcd; \
/sbin/modprobe ehci_hcd; /sbin/modprobe ehci_pci; \
/sbin/modprobe ohci_pci; /bin/true

The '\' and cr added by me for readability and is probably bss aackwards.

I should fix that and back out my dracut.conf patch to see if that
will fix the problem.

My solution to get rid of the warning was to modify dracut
configuration and run dracut -f

$ cat /etc/dracut.conf.d/my__dracut.conf
# created by /local/bin/dracut_conf_changes Fri 22 Aug 10:10 2014
# always include ehci_hcd driver first (mga#3667)
add_drivers+=" ehci_hcd ahci "

add_device+="LABEL=swap"

#************ end /etc/dracut.conf.d/my__dracut.conf **************

[William Unruh]

On 2014-08-23, Bit Twister <BitTw...@mouse-potato.com> wrote:
> On Sat, 23 Aug 2014 20:38:24 +0000 (UTC), William Unruh wrote:
>> On 2014-08-23, Bit Twister <BitTw...@mouse-potato.com> wrote:
>>> On Sat, 23 Aug 2014 12:33:05 +0000 (UTC), William Unruh wrote:
>>>
>>>> Wonderful. Since linux transfers bytes over the usb bus,
>>>
>>> I wonder if you have a module loading order problem.
>>> To check, grep your message log for uhci_hcd. If using journald, the
>>> command would be journalctl | grep uhci_hcd
>>> You should see a Warning string if you have that problem.
>>>
>>
>> Hmm. I do have
>>
>>
>> Jul 24 20:11:11 wormhole kernel: Warning! ehci_hcd should always be
>> loaded before uhci_hcd and ohci_hcd, not after
>>
>> which seemes to have occured at the last boot. Is that what you mean?
>
> Yup.
>
>> How do you alter the ordering of those things.
>
> That depends on distribution and release of distribution.

Mageia 3

>
>
>> And why would this warning occur with
>> /etc/modprobe.conf having
>>
>> install usb-interface /sbin/modprobe ehci_hcd; /sbin/modprobe ehci_pci;
>> /sbin/modprobe uhci_hcd; /bin/true
>
> Again that depends on distribution and release of distribution.

O
Mageia 3

[Bit Twister]

On Sun, 24 Aug 2014 03:13:40 +0000 (UTC), William Unruh wrote:
> On 2014-08-23, Bit Twister <BitTw...@mouse-potato.com> wrote:

>>> How do you alter the ordering of those things.
>>
>> That depends on distribution and release of distribution.
>
> Mageia 3

Ok, you might try creating /etc/dracut.conf.d/my__dracut.conf
with the following:

add_drivers+=" ehci_hcd ahci "
#*************** end /etc/dracut.conf.d/my__dracut.conf **********

running "dracut -f" , reboot, and check for the warning.

[William Unruh]

Unfortunately it will be a while before I am able to do that. But thanks

[William Unruh]

On 2014-08-24, Bit Twister <BitTw...@mouse-potato.com> wrote:

Actually dracut.conf.d/50-mangeia.conf alredy has the lines
# always include ahci driver (mga#4364)
add_drivers+=" ahci "

Does that cause problems with the line you suggested?

[Bit Twister]

On Sun, 24 Aug 2014 13:50:55 +0000 (UTC), William Unruh wrote:

> Actually dracut.conf.d/50-mangeia.conf alredy has the lines
> # always include ahci driver (mga#4364)
> add_drivers+=" ahci "
>
> Does that cause problems with the line you suggested?

Heheheh, no. New methodology about configuration files is the
applications look in their .d/ directory to get whatever needed.

The order of the files dictates what is set. That way the
user/distribution can custom make changes without having them
overwritten by the default settings released by the app designer.

Do a
ls -1 /etc/dracut.conf.d/
and notice my__dracut.conf will override whatever is in the files
above my__dracut.conf.