mirror of https://github.com/mkerrisk/man-pages
cciss.4, dsp56k.4, fuse.4, hpsa.4, loop.4, rtc.4, sd.4, sk98lin.4, wavelan.4: Formatting fix: replace blank lines with .PP/.IP
Blank lines shouldn't generally appear in *roff source (other than in code examples), since they create large vertical spaces between text blocks. Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
parent
5711c04f8f
commit
5b539973c4
16
man4/cciss.4
16
man4/cciss.4
|
@ -226,7 +226,7 @@ for more details.)
|
|||
You must enable "SCSI tape drive support for Smart Array 5xxx" and
|
||||
"SCSI support" in your kernel configuration to be able to use SCSI
|
||||
tape drives with your Smart Array 5xxx controller.
|
||||
|
||||
.PP
|
||||
Additionally, note that the driver will not engage the SCSI core at
|
||||
init time.
|
||||
The driver must be directed to dynamically engage the SCSI core via the
|
||||
|
@ -254,7 +254,7 @@ For example:
|
|||
.fi
|
||||
Once the SCSI core is engaged by the driver, it cannot be disengaged
|
||||
(except by unloading the driver, if it happens to be linked as a module.)
|
||||
|
||||
.PP
|
||||
Note also that if no sequential access devices or medium changers are
|
||||
detected, the SCSI core will not be engaged by the action of the above
|
||||
script.
|
||||
|
@ -268,9 +268,9 @@ This may be done via the
|
|||
.I /proc
|
||||
filesystem.
|
||||
For example:
|
||||
|
||||
.PP
|
||||
echo "rescan" > /proc/scsi/cciss0/1
|
||||
|
||||
.PP
|
||||
This causes the driver to:
|
||||
.RS
|
||||
.IP 1. 3
|
||||
|
@ -286,14 +286,14 @@ devices have been added or removed and the controller, bus, target, and
|
|||
lun used to address each device.
|
||||
The driver then notifies the SCSI midlayer
|
||||
of these changes.
|
||||
|
||||
.PP
|
||||
Note that the naming convention of the
|
||||
.I /proc
|
||||
filesystem entries
|
||||
contains a number in addition to the driver name
|
||||
(e.g., "cciss0"
|
||||
instead of just "cciss", which you might expect).
|
||||
|
||||
.PP
|
||||
Note:
|
||||
.I Only
|
||||
sequential access devices and medium changers are presented
|
||||
|
@ -345,7 +345,7 @@ in aborting commands, and sometimes it appears they will not even
|
|||
obey a reset command, though in most circumstances they will.
|
||||
If the command cannot be aborted and the device cannot be
|
||||
reset, the device will be set offline.
|
||||
|
||||
.PP
|
||||
In the event that the error-handling code is triggered and a tape drive is
|
||||
successfully reset or the tardy command is successfully aborted, the
|
||||
tape drive may still not allow I/O to continue until some command
|
||||
|
@ -358,7 +358,7 @@ for example) before I/O can proceed again to a tape drive that was reset.
|
|||
.BR cciss_vol_status (8),
|
||||
.BR hpacucli (8),
|
||||
.BR hpacuxe (8)
|
||||
|
||||
.PP
|
||||
.UR http://cciss.sf.net
|
||||
.UE ,
|
||||
and
|
||||
|
|
|
@ -93,7 +93,7 @@ general-purpose bits that can be read by both the hosting computer and
|
|||
the DSP56001.
|
||||
Bits 0 and 1 can be written by the host, and bits 2 and
|
||||
3 can be written by the DSP56001.
|
||||
|
||||
.IP
|
||||
To access the host flags, the third
|
||||
.BR ioctl (2)
|
||||
argument must be a pointer
|
||||
|
|
70
man4/fuse.4
70
man4/fuse.4
|
@ -31,7 +31,7 @@ fuse \- Filesystem in Userspace (FUSE) device
|
|||
.B #include <linux/fuse.h>
|
||||
.nf
|
||||
.SH DESCRIPTION
|
||||
|
||||
.PP
|
||||
This device is the primary interface between the FUSE filesystem driver
|
||||
and a user-space process wishing to provide the filesystem (referred to
|
||||
in the rest of this manual page as the
|
||||
|
@ -42,7 +42,7 @@ Those implementing a FUSE filesystem may wish to make use of
|
|||
a user-space library such as
|
||||
.I libfuse
|
||||
that abstracts away the low-level interface.
|
||||
|
||||
.PP
|
||||
At its core, FUSE is a simple client-server protocol, in which the Linux
|
||||
kernel is the client and the daemon is the server.
|
||||
After obtaining a file descriptor for this device, the daemon may
|
||||
|
@ -59,7 +59,7 @@ through the first file descriptor (and vice versa).
|
|||
.SS The basic protocol
|
||||
Every message that is read by the daemon begins with a header described by
|
||||
the following structure:
|
||||
|
||||
.PP
|
||||
.in +4n
|
||||
.nf
|
||||
struct fuse_in_header {
|
||||
|
@ -76,19 +76,19 @@ struct fuse_in_header {
|
|||
};
|
||||
.fi
|
||||
.in
|
||||
|
||||
.PP
|
||||
The header is followed by a variable-length data portion
|
||||
(which may be empty) specific to the requested operation
|
||||
(the requested operation is indicated by
|
||||
.IR opcode ).
|
||||
|
||||
.PP
|
||||
The daemon should then process the request and if applicable send
|
||||
a reply (almost all operations require a reply; if they do not,
|
||||
this is documented below), by performing a
|
||||
.BR write (2)
|
||||
to the file descriptor.
|
||||
All replies must start with the following header:
|
||||
|
||||
.PP
|
||||
.in +4n
|
||||
.nf
|
||||
struct fuse_out_header {
|
||||
|
@ -100,7 +100,7 @@ struct fuse_out_header {
|
|||
};
|
||||
.fi
|
||||
.in
|
||||
|
||||
.PP
|
||||
This header is also followed by (potentially empty) variable-sized
|
||||
data depending on the executed request.
|
||||
However, if the reply is an error reply (i.e.,
|
||||
|
@ -117,7 +117,7 @@ For each message, first the struct sent by the kernel is given,
|
|||
followed by a description of the semantics of the message.
|
||||
.TP
|
||||
.BR FUSE_INIT
|
||||
|
||||
.IP
|
||||
.in +4n
|
||||
.nf
|
||||
struct fuse_init_in {
|
||||
|
@ -128,7 +128,7 @@ struct fuse_init_in {
|
|||
};
|
||||
.fi
|
||||
.in
|
||||
|
||||
.IP
|
||||
This is the first request sent by the kernel to the daemon.
|
||||
It is used to negotiate the protocol version and other filesystem parameters.
|
||||
Note that the protocol version may affect the layout of any structure
|
||||
|
@ -138,12 +138,12 @@ and flags for each session.
|
|||
As of the writing of this man page,
|
||||
the highest supported kernel protocol version is
|
||||
.IR 7.26 .
|
||||
|
||||
.IP
|
||||
Users should be aware that the descriptions in this manual page
|
||||
may be incomplete or incorrect for older or more recent protocol versions.
|
||||
|
||||
.IP
|
||||
The reply for this request has the following format:
|
||||
|
||||
.IP
|
||||
.in +4n
|
||||
.nf
|
||||
struct fuse_init_out {
|
||||
|
@ -160,7 +160,7 @@ struct fuse_init_out {
|
|||
};
|
||||
.fi
|
||||
.in
|
||||
|
||||
.IP
|
||||
If the major version supported by the kernel is larger than that supported
|
||||
by the daemon, the reply shall consist of only
|
||||
.I uint32_t major
|
||||
|
@ -171,13 +171,13 @@ The kernel will then issue a new
|
|||
request conforming to the older version.
|
||||
In the reverse case, the daemon should
|
||||
quietly fall back to the kernel's major version.
|
||||
|
||||
.IP
|
||||
The negotiated minor version is considered to be the minimum
|
||||
of the minor versions provided by the daemon and the kernel and
|
||||
both parties should use the protocol corresponding to said minor version.
|
||||
.TP
|
||||
.BR FUSE_GETATTR
|
||||
|
||||
.IP
|
||||
.in +4n
|
||||
.nf
|
||||
struct fuse_getattr_in {
|
||||
|
@ -188,7 +188,7 @@ struct fuse_getattr_in {
|
|||
};
|
||||
.fi
|
||||
.in
|
||||
|
||||
.IP
|
||||
The requested operation is to compute the attributes to be returned
|
||||
by
|
||||
.BR stat (2)
|
||||
|
@ -202,17 +202,17 @@ flag is set, by the file handle
|
|||
.IR fh.
|
||||
The latter case of operation is analogous to
|
||||
.BR fstat (2).
|
||||
|
||||
.IP
|
||||
For performance reasons, these attributes may be cached in the kernel for
|
||||
a specified duration of time.
|
||||
While the cache timeout has not been exceeded,
|
||||
the attributes will be served from the cache and will not cause additional
|
||||
.B FUSE_GETATTR
|
||||
requests.
|
||||
|
||||
.IP
|
||||
The computed attributes and the requested
|
||||
cache timeout should then be returned in the following structure:
|
||||
|
||||
.IP
|
||||
.in +4n
|
||||
.nf
|
||||
struct fuse_attr_out {
|
||||
|
@ -241,10 +241,10 @@ struct fuse_attr_out {
|
|||
};
|
||||
.fi
|
||||
.in
|
||||
|
||||
.IP
|
||||
.TP
|
||||
.BR FUSE_ACCESS
|
||||
|
||||
.IP
|
||||
.in +4n
|
||||
.nf
|
||||
struct fuse_access_in {
|
||||
|
@ -253,7 +253,7 @@ struct fuse_access_in {
|
|||
};
|
||||
.fi
|
||||
.in
|
||||
|
||||
.IP
|
||||
If the
|
||||
.I default_permissions
|
||||
mount options is not used, this request may be used for permissions checking.
|
||||
|
@ -274,7 +274,7 @@ struct fuse_open_in {
|
|||
};
|
||||
.fi
|
||||
.in
|
||||
|
||||
.IP
|
||||
The requested operation is to open the node indicated by
|
||||
.IR header\->nodeid .
|
||||
The exact semantics of what this means will depend on the
|
||||
|
@ -284,7 +284,7 @@ filesystem should validate that the requested
|
|||
.I flags
|
||||
are valid for the indicated resource and then send a reply with the
|
||||
following format:
|
||||
|
||||
.IP
|
||||
.in +4n
|
||||
.nf
|
||||
|
||||
|
@ -296,7 +296,7 @@ struct fuse_open_out {
|
|||
|
||||
.fi
|
||||
.in
|
||||
|
||||
.IP
|
||||
The
|
||||
.I fh
|
||||
field is an opaque identifier that the kernel will use to refer
|
||||
|
@ -333,7 +333,7 @@ struct fuse_read_in {
|
|||
|
||||
.fi
|
||||
.in
|
||||
|
||||
.IP
|
||||
The requested action is to read up to
|
||||
.I size
|
||||
bytes of the file or directory, starting at
|
||||
|
@ -348,7 +348,7 @@ struct fuse_interrupt_in {
|
|||
};
|
||||
.fi
|
||||
.in
|
||||
|
||||
.IP
|
||||
The requested action is to cancel the pending operation indicated by
|
||||
.IR unique .
|
||||
This request requires no response.
|
||||
|
@ -368,7 +368,7 @@ Directly following the header is a filename to be looked up in the directory
|
|||
indicated by
|
||||
.IR header\->nodeid .
|
||||
The expected reply is of the form:
|
||||
|
||||
.IP
|
||||
.in +4n
|
||||
.nf
|
||||
struct fuse_entry_out {
|
||||
|
@ -382,13 +382,13 @@ struct fuse_entry_out {
|
|||
};
|
||||
.fi
|
||||
.in
|
||||
|
||||
.IP
|
||||
The combination of
|
||||
.I nodeid
|
||||
and
|
||||
.I generation
|
||||
must be unique for the filesystem's lifetime.
|
||||
|
||||
.IP
|
||||
The interpretation of timeouts and
|
||||
.I attr
|
||||
is as for
|
||||
|
@ -405,7 +405,7 @@ struct fuse_flush_in {
|
|||
};
|
||||
.fi
|
||||
.in
|
||||
|
||||
.IP
|
||||
The requested action is to flush any pending changes to the indicated
|
||||
file handle.
|
||||
No reply data is expected.
|
||||
|
@ -423,7 +423,7 @@ struct fuse_release_in {
|
|||
};
|
||||
.fi
|
||||
.in
|
||||
|
||||
.IP
|
||||
These are the converse of
|
||||
.BR FUSE_OPEN
|
||||
and
|
||||
|
@ -443,7 +443,7 @@ This operation implements
|
|||
for this filesystem.
|
||||
There is no input data associated with this request.
|
||||
The expected reply data has the following structure:
|
||||
|
||||
.IP
|
||||
.in +4n
|
||||
.nf
|
||||
struct fuse_kstatfs {
|
||||
|
@ -464,7 +464,7 @@ struct fuse_statfs_out {
|
|||
};
|
||||
.fi
|
||||
.in
|
||||
|
||||
.IP
|
||||
For the interpretation of these fields, see
|
||||
.BR statfs (2).
|
||||
.SH ERRORS
|
||||
|
@ -478,7 +478,7 @@ file descriptor that has not been mounted.
|
|||
Returned from
|
||||
.BR read (2)
|
||||
operations when the kernel's request is too large for the provided buffer.
|
||||
|
||||
.IP
|
||||
.IR Note :
|
||||
There are various ways in which incorrect use of these interfaces can cause
|
||||
operations on the provided filesystem's files and directories to fail with
|
||||
|
|
|
@ -93,9 +93,9 @@ or entire storage boxes containing preconfigured logical drives.
|
|||
.TP
|
||||
.I /sys/class/scsi_host/host*/firmware_revision
|
||||
This attribute contains the firmware version of the Smart Array.
|
||||
|
||||
.IP
|
||||
For example:
|
||||
|
||||
.IP
|
||||
.nf
|
||||
# \fBcd /sys/class/scsi_host/host4\fP
|
||||
# \fBcat firmware_revision\fP
|
||||
|
@ -183,7 +183,7 @@ for some examples.
|
|||
.BR cciss_vol_status (8),
|
||||
.BR hpacucli (8),
|
||||
.BR hpacuxe (8),
|
||||
|
||||
.PP
|
||||
.UR http://cciss.sf.net
|
||||
.UE ,
|
||||
and
|
||||
|
|
14
man4/loop.4
14
man4/loop.4
|
@ -50,10 +50,10 @@ $ \fBsudo mount /dev/loop4 /myloopdev\fP
|
|||
See
|
||||
.BR losetup (8)
|
||||
for another example.
|
||||
|
||||
.PP
|
||||
A transfer function can be specified for each loop device for
|
||||
encryption and decryption purposes.
|
||||
|
||||
.PP
|
||||
The following
|
||||
.BR ioctl (2)
|
||||
operations are provided by the loop block device:
|
||||
|
@ -76,7 +76,7 @@ This argument is a pointer to
|
|||
structure, defined in
|
||||
.I <linux/loop.h>
|
||||
as:
|
||||
|
||||
.IP
|
||||
.nf
|
||||
.in +4n
|
||||
struct loop_info {
|
||||
|
@ -96,7 +96,7 @@ struct loop_info {
|
|||
};
|
||||
.in
|
||||
.fi
|
||||
|
||||
.IP
|
||||
The encryption type
|
||||
.RI ( lo_encrypt_type )
|
||||
should be one of
|
||||
|
@ -111,7 +111,7 @@ should be one of
|
|||
.BR LO_CRYPT_SKIPJACK ,
|
||||
or (since Linux 2.6.0)
|
||||
.BR LO_CRYPT_CRYPTOAPI .
|
||||
|
||||
.IP
|
||||
The
|
||||
.I lo_flags
|
||||
field is a bit mask that can include zero or more of the following:
|
||||
|
@ -162,7 +162,7 @@ described above but use the
|
|||
.I loop_info64
|
||||
structure,
|
||||
which has some additional fields and a larger range for some other fields:
|
||||
|
||||
.IP
|
||||
.nf
|
||||
.in +4n
|
||||
struct loop_info64 {
|
||||
|
@ -227,7 +227,7 @@ device to find a free loop device, opens the loop device,
|
|||
opens a file to be used as the underlying storage for the device,
|
||||
and then associates the loop device with the backing store.
|
||||
The following shell session demonstrates the use of the program:
|
||||
|
||||
.PP
|
||||
.nf
|
||||
.in +4n
|
||||
$ \fBdd if=/dev/zero of=file.img bs=1MiB count=10\fP
|
||||
|
|
24
man4/rtc.4
24
man4/rtc.4
|
@ -36,19 +36,19 @@ rtc \- real-time clock
|
|||
.BI "int ioctl(" fd ", RTC_" request ", " param ");"
|
||||
.SH DESCRIPTION
|
||||
This is the interface to drivers for real-time clocks (RTCs).
|
||||
|
||||
.PP
|
||||
Most computers have one or more hardware clocks which record the
|
||||
current "wall clock" time.
|
||||
These are called "Real Time Clocks" (RTCs).
|
||||
One of these usually has battery backup power so that it tracks the time
|
||||
even while the computer is turned off.
|
||||
RTCs often provide alarms and other interrupts.
|
||||
|
||||
.PP
|
||||
All i386 PCs, and ACPI-based systems, have an RTC that is compatible with
|
||||
the Motorola MC146818 chip on the original PC/AT.
|
||||
Today such an RTC is usually integrated into the mainboard's chipset
|
||||
(south bridge), and uses a replaceable coin-sized backup battery.
|
||||
|
||||
.PP
|
||||
Non-PC systems, such as embedded systems built around system-on-chip
|
||||
processors, use other implementations.
|
||||
They usually won't offer the same functionality as the RTC from a PC/AT.
|
||||
|
@ -64,7 +64,7 @@ defined to be the POSIX Epoch: 1970-01-01 00:00:00 +0000 (UTC).
|
|||
(One common implementation counts timer interrupts, once
|
||||
per "jiffy", at a frequency of 100, 250, or 1000 Hz.)
|
||||
That is, it is supposed to report wall clock time, which RTCs also do.
|
||||
|
||||
.PP
|
||||
A key difference between an RTC and the system clock is that RTCs
|
||||
run even when the system is in a low power state (including "off"),
|
||||
and the system clock can't.
|
||||
|
@ -78,7 +78,7 @@ maybe across the network or by entering that data manually.
|
|||
RTCs can be read and written with
|
||||
.BR hwclock (8),
|
||||
or directly with the ioctl requests listed below.
|
||||
|
||||
.PP
|
||||
Besides tracking the date and time, many RTCs can also generate
|
||||
interrupts
|
||||
.IP * 3
|
||||
|
@ -97,7 +97,7 @@ Hibernation (called S4 in ACPI systems),
|
|||
or even "off" (called S5 in ACPI systems).
|
||||
On some systems, the battery backed RTC can't issue
|
||||
interrupts, but another one can.
|
||||
|
||||
.PP
|
||||
The
|
||||
.I /dev/rtc
|
||||
(or
|
||||
|
@ -296,7 +296,7 @@ argument.
|
|||
.IR /dev/rtc0 ", "
|
||||
.IR /dev/rtc1 ", "
|
||||
etc: RTC special character device files.
|
||||
|
||||
.PP
|
||||
.IR /proc/driver/rtc :
|
||||
status of the (first) RTC.
|
||||
.SH NOTES
|
||||
|
@ -306,21 +306,21 @@ reference using
|
|||
it will update a designated RTC periodically every 11 minutes.
|
||||
To do so, the kernel has to briefly turn off periodic interrupts;
|
||||
this might affect programs using that RTC.
|
||||
|
||||
.PP
|
||||
An RTC's Epoch has nothing to do with the POSIX Epoch which is
|
||||
used only for the system clock.
|
||||
|
||||
.PP
|
||||
If the year according to the RTC's Epoch and the year register is
|
||||
less than 1970 it is assumed to be 100 years later, that is, between 2000
|
||||
and 2069.
|
||||
|
||||
.PP
|
||||
Some RTCs support "wildcard" values in alarm fields, to support
|
||||
scenarios like periodic alarms at fifteen minutes after every hour,
|
||||
or on the first day of each month.
|
||||
Such usage is nonportable;
|
||||
portable user-space code expects only a single alarm interrupt, and
|
||||
will either disable or reinitialize the alarm after receiving it.
|
||||
|
||||
.PP
|
||||
Some RTCs support periodic interrupts with periods that are multiples
|
||||
of a second rather than fractions of a second;
|
||||
multiple alarms;
|
||||
|
@ -338,6 +338,6 @@ capabilities that are not currently exposed by this API.
|
|||
.BR gmtime (3),
|
||||
.BR time (7),
|
||||
.BR hwclock (8)
|
||||
|
||||
.PP
|
||||
.I Documentation/rtc.txt
|
||||
in the Linux kernel source tree
|
||||
|
|
14
man4/sd.4
14
man4/sd.4
|
@ -42,7 +42,7 @@ is a number denoting the partition on that physical drive.
|
|||
Often, the partition number,
|
||||
.IR p ,
|
||||
will be left off when the device corresponds to the whole drive.
|
||||
|
||||
.PP
|
||||
SCSI disks have a major device number of 8, and a minor device number of
|
||||
the form (16 *
|
||||
.IR drive_number ") + " partition_number ,
|
||||
|
@ -57,7 +57,7 @@ partition 0 is the whole drive
|
|||
partitions 1-4 are the DOS "primary" partitions
|
||||
.br
|
||||
partitions 5-8 are the DOS "extended" (or "logical") partitions
|
||||
|
||||
.PP
|
||||
For example,
|
||||
.I /dev/sda
|
||||
will have major 8, minor 0, and will refer to all of the first SCSI drive
|
||||
|
@ -65,7 +65,7 @@ in the system; and
|
|||
.I /dev/sdb3
|
||||
will have major 8, minor 19, and will refer to the third DOS "primary"
|
||||
partition on the second SCSI drive in the system.
|
||||
|
||||
.PP
|
||||
At this time, only block devices are provided.
|
||||
Raw devices have not yet been implemented.
|
||||
.SH DESCRIPTION
|
||||
|
@ -74,7 +74,6 @@ The following
|
|||
are provided:
|
||||
.TP
|
||||
.B HDIO_GETGEO
|
||||
.RS
|
||||
Returns the BIOS disk parameters in the following structure:
|
||||
.in +4n
|
||||
.nf
|
||||
|
@ -87,11 +86,11 @@ struct hd_geometry {
|
|||
};
|
||||
.fi
|
||||
.in
|
||||
|
||||
.IP
|
||||
A pointer to this structure is passed as the
|
||||
.BR ioctl (2)
|
||||
parameter.
|
||||
|
||||
.IP
|
||||
The information returned in the parameter is the disk geometry of the drive
|
||||
.I "as understood by DOS!"
|
||||
This geometry is
|
||||
|
@ -106,7 +105,6 @@ and
|
|||
.BR lilo (1).
|
||||
If the geometry information is not available, zero will be returned for all
|
||||
of the parameters.
|
||||
.RE
|
||||
.TP
|
||||
.B BLKGETSIZE
|
||||
Returns the device size in sectors.
|
||||
|
@ -118,7 +116,7 @@ parameter should be a pointer to a
|
|||
.B BLKRRPART
|
||||
Forces a reread of the SCSI disk partition tables.
|
||||
No parameter is needed.
|
||||
|
||||
.IP
|
||||
The SCSI
|
||||
.BR ioctl (2)
|
||||
operations are also supported.
|
||||
|
|
|
@ -64,23 +64,23 @@ sk98lin \- Marvell/SysKonnect Gigabit Ethernet driver v6.21
|
|||
.hy 0
|
||||
.BR Note :
|
||||
This obsolete driver was removed from the kernel in version 2.6.26.
|
||||
|
||||
.PP
|
||||
.B sk98lin
|
||||
is the Gigabit Ethernet driver for
|
||||
Marvell and SysKonnect network adapter cards.
|
||||
It supports SysKonnect SK-98xx/SK-95xx
|
||||
compliant Gigabit Ethernet Adapter and
|
||||
any Yukon compliant chipset.
|
||||
|
||||
.PP
|
||||
When loading the driver using insmod,
|
||||
parameters for the network adapter cards
|
||||
might be stated as a sequence of comma separated commands.
|
||||
If for instance two network adapters are installed and AutoNegotiation on
|
||||
Port A of the first adapter should be ON,
|
||||
but on the Port A of the second adapter switched OFF, one must enter:
|
||||
|
||||
.PP
|
||||
insmod sk98lin.o AutoNeg_A=On,Off
|
||||
|
||||
.PP
|
||||
After
|
||||
.B sk98lin
|
||||
is bound to one or more adapter cards and the
|
||||
|
@ -95,7 +95,7 @@ where
|
|||
.I x
|
||||
is the number of the interface that has been assigned to a
|
||||
dedicated port by the system.
|
||||
|
||||
.PP
|
||||
If loading is finished, any desired IP address can be
|
||||
assigned to the respective
|
||||
.I eth[x]
|
||||
|
@ -105,7 +105,7 @@ command.
|
|||
This causes the adapter to connect to the Ethernet and to display a status
|
||||
message on the console saying "ethx: network connection up using port y"
|
||||
followed by the configured or detected connection parameters.
|
||||
|
||||
.PP
|
||||
The
|
||||
.B sk98lin
|
||||
also supports large frames (also called jumbo frames).
|
||||
|
@ -121,14 +121,14 @@ command with the mtu parameter.
|
|||
If for instance eth0 needs an IP
|
||||
address and a large frame MTU size,
|
||||
the following two commands might be used:
|
||||
|
||||
.PP
|
||||
ifconfig eth0 10.1.1.1
|
||||
ifconfig eth0 mtu 9000
|
||||
|
||||
.PP
|
||||
Those two commands might even be combined into one:
|
||||
|
||||
.PP
|
||||
ifconfig eth0 10.1.1.1 mtu 9000
|
||||
|
||||
.PP
|
||||
Note that large frames can be used only if permitted by
|
||||
your network infrastructure.
|
||||
This means, that any switch being used in your Ethernet must
|
||||
|
@ -141,19 +141,19 @@ In addition to the switches inside the network,
|
|||
all network adapters that are to be used must also be
|
||||
enabled regarding jumbo frames.
|
||||
If an adapter is not set to receive large frames, it will simply drop them.
|
||||
|
||||
.PP
|
||||
Switching back to the standard Ethernet frame size can be done by using the
|
||||
.BR ifconfig (8)
|
||||
command again:
|
||||
|
||||
.PP
|
||||
ifconfig eth0 mtu 1500
|
||||
|
||||
.PP
|
||||
The Marvell/SysKonnect Gigabit Ethernet driver for Linux is able to
|
||||
support VLAN and Link Aggregation according to
|
||||
IEEE standards 802.1, 802.1q, and 802.3ad.
|
||||
Those features are available only after installation of open source modules
|
||||
which can be found on the Internet:
|
||||
|
||||
.PP
|
||||
.IR VLAN \c
|
||||
:
|
||||
.UR http://www.candelatech.com\:/~greear\:/vlan.html
|
||||
|
@ -164,7 +164,7 @@ which can be found on the Internet:
|
|||
:
|
||||
.UR http://www.st.rim.or.jp\:/~yumo
|
||||
.UE
|
||||
|
||||
.PP
|
||||
.br
|
||||
Note that Marvell/SysKonnect does not offer any support for these
|
||||
open source modules and does not take the responsibility for any
|
||||
|
@ -305,7 +305,7 @@ or
|
|||
.I SymOrRem
|
||||
is the default.
|
||||
The different modes have the following meaning:
|
||||
|
||||
.IP
|
||||
.br
|
||||
.I Sym
|
||||
= Symmetric
|
||||
|
@ -322,7 +322,7 @@ The different modes have the following meaning:
|
|||
.I None
|
||||
= None
|
||||
no link partner is allowed to send PAUSE frames
|
||||
|
||||
.IP
|
||||
Note that this parameter is ignored if AutoNeg_A is set to
|
||||
.IR Off .
|
||||
.TP
|
||||
|
@ -338,7 +338,7 @@ or
|
|||
.I SymOrRem
|
||||
is the default.
|
||||
The different modes have the following meaning:
|
||||
|
||||
.IP
|
||||
.I Sym
|
||||
= Symmetric
|
||||
both link partners are allowed to send PAUSE frames
|
||||
|
@ -355,7 +355,7 @@ The different modes have the following meaning:
|
|||
= None
|
||||
no link partner is allowed to send PAUSE frames
|
||||
.br
|
||||
|
||||
.IP
|
||||
Note that this parameter is ignored if AutoNeg_B is set to
|
||||
.IR Off .
|
||||
.TP
|
||||
|
@ -399,7 +399,7 @@ This simplifies the configuration of both ports of an adapter card.
|
|||
The different values of this variable reflect the
|
||||
most meaningful combinations of port parameters.
|
||||
Possible values and their corresponding combination of per-port parameters:
|
||||
|
||||
.IP
|
||||
.nf
|
||||
ConType | DupCap AutoNeg FlowCtrl Role Speed
|
||||
--------+-------------------------------------------
|
||||
|
@ -439,12 +439,12 @@ or
|
|||
.I None
|
||||
is the default.
|
||||
The different modes have the following meaning:
|
||||
|
||||
.IP
|
||||
.I None
|
||||
No interrupt moderation is applied on the adapter card.
|
||||
Therefore, each transmit or receive interrupt is served immediately
|
||||
as soon as it appears on the interrupt line of the adapter card.
|
||||
|
||||
.IP
|
||||
.br
|
||||
.I Static
|
||||
Interrupt moderation is applied on the adapter card.
|
||||
|
@ -459,7 +459,7 @@ regardless how much network load is currently passing via a
|
|||
particular interface.
|
||||
In addition, the duration of the moderation interval has a fixed
|
||||
length that never changes while the driver is operational.
|
||||
|
||||
.IP
|
||||
.br
|
||||
.I Dynamic
|
||||
Interrupt moderation might be applied on the adapter card,
|
||||
|
@ -470,13 +470,13 @@ load by enabling interrupt moderation.
|
|||
If\(emat a later time\(emthe CPU utilization decreases
|
||||
again (or if the network load is negligible), the interrupt
|
||||
moderation will automatically be disabled.
|
||||
|
||||
.IP
|
||||
Interrupt moderation should be used when the driver has to
|
||||
handle one or more interfaces with a high network load,
|
||||
which\(emas a consequence\(emleads also to a high CPU utilization.
|
||||
When moderation is applied in such high network load situations,
|
||||
CPU load might be reduced by 20-30% on slow computers.
|
||||
|
||||
.IP
|
||||
Note that the drawback of using interrupt moderation is an increase of
|
||||
the round-trip-time (RTT), due to the queuing and serving of
|
||||
interrupts at dedicated moderation times.
|
||||
|
@ -490,11 +490,11 @@ parameter value of 2000 will lead to an interrupt moderation interval of
|
|||
Possible values for this parameter are in the range of
|
||||
30...40000 (interrupts per second).
|
||||
The default value is 2000.
|
||||
|
||||
.IP
|
||||
This parameter is used only if either static or dynamic interrupt moderation
|
||||
is enabled on a network adapter card.
|
||||
This parameter is ignored if no moderation is applied.
|
||||
|
||||
.IP
|
||||
Note that the duration of the moderation interval is to be chosen with care.
|
||||
At first glance, selecting a very long duration (e.g., only 100 interrupts per
|
||||
second) seems to be meaningful, but the increase of packet-processing delay
|
||||
|
@ -529,12 +529,12 @@ or
|
|||
.I CheckLinkState
|
||||
is the default.
|
||||
The different modes have the following meaning:
|
||||
|
||||
.IP
|
||||
.I CheckLinkState
|
||||
Check link state only: RLMT uses the link state reported by the adapter
|
||||
hardware for each individual port to determine whether a port can be used
|
||||
for all network traffic or not.
|
||||
|
||||
.IP
|
||||
.br
|
||||
.I CheckLocalPort
|
||||
In this mode, RLMT monitors the network path between the two
|
||||
|
@ -542,7 +542,7 @@ ports of an adapter by regularly exchanging packets between them.
|
|||
This mode requires a network configuration in which the
|
||||
two ports are able to "see" each other (i.e., there
|
||||
must not be any router between the ports).
|
||||
|
||||
.IP
|
||||
.br
|
||||
.I CheckSeg
|
||||
Check local port and segmentation:
|
||||
|
@ -551,7 +551,7 @@ mode and additionally checks network segmentation between the ports.
|
|||
Therefore, this mode is to be used only if Gigabit Ethernet
|
||||
switches are installed on the network that have been
|
||||
configured to use the Spanning Tree protocol.
|
||||
|
||||
.IP
|
||||
.br
|
||||
.I DualNet
|
||||
In this mode, ports A and B are used as separate devices.
|
||||
|
@ -562,7 +562,7 @@ and port B as
|
|||
Both ports can be used independently with distinct IP addresses.
|
||||
The preferred port setting is not used.
|
||||
RLMT is turned off.
|
||||
|
||||
.IP
|
||||
Note that RLMT modes
|
||||
.I CheckLocalPort
|
||||
and
|
||||
|
|
|
@ -20,7 +20,7 @@ wavelan \- AT&T GIS WaveLAN ISA device driver
|
|||
.SH DESCRIPTION
|
||||
.I This driver is obsolete:
|
||||
it was removed from the kernel in version 2.6.35.
|
||||
|
||||
.PP
|
||||
.I wavelan
|
||||
is the low-level device driver for the NCR / AT&T / Lucent
|
||||
.B WaveLAN ISA
|
||||
|
|
Loading…
Reference in New Issue