My old HP 520 on parallel port (lp0) prints fine with driver CUPS+Gutenprint v5.2.9 under Slack 14.

I install the printer under Mint 17.1 Cinnamon with CUPS, which uses
CUPS+Gutenprint v5.2.10. Test page spews out a few lines of crap, then printer locks up in "Busy" state. Same for the other drivers CUPS offers for the 520. Same when a "Generic" printer is selected. Nothing to see in CUPS logs

HPLIP doesn't even see the printer on lp0, although it works fine with ENVY 4500 on USB.

Ideas anyone? Could a mere change from Gutenprint v5.2.9 to 5.2.10 really be to blame?

Check that Mint still provides parallel printing support

For reference, I get
http://hplipopensource.com/node/217

Great idea. Here's what I get:
Problem may be that my userid is not a member of the 'lp' group, but something called 'lpadmin.' An 'lp' group does exist, so I'm adding myself to that group. Pressed for time now, but I'll check and post again. Thanks again for the hint.

Added group 'lp' to my user id. Still no joy. Tried 'enscript' on an ASCII file instead of 'lpr'; no Busy lockup but no printing either. Even 'cat [an ASCII file] > /dev/lp0 fails. This is making me crazy.

Can you show us how the CUPS printer URI is defined in /etc/cups/printers.conf? (It might be worth comparing that with your Slack configuration as well)

Is the printer detected if the CUPS parallel backend is executed manually?
Some good diagnostic advice here:

https://wiki.ubuntu.com/DebuggingPri...l_port_printer

Wow, that was a revelation. /etc/cups/printers.conf shows ! Don't have any idea how that got there.

Also, that URI you recommended looks very informative. Thank you. Now I'll re-re-configure my HP 520 in CUPS again, and also look into the AppArmor thing, which I am ignorant of.

Deleted all the print queues; readded the 520. Now printers.conf shows
More info. I don't know if this is a good response or not.
Net result: no printing, printer locks in Busy state.

I think I need to run the diagnostics on my Slack install, to see what responses a working install gives.

Thanks again for your help.

The printer should be detected (enumerated) by running the backend manually. Since that is not happening, you might want to check BIOS settings for the parallel port perhaps.

Another thing that I observed from examination of your printers.conf configuration is that you are using the foomatic driver. Maybe try the hpcups (HPLIP) or the gutenprint driver which are available for this model.

To get more info about your parallel port, you could run
and note whether the parport_pc driver is bound to it.

My Slack distro (printing OK) gives the same response as Mint:
Alas, the response to is empty on Slack and Mint as well.

I've determined that the problem lies with /dev/lp0. I have a file written in HP's PCL. Under Slack I can run
and print it straight out. No CUPS involved. Under Mint the same command and file feeds a sheet, then prints nothing and the printer shows "Busy" until reset.

Permissions are the same for /dev/lp0 under Mint as for Slack. Access Control shows nothing special. I'm totally stumped.

Okay, but I'd still like to know about the parallel port itself, so still worth comparing the hardware and driver associated. The Slack and Mint distros are installed in different machines right?

Sometimes it is necessary to load the parport_pc driver with options (to match the parameters reported by lspci)

eg in /etc/modprobe.d/parport.conf
* The required parameters are specific to the parallel port device

That's a good test of the parallel port hardware and printer cable. Assuming it's the same cable, that really only leaves the hardware (and possibly the device driver).

Did you get a chance to check the BIOS settings for the parallel port? (eg ECP mode)

First off, sincere thanks for sticking with me on this.

The 2 distros are on the same machine.

The BIOS reports that the parallel port is ECP. FYI, other choices with this BIOS are EPP, Bi-Directional, Output Only.

The answer may lie in the kernel compile config. I got this hint from a Linux Documentation doc on the parport module, BTW. The Mint kernel has CONFIG_PARPORT_PC_FIFO=y, whereas the Slack kernel has CONFIG_PARPORT_PC_FIFO=n. No doubt that's why dmesg reports different results for parport0 under Mint and Slack:

When time permits I'm going to follow the suggestion in the Linux Doc and add this to the parport_pc module params:
We'll see.

I'm glad to be of whatever help I can be. I'm curious about the issue (and hopeful resolution)... and it may help others too.

Yes, I think that is the crux of the issue.

Yes, it will be interesting to see if it makes a difference. Make sure the base address and irq parameters do match what is reported in 'lspci' though. You dmesg output already convinces me that the module is correctly configured. It is that FIFO kernel configuration that is the likely issue here IMHO.

Now that I've looked, I see numerous other threads and bug reports describing similar situations

https://bugs.launchpad.net/ubuntu/+s...ux/+bug/339752
https://bugzilla.kernel.org/show_bug.cgi?id=56721
https://bugs.archlinux.org/task/35850
...and lot's more if one cares to search

The ArchLinux user found that changing the parallel port BIOS config to 'Bi-Directional' was sufficient to get things working.

You mentioned that your BIOS config was set to ECP. That usually requires a DMA channel to be selected ie I'm not sure that dma=none will work.

For reference, I have

Problem solved! You alerted me to the ECP use of DMA...my BIOS gave no clue that a DMA channel was involved. So I took the easy way out and just set the parallel port to "Bi-Directional," per the reference you found. Now both Slack and Mint show:

Mint prints via CUPS or via 'cat [a PCL file] > /dev/lp0'

I've had that HP 520 for a long long time, and I hated to see it become a paperweight.

Again, thanks for your continuing interest and your help. It renews my faith in the Linux community.