redonkable
/
alistair23-linux
1
0
Fork 0
Code Releases Activity

Merge branch 'linux-2.6' into for-linus

hifive-unleashed-5.1
Paul Mackerras 2006-12-04 15:59:07 +11:00
parent 19a79859e1 2b5f6dcce5
commit 79acbb3ff2
2661 changed files with 91558 additions and 34729 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.gitignore vendored
View File

@ -20,6 +20,7 @@
# Top-level generic files
#
tags
TAGS
vmlinux*
System.map
Module.symvers

11
CREDITS
View File

@ -45,7 +45,7 @@ S: Longford, Ireland
S: Sydney, Australia
N: Tigran A. Aivazian
E: tigran@veritas.com
E: tigran@aivazian.fsnet.co.uk
W: http://www.moses.uklinux.net/patches
D: BFS filesystem
D: Intel IA32 CPU microcode update support
@ -2598,6 +2598,9 @@ S: Ucitelska 1576
S: Prague 8
S: 182 00 Czech Republic
N: Rick Payne
D: RFC2385 Support for TCP
N: Barak A. Pearlmutter
E: bap@cs.unm.edu
W: http://www.cs.unm.edu/~bap/
@ -3511,14 +3514,12 @@ D: The Linux Support Team Erlangen
N: David Weinehall
E: tao@acc.umu.se
P: 1024D/DC47CA16 7ACE 0FB0 7A74 F994 9B36 E1D1 D14E 8526 DC47 CA16
W: http://www.acc.umu.se/~tao/
W: http://www.acc.umu.se/~mcalinux/
D: v2.0 kernel maintainer
D: Fixes for the NE/2-driver
D: Miscellaneous MCA-support
D: Cleanup of the Config-files
S: Axtorpsvagen 40:20
S: S-903 37 UMEA
S: Sweden
N: Matt Welsh
E: mdw@metalab.unc.edu

17
Documentation/ABI/testing/sysfs-power
View File

@ -21,7 +21,7 @@ Description:
these states.
What: /sys/power/disk
Date: August 2006
Date: September 2006
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Description:
The /sys/power/disk file controls the operating mode of the
@ -39,6 +39,19 @@ Description:
'reboot' - the memory image will be saved by the kernel and
the system will be rebooted.
Additionally, /sys/power/disk can be used to turn on one of the
two testing modes of the suspend-to-disk mechanism: 'testproc'
or 'test'. If the suspend-to-disk mechanism is in the
'testproc' mode, writing 'disk' to /sys/power/state will cause
the kernel to disable nonboot CPUs and freeze tasks, wait for 5
seconds, unfreeze tasks and enable nonboot CPUs. If it is in
the 'test' mode, writing 'disk' to /sys/power/state will cause
the kernel to disable nonboot CPUs and freeze tasks, shrink
memory, suspend devices, wait for 5 seconds, resume devices,
unfreeze tasks and enable nonboot CPUs. Then, we are able to
look in the log messages and work out, for example, which code
is being slow and which device drivers are misbehaving.
The suspend-to-disk method may be chosen by writing to this
file one of the accepted strings:
@ -46,6 +59,8 @@ Description:
'platform'
'shutdown'
'reboot'
'testproc'
'test'
It will only change to 'firmware' or 'platform' if the system
supports that.

2
Documentation/Changes
View File

@ -201,7 +201,7 @@ udev
----
udev is a userspace application for populating /dev dynamically with
only entries for devices actually present. udev replaces the basic
functionality of devfs, while allowing persistant device naming for
functionality of devfs, while allowing persistent device naming for
devices.
FUSE

2
Documentation/DMA-API.txt
View File

@ -489,7 +489,7 @@ size is the size of the area (must be multiples of PAGE_SIZE).
flags can be or'd together and are
DMA_MEMORY_MAP - request that the memory returned from
dma_alloc_coherent() be directly writeable.
dma_alloc_coherent() be directly writable.
DMA_MEMORY_IO - request that the memory returned from
dma_alloc_coherent() be addressable using read/write/memcpy_toio etc.

2
Documentation/DMA-ISA-LPC.txt
View File

@ -110,7 +110,7 @@ lock.
Once the DMA transfer is finished (or timed out) you should disable
the channel again. You should also check get_dma_residue() to make
sure that all data has been transfered.
sure that all data has been transferred.
Example:

2
Documentation/DocBook/Makefile
View File

@ -9,7 +9,7 @@
DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
procfs-guide.xml writing_usb_driver.xml \
kernel-api.xml journal-api.xml lsm.xml usb.xml \
kernel-api.xml filesystems.xml lsm.xml usb.xml \
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
genericirq.xml

256
Documentation/DocBook/journal-api.tmpl → Documentation/DocBook/filesystems.tmpl
View File

@ -2,9 +2,106 @@
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
<book id="LinuxJBDAPI">
<book id="Linux-filesystems-API">
<bookinfo>
<title>Linux Filesystems API</title>
<legalnotice>
<para>
This documentation is free software; you can redistribute
it and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later
version.
</para>
<para>
This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
</para>
<para>
You should have received a copy of the GNU General Public
License along with this program; if not, write to the Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
MA 02111-1307 USA
</para>
<para>
For more details see the file COPYING in the source
distribution of Linux.
</para>
</legalnotice>
</bookinfo>
<toc></toc>
<chapter id="vfs">
<title>The Linux VFS</title>
<sect1><title>The Filesystem types</title>
!Iinclude/linux/fs.h
</sect1>
<sect1><title>The Directory Cache</title>
!Efs/dcache.c
!Iinclude/linux/dcache.h
</sect1>
<sect1><title>Inode Handling</title>
!Efs/inode.c
!Efs/bad_inode.c
</sect1>
<sect1><title>Registration and Superblocks</title>
!Efs/super.c
</sect1>
<sect1><title>File Locks</title>
!Efs/locks.c
!Ifs/locks.c
</sect1>
<sect1><title>Other Functions</title>
!Efs/mpage.c
!Efs/namei.c
!Efs/buffer.c
!Efs/bio.c
!Efs/seq_file.c
!Efs/filesystems.c
!Efs/fs-writeback.c
!Efs/block_dev.c
</sect1>
</chapter>
<chapter id="proc">
<title>The proc filesystem</title>
<sect1><title>sysctl interface</title>
!Ekernel/sysctl.c
</sect1>
<sect1><title>proc filesystem interface</title>
!Ifs/proc/base.c
</sect1>
</chapter>
<chapter id="sysfs">
<title>The Filesystem for Exporting Kernel Objects</title>
!Efs/sysfs/file.c
!Efs/sysfs/symlink.c
!Efs/sysfs/bin.c
</chapter>
<chapter id="debugfs">
<title>The debugfs filesystem</title>
<sect1><title>debugfs interface</title>
!Efs/debugfs/inode.c
!Efs/debugfs/file.c
</sect1>
</chapter>
<chapter id="LinuxJDBAPI">
<chapterinfo>
<title>The Linux Journalling API</title>
<authorgroup>
<author>
<firstname>Roger</firstname>
@ -14,9 +111,9 @@
<email>rgammans@computer-surgery.co.uk</email>
</address>
</affiliation>
</author>
</author>
</authorgroup>
<authorgroup>
<author>
<firstname>Stephen</firstname>
@ -33,50 +130,21 @@
<year>2002</year>
<holder>Roger Gammans</holder>
</copyright>
</chapterinfo>
<legalnotice>
<para>
This documentation is free software; you can redistribute
it and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later
version.
</para>
<para>
This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the GNU General Public License for more details.
</para>
<para>
You should have received a copy of the GNU General Public
License along with this program; if not, write to the Free
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
MA 02111-1307 USA
</para>
<para>
For more details see the file COPYING in the source
distribution of Linux.
</para>
</legalnotice>
</bookinfo>
<title>The Linux Journalling API</title>
<toc></toc>
<chapter id="Overview">
<sect1>
<title>Overview</title>
<sect1>
<sect2>
<title>Details</title>
<para>
The journalling layer is easy to use. You need to
The journalling layer is easy to use. You need to
first of all create a journal_t data structure. There are
two calls to do this dependent on how you decide to allocate the physical
media on which the journal resides. The journal_init_inode() call
media on which the journal resides. The journal_init_inode() call
is for journals stored in filesystem inodes, or the journal_init_dev()
call can be use for journal stored on a raw device (in a continuous range
call can be use for journal stored on a raw device (in a continuous range
of blocks). A journal_t is a typedef for a struct pointer, so when
you are finally finished make sure you call journal_destroy() on it
to free up any used kernel memory.
@ -91,27 +159,26 @@ need to call journal_create().
<para>
Most of the time however your journal file will already have been created, but
before you load it you must call journal_wipe() to empty the journal file.
Hang on, you say , what if the filesystem wasn't cleanly umount()'d . Well, it is the
Hang on, you say , what if the filesystem wasn't cleanly umount()'d . Well, it is the
job of the client file system to detect this and skip the call to journal_wipe().
</para>
<para>
In either case the next call should be to journal_load() which prepares the
journal file for use. Note that journal_wipe(..,0) calls journal_skip_recovery()
journal file for use. Note that journal_wipe(..,0) calls journal_skip_recovery()
for you if it detects any outstanding transactions in the journal and similarly
journal_load() will call journal_recover() if necessary.
I would advise reading fs/ext3/super.c for examples on this stage.
[RGG: Why is the journal_wipe() call necessary - doesn't this needlessly
complicate the API. Or isn't a good idea for the journal layer to hide
[RGG: Why is the journal_wipe() call necessary - doesn't this needlessly
complicate the API. Or isn't a good idea for the journal layer to hide
dirty mounts from the client fs]
</para>
<para>
Now you can go ahead and start modifying the underlying
Now you can go ahead and start modifying the underlying
filesystem. Almost.
</para>
<para>
You still need to actually journal your filesystem changes, this
@ -138,10 +205,10 @@ individual buffers (blocks). Before you start to modify a buffer you
need to call journal_get_{create,write,undo}_access() as appropriate,
this allows the journalling layer to copy the unmodified data if it
needs to. After all the buffer may be part of a previously uncommitted
transaction.
transaction.
At this point you are at last ready to modify a buffer, and once
you are have done so you need to call journal_dirty_{meta,}data().
Or if you've asked for access to a buffer you now know is now longer
Or if you've asked for access to a buffer you now know is now longer
required to be pushed back on the device you can call journal_forget()
in much the same way as you might have used bforget() in the past.
</para>
@ -156,7 +223,6 @@ Then at umount time , in your put_super() (2.4) or write_super() (2.5)
you can then call journal_destroy() to clean up your in-core journal object.
</para>
<para>
Unfortunately there a couple of ways the journal layer can cause a deadlock.
The first thing to note is that each task can only have
@ -164,19 +230,19 @@ a single outstanding transaction at any one time, remember nothing
commits until the outermost journal_stop(). This means
you must complete the transaction at the end of each file/inode/address
etc. operation you perform, so that the journalling system isn't re-entered
on another journal. Since transactions can't be nested/batched
on another journal. Since transactions can't be nested/batched
across differing journals, and another filesystem other than
yours (say ext3) may be modified in a later syscall.
</para>
<para>
The second case to bear in mind is that journal_start() can
block if there isn't enough space in the journal for your transaction
The second case to bear in mind is that journal_start() can
block if there isn't enough space in the journal for your transaction
(based on the passed nblocks param) - when it blocks it merely(!) needs to
wait for transactions to complete and be committed from other tasks,
so essentially we are waiting for journal_stop(). So to avoid
wait for transactions to complete and be committed from other tasks,
so essentially we are waiting for journal_stop(). So to avoid
deadlocks you must treat journal_start/stop() as if they
were semaphores and include them in your semaphore ordering rules to prevent
were semaphores and include them in your semaphore ordering rules to prevent
deadlocks. Note that journal_extend() has similar blocking behaviour to
journal_start() so you can deadlock here just as easily as on journal_start().
</para>
@ -184,7 +250,7 @@ journal_start() so you can deadlock here just as easily as on journal_start().
<para>
Try to reserve the right number of blocks the first time. ;-). This will
be the maximum number of blocks you are going to touch in this transaction.
I advise having a look at at least ext3_jbd.h to see the basis on which
I advise having a look at at least ext3_jbd.h to see the basis on which
ext3 uses to make these decisions.
</para>
@ -193,13 +259,13 @@ Another wriggle to watch out for is your on-disk block allocation strategy.
why? Because, if you undo a delete, you need to ensure you haven't reused any
of the freed blocks in a later transaction. One simple way of doing this
is make sure any blocks you allocate only have checkpointed transactions
listed against them. Ext3 does this in ext3_test_allocatable().
listed against them. Ext3 does this in ext3_test_allocatable().
</para>
<para>
Lock is also providing through journal_{un,}lock_updates(),
ext3 uses this when it wants a window with a clean and stable fs for a moment.
eg.
eg.
</para>
<programlisting>
@ -230,19 +296,19 @@ extend it like this:-
struct journal_callback for_jbd;
// Stuff for myfs allocated together.
myfs_inode* i_commited;
}
</programlisting>
<para>
this would be useful if you needed to know when data was committed to a
this would be useful if you needed to know when data was committed to a
particular inode.
</para>
</sect1>
</sect2>
<sect1>
<title>Summary</title>
<sect2>
<title>Summary</title>
<para>
Using the journal is a matter of wrapping the different context changes,
being each mount, each modification (transaction) and each changed buffer
@ -260,15 +326,15 @@ an example.
if (clean) journal_wipe();
journal_load();
foreach(transaction) { /*transactions must be
foreach(transaction) { /*transactions must be
completed before
a syscall returns to
a syscall returns to
userspace*/
handle_t * xct=journal_start(my_jnrl);
foreach(bh) {
journal_get_{create,write,undo}_access(xact,bh);
if ( myfs_modify(bh) ) { /* returns true
if ( myfs_modify(bh) ) { /* returns true
if makes changes */
journal_dirty_{meta,}data(xact,bh);
} else {
@ -279,55 +345,57 @@ an example.
}
journal_destroy(my_jrnl);
</programlisting>
</sect1>
</sect2>
</chapter>
</sect1>
<chapter id="adt">
<sect1>
<title>Data Types</title>
<para>
<para>
The journalling layer uses typedefs to 'hide' the concrete definitions
of the structures used. As a client of the JBD layer you can
just rely on the using the pointer as a magic cookie of some sort.
Obviously the hiding is not enforced as this is 'C'.
</para>
<sect1><title>Structures</title>
!Iinclude/linux/jbd.h
</sect1>
</chapter>
<chapter id="calls">
Obviously the hiding is not enforced as this is 'C'.
</para>
<sect2><title>Structures</title>
!Iinclude/linux/jbd.h
</sect2>
</sect1>
<sect1>
<title>Functions</title>
<para>
<para>
The functions here are split into two groups those that
affect a journal as a whole, and those which are used to
manage transactions
</para>
<sect1><title>Journal Level</title>
</para>
<sect2><title>Journal Level</title>
!Efs/jbd/journal.c
!Ifs/jbd/recovery.c
</sect1>
<sect1><title>Transasction Level</title>
!Efs/jbd/transaction.c
</sect1>
</chapter>
<chapter>
</sect2>
<sect2><title>Transasction Level</title>
!Efs/jbd/transaction.c
</sect2>
</sect1>
<sect1>
<title>See also</title>
<para>
<citation>
<citation>
<ulink url="ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs/journal-design.ps.gz">
Journaling the Linux ext2fs Filesystem,LinuxExpo 98, Stephen Tweedie
Journaling the Linux ext2fs Filesystem, LinuxExpo 98, Stephen Tweedie
</ulink>
</citation>
</para>
<para>
</citation>
</para>
<para>
<citation>
<ulink url="http://olstrans.sourceforge.net/release/OLS2000-ext3/OLS2000-ext3.html">
Ext3 Journalling FileSystem , OLS 2000, Dr. Stephen Tweedie
Ext3 Journalling FileSystem, OLS 2000, Dr. Stephen Tweedie
</ulink>
</citation>
</para>
</chapter>
</para>
</sect1>
</chapter>
</book>

60
Documentation/DocBook/kernel-api.tmpl
View File

@ -182,66 +182,6 @@ X!Ilib/string.c
</sect1>
</chapter>
<chapter id="vfs">
<title>The Linux VFS</title>
<sect1><title>The Filesystem types</title>
!Iinclude/linux/fs.h
</sect1>
<sect1><title>The Directory Cache</title>
!Efs/dcache.c
!Iinclude/linux/dcache.h
</sect1>
<sect1><title>Inode Handling</title>
!Efs/inode.c
!Efs/bad_inode.c
</sect1>
<sect1><title>Registration and Superblocks</title>
!Efs/super.c
</sect1>
<sect1><title>File Locks</title>
!Efs/locks.c
!Ifs/locks.c
</sect1>
<sect1><title>Other Functions</title>
!Efs/mpage.c
!Efs/namei.c
!Efs/buffer.c
!Efs/bio.c
!Efs/seq_file.c
!Efs/filesystems.c
!Efs/fs-writeback.c
!Efs/block_dev.c
</sect1>
</chapter>
<chapter id="proc">
<title>The proc filesystem</title>
<sect1><title>sysctl interface</title>
!Ekernel/sysctl.c
</sect1>
<sect1><title>proc filesystem interface</title>
!Ifs/proc/base.c
</sect1>
</chapter>
<chapter id="sysfs">
<title>The Filesystem for Exporting Kernel Objects</title>
!Efs/sysfs/file.c
!Efs/sysfs/symlink.c
!Efs/sysfs/bin.c
</chapter>
<chapter id="debugfs">
<title>The debugfs filesystem</title>
<sect1><title>debugfs interface</title>
!Efs/debugfs/inode.c
!Efs/debugfs/file.c
</sect1>
</chapter>
<chapter id="relayfs">
<title>relay interface support</title>

3
Documentation/DocBook/writing_usb_driver.tmpl
View File

@ -345,8 +345,7 @@ static inline void skel_delete (struct usb_skel *dev)
usb_buffer_free (dev->udev, dev->bulk_out_size,
dev->bulk_out_buffer,
dev->write_urb->transfer_dma);
if (dev->write_urb != NULL)
usb_free_urb (dev->write_urb);
usb_free_urb (dev->write_urb);
kfree (dev);
}
</programlisting>

20
Documentation/HOWTO
View File

@ -395,6 +395,26 @@ bugme-janitor mailing list (every change in the bugzilla is mailed here)
Managing bug reports
--------------------
One of the best ways to put into practice your hacking skills is by fixing
bugs reported by other people. Not only you will help to make the kernel
more stable, you'll learn to fix real world problems and you will improve
your skills, and other developers will be aware of your presence. Fixing
bugs is one of the best ways to get merits among other developers, because
not many people like wasting time fixing other people's bugs.
To work in the already reported bug reports, go to http://bugzilla.kernel.org.
If you want to be advised of the future bug reports, you can subscribe to the
bugme-new mailing list (only new bug reports are mailed here) or to the
bugme-janitor mailing list (every change in the bugzilla is mailed here)
http://lists.osdl.org/mailman/listinfo/bugme-new
http://lists.osdl.org/mailman/listinfo/bugme-janitors
Mailing lists
-------------

65
Documentation/MSI-HOWTO.txt
View File

@ -219,7 +219,7 @@ into the field vector of each element contained in a second argument.
Note that the pre-assigned IOAPIC dev->irq is valid only if the device
operates in PIN-IRQ assertion mode. In MSI-X mode, any attempt at
using dev->irq by the device driver to request for interrupt service
may result unpredictabe behavior.
may result in unpredictable behavior.
For each MSI-X vector granted, a device driver is responsible for calling
other functions like request_irq(), enable_irq(), etc. to enable
@ -470,7 +470,68 @@ LOC: 324553 325068
ERR: 0
MIS: 0
6. FAQ
6. MSI quirks
Several PCI chipsets or devices are known to not support MSI.
The PCI stack provides 3 possible levels of MSI disabling:
* on a single device
* on all devices behind a specific bridge
* globally
6.1. Disabling MSI on a single device
Under some circumstances, it might be required to disable MSI on a
single device, It may be achived by either not calling pci_enable_msi()
or all, or setting the pci_dev->no_msi flag before (most of the time
in a quirk).
6.2. Disabling MSI below a bridge
The vast majority of MSI quirks are required by PCI bridges not
being able to route MSI between busses. In this case, MSI have to be
disabled on all devices behind this bridge. It is achieves by setting
the PCI_BUS_FLAGS_NO_MSI flag in the pci_bus->bus_flags of the bridge
subordinate bus. There is no need to set the same flag on bridges that
are below the broken brigde. When pci_enable_msi() is called to enable
MSI on a device, pci_msi_supported() takes care of checking the NO_MSI
flag in all parent busses of the device.
Some bridges actually support dynamic MSI support enabling/disabling
by changing some bits in their PCI configuration space (especially
the Hypertransport chipsets such as the nVidia nForce and Serverworks
HT2000). It may then be required to update the NO_MSI flag on the
corresponding devices in the sysfs hierarchy. To enable MSI support
on device "0000:00:0e", do:
echo 1 > /sys/bus/pci/devices/0000:00:0e/msi_bus
To disable MSI support, echo 0 instead of 1. Note that it should be
used with caution since changing this value might break interrupts.
6.3. Disabling MSI globally
Some extreme cases may require to disable MSI globally on the system.
For now, the only known case is a Serverworks PCI-X chipsets (MSI are
not supported on several busses that are not all connected to the
chipset in the Linux PCI hierarchy). In the vast majority of other
cases, disabling only behind a specific bridge is enough.
For debugging purpose, the user may also pass pci=nomsi on the kernel
command-line to explicitly disable MSI globally. But, once the appro-
priate quirks are added to the kernel, this option should not be
required anymore.
6.4. Finding why MSI cannot be enabled on a device
Assuming that MSI are not enabled on a device, you should look at
dmesg to find messages that quirks may output when disabling MSI
on some devices, some bridges or even globally.
Then, lspci -t gives the list of bridges above a device. Reading
/sys/bus/pci/devices/0000:00:0e/msi_bus will tell you whether MSI
are enabled (1) or disabled (0). In 0 is found in a single bridge
msi_bus file above the device, MSI cannot be enabled.
7. FAQ
Q1. Are there any limitations on using the MSI?

2
Documentation/accounting/getdelays.c
View File

@ -49,7 +49,7 @@ __u64 stime, utime;
}
/* Maximum size of response requested or message sent */
#define MAX_MSG_SIZE 256
#define MAX_MSG_SIZE 1024
/* Maximum number of cpus expected to be specified in a cpumask */
#define MAX_CPUS 32
/* Maximum length of pathname to log file */

10
Documentation/accounting/taskstats.txt
View File

