[tulip] Re: Failed to map PCI address ? (Problem solved!)

[Donald Becker]

On Sat, 8 Jul 2000, Fred Wilson Horch wrote:
> On Sat, Jul 08, 2000, Philipp Schulte wrote:
> >> Does anyone know what 'Failed to map PCI address' means?
> >
> >I don't know what it means but I know how to avoid it :)
> >I had this problemsome time ago and Mr. Becker told me to do this:
> >Compile tulip.c v92 with the *additional* flag '-DUSE_IO_OPS'
> 
> Wow, that's impressive -- worked like a charm!
> 
> I recompiled tulip.c with this command:
> 
> gcc -DMODULE -DUSE_IO_OPS -Wall -Wstrict-prototypes -O6 -c tulip.c
...
> Now, what did I just do?  ;-)

The Tulip registers may be accessed using either I/O space operations, or
using memory space operations.  This compile option switches to using I/O
space operations, which was the original mode the driver used.

The BIOS sets both the I/O base address and the memory base address.  On the
PC architecture I/O space access is traditionally used for peripherals, and
is sometime the only method tested.  The problem you are experiencing is
that the Tulip's memory space is set to a high address, and the 2.0.* kernel
is apparently unable to map that address.  Thus the driver+kernel works with
most BIOSes, but fails with yours.  The 2.2.* kernel uses a different kernel
memory mapping, and thus works with all BIOSes.

I'll change the Tulip driver (and others) to alway use the I/O space mapping
with the pre-2.2 kernels.

> I see the comment in the source of tulip.c:
> 
> /* This driver was originally written to use I/O space access, but now
>    uses memory space by default. Override this this with -DUSE_IO_OPS.
> */
> 
> Is there any practical difference between the two (I/O space access vs.
> memory space access), aside from the obvious (i.e., that memory space
> doesn't work for me)?  Why was the driver rewritten to use memory space
> by default?

Memory space write operations can be more efficient on most recent systems.
If you do a single memory write operation it's put into the cache-coherent
write buffer, and the CPU continues operation without delay.  The similar
I/O 'outl' operation will cause the CPU to wait until the PCI bus
transaction completes.

This efficiency is most obvious when transmitting a packet.  The only PCI
transaction necessary is a writel or outl that triggers the chip to check
the Tx queue.  (The chip can poll on Tx descriptors, but that adds latency.)

Don't get the mis-impression that waiting one additional PCI transaction
per Tx and packet and interrupt cycle is significant.  It isn't going to be
measurable, let alone noticeable.

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Beowulf Clusters / Linux Installations
Annapolis MD 21403