++++++++++++++++++++++++++++++++++++ ++++
+++++++++++++++++++++++++++++++++++++++++ +++++++++
++++++++++++++++++++++++++++++++++++++++++ +++++++++++
+++++++++++++++++++++++++++++++++++++++++ +++++++++++++
+++++++++++++
+++++++++++++
+++++++++++++
++++++++++++++++++++++++++++++ ++++++++++++
++++++++++++++++++++++++++++++ +++++++++++
+++++++++++++++++++++++++++++ +++++++++++
+++++++++++++++++++++++++++ ++++++++++
++++++++++
++++++++++
+++++++++++++++++++++++++++++++++++++++++ ++++++++++
++++++++++++++++++++++++++++++++++++++++++ ++++++++++
++++++++++++++++++++++++++++++++++++++++ +++++++++
+++++++++++++++++++++++++++++++++++ +++++
(C)Copyright 1994-1997 SysKonnect,
a business unit of Schneider & Koch & Co. Datensysteme GmbH.
All rights reserved
================================================================================
Name : skfp.txt
Readme File for SK-NET FDDI-FP Network Device Driver (NDD)
Subject: SK-NET FDDI-FP, PCI NDD Driver for AIX for IBM PowerPC Serie
Version/ Date/ Author of this file: 1.40.1.1 / 97/09/12 / A. Fischer
Version/ Date/ Author of the referred subject: v1.12b03 / 12.09.97 / A.Fischer
This file contains
(1) overview
(2) installation instructions for the PCI device driver on AIX 4.1
(3) reference list of additional device configuration parameters
(4) known limitaions
(5) bugs fixed
(6) problems fixed
================================================================================
(1) OVERVIEW
============
The network device driver (NDD) supports max. 32 SK FDDI PCI network
adapters.
Requirements:
-------------
The SK-NET FDDI-FP network device driver is designed for network access
on AIX 4.1 based PowerPC machines with PCI bus.
For proper driver access the corresponding FDDI protocol interface must
be installed for TCP/IP configuration.
Required software for network driver only:
devices.mca.8ef4.com - Software package from AIX installation CD
Required Software for network driver's diagnostic package only:
bos.diag.rte 4.1.2.0 - Diagnostic software package from AIX
installation CD
devices.pci.48110040.rte 1.0.0.2 - Network driver package
If you select the complete NDD software package both the network driver and
the diagnostic package will be installed.
(2) INSTALL THE DRIVER ON AIX 4.1
=================================
For the following actions you should login as root on your console:
* Software Installation
- Installation from console
* Removing Software Package
- Deinstallation from console
* Configuration of the NDD
* Copyright messages
Software Installation
---------------------
You have probably done these steps below:
Run the `smit` program and step through the following menus:
"Software Installation and Maintenance"
"Install and Update Software"
"Install/Update Selectable Software (Custom Install)"
"Install Additional Device Software"
Some additional input is required when the following text appears:
"INPUT device / directory for software [ ]"
Press F4 and select the device /dev/fd0 (Diskette Driver)
"SOFTWARE to install [ ]"
Press F4 to list the software package on your installation diskette.
Then move the cursor to the desired item and press F7 <RETURN>:
"x.x.x.x devices.pci.48110040"
Installation from console:
You can also install the network driver package from the system console
with the `installp` command as follows:
Installation from floppy: installp -d /dev/fd0 devices.pci.48110040
Installation from HD : installp -d <image-file> devices.pci.48110040
Typically the <image-file> is a disk dump file with the extension .dd .
You can create a 3,5" install diskette from this file:
dd if=<image-file> of=/dev/rfd0 bs=32k .
Removing Software Package
-------------------------
Before you deinstall the NDD package from your hard disk you must remove
the network driver from the kernel:
rmdev -l fi0 Remove FDDI protocol from network driver
rmdev -l fddi0 -d Remove the network device driver
To remove the software package step through the following smit menus:
"Software Installation and Maintenance"
"Maintain Installed Software"
"Remove Software Products"
Press F4 to list the installed software packages. Use the search key "/"
to get to the network device software package. Select the driver package
`devices.pci.48110040.driver` with F7 and return to the previous menu.
Set the field `PREVIEW only` to `no` to remove the software package ....
Then hit the RETURN key to remove the software package.
Deinstallation from console:
You can remove the driver package with the `installp` comand as follows.
Deinstallation from HD : installp -u devices.pci.48110040
You can also invoke the `smit` command for removing the driver software.
Please refer to the following section.
Configuration of the NDD
------------------------
You can configure up to 32 network devices of the same type. Normally
the number of devices is restricted due to the limited number of system
resources available. You need not care for system configuration para-
meters e.g. interrupt or IO space. This is automatically done when you
reboot the computer or if you execute the `smit` command:
"Devices"
"Configure Devices Added After IPL"
The configuration manager on your computer detects the network adapter
automatically in the PCI configuration space. It creates the network
devices for each existing adapter.
If all network adapters have been configured the devices are set to the
state `Available`. Check the FDDI network driver state by entering this
command:
lsdev -C | grep fddi
You can also configure some parameters that can be changed by the user.
These are parameters for configuring the MAC address, software queue or
the SBA/ESS (Synchronous Bandwidth Allocator/End Station Support). Find
a detailed description below.
To get to the driver's configuration menu step through these menus:
"Devices"
"Communication"
"SK-NET FDDI-FP Adapter"
"Adapter"
"Change / Show Characteristics of an SK-NET FDDI-FP Adapter"
and select a network device from the list of available devices
"fddi0 Available 04-0X SK-NET FDDI-FP Network Adapter"
"fddi1 Available 04-0X SK-NET FDDI-FP Network Adapter"
....
A configuration window appears.Change the configuration parameters that
you want to change for the active device and press RETURN. The network
device will be updated with the new configuration parameter.Please note
that some configuration becomes active if the network device is started
again. To do this you should detach any existing FDDI protocol from the
network device and start the protocol again. Please note that the net-
work driver attaches to the FDDI ring if the device is opened by a user
(network protocol). The driver detaches a device from the FDDI ring on
the last close.
Copyright messages:
-------------------
The NDD does not display any boot message on screen.When installing the
driver package the following copyright messages will be displayed:
"Copyright (C) 1995, 1996, 1997 SysKonnect
a business unit of Schneider & Koch & Co. Datensysteme GmbH.
All Rights Reserved."
"Synchronous Bandwidth Allocator, Copyright International Business
Machines Corporation, 1993, 1994, 1995, 1996, 1997. All rights reserved.
(3) ADDITIONAL DEVICE CONFIGURATION PARAMETERS
==============================================
"USER Data"
User data to be passed to the SMT for management information base (MIB).
"PMF password"
Parameter Management Frame (PMF) for the adapter. A nonzero PMF password
enables autorization checking of the adapter for remote change requests.
A PMF password of 0 disables the authorization checking of the adapter.
The PMF password consists of 16 hexadecimal digits. Default value is 0.
"Transmit Queue Size"
Number of tx - frames that can be queued by the driver software queue in
both the synchronous and the aysnchronous transmit queue when the ring is
under heavy load. Valid values: 3-250. Default value : 30.
"MAX T-REQ"
The parameter provides local write access to the 2s complement TReq value
registered as fddiMAC 51 in the SMT Standard.The value for TREQ is speci-
fied in milliseconds. The valid range reaches from 5 ms to 165 ms. If any
value is specified which is outside the limits, the upper/lower limit will
be used. If no value is specified the default value for TREQ (165 ms) will
be used.
"TVX lower bound"
This parameter provides local write access to the TVX attribute registered
as fddiMAC 54 in the SMT Standard.This attribute provides local control of
the recovery time from transient ring errors. The value for TVX is speci-
fied in microseconds. The valid range reaches from 2500 us to 10000 us. If
a value is specified outside the limits, the upper/lower limit is used. If
no value is specified the default value for TVX (2700 us) is used.
"Enable Alternate MAC / SMT Address"
If the attribute is set to yes,the network node address will be set to the
alternate address instead of the manufacturer provided unique address. If
the attribute is set to no, this has no effect. Valid values: yes, no.
Default value is no.
"Alternate MAC/SMT Address"
If the `Enable Alternate Mac / SMT Address` attribute is set to yes, this
address describes the MAC address that is used as alternate network address.
A valid value is 12 hexadecimal digit. Default value is none.
"SBA_Payload"
The parameter defines the requested synchronous bandwidth for manual static
allocations. The valid range is from 0-1562 bytes per 125 micro seconds.For
example, if the required bandwidth is 1 MBit/s (125,000 Bytes/s) the value
of the payload is 125,000 * 125E-6 = 15.625 round up to 16. If a value is
specified outside the limits the upper/lower limit is used.
The default value is zero - no synchronous bandwidth is used. The user is
required to define the amount of bandwidth to be able to send synchronous
frames.If the parameter SbaPayLoad is not specified the keyword SbaOverHead,
MaxTNeg, MinSegmentSize and SbaCategory have no effect.
The end station supports either the static allocation model, where the re-
quested payload is specified by the parameter SbaPayload or by the dynamic
allocation model, where the required synchronous bandwidth is allocated by
the multimedia application. If a multimedia application is used that can
dynamically allocate the bandwidth, the parameter SbaPayLoad should not be
specified.
"SBA_Overhead"
This parameter defines the requested overhead for static allocations.
The valid range reaches from 0 to 5000 bytes. If a value is specified which
is outside the limits, the upper/lower limit is taken. The default value is
50 bytes. This parameter has only an effect if the parameter SbaPayLoad is
specified.
"Max_TNEG"
This parameter defines the maximum token rotation delay that is acceptable
to the application(s) using synchronous bandwidth. The valid range reaches
from 5 ms to 165 ms. If a value is specified outside the limits, the upper/
lower limit will be taken. The default value is 25 ms.This parameter has an
effect, if the parameter SbaPayLoad is specified.
"Min_Segm_Size"
This parameter defines the minimum synchronous segmentation size. The value
corresponds to the amount of bytes to be transmitted on a per token opportu-
nity. The valid range reaches from 1 to 4478 bytes. If a value is specified
which is outside the limits,the upper/lower limit is used.The parameter has
only an effect if the keyword SbaPayLoad is specified.
"SBA_Category"
This parameter defines the session ID of the SBA_Category for the static
allocation.The valid ranges reaches from 0 to 65535.If a value is specified
which lies outside the limits, the upper / lower limit will be taken. This
parameter has only an effect, if the keyword SbaPayLoad is specified.
"Sync_Tx_Mode"
This keyword defines the synchronous transmission mode.The default value is
'SPLIT' where only packets identified as synchronous packets shall be trans-
mitted by the synchronous queue.The other value is 'ALL' that means that all
LLC packets received from upper layers are transmitted via the synchronous
queue. This keyword has only an effect, if the end station support was able
to get the required synchronous bandwidth from the SBA.
"SBA_Command"
The SbaCommand specifies a SBA local action to start / stop the SBA of the
network device. Valid values: start, stop. Default value : stop.
"SBA_Available"
The parameter SbaAvailable specifies the maximum synchronous bandwidth in
percent available for the primary path. If the value is outside the valid
range, the upper/lower limit will be taken. Valid values: 0 .. 100. Default
value is 50.
(4) KNOWN LIMITATIONS
=====================
No limitations are known.
(5) KNOWN BUGS
==============
(6) PROBLEMS FIXED
==================
Problems fixed in rel: v1.02b01:
--------------------------------
The DAS adapters did not insert into a dual ring. This problem is fixed.
A lack of performance may be caused on the send side due to a problem when
scheduling the transmit queue. The performance problem when sending with
max. speed has been fixed in this driver release.
A strange behaviour of the LEDs was detected when loading or unloading the
network driver. This problem is fixed.
The error message "ST3L: parity error in receive queue 2" has been printed
out although this error did not occur. This problem had been fixed. This
message was caused due to checking the wrong bit. The problem is fixed.
Problems fixed in rel: v1.02b03:
--------------------------------
NFS accesses are very slow with the PCI FDDI board if there is no traffic.
Since NFS keeps on waiting for tx-mbuf to be freed immediately, the driver
checks the outgoing mbufs for an optional free - function. If such a free-
function exists (like in NFS mbufs) a tx-complete interrupt is generated
after the mbuf has been sent. This prevents NFS from running slowly.
When running the driver on multiprocessor machines an invalid IO address
may be used for IO access that causes one processor reading invalid data
and blocking the system. This bug has been fixed in this release.
When queueing outgoing frames with a very high rate (more than 70% of the
tx frames) frames may be lost when the driver was not able to clear the tx
queue.
When running netperf - tests on TCP/IP with the RFC1323 option set to one
a lack of performance was detected.In this mode additional space in the tx
ring is needed for sending higher fragmented frames. A higher number of tx
fragments in the transmit path prevents the driver from queueing too many
frames.
Problems fixed in rel: v1.02b04:
--------------------------------
Allocation of RX mbufs has been changed. The driver allocates now receive
buffers with two 4K mbufs instead of a single mbuf with more than 4K size.
This was neccessary due to an 'out of mbuf' error that was caused by the
driver's preallocation function for receive buffers. System resources
exhausted due to the large amount of receive buffer storage of the driver.
Problems fixed in rel: v1.02b05:
--------------------------------
Allocation of RX mbufs has been made configurable.Configuration parameters
for allocation of both frames with two 4K mbufs and with single mbufs with
more than 4K size have been added to the smit configuration files. Now the
two configuration parameters `Extended receive mbuf size` and `Receive
frame count` can be used to specify the type of allocation and the number
of max. receive buffers (frames) in the receive queue.
Support of VPD has been implemented in the driver.
Error logging has been implemented in the driver.
Problems fixed in rel: v1.02b06
-------------------------------
The following bug in the SMT has been fixed:
After a ring op changes or a driver reset it could happen, that the FORMAC
and the ASIC became asynchronous.As a consequence the following may happen
- PCI bus violations, the machine my hang up.
- The FORMAC may send frames which will never
stripped by any station after a ring operational change.
The bug has been fixd in this driver release release.
Problems fixed in rel: v1.02b07
-------------------------------
The RX/TX descripors have been placed into physical contiguous memory.
If a large number of descriptors are used a page size of 4K memory will be
exceeded that may not be physically contguous.
Problems fixed in rel: v1.02b08
-------------------------------
In the previous release the driver did not correctly set the multicast RX-
mode automatically if the multicast address table was full.The problem has
been fixed in this release. Independent of setting the multicast RX - mode
by I/O control the driver enables the promisuous mode automatically if the
multicast address table is full and disables the promisuous mode again if
the address table contains less multicast addresses than the address table
can hold ( assumed that the multicast receive mode is not enabled by I/O -
control permanently).
Problems fixed in rel: v1.03b01:
--------------------------------
Previous PCI drivers that include SMT software releases 2.6.2 and before
had the following SMT bug:
A dual homing problem has been detected in DAS and DAC: If you plug port B
and then port A and then unplug port B again the ring would come up after
50 seconds. The bug has been fixed in this new release. Now the ring comes
up immediately.The network driver contains SMT software release 2.6.3 that
complies to the SMT version 7.3.
A bug in the receive part of the driver has been fixed, that causes a loss
of performance only: on heavy receive load the receive descriptor ring was
completely cleared, that delayed the next receive interrupt.An internal rx
counter was not reset on adapter restart. As a consequence the rx-ring was
not refilled correctly. Basically the problem does not happen if the driver
was not restarted or was reloaded. The problem occurs the first time after
the driver was stopped (but not unloaded) and restarted and if system mbufs
become low.
Error Log Entry: LABEL: SKFX_HWM_SWE
IDENTIFIER: A06C8DD0
FAILURE REASON: HWM: Out of RxD condition detected
The field "Max Packets on S/W Transmit Queue:" was set to the max. transmit
queue length. It should be a 'high water' mark of the maximum number of the
packets ever queued up to the driver. In the new driver release it reflects
the high water mark of frames that have been queued after the last reset of
FDDI statistic counters. This field can be reset by 'fddistat -r' command.
Problems fixed in rel: v1.04b01:
--------------------------------
A bug was fixed that could cause a driver crash or at least invalid data:
When the driver requeues a receive descriptor because the descriptor ring
of the receive side was empty an incorrect physical address may passed to
receive descriptor ring. If the length of the next receive frame exceeds a
page size of 4K the system could crash.Typically this happens only on very
strong receive load or if the driver receives an SMT - frame followed by a
any rame with a length of more than 4K. This does not happen if the driver
configuration parameter "Extended receive mbuf size" was set to "yes" (no
default value).
Internal NDD statistics will be set by the driver correctly. The former
driver release did not set the NDD statistic variables.NDD statistics can
be displayed with the 'ndb' command.
The receive address table returned from the NDD_MIB_ADDR - IO control was
incorrect. This has been corrected.
The IO controls NDD_MIB_QUERY and NDD_MIB_GET were not implemented in the
former driver release but the driver returned zero indicating valid data
have been copied into the caller's receive buffer. Now both IO controls
are implemented and will return correct data.
Problems fixed in rel: v1.04b02
-------------------------------
Additional trace IDs have been added for the trace groups 'open / close /
config / control and error conditions. This allows a trace separated from
the RX and TX path (that will normally produce very much output).
Problems fixed in rel: v1.04b03
-------------------------------
Statistic counters for in/out errors and purged frames were not correctly
updated. This has been fixed in this latest release.
Problems fixed in rel: v1.04b04
-------------------------------
The IOCTRL command 'NDD_MIB_ADDR' returned an invalid mac address. Now it
returns the physical address format of the mac address.
The NDD_RUNNING flag is set in the ndd_flags field before the driver is
ready to transmit packets. The NDD_RUNNING flag remains set in the field
after the cable is unplugged.Now the flag is set when the NDD is attached
to the ring and is removed when the NDD is detached from the ring.
Not all trace points are formated in the trace format file.Additional IDs
have been added to the trace file for the rx- function: mac_drv_rx_init.
The command fddistat showed an invalid statistic value for the Connection
Policy Violation. This is now set to zero because there is no appropriate
SMT variable available for this statistic counter.
A bug in the PowerManagement handler function was fixed that lets the NDD
crash on SMP environment only (invalid lock access).
Problems fixed in rel: v1.04b05 / v1.04
---------------------------------------
A bug in the PowerManagement handler functions was fixed that caused the
driver not to attach to the ring again after coming up from hibernation.
IOCTLs have been added to the ADD FILTER command for receiving SMT frames
from the network driver's SMT.
The network driver description has been changed for the lsdev -C command.
Problems fixed in rel: v1.05b01 / v1.05
---------------------------------------
The error log message identifies now the adapter number that displayed the
error e.g: fddi0, fddi1 .....
In error logs of previous driver releases it could happen that an error text
was truncated.The maximum length of error message field 'Detail_Data' is now
128 characters instead of 64 characters before.
If the driver is busy and the customer tries to unload the driver it does no
more generate an error log entry (rmdev -l fddiX).
In previous driver releases no error message description was added to the
error description data base (errpt -w E) for the driver specific message IDs
8500 - 8509.In this new release an appropriate error description is added to
the data base file. Instead of the message ID the errorlog output shows now
the error description.
A bug was fixed that could cause a system crash if a not existing device was
initialized.
Problems fixed in rel: v1.06b01
-------------------------------
A bug was fixed that could cause a system crash under certain circumstances:
When the driver has to requeue outgoing frames due to heavy netload and the
cable connected to the corresponding adapter was unpluged and pluged again
the system could crash. The problem does not occur,if the cable of an other
station was unpluged to generate the ring operational change.
Problems fixed in rel: v1.06b02
-------------------------------
Another bug was fixed that let the outgoing traffic stuck after he cable of
the corresponding adapter was unpluged and pluged during heavy netload. Any
applications e.g. TCP/IP or ping would no more operate correctly though the
operating system seems to work fine. The problem could be resolved if the
network driver was restarted again. Under certain circumstances the machine
could also hang up.
On SMP machines tx - frames may be lost if the network driver has to queue
outgoing frames due to heavy network load and any existing frames in the tx
queue are cleared during a long inoperational time (> 1 sec) of the network
adapter.The order of queued frames may be corrupted due to a SMP sync. bug.
A system crash or driver hang up was not yet detected concerning this bug.
Problems fixed in rel: v1.06b03 / v1.06
---------------------------------------
A new SMT release 2.6.4 has been implemented in this driver release with
the following changes:
- all stations: SUCCESS was returned on an PMF SET frame when setting the
mib.a[PATH0].fddiPATHSbaOverhead , but the parameter cannot be set when
mib.a[PATH0].fddiPATHSbaPayload is zero.
Now 'not authorizeed' is returned in this situation.
- all stations with SBA:DENIED was returned on an PMF SET when setting the
mib.a[PATH0].fddiPATHSbaAvailable and the SBA is not started ;
'not authorizeed' should be returned.
- all stations: mib.fddiSMTStationStatus was not set correctly.
- all stations/concentrator: entering RM4:NON_OP_DUP via RM(34a) , RM(34b)
or RM(34c) the station should disconnect from the ring. In the old SMT
version it was working, but it immediately reconnected to the ring. Now
it will not reconnect. An errorlog is generated.
- all stations/concentrator:the Link Error rate was compute wrongly (about
factor 12 to high)
- all stations/concentrator:the PLCs interrupt mask was not set correctly.
The PL_SELF_TEST bit was not set. The incorrect interrupt mask caused a
missing interrupt in the TRACE state and an unnecessary wait of 7 sec.
Problems fixed in rel: v1.07b01
-------------------------------
A new SMT release 2.6.5 has been implemented in this driver release with
the following changes:
- all stations : Setting SBA parameter results in success or `OutOfRange`
error.
- all station concentrator : duplicate address is now detected correctly.
The Duplicate Claim with T-Bid != T-Req is signaled directly to RMT.
- PCI driver:the PLC signaling starting has changed for the internal port.
It is now exactly according to the PLCS description.
- SN3 drivers : sometimes the PLL logic got locked up (under strange vol-
tage and temperature conditions). In that case the whole card must be
reset. The reset is handled by the individual driver. For that purpose a
function called drv_reset_indication is introduced. Also an Error log is
made in that situation.
- all drivers/concentrator: increment fddimibEBError_Ct if neccessary.
Problems fixed in rel: v1.07b02
-------------------------------
- The following bug was fixed:
Under stress the TX descriptor ring of the driver may run out of free TX
descriptors to be used for TX frames.If this happens the driver needs to
clear fragments from the TX descriptor ring,that have been already sent.
Clearing the TX descriptor ring may conflict with a send operation when
a new transmit descriptor list for a TX frame is generated. In this case
the TX fragment list was corrupted and did not send the correct data out
to the network. As a consequence protocols like TCP / IP receive invalid
data frames that seem to have an invalid packet size set in the protocol
header.TCP/IP performs retransmission and will get retransmission errors.
As a result a bad performance may be achieved.
- The following bug was fixed:
If the driver was just loaded but not started and was unloaded again the
driver did not free receive mbuf resources again.The bug could cause the
system running out of mbufs if the command is executed very frequently :
mkdev -l fddiX or chdev -l fddi0 -a MBUF_type=yes
rmdev -l fddiX chdev -l fddi0 -a MBUF_type=no
mkdev -l fddiX chdev -l fddi0 -a MBUF_type=no
rmdev -l fddiX chdev -l fddi0 -a MBUF_type=yes
..... .....
A new SMT release 2.6.6 has been implemented in this driver release with
the following changes:
- FDDI PCI driver: Workaround for SN3 temperature / low voltage problem has
changed. The counter of EBUF errors increased.
- all stations and concentrators: EBErrors can now be received by SMTLOOK.
Problems fixed in rel: v1.07b03
-------------------------------
- The following bug was fixed:
When setting a MAC address at driver initialization a canonical address
was expected by the driver. As a consequence the ndb and lscfg commands
displayed a different MAC address than passed to the driver. The address
format that is passed to the driver is also physical format as returned
from the driver in the NDD - interface structure and therefore needs to
be converted into canonical form.The bug has been fixed in this release.
Problems fixed in rel: v1.07b04
-------------------------------
- The following bug was fixed for multiprocessor machines only:
In a stress situation it happens that tx frames have to be queued in the
transmit queue because the receive path (interrupt was busy). Sometimes
the tx - scheduler function was not enabled for clearing the tx - queue.
This problem caused performance leaks that can be detected with netperf
tool. The bug is fixed in this new release.
Problems fixed in rel: v1.07b05
-------------------------------
A new SMT release 2.6.7 has been implemented in this driver release with
the following changes:
-Setting the TReq parameter was not handled correctly in the ISOLATED ring
state.This caused situation where the SBA could not be started correctly.
Problems fixed in rel: v1.07b06
-------------------------------
- The following bug was fixed:
If the driver was loaded and opened and was closed again the driver did
not free receive mbuf resources again. This bug could cause the system
running out of mbufs if the command is executed very frequently.
Problems fixed in rel: v1.07b07
-------------------------------
The driver release number has been added to the driver's object file that
can be requested with the following command:
what /etc/drivers/<driver-object>
A release string is displayed for a beta release e.g:
SK-NET FDDI-PCI rel. v1.07b07 96/11/15 (C) SK" ;
or for a final release e.g:
SK-NET FDDI-PCI rel. v1.07 96/11/15 (C) SK" ;
Problems fixed in rel: v1.08b01
-------------------------------
A bug was fixed for multiprocessor machines concerning the following bug
fix that has been done already ( for single processor machines only ) in
release: v1.07b01
- SN3 drivers : sometimes the PLL logic got locked up (under strange vol-
tage and temperature conditions). In that case the whole card must be
reset. The reset is handled by the individual driver. For that purpose a
function called drv_reset_indication is introduced. Also an Error log is
made in that situation.
The workaround for the problem described above did not work correctly on
SMP machines.A system lock may occur while recovering from the PLL error
condition due to a conflict with the TX path. Now the problem is fixed.
Problems fixed in rel: v1.08b02
-------------------------------
A bug was fixed concerning the `PLL logic` problem described above for
previous driver release.
If the driver needs to recover from the `PLL logic hangup condition` it
causes the consumtion of system mbufs. As a consequence the system runs
out mbuf resources over a long time. The system locks up. Sometimes the
error log entry may occur: HWM: Out of RxD condition detected
Problems fixed in rel: v1.08b03
-------------------------------
The following bugs have been fixed:
If the tx-ring runs out of space during the tx queue is cleared the tx-
queue looses mbufs only if the tx - queue is partially cleared when the
`tx ring is full` condition is given. As a consequence the system could
run out of system resources after a long time. The problem occurs only
if there is at least a network load of more that 90% over a long time.
A spurious interrupt may occur after the driver has been closed and the
adapter`s interrupt has been disabled. In this case the driver`s inter-
rupt handler returned an invalid return code, indicating that there was
no valid interrupt. The system displays a SYSINTR error log message.
Problems fixed in rel: v1.08b04
-------------------------------
The following bug has been fixed for MP machines:
The driver may loose some tx - mbufs while queueing frames due to heavy
network load. The lack is caused by a missing SMP lock.
Problems fixed in rel: v1.08b05
-------------------------------
The following bug has been fixed for MP machines:
On heavy network load the tx-queue may be overload on a tx packet storm
that caused the driver to exceed the max. number of packets in the tx -
queue. As a consequence to much mbuf resources are held by the driver .
The protocol stack may hang due to a resource allocation failure . This
problem does not occur on single processor machines. Normally the mbuf
resources are returned to the system's mbuf pool when the driver is
exiting the stress situation. The bug is fixed in this new release.
Spurious interrupts may still occur when the driver recoveres from the
PLL elasticity event ( see also rel. v1.07b01 ) when there is heavy tx-
load e.g. a UDP tx storm. This problem is also fixed.
Problems fixed in rel: v1.08b06
-------------------------------
The following bug has been fixed:
SBA/ESS did not work correctly . The allocation of synchronous bandwith
failed. It was impossible to use synchronous bandwith between two nodes
that requested synchronous bandwidth from an SBA. Now the bug is fixed.
Problems fixed in rel: v1.09b01
-------------------------------
The following bug has been fixed:
If there is transient interrupt source that does not persist to be read
again by the second level interrupt handler , this can cause the driver
to disable interrupts without enabling them again. As a consequence the
driver seems to hang in the receive side . In this case the led does not
indicate a 'ring operational change' when disconnecting the driver from
the FDDI ring (green led is still on).
Problems fixed in rel: v1.09b04
-------------------------------
The following has been changed:
The ODM data base entry for the interrupt level has been changed as
follows (IBM/ID:214907): default value == "" (empty)
value range == "" (empty)
This allows the system to use a wider range of interrupt levels for
the PCI driver.
To avoid a possible deadlock situation in the PM handler the MP- lock in
the the PM handler function has been removed except for critical code as
stopping and starting the network driver (IBM/ID:218111).
The following bug has been fixed:
The driver may let the system crash due to an invalid mbuf pointer that
is used in the `nd_trace` kernel interface function. This may happen if
data is sent via NFS.The problem (IBM/ID:217487) is fixed in this driver
release.
The driver may let the system crash during an internal data copy of SMT
data, that have been received from the network addressed to the driver's
local SMT. This problem is caused by a ring-op, when the driver receives
large SMT info frames, or after loading and connecting the driver to the
network The problem (IBM/ID:217732) is fixed in this driver release.
Problems fixed in rel: v1.10b01
-------------------------------
The following bugs have been fixed:
The machine initialization by BIOS or Firmware of the PCI command register
was overwritten since the command register was not read back before is was
configured. The bug has been fixed in this release.
There was an uninitialized local variable that is used to update the m_flag
of an mbuf that could cause kernel crashes. This function is called only if
a driver user has requested SMT frames to be returned from the driver . The
problem has been triggered by a new version of the snmpd command in AIX 4.2.
The problem does not occur in normal operation with TCP/IP of NFS. The bug
has been fixed in this release.
When executing a `sna -display` command SNA gets a timout error if only SNA
is attached to the driver but no other protocol stack e.g. FDDI.The timeout
was cuased by a wrong signaling of the driver's LIMBO and RUNNING status to
the upper protocol with both the ndd interface structure and the nd_status
interface function.
The incorrect signaling is shown in picture (I). The correction is shown in
picture (II):
L=Driver is loaded
O=First open of network driver (NDD_open)
C=(Re-)Connect to FDDI ring
D=Detach from FDDI ring
*=nd_status - messages
I) SK FDDI driver - status signaling (rel 1.09b04)
-----------------------------------------------
L O C D C
__________________________________ 1 (set)
NDD_UP ___|.........................................0
___________ ________ 1 (set)
NDD_RUNNING __________| |________|...............0
________ __________ 1 (set)
NDD_LIMBO ___| |_________| |_______........0
*NDD_CONNECTED
*NDD_LIMBO_EXIT X X
*NDD_LIMBO_ENTER X
II) SK FDDI driver - status signaling (rel 1.10b01)
-----------------------------------------------
L O C D C
__________________________________ 1 (set)
NDD_UP ___|.........................................0
___________ ________ 1 (set)
NDD_RUNNING __________| |________|...............0
__________ 1 (set)
NDD_LIMBO ____________________| |_______........0
*NDD_CONNECTED X
*NDD_LIMBO_EXIT X
*NDD_LIMBO_ENTER X
Problems fixed in rel: v1.11b01
-------------------------------
64 Bit enhancement:
The 64bit enhancement does not apply to the ability of addressing physical
64 bit wide addresses by the NIC. There is still no such enhancement in the
driver. Furthermore this means only that the driver may also be loaded to a
64 bit hardware platform.
Problems fixed in rel: v1.12b01
-------------------------------
In case of a 'bus list overflow' error a frame's fragmentation of physical
addresses may exceed internal storage capacity of the TX descriptor ring.In
this case the frame was discarded . The driver has been enhanced to handle
this exception by allocating a new mesage block and copying data into this
new data block before executing the DMA operation . If this operation also
fails the driver will generate a 'bus list overflow'. This is not a bug fix
but may solve TX problems especially if a protocol sends frames that exist
of several mbufs that do not fit temporarily into the TX descriptor ring.
Changes for 64 Bit enhancement:
The DMA_MAXMIN_512K flag passed to the D_MAP_INIT kernel function has been
changed to the value DMA_MAXMIN_2M. Also the DMA_BYPASS flag that is passed
to the D_MAP_LIST function has been changed to DMA_READ.
Problems fixed in rel: v1.12b02
-------------------------------
The following bug has been fixed:
After returning from completed DMA operation when unmapping physical DMA
addresses an invalid pointer was passed to the kernel function D_UNMAP_LIST.
This occures also if the ring is down and the protocol layer tries to send
a frame to the network. The bug may cause a system crash.A system crash has
not been detected yet but is likely especially on heavy network load.
The configuration utility that is used for loading and initializing the
driver has been changed. Some printf messages have been removed.
Problems fixed in rel: v1.12b03
-------------------------------
The following bug has been fixed:
Due to a bug in the driver' s configuration part configuration of more than
10 devices was not possible since the network device driver did not handle
the logical device name fddi10 (and higher) correctly. The bug is now fixed
in this release.
Download Driver Pack
After your driver has been downloaded, follow these simple steps to install it.
Expand the archive file (if the download file is in zip or rar format).
If the expanded file has an .exe extension, double click it and follow the installation instructions.
Otherwise, open Device Manager by right-clicking the Start menu and selecting Device Manager.
Find the device and model you want to update in the device list.
Double-click on it to open the Properties dialog box.
From the Properties dialog box, select the Driver tab.
Click the Update Driver button, then follow the instructions.
Very important: You must reboot your system to ensure that any driver updates have taken effect.
For more help, visit our Driver Support section for step-by-step videos on how to install drivers for every file type.