@ -96,9 +96,9 @@ a) TASKSTATS_TYPE_AGGR_PID/TGID : attribute containing no payload but indicates
a pid/tgid will be followed by some stats.
b) TASKSTATS_TYPE_PID/TGID: attribute whose payload is the pid/tgid whose stats
is being returned.
are being returned.
c) TASKSTATS_TYPE_STATS: attribute with a struct taskstsats as payload. The
c) TASKSTATS_TYPE_STATS: attribute with a struct taskstats as payload. The
same structure is used for both per-pid and per-tgid stats.
3. New message sent by kernel whenever a task exits. The payload consists of a
@ -122,12 +122,12 @@ of atomicity).
However, maintaining per-process, in addition to per-task stats, within the
kernel has space and time overheads. To address this, the taskstats code
accumalates each exiting task's statistics into a process-wide data structure.
When the last task of a process exits, the process level data accumalated also
accumulates each exiting task's statistics into a process-wide data structure.
When the last task of a process exits, the process level data accumulated also
gets sent to userspace (along with the per-task data).
When a user queries to get per-tgid data, the sum of all other live threads in
the group is added up and added to the accumalated total for previously exited
the group is added up and added to the accumulated total for previously exited
threads of the same thread group.
Extending taskstats

10
Documentation/block/biodoc.txt
View File

