DLink DFE-530TX+ Driver for Linux
From:
http://www.scyld.com/network/rtl8139.html
The driver installation directions are on the
Driver Updates page. You may install just one driver (see below), or install all updated drivers using either the netdriver.tgz file or the SRPM.
To install a single updated driver read the
Network Drivers as Modules page for instructions. You should, of course, substitute the proper driver file name.
When updating a single driver you will need to build pci-scan.o along with the specific driver.o file. This means that in addition to the driver.c file, you must download pci-scan.c, pci-scan.h, and kern_compat.h.
This driver provide a interface to the Media Independent Interface, "MII" transceiver configuration and diagnostic settings. This interface allows the media type (i.e. 10Mbps or 100Mbps, half or full duplex) to be configured. The settings are usually configured by the (slightly misnamed) mii-diag program. The details of this program may found on the
diagnostic home page.
From:
http://www.scyld.com/expert/modules.html
This page contains instructions on using Linux device drivers as loadable kernel modules.
Linux has a facility for linking device drivers into the running kernel.
This is called Modules support. With the vast variety of supported
devices, pre-linking a kernel with all device drivers is impractical.
Using loadable modules allow a commercial Linux distribution to use a
small initial kernel and link in the device support needed after the
machine has booted.
You may skip this step if a pre-compiled module is available for your
Linux distribution. In many cases drivers compiled for similar kernel
versions will work. Pre-compiled modules in the form of RPMS for popular
distributions are frequently available for Scyld provided device
drivers.
If a pre-compiled module is not available, you'll have to compile one
from the driver source code, or the source code RPM (SRPM). In the
instructions below driver.c refers to the name of the driver source file
for your device e.g. 3c59x.c, and driver.o refers to the compiled driver
module binary.
Verify that the source code for your current kernel version is installed.
If you don't have a /usr/include/linux/version.h file, do
cd /usr/src/linux; make include/linux/version.h
Copy the driver source code to a source directory. I usually use /usr/src/modules/driver.c.
Compile the file using the compile-command at the bottom of the driver
source file. If a compile-command is not there use the following compile
command:
gcc -DMODULE -D__KERNEL__ -O6 -c driver.c
As 'root', test the module by doing "insmod driver.o".
Install the driver module in the proper location for your distribution. This is usually /lib/modules/kernel-version/net/driver.o. The command to do this is
install -m 644 driver.o /lib/modules/`uname -r`/net/
If you get an "linux/version.h no such file or directory" message when
compiling the driver, you either have not installed the kernel source
code, or you haven't run
cd /usr/src/linux; make include/linux/version.h
yet. Most modern distributions install the essential header files of the
kernel source code, including a pre-built "version.h", so this isn't
always necessary. If you get a "modversions.h not found" message when
compiling the driver, delete '-DMODVERSIONS' from the command used to
compile the driver module.
As 'root', load the module using "insmod driver.o" and execute the
appropriate
route add -net ... for your local network.
If the networking works correctly, add the module to your system
configuration. For Slackware and most other systems, add the insmod
command to /etc/rc.d/rc.inet1 or /etc/rc.d/rc.local.
RedHat? users should
add the insmod line to /etc/rc.d/rc.modules or copy driver.o to
/lib/modules/`uname -r`/net/ and add the following line to
/etc/conf.modules:
alias eth0 driver
Drivers are designed with the goal that no options should be needed in
most environments. However not all cards and networks can be
automatically configured, thus drivers allow operational parameters to
be modified when they are loaded as a module. Typically the following
variables may be set:
name type description
debug int The debug message level, 0 (no messages) to 6 (wordy).
options int[] Per-card media type override and card operation
settings, typically the media type.
full_duplex int[] Set to '1' to force this interface to always be used in FD mode.
To test an option, load the module (as above) with a command such as
"/sbin/insmod driver.o full_duplex=1,0,1". This command sets the
full_duplex flag for the first and third cards of this type.
To set module parameters when the module is loaded automatically, add
the following line to /etc/conf.modules
alias eth0 driver
options driver full_duplex=1,0,1 debug=0
Note that spaces are permitted only between parameter names, not between the comma-separated numeric options.
There are three known causes of this problem.
- Warm-booting from Win95 OSR2.1 or Win98 (power-managed cards only)
- "PnP OS" is set in the PCI BIOS setup.
- Broken PCI BIOSes (reportedly version "AI78" is broken).
Quick summary: restore operation by unplugging the machine after running
an OS that disables the card. Merely using the "soft-off" pushbutton on
a ATX case is not sufficient.
Many modern PCI chips have ACPI power management capability. Some
include a mode known as "D3-cold", where the chip can power itself off.
When in this mode the chip uses only the tiny amount of stand-by power
always available when an ATX power supply is plugged in. In the D3-cold
mode the chip can be turned on only by writing a PCI configuration space
register. This works great if you have a ACPI-aware BIOS that knows how
to re-enable the chip on a warm boot, but older BIOS don't know that the
chip cannot retain configuration information. When the machine is warm
booted the chip has only invalid configuration information.
The
PnP? OS problem occurs because Microsoft has convinced BIOS makers to
modify their PCI device configuration from the previous rational
standard, to one that works well only with Microsoft operating systems.
Where previously the BIOS allocated resources for and enabled the PCI
device by default, it now does so only for boot devices and audio
devices. (Why are audio devices specifically an exception? Because
MS-Windows can't handle the resource allocation for them!)
The solution is to either update to the latest driver, (the drivers are
being re-worked to enable the devices) or to disable the "PnP OS"
setting in the machine's BIOS setup.
The reason Microsoft had to have this change implemented for them was
that MS-Windows still handles some devices with "real-mode" drivers, and
this change makes it easier to mix real-mode and protected-mode device
drivers. This is an excellent example of Microsoft using its dominant
position in the software industry force a technical change that is
detrimental to other operating systems.
Drivers may be updated individually by following the directions in
http://scyld.com/expert/modules.html. You will need to build both the
driver.o and pci-scan.o modules using the following source files from
ftp://ftp.scyld.com/pub/network/
the driver source file
pci-scan.c
pci-scan.h and
kern_compat.h
In the instructions below driver.c refers to the name of the driver
source file for your device e.g. 3c59x.c, and driver.o refers to the
compiled driver binary module.
- Copy the driver source files to a convenient directory. I usually use /usr/src/modules/.
- Compile both the driver file and pci-scan.c using the compile-command at the bottom of the source files. If a compile-command is not there use the following compile command:
gcc -DMODULE -D__KERNEL__ -O6 -c driver.c
gcc -DMODULE -D__KERNEL__ -O6 -c pci-scan.c
With some distributions, especially those based on the 2.4 kernel,
you may need to add the following options to the compile command
-I/usr/src/linux/include -include /usr/src/linux/include/linux/modversions.h
As 'root', test the module by doing
insmod pci-scan.o
insmod driver.o
Install the modules in the proper location for your distribution. This is usually /lib/modules/kernel-version/net/driver.o. The command to do this is
install -m 644 pci-scan.o driver.o /lib/modules/`uname -r`/net/
The uname -r command expands to the current kernel version name.
Red Hat 7.0 has a flawed configuration with their default install. The
symptom is a variety of errors when trying to compile the driver update
source RPM. The easiest work-around is to use a precompiled RPM for Red
Hat 7.0 running the x86 uniprocessor kernel from
ftp://ftp.scyld.com/pub/network/netdrivers-rh70.i386.rpm
Red Hat 7.0 uses the header files from an unreleased 2.3.99 kernel,
rather than installing the header files from the kernel that is actually
running. This was an attempt to make user-level binaries independent of
the specific kernel version, but it makes it impossible to automatically
build kernel modules.
A second problem is that 7.0 provides an experimental version of gcc
that was not intended for public release. The stable version of gcc
needed to correctly compile the kernel has been renamed to kgcc.
The work-around is to substitute kgcc for gcc and to add
-I/usr/src/linux/include on the compile command line when compiling by
hand. The Makefile in the tar file and RPM automatically include this
compile flag, however they cannot automatically use 'kgcc'.
To repeat: this is a flaw that was introduced with Red Hat 7.0. It is a
Red Hat configuration problem, not a driver update distribution bug. The
symptom of this bug is compile error messages such as
tulip.c: In function `tulip_open':
tulip.c:1437: structure has no member named `tbusy'
tulip.c:1438: structure has no member named `start'
...
The updated drivers may be also be linked into the kernel, rather than
being used as a module that is linked later. Replace the drivers in
drivers/net/* with the updated driver list.
Most kernel versions do not natively support the pci-scan.c layer. You
will have to explicitly add pci-scan.o to the L_OBJS entry in
drivers/net/Makefile.
L_TARGET := net.a
-L_OBJS := auto_irq.o
+L_OBJS := auto_irq.o pci-scan.o
-M_OBJS :=
+M_OBJS := pci-scan.o
MOD_LIST_NAME := NET_MODULES
Note that the 2.4 kernel is supported only as an experimental system. We
do not recommend using 2.4 kernels on production systems.
--
DaleBrayden - 12 Aug 2002
Books RSS
