Modes reported by parport_pc

 "ECP has disappeared"

In the 2.4.x kernel series a bug was fixed concerning the reported available modes in the parport_pc driver. Unfortunately, at least one commercial product (VMware, versions prior to 3.1) relied on the previous behaviour. This is fixed in the VMware Workstation 3.1 release.

The driver makes available, via /proc, a list of capabilities that the driver can offer. One of these possible modes is 'ECP', meaning 'hardware acceleration for ECP protocol is available and will be used' (text from Documentation/parport.txt).

During initialization, the driver probes for an extended control register (ECR) in order to find out more about the parallel port's resources. In general if an ECR is present then the parallel port hardware is able to offer acceleration for ECP protocol.

There is a kernel configuration option, marked as experimental since it doesn't reliably work yet, for actually using this hardware acceleration in normal operation.

The original behaviour was for the driver to list 'ECP' among the available modes if an ECR was detected during initialization, even if the experimental kernel configuration option for using hardware ECP acceleration was disabled. This was an oversight on my part (or whoever wrote that code; I forget). It is clearly wrong to list ECP among the available modes when the code for using it is not even compiled.

The experimental kernel code for using hardware ECP acceleration currently has a significant limitation (aside from not working reliably!): it requires an interrupt line in order to work. Work is in progress to rectify this.

Historically, ISA sound card IRQ lines have conflicted with on-board parallel port IRQ lines, and so by default the parport_pc driver does not use interrupts. This can be changed by using the 'irq=auto' option to the module at load time.

So, during the 2.4.x kernel series, the available-modes bug was fixed, and ECP is now only listed among the available modes if an ECR is detected, the experimental code for using it is enabled, and there is a usable IRQ line for the parallel port.

This bug wasn't fixed without reason either. In order to sensibly support ECP printers, the kernel printer driver needs to know whether hardware ECP acceleration is available. If not, there is no real point in using ECP for data transfers.

Meanwhile, VMware (a program for virtualising a machine) has code to use a parallel port. It doesn't use the kernel driver, for various (entirely valid) reasons, but instead goes straight to the hardware using inb and outb instructions. But it does use the kernel for finding out what host ports there are, and for requesting exclusive access to whichever port is needed. As it turns out, it also relies on the kernel to determine what modes are available, and this is the problem. Even though the parport_pc implementation has the limitation of requiring interrupts for using ECP hardware acceleration, VMware doesn't (or else it just uses the interrupts anyway: I don't know which).

The upshot is the VMware gets upset that it can't use hardware ECP with a particular port, even if both the hardware and the VMware application are capable of it, just because the kernel implementation (which won't even be used) is not going to use it.

A work-around of course is to convince the kernel to use hardware ECP, and then it will report ECP as available to VMware. To do this:

• Make sure to compile your kernel with CONFIG_EXPERIMENTAL and CONFIG_PARPORT_PC_FIFO enabled.
• Supply 'irq=auto' to the parport_pc driver when it loads, or if 'irq=auto' doesn't work then you need to supply the correct base address and IRQ as in 'io=0x378 irq=7'. (You can do this by putting 'options parport_pc irq=auto' or whatever in your /etc/modules.conf file.)

The above is obviously just a work-around. The proper way forward is for VMware to do its own capabilities detection of the port once it is found and exclusively claimed.

I have communicated this in an email to VMware's feedback address, as well as to a specific engineer there, but so far I haven't received any response from either mail so I have no idea if they ever even got it. Since I don't own a VMware license I am apparently not allowed to report bugs against it using their web site!

 Small print