FATM(4) BSD Kernel Interfaces Manual FATM(4)NAME
fatm -- device driver for Fore PCA200E ATM interfaces
SYNOPSIS
device fatm
device utopia
device atm
options NATM
DESCRIPTION
The fatm device driver supports the FORE (now Marconi) PCA200E ATM interface cards. The driver interfaces with the natm(4) framework,
netgraph(4) and HARP. It provides only PVC services. Signalling, ATMARP, ILMI and other higher layer protocols are implemented using
netgraph(4) or HARP.
For configuring the card for IP see natmip(4). The following sysctls are recognized by the driver additionally to those handled by
utopia(4):
hw.atm.fatmN.stats
Returns a device specific statistic list of uint32_t statistic counters.
hw.atm.fatmN.istats
Returns a list of uint32_t with internal driver statistics.
hw.atm.fatmN.retry_tx
If this is set packets are stuffed back into the interface's send queue when the cards transmit queue is found to be full. They are
transmitted later. If this is not set the packets are dropped. It may be useful to set this if only UBR traffic is sent.
hw.atm.fatmN.debug
(Only if debugging enabled.) These are debugging flags. See src/sys/dev/fatm/if_fatmvar.h for the possible flags.
The driver supports the media options sdh, noscramb and unassigned (see utopia(4)).
DIAGNOSTICS
fatm0: <FORE PCA200E> mem 0xd5800000-0xd59fffff irq 9 at device 9.0 on pci0
SEE ALSO natm(4), natmip(4), utopia(4)AUTHORS
Harti Brandt <harti@FreeBSD.org>
BUGS
These cards can CBR shape a single VCC only. It is currently possible to request more than one CBR connection. In this case all the timing
will be wrong. See hatm(4) for a better card.
BSD May 15, 2003 BSD
Check Out this Related Man Page
PATM(4) BSD Kernel Interfaces Manual PATM(4)NAME
patm -- device driver for IDT77252 based ATM interfaces (ProSum and IDT)
SYNOPSIS
device patm
device utopia
device atm
options NATM
options LIBMBPOOL
DESCRIPTION
The patm device driver supports ATM cards based on the IDT77252 chip. It has been tested with ProSum's ProATM-155 cards and with IDT's eval-
uation boards. The driver interfaces with the natm(4) framework, netgraph(4) and HARP. It provides only PVC services. Signalling, ATMARP,
ILMI and other higher layer protocols are implemented using netgraph(4) or HARP.
For configuring the card for IP see natmip(4).
The driver supports UBR, CBR, VBR and ABR traffic. Supported AALs are: AAL0 (cell payloads), AAL5 and raw AAL. The driver supports opening
of VCI/VPI 0/0 in RX, raw AAL-mode. This VC will receive all incoming cells (even those with non-zero GFC fields and VPI/VCI values outside
the allowed range) that are not claimed by other open connections. This may be used for monitoring purposes.
The following sysctls are recognized by the driver additionally to those handled by utopia(4):
hw.atm.patmN.istats
Returns a list of uint32_t statistic counters with internal driver statistics.
hw.atm.patmN.eeprom
This is a read-only variable containing the contents of the on-board EEPROM device.
hw.atm.patmN.lbuf_max
This puts an upper limit on the number of large receive buffers the driver will allocate. This is a read-only variable that can be
set via a loader(8) tunable.
hw.atm.patmN.tx_maxmaps
This is the upper limit of transmission DMA maps the driver will allocate. This is read-only but may be set via a loader(8) tunable.
hw.atm.patmN.debug
(Only if debugging enabled.) These are debugging flags. See src/sys/dev/patm/if_patmvar.h for the possible flags. This may be ini-
tialized via a loader(8) tunable.
hw.atm.patmN.regs
(Only if debugging enabled.) Returns the current values of the card's registers.
hw.atm.patmN.tsq
Returns the transmit status queue.
When loaded, the driver initializes several variables from loader(8) tunables:
hw.patmN.lbuf_max
This initializes the corresponding sysctl(8) variable and defines an upper limit on the number of large receive buffers (mbuf clus-
ters).
hw.patmN.tx_maxmaps
This initializes the corresponding sysctl(8) variable and is the maximum number of DMA maps for transmission that the driver will
allocated.
hw.patmN.debug
(Only if debugging enabled.) Initializes the debugging flags.
The driver supports the media options sdh, noscramb and unassigned (see utopia(4)) when the card is a 155MBit card. Both PMC-Sierra S/UNI
and IDT77155 PHY chips are supported for these cards. For 25MBit cards the IDT77105 is supported.
DIAGNOSTICS
patm1: <NICStAR (77222/77252) ATM adapter> port 0xc000-0xc0ff mem 0xf8000000-0xf83fffff,0xf4000000-0xf4000fff irq 11 at device 8.0 on pci2
patm1: IDT77252 155MBit interface; idt77252 Rev. G; IDT77155 PHY
patm1: 128K x 32 SRAM; 4096 connections
SEE ALSO natm(4), natmip(4), utopia(4)CAVEATS
The card fails to generate an interrupt if a cell is received in AAL0 mode that has the MSB of the PTI field cleared. Therefore cells will
be delivered on the next receive interrupt which can happen either when the receive status queue is full, or a cell with the last bit of the
PTI set is received.
Although the card supports AAL3/4 the driver does not.
The rate tables used by this driver are not the tables recommended by IDT (they are wrong anyway). The driver's tables are slightly more
aggressive than IDT's. That means, that the actual cell rate can be slightly higher than the specified. This is in contrast to the IDT
tables where cell rates 5% less than the allowed one have been observed. This can be changed by changing the program that generates these
tables, found in /usr/src/sys/dev/patm/genrtab, and regenerating them.
The reported media for the 155MBit cards will always be OC3/MM, because there is no (known to me) way to figure out the actual medium. The
medium should really be coded in the EEPROM by the manufacturer.
The Tx cell counter in the utopia statistics is wrong, because the chip uses idle cells for spacing and the PHY counts these cells. While
there is a configuration option for the chip to switch of these cells and, according to the documentation, this should not influence cell
spacing, it does, so the driver lets the chip generate idle cells.
ACKNOWLEDGEMENTS
Thanks to Christian Bucari from ProSum for lending two of these cards to enable the development of this driver. Thanks also for answering my
questions.
AUTHORS
Harti Brandt <harti@FreeBSD.org>
BSD July 15, 2003 BSD