@ -183,7 +183,7 @@ it, the pci dma mapping routines and associated data structures have now been
modified to accomplish a direct page -> bus translation, without requiring
a virtual address mapping (unlike the earlier scheme of virtual address
-> bus translation). So this works uniformly for high-memory pages (which
do not have a correponding kernel virtual address space mapping) and
do not have a corresponding kernel virtual address space mapping) and
low-memory pages.
Note: Please refer to DMA-mapping.txt for a discussion on PCI high mem DMA
@ -391,7 +391,7 @@ forced such requests to be broken up into small chunks before being passed
on to the generic block layer, only to be merged by the i/o scheduler
when the underlying device was capable of handling the i/o in one shot.
Also, using the buffer head as an i/o structure for i/os that didn't originate
from the buffer cache unecessarily added to the weight of the descriptors
from the buffer cache unnecessarily added to the weight of the descriptors
which were generated for each such chunk.
The following were some of the goals and expectations considered in the
@ -403,14 +403,14 @@ i. Should be appropriate as a descriptor for both raw and buffered i/o -
for raw i/o.
ii. Ability to represent high-memory buffers (which do not have a virtual
address mapping in kernel address space).
iii.Ability to represent large i/os w/o unecessarily breaking them up (i.e
iii.Ability to represent large i/os w/o unnecessarily breaking them up (i.e
greater than PAGE_SIZE chunks in one shot)
iv. At the same time, ability to retain independent identity of i/os from
different sources or i/o units requiring individual completion (e.g. for
latency reasons)
v. Ability to represent an i/o involving multiple physical memory segments
(including non-page aligned page fragments, as specified via readv/writev)
without unecessarily breaking it up, if the underlying device is capable of
without unnecessarily breaking it up, if the underlying device is capable of
handling it.
vi. Preferably should be based on a memory descriptor structure that can be
passed around different types of subsystems or layers, maybe even
@ -1013,7 +1013,7 @@ Characteristics:
i. Binary tree
AS and deadline i/o schedulers use red black binary trees for disk position
sorting and searching, and a fifo linked list for time-based searching. This
gives good scalability and good availablility of information. Requests are
gives good scalability and good availability of information. Requests are
almost always dispatched in disk sort order, so a cache is kept of the next
request in sort order to prevent binary tree lookups.

4
Documentation/cpu-freq/cpufreq-nforce2.txt
View File

@ -1,7 +1,7 @@
The cpufreq-nforce2 driver changes the FSB on nVidia nForce2 plattforms.
The cpufreq-nforce2 driver changes the FSB on nVidia nForce2 platforms.
This works better than on other plattforms, because the FSB of the CPU
This works better than on other platforms, because the FSB of the CPU
can be controlled independently from the PCI/AGP clock.
The module has two options:

144
Documentation/cpu-hotplug.txt
View File

@ -46,7 +46,7 @@ maxcpus=n Restrict boot time cpus to n. Say if you have 4 cpus, using
maxcpus=2 will only boot 2. You can choose to bring the
other cpus later online, read FAQ's for more info.
additional_cpus*=n Use this to limit hotpluggable cpus. This option sets
additional_cpus=n (*) Use this to limit hotpluggable cpus. This option sets
cpu_possible_map = cpu_present_map + additional_cpus
(*) Option valid only for following architectures
@ -54,8 +54,8 @@ additional_cpus*=n Use this to limit hotpluggable cpus. This option sets
ia64 and x86_64 use the number of disabled local apics in ACPI tables MADT
to determine the number of potentially hot-pluggable cpus. The implementation
should only rely on this to count the #of cpus, but *MUST* not rely on the
apicid values in those tables for disabled apics. In the event BIOS doesnt
should only rely on this to count the # of cpus, but *MUST* not rely on the
apicid values in those tables for disabled apics. In the event BIOS doesn't
mark such hot-pluggable cpus as disabled entries, one could use this
parameter "additional_cpus=x" to represent those cpus in the cpu_possible_map.
@ -101,15 +101,15 @@ cpu_possible_map/for_each_possible_cpu() to iterate.
Never use anything other than cpumask_t to represent bitmap of CPUs.
#include <linux/cpumask.h>
#include <linux/cpumask.h>
for_each_possible_cpu - Iterate over cpu_possible_map
for_each_online_cpu - Iterate over cpu_online_map
for_each_present_cpu - Iterate over cpu_present_map
for_each_cpu_mask(x,mask) - Iterate over some random collection of cpu mask.
for_each_possible_cpu - Iterate over cpu_possible_map
for_each_online_cpu - Iterate over cpu_online_map
for_each_present_cpu - Iterate over cpu_present_map
for_each_cpu_mask(x,mask) - Iterate over some random collection of cpu mask.
#include <linux/cpu.h>
lock_cpu_hotplug() and unlock_cpu_hotplug():
#include <linux/cpu.h>
lock_cpu_hotplug() and unlock_cpu_hotplug():
The above calls are used to inhibit cpu hotplug operations. While holding the
cpucontrol mutex, cpu_online_map will not change. If you merely need to avoid
@ -120,7 +120,7 @@ will work as long as stop_machine_run() is used to take a cpu down.
CPU Hotplug - Frequently Asked Questions.
Q: How to i enable my kernel to support CPU hotplug?
Q: How to enable my kernel to support CPU hotplug?
A: When doing make defconfig, Enable CPU hotplug support
"Processor type and Features" -> Support for Hotpluggable CPUs
@ -141,39 +141,39 @@ A: You should now notice an entry in sysfs.
Check if sysfs is mounted, using the "mount" command. You should notice
an entry as shown below in the output.
....
none on /sys type sysfs (rw)
....
....
none on /sys type sysfs (rw)
....
if this is not mounted, do the following.
If this is not mounted, do the following.
#mkdir /sysfs
#mount -t sysfs sys /sys
#mkdir /sysfs
#mount -t sysfs sys /sys
now you should see entries for all present cpu, the following is an example
Now you should see entries for all present cpu, the following is an example
in a 8-way system.
#pwd
#/sys/devices/system/cpu
#ls -l
total 0
drwxr-xr-x 10 root root 0 Sep 19 07:44 .
drwxr-xr-x 13 root root 0 Sep 19 07:45 ..
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu0
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu1
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu2
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu3
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu4
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu5
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu6
drwxr-xr-x 3 root root 0 Sep 19 07:48 cpu7
#pwd
#/sys/devices/system/cpu
#ls -l
total 0
drwxr-xr-x 10 root root 0 Sep 19 07:44 .
drwxr-xr-x 13 root root 0 Sep 19 07:45 ..
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu0
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu1
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu2
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu3
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu4
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu5
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu6
drwxr-xr-x 3 root root 0 Sep 19 07:48 cpu7
Under each directory you would find an "online" file which is the control
file to logically online/offline a processor.
Q: Does hot-add/hot-remove refer to physical add/remove of cpus?
A: The usage of hot-add/remove may not be very consistently used in the code.
CONFIG_CPU_HOTPLUG enables logical online/offline capability in the kernel.
CONFIG_HOTPLUG_CPU enables logical online/offline capability in the kernel.
To support physical addition/removal, one would need some BIOS hooks and
the platform should have something like an attention button in PCI hotplug.
CONFIG_ACPI_HOTPLUG_CPU enables ACPI support for physical add/remove of CPUs.
@ -181,17 +181,17 @@ CONFIG_ACPI_HOTPLUG_CPU enables ACPI support for physical add/remove of CPUs.
Q: How do i logically offline a CPU?
A: Do the following.
#echo 0 > /sys/devices/system/cpu/cpuX/online
#echo 0 > /sys/devices/system/cpu/cpuX/online
once the logical offline is successful, check
Once the logical offline is successful, check
#cat /proc/interrupts
#cat /proc/interrupts
you should now not see the CPU that you removed. Also online file will report
You should now not see the CPU that you removed. Also online file will report
the state as 0 when a cpu if offline and 1 when its online.
#To display the current cpu state.
#cat /sys/devices/system/cpu/cpuX/online
#To display the current cpu state.
#cat /sys/devices/system/cpu/cpuX/online
Q: Why cant i remove CPU0 on some systems?
A: Some architectures may have some special dependency on a certain CPU.
@ -234,8 +234,8 @@ Q: If i have some kernel code that needs to be aware of CPU arrival and
departure, how to i arrange for proper notification?
A: This is what you would need in your kernel code to receive notifications.
#include <linux/cpu.h>
static int __cpuinit foobar_cpu_callback(struct notifier_block *nfb,
#include <linux/cpu.h>
static int __cpuinit foobar_cpu_callback(struct notifier_block *nfb,
unsigned long action, void *hcpu)
{
unsigned int cpu = (unsigned long)hcpu;
@ -279,10 +279,10 @@ Q: I don't see my action being called for all CPUs already up and running?
A: Yes, CPU notifiers are called only when new CPUs are on-lined or offlined.
If you need to perform some action for each cpu already in the system, then
for_each_online_cpu(i) {
for_each_online_cpu(i) {
foobar_cpu_callback(&foobar_cpu_notifier, CPU_UP_PREPARE, i);
foobar_cpu_callback(&foobar-cpu_notifier, CPU_ONLINE, i);
}
foobar_cpu_callback(&foobar_cpu_notifier, CPU_ONLINE, i);
}
Q: If i would like to develop cpu hotplug support for a new architecture,
what do i need at a minimum?
@ -307,38 +307,38 @@ Q: I need to ensure that a particular cpu is not removed when there is some
work specific to this cpu is in progress.
A: First switch the current thread context to preferred cpu
int my_func_on_cpu(int cpu)
{
cpumask_t saved_mask, new_mask = CPU_MASK_NONE;
int curr_cpu, err = 0;
int my_func_on_cpu(int cpu)
{
cpumask_t saved_mask, new_mask = CPU_MASK_NONE;
int curr_cpu, err = 0;
saved_mask = current->cpus_allowed;
cpu_set(cpu, new_mask);
err = set_cpus_allowed(current, new_mask);
saved_mask = current->cpus_allowed;
cpu_set(cpu, new_mask);
err = set_cpus_allowed(current, new_mask);
if (err)
return err;
if (err)
return err;
/*
* If we got scheduled out just after the return from
* set_cpus_allowed() before running the work, this ensures
* we stay locked.
*/
curr_cpu = get_cpu();
/*
* If we got scheduled out just after the return from
* set_cpus_allowed() before running the work, this ensures
* we stay locked.
*/
curr_cpu = get_cpu();
if (curr_cpu != cpu) {
err = -EAGAIN;
goto ret;
} else {
/*
* Do work : But cant sleep, since get_cpu() disables preempt
*/
}
ret:
put_cpu();
set_cpus_allowed(current, saved_mask);
return err;
}
if (curr_cpu != cpu) {
err = -EAGAIN;
goto ret;
} else {
/*
* Do work : But cant sleep, since get_cpu() disables preempt
*/
}
ret:
put_cpu();
set_cpus_allowed(current, saved_mask);
return err;
}
Q: How do we determine how many CPUs are available for hotplug.

8
Documentation/devices.txt
View File

@ -92,7 +92,7 @@ Your cooperation is appreciated.
7 = /dev/full Returns ENOSPC on write
8 = /dev/random Nondeterministic random number gen.
9 = /dev/urandom Faster, less secure random number gen.
10 = /dev/aio Asyncronous I/O notification interface
10 = /dev/aio Asynchronous I/O notification interface
11 = /dev/kmsg Writes to this come out as printk's
1 block RAM disk
0 = /dev/ram0 First RAM disk
@ -1093,7 +1093,7 @@ Your cooperation is appreciated.
55 char DSP56001 digital signal processor
0 = /dev/dsp56k First DSP56001
55 block Mylex DAC960 PCI RAID controller; eigth controller
55 block Mylex DAC960 PCI RAID controller; eighth controller
0 = /dev/rd/c7d0 First disk, whole disk
8 = /dev/rd/c7d1 Second disk, whole disk
...
@ -1456,7 +1456,7 @@ Your cooperation is appreciated.
1 = /dev/cum1 Callout device for ttyM1
...
79 block Compaq Intelligent Drive Array, eigth controller
79 block Compaq Intelligent Drive Array, eighth controller
0 = /dev/ida/c7d0 First logical drive whole disk
16 = /dev/ida/c7d1 Second logical drive whole disk
...
@ -1900,7 +1900,7 @@ Your cooperation is appreciated.
1 = /dev/av1 Second A/V card
...
111 block Compaq Next Generation Drive Array, eigth controller
111 block Compaq Next Generation Drive Array, eighth controller
0 = /dev/cciss/c7d0 First logical drive, whole disk
16 = /dev/cciss/c7d1 Second logical drive, whole disk
...

184
Documentation/driver-model/platform.txt
View File

@ -1,99 +1,131 @@
Platform Devices and Drivers
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
See <linux/platform_device.h> for the driver model interface to the
platform bus: platform_device, and platform_driver. This pseudo-bus
is used to connect devices on busses with minimal infrastructure,
like those used to integrate peripherals on many system-on-chip
processors, or some "legacy" PC interconnects; as opposed to large
formally specified ones like PCI or USB.
Platform devices
~~~~~~~~~~~~~~~~
Platform devices are devices that typically appear as autonomous
entities in the system. This includes legacy port-based devices and
host bridges to peripheral buses.
host bridges to peripheral buses, and most controllers integrated
into system-on-chip platforms. What they usually have in common
is direct addressing from a CPU bus. Rarely, a platform_device will
be connected through a segment of some other kind of bus; but its
registers will still be directly addressible.
Platform devices are given a name, used in driver binding, and a
list of resources such as addresses and IRQs.
struct platform_device {
const char *name;
u32 id;
struct device dev;
u32 num_resources;
struct resource *resource;
};
Platform drivers
~~~~~~~~~~~~~~~~
Drivers for platform devices are typically very simple and
unstructured. Either the device was present at a particular I/O port
and the driver was loaded, or it was not. There was no possibility
of hotplugging or alternative discovery besides probing at a specific
I/O address and expecting a specific response.
Platform drivers follow the standard driver model convention, where
discovery/enumeration is handled outside the drivers, and drivers
provide probe() and remove() methods. They support power management
and shutdown notifications using the standard conventions.
struct platform_driver {
int (*probe)(struct platform_device *);
int (*remove)(struct platform_device *);
void (*shutdown)(struct platform_device *);
int (*suspend)(struct platform_device *, pm_message_t state);
int (*suspend_late)(struct platform_device *, pm_message_t state);
int (*resume_early)(struct platform_device *);
int (*resume)(struct platform_device *);
struct device_driver driver;
};
Note that probe() should general verify that the specified device hardware
actually exists; sometimes platform setup code can't be sure. The probing
can use device resources, including clocks, and device platform_data.
Platform drivers register themselves the normal way:
int platform_driver_register(struct platform_driver *drv);
Or, in common situations where the device is known not to be hot-pluggable,
the probe() routine can live in an init section to reduce the driver's
runtime memory footprint:
int platform_driver_probe(struct platform_driver *drv,
int (*probe)(struct platform_device *))
Other Architectures, Modern Firmware, and new Platforms
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
These devices are not always at the legacy I/O ports. This is true on
other architectures and on some modern architectures. In most cases,
the drivers are modified to discover the devices at other well-known
ports for the given platform. However, the firmware in these systems
does usually know where exactly these devices reside, and in some
cases, it's the only way of discovering them.
Device Enumeration
~~~~~~~~~~~~~~~~~~
As a rule, platform specific (and often board-specific) setup code wil
register platform devices:
int platform_device_register(struct platform_device *pdev);
int platform_add_devices(struct platform_device **pdevs, int ndev);
The general rule is to register only those devices that actually exist,
but in some cases extra devices might be registered. For example, a kernel
might be configured to work with an external network adapter that might not
be populated on all boards, or likewise to work with an integrated controller
that some boards might not hook up to any peripherals.
In some cases, boot firmware will export tables describing the devices
that are populated on a given board. Without such tables, often the
only way for system setup code to set up the correct devices is to build
a kernel for a specific target board. Such board-specific kernels are
common with embedded and custom systems development.
In many cases, the memory and IRQ resources associated with the platform
device are not enough to let the device's driver work. Board setup code
will often provide additional information using the device's platform_data
field to hold additional information.
Embedded systems frequently need one or more clocks for platform devices,
which are normally kept off until they're actively needed (to save power).
System setup also associates those clocks with the device, so that that
calls to clk_get(&pdev->dev, clock_name) return them as needed.
The Platform Bus
~~~~~~~~~~~~~~~~
A platform bus has been created to deal with these issues. First and
foremost, it groups all the legacy devices under a common bus, and
gives them a common parent if they don't already have one.
Device Naming and Driver Binding
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The platform_device.dev.bus_id is the canonical name for the devices.
It's built from two components:
But, besides the organizational benefits, the platform bus can also
accommodate firmware-based enumeration.
* platform_device.name ... which is also used to for driver matching.
* platform_device.id ... the device instance number, or else "-1"
to indicate there's only one.
Device Discovery
~~~~~~~~~~~~~~~~
The platform bus has no concept of probing for devices. Devices
discovery is left up to either the legacy drivers or the
firmware. These entities are expected to notify the platform of
devices that it discovers via the bus's add() callback:
These are catenated, so name/id "serial"/0 indicates bus_id "serial.0", and
"serial/3" indicates bus_id "serial.3"; both would use the platform_driver
named "serial". While "my_rtc"/-1 would be bus_id "my_rtc" (no instance id)
and use the platform_driver called "my_rtc".
platform_bus.add(parent,bus_id).
Driver binding is performed automatically by the driver core, invoking
driver probe() after finding a match between device and driver. If the
probe() succeeds, the driver and device are bound as usual. There are
three different ways to find such a match:
- Whenever a device is registered, the drivers for that bus are
checked for matches. Platform devices should be registered very
early during system boot.
Bus IDs
~~~~~~~
Bus IDs are the canonical names for the devices. There is no globally
standard addressing mechanism for legacy devices. In the IA-32 world,
we have Pnp IDs to use, as well as the legacy I/O ports. However,
neither tell what the device really is or have any meaning on other
platforms.
- When a driver is registered using platform_driver_register(), all
unbound devices on that bus are checked for matches. Drivers
usually register later during booting, or by module loading.
Since both PnP IDs and the legacy I/O ports (and other standard I/O
ports for specific devices) have a 1:1 mapping, we map the
platform-specific name or identifier to a generic name (at least
within the scope of the kernel).
For example, a serial driver might find a device at I/O 0x3f8. The
ACPI firmware might also discover a device with PnP ID (_HID)
PNP0501. Both correspond to the same device and should be mapped to the
canonical name 'serial'.
The bus_id field should be a concatenation of the canonical name and
the instance of that type of device. For example, the device at I/O
port 0x3f8 should have a bus_id of "serial0". This places the
responsibility of enumerating devices of a particular type up to the
discovery mechanism. But, they are the entity that should know best
(as opposed to the platform bus driver).
Drivers
~~~~~~~
Drivers for platform devices should have a name that is the same as
the canonical name of the devices they support. This allows the
platform bus driver to do simple matching with the basic data
structures to determine if a driver supports a certain device.
For example, a legacy serial driver should have a name of 'serial' and
register itself with the platform bus.
Driver Binding
~~~~~~~~~~~~~~
Legacy drivers assume they are bound to the device once they start up
and probe an I/O port. Divorcing them from this will be a difficult
process. However, that shouldn't prevent us from implementing
firmware-based enumeration.
The firmware should notify the platform bus about devices before the
legacy drivers have had a chance to load. Once the drivers are loaded,
they driver model core will attempt to bind the driver to any
previously-discovered devices. Once that has happened, it will be free
to discover any other devices it pleases.
- Registering a driver using platform_driver_probe() works just like
using platform_driver_register(), except that the the driver won't
be probed later if another device registers. (Which is OK, since
this interface is only for use with non-hotpluggable devices.)

2
Documentation/driver-model/porting.txt
View File

@ -92,7 +92,7 @@ struct device represents a single device. It mainly contains metadata
describing the relationship the device has to other entities.
- Embedd a struct device in the bus-specific device type.
- Embed a struct device in the bus-specific device type.
struct pci_dev {

4
Documentation/dvb/ci.txt
View File

@ -71,7 +71,7 @@ eliminating the need for any additional ioctls.
The disadvantage is that the driver/hardware has to manage the rest. For
the application programmer it would be as simple as sending/receiving an
array to/from the CI ioctls as defined in the Linux DVB API. No changes
have been made in the API to accomodate this feature.
have been made in the API to accommodate this feature.
* Why the need for another CI interface ?
@ -102,7 +102,7 @@ This CI interface follows the CI high level interface, which is not
implemented by most applications. Hence this area is revisited.
This CI interface is quite different in the case that it tries to
accomodate all other CI based devices, that fall into the other categories
accommodate all other CI based devices, that fall into the other categories.
This means that this CI interface handles the EN50221 style tags in the
Application layer only and no session management is taken care of by the

2
Documentation/eisa.txt
View File

@ -62,7 +62,7 @@ res : root device I/O resource
bus_base_addr : slot 0 address on this bus
slots : max slot number to probe
force_probe : Probe even when slot 0 is empty (no EISA mainboard)
dma_mask : Default DMA mask. Usualy the bridge device dma_mask.
dma_mask : Default DMA mask. Usually the bridge device dma_mask.
bus_nr : unique bus id, set by eisa_root_register
** Driver :

50
Documentation/feature-removal-schedule.txt
View File

@ -53,18 +53,6 @@ Who: Mauro Carvalho Chehab <mchehab@brturbo.com.br>
---------------------------
What: sys_sysctl
When: January 2007
Why: The same information is available through /proc/sys and that is the
interface user space prefers to use. And there do not appear to be
any existing user in user space of sys_sysctl. The additional
maintenance overhead of keeping a set of binary names gets
in the way of doing a good job of maintaining this interface.
Who: Eric Biederman <ebiederm@xmission.com>
---------------------------
What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
When: November 2005
Files: drivers/pcmcia/: pcmcia_ioctl.c
@ -82,18 +70,6 @@ Who: Dominik Brodowski <linux@brodo.de>
---------------------------
What: ip_queue and ip6_queue (old ipv4-only and ipv6-only netfilter queue)
When: December 2005
Why: This interface has been obsoleted by the new layer3-independent
"nfnetlink_queue". The Kernel interface is compatible, so the old
ip[6]tables "QUEUE" targets still work and will transparently handle
all packets into nfnetlink queue number 0. Userspace users will have
to link against API-compatible library on top of libnfnetlink_queue
instead of the current 'libipq'.
Who: Harald Welte <laforge@netfilter.org>
---------------------------
What: remove EXPORT_SYMBOL(kernel_thread)
When: August 2006
Files: arch/*/kernel/*_ksyms.c
@ -239,23 +215,8 @@ Who: Patrick McHardy <kaber@trash.net>
---------------------------
What: frame diverter
When: November 2006
Why: The frame diverter is included in most distribution kernels, but is
broken. It does not correctly handle many things:
- IPV6
- non-linear skb's
- network device RCU on removal
- input frames not correctly checked for protocol errors
It also adds allocation overhead even if not enabled.
It is not clear if anyone is still using it.
Who: Stephen Hemminger <shemminger@osdl.org>
---------------------------
What: PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment
When: Oktober 2008
When: October 2008
Why: The stacking of class devices makes these values misleading and
inconsistent.
Class devices should not carry any of these properties, and bus
@ -280,3 +241,12 @@ Why: Orphaned for ages. SMP bugs long unfixed. Few users left
Who: Jeff Garzik <jeff@garzik.org>
---------------------------
What: IPv4 only connection tracking/NAT/helpers
When: 2.6.22
Why: The new layer 3 independant connection tracking replaces the old
IPv4 only version. After some stabilization of the new code the
old one will be removed.
Who: Patrick McHardy <kaber@trash.net>
---------------------------

2
Documentation/filesystems/adfs.txt
View File

@ -3,7 +3,7 @@ Mount options for ADFS
uid=nnn All files in the partition will be owned by
user id nnn. Default 0 (root).
gid=nnn All files in the partition willbe in group
gid=nnn All files in the partition will be in group
nnn. Default 0 (root).
ownmask=nnn The permission mask for ADFS 'owner' permissions
will be nnn. Default 0700.

4
Documentation/filesystems/configfs/configfs.txt
View File

@ -209,7 +209,7 @@ will happen for write(2).
[struct config_group]
A config_item cannot live in a vaccum. The only way one can be created
A config_item cannot live in a vacuum. The only way one can be created
is via mkdir(2) on a config_group. This will trigger creation of a
child item.
@ -275,7 +275,7 @@ directory is not empty.
[struct configfs_subsystem]
A subsystem must register itself, ususally at module_init time. This
A subsystem must register itself, usually at module_init time. This
tells configfs to make the subsystem appear in the file tree.
struct configfs_subsystem {

4
Documentation/filesystems/fuse.txt
View File

@ -111,7 +111,7 @@ For each connection the following files exist within this directory:
'waiting'
The number of requests which are waiting to be transfered to
The number of requests which are waiting to be transferred to
userspace or being processed by the filesystem daemon. If there is
no filesystem activity and 'waiting' is non-zero, then the
filesystem is hung or deadlocked.
@ -136,7 +136,7 @@ following will happen:
2) If the request is not yet sent to userspace AND the signal is not
fatal, then an 'interrupted' flag is set for the request. When
the request has been successfully transfered to userspace and
the request has been successfully transferred to userspace and
this flag is set, an INTERRUPT request is queued.
3) If the request is already sent to userspace, then an INTERRUPT

2
Documentation/filesystems/hpfs.txt
View File

@ -274,7 +274,7 @@ History
Fixed race-condition in buffer code - it is in all filesystems in Linux;
when reading device (cat /dev/hda) while creating files on it, files
could be damaged
2.02 Woraround for bug in breada in Linux. breada could cause accesses beyond
2.02 Workaround for bug in breada in Linux. breada could cause accesses beyond
end of partition
2.03 Char, block devices and pipes are correctly created
Fixed non-crashing race in unlink (Alexander Viro)

4
Documentation/filesystems/ntfs.txt
View File

@ -337,7 +337,7 @@ Finally, for a mirrored volume, i.e. raid level 1, the table would look like
this (note all values are in 512-byte sectors):
--- cut here ---
# Ofs Size Raid Log Number Region Should Number Source Start Taget Start
# Ofs Size Raid Log Number Region Should Number Source Start Target Start
# in of the type type of log size sync? of Device in Device in
# vol volume params mirrors Device Device
0 2056320 mirror core 2 16 nosync 2 /dev/hda1 0 /dev/hdb1 0
@ -599,7 +599,7 @@ Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog.
- Major bug fixes for reading files and volumes in corner cases which
were being hit by Windows 2k/XP users.
2.1.2:
- Major bug fixes aleviating the hangs in statfs experienced by some
- Major bug fixes alleviating the hangs in statfs experienced by some
users.
2.1.1:
- Update handling of compressed files so people no longer get the

2
Documentation/filesystems/ocfs2.txt
View File

@ -30,7 +30,7 @@ Caveats
Features which OCFS2 does not support yet:
- sparse files
- extended attributes
- shared writeable mmap
- shared writable mmap
- loopback is supported, but data written will not
be cluster coherent.
- quotas

10
Documentation/filesystems/proc.txt
View File

@ -1220,9 +1220,9 @@ applications are using mlock(), or if you are running with no swap then
you probably should increase the lower_zone_protection setting.
The units of this tunable are fairly vague. It is approximately equal
to "megabytes". So setting lower_zone_protection=100 will protect around 100
to "megabytes," so setting lower_zone_protection=100 will protect around 100
megabytes of the lowmem zone from user allocations. It will also make
those 100 megabytes unavaliable for use by applications and by
those 100 megabytes unavailable for use by applications and by
pagecache, so there is a cost.
The effects of this tunable may be observed by monitoring
@ -1538,10 +1538,10 @@ TCP settings
tcp_ecn
-------
This file controls the use of the ECN bit in the IPv4 headers, this is a new
This file controls the use of the ECN bit in the IPv4 headers. This is a new
feature about Explicit Congestion Notification, but some routers and firewalls
block trafic that has this bit set, so it could be necessary to echo 0 to
/proc/sys/net/ipv4/tcp_ecn, if you want to talk to this sites. For more info
block traffic that has this bit set, so it could be necessary to echo 0 to
/proc/sys/net/ipv4/tcp_ecn if you want to talk to these sites. For more info
you could read RFC2481.
tcp_retrans_collapse

2
Documentation/filesystems/spufs.txt
View File

@ -210,7 +210,7 @@ FILES
/signal2
The two signal notification channels of an SPU. These are read-write
files that operate on a 32 bit word. Writing to one of these files
triggers an interrupt on the SPU. The value writting to the signal
triggers an interrupt on the SPU. The value written to the signal
files can be read from the SPU through a channel read or from host user
space through the file. After the value has been read by the SPU, it
is reset to zero. The possible operations on an open signal1 or sig-

13
Documentation/filesystems/udf.txt
View File

@ -7,8 +7,17 @@ If you encounter problems with reading UDF discs using this driver,
please report them to linux_udf@hpesjro.fc.hp.com, which is the
developer's list.
Write support requires a block driver which supports writing. The current
scsi and ide cdrom drivers do not support writing.
Write support requires a block driver which supports writing. Currently
dvd+rw drives and media support true random sector writes, and so a udf
filesystem on such devices can be directly mounted read/write. CD-RW
media however, does not support this. Instead the media can be formatted
for packet mode using the utility cdrwtool, then the pktcdvd driver can
be bound to the underlying cd device to provide the required buffering
and read-modify-write cycles to allow the filesystem random sector writes
while providing the hardware with only full packet writes. While not
required for dvd+rw media, use of the pktcdvd driver often enhances
performance due to very poor read-modify-write support supplied internally
by drive firmware.
-------------------------------------------------------------------------------
The following mount options are supported:

2
Documentation/fujitsu/frv/gdbstub.txt
View File

@ -59,7 +59,7 @@ the following things on the "Kernel Hacking" tab:
Then build as usual, download to the board and execute. Note that if
"Immediate activation" was selected, then the kernel will wait for GDB to
attach. If not, then the kernel will boot immediately and GDB will have to
interupt it or wait for an exception to occur if before doing anything with
interrupt it or wait for an exception to occur before doing anything with
the kernel.

2
Documentation/fujitsu/frv/kernel-ABI.txt
View File

@ -156,7 +156,7 @@ with the main kernel in this regard. Hence the debug mode code (gdbstub) is
almost completely self-contained. The only external code used is the
sprintf family of functions.
Futhermore, break.S is so complicated because single-step mode does not
Furthermore, break.S is so complicated because single-step mode does not
switch off on entry to an exception. That means unless manually disabled,
single-stepping will blithely go on stepping into things like interrupts.
See gdbstub.txt for more information.

2
Documentation/hwmon/adm9240
View File

@ -24,7 +24,7 @@ Authors:
Frodo Looijaard <frodol@dds.nl>,
Philip Edelbrock <phil@netroedge.com>,
Michiel Rook <michiel@grendelproject.nl>,
Grant Coady <gcoady@gmail.com> with guidance
Grant Coady <gcoady.lk@gmail.com> with guidance
from Jean Delvare <khali@linux-fr.org>
Interface

2
Documentation/hwmon/f71805f
View File

@ -17,7 +17,7 @@ Thanks to Kris Chen from Fintek for answering technical questions and
providing additional documentation.
Thanks to Chris Lin from Jetway for providing wiring schematics and
anwsering technical questions.
answering technical questions.
Description

13
Documentation/hwmon/k8temp
View File

@ -2,7 +2,7 @@ Kernel driver k8temp
====================
Supported chips:
* AMD K8 CPU
* AMD Athlon64/FX or Opteron CPUs
Prefix: 'k8temp'
Addresses scanned: PCI space
Datasheet: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/32559.pdf
@ -13,10 +13,13 @@ Contact: Rudolf Marek <r.marek@sh.cvut.cz>
Description
-----------
This driver permits reading temperature sensor(s) embedded inside AMD K8 CPUs.
Official documentation says that it works from revision F of K8 core, but
in fact it seems to be implemented for all revisions of K8 except the first
two revisions (SH-B0 and SH-B3).
This driver permits reading temperature sensor(s) embedded inside AMD K8
family CPUs (Athlon64/FX, Opteron). Official documentation says that it works
from revision F of K8 core, but in fact it seems to be implemented for all
revisions of K8 except the first two revisions (SH-B0 and SH-B3).
Please note that you will need at least lm-sensors 2.10.1 for proper userspace
support.
There can be up to four temperature sensors inside single CPU. The driver
will auto-detect the sensors and will display only temperatures from

4
Documentation/hwmon/smsc47m1
View File

@ -2,12 +2,14 @@ Kernel driver smsc47m1
======================
Supported chips:
* SMSC LPC47B27x, LPC47M10x, LPC47M13x, LPC47M14x, LPC47M15x and LPC47M192
* SMSC LPC47B27x, LPC47M112, LPC47M10x, LPC47M13x, LPC47M14x,
LPC47M15x and LPC47M192
Addresses scanned: none, address read from Super I/O config space
Prefix: 'smsc47m1'
Datasheets:
http://www.smsc.com/main/datasheets/47b27x.pdf
http://www.smsc.com/main/datasheets/47m10x.pdf
http://www.smsc.com/main/datasheets/47m112.pdf
http://www.smsc.com/main/tools/discontinued/47m13x.pdf
http://www.smsc.com/main/datasheets/47m14x.pdf
http://www.smsc.com/main/tools/discontinued/47m15x.pdf

6
Documentation/hwmon/w83627ehf
View File

@ -26,7 +26,7 @@ fan control mode).
Temperatures are measured in degrees Celsius and measurement resolution is 1
degC for temp1 and 0.5 degC for temp2 and temp3. An alarm is triggered when
the temperature gets higher than high limit; it stays on until the temperature
falls below the Hysteresis value.
falls below the hysteresis value.
Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan
@ -67,9 +67,9 @@ Thermal Cruise mode
If the temperature is in the range defined by:
pwm[1-4]_target - set target temperature, unit millidegree Celcius
pwm[1-4]_target - set target temperature, unit millidegree Celsius
(range 0 - 127000)
pwm[1-4]_tolerance - tolerance, unit millidegree Celcius (range 0 - 15000)
pwm[1-4]_tolerance - tolerance, unit millidegree Celsius (range 0 - 15000)
there are no changes to fan speed. Once the temperature leaves the interval,
fan speed increases (temp is higher) or decreases if lower than desired.

2
Documentation/ide.txt
View File

@ -390,5 +390,5 @@ mlord@pobox.com
Wed Apr 17 22:52:44 CEST 2002 edited by Marcin Dalecki, the current
maintainer.
Wed Aug 20 22:31:29 CEST 2003 updated ide boot uptions to current ide.c
Wed Aug 20 22:31:29 CEST 2003 updated ide boot options to current ide.c
comments at 2.6.0-test4 time. Maciej Soltysiak <solt@dns.toxicfilms.tv>

4
Documentation/input/amijoy.txt
View File

@ -91,8 +91,8 @@ JOY1DAT Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0 X7 X6 X5 X4 X3 X2 X1 X0
| 1 | M0HQ | JOY0DAT Horizontal Clock (quadrature) |
| 2 | M0V | JOY0DAT Vertical Clock |
| 3 | M0VQ | JOY0DAT Vertical Clock (quadrature) |
| 4 | M1V | JOY1DAT Horizontall Clock |
| 5 | M1VQ | JOY1DAT Horizontall Clock (quadrature) |
| 4 | M1V | JOY1DAT Horizontal Clock |
| 5 | M1VQ | JOY1DAT Horizontal Clock (quadrature) |
| 6 | M1V | JOY1DAT Vertical Clock |
| 7 | M1VQ | JOY1DAT Vertical Clock (quadrature) |
+--------+----------+-----------------------------------------+

12
Documentation/input/atarikbd.txt
View File

@ -103,7 +103,7 @@ LEFT=0x74 & RIGHT=0x75).
5.1 Joystick Event Reporting
In this mode, the ikbd generates a record whever the joystick position is
In this mode, the ikbd generates a record whenever the joystick position is
changed (i.e. for each opening or closing of a joystick switch or trigger).
The joystick event record is two bytes of the form:
@ -277,8 +277,8 @@ default to 1 at RESET (or power-up).
9.7 SET MOUSE SCALE
0x0C
X ; horizontal mouse ticks per internel X
Y ; vertical mouse ticks per internel Y
X ; horizontal mouse ticks per internal X
Y ; vertical mouse ticks per internal Y
This command sets the scale factor for the ABSOLUTE MOUSE POSITIONING mode.
In this mode, the specified number of mouse phase changes ('clicks') must
@ -323,7 +323,7 @@ mouse position.
0x0F
This command makes the origin of the Y axis to be at the bottom of the
logical coordinate system internel to the ikbd for all relative or absolute
logical coordinate system internal to the ikbd for all relative or absolute
mouse motion. This causes mouse motion toward the user to be negative in sign
and away from the user to be positive.
@ -597,8 +597,8 @@ mode or FIRE BUTTON MONITORING mode.
10. SCAN CODES
The key scan codes return by the ikbd are chosen to simplify the
implementaion of GSX.
The key scan codes returned by the ikbd are chosen to simplify the
implementation of GSX.
GSX Standard Keyboard Mapping.

115
Documentation/input/xpad.txt
View File

@ -3,20 +3,37 @@ xpad - Linux USB driver for X-Box gamepads
This is the very first release of a driver for X-Box gamepads.
Basically, this was hacked away in just a few hours, so don't expect
miracles.
In particular, there is currently NO support for the rumble pack.
You won't find many ff-aware linux applications anyway.
0. Status
---------
0. Notes
--------
For now, this driver has only been tested on just one Linux-Box.
This one is running a 2.4.18 kernel with usb-uhci on an amd athlon 600.
Driver updated for kernel 2.6.17.11. (Based on a patch for 2.6.11.4.)
The jstest-program from joystick-1.2.15 (jstest-version 2.1.0) reports
8 axes and 10 buttons.
The number of buttons/axes reported varies based on 3 things:
- if you are using a known controller
- if you are using a known dance pad
- if using an unknown device (one not listed below), what you set in the
module configuration for "Map D-PAD to buttons rather than axes for unknown
pads" (module option dpad_to_buttons)
Alls 8 axes work, though they all have the same range (-32768..32767)
If you set dpad_to_buttons to 0 and you are using an unknown device (one
not listed below), the driver will map the directional pad to axes (X/Y),
if you said N it will map the d-pad to buttons, which is needed for dance
style games to function correctly. The default is Y.
dpad_to_buttons has no effect for known pads.
0.1 Normal Controllers
----------------------
With a normal controller, the directional pad is mapped to its own X/Y axes.
The jstest-program from joystick-1.2.15 (jstest-version 2.1.0) will report 8
axes and 10 buttons.
All 8 axes work, though they all have the same range (-32768..32767)
and the zero-setting is not correct for the triggers (I don't know if that
is some limitation of jstest, since the input device setup should be fine. I
didn't have a look at jstest itself yet).
@ -30,16 +47,50 @@ in game functionality were OK. However, I find it rather difficult to
play first person shooters with a pad. Your mileage may vary.
0.2 Xbox Dance Pads
-------------------
When using a known dance pad, jstest will report 6 axes and 14 buttons.
For dance style pads (like the redoctane pad) several changes
have been made. The old driver would map the d-pad to axes, resulting
in the driver being unable to report when the user was pressing both
left+right or up+down, making DDR style games unplayable.
Known dance pads automatically map the d-pad to buttons and will work
correctly out of the box.
If your dance pad is recognized by the driver but is using axes instead
of buttons, see section 0.3 - Unknown Controllers
I've tested this with Stepmania, and it works quite well.
0.3 Unkown Controllers
----------------------
If you have an unkown xbox controller, it should work just fine with
the default settings.
HOWEVER if you have an unknown dance pad not listed below, it will not
work UNLESS you set "dpad_to_buttons" to 1 in the module configuration.
PLEASE if you have an unkown controller, email Dom <binary1230@yahoo.com> with
a dump from /proc/bus/usb and a description of the pad (manufacturer, country,
whether it is a dance pad or normal controller) so that we can add your pad
to the list of supported devices, ensuring that it will work out of the
box in the future.
1. USB adapter
--------------
Before you can actually use the driver, you need to get yourself an
adapter cable to connect the X-Box controller to your Linux-Box.
adapter cable to connect the X-Box controller to your Linux-Box. You
can buy these online fairly cheap, or build your own.
Such a cable is pretty easy to build. The Controller itself is a USB compound
device (a hub with three ports for two expansion slots and the controller
device) with the only difference in a nonstandard connector (5 pins vs. 4 on
standard USB connector).
Such a cable is pretty easy to build. The Controller itself is a USB
compound device (a hub with three ports for two expansion slots and
the controller device) with the only difference in a nonstandard connector
(5 pins vs. 4 on standard USB connector).
You just need to solder a USB connector onto the cable and keep the
yellow wire unconnected. The other pins have the same order on both
@ -51,36 +102,36 @@ original one. You can buy an extension cable and cut that instead. That way,
you can still use the controller with your X-Box, if you have one ;)
2. driver installation
2. Driver Installation
----------------------
Once you have the adapter cable and the controller is connected, you need
to load your USB subsystem and should cat /proc/bus/usb/devices.
There should be an entry like the one at the end [4].
Currently (as of version 0.0.4), the following three devices are included:
Currently (as of version 0.0.6), the following devices are included:
original Microsoft XBOX controller (US), vendor=0x045e, product=0x0202
smaller Microsoft XBOX controller (US), vendor=0x045e, product=0x0289
original Microsoft XBOX controller (Japan), vendor=0x045e, product=0x0285
InterAct PowerPad Pro (Germany), vendor=0x05fd, product=0x107a
RedOctane Xbox Dance Pad (US), vendor=0x0c12, product=0x8809
If you have another controller that is not listed above and is not recognized
by the driver, please drop me a line with the appropriate info (that is, include
the name, vendor and product ID, as well as the country where you bought it;
sending the whole dump out of /proc/bus/usb/devices along would be even better).
The driver should work with xbox pads not listed above as well, however
you will need to do something extra for dance pads to work.
In theory, the driver should work with other controllers than mine
(InterAct PowerPad pro, bought in Germany) just fine, but I cannot test this
for I only have this one controller.
If you have a controller not listed above, see 0.3 - Unknown Controllers
If you compiled and installed the driver, test the functionality:
> modprobe xpad
> modprobe joydev
> jstest /dev/js0
There should be a single line showing 18 inputs (8 axes, 10 buttons), and
it's values should change if you move the sticks and push the buttons.
If you're using a normal controller, there should be a single line showing
18 inputs (8 axes, 10 buttons), and its values should change if you move
the sticks and push the buttons. If you're using a dance pad, it should
show 20 inputs (6 axes, 14 buttons).
It works? Voila, your done ;)
It works? Voila, you're done ;)
3. Thanks
@ -111,6 +162,22 @@ I: If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=(none)
E: Ad=81(I) Atr=03(Int.) MxPS= 32 Ivl= 10ms
E: Ad=02(O) Atr=03(Int.) MxPS= 32 Ivl= 10ms
5. /proc/bus/usb/devices - dump from Redoctane Xbox Dance Pad (US):
T: Bus=01 Lev=02 Prnt=09 Port=00 Cnt=01 Dev#= 10 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0c12 ProdID=8809 Rev= 0.01
S: Product=XBOX DDR
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=58(unk. ) Sub=42 Prot=00 Driver=xpad
E: Ad=82(I) Atr=03(Int.) MxPS= 32 Ivl=4ms
E: Ad=02(O) Atr=03(Int.) MxPS= 32 Ivl=4ms
--
Marko Friedemann <mfr@bmx-chemnitz.de>
2002-07-16
- original doc
Dominic Cerquetti <binary1230@yahoo.com>
2005-03-19
- added stuff for dance pads, new d-pad->axes mappings

2
Documentation/input/yealink.txt
View File

@ -134,7 +134,7 @@ Reading /sys/../lineX will return the format string with its current value:
888888888888
Linux Rocks!
Writing to /sys/../lineX will set the coresponding LCD line.
Writing to /sys/../lineX will set the corresponding LCD line.
- Excess characters are ignored.
- If less characters are written than allowed, the remaining digits are
unchanged.

2
Documentation/ioctl/cdrom.txt
View File

@ -735,7 +735,7 @@ CDROM_DISC_STATUS Get disc type, etc.
Ok, this is where problems start. The current interface for
the CDROM_DISC_STATUS ioctl is flawed. It makes the false
assumption that CDs are all CDS_DATA_1 or all CDS_AUDIO, etc.
Unfortunatly, while this is often the case, it is also
Unfortunately, while this is often the case, it is also
very common for CDs to have some tracks with data, and some
tracks with audio. Just because I feel like it, I declare
the following to be the best way to cope. If the CD has

10
Documentation/kbuild/makefiles.txt
View File

@ -227,9 +227,9 @@ more details, with real examples.
be included in a library, lib.a.
All objects listed with lib-y are combined in a single
library for that directory.
Objects that are listed in obj-y and additionaly listed in
lib-y will not be included in the library, since they will anyway
be accessible.
Objects that are listed in obj-y and additionally listed in
lib-y will not be included in the library, since they will
be accessible anyway.
For consistency, objects listed in lib-m will be included in lib.a.
Note that the same kbuild makefile may list files to be built-in
@ -535,7 +535,7 @@ Both possibilities are described in the following.
Host programs can be made up based on composite objects.
The syntax used to define composite objects for host programs is
similar to the syntax used for kernel objects.
$(<executeable>-objs) lists all objects used to link the final
$(<executable>-objs) lists all objects used to link the final
executable.
Example:
@ -1022,7 +1022,7 @@ When kbuild executes, the following steps are followed (roughly):
In this example, there are two possible targets, requiring different
options to the linker. The linker options are specified using the
LDFLAGS_$@ syntax - one for each potential target.
$(targets) are assinged all potential targets, by which kbuild knows
$(targets) are assigned all potential targets, by which kbuild knows
the targets and will:
1) check for commandline changes
2) delete target during make clean

2
Documentation/kernel-doc-nano-HOWTO.txt
View File

@ -17,7 +17,7 @@ are:
special place-holders for where the extracted documentation should
go.
- scripts/docproc.c
- scripts/basic/docproc.c
This is a program for converting SGML template files into SGML
files. When a file is referenced it is searched for symbols

9
Documentation/kernel-parameters.txt
View File

@ -164,6 +164,10 @@ and is between 256 and 4096 characters. It is defined in the file
acpi_skip_timer_override [HW,ACPI]
Recognize and ignore IRQ0/pin2 Interrupt Override.
For broken nForce2 BIOS resulting in XT-PIC timer.
acpi_use_timer_override [HW,ACPI}
Use timer override. For some broken Nvidia NF5 boards
that require a timer override, but don't have
HPET
acpi_dbg_layer= [HW,ACPI]
Format: <int>
@ -1231,6 +1235,11 @@ and is between 256 and 4096 characters. It is defined in the file
machine check when some devices' config space
is read. But various workarounds are disabled
and some IOMMU drivers will not work.
bfsort Sort PCI devices into breadth-first order.
This sorting is done to get a device
order compatible with older (<= 2.4) kernels.
nobfsort Don't sort PCI devices into breadth-first order.
pcmv= [HW,PCMCIA] BadgePAD 4
pd. [PARIDE]

2
Documentation/keys.txt
View File

@ -304,7 +304,7 @@ about the status of the key service:
R Revoked
D Dead
Q Contributes to user's quota
U Under contruction by callback to userspace
U Under construction by callback to userspace
N Negative key
This file must be enabled at kernel configuration time as it allows anyone

5
Documentation/kprobes.txt
View File

@ -442,9 +442,10 @@ static int __init kprobe_init(void)
kp.fault_handler = handler_fault;
kp.symbol_name = "do_fork";
if ((ret = register_kprobe(&kp) < 0)) {
ret = register_kprobe(&kp);
if (ret < 0) {
printk("register_kprobe failed, returned %d\n", ret);
return -1;
return ret;
}
printk("kprobe registered\n");
return 0;

8
Documentation/laptop-mode.txt
View File

@ -121,7 +121,7 @@ contains the following options:
MAX_AGE:
Maximum time, in seconds, of hard drive spindown time that you are
confortable with. Worst case, it's possible that you could lose this
comfortable with. Worst case, it's possible that you could lose this
amount of work if your battery fails while you're in laptop mode.
MINIMUM_BATTERY_MINUTES:
@ -235,7 +235,7 @@ It should be installed as /etc/default/laptop-mode on Debian, and as
--------------------CONFIG FILE BEGIN-------------------------------------------
# Maximum time, in seconds, of hard drive spindown time that you are
# confortable with. Worst case, it's possible that you could lose this
# comfortable with. Worst case, it's possible that you could lose this
# amount of work if your battery fails you while in laptop mode.
#MAX_AGE=600
@ -350,7 +350,7 @@ fi
# set defaults instead:
# Maximum time, in seconds, of hard drive spindown time that you are
# confortable with. Worst case, it's possible that you could lose this
# comfortable with. Worst case, it's possible that you could lose this
# amount of work if your battery fails you while in laptop mode.
MAX_AGE=${MAX_AGE:-'600'}
@ -699,7 +699,7 @@ ACPI integration
Dax Kelson submitted this so that the ACPI acpid daemon will
kick off the laptop_mode script and run hdparm. The part that
automatically disables laptop mode when the battery is low was
writen by Jan Topinski.
written by Jan Topinski.
-----------------/etc/acpi/events/ac_adapter BEGIN------------------------------
event=ac_adapter

6
Documentation/memory-barriers.txt
View File

@ -212,7 +212,7 @@ There are some minimal guarantees that may be expected of a CPU:
STORE *X = c, d = LOAD *X
(Loads and stores overlap if they are targetted at overlapping pieces of
(Loads and stores overlap if they are targeted at overlapping pieces of
memory).
And there are a number of things that _must_ or _must_not_ be assumed:
@ -1016,7 +1016,7 @@ There are some more advanced barrier functions:
(*) set_mb(var, value)
This assigns the value to the variable and then inserts at least a write
This assigns the value to the variable and then inserts a full memory
barrier after it, depending on the function. It isn't guaranteed to
insert anything more than a compiler barrier in a UP compilation.
@ -1898,7 +1898,7 @@ queue before processing any further requests:
smp_wmb();
<A:modify v=2> <C:busy>
<C:queue v=2>
p = &b; q = p;
p = &v; q = p;
<D:request p>
<B:modify p=&v> <D:commit p=&v>
<D:read p>

49
Documentation/mips/time.README
View File

@ -38,19 +38,14 @@ The new time code provide the following services:
a) Implements functions required by Linux common code:
time_init
do_gettimeofday
do_settimeofday
b) provides an abstraction of RTC and null RTC implementation as default.
extern unsigned long (*rtc_get_time)(void);
extern int (*rtc_set_time)(unsigned long);
c) a set of gettimeoffset functions for different CPUs and different
needs.
d) high-level and low-level timer interrupt routines where the timer
interrupt source may or may not be the CPU timer. The high-level
routine is dispatched through do_IRQ() while the low-level is
c) high-level and low-level timer interrupt routines where the timer
interrupt source may or may not be the CPU timer. The high-level
routine is dispatched through do_IRQ() while the low-level is
dispatched in assemably code (usually int-handler.S)
@ -63,7 +58,7 @@ the following functions or values:
a) board_time_init - a function pointer. Invoked at the beginnig of
time_init(). It is optional.
1. (optional) set up RTC routines
2. (optional) calibrate and set the mips_counter_frequency
2. (optional) calibrate and set the mips_hpt_frequency
b) plat_timer_setup - a function pointer. Invoked at the end of time_init()
1. (optional) over-ride any decisions made in time_init()
@ -72,9 +67,8 @@ the following functions or values:
c) (optional) board-specific RTC routines.
d) (optional) mips_counter_frequency - It must be definied if the board
is using CPU counter for timer interrupt or it is using fixed rate
gettimeoffset().
d) (optional) mips_hpt_frequency - It must be definied if the board
is using CPU counter for timer interrupt.
PORTING GUIDE
@ -89,22 +83,12 @@ Step 1: decide how you like to implement the time services.
If the answer is no, you need a timer to provide the timer interrupt
at 100 HZ speed.
You cannot use the fast gettimeoffset functions, i.e.,
unsigned long fixed_rate_gettimeoffset(void);
unsigned long calibrate_div32_gettimeoffset(void);
unsigned long calibrate_div64_gettimeoffset(void);
You can use null_gettimeoffset() will gives the same time resolution as
jiffy. Or you can implement your own gettimeoffset (probably based on
some ad hoc hardware on your machine.)
c) The following sub steps assume your CPU has counter register.
Do you plan to use the CPU counter register as the timer interrupt
or use an exnternal timer?
In order to use CPU counter register as the timer interrupt source, you
must know the counter speed (mips_counter_frequency). It is usually the
must know the counter speed (mips_hpt_frequency). It is usually the
same as the CPU speed or an integral divisor of it.
d) decide on whether you want to use high-level or low-level timer
@ -121,10 +105,10 @@ Step 3: implement rtc routines, board_time_init() and plat_timer_setup()
if needed.
board_time_init() -
a) (optional) set up RTC routines,
b) (optional) calibrate and set the mips_counter_frequency
(only needed if you intended to use fixed_rate_gettimeoffset
or use cpu counter as timer interrupt source)
a) (optional) set up RTC routines,
b) (optional) calibrate and set the mips_hpt_frequency
(only needed if you intended to use cpu counter as timer interrupt
source)
plat_timer_setup() -
a) (optional) over-write any choices made above by time_init().
@ -154,8 +138,8 @@ for some of the functions in time.c.
For example, you may define your own timer interrupt routine, which does
some of its own processing and then calls timer_interrupt().
You can also over-ride any of the built-in functions (gettimeoffset,
RTC routines and/or timer interrupt routine).
You can also over-ride any of the built-in functions (RTC routines
and/or timer interrupt routine).
PORTING NOTES FOR SMP
@ -187,10 +171,3 @@ You need to decide on your timer interrupt sources.
You can also do the low-level version of those interrupt routines,
following similar dispatching routes described above.
Note about do_gettimeoffset():
It is very likely the CPU counter registers are not sync'ed up in a SMP box.
Therefore you cannot really use the many of the existing routines that
are based on CPU counter. You should wirte your own gettimeoffset rouinte
if you want intra-jiffy resolution.

26
Documentation/networking/NAPI_HOWTO.txt
View File

@ -95,8 +95,8 @@ There are two types of event register ACK mechanisms.
Move all to dev->poll()
C) Ability to detect new work correctly.
NAPI works by shutting down event interrupts when theres work and
turning them on when theres none.
NAPI works by shutting down event interrupts when there's work and
turning them on when there's none.
New packets might show up in the small window while interrupts were being
re-enabled (refer to appendix 2). A packet might sneak in during the period
we are enabling interrupts. We only get to know about such a packet when the
@ -114,7 +114,7 @@ Locking rules and environmental guarantees
only one CPU can pick the initial interrupt and hence the initial
netif_rx_schedule(dev);
- The core layer invokes devices to send packets in a round robin format.
This implies receive is totaly lockless because of the guarantee only that
This implies receive is totally lockless because of the guarantee that only
one CPU is executing it.
- contention can only be the result of some other CPU accessing the rx
ring. This happens only in close() and suspend() (when these methods
@ -510,7 +510,7 @@ static int my_poll (struct net_device *dev, int *budget)
an interrupt will be generated */
goto done;
}
/* done! at least thats what it looks like ;->
/* done! at least that's what it looks like ;->
if new packets came in after our last check on status bits
they'll be caught by the while check and we go back and clear them
since we havent exceeded our quota */
@ -535,11 +535,11 @@ done:
* 1. it can race with disabling irqs in irq handler (which are done to
* schedule polls)
* 2. it can race with dis/enabling irqs in other poll threads
* 3. if an irq raised after the begining of the outer beginning
* loop(marked in the code above), it will be immediately
* 3. if an irq raised after the beginning of the outer beginning
* loop (marked in the code above), it will be immediately
* triggered here.
*
* Summarizing: the logic may results in some redundant irqs both
* Summarizing: the logic may result in some redundant irqs both
* due to races in masking and due to too late acking of already
* processed irqs. The good news: no events are ever lost.
*/
@ -601,7 +601,7 @@ a)
5) dev->close() and dev->suspend() issues
==========================================
The driver writter neednt worry about this. The top net layer takes
The driver writer needn't worry about this; the top net layer takes
care of it.
6) Adding new Stats to /proc
@ -622,9 +622,9 @@ FC should be programmed to apply in the case when the system cant pull out
packets fast enough i.e send a pause only when you run out of rx buffers.
Note FC in itself is a good solution but we have found it to not be
much of a commodity feature (both in NICs and switches) and hence falls
under the same category as using NIC based mitigation. Also experiments
indicate that its much harder to resolve the resource allocation
issue (aka lazy receiving that NAPI offers) and hence quantify its usefullness
under the same category as using NIC based mitigation. Also, experiments
indicate that it's much harder to resolve the resource allocation
issue (aka lazy receiving that NAPI offers) and hence quantify its usefulness
proved harder. In any case, FC works even better with NAPI but is not
necessary.
@ -678,10 +678,10 @@ routine:
CSR5 bit of interest is only the rx status.
If you look at the last if statement:
you just finished grabbing all the packets from the rx ring .. you check if
status bit says theres more packets just in ... it says none; you then
status bit says there are more packets just in ... it says none; you then
enable rx interrupts again; if a new packet just came in during this check,
we are counting that CSR5 will be set in that small window of opportunity
and that by re-enabling interrupts, we would actually triger an interrupt
and that by re-enabling interrupts, we would actually trigger an interrupt
to register the new packet for processing.
[The above description nay be very verbose, if you have better wording

6
Documentation/networking/cs89x0.txt
View File

@ -248,7 +248,7 @@ c) The driver's hardware probe routine is designed to avoid
with device probing. To avoid this behaviour, add one
to the `io=' module parameter. This doesn't actually change
the I/O address, but it is a flag to tell the driver
topartially initialise the hardware before trying to
to partially initialise the hardware before trying to
identify the card. This could be dangerous if you are
not sure that there is a cs89x0 card at the provided address.
@ -620,8 +620,8 @@ I/O Address Device IRQ Device
12 Mouse (PS/2)
Memory Address Device 13 Math Coprocessor
-------------- --------------------- 14 Hard Disk controller
A000-BFFF EGA Graphics Adpater
A000-C7FF VGA Graphics Adpater
A000-BFFF EGA Graphics Adapter
A000-C7FF VGA Graphics Adapter
B000-BFFF Mono Graphics Adapter
B800-BFFF Color Graphics Adapter
E000-FFFF AT BIOS

84
Documentation/networking/dccp.txt
View File

@ -19,21 +19,17 @@ for real time and multimedia traffic.
It has a base protocol and pluggable congestion control IDs (CCIDs).
It is at draft RFC status and the homepage for DCCP as a protocol is at:
http://www.icir.org/kohler/dcp/
It is at experimental RFC status and the homepage for DCCP as a protocol is at:
http://www.read.cs.ucla.edu/dccp/
Missing features
================
The DCCP implementation does not currently have all the features that are in
the draft RFC.
the RFC.
In particular the following are missing:
- CCID2 support
- feature negotiation
When testing against other implementations it appears that elapsed time
options are not coded compliant to the specification.
The known bugs are at:
http://linux-net.osdl.org/index.php/TODO#DCCP
Socket options
==============
@ -47,12 +43,70 @@ the socket will fall back to 0 (which means that no meaningful service code
is present). Connecting sockets set at most one service option; for
listening sockets, multiple service codes can be specified.
DCCP_SOCKOPT_SEND_CSCOV and DCCP_SOCKOPT_RECV_CSCOV are used for setting the
partial checksum coverage (RFC 4340, sec. 9.2). The default is that checksums
always cover the entire packet and that only fully covered application data is
accepted by the receiver. Hence, when using this feature on the sender, it must
be enabled at the receiver, too with suitable choice of CsCov.
DCCP_SOCKOPT_SEND_CSCOV sets the sender checksum coverage. Values in the
range 0..15 are acceptable. The default setting is 0 (full coverage),
values between 1..15 indicate partial coverage.
DCCP_SOCKOPT_SEND_CSCOV is for the receiver and has a different meaning: it
sets a threshold, where again values 0..15 are acceptable. The default
of 0 means that all packets with a partial coverage will be discarded.
Values in the range 1..15 indicate that packets with minimally such a
coverage value are also acceptable. The higher the number, the more
restrictive this setting (see [RFC 4340, sec. 9.2.1]).
Sysctl variables
================
Several DCCP default parameters can be managed by the following sysctls
(sysctl net.dccp.default or /proc/sys/net/dccp/default):
request_retries
The number of active connection initiation retries (the number of
Requests minus one) before timing out. In addition, it also governs
the behaviour of the other, passive side: this variable also sets
the number of times DCCP repeats sending a Response when the initial
handshake does not progress from RESPOND to OPEN (i.e. when no Ack
is received after the initial Request). This value should be greater
than 0, suggested is less than 10. Analogue of tcp_syn_retries.
retries1
How often a DCCP Response is retransmitted until the listening DCCP
side considers its connecting peer dead. Analogue of tcp_retries1.
retries2
The number of times a general DCCP packet is retransmitted. This has
importance for retransmitted acknowledgments and feature negotiation,
data packets are never retransmitted. Analogue of tcp_retries2.
send_ndp = 1
Whether or not to send NDP count options (sec. 7.7.2).
send_ackvec = 1
Whether or not to send Ack Vector options (sec. 11.5).
ack_ratio = 2
The default Ack Ratio (sec. 11.3) to use.
tx_ccid = 2
Default CCID for the sender-receiver half-connection.
rx_ccid = 2
Default CCID for the receiver-sender half-connection.
seq_window = 100
The initial sequence window (sec. 7.5.2).
tx_qlen = 5
The size of the transmit buffer in packets. A value of 0 corresponds
to an unbounded transmit buffer.
Notes
=====
SELinux does not yet have support for DCCP. You will need to turn it off or
else you will get EACCES.
DCCP does not travel through NAT successfully at present. This is because
the checksum covers the psuedo-header as per TCP and UDP. It should be
relatively trivial to add Linux NAT support for DCCP.
DCCP does not travel through NAT successfully at present on many boxes. This is
because the checksum covers the psuedo-header as per TCP and UDP. Linux NAT
support for DCCP has been added.

407
Documentation/networking/e1000.txt
View File

@ -1,7 +1,7 @@
Linux* Base Driver for the Intel(R) PRO/1000 Family of Adapters
===============================================================
November 15, 2005
September 26, 2006
Contents
@ -9,6 +9,7 @@ Contents
- In This Release
- Identifying Your Adapter
- Building and Installation
- Command Line Parameters
- Speed and Duplex Configuration
- Additional Configurations
@ -41,6 +42,9 @@ or later), lspci, and ifconfig to obtain the same information.
Instructions on updating ethtool can be found in the section "Additional
Configurations" later in this document.
NOTE: The Intel(R) 82562v 10/100 Network Connection only provides 10/100
support.
Identifying Your Adapter
========================
@ -51,28 +55,27 @@ Driver ID Guide at:
http://support.intel.com/support/network/adapter/pro100/21397.htm
For the latest Intel network drivers for Linux, refer to the following
website. In the search field, enter your adapter name or type, or use the
website. In the search field, enter your adapter name or type, or use the
networking link on the left to search for your adapter:
http://downloadfinder.intel.com/scripts-df/support_intel.asp
Command Line Parameters =======================
Command Line Parameters
=======================
If the driver is built as a module, the following optional parameters
are used by entering them on the command line with the modprobe or insmod
command using this syntax:
are used by entering them on the command line with the modprobe command
using this syntax:
modprobe e1000 [<option>=<VAL1>,<VAL2>,...]
insmod e1000 [<option>=<VAL1>,<VAL2>,...]
For example, with two PRO/1000 PCI adapters, entering:
insmod e1000 TxDescriptors=80,128
modprobe e1000 TxDescriptors=80,128
loads the e1000 driver with 80 TX descriptors for the first adapter and 128
TX descriptors for the second adapter.
loads the e1000 driver with 80 TX descriptors for the first adapter and
128 TX descriptors for the second adapter.
The default value for each parameter is generally the recommended setting,
unless otherwise noted.
@ -87,7 +90,7 @@ NOTES: For more information about the AutoNeg, Duplex, and Speed
http://www.intel.com/design/network/applnots/ap450.htm
A descriptor describes a data buffer and attributes related to
the data buffer. This information is accessed by the hardware.
the data buffer. This information is accessed by the hardware.
AutoNeg
@ -96,9 +99,9 @@ AutoNeg
Valid Range: 0x01-0x0F, 0x20-0x2F
Default Value: 0x2F
This parameter is a bit mask that specifies which speed and duplex
settings the board advertises. When this parameter is used, the Speed
and Duplex parameters must not be specified.
This parameter is a bit-mask that specifies the speed and duplex settings
advertised by the adapter. When this parameter is used, the Speed and
Duplex parameters must not be specified.
NOTE: Refer to the Speed and Duplex section of this readme for more
information on the AutoNeg parameter.
@ -110,14 +113,15 @@ Duplex
Valid Range: 0-2 (0=auto-negotiate, 1=half, 2=full)
Default Value: 0
Defines the direction in which data is allowed to flow. Can be either
one or two-directional. If both Duplex and the link partner are set to
auto-negotiate, the board auto-detects the correct duplex. If the link
partner is forced (either full or half), Duplex defaults to half-duplex.
This defines the direction in which data is allowed to flow. Can be
either one or two-directional. If both Duplex and the link partner are
set to auto-negotiate, the board auto-detects the correct duplex. If the
link partner is forced (either full or half), Duplex defaults to half-
duplex.
FlowControl
----------
-----------
Valid Range: 0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx)
Default Value: Reads flow control settings from the EEPROM
@ -127,57 +131,107 @@ to Ethernet PAUSE frames.
InterruptThrottleRate
---------------------
(not supported on Intel 82542, 82543 or 82544-based adapters)
Valid Range: 100-100000 (0=off, 1=dynamic)
Default Value: 8000
(not supported on Intel(R) 82542, 82543 or 82544-based adapters)
Valid Range: 0,1,3,100-100000 (0=off, 1=dynamic, 3=dynamic conservative)
Default Value: 3
This value represents the maximum number of interrupts per second the
controller generates. InterruptThrottleRate is another setting used in
interrupt moderation. Dynamic mode uses a heuristic algorithm to adjust
InterruptThrottleRate based on the current traffic load.
The driver can limit the amount of interrupts per second that the adapter
will generate for incoming packets. It does this by writing a value to the
adapter that is based on the maximum amount of interrupts that the adapter
will generate per second.
Setting InterruptThrottleRate to a value greater or equal to 100
will program the adapter to send out a maximum of that many interrupts
per second, even if more packets have come in. This reduces interrupt
load on the system and can lower CPU utilization under heavy load,
but will increase latency as packets are not processed as quickly.
The default behaviour of the driver previously assumed a static
InterruptThrottleRate value of 8000, providing a good fallback value for
all traffic types,but lacking in small packet performance and latency.
The hardware can handle many more small packets per second however, and
for this reason an adaptive interrupt moderation algorithm was implemented.
Since 7.3.x, the driver has two adaptive modes (setting 1 or 3) in which
it dynamically adjusts the InterruptThrottleRate value based on the traffic
that it receives. After determining the type of incoming traffic in the last
timeframe, it will adjust the InterruptThrottleRate to an appropriate value
for that traffic.
The algorithm classifies the incoming traffic every interval into
classes. Once the class is determined, the InterruptThrottleRate value is
adjusted to suit that traffic type the best. There are three classes defined:
"Bulk traffic", for large amounts of packets of normal size; "Low latency",
for small amounts of traffic and/or a significant percentage of small
packets; and "Lowest latency", for almost completely small packets or
minimal traffic.
In dynamic conservative mode, the InterruptThrottleRate value is set to 4000
for traffic that falls in class "Bulk traffic". If traffic falls in the "Low
latency" or "Lowest latency" class, the InterruptThrottleRate is increased
stepwise to 20000. This default mode is suitable for most applications.
For situations where low latency is vital such as cluster or
grid computing, the algorithm can reduce latency even more when
InterruptThrottleRate is set to mode 1. In this mode, which operates
the same as mode 3, the InterruptThrottleRate will be increased stepwise to
70000 for traffic in class "Lowest latency".
Setting InterruptThrottleRate to 0 turns off any interrupt moderation
and may improve small packet latency, but is generally not suitable
for bulk throughput traffic.
NOTE: InterruptThrottleRate takes precedence over the TxAbsIntDelay and
RxAbsIntDelay parameters. In other words, minimizing the receive
RxAbsIntDelay parameters. In other words, minimizing the receive
and/or transmit absolute delays does not force the controller to
generate more interrupts than what the Interrupt Throttle Rate
allows.
CAUTION: If you are using the Intel PRO/1000 CT Network Connection
CAUTION: If you are using the Intel(R) PRO/1000 CT Network Connection
(controller 82547), setting InterruptThrottleRate to a value
greater than 75,000, may hang (stop transmitting) adapters
under certain network conditions. If this occurs a NETDEV
WATCHDOG message is logged in the system event log. In
under certain network conditions. If this occurs a NETDEV
WATCHDOG message is logged in the system event log. In
addition, the controller is automatically reset, restoring
the network connection. To eliminate the potential for the
the network connection. To eliminate the potential for the
hang, ensure that InterruptThrottleRate is set no greater
than 75,000 and is not set to 0.
NOTE: When e1000 is loaded with default settings and multiple adapters
are in use simultaneously, the CPU utilization may increase non-
linearly. In order to limit the CPU utilization without impacting
linearly. In order to limit the CPU utilization without impacting
the overall throughput, we recommend that you load the driver as
follows:
insmod e1000.o InterruptThrottleRate=3000,3000,3000
modprobe e1000 InterruptThrottleRate=3000,3000,3000
This sets the InterruptThrottleRate to 3000 interrupts/sec for
the first, second, and third instances of the driver. The range
the first, second, and third instances of the driver. The range
of 2000 to 3000 interrupts per second works on a majority of
systems and is a good starting point, but the optimal value will
be platform-specific. If CPU utilization is not a concern, use
be platform-specific. If CPU utilization is not a concern, use
RX_POLLING (NAPI) and default driver settings.
RxDescriptors
-------------
Valid Range: 80-256 for 82542 and 82543-based adapters
80-4096 for all other supported adapters
Default Value: 256
This value specifies the number of receive descriptors allocated by the
driver. Increasing this value allows the driver to buffer more incoming
packets. Each descriptor is 16 bytes. A receive buffer is also
allocated for each descriptor and is 2048.
This value specifies the number of receive buffer descriptors allocated
by the driver. Increasing this value allows the driver to buffer more
incoming packets, at the expense of increased system memory utilization.
Each descriptor is 16 bytes. A receive buffer is also allocated for each
descriptor and can be either 2048, 4096, 8192, or 16384 bytes, depending
on the MTU setting. The maximum MTU size is 16110.
NOTE: MTU designates the frame size. It only needs to be set for Jumbo
Frames. Depending on the available system resources, the request
for a higher number of receive descriptors may be denied. In this
case, use a lower number.
RxIntDelay
@ -187,17 +241,17 @@ Default Value: 0
This value delays the generation of receive interrupts in units of 1.024
microseconds. Receive interrupt reduction can improve CPU efficiency if
properly tuned for specific network traffic. Increasing this value adds
properly tuned for specific network traffic. Increasing this value adds
extra latency to frame reception and can end up decreasing the throughput
of TCP traffic. If the system is reporting dropped receives, this value
of TCP traffic. If the system is reporting dropped receives, this value
may be set too high, causing the driver to run out of available receive
descriptors.
CAUTION: When setting RxIntDelay to a value other than 0, adapters may
hang (stop transmitting) under certain network conditions. If
hang (stop transmitting) under certain network conditions. If
this occurs a NETDEV WATCHDOG message is logged in the system
event log. In addition, the controller is automatically reset,
restoring the network connection. To eliminate the potential
event log. In addition, the controller is automatically reset,
restoring the network connection. To eliminate the potential
for the hang ensure that RxIntDelay is set to 0.
@ -208,7 +262,7 @@ Valid Range: 0-65535 (0=off)
Default Value: 128
This value, in units of 1.024 microseconds, limits the delay in which a
receive interrupt is generated. Useful only if RxIntDelay is non-zero,
receive interrupt is generated. Useful only if RxIntDelay is non-zero,
this value ensures that an interrupt is generated after the initial
packet is received within the set amount of time. Proper tuning,
along with RxIntDelay, may improve traffic throughput in specific network
@ -222,9 +276,9 @@ Valid Settings: 0, 10, 100, 1000
Default Value: 0 (auto-negotiate at all supported speeds)
Speed forces the line speed to the specified value in megabits per second
(Mbps). If this parameter is not specified or is set to 0 and the link
(Mbps). If this parameter is not specified or is set to 0 and the link
partner is set to auto-negotiate, the board will auto-detect the correct
speed. Duplex should also be set when Speed is set to either 10 or 100.
speed. Duplex should also be set when Speed is set to either 10 or 100.
TxDescriptors
@ -234,7 +288,7 @@ Valid Range: 80-256 for 82542 and 82543-based adapters
Default Value: 256
This value is the number of transmit descriptors allocated by the driver.
Increasing this value allows the driver to queue more transmits. Each
Increasing this value allows the driver to queue more transmits. Each
descriptor is 16 bytes.
NOTE: Depending on the available system resources, the request for a
@ -248,8 +302,8 @@ Valid Range: 0-65535 (0=off)
Default Value: 64
This value delays the generation of transmit interrupts in units of
1.024 microseconds. Transmit interrupt reduction can improve CPU
efficiency if properly tuned for specific network traffic. If the
1.024 microseconds. Transmit interrupt reduction can improve CPU
efficiency if properly tuned for specific network traffic. If the
system is reporting dropped transmits, this value may be set too high
causing the driver to run out of available transmit descriptors.
@ -261,7 +315,7 @@ Valid Range: 0-65535 (0=off)
Default Value: 64
This value, in units of 1.024 microseconds, limits the delay in which a
transmit interrupt is generated. Useful only if TxIntDelay is non-zero,
transmit interrupt is generated. Useful only if TxIntDelay is non-zero,
this value ensures that an interrupt is generated after the initial
packet is sent on the wire within the set amount of time. Proper tuning,
along with TxIntDelay, may improve traffic throughput in specific
@ -288,15 +342,15 @@ fiber interface board only links at 1000 Mbps full-duplex.
For copper-based boards, the keywords interact as follows:
The default operation is auto-negotiate. The board advertises all
The default operation is auto-negotiate. The board advertises all
supported speed and duplex combinations, and it links at the highest
common speed and duplex mode IF the link partner is set to auto-negotiate.
If Speed = 1000, limited auto-negotiation is enabled and only 1000 Mbps
is advertised (The 1000BaseT spec requires auto-negotiation.)
If Speed = 10 or 100, then both Speed and Duplex should be set. Auto-
negotiation is disabled, and the AutoNeg parameter is ignored. Partner
If Speed = 10 or 100, then both Speed and Duplex should be set. Auto-
negotiation is disabled, and the AutoNeg parameter is ignored. Partner
SHOULD also be forced.
The AutoNeg parameter is used when more control is required over the
@ -304,7 +358,7 @@ auto-negotiation process. It should be used when you wish to control which
speed and duplex combinations are advertised during the auto-negotiation
process.
The parameter may be specified as either a decimal or hexidecimal value as
The parameter may be specified as either a decimal or hexadecimal value as
determined by the bitmap below.
Bit position 7 6 5 4 3 2 1 0
@ -337,20 +391,19 @@ Additional Configurations
Configuring the Driver on Different Distributions
-------------------------------------------------
Configuring a network driver to load properly when the system is started
is distribution dependent. Typically, the configuration process involves
is distribution dependent. Typically, the configuration process involves
adding an alias line to /etc/modules.conf or /etc/modprobe.conf as well
as editing other system startup scripts and/or configuration files. Many
as editing other system startup scripts and/or configuration files. Many
popular Linux distributions ship with tools to make these changes for you.
To learn the proper way to configure a network device for your system,
refer to your distribution documentation. If during this process you are
refer to your distribution documentation. If during this process you are
asked for the driver or module name, the name for the Linux Base Driver
for the Intel PRO/1000 Family of Adapters is e1000.
for the Intel(R) PRO/1000 Family of Adapters is e1000.
As an example, if you install the e1000 driver for two PRO/1000 adapters
(eth0 and eth1) and set the speed and duplex to 10full and 100half, add
the following to modules.conf or modprobe.conf:
the following to modules.conf or or modprobe.conf:
alias eth0 e1000
alias eth1 e1000
@ -358,9 +411,8 @@ Additional Configurations
Viewing Link Messages
---------------------
Link messages will not be displayed to the console if the distribution is
restricting system messages. In order to see network driver link messages
restricting system messages. In order to see network driver link messages
on your console, set dmesg to eight by entering the following:
dmesg -n 8
@ -369,11 +421,9 @@ Additional Configurations
Jumbo Frames
------------
The driver supports Jumbo Frames for all adapters except 82542 and
82573-based adapters. Jumbo Frames support is enabled by changing the
MTU to a value larger than the default of 1500. Use the ifconfig command
to increase the MTU size. For example:
Jumbo Frames support is enabled by changing the MTU to a value larger than
the default of 1500. Use the ifconfig command to increase the MTU size.
For example:
ifconfig eth<x> mtu 9000 up
@ -390,26 +440,49 @@ Additional Configurations
- To enable Jumbo Frames, increase the MTU size on the interface beyond
1500.
- The maximum MTU setting for Jumbo Frames is 16110. This value coincides
- The maximum MTU setting for Jumbo Frames is 16110. This value coincides
with the maximum Jumbo Frames size of 16128.
- Using Jumbo Frames at 10 or 100 Mbps may result in poor performance or
loss of link.
- Some Intel gigabit adapters that support Jumbo Frames have a frame size
limit of 9238 bytes, with a corresponding MTU size limit of 9216 bytes.
The adapters with this limitation are based on the Intel 82571EB and
82572EI controllers, which correspond to these product names:
Intel® PRO/1000 PT Dual Port Server Adapter
Intel® PRO/1000 PF Dual Port Server Adapter
Intel® PRO/1000 PT Server Adapter
Intel® PRO/1000 PT Desktop Adapter
Intel® PRO/1000 PF Server Adapter
The adapters with this limitation are based on the Intel(R) 82571EB,
82572EI, 82573L and 80003ES2LAN controller. These correspond to the
following product names:
Intel(R) PRO/1000 PT Server Adapter
Intel(R) PRO/1000 PT Desktop Adapter
Intel(R) PRO/1000 PT Network Connection
Intel(R) PRO/1000 PT Dual Port Server Adapter
Intel(R) PRO/1000 PT Dual Port Network Connection
Intel(R) PRO/1000 PF Server Adapter
Intel(R) PRO/1000 PF Network Connection
Intel(R) PRO/1000 PF Dual Port Server Adapter
Intel(R) PRO/1000 PB Server Connection
Intel(R) PRO/1000 PL Network Connection
Intel(R) PRO/1000 EB Network Connection with I/O Acceleration
Intel(R) PRO/1000 EB Backplane Connection with I/O Acceleration
Intel(R) PRO/1000 PT Quad Port Server Adapter
- The Intel PRO/1000 PM Network Connection does not support jumbo frames.
- Adapters based on the Intel(R) 82542 and 82573V/E controller do not
support Jumbo Frames. These correspond to the following product names:
Intel(R) PRO/1000 Gigabit Server Adapter
Intel(R) PRO/1000 PM Network Connection
- The following adapters do not support Jumbo Frames:
Intel(R) 82562V 10/100 Network Connection
Intel(R) 82566DM Gigabit Network Connection
Intel(R) 82566DC Gigabit Network Connection
Intel(R) 82566MM Gigabit Network Connection
Intel(R) 82566MC Gigabit Network Connection
Intel(R) 82562GT 10/100 Network Connection
Intel(R) 82562G 10/100 Network Connection
Ethtool
-------
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. Ethtool
version 1.6 or later is required for this functionality.
@ -417,15 +490,14 @@ Additional Configurations
The latest release of ethtool can be found from
http://sourceforge.net/projects/gkernel.
NOTE: Ethtool 1.6 only supports a limited set of ethtool options. Support
NOTE: Ethtool 1.6 only supports a limited set of ethtool options. Support
for a more complete ethtool feature set can be enabled by upgrading
ethtool to ethtool-1.8.1.
Enabling Wake on LAN* (WoL)
---------------------------
WoL is configured through the Ethtool* utility. Ethtool is included with
all versions of Red Hat after Red Hat 7.2. For other Linux distributions,
WoL is configured through the Ethtool* utility. Ethtool is included with
all versions of Red Hat after Red Hat 7.2. For other Linux distributions,
download and install Ethtool from the following website:
http://sourceforge.net/projects/gkernel.
@ -436,11 +508,17 @@ Additional Configurations
For this driver version, in order to enable WoL, the e1000 driver must be
loaded when shutting down or rebooting the system.
Wake On LAN is only supported on port A for the following devices:
Intel(R) PRO/1000 PT Dual Port Network Connection
Intel(R) PRO/1000 PT Dual Port Server Connection
Intel(R) PRO/1000 PT Dual Port Server Adapter
Intel(R) PRO/1000 PF Dual Port Server Adapter
Intel(R) PRO/1000 PT Quad Port Server Adapter
NAPI
----
NAPI (Rx polling mode) is supported in the e1000 driver. NAPI is enabled
or disabled based on the configuration of the kernel. To override
NAPI (Rx polling mode) is supported in the e1000 driver. NAPI is enabled
or disabled based on the configuration of the kernel. To override
the default, use the following compile-time flags.
To enable NAPI, compile the driver module, passing in a configuration option:
@ -457,88 +535,105 @@ Additional Configurations
Known Issues
============
Jumbo Frames System Requirement
-------------------------------
Dropped Receive Packets on Half-duplex 10/100 Networks
------------------------------------------------------
If you have an Intel PCI Express adapter running at 10mbps or 100mbps, half-
duplex, you may observe occasional dropped receive packets. There are no
workarounds for this problem in this network configuration. The network must
be updated to operate in full-duplex, and/or 1000mbps only.
Memory allocation failures have been observed on Linux systems with 64 MB
of RAM or less that are running Jumbo Frames. If you are using Jumbo
Frames, your system may require more than the advertised minimum
requirement of 64 MB of system memory.
Jumbo Frames System Requirement
-------------------------------
Memory allocation failures have been observed on Linux systems with 64 MB
of RAM or less that are running Jumbo Frames. If you are using Jumbo
Frames, your system may require more than the advertised minimum
requirement of 64 MB of system memory.
Performance Degradation with Jumbo Frames
-----------------------------------------
Performance Degradation with Jumbo Frames
-----------------------------------------
Degradation in throughput performance may be observed in some Jumbo frames
environments. If this is observed, increasing the application's socket
buffer size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values
may help. See the specific application manual and
/usr/src/linux*/Documentation/
networking/ip-sysctl.txt for more details.
Degradation in throughput performance may be observed in some Jumbo frames
environments. If this is observed, increasing the application's socket
buffer size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values
may help. See the specific application manual and
/usr/src/linux*/Documentation/
networking/ip-sysctl.txt for more details.
Jumbo Frames on Foundry BigIron 8000 switch
-------------------------------------------
There is a known issue using Jumbo frames when connected to a Foundry
BigIron 8000 switch. This is a 3rd party limitation. If you experience
loss of packets, lower the MTU size.
Jumbo frames on Foundry BigIron 8000 switch
-------------------------------------------
There is a known issue using Jumbo frames when connected to a Foundry
BigIron 8000 switch. This is a 3rd party limitation. If you experience
loss of packets, lower the MTU size.
Allocating Rx Buffers when Using Jumbo Frames
---------------------------------------------
Allocating Rx buffers when using Jumbo Frames on 2.6.x kernels may fail if
the available memory is heavily fragmented. This issue may be seen with PCI-X
adapters or with packet split disabled. This can be reduced or eliminated
by changing the amount of available memory for receive buffer allocation, by
increasing /proc/sys/vm/min_free_kbytes.
Multiple Interfaces on Same Ethernet Broadcast Network
------------------------------------------------------
Multiple Interfaces on Same Ethernet Broadcast Network
------------------------------------------------------
Due to the default ARP behavior on Linux, it is not possible to have
one system on two IP networks in the same Ethernet broadcast domain
(non-partitioned switch) behave as expected. All Ethernet interfaces
will respond to IP traffic for any IP address assigned to the system.
This results in unbalanced receive traffic.
Due to the default ARP behavior on Linux, it is not possible to have
one system on two IP networks in the same Ethernet broadcast domain
(non-partitioned switch) behave as expected. All Ethernet interfaces
will respond to IP traffic for any IP address assigned to the system.
This results in unbalanced receive traffic.
If you have multiple interfaces in a server, either turn on ARP
filtering by entering:
If you have multiple interfaces in a server, either turn on ARP
filtering by entering:
echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
(this only works if your kernel's version is higher than 2.4.5),
echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
(this only works if your kernel's version is higher than 2.4.5),
NOTE: This setting is not saved across reboots. The configuration
change can be made permanent by adding the line:
net.ipv4.conf.all.arp_filter = 1
to the file /etc/sysctl.conf
NOTE: This setting is not saved across reboots. The configuration
change can be made permanent by adding the line:
net.ipv4.conf.all.arp_filter = 1
to the file /etc/sysctl.conf
or,
or,
install the interfaces in separate broadcast domains (either in
different switches or in a switch partitioned to VLANs).
install the interfaces in separate broadcast domains (either in
different switches or in a switch partitioned to VLANs).
82541/82547 can't link or are slow to link with some link partners
-----------------------------------------------------------------
There is a known compatibility issue with 82541/82547 and some
low-end switches where the link will not be established, or will
be slow to establish. In particular, these switches are known to
be incompatible with 82541/82547:
82541/82547 can't link or are slow to link with some link partners
-----------------------------------------------------------------
Planex FXG-08TE
I-O Data ETG-SH8
There is a known compatibility issue with 82541/82547 and some
low-end switches where the link will not be established, or will
be slow to establish. In particular, these switches are known to
be incompatible with 82541/82547:
To workaround this issue, the driver can be compiled with an override
of the PHY's master/slave setting. Forcing master or forcing slave
mode will improve time-to-link.
Planex FXG-08TE
I-O Data ETG-SH8
# make CFLAGS_EXTRA=-DE1000_MASTER_SLAVE=<n>
To workaround this issue, the driver can be compiled with an override
of the PHY's master/slave setting. Forcing master or forcing slave
mode will improve time-to-link.
Where <n> is:
# make EXTRA_CFLAGS=-DE1000_MASTER_SLAVE=<n>
0 = Hardware default
1 = Master mode
2 = Slave mode
3 = Auto master/slave
Where <n> is:
Disable rx flow control with ethtool
------------------------------------
In order to disable receive flow control using ethtool, you must turn
off auto-negotiation on the same command line.
0 = Hardware default
1 = Master mode
2 = Slave mode
3 = Auto master/slave
For example:
Disable rx flow control with ethtool
------------------------------------
ethtool -A eth? autoneg off rx off
In order to disable receive flow control using ethtool, you must turn
off auto-negotiation on the same command line.
For example:
ethtool -A eth? autoneg off rx off
Unplugging network cable while ethtool -p is running
----------------------------------------------------
In kernel versions 2.5.50 and later (including 2.6 kernel), unplugging
the network cable while ethtool -p is running will cause the system to
become unresponsive to keyboard commands, except for control-alt-delete.
Restarting the system appears to be the only remedy.
Support
@ -548,24 +643,10 @@ For general information, go to the Intel support website at:
http://support.intel.com
or the Intel Wired Networking project hosted by Sourceforge at:
or the Intel Wired Networking project hosted by Sourceforge at:
http://sourceforge.net/projects/e1000
If an issue is identified with the released source code on the supported
kernel with a supported adapter, email the specific information related
to the issue to e1000-devel@lists.sourceforge.net
License
=======
This software program is released under the terms of a license agreement
between you ('Licensee') and Intel. Do not use or load this software or any
associated materials (collectively, the 'Software') until you have carefully
read the full terms and conditions of the file COPYING located in this software
package. By loading or using the Software, you agree to the terms of this
Agreement. If you do not agree with the terms of this Agreement, do not
install or use the Software.
* Other names and brands may be claimed as the property of others.
to the issue to e1000-devel@lists.sf.net

381
Documentation/networking/ip-sysctl.txt
View File

@ -101,6 +101,11 @@ inet_peer_gc_maxtime - INTEGER
TCP variables:
somaxconn - INTEGER
Limit of socket listen() backlog, known in userspace as SOMAXCONN.
Defaults to 128. See also tcp_max_syn_backlog for additional tuning
for TCP sockets.
tcp_abc - INTEGER
Controls Appropriate Byte Count (ABC) defined in RFC3465.
ABC is a way of increasing congestion window (cwnd) more slowly
@ -112,15 +117,68 @@ tcp_abc - INTEGER
of two segments to compensate for delayed acknowledgments.
Default: 0 (off)
tcp_syn_retries - INTEGER
Number of times initial SYNs for an active TCP connection attempt
will be retransmitted. Should not be higher than 255. Default value
is 5, which corresponds to ~180seconds.
tcp_abort_on_overflow - BOOLEAN
If listening service is too slow to accept new connections,
reset them. Default state is FALSE. It means that if overflow
occurred due to a burst, connection will recover. Enable this
option _only_ if you are really sure that listening daemon
cannot be tuned to accept connections faster. Enabling this
option can harm clients of your server.
tcp_synack_retries - INTEGER
Number of times SYNACKs for a passive TCP connection attempt will
be retransmitted. Should not be higher than 255. Default value
is 5, which corresponds to ~180seconds.
tcp_adv_win_scale - INTEGER
Count buffering overhead as bytes/2^tcp_adv_win_scale
(if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
if it is <= 0.
Default: 2
tcp_allowed_congestion_control - STRING
Show/set the congestion control choices available to non-privileged
processes. The list is a subset of those listed in
tcp_available_congestion_control.
Default is "reno" and the default setting (tcp_congestion_control).
tcp_app_win - INTEGER
Reserve max(window/2^tcp_app_win, mss) of window for application
buffer. Value 0 is special, it means that nothing is reserved.
Default: 31
tcp_available_congestion_control - STRING
Shows the available congestion control choices that are registered.
More congestion control algorithms may be available as modules,
but not loaded.
tcp_congestion_control - STRING
Set the congestion control algorithm to be used for new
connections. The algorithm "reno" is always available, but
additional choices may be available based on kernel configuration.
Default is set as part of kernel configuration.
tcp_dsack - BOOLEAN
Allows TCP to send "duplicate" SACKs.
tcp_ecn - BOOLEAN
Enable Explicit Congestion Notification in TCP.
tcp_fack - BOOLEAN
Enable FACK congestion avoidance and fast retransmission.
The value is not used, if tcp_sack is not enabled.
tcp_fin_timeout - INTEGER
Time to hold socket in state FIN-WAIT-2, if it was closed
by our side. Peer can be broken and never close its side,
or even died unexpectedly. Default value is 60sec.
Usual value used in 2.2 was 180 seconds, you may restore
it, but remember that if your machine is even underloaded WEB server,
you risk to overflow memory with kilotons of dead sockets,
FIN-WAIT-2 sockets are less dangerous than FIN-WAIT-1,
because they eat maximum 1.5K of memory, but they tend
to live longer. Cf. tcp_max_orphans.
tcp_frto - BOOLEAN
Enables F-RTO, an enhanced recovery algorithm for TCP retransmission
timeouts. It is particularly beneficial in wireless environments
where packet loss is typically due to random radio interference
rather than intermediate router congestion.
tcp_keepalive_time - INTEGER
How often TCP sends out keepalive messages when keepalive is enabled.
@ -136,54 +194,13 @@ tcp_keepalive_intvl - INTEGER
after probes started. Default value: 75sec i.e. connection
will be aborted after ~11 minutes of retries.
tcp_retries1 - INTEGER
How many times to retry before deciding that something is wrong
and it is necessary to report this suspicion to network layer.
Minimal RFC value is 3, it is default, which corresponds
to ~3sec-8min depending on RTO.
tcp_retries2 - INTEGER
How may times to retry before killing alive TCP connection.
RFC1122 says that the limit should be longer than 100 sec.
It is too small number. Default value 15 corresponds to ~13-30min
depending on RTO.
tcp_orphan_retries - INTEGER
How may times to retry before killing TCP connection, closed
by our side. Default value 7 corresponds to ~50sec-16min
depending on RTO. If you machine is loaded WEB server,
you should think about lowering this value, such sockets
may consume significant resources. Cf. tcp_max_orphans.
tcp_fin_timeout - INTEGER
Time to hold socket in state FIN-WAIT-2, if it was closed
by our side. Peer can be broken and never close its side,
or even died unexpectedly. Default value is 60sec.
Usual value used in 2.2 was 180 seconds, you may restore
it, but remember that if your machine is even underloaded WEB server,
you risk to overflow memory with kilotons of dead sockets,
FIN-WAIT-2 sockets are less dangerous than FIN-WAIT-1,
because they eat maximum 1.5K of memory, but they tend
to live longer. Cf. tcp_max_orphans.
tcp_max_tw_buckets - INTEGER
Maximal number of timewait sockets held by system simultaneously.
If this number is exceeded time-wait socket is immediately destroyed
and warning is printed. This limit exists only to prevent
simple DoS attacks, you _must_ not lower the limit artificially,
but rather increase it (probably, after increasing installed memory),
if network conditions require more than default value.
tcp_tw_recycle - BOOLEAN
Enable fast recycling TIME-WAIT sockets. Default value is 0.
It should not be changed without advice/request of technical
experts.
tcp_tw_reuse - BOOLEAN
Allow to reuse TIME-WAIT sockets for new connections when it is
safe from protocol viewpoint. Default value is 0.
It should not be changed without advice/request of technical
experts.
tcp_low_latency - BOOLEAN
If set, the TCP stack makes decisions that prefer lower
latency as opposed to higher throughput. By default, this
option is not set meaning that higher throughput is preferred.
An example of an application where this default should be
changed would be a Beowulf compute cluster.
Default: 0
tcp_max_orphans - INTEGER
Maximal number of TCP sockets not attached to any user file handle,
@ -197,41 +214,6 @@ tcp_max_orphans - INTEGER
more aggressively. Let me to remind again: each orphan eats
up to ~64K of unswappable memory.
tcp_abort_on_overflow - BOOLEAN
If listening service is too slow to accept new connections,
reset them. Default state is FALSE. It means that if overflow
occurred due to a burst, connection will recover. Enable this
option _only_ if you are really sure that listening daemon
cannot be tuned to accept connections faster. Enabling this
option can harm clients of your server.
tcp_syncookies - BOOLEAN
Only valid when the kernel was compiled with CONFIG_SYNCOOKIES
Send out syncookies when the syn backlog queue of a socket
overflows. This is to prevent against the common 'syn flood attack'
Default: FALSE
Note, that syncookies is fallback facility.
It MUST NOT be used to help highly loaded servers to stand
against legal connection rate. If you see synflood warnings
in your logs, but investigation shows that they occur
because of overload with legal connections, you should tune
another parameters until this warning disappear.
See: tcp_max_syn_backlog, tcp_synack_retries, tcp_abort_on_overflow.
syncookies seriously violate TCP protocol, do not allow
to use TCP extensions, can result in serious degradation
of some services (f.e. SMTP relaying), visible not by you,
but your clients and relays, contacting you. While you see
synflood warnings in logs not being really flooded, your server
is seriously misconfigured.
tcp_stdurg - BOOLEAN
Use the Host requirements interpretation of the TCP urg pointer field.
Most hosts use the older BSD interpretation, so if you turn this on
Linux might not communicate correctly with them.
Default: FALSE
tcp_max_syn_backlog - INTEGER
Maximal number of remembered connection requests, which are
still did not receive an acknowledgment from connecting client.
@ -239,24 +221,34 @@ tcp_max_syn_backlog - INTEGER
and 128 for low memory machines. If server suffers of overload,
try to increase this number.
tcp_window_scaling - BOOLEAN
Enable window scaling as defined in RFC1323.
tcp_max_tw_buckets - INTEGER
Maximal number of timewait sockets held by system simultaneously.
If this number is exceeded time-wait socket is immediately destroyed
and warning is printed. This limit exists only to prevent
simple DoS attacks, you _must_ not lower the limit artificially,
but rather increase it (probably, after increasing installed memory),
if network conditions require more than default value.
tcp_timestamps - BOOLEAN
Enable timestamps as defined in RFC1323.
tcp_mem - vector of 3 INTEGERs: min, pressure, max
min: below this number of pages TCP is not bothered about its
memory appetite.
tcp_sack - BOOLEAN
Enable select acknowledgments (SACKS).
pressure: when amount of memory allocated by TCP exceeds this number
of pages, TCP moderates its memory consumption and enters memory
pressure mode, which is exited when memory consumption falls
under "min".
tcp_fack - BOOLEAN
Enable FACK congestion avoidance and fast retransmission.
The value is not used, if tcp_sack is not enabled.
max: number of pages allowed for queueing by all TCP sockets.
tcp_dsack - BOOLEAN
Allows TCP to send "duplicate" SACKs.
Defaults are calculated at boot time from amount of available
memory.
tcp_ecn - BOOLEAN
Enable Explicit Congestion Notification in TCP.
tcp_orphan_retries - INTEGER
How may times to retry before killing TCP connection, closed
by our side. Default value 7 corresponds to ~50sec-16min
depending on RTO. If you machine is loaded WEB server,
you should think about lowering this value, such sockets
may consume significant resources. Cf. tcp_max_orphans.
tcp_reordering - INTEGER
Maximal reordering of packets in a TCP stream.
@ -267,20 +259,23 @@ tcp_retrans_collapse - BOOLEAN
On retransmit try to send bigger packets to work around bugs in
certain TCP stacks.
tcp_wmem - vector of 3 INTEGERs: min, default, max
min: Amount of memory reserved for send buffers for TCP socket.
Each TCP socket has rights to use it due to fact of its birth.
Default: 4K
tcp_retries1 - INTEGER
How many times to retry before deciding that something is wrong
and it is necessary to report this suspicion to network layer.
Minimal RFC value is 3, it is default, which corresponds
to ~3sec-8min depending on RTO.
default: Amount of memory allowed for send buffers for TCP socket
by default. This value overrides net.core.wmem_default used
by other protocols, it is usually lower than net.core.wmem_default.
Default: 16K
tcp_retries2 - INTEGER
How may times to retry before killing alive TCP connection.
RFC1122 says that the limit should be longer than 100 sec.
It is too small number. Default value 15 corresponds to ~13-30min
depending on RTO.
max: Maximal amount of memory allowed for automatically selected
send buffers for TCP socket. This value does not override
net.core.wmem_max, "static" selection via SO_SNDBUF does not use this.
Default: 128K
tcp_rfc1337 - BOOLEAN
If set, the TCP stack behaves conforming to RFC1337. If unset,
we are not conforming to RFC, but prevent TCP TIME_WAIT
assassination.
Default: 0
tcp_rmem - vector of 3 INTEGERs: min, default, max
min: Minimal size of receive buffer used by TCP sockets.
@ -299,74 +294,8 @@ tcp_rmem - vector of 3 INTEGERs: min, default, max
net.core.rmem_max, "static" selection via SO_RCVBUF does not use this.
Default: 87380*2 bytes.
tcp_mem - vector of 3 INTEGERs: min, pressure, max
min: below this number of pages TCP is not bothered about its
memory appetite.
pressure: when amount of memory allocated by TCP exceeds this number
of pages, TCP moderates its memory consumption and enters memory
pressure mode, which is exited when memory consumption falls
under "min".
max: number of pages allowed for queueing by all TCP sockets.
Defaults are calculated at boot time from amount of available
memory.
tcp_app_win - INTEGER
Reserve max(window/2^tcp_app_win, mss) of window for application
buffer. Value 0 is special, it means that nothing is reserved.
Default: 31
tcp_adv_win_scale - INTEGER
Count buffering overhead as bytes/2^tcp_adv_win_scale
(if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
if it is <= 0.
Default: 2
tcp_rfc1337 - BOOLEAN
If set, the TCP stack behaves conforming to RFC1337. If unset,
we are not conforming to RFC, but prevent TCP TIME_WAIT
assassination.
Default: 0
tcp_low_latency - BOOLEAN
If set, the TCP stack makes decisions that prefer lower
latency as opposed to higher throughput. By default, this
option is not set meaning that higher throughput is preferred.
An example of an application where this default should be
changed would be a Beowulf compute cluster.
Default: 0
tcp_tso_win_divisor - INTEGER
This allows control over what percentage of the congestion window
can be consumed by a single TSO frame.
The setting of this parameter is a choice between burstiness and
building larger TSO frames.
Default: 3
tcp_frto - BOOLEAN
Enables F-RTO, an enhanced recovery algorithm for TCP retransmission
timeouts. It is particularly beneficial in wireless environments
where packet loss is typically due to random radio interference
rather than intermediate router congestion.
tcp_congestion_control - STRING
Set the congestion control algorithm to be used for new
connections. The algorithm "reno" is always available, but
additional choices may be available based on kernel configuration.
somaxconn - INTEGER
Limit of socket listen() backlog, known in userspace as SOMAXCONN.
Defaults to 128. See also tcp_max_syn_backlog for additional tuning
for TCP sockets.
tcp_workaround_signed_windows - BOOLEAN
If set, assume no receipt of a window scaling option means the
remote TCP is broken and treats the window as a signed quantity.
If unset, assume the remote TCP is not broken even if we do
not receive a window scaling option from them.
Default: 0
tcp_sack - BOOLEAN
Enable select acknowledgments (SACKS).
tcp_slow_start_after_idle - BOOLEAN
If set, provide RFC2861 behavior and time out the congestion
@ -375,6 +304,89 @@ tcp_slow_start_after_idle - BOOLEAN
be timed out after an idle period.
Default: 1
tcp_stdurg - BOOLEAN
Use the Host requirements interpretation of the TCP urg pointer field.
Most hosts use the older BSD interpretation, so if you turn this on
Linux might not communicate correctly with them.
Default: FALSE
tcp_synack_retries - INTEGER
Number of times SYNACKs for a passive TCP connection attempt will
be retransmitted. Should not be higher than 255. Default value
is 5, which corresponds to ~180seconds.
tcp_syncookies - BOOLEAN
Only valid when the kernel was compiled with CONFIG_SYNCOOKIES
Send out syncookies when the syn backlog queue of a socket
overflows. This is to prevent against the common 'syn flood attack'
Default: FALSE
Note, that syncookies is fallback facility.
It MUST NOT be used to help highly loaded servers to stand
against legal connection rate. If you see synflood warnings
in your logs, but investigation shows that they occur
because of overload with legal connections, you should tune
another parameters until this warning disappear.
See: tcp_max_syn_backlog, tcp_synack_retries, tcp_abort_on_overflow.
syncookies seriously violate TCP protocol, do not allow
to use TCP extensions, can result in serious degradation
of some services (f.e. SMTP relaying), visible not by you,
but your clients and relays, contacting you. While you see
synflood warnings in logs not being really flooded, your server
is seriously misconfigured.
tcp_syn_retries - INTEGER
Number of times initial SYNs for an active TCP connection attempt
will be retransmitted. Should not be higher than 255. Default value
is 5, which corresponds to ~180seconds.
tcp_timestamps - BOOLEAN
Enable timestamps as defined in RFC1323.
tcp_tso_win_divisor - INTEGER
This allows control over what percentage of the congestion window
can be consumed by a single TSO frame.
The setting of this parameter is a choice between burstiness and
building larger TSO frames.
Default: 3
tcp_tw_recycle - BOOLEAN
Enable fast recycling TIME-WAIT sockets. Default value is 0.
It should not be changed without advice/request of technical
experts.
tcp_tw_reuse - BOOLEAN
Allow to reuse TIME-WAIT sockets for new connections when it is
safe from protocol viewpoint. Default value is 0.
It should not be changed without advice/request of technical
experts.
tcp_window_scaling - BOOLEAN
Enable window scaling as defined in RFC1323.
tcp_wmem - vector of 3 INTEGERs: min, default, max
min: Amount of memory reserved for send buffers for TCP socket.
Each TCP socket has rights to use it due to fact of its birth.
Default: 4K
default: Amount of memory allowed for send buffers for TCP socket
by default. This value overrides net.core.wmem_default used
by other protocols, it is usually lower than net.core.wmem_default.
Default: 16K
max: Maximal amount of memory allowed for automatically selected
send buffers for TCP socket. This value does not override
net.core.wmem_max, "static" selection via SO_SNDBUF does not use this.
Default: 128K
tcp_workaround_signed_windows - BOOLEAN
If set, assume no receipt of a window scaling option means the
remote TCP is broken and treats the window as a signed quantity.
If unset, assume the remote TCP is not broken even if we do
not receive a window scaling option from them.
Default: 0
CIPSOv4 Variables:
cipso_cache_enable - BOOLEAN
@ -974,4 +986,3 @@ no_cong_thresh FIXME
slot_timeout FIXME
warn_noreply_time FIXME
$Id: ip-sysctl.txt,v 1.20 2001/12/13 09:00:18 davem Exp $

2
Documentation/networking/iphase.txt
View File

@ -81,7 +81,7 @@ Installation
1M. The RAM size decides the number of buffers and buffer size. The default
size and number of buffers are set as following:
Totol Rx RAM Tx RAM Rx Buf Tx Buf Rx buf Tx buf
Total Rx RAM Tx RAM Rx Buf Tx Buf Rx buf Tx buf
RAM size size size size size cnt cnt
-------- ------ ------ ------ ------ ------ ------
128K 64K 64K 10K 10K 6 6

2
Documentation/networking/packet_mmap.txt
View File

@ -284,7 +284,7 @@ the necessary memory, so normally limits can be reached.
-------------------
If you check the source code you will see that what I draw here as a frame
is not only the link level frame. At the begining of each frame there is a
is not only the link level frame. At the beginning of each frame there is a
header called struct tpacket_hdr used in PACKET_MMAP to hold link level's frame
meta information like timestamp. So what we draw here a frame it's really
the following (from include/linux/if_packet.h):

13
Documentation/networking/phy.txt
View File

@ -1,7 +1,7 @@
-------
PHY Abstraction Layer
(Updated 2005-07-21)
(Updated 2006-11-30)
Purpose
@ -97,11 +97,12 @@ Letting the PHY Abstraction Layer do Everything
Next, you need to know the device name of the PHY connected to this device.
The name will look something like, "phy0:0", where the first number is the
bus id, and the second is the PHY's address on that bus.
bus id, and the second is the PHY's address on that bus. Typically,
the bus is responsible for making its ID unique.
Now, to connect, just call this function:
phydev = phy_connect(dev, phy_name, &adjust_link, flags);
phydev = phy_connect(dev, phy_name, &adjust_link, flags, interface);
phydev is a pointer to the phy_device structure which represents the PHY. If
phy_connect is successful, it will return the pointer. dev, here, is the
@ -115,6 +116,10 @@ Letting the PHY Abstraction Layer do Everything
This is useful if the system has put hardware restrictions on
the PHY/controller, of which the PHY needs to be aware.
interface is a u32 which specifies the connection type used
between the controller and the PHY. Examples are GMII, MII,
RGMII, and SGMII. For a full list, see include/linux/phy.h
Now just make sure that phydev->supported and phydev->advertising have any
values pruned from them which don't make sense for your controller (a 10/100
controller may be connected to a gigabit capable PHY, so you would need to
@ -191,7 +196,7 @@ Doing it all yourself
start, or disables then frees them for stop.
struct phy_device * phy_attach(struct net_device *dev, const char *phy_id,
u32 flags);
u32 flags, phy_interface_t interface);
Attaches a network device to a particular PHY, binding the PHY to a generic
driver if none was found during bus initialization. Passes in

6
Documentation/networking/pktgen.txt
View File

@ -63,8 +63,8 @@ Current:
Result: OK: 13101142(c12220741+d880401) usec, 10000000 (60byte,0frags)
763292pps 390Mb/sec (390805504bps) errors: 39664
Confguring threads and devices
==============================
Configuring threads and devices
================================
This is done via the /proc interface easiest done via pgset in the scripts
Examples:
@ -116,7 +116,7 @@ Examples:
there must be no spaces between the
arguments. Leading zeros are required.
Do not set the bottom of stack bit,
thats done automatically. If you do
that's done automatically. If you do
set the bottom of stack bit, that
indicates that you want to randomly
generate that address and the flag

2
Documentation/networking/proc_net_tcp.txt
View File

@ -25,7 +25,7 @@ up into 3 parts because of the length of the line):
1000 0 54165785 4 cd1e6040 25 4 27 3 -1
| | | | | | | | | |--> slow start size threshold,
| | | | | | | | | or -1 if the treshold
| | | | | | | | | or -1 if the threshold
| | | | | | | | | is >= 0xFFFF
| | | | | | | | |----> sending congestion window
| | | | | | | |-------> (ack.quick<<1)|ack.pingpong

2
Documentation/networking/sk98lin.txt
View File

@ -346,7 +346,7 @@ Possible modes:
depending on the load of the system. If the driver detects that the
system load is too high, the driver tries to shield the system against
too much network load by enabling interrupt moderation. If - at a later
time - the CPU utilizaton decreases again (or if the network load is
time - the CPU utilization decreases again (or if the network load is
negligible) the interrupt moderation will automatically be disabled.
Interrupt moderation should be used when the driver has to handle one or more

2
Documentation/networking/slicecom.txt
View File

@ -126,7 +126,7 @@ comx0/boardnum - board number of the SliceCom in the PC (using the 'natural'
Though the options below are to be set on a single interface, they apply to the
whole board. The restriction, to use them on 'UP' interfaces, is because the
command sequence below could lead to unpredicable results.
command sequence below could lead to unpredictable results.
# echo 0 >boardnum
# echo internal >clock_source

281
Documentation/networking/udplite.txt 100644
View File

@ -0,0 +1,281 @@
===========================================================================
The UDP-Lite protocol (RFC 3828)
===========================================================================
UDP-Lite is a Standards-Track IETF transport protocol whose characteristic
is a variable-length checksum. This has advantages for transport of multimedia
(video, VoIP) over wireless networks, as partly damaged packets can still be
fed into the codec instead of being discarded due to a failed checksum test.
This file briefly describes the existing kernel support and the socket API.
For in-depth information, you can consult:
o The UDP-Lite Homepage: http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/
Fom here you can also download some example application source code.
o The UDP-Lite HOWTO on
http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/UDP-Lite-HOWTO.txt
o The Wireshark UDP-Lite WiKi (with capture files):
http://wiki.wireshark.org/Lightweight_User_Datagram_Protocol
o The Protocol Spec, RFC 3828, http://www.ietf.org/rfc/rfc3828.txt
I) APPLICATIONS
Several applications have been ported successfully to UDP-Lite. Ethereal
(now called wireshark) has UDP-Litev4/v6 support by default. The tarball on
http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/udplite_linux.tar.gz
has source code for several v4/v6 client-server and network testing examples.
Porting applications to UDP-Lite is straightforward: only socket level and
IPPROTO need to be changed; senders additionally set the checksum coverage
length (default = header length = 8). Details are in the next section.
II) PROGRAMMING API
UDP-Lite provides a connectionless, unreliable datagram service and hence
uses the same socket type as UDP. In fact, porting from UDP to UDP-Lite is
very easy: simply add `IPPROTO_UDPLITE' as the last argument of the socket(2)
call so that the statement looks like:
s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE);
or, respectively,
s = socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDPLITE);
With just the above change you are able to run UDP-Lite services or connect
to UDP-Lite servers. The kernel will assume that you are not interested in
using partial checksum coverage and so emulate UDP mode (full coverage).
To make use of the partial checksum coverage facilities requires setting a
single socket option, which takes an integer specifying the coverage length:
* Sender checksum coverage: UDPLITE_SEND_CSCOV
For example,
int val = 20;
setsockopt(s, SOL_UDPLITE, UDPLITE_SEND_CSCOV, &val, sizeof(int));
sets the checksum coverage length to 20 bytes (12b data + 8b header).
Of each packet only the first 20 bytes (plus the pseudo-header) will be
checksummed. This is useful for RTP applications which have a 12-byte
base header.
* Receiver checksum coverage: UDPLITE_RECV_CSCOV
This option is the receiver-side analogue. It is truly optional, i.e. not
required to enable traffic with partial checksum coverage. Its function is
that of a traffic filter: when enabled, it instructs the kernel to drop
all packets which have a coverage _less_ than this value. For example, if
RTP and UDP headers are to be protected, a receiver can enforce that only
packets with a minimum coverage of 20 are admitted:
int min = 20;
setsockopt(s, SOL_UDPLITE, UDPLITE_RECV_CSCOV, &min, sizeof(int));
The calls to getsockopt(2) are analogous. Being an extension and not a stand-
alone protocol, all socket options known from UDP can be used in exactly the
same manner as before, e.g. UDP_CORK or UDP_ENCAP.
A detailed discussion of UDP-Lite checksum coverage options is in section IV.
III) HEADER FILES
The socket API requires support through header files in /usr/include:
* /usr/include/netinet/in.h
to define IPPROTO_UDPLITE
* /usr/include/netinet/udplite.h
for UDP-Lite header fields and protocol constants
For testing purposes, the following can serve as a `mini' header file:
#define IPPROTO_UDPLITE 136
#define SOL_UDPLITE 136
#define UDPLITE_SEND_CSCOV 10
#define UDPLITE_RECV_CSCOV 11
Ready-made header files for various distros are in the UDP-Lite tarball.
IV) KERNEL BEHAVIOUR WITH REGARD TO THE VARIOUS SOCKET OPTIONS
To enable debugging messages, the log level need to be set to 8, as most
messages use the KERN_DEBUG level (7).
1) Sender Socket Options
If the sender specifies a value of 0 as coverage length, the module
assumes full coverage, transmits a packet with coverage length of 0
and according checksum. If the sender specifies a coverage < 8 and
different from 0, the kernel assumes 8 as default value. Finally,
if the specified coverage length exceeds the packet length, the packet
length is used instead as coverage length.
2) Receiver Socket Options
The receiver specifies the minimum value of the coverage length it
is willing to accept. A value of 0 here indicates that the receiver
always wants the whole of the packet covered. In this case, all
partially covered packets are dropped and an error is logged.
It is not possible to specify illegal values (<0 and <8); in these
cases the default of 8 is assumed.
All packets arriving with a coverage value less than the specified
threshold are discarded, these events are also logged.
3) Disabling the Checksum Computation
On both sender and receiver, checksumming will always be performed
and can not be disabled using SO_NO_CHECK. Thus
setsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, ... );
will always will be ignored, while the value of
getsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, &value, ...);
is meaningless (as in TCP). Packets with a zero checksum field are
illegal (cf. RFC 3828, sec. 3.1) will be silently discarded.
4) Fragmentation
The checksum computation respects both buffersize and MTU. The size
of UDP-Lite packets is determined by the size of the send buffer. The
minimum size of the send buffer is 2048 (defined as SOCK_MIN_SNDBUF
in include/net/sock.h), the default value is configurable as
net.core.wmem_default or via setting the SO_SNDBUF socket(7)
option. The maximum upper bound for the send buffer is determined
by net.core.wmem_max.
Given a payload size larger than the send buffer size, UDP-Lite will
split the payload into several individual packets, filling up the
send buffer size in each case.
The precise value also depends on the interface MTU. The interface MTU,
in turn, may trigger IP fragmentation. In this case, the generated
UDP-Lite packet is split into several IP packets, of which only the
first one contains the L4 header.
The send buffer size has implications on the checksum coverage length.
Consider the following example:
Payload: 1536 bytes Send Buffer: 1024 bytes
MTU: 1500 bytes Coverage Length: 856 bytes
UDP-Lite will ship the 1536 bytes in two separate packets:
Packet 1: 1024 payload + 8 byte header + 20 byte IP header = 1052 bytes
Packet 2: 512 payload + 8 byte header + 20 byte IP header = 540 bytes
The coverage packet covers the UDP-Lite header and 848 bytes of the
payload in the first packet, the second packet is fully covered. Note
that for the second packet, the coverage length exceeds the packet
length. The kernel always re-adjusts the coverage length to the packet
length in such cases.
As an example of what happens when one UDP-Lite packet is split into
several tiny fragments, consider the following example.
Payload: 1024 bytes Send buffer size: 1024 bytes
MTU: 300 bytes Coverage length: 575 bytes
+-+-----------+--------------+--------------+--------------+
|8| 272 | 280 | 280 | 280 |
+-+-----------+--------------+--------------+--------------+
280 560 840 1032
^
*****checksum coverage*************
The UDP-Lite module generates one 1032 byte packet (1024 + 8 byte
header). According to the interface MTU, these are split into 4 IP
packets (280 byte IP payload + 20 byte IP header). The kernel module
sums the contents of the entire first two packets, plus 15 bytes of
the last packet before releasing the fragments to the IP module.
To see the analogous case for IPv6 fragmentation, consider a link
MTU of 1280 bytes and a write buffer of 3356 bytes. If the checksum
coverage is less than 1232 bytes (MTU minus IPv6/fragment header
lengths), only the first fragment needs to be considered. When using
larger checksum coverage lengths, each eligible fragment needs to be
checksummed. Suppose we have a checksum coverage of 3062. The buffer
of 3356 bytes will be split into the following fragments:
Fragment 1: 1280 bytes carrying 1232 bytes of UDP-Lite data
Fragment 2: 1280 bytes carrying 1232 bytes of UDP-Lite data
Fragment 3: 948 bytes carrying 900 bytes of UDP-Lite data
The first two fragments have to be checksummed in full, of the last
fragment only 598 (= 3062 - 2*1232) bytes are checksummed.
While it is important that such cases are dealt with correctly, they
are (annoyingly) rare: UDP-Lite is designed for optimising multimedia
performance over wireless (or generally noisy) links and thus smaller
coverage lenghts are likely to be expected.
V) UDP-LITE RUNTIME STATISTICS AND THEIR MEANING
Exceptional and error conditions are logged to syslog at the KERN_DEBUG
level. Live statistics about UDP-Lite are available in /proc/net/snmp
and can (with newer versions of netstat) be viewed using
netstat -svu
This displays UDP-Lite statistics variables, whose meaning is as follows.
InDatagrams: Total number of received datagrams.
NoPorts: Number of packets received to an unknown port.
These cases are counted separately (not as InErrors).
InErrors: Number of erroneous UDP-Lite packets. Errors include:
* internal socket queue receive errors
* packet too short (less than 8 bytes or stated
coverage length exceeds received length)
* xfrm4_policy_check() returned with error
* application has specified larger min. coverage
length than that of incoming packet
* checksum coverage violated
* bad checksum
OutDatagrams: Total number of sent datagrams.
These statistics derive from the UDP MIB (RFC 2013).
VI) IPTABLES
There is packet match support for UDP-Lite as well as support for the LOG target.
If you copy and paste the following line into /etc/protcols,
udplite 136 UDP-Lite # UDP-Lite [RFC 3828]
then
iptables -A INPUT -p udplite -j LOG
will produce logging output to syslog. Dropping and rejecting packets also works.
VII) MAINTAINER ADDRESS
The UDP-Lite patch was developed at
University of Aberdeen
Electronics Research Group
Department of Engineering
Fraser Noble Building
Aberdeen AB24 3UE; UK
The current maintainer is Gerrit Renker, <gerrit@erg.abdn.ac.uk>. Initial
code was developed by William Stanislaus, <william@erg.abdn.ac.uk>.

8
Documentation/networking/wan-router.txt
View File

@ -412,7 +412,7 @@ beta-2.1.4 Jul 2000 o Dynamic interface configuration:
beta3-2.1.4 Jul 2000 o X25 M_BIT Problem fix.
o Added the Multi-Port PPP
Updated utilites for the Multi-Port PPP.
Updated utilities for the Multi-Port PPP.
2.1.4 Aut 2000
o In X25API:
@ -444,13 +444,13 @@ beta1-2.1.5 Nov 15 2000
o Cpipemon
- Added set FT1 commands to the cpipemon. Thus CSU/DSU
configuraiton can be performed using cpipemon.
configuration can be performed using cpipemon.
All systems that cannot run cfgft1 GUI utility should
use cpipemon to configure the on board CSU/DSU.
o Keyboard Led Monitor/Debugger
- A new utilty /usr/sbin/wpkbdmon uses keyboard leds
- A new utility /usr/sbin/wpkbdmon uses keyboard leds
to convey operational statistic information of the
Sangoma WANPIPE cards.
NUM_LOCK = Line State (On=connected, Off=disconnected)
@ -464,7 +464,7 @@ beta1-2.1.5 Nov 15 2000
- Appropriate number of devices are dynamically loaded
based on the number of Sangoma cards found.
Note: The kernel configuraiton option
Note: The kernel configuration option
CONFIG_WANPIPE_CARDS has been taken out.
o Fixed the Frame Relay and Chdlc network interfaces so they are

5
Documentation/networking/xfrm_sync.txt
View File

@ -47,10 +47,13 @@ aevent_id structure looks like:
struct xfrm_aevent_id {
struct xfrm_usersa_id sa_id;
xfrm_address_t saddr;
__u32 flags;
__u32 reqid;
};
xfrm_usersa_id in this message layout identifies the SA.
The unique SA is identified by the combination of xfrm_usersa_id,
reqid and saddr.
flags are used to indicate different things. The possible
flags are:

2
Documentation/pnp.txt
View File

@ -184,7 +184,7 @@ static const struct pnp_id pnp_dev_table[] = {
Please note that the character 'X' can be used as a wild card in the function
portion (last four characters).
ex:
/* Unkown PnP modems */
/* Unknown PnP modems */
{ "PNPCXXX", UNKNOWN_DEV },
Supported PnP card IDs can optionally be defined.

13
Documentation/power/interface.txt
View File

@ -30,6 +30,17 @@ testing). The system will support either 'firmware' or 'platform', and
that is known a priori. But, the user may choose 'shutdown' or
'reboot' as alternatives.
Additionally, /sys/power/disk can be used to turn on one of the two testing
modes of the suspend-to-disk mechanism: 'testproc' or 'test'. If the
suspend-to-disk mechanism is in the 'testproc' mode, writing 'disk' to
/sys/power/state will cause the kernel to disable nonboot CPUs and freeze
tasks, wait for 5 seconds, unfreeze tasks and enable nonboot CPUs. If it is
in the 'test' mode, writing 'disk' to /sys/power/state will cause the kernel
to disable nonboot CPUs and freeze tasks, shrink memory, suspend devices, wait
for 5 seconds, resume devices, unfreeze tasks and enable nonboot CPUs. Then,
we are able to look in the log messages and work out, for example, which code
is being slow and which device drivers are misbehaving.
Reading from this file will display what the mode is currently set
to. Writing to this file will accept one of
@ -37,6 +48,8 @@ to. Writing to this file will accept one of
'platform'
'shutdown'
'reboot'
'testproc'
'test'
It will only change to 'firmware' or 'platform' if the system supports
it.

4
Documentation/power/pci.txt
View File

@ -153,7 +153,7 @@ Description:
events, which is implicit if it doesn't even support it in the first
place).
Note that the PMC Register in the device's PM Capabilties has a bitmask
Note that the PMC Register in the device's PM Capabilities has a bitmask
of the states it supports generating PME# from. D3hot is bit 3 and
D3cold is bit 4. So, while a value of 4 as the state may not seem
semantically correct, it is.
@ -268,7 +268,7 @@ to wake the system up. (However, it is possible that a device may support
some non-standard way of generating a wake event on sleep.)
Bits 15:11 of the PMC (Power Mgmt Capabilities) Register in a device's
PM Capabilties describe what power states the device supports generating a
PM Capabilities describe what power states the device supports generating a
wake event from:
+------------------+

2
Documentation/power/states.txt
View File

@ -62,7 +62,7 @@ setup via another operating system for it to use. Despite the
inconvenience, this method requires minimal work by the kernel, since
the firmware will also handle restoring memory contents on resume.
If the kernel is responsible for persistantly saving state, a mechanism
If the kernel is responsible for persistently saving state, a mechanism
called 'swsusp' (Swap Suspend) is used to write memory contents to
free swap space. swsusp has some restrictive requirements, but should
work in most cases. Some, albeit outdated, documentation can be found

2
Documentation/power/swsusp.txt
View File

@ -153,7 +153,7 @@ add:
If the thread is needed for writing the image to storage, you should
instead set the PF_NOFREEZE process flag when creating the thread (and
be very carefull).
be very careful).
Q: What is the difference between "platform", "shutdown" and

8
Documentation/powerpc/booting-without-of.txt
View File

@ -33,13 +33,13 @@
- Change version 16 format to always align
property data to 4 bytes. Since tokens are
already aligned, that means no specific
required alignement between property size
required alignment between property size
and property data. The old style variable
alignment would make it impossible to do
"simple" insertion of properties using
memove (thanks Milton for
noticing). Updated kernel patch as well
- Correct a few more alignement constraints
- Correct a few more alignment constraints
- Add a chapter about the device-tree
compiler and the textural representation of
the tree that can be "compiled" by dtc.
@ -854,7 +854,7 @@ address which can extend beyond that limit.
console device if any. Typically, if you have serial devices on
your board, you may want to put the full path to the one set as
the default console in the firmware here, for the kernel to pick
it up as it's own default console. If you look at the funciton
it up as its own default console. If you look at the function
set_preferred_console() in arch/ppc64/kernel/setup.c, you'll see
that the kernel tries to find out the default console and has
knowledge of various types like 8250 serial ports. You may want
@ -1124,7 +1124,7 @@ should have the following properties:
- interrupt-parent : contains the phandle of the interrupt
controller which handles interrupts for this device
- interrupts : a list of tuples representing the interrupt
number and the interrupt sense and level for each interupt
number and the interrupt sense and level for each interrupt
for this device.
This information is used by the kernel to build the interrupt table

2
Documentation/robust-futex-ABI.txt
View File

@ -170,7 +170,7 @@ any point:
1) the 'head' pointer or an subsequent linked list pointer
is not a valid address of a user space word
2) the calculated location of the 'lock word' (address plus
'offset') is not the valud address of a 32 bit user space
'offset') is not the valid address of a 32 bit user space
word
3) if the list contains more than 1 million (subject to
future kernel configuration changes) elements.

2
Documentation/robust-futexes.txt
View File

@ -181,7 +181,7 @@ for new threads, without the need of another syscall.]
So there is virtually zero overhead for tasks not using robust futexes,
and even for robust futex users, there is only one extra syscall per
thread lifetime, and the cleanup operation, if it happens, is fast and
straightforward. The kernel doesnt have any internal distinction between
straightforward. The kernel doesn't have any internal distinction between
robust and normal futexes.
If a futex is found to be held at exit time, the kernel sets the

491
Documentation/rtc.txt
View File

@ -1,12 +1,49 @@
Real Time Clock Driver for Linux
================================
Real Time Clock (RTC) Drivers for Linux
=======================================
When Linux developers talk about a "Real Time Clock", they usually mean
something that tracks wall clock time and is battery backed so that it
works even with system power off. Such clocks will normally not track
the local time zone or daylight savings time -- unless they dual boot
with MS-Windows -- but will instead be set to Coordinated Universal Time
(UTC, formerly "Greenwich Mean Time").
The newest non-PC hardware tends to just count seconds, like the time(2)
system call reports, but RTCs also very commonly represent time using
the Gregorian calendar and 24 hour time, as reported by gmtime(3).
Linux has two largely-compatible userspace RTC API families you may
need to know about:
* /dev/rtc ... is the RTC provided by PC compatible systems,
so it's not very portable to non-x86 systems.
* /dev/rtc0, /dev/rtc1 ... are part of a framework that's
supported by a wide variety of RTC chips on all systems.
Programmers need to understand that the PC/AT functionality is not
always available, and some systems can do much more. That is, the
RTCs use the same API to make requests in both RTC frameworks (using
different filenames of course), but the hardware may not offer the
same functionality. For example, not every RTC is hooked up to an
IRQ, so they can't all issue alarms; and where standard PC RTCs can
only issue an alarm up to 24 hours in the future, other hardware may
be able to schedule one any time in the upcoming century.
Old PC/AT-Compatible driver: /dev/rtc
--------------------------------------
All PCs (even Alpha machines) have a Real Time Clock built into them.
Usually they are built into the chipset of the computer, but some may
actually have a Motorola MC146818 (or clone) on the board. This is the
clock that keeps the date and time while your computer is turned off.
ACPI has standardized that MC146818 functionality, and extended it in
a few ways (enabling longer alarm periods, and wake-from-hibernate).
That functionality is NOT exposed in the old driver.
However it can also be used to generate signals from a slow 2Hz to a
relatively fast 8192Hz, in increments of powers of two. These signals
are reported by interrupt number 8. (Oh! So *that* is what IRQ 8 is
@ -63,223 +100,331 @@ Rather than write 50 pages describing the ioctl() and so on, it is
perhaps more useful to include a small test program that demonstrates
how to use them, and demonstrates the features of the driver. This is
probably a lot more useful to people interested in writing applications
that will be using this driver.
that will be using this driver. See the code at the end of this document.
(The original /dev/rtc driver was written by Paul Gortmaker.)
New portable "RTC Class" drivers: /dev/rtcN
--------------------------------------------
Because Linux supports many non-ACPI and non-PC platforms, some of which
have more than one RTC style clock, it needed a more portable solution
than expecting a single battery-backed MC146818 clone on every system.
Accordingly, a new "RTC Class" framework has been defined. It offers
three different userspace interfaces:
* /dev/rtcN ... much the same as the older /dev/rtc interface
* /sys/class/rtc/rtcN ... sysfs attributes support readonly
access to some RTC attributes.
* /proc/driver/rtc ... the first RTC (rtc0) may expose itself
using a procfs interface. More information is (currently) shown
here than through sysfs.
The RTC Class framework supports a wide variety of RTCs, ranging from those
integrated into embeddable system-on-chip (SOC) processors to discrete chips
using I2C, SPI, or some other bus to communicate with the host CPU. There's
even support for PC-style RTCs ... including the features exposed on newer PCs
through ACPI.
The new framework also removes the "one RTC per system" restriction. For
example, maybe the low-power battery-backed RTC is a discrete I2C chip, but
a high functionality RTC is integrated into the SOC. That system might read
the system clock from the discrete RTC, but use the integrated one for all
other tasks, because of its greater functionality.
The ioctl() calls supported by /dev/rtc are also supported by the RTC class
framework. However, because the chips and systems are not standardized,
some PC/AT functionality might not be provided. And in the same way, some
newer features -- including those enabled by ACPI -- are exposed by the
RTC class framework, but can't be supported by the older driver.
* RTC_RD_TIME, RTC_SET_TIME ... every RTC supports at least reading
time, returning the result as a Gregorian calendar date and 24 hour
wall clock time. To be most useful, this time may also be updated.
* RTC_AIE_ON, RTC_AIE_OFF, RTC_ALM_SET, RTC_ALM_READ ... when the RTC
is connected to an IRQ line, it can often issue an alarm IRQ up to
24 hours in the future.
* RTC_WKALM_SET, RTC_WKALM_READ ... RTCs that can issue alarms beyond
the next 24 hours use a slightly more powerful API, which supports
setting the longer alarm time and enabling its IRQ using a single
request (using the same model as EFI firmware).
* RTC_UIE_ON, RTC_UIE_OFF ... if the RTC offers IRQs, it probably
also offers update IRQs whenever the "seconds" counter changes.
If needed, the RTC framework can emulate this mechanism.
* RTC_PIE_ON, RTC_PIE_OFF, RTC_IRQP_SET, RTC_IRQP_READ ... another
feature often accessible with an IRQ line is a periodic IRQ, issued
at settable frequencies (usually 2^N Hz).
In many cases, the RTC alarm can be a system wake event, used to force
Linux out of a low power sleep state (or hibernation) back to a fully
operational state. For example, a system could enter a deep power saving
state until it's time to execute some scheduled tasks.
Paul Gortmaker
-------------------- 8< ---------------- 8< -----------------------------
/*
* Real Time Clock Driver Test/Example Program
* Real Time Clock Driver Test/Example Program
*
* Compile with:
* gcc -s -Wall -Wstrict-prototypes rtctest.c -o rtctest
* Compile with:
* gcc -s -Wall -Wstrict-prototypes rtctest.c -o rtctest
*
* Copyright (C) 1996, Paul Gortmaker.
* Copyright (C) 1996, Paul Gortmaker.
*
* Released under the GNU General Public License, version 2,
* included herein by reference.
* Released under the GNU General Public License, version 2,
* included herein by reference.
*
*/
#include <stdio.h>
#include <stdlib.h>
#include <linux/rtc.h>
#include <sys/ioctl.h>
#include <sys/time.h>
#include <sys/types.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <errno.h>
int main(void) {
int i, fd, retval, irqcount = 0;
unsigned long tmp, data;
struct rtc_time rtc_tm;
/*
* This expects the new RTC class driver framework, working with
* clocks that will often not be clones of what the PC-AT had.
* Use the command line to specify another RTC if you need one.
*/
static const char default_rtc[] = "/dev/rtc0";
fd = open ("/dev/rtc", O_RDONLY);
if (fd == -1) {
perror("/dev/rtc");
exit(errno);
}
int main(int argc, char **argv)
{
int i, fd, retval, irqcount = 0;
unsigned long tmp, data;
struct rtc_time rtc_tm;
const char *rtc = default_rtc;
fprintf(stderr, "\n\t\t\tRTC Driver Test Example.\n\n");
switch (argc) {
case 2:
rtc = argv[1];
/* FALLTHROUGH */
case 1:
break;
default:
fprintf(stderr, "usage: rtctest [rtcdev]\n");
return 1;
}
/* Turn on update interrupts (one per second) */
retval = ioctl(fd, RTC_UIE_ON, 0);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
fd = open(rtc, O_RDONLY);
fprintf(stderr, "Counting 5 update (1/sec) interrupts from reading /dev/rtc:");
fflush(stderr);
for (i=1; i<6; i++) {
/* This read will block */
retval = read(fd, &data, sizeof(unsigned long));
if (retval == -1) {
perror("read");
if (fd == -1) {
perror(rtc);
exit(errno);
}
fprintf(stderr, " %d",i);
fflush(stderr);
irqcount++;
}
fprintf(stderr, "\nAgain, from using select(2) on /dev/rtc:");
fflush(stderr);
for (i=1; i<6; i++) {
struct timeval tv = {5, 0}; /* 5 second timeout on select */
fd_set readfds;
fprintf(stderr, "\n\t\t\tRTC Driver Test Example.\n\n");
FD_ZERO(&readfds);
FD_SET(fd, &readfds);
/* The select will wait until an RTC interrupt happens. */
retval = select(fd+1, &readfds, NULL, NULL, &tv);
if (retval == -1) {
perror("select");
exit(errno);
}
/* This read won't block unlike the select-less case above. */
retval = read(fd, &data, sizeof(unsigned long));
if (retval == -1) {
perror("read");
exit(errno);
}
fprintf(stderr, " %d",i);
fflush(stderr);
irqcount++;
}
/* Turn off update interrupts */
retval = ioctl(fd, RTC_UIE_OFF, 0);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
/* Read the RTC time/date */
retval = ioctl(fd, RTC_RD_TIME, &rtc_tm);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
fprintf(stderr, "\n\nCurrent RTC date/time is %d-%d-%d, %02d:%02d:%02d.\n",
rtc_tm.tm_mday, rtc_tm.tm_mon + 1, rtc_tm.tm_year + 1900,
rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec);
/* Set the alarm to 5 sec in the future, and check for rollover */
rtc_tm.tm_sec += 5;
if (rtc_tm.tm_sec >= 60) {
rtc_tm.tm_sec %= 60;
rtc_tm.tm_min++;
}
if (rtc_tm.tm_min == 60) {
rtc_tm.tm_min = 0;
rtc_tm.tm_hour++;
}
if (rtc_tm.tm_hour == 24)
rtc_tm.tm_hour = 0;
retval = ioctl(fd, RTC_ALM_SET, &rtc_tm);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
/* Read the current alarm settings */
retval = ioctl(fd, RTC_ALM_READ, &rtc_tm);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
fprintf(stderr, "Alarm time now set to %02d:%02d:%02d.\n",
rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec);
/* Enable alarm interrupts */
retval = ioctl(fd, RTC_AIE_ON, 0);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
fprintf(stderr, "Waiting 5 seconds for alarm...");
fflush(stderr);
/* This blocks until the alarm ring causes an interrupt */
retval = read(fd, &data, sizeof(unsigned long));
if (retval == -1) {
perror("read");
exit(errno);
}
irqcount++;
fprintf(stderr, " okay. Alarm rang.\n");
/* Disable alarm interrupts */
retval = ioctl(fd, RTC_AIE_OFF, 0);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
/* Read periodic IRQ rate */
retval = ioctl(fd, RTC_IRQP_READ, &tmp);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
fprintf(stderr, "\nPeriodic IRQ rate was %ldHz.\n", tmp);
fprintf(stderr, "Counting 20 interrupts at:");
fflush(stderr);
/* The frequencies 128Hz, 256Hz, ... 8192Hz are only allowed for root. */
for (tmp=2; tmp<=64; tmp*=2) {
retval = ioctl(fd, RTC_IRQP_SET, tmp);
/* Turn on update interrupts (one per second) */
retval = ioctl(fd, RTC_UIE_ON, 0);
if (retval == -1) {
if (errno == ENOTTY) {
fprintf(stderr,
"\n...Update IRQs not supported.\n");
goto test_READ;
}
perror("ioctl");
exit(errno);
}
fprintf(stderr, "\n%ldHz:\t", tmp);
fprintf(stderr, "Counting 5 update (1/sec) interrupts from reading %s:",
rtc);
fflush(stderr);
/* Enable periodic interrupts */
retval = ioctl(fd, RTC_PIE_ON, 0);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
for (i=1; i<21; i++) {
/* This blocks */
for (i=1; i<6; i++) {
/* This read will block */
retval = read(fd, &data, sizeof(unsigned long));
if (retval == -1) {
perror("read");
exit(errno);
perror("read");
exit(errno);
}
fprintf(stderr, " %d",i);
fflush(stderr);
irqcount++;
}
/* Disable periodic interrupts */
retval = ioctl(fd, RTC_PIE_OFF, 0);
fprintf(stderr, "\nAgain, from using select(2) on /dev/rtc:");
fflush(stderr);
for (i=1; i<6; i++) {
struct timeval tv = {5, 0}; /* 5 second timeout on select */
fd_set readfds;
FD_ZERO(&readfds);
FD_SET(fd, &readfds);
/* The select will wait until an RTC interrupt happens. */
retval = select(fd+1, &readfds, NULL, NULL, &tv);
if (retval == -1) {
perror("select");
exit(errno);
}
/* This read won't block unlike the select-less case above. */
retval = read(fd, &data, sizeof(unsigned long));
if (retval == -1) {
perror("read");
exit(errno);
}
fprintf(stderr, " %d",i);
fflush(stderr);
irqcount++;
}
/* Turn off update interrupts */
retval = ioctl(fd, RTC_UIE_OFF, 0);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
test_READ:
/* Read the RTC time/date */
retval = ioctl(fd, RTC_RD_TIME, &rtc_tm);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
fprintf(stderr, "\n\nCurrent RTC date/time is %d-%d-%d, %02d:%02d:%02d.\n",
rtc_tm.tm_mday, rtc_tm.tm_mon + 1, rtc_tm.tm_year + 1900,
rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec);
/* Set the alarm to 5 sec in the future, and check for rollover */
rtc_tm.tm_sec += 5;
if (rtc_tm.tm_sec >= 60) {
rtc_tm.tm_sec %= 60;
rtc_tm.tm_min++;
}
if (rtc_tm.tm_min == 60) {
rtc_tm.tm_min = 0;
rtc_tm.tm_hour++;
}
if (rtc_tm.tm_hour == 24)
rtc_tm.tm_hour = 0;
retval = ioctl(fd, RTC_ALM_SET, &rtc_tm);
if (retval == -1) {
if (errno == ENOTTY) {
fprintf(stderr,
"\n...Alarm IRQs not supported.\n");
goto test_PIE;
}
perror("ioctl");
exit(errno);
}
/* Read the current alarm settings */
retval = ioctl(fd, RTC_ALM_READ, &rtc_tm);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
fprintf(stderr, "Alarm time now set to %02d:%02d:%02d.\n",
rtc_tm.tm_hour, rtc_tm.tm_min, rtc_tm.tm_sec);
/* Enable alarm interrupts */
retval = ioctl(fd, RTC_AIE_ON, 0);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
fprintf(stderr, "Waiting 5 seconds for alarm...");
fflush(stderr);
/* This blocks until the alarm ring causes an interrupt */
retval = read(fd, &data, sizeof(unsigned long));
if (retval == -1) {
perror("read");
exit(errno);
}
irqcount++;
fprintf(stderr, " okay. Alarm rang.\n");
/* Disable alarm interrupts */
retval = ioctl(fd, RTC_AIE_OFF, 0);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
test_PIE:
/* Read periodic IRQ rate */
retval = ioctl(fd, RTC_IRQP_READ, &tmp);
if (retval == -1) {
/* not all RTCs support periodic IRQs */
if (errno == ENOTTY) {
fprintf(stderr, "\nNo periodic IRQ support\n");
return 0;
}
perror("ioctl");
exit(errno);
}
fprintf(stderr, "\nPeriodic IRQ rate is %ldHz.\n", tmp);
fprintf(stderr, "Counting 20 interrupts at:");
fflush(stderr);
/* The frequencies 128Hz, 256Hz, ... 8192Hz are only allowed for root. */
for (tmp=2; tmp<=64; tmp*=2) {
retval = ioctl(fd, RTC_IRQP_SET, tmp);
if (retval == -1) {
/* not all RTCs can change their periodic IRQ rate */
if (errno == ENOTTY) {
fprintf(stderr,
"\n...Periodic IRQ rate is fixed\n");
goto done;
}
perror("ioctl");
exit(errno);
}
fprintf(stderr, "\n%ldHz:\t", tmp);
fflush(stderr);
/* Enable periodic interrupts */
retval = ioctl(fd, RTC_PIE_ON, 0);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
for (i=1; i<21; i++) {
/* This blocks */
retval = read(fd, &data, sizeof(unsigned long));
if (retval == -1) {
perror("read");
exit(errno);
}
fprintf(stderr, " %d",i);
fflush(stderr);
irqcount++;
}
/* Disable periodic interrupts */
retval = ioctl(fd, RTC_PIE_OFF, 0);
if (retval == -1) {
perror("ioctl");
exit(errno);
}
}
done:
fprintf(stderr, "\n\n\t\t\t *** Test complete ***\n");
close(fd);
return 0;
}
fprintf(stderr, "\n\n\t\t\t *** Test complete ***\n");
fprintf(stderr, "\nTyping \"cat /proc/interrupts\" will show %d more events on IRQ 8.\n\n",
irqcount);
close(fd);
return 0;
} /* end main */

2
Documentation/s390/CommonIO
View File

@ -66,7 +66,7 @@ Command line parameters
When a device is un-ignored, device recognition and sensing is performed and
the device driver will be notified if possible, so the device will become
available to the system.
available to the system. Note that un-ignoring is performed asynchronously.
You can also add ranges of devices to be ignored by piping to
/proc/cio_ignore; "add <device range>, <device range>, ..." will ignore the

52
Documentation/s390/cds.txt
View File

@ -174,14 +174,10 @@ read_dev_chars() - Read Device Characteristics
This routine returns the characteristics for the device specified.
The function is meant to be called with an irq handler in place; that is,
The function is meant to be called with the device already enabled; that is,
at earliest during set_online() processing.
While the request is processed synchronously, the device interrupt
handler is called for final ending status. In case of error situations the
interrupt handler may recover appropriately. The device irq handler can
recognize the corresponding interrupts by the interruption parameter be
0x00524443. The ccw_device must not be locked prior to calling read_dev_chars().
The ccw_device must not be locked prior to calling read_dev_chars().
The function may be called enabled or disabled.
@ -410,26 +406,7 @@ individual flag meanings.
Usage Notes :
Prior to call ccw_device_start() the device driver must assure disabled state,
i.e. the I/O mask value in the PSW must be disabled. This can be accomplished
by calling local_save_flags( flags). The current PSW flags are preserved and
can be restored by local_irq_restore( flags) at a later time.
If the device driver violates this rule while running in a uni-processor
environment an interrupt might be presented prior to the ccw_device_start()
routine returning to the device driver main path. In this case we will end in a
deadlock situation as the interrupt handler will try to obtain the irq
lock the device driver still owns (see below) !
The driver must assure to hold the device specific lock. This can be
accomplished by
(i) spin_lock(get_ccwdev_lock(cdev)), or
(ii) spin_lock_irqsave(get_ccwdev_lock(cdev), flags)
Option (i) should be used if the calling routine is running disabled for
I/O interrupts (see above) already. Option (ii) obtains the device gate und
puts the CPU into I/O disabled state by preserving the current PSW flags.
ccw_device_start() must be called disabled and with the ccw device lock held.
The device driver is allowed to issue the next ccw_device_start() call from
within its interrupt handler already. It is not required to schedule a
@ -488,7 +465,7 @@ int ccw_device_resume(struct ccw_device *cdev);
cdev - ccw_device the resume operation is requested for
The resume_IO() function returns:
The ccw_device_resume() function returns:
0 - suspended channel program is resumed
-EBUSY - status pending
@ -507,6 +484,8 @@ a long-running channel program or the device might require to initially issue
a halt subchannel (HSCH) I/O command. For those purposes the ccw_device_halt()
command is provided.
ccw_device_halt() must be called disabled and with the ccw device lock held.
int ccw_device_halt(struct ccw_device *cdev,
unsigned long intparm);
@ -517,7 +496,7 @@ intparm : interruption parameter; value is only used if no I/O
The ccw_device_halt() function returns :
0 - successful completion or request successfully initiated
0 - request successfully initiated
-EBUSY - the device is currently busy, or status pending.
-ENODEV - cdev invalid.
-EINVAL - The device is not operational or the ccw device is not online.
@ -533,6 +512,23 @@ can then perform an appropriate action. Prior to interrupt of an outstanding
read to a network device (with or without PCI flag) a ccw_device_halt()
is required to end the pending operation.
ccw_device_clear() - Terminage I/O Request Processing
In order to terminate all I/O processing at the subchannel, the clear subchannel
(CSCH) command is used. It can be issued via ccw_device_clear().
ccw_device_clear() must be called disabled and with the ccw device lock held.
int ccw_device_clear(struct ccw_device *cdev, unsigned long intparm);
cdev: ccw_device the clear operation is requested for
intparm: interruption parameter (see ccw_device_halt())
The ccw_device_clear() function returns:
0 - request successfully initiated
-ENODEV - cdev invalid
-EINVAL - The device is not operational or the ccw device is not online.
Miscellaneous Support Routines

4
Documentation/s390/crypto/crypto-API.txt
View File

@ -75,8 +75,8 @@ name of the respective module is given in square brackets.
- SHA1 Digest Algorithm [sha1 -> sha1_z990]
- DES Encrypt/Decrypt Algorithm (64bit key) [des -> des_z990]
- Tripple DES Encrypt/Decrypt Algorithm (128bit key) [des3_ede128 -> des_z990]
- Tripple DES Encrypt/Decrypt Algorithm (192bit key) [des3_ede -> des_z990]
- Triple DES Encrypt/Decrypt Algorithm (128bit key) [des3_ede128 -> des_z990]
- Triple DES Encrypt/Decrypt Algorithm (192bit key) [des3_ede -> des_z990]
In order to load, for example, the sha1_z990 module when the sha1 algorithm is
requested (see 3.2.) add 'alias sha1 sha1_z990' to /etc/modprobe.conf.

3
Documentation/s390/driver-model.txt
View File

@ -239,6 +239,9 @@ status - Can be 'online' or 'offline'.
type - The physical type of the channel path.
shared - Whether the channel path is shared.
cmg - The channel measurement group.
3. System devices
-----------------

4
Documentation/scsi/aic79xx.txt
View File

@ -127,7 +127,7 @@ The following information is available in this file:
- Correct a reference to free'ed memory during controller
shutdown.
- Reset the bus on an SE->LVD change. This is required
to reset our transcievers.
to reset our transceivers.
1.3.5 (March 24th, 2003)
- Fix a few register window mode bugs.
@ -169,7 +169,7 @@ The following information is available in this file:
1.3.0 (January 21st, 2003)
- Full regression testing for all U320 products completed.
- Added abort and target/lun reset error recovery handler and
interrupt coalessing.
interrupt coalescing.
1.2.0 (November 14th, 2002)
- Added support for Domain Validation

4
Documentation/scsi/aic7xxx_old.txt
View File

@ -256,7 +256,7 @@ linux-1.1.x and fairly stable since linux-1.2.x, and are also in FreeBSD
En/Disable High Byte LVD Termination
The upper 2 bits that deal with LVD termination only apply to Ultra2
controllers. Futhermore, due to the current Ultra2 controller
controllers. Furthermore, due to the current Ultra2 controller
designs, these bits are tied together such that setting either bit
enables both low and high byte LVD termination. It is not possible
to only set high or low byte LVD termination in this manner. This is
@ -436,7 +436,7 @@ linux-1.1.x and fairly stable since linux-1.2.x, and are also in FreeBSD
the commas to periods, insmod won't interpret this as more than one
string and write junk into our binary image. I consider it a bug in
the insmod program that even if you wrap your string in quotes (quotes
that pass the shell mind you and that insmod sees) it still treates
that pass the shell mind you and that insmod sees) it still treats
a comma inside of those quotes as starting a new variable, resulting
in memory scribbles if you don't switch the commas to periods.

14
Documentation/scsi/ibmmca.txt
View File

@ -461,7 +461,7 @@
This needs the RD-Bit to be disabled on IM_OTHER_SCSI_CMD_CMD which
allows data to be written from the system to the device. It is a
necessary step to be allowed to set blocksize of SCSI-tape-drives and
the tape-speed, whithout confusing the SCSI-Subsystem.
the tape-speed, without confusing the SCSI-Subsystem.
2) The recognition of a tape is included in the check_devices routine.
This is done by checking for TYPE_TAPE, that is already defined in
the kernel-scsi-environment. The markup of a tape is done in the
@ -710,8 +710,8 @@
of troubles with some controllers and after I wanted to apply some
extensions, it jumped out in the same situation, on my w/cache, as like
on D. Weinehalls' Model 56, having integrated SCSI. This gave me the
descissive hint to move the code-part out and declare it global. Now,
it seems to work by far much better an more stable. Let us see, what
decisive hint to move the code-part out and declare it global. Now
it seems to work far better and more stable. Let us see what
the world thinks of it...
3) By the way, only Sony DAT-drives seem to show density code 0x13. A
test with a HP drive gave right results, so the problem is vendor-
@ -822,10 +822,10 @@
A long period of collecting bugreports from all corners of the world
now lead to the following corrections to the code:
1) SCSI-2 F/W support crashed with a COMMAND ERROR. The reason for this
was, that it is possible to disbale Fast-SCSI for the external bus.
The feature-control command, where this crash appeared regularly tried
was that it is possible to disable Fast-SCSI for the external bus.
The feature-control command, where this crash appeared regularly, tried
to set the maximum speed of 10MHz synchronous transfer speed and that
reports a COMMAND ERROR, if external bus Fast-SCSI is disabled. Now,
reports a COMMAND ERROR if external bus Fast-SCSI is disabled. Now,
the feature-command probes down from maximum speed until the adapter
stops to complain, which is at the same time the maximum possible
speed selected in the reference program. So, F/W external can run at
@ -920,7 +920,7 @@
completed in such a way, that they are now completely conform to the
demands in the technical description of IBM. Main candidates were the
DEVICE_INQUIRY, REQUEST_SENSE and DEVICE_CAPACITY commands. They must
be tranferred by bypassing the internal command buffer of the adapter
be transferred by bypassing the internal command buffer of the adapter
or else the response can be a random result. GET_POS_INFO would be more
safe in usage, if one could use the SUPRESS_EXCEPTION_SHORT, but this
is not allowed by the technical references of IBM. (Sorry, folks, the

2
Documentation/scsi/in2000.txt
View File

@ -24,7 +24,7 @@ UPDATE NEWS: version 1.32 - 28 Mar 98
UPDATE NEWS: version 1.31 - 6 Jul 97
Fixed a bug that caused incorrect SCSI status bytes to be
returned from commands sent to LUN's greater than 0. This
returned from commands sent to LUNs greater than 0. This
means that CDROM changers work now! Fixed a bug in the
handling of command-line arguments when loaded as a module.
Also put all the header data in in2000.h where it belongs.

2
Documentation/scsi/libsas.txt
View File

@ -393,7 +393,7 @@ struct sas_task {
task_proto -- _one_ of enum sas_proto
scatter -- pointer to scatter gather list array
num_scatter -- number of elements in scatter
total_xfer_len -- total number of bytes expected to be transfered
total_xfer_len -- total number of bytes expected to be transferred
data_dir -- PCI_DMA_...
task_done -- callback when the task has finished execution
};

2
Documentation/scsi/ncr53c8xx.txt
View File

@ -115,7 +115,7 @@ SCSI standard documentations are available at SYMBIOS ftp server:
ftp://ftp.symbios.com/
Usefull SCSI tools written by Eric Youngdale are available at tsx-11:
Useful SCSI tools written by Eric Youngdale are available at tsx-11:
ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/scsiinfo-X.Y.tar.gz
ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/scsidev-X.Y.tar.gz

4
Documentation/scsi/scsi-changer.txt
View File

@ -88,7 +88,7 @@ If the module finds the changer, it prints some messages about the
device [ try "dmesg" if you don't see anything ] and should show up in
/proc/devices. If not.... some changers use ID ? / LUN 0 for the
device and ID ? / LUN 1 for the robot mechanism. But Linux does *not*
look for LUN's other than 0 as default, becauce there are to many
look for LUNs other than 0 as default, because there are too many
broken devices. So you can try:
1) echo "scsi add-single-device 0 0 ID 1" > /proc/scsi/scsi
@ -107,7 +107,7 @@ because the kernel will translate the error codes into human-readable
strings then.
You can display these messages with the dmesg command (or check the
logfiles). If you email me some question becauce of a problem with the
logfiles). If you email me some question because of a problem with the
driver, please include these messages.

2
Documentation/scsi/scsi_eh.txt
View File

@ -75,7 +75,7 @@ with the command.
- otherwise
scsi_eh_scmd_add(scmd, 0) is invoked for the command. See
[1-3] for details of this funciton.
[1-3] for details of this function.
[1-2-2] Completing a scmd w/ timeout

2
Documentation/scsi/st.txt
View File

@ -261,7 +261,7 @@ pairs are separated with a comma (no spaces allowed). A colon can be
used instead of the equal mark. The definition is prepended by the
string st=. Here is an example:
st=buffer_kbs:64,write_threhold_kbs:60
st=buffer_kbs:64,write_threshold_kbs:60
The following syntax used by the old kernel versions is also supported:

2
Documentation/scsi/sym53c8xx_2.txt
View File

@ -609,7 +609,7 @@ appropriate mailing lists or news-groups. Send me a copy in order to
be sure I will receive it. Obviously, a bug in the driver code is
possible.
My cyrrent email address: Gerard Roudier <groudier@free.fr>
My current email address: Gerard Roudier <groudier@free.fr>
Allowing disconnections is important if you use several devices on
your SCSI bus but often causes problems with buggy devices.

4
Documentation/sharedsubtree.txt
View File

@ -942,13 +942,13 @@ replicas continue to be exactly same.
->mnt_slave
->mnt_master
->mnt_share links togather all the mount to/from which this vfsmount
->mnt_share links together all the mount to/from which this vfsmount
send/receives propagation events.
->mnt_slave_list links all the mounts to which this vfsmount propagates
to.
->mnt_slave links togather all the slaves that its master vfsmount
->mnt_slave links together all the slaves that its master vfsmount
propagates to.
->mnt_master points to the master vfsmount from which this vfsmount

4
Documentation/sound/alsa/ALSA-Configuration.txt
View File

@ -753,7 +753,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
position_fix - Fix DMA pointer (0 = auto, 1 = none, 2 = POSBUF, 3 = FIFO size)
single_cmd - Use single immediate commands to communicate with
codecs (for debugging only)
disable_msi - Disable Message Signaled Interrupt (MSI)
enable_msi - Enable Message Signaled Interrupt (MSI) (default = off)
This module supports one card and autoprobe.
@ -955,7 +955,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
dmx6fire, dsp24, dsp24_value, dsp24_71, ez8,
phase88, mediastation
omni - Omni I/O support for MidiMan M-Audio Delta44/66
cs8427_timeout - reset timeout for the CS8427 chip (S/PDIF transciever)
cs8427_timeout - reset timeout for the CS8427 chip (S/PDIF transceiver)
in msec resolution, default value is 500 (0.5 sec)
This module supports multiple cards and autoprobe. Note: The consumer part

2
Documentation/sound/alsa/Audigy-mixer.txt
View File

@ -6,7 +6,7 @@ This is based on SB-Live-mixer.txt.
The EMU10K2 chips have a DSP part which can be programmed to support
various ways of sample processing, which is described here.
(This acticle does not deal with the overall functionality of the
(This article does not deal with the overall functionality of the
EMU10K2 chips. See the manuals section for further details.)
The ALSA driver programs this portion of chip by default code

2
Documentation/sound/alsa/SB-Live-mixer.txt
View File

@ -5,7 +5,7 @@
The EMU10K1 chips have a DSP part which can be programmed to support
various ways of sample processing, which is described here.
(This acticle does not deal with the overall functionality of the
(This article does not deal with the overall functionality of the
EMU10K1 chips. See the manuals section for further details.)
The ALSA driver programs this portion of chip by default code

2
Documentation/stable_kernel_rules.txt
View File

@ -50,7 +50,7 @@ Review cycle:
Contact the kernel security team for more details on this procedure.
Review committe:
Review committee:
- This is made up of a number of kernel developers who have volunteered for
this task, and a few that haven't.

2
Documentation/sysctl/fs.txt
View File

@ -146,7 +146,7 @@ or otherwise protected/tainted binaries. The modes are
readable by root only. This allows the end user to remove
such a dump but not access it directly. For security reasons
core dumps in this mode will not overwrite one another or
other files. This mode is appropriate when adminstrators are
other files. This mode is appropriate when administrators are
attempting to debug problems in a normal environment.
==============================================================

2
Documentation/sysctl/vm.txt
View File

@ -129,7 +129,7 @@ the high water marks for each per cpu page list.
zone_reclaim_mode:
Zone_reclaim_mode allows to set more or less agressive approaches to
Zone_reclaim_mode allows someone to set more or less aggressive approaches to
reclaim memory when a zone runs out of memory. If it is set to zero then no
zone reclaim occurs. Allocations will be satisfied from other zones / nodes
in the system.

2
Documentation/uml/UserModeLinux-HOWTO.txt
View File

@ -1477,7 +1477,7 @@
Making it world-writeable looks bad, but it seems not to be
Making it world-writable looks bad, but it seems not to be
exploitable as a security hole. However, it does allow anyone to cre-
ate useless tap devices (useless because they can't configure them),
which is a DOS attack. A somewhat more secure alternative would to be

2
Documentation/usb/hiddev.txt
View File

@ -8,7 +8,7 @@ interfaces, but have similar sorts of communication needs. The two big
examples for this are power devices (especially uninterruptable power
supplies) and monitor control on higher end monitors.
To support these disparite requirements, the Linux USB system provides
To support these disparate requirements, the Linux USB system provides
HID events to two separate interfaces:
* the input subsystem, which converts HID events into normal input
device interfaces (such as keyboard, mouse and joystick) and a

Some files were not shown because too many files have changed in this diff Show More