Hi,
I try to connect a HP Laserjet 6P with Centronics connection to an Acer Veriton M4640G on openSUSE 13.2 32 bit. The parallel port is provided by a
"
03:00.0 Communication controller: MosChip Semiconductor Technology Ltd. PCI 9815 Multi-I/O Controller (rev 01)
Subsystem: LSI Logic / Symbios Logic 2P0S (2 port parallel adaptor)
Flags: medium devsel, IRQ 18
I/O ports at d050 [size=8]
I/O ports at d040 [size=8]
I/O ports at d030 [size=8]
I/O ports at d020 [size=8]
I/O ports at d010 [size=8]
I/O ports at d000 [size=16]
Kernel modules: parport_pc
"
PCI card.
Yast correctly finds and initializes the printer, printing of some characters works, longer texts or graphics print garbage.
Exactly the same happens with a HP Laserjet 4MP.
Also the same happens with the same printers on a second computer with Leap 42.1 and two other different PCI-Express parport cards with different chips.
The Windows7 64 bit installation on this second computer worked with the same printers and both PCI-Express cards IIRC.
A third computer with the older openSUSE 13.1 32 bit worked OK with the “LSI Logic / Symbios Logic 2P0S” card, other cards not tested, sadly that computer died.
Is it possible that newer kernels have problems with the parallel port, timing/handshake maybe?
Sorry for the late reply, I did not see your answer, I got no notification.
It is no USB adapter but a PCI card.
lspci shows:
"
03:00.0 Communication controller: MosChip Semiconductor Technology Ltd. PCI 9815 Multi-I/O Controller (rev 01)
Subsystem: LSI Logic / Symbios Logic 2P0S (2 port parallel adaptor)
Flags: medium devsel, IRQ 18
I/O ports at d050 [size=8]
I/O ports at d040 [size=8]
I/O ports at d030 [size=8]
I/O ports at d020 [size=8]
I/O ports at d010 [size=8]
I/O ports at d000 [size=16]
Kernel driver in use: parport_pc
Kernel modules: parport_pc
"
The same problem exists with two different PCI-Express cards on another computer with Leap 42.1.
Under io, enter the IO address of the parallel port. Under irq, keep the default none for polling mode. Otherwise, provide the IRQ number for the parallel port. Polling mode is less problematic than interrupt mode as it helps to avoid interrupt conflicts. However, there are combinations of motherboards and printers that only function well if this is set to interrupt mode. Apart from that, interrupt mode ensures a continuous data flow to the printer even when the system is under very high load.
10.574929] parport_pc 00:03: reported by Plug and Play ACPI
10.575017] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
10.661410] parport1: PC-style at 0xd050 (0xd040), irq 18, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]
10.670099] parport1: Printer, Hewlett-Packard HP LaserJet 6P
10.670179] parport2: PC-style at 0xd030 (0xd020), irq 18, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]
Seeing that the working parport0 uses PCSPP i added “options parport_pc dma=none init_mode=PCSPP” to /etc/modprobe.d/99-local.conf, “dmesg|grep parport” lists
17.850080] parport_pc.c: Specified parameter parport_init_mode=PCSPP
17.892104] parport_pc 00:03: reported by Plug and Play ACPI
17.892207] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
17.979484] parport1: PC-style at 0xd050 (0xd040), irq 18, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]
17.987679] parport1: Printer, Hewlett-Packard HP LaserJet 6P
17.988569] parport2: PC-style at 0xd030 (0xd020), irq 18, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]
179.045408] lp0: using parport0 (interrupt-driven).
179.045682] lp1: using parport1 (interrupt-driven).
179.045937] lp2: using parport2 (interrupt-driven).
after reboot but there is still garbage printed. It seems there is a difference however, with init_mode=PCSPP start of printing is delayed some seconds.
After adding “options parport_pc io=0xd050 dma=none irq=none” to /etc/modprobe.d/99-local.conf
“dmesg|grep parport” lists
5.729568] parport0: PC-style at 0xd050 [PCSPP,TRISTATE,EPP]
5.739976] parport0: Printer, Hewlett-Packard HP LaserJet 6P
Printing to the printer queue which was the working motherboard parallel port before works. The motherboard port and the second port of the PCI card are not available anymore.
Do you actually need the other ports though? You can specify multiple addresses (to match the hardware) if need be. See the parport_pc kernel reference I linked to earlier.
17.250204] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
17.333784] parport1: PC-style at 0xd050, irq 18 [PCSPP,TRISTATE,EPP]
17.416860] parport2: PC-style at 0xd030, irq 10 [PCSPP,TRISTATE,EPP]
17.424652] parport2: Printer, Hewlett-Packard HP LaserJet 6P
105.840722] lp0: using parport0 (interrupt-driven).
105.840745] lp1: using parport1 (interrupt-driven).
105.840766] lp2: using parport2 (interrupt-driven).
so maybe the problem is not interrupts but “using FIFO [PCSPP,TRISTATE,COMPAT,ECP]”. Now the question is how to switch off FIFO/COMPAT so one doesn’t need to fumble with IRQ’s?
Yes, that is good to know that polling and IRQ both work here. I could be wrong, but explicitly setting using dma=none prevents FIFO buffer being used perhaps?
The kernel configuration parameter CONFIG_PARPORT_PC_FIFO= is relevant here. Most parport builds have it enabled, but RH had it disabled according to the bug report.
There is already “options parport_pc dma=none” in “/etc/modprobe.d/00-system.conf” (openSUSE default).
“options parport_pc io=0x378,0xd050,0xd030 dma=none,none,none” in “/etc/modprobe.d/99-local.conf” reports as:
6.502001] parport0: PC-style at 0x378, irq 1 [PCSPP,TRISTATE]
6.502006] genirq: Flags mismatch irq 1. 00000000 (parport0) vs. 00000080 (i8042)
6.502817] parport0: irq 1 in use, resorting to polled operation
6.585474] parport1: PC-style at 0xd050 [PCSPP,TRISTATE,EPP]
6.668475] parport2: PC-style at 0xd030 [PCSPP,TRISTATE,EPP]
163.712859] lp0: using parport0 (polling).
163.712883] lp1: using parport1 (polling).
163.712905] lp2: using parport2 (polling).
