Merge branch 'linux-2.6' into for-linus
This commit is contained in:
Paul Mackerras
Коммит
79acbb3ff2
|
|
@ -20,6 +20,7 @@
|
||||||
# Top-level generic files
|
# Top-level generic files
|
||||||
#
|
#
|
||||||
tags
|
tags
|
||||||
|
TAGS
|
||||||
vmlinux*
|
vmlinux*
|
||||||
System.map
|
System.map
|
||||||
Module.symvers
|
Module.symvers
|
||||||
|
|
|
||||||
11
CREDITS
11
CREDITS
|
|
@ -45,7 +45,7 @@ S: Longford, Ireland
|
||||||
S: Sydney, Australia
|
S: Sydney, Australia
|
||||||
|
|
||||||
N: Tigran A. Aivazian
|
N: Tigran A. Aivazian
|
||||||
E: tigran@veritas.com
|
E: tigran@aivazian.fsnet.co.uk
|
||||||
W: http://www.moses.uklinux.net/patches
|
W: http://www.moses.uklinux.net/patches
|
||||||
D: BFS filesystem
|
D: BFS filesystem
|
||||||
D: Intel IA32 CPU microcode update support
|
D: Intel IA32 CPU microcode update support
|
||||||
|
|
@ -2598,6 +2598,9 @@ S: Ucitelska 1576
|
||||||
S: Prague 8
|
S: Prague 8
|
||||||
S: 182 00 Czech Republic
|
S: 182 00 Czech Republic
|
||||||
|
|
||||||
|
N: Rick Payne
|
||||||
|
D: RFC2385 Support for TCP
|
||||||
|
|
||||||
N: Barak A. Pearlmutter
|
N: Barak A. Pearlmutter
|
||||||
E: bap@cs.unm.edu
|
E: bap@cs.unm.edu
|
||||||
W: http://www.cs.unm.edu/~bap/
|
W: http://www.cs.unm.edu/~bap/
|
||||||
|
|
@ -3511,14 +3514,12 @@ D: The Linux Support Team Erlangen
|
||||||
|
|
||||||
N: David Weinehall
|
N: David Weinehall
|
||||||
E: tao@acc.umu.se
|
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/~tao/
|
||||||
W: http://www.acc.umu.se/~mcalinux/
|
D: v2.0 kernel maintainer
|
||||||
D: Fixes for the NE/2-driver
|
D: Fixes for the NE/2-driver
|
||||||
D: Miscellaneous MCA-support
|
D: Miscellaneous MCA-support
|
||||||
D: Cleanup of the Config-files
|
D: Cleanup of the Config-files
|
||||||
S: Axtorpsvagen 40:20
|
|
||||||
S: S-903 37 UMEA
|
|
||||||
S: Sweden
|
|
||||||
|
|
||||||
N: Matt Welsh
|
N: Matt Welsh
|
||||||
E: mdw@metalab.unc.edu
|
E: mdw@metalab.unc.edu
|
||||||
|
|
|
||||||
|
|
@ -21,7 +21,7 @@ Description:
|
||||||
these states.
|
these states.
|
||||||
|
|
||||||
What: /sys/power/disk
|
What: /sys/power/disk
|
||||||
Date: August 2006
|
Date: September 2006
|
||||||
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
Contact: Rafael J. Wysocki <rjw@sisk.pl>
|
||||||
Description:
|
Description:
|
||||||
The /sys/power/disk file controls the operating mode of the
|
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
|
'reboot' - the memory image will be saved by the kernel and
|
||||||
the system will be rebooted.
|
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
|
The suspend-to-disk method may be chosen by writing to this
|
||||||
file one of the accepted strings:
|
file one of the accepted strings:
|
||||||
|
|
||||||
|
|
@ -46,6 +59,8 @@ Description:
|
||||||
'platform'
|
'platform'
|
||||||
'shutdown'
|
'shutdown'
|
||||||
'reboot'
|
'reboot'
|
||||||
|
'testproc'
|
||||||
|
'test'
|
||||||
|
|
||||||
It will only change to 'firmware' or 'platform' if the system
|
It will only change to 'firmware' or 'platform' if the system
|
||||||
supports that.
|
supports that.
|
||||||
|
|
|
||||||
|
|
@ -201,7 +201,7 @@ udev
|
||||||
----
|
----
|
||||||
udev is a userspace application for populating /dev dynamically with
|
udev is a userspace application for populating /dev dynamically with
|
||||||
only entries for devices actually present. udev replaces the basic
|
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.
|
devices.
|
||||||
|
|
||||||
FUSE
|
FUSE
|
||||||
|
|
|
||||||
|
|
@ -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
|
flags can be or'd together and are
|
||||||
|
|
||||||
DMA_MEMORY_MAP - request that the memory returned from
|
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_MEMORY_IO - request that the memory returned from
|
||||||
dma_alloc_coherent() be addressable using read/write/memcpy_toio etc.
|
dma_alloc_coherent() be addressable using read/write/memcpy_toio etc.
|
||||||
|
|
|
||||||
|
|
@ -110,7 +110,7 @@ lock.
|
||||||
|
|
||||||
Once the DMA transfer is finished (or timed out) you should disable
|
Once the DMA transfer is finished (or timed out) you should disable
|
||||||
the channel again. You should also check get_dma_residue() to make
|
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:
|
Example:
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -9,7 +9,7 @@
|
||||||
DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
|
DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
|
||||||
kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
|
kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
|
||||||
procfs-guide.xml writing_usb_driver.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 \
|
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
|
||||||
genericirq.xml
|
genericirq.xml
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -2,9 +2,106 @@
|
||||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
|
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
|
||||||
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
|
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
|
||||||
|
|
||||||
<book id="LinuxJBDAPI">
|
<book id="Linux-filesystems-API">
|
||||||
<bookinfo>
|
<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>
|
<title>The Linux Journalling API</title>
|
||||||
|
|
||||||
<authorgroup>
|
<authorgroup>
|
||||||
<author>
|
<author>
|
||||||
<firstname>Roger</firstname>
|
<firstname>Roger</firstname>
|
||||||
|
|
@ -14,9 +111,9 @@
|
||||||
<email>rgammans@computer-surgery.co.uk</email>
|
<email>rgammans@computer-surgery.co.uk</email>
|
||||||
</address>
|
</address>
|
||||||
</affiliation>
|
</affiliation>
|
||||||
</author>
|
</author>
|
||||||
</authorgroup>
|
</authorgroup>
|
||||||
|
|
||||||
<authorgroup>
|
<authorgroup>
|
||||||
<author>
|
<author>
|
||||||
<firstname>Stephen</firstname>
|
<firstname>Stephen</firstname>
|
||||||
|
|
@ -33,50 +130,21 @@
|
||||||
<year>2002</year>
|
<year>2002</year>
|
||||||
<holder>Roger Gammans</holder>
|
<holder>Roger Gammans</holder>
|
||||||
</copyright>
|
</copyright>
|
||||||
|
</chapterinfo>
|
||||||
|
|
||||||
<legalnotice>
|
<title>The Linux Journalling API</title>
|
||||||
<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>
|
<sect1>
|
||||||
|
|
||||||
<chapter id="Overview">
|
|
||||||
<title>Overview</title>
|
<title>Overview</title>
|
||||||
<sect1>
|
<sect2>
|
||||||
<title>Details</title>
|
<title>Details</title>
|
||||||
<para>
|
<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
|
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
|
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()
|
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
|
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
|
you are finally finished make sure you call journal_destroy() on it
|
||||||
to free up any used kernel memory.
|
to free up any used kernel memory.
|
||||||
|
|
@ -91,27 +159,26 @@ need to call journal_create().
|
||||||
<para>
|
<para>
|
||||||
Most of the time however your journal file will already have been created, but
|
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.
|
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().
|
job of the client file system to detect this and skip the call to journal_wipe().
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
In either case the next call should be to journal_load() which prepares the
|
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
|
for you if it detects any outstanding transactions in the journal and similarly
|
||||||
journal_load() will call journal_recover() if necessary.
|
journal_load() will call journal_recover() if necessary.
|
||||||
I would advise reading fs/ext3/super.c for examples on this stage.
|
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
|
[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
|
complicate the API. Or isn't a good idea for the journal layer to hide
|
||||||
dirty mounts from the client fs]
|
dirty mounts from the client fs]
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Now you can go ahead and start modifying the underlying
|
Now you can go ahead and start modifying the underlying
|
||||||
filesystem. Almost.
|
filesystem. Almost.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
|
||||||
You still need to actually journal your filesystem changes, this
|
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,
|
need to call journal_get_{create,write,undo}_access() as appropriate,
|
||||||
this allows the journalling layer to copy the unmodified data if it
|
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
|
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
|
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().
|
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()
|
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.
|
in much the same way as you might have used bforget() in the past.
|
||||||
</para>
|
</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.
|
you can then call journal_destroy() to clean up your in-core journal object.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Unfortunately there a couple of ways the journal layer can cause a deadlock.
|
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
|
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
|
commits until the outermost journal_stop(). This means
|
||||||
you must complete the transaction at the end of each file/inode/address
|
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
|
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
|
across differing journals, and another filesystem other than
|
||||||
yours (say ext3) may be modified in a later syscall.
|
yours (say ext3) may be modified in a later syscall.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The second case to bear in mind is that journal_start() can
|
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
|
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
|
(based on the passed nblocks param) - when it blocks it merely(!) needs to
|
||||||
wait for transactions to complete and be committed from other tasks,
|
wait for transactions to complete and be committed from other tasks,
|
||||||
so essentially we are waiting for journal_stop(). So to avoid
|
so essentially we are waiting for journal_stop(). So to avoid
|
||||||
deadlocks you must treat journal_start/stop() as if they
|
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
|
deadlocks. Note that journal_extend() has similar blocking behaviour to
|
||||||
journal_start() so you can deadlock here just as easily as on journal_start().
|
journal_start() so you can deadlock here just as easily as on journal_start().
|
||||||
</para>
|
</para>
|
||||||
|
|
@ -184,7 +250,7 @@ journal_start() so you can deadlock here just as easily as on journal_start().
|
||||||
<para>
|
<para>
|
||||||
Try to reserve the right number of blocks the first time. ;-). This will
|
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.
|
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.
|
ext3 uses to make these decisions.
|
||||||
</para>
|
</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
|
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
|
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
|
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>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Lock is also providing through journal_{un,}lock_updates(),
|
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.
|
ext3 uses this when it wants a window with a clean and stable fs for a moment.
|
||||||
eg.
|
eg.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
|
|
@ -230,19 +296,19 @@ extend it like this:-
|
||||||
struct journal_callback for_jbd;
|
struct journal_callback for_jbd;
|
||||||
// Stuff for myfs allocated together.
|
// Stuff for myfs allocated together.
|
||||||
myfs_inode* i_commited;
|
myfs_inode* i_commited;
|
||||||
|
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
<para>
|
<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.
|
particular inode.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
</sect1>
|
</sect2>
|
||||||
|
|
||||||
<sect1>
|
<sect2>
|
||||||
<title>Summary</title>
|
<title>Summary</title>
|
||||||
<para>
|
<para>
|
||||||
Using the journal is a matter of wrapping the different context changes,
|
Using the journal is a matter of wrapping the different context changes,
|
||||||
being each mount, each modification (transaction) and each changed buffer
|
being each mount, each modification (transaction) and each changed buffer
|
||||||
|
|
@ -260,15 +326,15 @@ an example.
|
||||||
if (clean) journal_wipe();
|
if (clean) journal_wipe();
|
||||||
journal_load();
|
journal_load();
|
||||||
|
|
||||||
foreach(transaction) { /*transactions must be
|
foreach(transaction) { /*transactions must be
|
||||||
completed before
|
completed before
|
||||||
a syscall returns to
|
a syscall returns to
|
||||||
userspace*/
|
userspace*/
|
||||||
|
|
||||||
handle_t * xct=journal_start(my_jnrl);
|
handle_t * xct=journal_start(my_jnrl);
|
||||||
foreach(bh) {
|
foreach(bh) {
|
||||||
journal_get_{create,write,undo}_access(xact,bh);
|
journal_get_{create,write,undo}_access(xact,bh);
|
||||||
if ( myfs_modify(bh) ) { /* returns true
|
if ( myfs_modify(bh) ) { /* returns true
|
||||||
if makes changes */
|
if makes changes */
|
||||||
journal_dirty_{meta,}data(xact,bh);
|
journal_dirty_{meta,}data(xact,bh);
|
||||||
} else {
|
} else {
|
||||||
|
|
@ -279,55 +345,57 @@ an example.
|
||||||
}
|
}
|
||||||
journal_destroy(my_jrnl);
|
journal_destroy(my_jrnl);
|
||||||
</programlisting>
|
</programlisting>
|
||||||
</sect1>
|
</sect2>
|
||||||
|
|
||||||
</chapter>
|
</sect1>
|
||||||
|
|
||||||
<chapter id="adt">
|
<sect1>
|
||||||
<title>Data Types</title>
|
<title>Data Types</title>
|
||||||
<para>
|
<para>
|
||||||
The journalling layer uses typedefs to 'hide' the concrete definitions
|
The journalling layer uses typedefs to 'hide' the concrete definitions
|
||||||
of the structures used. As a client of the JBD layer you can
|
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.
|
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>
|
<title>Functions</title>
|
||||||
<para>
|
<para>
|
||||||
The functions here are split into two groups those that
|
The functions here are split into two groups those that
|
||||||
affect a journal as a whole, and those which are used to
|
affect a journal as a whole, and those which are used to
|
||||||
manage transactions
|
manage transactions
|
||||||
</para>
|
</para>
|
||||||
<sect1><title>Journal Level</title>
|
<sect2><title>Journal Level</title>
|
||||||
!Efs/jbd/journal.c
|
!Efs/jbd/journal.c
|
||||||
!Ifs/jbd/recovery.c
|
!Ifs/jbd/recovery.c
|
||||||
</sect1>
|
</sect2>
|
||||||
<sect1><title>Transasction Level</title>
|
<sect2><title>Transasction Level</title>
|
||||||
!Efs/jbd/transaction.c
|
!Efs/jbd/transaction.c
|
||||||
</sect1>
|
</sect2>
|
||||||
</chapter>
|
</sect1>
|
||||||
<chapter>
|
<sect1>
|
||||||
<title>See also</title>
|
<title>See also</title>
|
||||||
<para>
|
<para>
|
||||||
<citation>
|
<citation>
|
||||||
<ulink url="ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs/journal-design.ps.gz">
|
<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>
|
</ulink>
|
||||||
</citation>
|
</citation>
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
<citation>
|
<citation>
|
||||||
<ulink url="http://olstrans.sourceforge.net/release/OLS2000-ext3/OLS2000-ext3.html">
|
<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>
|
</ulink>
|
||||||
</citation>
|
</citation>
|
||||||
</para>
|
</para>
|
||||||
</chapter>
|
</sect1>
|
||||||
|
|
||||||
|
</chapter>
|
||||||
|
|
||||||
</book>
|
</book>
|
||||||
|
|
@ -182,66 +182,6 @@ X!Ilib/string.c
|
||||||
</sect1>
|
</sect1>
|
||||||
</chapter>
|
</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">
|
<chapter id="relayfs">
|
||||||
<title>relay interface support</title>
|
<title>relay interface support</title>
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -345,8 +345,7 @@ static inline void skel_delete (struct usb_skel *dev)
|
||||||
usb_buffer_free (dev->udev, dev->bulk_out_size,
|
usb_buffer_free (dev->udev, dev->bulk_out_size,
|
||||||
dev->bulk_out_buffer,
|
dev->bulk_out_buffer,
|
||||||
dev->write_urb->transfer_dma);
|
dev->write_urb->transfer_dma);
|
||||||
if (dev->write_urb != NULL)
|
usb_free_urb (dev->write_urb);
|
||||||
usb_free_urb (dev->write_urb);
|
|
||||||
kfree (dev);
|
kfree (dev);
|
||||||
}
|
}
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
|
||||||
|
|
@ -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
|
Mailing lists
|
||||||
-------------
|
-------------
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -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
|
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
|
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
|
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
|
For each MSI-X vector granted, a device driver is responsible for calling
|
||||||
other functions like request_irq(), enable_irq(), etc. to enable
|
other functions like request_irq(), enable_irq(), etc. to enable
|
||||||
|
|
@ -470,7 +470,68 @@ LOC: 324553 325068
|
||||||
ERR: 0
|
ERR: 0
|
||||||
MIS: 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?
|
Q1. Are there any limitations on using the MSI?
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -49,7 +49,7 @@ __u64 stime, utime;
|
||||||
}
|
}
|
||||||
|
|
||||||
/* Maximum size of response requested or message sent */
|
/* 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 */
|
/* Maximum number of cpus expected to be specified in a cpumask */
|
||||||
#define MAX_CPUS 32
|
#define MAX_CPUS 32
|
||||||
/* Maximum length of pathname to log file */
|
/* Maximum length of pathname to log 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.
|
a pid/tgid will be followed by some stats.
|
||||||
|
|
||||||
b) TASKSTATS_TYPE_PID/TGID: attribute whose payload is the pid/tgid whose 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.
|
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
|
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
|
However, maintaining per-process, in addition to per-task stats, within the
|
||||||
kernel has space and time overheads. To address this, the taskstats code
|
kernel has space and time overheads. To address this, the taskstats code
|
||||||
accumalates each exiting task's statistics into a process-wide data structure.
|
accumulates 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
|
When the last task of a process exits, the process level data accumulated also
|
||||||
gets sent to userspace (along with the per-task data).
|
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
|
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.
|
threads of the same thread group.
|
||||||
|
|
||||||
Extending taskstats
|
Extending taskstats
|
||||||
|
|
|
||||||
|
|
@ -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
|
modified to accomplish a direct page -> bus translation, without requiring
|
||||||
a virtual address mapping (unlike the earlier scheme of virtual address
|
a virtual address mapping (unlike the earlier scheme of virtual address
|
||||||
-> bus translation). So this works uniformly for high-memory pages (which
|
-> 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.
|
low-memory pages.
|
||||||
|
|
||||||
Note: Please refer to DMA-mapping.txt for a discussion on PCI high mem DMA
|
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
|
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.
|
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
|
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.
|
which were generated for each such chunk.
|
||||||
|
|
||||||
The following were some of the goals and expectations considered in the
|
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.
|
for raw i/o.
|
||||||
ii. Ability to represent high-memory buffers (which do not have a virtual
|
ii. Ability to represent high-memory buffers (which do not have a virtual
|
||||||
address mapping in kernel address space).
|
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)
|
greater than PAGE_SIZE chunks in one shot)
|
||||||
iv. At the same time, ability to retain independent identity of i/os from
|
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
|
different sources or i/o units requiring individual completion (e.g. for
|
||||||
latency reasons)
|
latency reasons)
|
||||||
v. Ability to represent an i/o involving multiple physical memory segments
|
v. Ability to represent an i/o involving multiple physical memory segments
|
||||||
(including non-page aligned page fragments, as specified via readv/writev)
|
(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.
|
handling it.
|
||||||
vi. Preferably should be based on a memory descriptor structure that can be
|
vi. Preferably should be based on a memory descriptor structure that can be
|
||||||
passed around different types of subsystems or layers, maybe even
|
passed around different types of subsystems or layers, maybe even
|
||||||
|
|
@ -1013,7 +1013,7 @@ Characteristics:
|
||||||
i. Binary tree
|
i. Binary tree
|
||||||
AS and deadline i/o schedulers use red black binary trees for disk position
|
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
|
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
|
almost always dispatched in disk sort order, so a cache is kept of the next
|
||||||
request in sort order to prevent binary tree lookups.
|
request in sort order to prevent binary tree lookups.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -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.
|
can be controlled independently from the PCI/AGP clock.
|
||||||
|
|
||||||
The module has two options:
|
The module has two options:
|
||||||
|
|
|
||||||
|
|
@ -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
|
maxcpus=2 will only boot 2. You can choose to bring the
|
||||||
other cpus later online, read FAQ's for more info.
|
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
|
cpu_possible_map = cpu_present_map + additional_cpus
|
||||||
|
|
||||||
(*) Option valid only for following architectures
|
(*) 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
|
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
|
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
|
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
|
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
|
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.
|
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.
|
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_possible_cpu - Iterate over cpu_possible_map
|
||||||
for_each_online_cpu - Iterate over cpu_online_map
|
for_each_online_cpu - Iterate over cpu_online_map
|
||||||
for_each_present_cpu - Iterate over cpu_present_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_cpu_mask(x,mask) - Iterate over some random collection of cpu mask.
|
||||||
|
|
||||||
#include <linux/cpu.h>
|
#include <linux/cpu.h>
|
||||||
lock_cpu_hotplug() and unlock_cpu_hotplug():
|
lock_cpu_hotplug() and unlock_cpu_hotplug():
|
||||||
|
|
||||||
The above calls are used to inhibit cpu hotplug operations. While holding the
|
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
|
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.
|
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
|
A: When doing make defconfig, Enable CPU hotplug support
|
||||||
|
|
||||||
"Processor type and Features" -> Support for Hotpluggable CPUs
|
"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
|
Check if sysfs is mounted, using the "mount" command. You should notice
|
||||||
an entry as shown below in the output.
|
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
|
#mkdir /sysfs
|
||||||
#mount -t sysfs sys /sys
|
#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.
|
in a 8-way system.
|
||||||
|
|
||||||
#pwd
|
#pwd
|
||||||
#/sys/devices/system/cpu
|
#/sys/devices/system/cpu
|
||||||
#ls -l
|
#ls -l
|
||||||
total 0
|
total 0
|
||||||
drwxr-xr-x 10 root root 0 Sep 19 07:44 .
|
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 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 cpu0
|
||||||
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu1
|
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 cpu2
|
||||||
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu3
|
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 cpu4
|
||||||
drwxr-xr-x 3 root root 0 Sep 19 07:44 cpu5
|
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:44 cpu6
|
||||||
drwxr-xr-x 3 root root 0 Sep 19 07:48 cpu7
|
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
|
Under each directory you would find an "online" file which is the control
|
||||||
file to logically online/offline a processor.
|
file to logically online/offline a processor.
|
||||||
|
|
||||||
Q: Does hot-add/hot-remove refer to physical add/remove of cpus?
|
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.
|
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
|
To support physical addition/removal, one would need some BIOS hooks and
|
||||||
the platform should have something like an attention button in PCI hotplug.
|
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.
|
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?
|
Q: How do i logically offline a CPU?
|
||||||
A: Do the following.
|
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.
|
the state as 0 when a cpu if offline and 1 when its online.
|
||||||
|
|
||||||
#To display the current cpu state.
|
#To display the current cpu state.
|
||||||
#cat /sys/devices/system/cpu/cpuX/online
|
#cat /sys/devices/system/cpu/cpuX/online
|
||||||
|
|
||||||
Q: Why cant i remove CPU0 on some systems?
|
Q: Why cant i remove CPU0 on some systems?
|
||||||
A: Some architectures may have some special dependency on a certain CPU.
|
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?
|
departure, how to i arrange for proper notification?
|
||||||
A: This is what you would need in your kernel code to receive notifications.
|
A: This is what you would need in your kernel code to receive notifications.
|
||||||
|
|
||||||
#include <linux/cpu.h>
|
#include <linux/cpu.h>
|
||||||
static int __cpuinit foobar_cpu_callback(struct notifier_block *nfb,
|
static int __cpuinit foobar_cpu_callback(struct notifier_block *nfb,
|
||||||
unsigned long action, void *hcpu)
|
unsigned long action, void *hcpu)
|
||||||
{
|
{
|
||||||
unsigned int cpu = (unsigned long)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.
|
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
|
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_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,
|
Q: If i would like to develop cpu hotplug support for a new architecture,
|
||||||
what do i need at a minimum?
|
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.
|
work specific to this cpu is in progress.
|
||||||
A: First switch the current thread context to preferred cpu
|
A: First switch the current thread context to preferred cpu
|
||||||
|
|
||||||
int my_func_on_cpu(int cpu)
|
int my_func_on_cpu(int cpu)
|
||||||
{
|
{
|
||||||
cpumask_t saved_mask, new_mask = CPU_MASK_NONE;
|
cpumask_t saved_mask, new_mask = CPU_MASK_NONE;
|
||||||
int curr_cpu, err = 0;
|
int curr_cpu, err = 0;
|
||||||
|
|
||||||
saved_mask = current->cpus_allowed;
|
saved_mask = current->cpus_allowed;
|
||||||
cpu_set(cpu, new_mask);
|
cpu_set(cpu, new_mask);
|
||||||
err = set_cpus_allowed(current, new_mask);
|
err = set_cpus_allowed(current, new_mask);
|
||||||
|
|
||||||
if (err)
|
if (err)
|
||||||
return err;
|
return err;
|
||||||
|
|
||||||
/*
|
/*
|
||||||
* If we got scheduled out just after the return from
|
* If we got scheduled out just after the return from
|
||||||
* set_cpus_allowed() before running the work, this ensures
|
* set_cpus_allowed() before running the work, this ensures
|
||||||
* we stay locked.
|
* we stay locked.
|
||||||
*/
|
*/
|
||||||
curr_cpu = get_cpu();
|
curr_cpu = get_cpu();
|
||||||
|
|
||||||
if (curr_cpu != cpu) {
|
if (curr_cpu != cpu) {
|
||||||
err = -EAGAIN;
|
err = -EAGAIN;
|
||||||
goto ret;
|
goto ret;
|
||||||
} else {
|
} else {
|
||||||
/*
|
/*
|
||||||
* Do work : But cant sleep, since get_cpu() disables preempt
|
* Do work : But cant sleep, since get_cpu() disables preempt
|
||||||
*/
|
*/
|
||||||
}
|
}
|
||||||
ret:
|
ret:
|
||||||
put_cpu();
|
put_cpu();
|
||||||
set_cpus_allowed(current, saved_mask);
|
set_cpus_allowed(current, saved_mask);
|
||||||
return err;
|
return err;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
||||||
Q: How do we determine how many CPUs are available for hotplug.
|
Q: How do we determine how many CPUs are available for hotplug.
|
||||||
|
|
|
||||||
|
|
@ -92,7 +92,7 @@ Your cooperation is appreciated.
|
||||||
7 = /dev/full Returns ENOSPC on write
|
7 = /dev/full Returns ENOSPC on write
|
||||||
8 = /dev/random Nondeterministic random number gen.
|
8 = /dev/random Nondeterministic random number gen.
|
||||||
9 = /dev/urandom Faster, less secure 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
|
11 = /dev/kmsg Writes to this come out as printk's
|
||||||
1 block RAM disk
|
1 block RAM disk
|
||||||
0 = /dev/ram0 First RAM disk
|
0 = /dev/ram0 First RAM disk
|
||||||
|
|
@ -1093,7 +1093,7 @@ Your cooperation is appreciated.
|
||||||
|
|
||||||
55 char DSP56001 digital signal processor
|
55 char DSP56001 digital signal processor
|
||||||
0 = /dev/dsp56k First DSP56001
|
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
|
0 = /dev/rd/c7d0 First disk, whole disk
|
||||||
8 = /dev/rd/c7d1 Second 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
|
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
|
0 = /dev/ida/c7d0 First logical drive whole disk
|
||||||
16 = /dev/ida/c7d1 Second 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
|
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
|
0 = /dev/cciss/c7d0 First logical drive, whole disk
|
||||||
16 = /dev/cciss/c7d1 Second logical drive, whole disk
|
16 = /dev/cciss/c7d1 Second logical drive, whole disk
|
||||||
...
|
...
|
||||||
|
|
|
||||||
|
|
@ -1,99 +1,131 @@
|
||||||
Platform Devices and Drivers
|
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
|
||||||
~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~
|
||||||
Platform devices are devices that typically appear as autonomous
|
Platform devices are devices that typically appear as autonomous
|
||||||
entities in the system. This includes legacy port-based devices and
|
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
|
Platform drivers
|
||||||
~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~
|
||||||
Drivers for platform devices are typically very simple and
|
Platform drivers follow the standard driver model convention, where
|
||||||
unstructured. Either the device was present at a particular I/O port
|
discovery/enumeration is handled outside the drivers, and drivers
|
||||||
and the driver was loaded, or it was not. There was no possibility
|
provide probe() and remove() methods. They support power management
|
||||||
of hotplugging or alternative discovery besides probing at a specific
|
and shutdown notifications using the standard conventions.
|
||||||
I/O address and expecting a specific response.
|
|
||||||
|
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
|
Device Enumeration
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~
|
||||||
These devices are not always at the legacy I/O ports. This is true on
|
As a rule, platform specific (and often board-specific) setup code wil
|
||||||
other architectures and on some modern architectures. In most cases,
|
register platform devices:
|
||||||
the drivers are modified to discover the devices at other well-known
|
|
||||||
ports for the given platform. However, the firmware in these systems
|
int platform_device_register(struct platform_device *pdev);
|
||||||
does usually know where exactly these devices reside, and in some
|
|
||||||
cases, it's the only way of discovering them.
|
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
|
Device Naming and Driver Binding
|
||||||
~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
A platform bus has been created to deal with these issues. First and
|
The platform_device.dev.bus_id is the canonical name for the devices.
|
||||||
foremost, it groups all the legacy devices under a common bus, and
|
It's built from two components:
|
||||||
gives them a common parent if they don't already have one.
|
|
||||||
|
|
||||||
But, besides the organizational benefits, the platform bus can also
|
* platform_device.name ... which is also used to for driver matching.
|
||||||
accommodate firmware-based enumeration.
|
|
||||||
|
|
||||||
|
* platform_device.id ... the device instance number, or else "-1"
|
||||||
|
to indicate there's only one.
|
||||||
|
|
||||||
Device Discovery
|
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
|
||||||
The platform bus has no concept of probing for devices. Devices
|
named "serial". While "my_rtc"/-1 would be bus_id "my_rtc" (no instance id)
|
||||||
discovery is left up to either the legacy drivers or the
|
and use the platform_driver called "my_rtc".
|
||||||
firmware. These entities are expected to notify the platform of
|
|
||||||
devices that it discovers via the bus's add() callback:
|
|
||||||
|
|
||||||
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
|
- When a driver is registered using platform_driver_register(), all
|
||||||
~~~~~~~
|
unbound devices on that bus are checked for matches. Drivers
|
||||||
Bus IDs are the canonical names for the devices. There is no globally
|
usually register later during booting, or by module loading.
|
||||||
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.
|
|
||||||
|
|
||||||
Since both PnP IDs and the legacy I/O ports (and other standard I/O
|
- Registering a driver using platform_driver_probe() works just like
|
||||||
ports for specific devices) have a 1:1 mapping, we map the
|
using platform_driver_register(), except that the the driver won't
|
||||||
platform-specific name or identifier to a generic name (at least
|
be probed later if another device registers. (Which is OK, since
|
||||||
within the scope of the kernel).
|
this interface is only for use with non-hotpluggable devices.)
|
||||||
|
|
||||||
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.
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -92,7 +92,7 @@ struct device represents a single device. It mainly contains metadata
|
||||||
describing the relationship the device has to other entities.
|
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 {
|
struct pci_dev {
|
||||||
|
|
|
||||||
|
|
@ -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 disadvantage is that the driver/hardware has to manage the rest. For
|
||||||
the application programmer it would be as simple as sending/receiving an
|
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
|
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 ?
|
* 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.
|
implemented by most applications. Hence this area is revisited.
|
||||||
|
|
||||||
This CI interface is quite different in the case that it tries to
|
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
|
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
|
Application layer only and no session management is taken care of by the
|
||||||
|
|
|
||||||
|
|
@ -62,7 +62,7 @@ res : root device I/O resource
|
||||||
bus_base_addr : slot 0 address on this bus
|
bus_base_addr : slot 0 address on this bus
|
||||||
slots : max slot number to probe
|
slots : max slot number to probe
|
||||||
force_probe : Probe even when slot 0 is empty (no EISA mainboard)
|
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
|
bus_nr : unique bus id, set by eisa_root_register
|
||||||
|
|
||||||
** Driver :
|
** Driver :
|
||||||
|
|
|
||||||
|
|
@ -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])
|
What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
|
||||||
When: November 2005
|
When: November 2005
|
||||||
Files: drivers/pcmcia/: pcmcia_ioctl.c
|
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)
|
What: remove EXPORT_SYMBOL(kernel_thread)
|
||||||
When: August 2006
|
When: August 2006
|
||||||
Files: arch/*/kernel/*_ksyms.c
|
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
|
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
|
Why: The stacking of class devices makes these values misleading and
|
||||||
inconsistent.
|
inconsistent.
|
||||||
Class devices should not carry any of these properties, and bus
|
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>
|
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>
|
||||||
|
|
||||||
|
---------------------------
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@ Mount options for ADFS
|
||||||
|
|
||||||
uid=nnn All files in the partition will be owned by
|
uid=nnn All files in the partition will be owned by
|
||||||
user id nnn. Default 0 (root).
|
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).
|
nnn. Default 0 (root).
|
||||||
ownmask=nnn The permission mask for ADFS 'owner' permissions
|
ownmask=nnn The permission mask for ADFS 'owner' permissions
|
||||||
will be nnn. Default 0700.
|
will be nnn. Default 0700.
|
||||||
|
|
|
||||||
|
|
@ -209,7 +209,7 @@ will happen for write(2).
|
||||||
|
|
||||||
[struct config_group]
|
[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
|
is via mkdir(2) on a config_group. This will trigger creation of a
|
||||||
child item.
|
child item.
|
||||||
|
|
||||||
|
|
@ -275,7 +275,7 @@ directory is not empty.
|
||||||
|
|
||||||
[struct configfs_subsystem]
|
[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.
|
tells configfs to make the subsystem appear in the file tree.
|
||||||
|
|
||||||
struct configfs_subsystem {
|
struct configfs_subsystem {
|
||||||
|
|
|
||||||
|
|
@ -111,7 +111,7 @@ For each connection the following files exist within this directory:
|
||||||
|
|
||||||
'waiting'
|
'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
|
userspace or being processed by the filesystem daemon. If there is
|
||||||
no filesystem activity and 'waiting' is non-zero, then the
|
no filesystem activity and 'waiting' is non-zero, then the
|
||||||
filesystem is hung or deadlocked.
|
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
|
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
|
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.
|
this flag is set, an INTERRUPT request is queued.
|
||||||
|
|
||||||
3) If the request is already sent to userspace, then an INTERRUPT
|
3) If the request is already sent to userspace, then an INTERRUPT
|
||||||
|
|
|
||||||
|
|
@ -274,7 +274,7 @@ History
|
||||||
Fixed race-condition in buffer code - it is in all filesystems in Linux;
|
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
|
when reading device (cat /dev/hda) while creating files on it, files
|
||||||
could be damaged
|
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
|
end of partition
|
||||||
2.03 Char, block devices and pipes are correctly created
|
2.03 Char, block devices and pipes are correctly created
|
||||||
Fixed non-crashing race in unlink (Alexander Viro)
|
Fixed non-crashing race in unlink (Alexander Viro)
|
||||||
|
|
|
||||||
|
|
@ -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):
|
this (note all values are in 512-byte sectors):
|
||||||
|
|
||||||
--- cut here ---
|
--- 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
|
# in of the type type of log size sync? of Device in Device in
|
||||||
# vol volume params mirrors Device Device
|
# vol volume params mirrors Device Device
|
||||||
0 2056320 mirror core 2 16 nosync 2 /dev/hda1 0 /dev/hdb1 0
|
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
|
- Major bug fixes for reading files and volumes in corner cases which
|
||||||
were being hit by Windows 2k/XP users.
|
were being hit by Windows 2k/XP users.
|
||||||
2.1.2:
|
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.
|
users.
|
||||||
2.1.1:
|
2.1.1:
|
||||||
- Update handling of compressed files so people no longer get the
|
- Update handling of compressed files so people no longer get the
|
||||||
|
|
|
||||||
|
|
@ -30,7 +30,7 @@ Caveats
|
||||||
Features which OCFS2 does not support yet:
|
Features which OCFS2 does not support yet:
|
||||||
- sparse files
|
- sparse files
|
||||||
- extended attributes
|
- extended attributes
|
||||||
- shared writeable mmap
|
- shared writable mmap
|
||||||
- loopback is supported, but data written will not
|
- loopback is supported, but data written will not
|
||||||
be cluster coherent.
|
be cluster coherent.
|
||||||
- quotas
|
- quotas
|
||||||
|
|
|
||||||
|
|
@ -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.
|
you probably should increase the lower_zone_protection setting.
|
||||||
|
|
||||||
The units of this tunable are fairly vague. It is approximately equal
|
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
|
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.
|
pagecache, so there is a cost.
|
||||||
|
|
||||||
The effects of this tunable may be observed by monitoring
|
The effects of this tunable may be observed by monitoring
|
||||||
|
|
@ -1538,10 +1538,10 @@ TCP settings
|
||||||
tcp_ecn
|
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
|
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
|
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 this sites. For more info
|
/proc/sys/net/ipv4/tcp_ecn if you want to talk to these sites. For more info
|
||||||
you could read RFC2481.
|
you could read RFC2481.
|
||||||
|
|
||||||
tcp_retrans_collapse
|
tcp_retrans_collapse
|
||||||
|
|
|
||||||
|
|
@ -210,7 +210,7 @@ FILES
|
||||||
/signal2
|
/signal2
|
||||||
The two signal notification channels of an SPU. These are read-write
|
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
|
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
|
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
|
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-
|
is reset to zero. The possible operations on an open signal1 or sig-
|
||||||
|
|
|
||||||
|
|
@ -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
|
please report them to linux_udf@hpesjro.fc.hp.com, which is the
|
||||||
developer's list.
|
developer's list.
|
||||||
|
|
||||||
Write support requires a block driver which supports writing. The current
|
Write support requires a block driver which supports writing. Currently
|
||||||
scsi and ide cdrom drivers do not support writing.
|
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:
|
The following mount options are supported:
|
||||||
|
|
|
||||||
|
|
@ -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
|
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
|
"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
|
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.
|
the kernel.
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -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
|
almost completely self-contained. The only external code used is the
|
||||||
sprintf family of functions.
|
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,
|
switch off on entry to an exception. That means unless manually disabled,
|
||||||
single-stepping will blithely go on stepping into things like interrupts.
|
single-stepping will blithely go on stepping into things like interrupts.
|
||||||
See gdbstub.txt for more information.
|
See gdbstub.txt for more information.
|
||||||
|
|
|
||||||
|
|
@ -24,7 +24,7 @@ Authors:
|
||||||
Frodo Looijaard <frodol@dds.nl>,
|
Frodo Looijaard <frodol@dds.nl>,
|
||||||
Philip Edelbrock <phil@netroedge.com>,
|
Philip Edelbrock <phil@netroedge.com>,
|
||||||
Michiel Rook <michiel@grendelproject.nl>,
|
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>
|
from Jean Delvare <khali@linux-fr.org>
|
||||||
|
|
||||||
Interface
|
Interface
|
||||||
|
|
|
||||||
|
|
@ -17,7 +17,7 @@ Thanks to Kris Chen from Fintek for answering technical questions and
|
||||||
providing additional documentation.
|
providing additional documentation.
|
||||||
|
|
||||||
Thanks to Chris Lin from Jetway for providing wiring schematics and
|
Thanks to Chris Lin from Jetway for providing wiring schematics and
|
||||||
anwsering technical questions.
|
answering technical questions.
|
||||||
|
|
||||||
|
|
||||||
Description
|
Description
|
||||||
|
|
|
||||||
|
|
@ -2,7 +2,7 @@ Kernel driver k8temp
|
||||||
====================
|
====================
|
||||||
|
|
||||||
Supported chips:
|
Supported chips:
|
||||||
* AMD K8 CPU
|
* AMD Athlon64/FX or Opteron CPUs
|
||||||
Prefix: 'k8temp'
|
Prefix: 'k8temp'
|
||||||
Addresses scanned: PCI space
|
Addresses scanned: PCI space
|
||||||
Datasheet: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/32559.pdf
|
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
|
Description
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
This driver permits reading temperature sensor(s) embedded inside AMD K8 CPUs.
|
This driver permits reading temperature sensor(s) embedded inside AMD K8
|
||||||
Official documentation says that it works from revision F of K8 core, but
|
family CPUs (Athlon64/FX, Opteron). Official documentation says that it works
|
||||||
in fact it seems to be implemented for all revisions of K8 except the first
|
from revision F of K8 core, but in fact it seems to be implemented for all
|
||||||
two revisions (SH-B0 and SH-B3).
|
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
|
There can be up to four temperature sensors inside single CPU. The driver
|
||||||
will auto-detect the sensors and will display only temperatures from
|
will auto-detect the sensors and will display only temperatures from
|
||||||
|
|
|
||||||
|
|
@ -2,12 +2,14 @@ Kernel driver smsc47m1
|
||||||
======================
|
======================
|
||||||
|
|
||||||
Supported chips:
|
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
|
Addresses scanned: none, address read from Super I/O config space
|
||||||
Prefix: 'smsc47m1'
|
Prefix: 'smsc47m1'
|
||||||
Datasheets:
|
Datasheets:
|
||||||
http://www.smsc.com/main/datasheets/47b27x.pdf
|
http://www.smsc.com/main/datasheets/47b27x.pdf
|
||||||
http://www.smsc.com/main/datasheets/47m10x.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/tools/discontinued/47m13x.pdf
|
||||||
http://www.smsc.com/main/datasheets/47m14x.pdf
|
http://www.smsc.com/main/datasheets/47m14x.pdf
|
||||||
http://www.smsc.com/main/tools/discontinued/47m15x.pdf
|
http://www.smsc.com/main/tools/discontinued/47m15x.pdf
|
||||||
|
|
|
||||||
|
|
@ -26,7 +26,7 @@ fan control mode).
|
||||||
Temperatures are measured in degrees Celsius and measurement resolution is 1
|
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
|
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
|
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
|
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
|
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:
|
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)
|
(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,
|
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.
|
fan speed increases (temp is higher) or decreases if lower than desired.
|
||||||
|
|
|
||||||
|
|
@ -390,5 +390,5 @@ mlord@pobox.com
|
||||||
Wed Apr 17 22:52:44 CEST 2002 edited by Marcin Dalecki, the current
|
Wed Apr 17 22:52:44 CEST 2002 edited by Marcin Dalecki, the current
|
||||||
maintainer.
|
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>
|
comments at 2.6.0-test4 time. Maciej Soltysiak <solt@dns.toxicfilms.tv>
|
||||||
|
|
|
||||||
|
|
@ -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) |
|
| 1 | M0HQ | JOY0DAT Horizontal Clock (quadrature) |
|
||||||
| 2 | M0V | JOY0DAT Vertical Clock |
|
| 2 | M0V | JOY0DAT Vertical Clock |
|
||||||
| 3 | M0VQ | JOY0DAT Vertical Clock (quadrature) |
|
| 3 | M0VQ | JOY0DAT Vertical Clock (quadrature) |
|
||||||
| 4 | M1V | JOY1DAT Horizontall Clock |
|
| 4 | M1V | JOY1DAT Horizontal Clock |
|
||||||
| 5 | M1VQ | JOY1DAT Horizontall Clock (quadrature) |
|
| 5 | M1VQ | JOY1DAT Horizontal Clock (quadrature) |
|
||||||
| 6 | M1V | JOY1DAT Vertical Clock |
|
| 6 | M1V | JOY1DAT Vertical Clock |
|
||||||
| 7 | M1VQ | JOY1DAT Vertical Clock (quadrature) |
|
| 7 | M1VQ | JOY1DAT Vertical Clock (quadrature) |
|
||||||
+--------+----------+-----------------------------------------+
|
+--------+----------+-----------------------------------------+
|
||||||
|
|
|
||||||
|
|
@ -103,7 +103,7 @@ LEFT=0x74 & RIGHT=0x75).
|
||||||
|
|
||||||
5.1 Joystick Event Reporting
|
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).
|
changed (i.e. for each opening or closing of a joystick switch or trigger).
|
||||||
|
|
||||||
The joystick event record is two bytes of the form:
|
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
|
9.7 SET MOUSE SCALE
|
||||||
|
|
||||||
0x0C
|
0x0C
|
||||||
X ; horizontal mouse ticks per internel X
|
X ; horizontal mouse ticks per internal X
|
||||||
Y ; vertical mouse ticks per internel Y
|
Y ; vertical mouse ticks per internal Y
|
||||||
|
|
||||||
This command sets the scale factor for the ABSOLUTE MOUSE POSITIONING mode.
|
This command sets the scale factor for the ABSOLUTE MOUSE POSITIONING mode.
|
||||||
In this mode, the specified number of mouse phase changes ('clicks') must
|
In this mode, the specified number of mouse phase changes ('clicks') must
|
||||||
|
|
@ -323,7 +323,7 @@ mouse position.
|
||||||
0x0F
|
0x0F
|
||||||
|
|
||||||
This command makes the origin of the Y axis to be at the bottom of the
|
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
|
mouse motion. This causes mouse motion toward the user to be negative in sign
|
||||||
and away from the user to be positive.
|
and away from the user to be positive.
|
||||||
|
|
||||||
|
|
@ -597,8 +597,8 @@ mode or FIRE BUTTON MONITORING mode.
|
||||||
|
|
||||||
10. SCAN CODES
|
10. SCAN CODES
|
||||||
|
|
||||||
The key scan codes return by the ikbd are chosen to simplify the
|
The key scan codes returned by the ikbd are chosen to simplify the
|
||||||
implementaion of GSX.
|
implementation of GSX.
|
||||||
|
|
||||||
GSX Standard Keyboard Mapping.
|
GSX Standard Keyboard Mapping.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -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.
|
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
|
Basically, this was hacked away in just a few hours, so don't expect
|
||||||
miracles.
|
miracles.
|
||||||
|
|
||||||
In particular, there is currently NO support for the rumble pack.
|
In particular, there is currently NO support for the rumble pack.
|
||||||
You won't find many ff-aware linux applications anyway.
|
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.
|
Driver updated for kernel 2.6.17.11. (Based on a patch for 2.6.11.4.)
|
||||||
This one is running a 2.4.18 kernel with usb-uhci on an amd athlon 600.
|
|
||||||
|
|
||||||
The jstest-program from joystick-1.2.15 (jstest-version 2.1.0) reports
|
The number of buttons/axes reported varies based on 3 things:
|
||||||
8 axes and 10 buttons.
|
- 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
|
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
|
is some limitation of jstest, since the input device setup should be fine. I
|
||||||
didn't have a look at jstest itself yet).
|
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.
|
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
|
1. USB adapter
|
||||||
--------------
|
--------------
|
||||||
|
|
||||||
Before you can actually use the driver, you need to get yourself an
|
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
|
Such a cable is pretty easy to build. The Controller itself is a USB
|
||||||
device (a hub with three ports for two expansion slots and the controller
|
compound device (a hub with three ports for two expansion slots and
|
||||||
device) with the only difference in a nonstandard connector (5 pins vs. 4 on
|
the controller device) with the only difference in a nonstandard connector
|
||||||
standard USB connector).
|
(5 pins vs. 4 on standard USB connector).
|
||||||
|
|
||||||
You just need to solder a USB connector onto the cable and keep the
|
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
|
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 ;)
|
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
|
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.
|
to load your USB subsystem and should cat /proc/bus/usb/devices.
|
||||||
There should be an entry like the one at the end [4].
|
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
|
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
|
original Microsoft XBOX controller (Japan), vendor=0x045e, product=0x0285
|
||||||
InterAct PowerPad Pro (Germany), vendor=0x05fd, product=0x107a
|
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
|
The driver should work with xbox pads not listed above as well, however
|
||||||
by the driver, please drop me a line with the appropriate info (that is, include
|
you will need to do something extra for dance pads to work.
|
||||||
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).
|
|
||||||
|
|
||||||
In theory, the driver should work with other controllers than mine
|
If you have a controller not listed above, see 0.3 - Unknown Controllers
|
||||||
(InterAct PowerPad pro, bought in Germany) just fine, but I cannot test this
|
|
||||||
for I only have this one controller.
|
|
||||||
|
|
||||||
If you compiled and installed the driver, test the functionality:
|
If you compiled and installed the driver, test the functionality:
|
||||||
> modprobe xpad
|
> modprobe xpad
|
||||||
> modprobe joydev
|
> modprobe joydev
|
||||||
> jstest /dev/js0
|
> jstest /dev/js0
|
||||||
|
|
||||||
There should be a single line showing 18 inputs (8 axes, 10 buttons), and
|
If you're using a normal controller, there should be a single line showing
|
||||||
it's values should change if you move the sticks and push the buttons.
|
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
|
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=81(I) Atr=03(Int.) MxPS= 32 Ivl= 10ms
|
||||||
E: Ad=02(O) 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>
|
Marko Friedemann <mfr@bmx-chemnitz.de>
|
||||||
2002-07-16
|
2002-07-16
|
||||||
|
- original doc
|
||||||
|
|
||||||
|
Dominic Cerquetti <binary1230@yahoo.com>
|
||||||
|
2005-03-19
|
||||||
|
- added stuff for dance pads, new d-pad->axes mappings
|
||||||
|
|
|
||||||
|
|
@ -134,7 +134,7 @@ Reading /sys/../lineX will return the format string with its current value:
|
||||||
888888888888
|
888888888888
|
||||||
Linux Rocks!
|
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.
|
- Excess characters are ignored.
|
||||||
- If less characters are written than allowed, the remaining digits are
|
- If less characters are written than allowed, the remaining digits are
|
||||||
unchanged.
|
unchanged.
|
||||||
|
|
|
||||||
|
|
@ -735,7 +735,7 @@ CDROM_DISC_STATUS Get disc type, etc.
|
||||||
Ok, this is where problems start. The current interface for
|
Ok, this is where problems start. The current interface for
|
||||||
the CDROM_DISC_STATUS ioctl is flawed. It makes the false
|
the CDROM_DISC_STATUS ioctl is flawed. It makes the false
|
||||||
assumption that CDs are all CDS_DATA_1 or all CDS_AUDIO, etc.
|
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
|
very common for CDs to have some tracks with data, and some
|
||||||
tracks with audio. Just because I feel like it, I declare
|
tracks with audio. Just because I feel like it, I declare
|
||||||
the following to be the best way to cope. If the CD has
|
the following to be the best way to cope. If the CD has
|
||||||
|
|
|
||||||
|
|
@ -227,9 +227,9 @@ more details, with real examples.
|
||||||
be included in a library, lib.a.
|
be included in a library, lib.a.
|
||||||
All objects listed with lib-y are combined in a single
|
All objects listed with lib-y are combined in a single
|
||||||
library for that directory.
|
library for that directory.
|
||||||
Objects that are listed in obj-y and additionaly listed in
|
Objects that are listed in obj-y and additionally listed in
|
||||||
lib-y will not be included in the library, since they will anyway
|
lib-y will not be included in the library, since they will
|
||||||
be accessible.
|
be accessible anyway.
|
||||||
For consistency, objects listed in lib-m will be included in lib.a.
|
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
|
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.
|
Host programs can be made up based on composite objects.
|
||||||
The syntax used to define composite objects for host programs is
|
The syntax used to define composite objects for host programs is
|
||||||
similar to the syntax used for kernel objects.
|
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.
|
executable.
|
||||||
|
|
||||||
Example:
|
Example:
|
||||||
|
|
@ -1022,7 +1022,7 @@ When kbuild executes, the following steps are followed (roughly):
|
||||||
In this example, there are two possible targets, requiring different
|
In this example, there are two possible targets, requiring different
|
||||||
options to the linker. The linker options are specified using the
|
options to the linker. The linker options are specified using the
|
||||||
LDFLAGS_$@ syntax - one for each potential target.
|
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:
|
the targets and will:
|
||||||
1) check for commandline changes
|
1) check for commandline changes
|
||||||
2) delete target during make clean
|
2) delete target during make clean
|
||||||
|
|
|
||||||
|
|
@ -17,7 +17,7 @@ are:
|
||||||
special place-holders for where the extracted documentation should
|
special place-holders for where the extracted documentation should
|
||||||
go.
|
go.
|
||||||
|
|
||||||
- scripts/docproc.c
|
- scripts/basic/docproc.c
|
||||||
|
|
||||||
This is a program for converting SGML template files into SGML
|
This is a program for converting SGML template files into SGML
|
||||||
files. When a file is referenced it is searched for symbols
|
files. When a file is referenced it is searched for symbols
|
||||||
|
|
|
||||||
|
|
@ -164,6 +164,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
acpi_skip_timer_override [HW,ACPI]
|
acpi_skip_timer_override [HW,ACPI]
|
||||||
Recognize and ignore IRQ0/pin2 Interrupt Override.
|
Recognize and ignore IRQ0/pin2 Interrupt Override.
|
||||||
For broken nForce2 BIOS resulting in XT-PIC timer.
|
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]
|
acpi_dbg_layer= [HW,ACPI]
|
||||||
Format: <int>
|
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
|
machine check when some devices' config space
|
||||||
is read. But various workarounds are disabled
|
is read. But various workarounds are disabled
|
||||||
and some IOMMU drivers will not work.
|
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
|
pcmv= [HW,PCMCIA] BadgePAD 4
|
||||||
|
|
||||||
pd. [PARIDE]
|
pd. [PARIDE]
|
||||||
|
|
|
||||||
|
|
@ -304,7 +304,7 @@ about the status of the key service:
|
||||||
R Revoked
|
R Revoked
|
||||||
D Dead
|
D Dead
|
||||||
Q Contributes to user's quota
|
Q Contributes to user's quota
|
||||||
U Under contruction by callback to userspace
|
U Under construction by callback to userspace
|
||||||
N Negative key
|
N Negative key
|
||||||
|
|
||||||
This file must be enabled at kernel configuration time as it allows anyone
|
This file must be enabled at kernel configuration time as it allows anyone
|
||||||
|
|
|
||||||
|
|
@ -442,9 +442,10 @@ static int __init kprobe_init(void)
|
||||||
kp.fault_handler = handler_fault;
|
kp.fault_handler = handler_fault;
|
||||||
kp.symbol_name = "do_fork";
|
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);
|
printk("register_kprobe failed, returned %d\n", ret);
|
||||||
return -1;
|
return ret;
|
||||||
}
|
}
|
||||||
printk("kprobe registered\n");
|
printk("kprobe registered\n");
|
||||||
return 0;
|
return 0;
|
||||||
|
|
|
||||||
|
|
@ -121,7 +121,7 @@ contains the following options:
|
||||||
MAX_AGE:
|
MAX_AGE:
|
||||||
|
|
||||||
Maximum time, in seconds, of hard drive spindown time that you are
|
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.
|
amount of work if your battery fails while you're in laptop mode.
|
||||||
|
|
||||||
MINIMUM_BATTERY_MINUTES:
|
MINIMUM_BATTERY_MINUTES:
|
||||||
|
|
@ -235,7 +235,7 @@ It should be installed as /etc/default/laptop-mode on Debian, and as
|
||||||
|
|
||||||
--------------------CONFIG FILE BEGIN-------------------------------------------
|
--------------------CONFIG FILE BEGIN-------------------------------------------
|
||||||
# Maximum time, in seconds, of hard drive spindown time that you are
|
# 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.
|
# amount of work if your battery fails you while in laptop mode.
|
||||||
#MAX_AGE=600
|
#MAX_AGE=600
|
||||||
|
|
||||||
|
|
@ -350,7 +350,7 @@ fi
|
||||||
# set defaults instead:
|
# set defaults instead:
|
||||||
|
|
||||||
# Maximum time, in seconds, of hard drive spindown time that you are
|
# 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.
|
# amount of work if your battery fails you while in laptop mode.
|
||||||
MAX_AGE=${MAX_AGE:-'600'}
|
MAX_AGE=${MAX_AGE:-'600'}
|
||||||
|
|
||||||
|
|
@ -699,7 +699,7 @@ ACPI integration
|
||||||
Dax Kelson submitted this so that the ACPI acpid daemon will
|
Dax Kelson submitted this so that the ACPI acpid daemon will
|
||||||
kick off the laptop_mode script and run hdparm. The part that
|
kick off the laptop_mode script and run hdparm. The part that
|
||||||
automatically disables laptop mode when the battery is low was
|
automatically disables laptop mode when the battery is low was
|
||||||
writen by Jan Topinski.
|
written by Jan Topinski.
|
||||||
|
|
||||||
-----------------/etc/acpi/events/ac_adapter BEGIN------------------------------
|
-----------------/etc/acpi/events/ac_adapter BEGIN------------------------------
|
||||||
event=ac_adapter
|
event=ac_adapter
|
||||||
|
|
|
||||||
|
|
@ -212,7 +212,7 @@ There are some minimal guarantees that may be expected of a CPU:
|
||||||
|
|
||||||
STORE *X = c, d = LOAD *X
|
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).
|
memory).
|
||||||
|
|
||||||
And there are a number of things that _must_ or _must_not_ be assumed:
|
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)
|
(*) 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
|
barrier after it, depending on the function. It isn't guaranteed to
|
||||||
insert anything more than a compiler barrier in a UP compilation.
|
insert anything more than a compiler barrier in a UP compilation.
|
||||||
|
|
||||||
|
|
@ -1898,7 +1898,7 @@ queue before processing any further requests:
|
||||||
smp_wmb();
|
smp_wmb();
|
||||||
<A:modify v=2> <C:busy>
|
<A:modify v=2> <C:busy>
|
||||||
<C:queue v=2>
|
<C:queue v=2>
|
||||||
p = &b; q = p;
|
p = &v; q = p;
|
||||||
<D:request p>
|
<D:request p>
|
||||||
<B:modify p=&v> <D:commit p=&v>
|
<B:modify p=&v> <D:commit p=&v>
|
||||||
<D:read p>
|
<D:read p>
|
||||||
|
|
|
||||||
|
|
@ -38,19 +38,14 @@ The new time code provide the following services:
|
||||||
|
|
||||||
a) Implements functions required by Linux common code:
|
a) Implements functions required by Linux common code:
|
||||||
time_init
|
time_init
|
||||||
do_gettimeofday
|
|
||||||
do_settimeofday
|
|
||||||
|
|
||||||
b) provides an abstraction of RTC and null RTC implementation as default.
|
b) provides an abstraction of RTC and null RTC implementation as default.
|
||||||
extern unsigned long (*rtc_get_time)(void);
|
extern unsigned long (*rtc_get_time)(void);
|
||||||
extern int (*rtc_set_time)(unsigned long);
|
extern int (*rtc_set_time)(unsigned long);
|
||||||
|
|
||||||
c) a set of gettimeoffset functions for different CPUs and different
|
c) high-level and low-level timer interrupt routines where the timer
|
||||||
needs.
|
interrupt source may or may not be the CPU timer. The high-level
|
||||||
|
routine is dispatched through do_IRQ() while the low-level is
|
||||||
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
|
|
||||||
dispatched in assemably code (usually int-handler.S)
|
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
|
a) board_time_init - a function pointer. Invoked at the beginnig of
|
||||||
time_init(). It is optional.
|
time_init(). It is optional.
|
||||||
1. (optional) set up RTC routines
|
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()
|
b) plat_timer_setup - a function pointer. Invoked at the end of time_init()
|
||||||
1. (optional) over-ride any decisions made in 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.
|
c) (optional) board-specific RTC routines.
|
||||||
|
|
||||||
d) (optional) mips_counter_frequency - It must be definied if the board
|
d) (optional) mips_hpt_frequency - It must be definied if the board
|
||||||
is using CPU counter for timer interrupt or it is using fixed rate
|
is using CPU counter for timer interrupt.
|
||||||
gettimeoffset().
|
|
||||||
|
|
||||||
|
|
||||||
PORTING GUIDE
|
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
|
If the answer is no, you need a timer to provide the timer interrupt
|
||||||
at 100 HZ speed.
|
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.
|
c) The following sub steps assume your CPU has counter register.
|
||||||
Do you plan to use the CPU counter register as the timer interrupt
|
Do you plan to use the CPU counter register as the timer interrupt
|
||||||
or use an exnternal timer?
|
or use an exnternal timer?
|
||||||
|
|
||||||
In order to use CPU counter register as the timer interrupt source, you
|
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.
|
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
|
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.
|
if needed.
|
||||||
|
|
||||||
board_time_init() -
|
board_time_init() -
|
||||||
a) (optional) set up RTC routines,
|
a) (optional) set up RTC routines,
|
||||||
b) (optional) calibrate and set the mips_counter_frequency
|
b) (optional) calibrate and set the mips_hpt_frequency
|
||||||
(only needed if you intended to use fixed_rate_gettimeoffset
|
(only needed if you intended to use cpu counter as timer interrupt
|
||||||
or use cpu counter as timer interrupt source)
|
source)
|
||||||
|
|
||||||
plat_timer_setup() -
|
plat_timer_setup() -
|
||||||
a) (optional) over-write any choices made above by time_init().
|
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
|
For example, you may define your own timer interrupt routine, which does
|
||||||
some of its own processing and then calls timer_interrupt().
|
some of its own processing and then calls timer_interrupt().
|
||||||
|
|
||||||
You can also over-ride any of the built-in functions (gettimeoffset,
|
You can also over-ride any of the built-in functions (RTC routines
|
||||||
RTC routines and/or timer interrupt routine).
|
and/or timer interrupt routine).
|
||||||
|
|
||||||
|
|
||||||
PORTING NOTES FOR SMP
|
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,
|
You can also do the low-level version of those interrupt routines,
|
||||||
following similar dispatching routes described above.
|
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.
|
|
||||||
|
|
|
||||||
|
|
@ -95,8 +95,8 @@ There are two types of event register ACK mechanisms.
|
||||||
Move all to dev->poll()
|
Move all to dev->poll()
|
||||||
|
|
||||||
C) Ability to detect new work correctly.
|
C) Ability to detect new work correctly.
|
||||||
NAPI works by shutting down event interrupts when theres work and
|
NAPI works by shutting down event interrupts when there's work and
|
||||||
turning them on when theres none.
|
turning them on when there's none.
|
||||||
New packets might show up in the small window while interrupts were being
|
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
|
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
|
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
|
only one CPU can pick the initial interrupt and hence the initial
|
||||||
netif_rx_schedule(dev);
|
netif_rx_schedule(dev);
|
||||||
- The core layer invokes devices to send packets in a round robin format.
|
- 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.
|
one CPU is executing it.
|
||||||
- contention can only be the result of some other CPU accessing the rx
|
- contention can only be the result of some other CPU accessing the rx
|
||||||
ring. This happens only in close() and suspend() (when these methods
|
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 */
|
an interrupt will be generated */
|
||||||
goto done;
|
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
|
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
|
they'll be caught by the while check and we go back and clear them
|
||||||
since we havent exceeded our quota */
|
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
|
* 1. it can race with disabling irqs in irq handler (which are done to
|
||||||
* schedule polls)
|
* schedule polls)
|
||||||
* 2. it can race with dis/enabling irqs in other poll threads
|
* 2. it can race with dis/enabling irqs in other poll threads
|
||||||
* 3. if an irq raised after the begining of the outer beginning
|
* 3. if an irq raised after the beginning of the outer beginning
|
||||||
* loop(marked in the code above), it will be immediately
|
* loop (marked in the code above), it will be immediately
|
||||||
* triggered here.
|
* 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
|
* due to races in masking and due to too late acking of already
|
||||||
* processed irqs. The good news: no events are ever lost.
|
* processed irqs. The good news: no events are ever lost.
|
||||||
*/
|
*/
|
||||||
|
|
@ -601,7 +601,7 @@ a)
|
||||||
|
|
||||||
5) dev->close() and dev->suspend() issues
|
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.
|
care of it.
|
||||||
|
|
||||||
6) Adding new Stats to /proc
|
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.
|
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
|
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
|
much of a commodity feature (both in NICs and switches) and hence falls
|
||||||
under the same category as using NIC based mitigation. Also experiments
|
under the same category as using NIC based mitigation. Also, experiments
|
||||||
indicate that its much harder to resolve the resource allocation
|
indicate that it's much harder to resolve the resource allocation
|
||||||
issue (aka lazy receiving that NAPI offers) and hence quantify its usefullness
|
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
|
proved harder. In any case, FC works even better with NAPI but is not
|
||||||
necessary.
|
necessary.
|
||||||
|
|
||||||
|
|
@ -678,10 +678,10 @@ routine:
|
||||||
CSR5 bit of interest is only the rx status.
|
CSR5 bit of interest is only the rx status.
|
||||||
If you look at the last if statement:
|
If you look at the last if statement:
|
||||||
you just finished grabbing all the packets from the rx ring .. you check if
|
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,
|
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
|
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.
|
to register the new packet for processing.
|
||||||
|
|
||||||
[The above description nay be very verbose, if you have better wording
|
[The above description nay be very verbose, if you have better wording
|
||||||
|
|
|
||||||
|
|
@ -248,7 +248,7 @@ c) The driver's hardware probe routine is designed to avoid
|
||||||
with device probing. To avoid this behaviour, add one
|
with device probing. To avoid this behaviour, add one
|
||||||
to the `io=' module parameter. This doesn't actually change
|
to the `io=' module parameter. This doesn't actually change
|
||||||
the I/O address, but it is a flag to tell the driver
|
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
|
identify the card. This could be dangerous if you are
|
||||||
not sure that there is a cs89x0 card at the provided address.
|
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)
|
12 Mouse (PS/2)
|
||||||
Memory Address Device 13 Math Coprocessor
|
Memory Address Device 13 Math Coprocessor
|
||||||
-------------- --------------------- 14 Hard Disk controller
|
-------------- --------------------- 14 Hard Disk controller
|
||||||
A000-BFFF EGA Graphics Adpater
|
A000-BFFF EGA Graphics Adapter
|
||||||
A000-C7FF VGA Graphics Adpater
|
A000-C7FF VGA Graphics Adapter
|
||||||
B000-BFFF Mono Graphics Adapter
|
B000-BFFF Mono Graphics Adapter
|
||||||
B800-BFFF Color Graphics Adapter
|
B800-BFFF Color Graphics Adapter
|
||||||
E000-FFFF AT BIOS
|
E000-FFFF AT BIOS
|
||||||
|
|
|
||||||
|
|
@ -19,21 +19,17 @@ for real time and multimedia traffic.
|
||||||
|
|
||||||
It has a base protocol and pluggable congestion control IDs (CCIDs).
|
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:
|
It is at experimental RFC status and the homepage for DCCP as a protocol is at:
|
||||||
http://www.icir.org/kohler/dcp/
|
http://www.read.cs.ucla.edu/dccp/
|
||||||
|
|
||||||
Missing features
|
Missing features
|
||||||
================
|
================
|
||||||
|
|
||||||
The DCCP implementation does not currently have all the features that are in
|
The DCCP implementation does not currently have all the features that are in
|
||||||
the draft RFC.
|
the RFC.
|
||||||
|
|
||||||
In particular the following are missing:
|
The known bugs are at:
|
||||||
- CCID2 support
|
http://linux-net.osdl.org/index.php/TODO#DCCP
|
||||||
- feature negotiation
|
|
||||||
|
|
||||||
When testing against other implementations it appears that elapsed time
|
|
||||||
options are not coded compliant to the specification.
|
|
||||||
|
|
||||||
Socket options
|
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
|
is present). Connecting sockets set at most one service option; for
|
||||||
listening sockets, multiple service codes can be specified.
|
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
|
Notes
|
||||||
=====
|
=====
|
||||||
|
|
||||||
SELinux does not yet have support for DCCP. You will need to turn it off or
|
DCCP does not travel through NAT successfully at present on many boxes. This is
|
||||||
else you will get EACCES.
|
because the checksum covers the psuedo-header as per TCP and UDP. Linux NAT
|
||||||
|
support for DCCP has been added.
|
||||||
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.
|
|
||||||
|
|
|
||||||
|
|
@ -1,7 +1,7 @@
|
||||||
Linux* Base Driver for the Intel(R) PRO/1000 Family of Adapters
|
Linux* Base Driver for the Intel(R) PRO/1000 Family of Adapters
|
||||||
===============================================================
|
===============================================================
|
||||||
|
|
||||||
November 15, 2005
|
September 26, 2006
|
||||||
|
|
||||||
|
|
||||||
Contents
|
Contents
|
||||||
|
|
@ -9,6 +9,7 @@ Contents
|
||||||
|
|
||||||
- In This Release
|
- In This Release
|
||||||
- Identifying Your Adapter
|
- Identifying Your Adapter
|
||||||
|
- Building and Installation
|
||||||
- Command Line Parameters
|
- Command Line Parameters
|
||||||
- Speed and Duplex Configuration
|
- Speed and Duplex Configuration
|
||||||
- Additional Configurations
|
- 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
|
Instructions on updating ethtool can be found in the section "Additional
|
||||||
Configurations" later in this document.
|
Configurations" later in this document.
|
||||||
|
|
||||||
|
NOTE: The Intel(R) 82562v 10/100 Network Connection only provides 10/100
|
||||||
|
support.
|
||||||
|
|
||||||
|
|
||||||
Identifying Your Adapter
|
Identifying Your Adapter
|
||||||
========================
|
========================
|
||||||
|
|
@ -51,28 +55,27 @@ Driver ID Guide at:
|
||||||
http://support.intel.com/support/network/adapter/pro100/21397.htm
|
http://support.intel.com/support/network/adapter/pro100/21397.htm
|
||||||
|
|
||||||
For the latest Intel network drivers for Linux, refer to the following
|
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:
|
networking link on the left to search for your adapter:
|
||||||
|
|
||||||
http://downloadfinder.intel.com/scripts-df/support_intel.asp
|
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
|
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
|
are used by entering them on the command line with the modprobe command
|
||||||
command using this syntax:
|
using this syntax:
|
||||||
|
|
||||||
modprobe e1000 [<option>=<VAL1>,<VAL2>,...]
|
modprobe e1000 [<option>=<VAL1>,<VAL2>,...]
|
||||||
|
|
||||||
insmod e1000 [<option>=<VAL1>,<VAL2>,...]
|
|
||||||
|
|
||||||
For example, with two PRO/1000 PCI adapters, entering:
|
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
|
loads the e1000 driver with 80 TX descriptors for the first adapter and
|
||||||
TX descriptors for the second adapter.
|
128 TX descriptors for the second adapter.
|
||||||
|
|
||||||
The default value for each parameter is generally the recommended setting,
|
The default value for each parameter is generally the recommended setting,
|
||||||
unless otherwise noted.
|
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
|
http://www.intel.com/design/network/applnots/ap450.htm
|
||||||
|
|
||||||
A descriptor describes a data buffer and attributes related to
|
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
|
AutoNeg
|
||||||
|
|
@ -96,9 +99,9 @@ AutoNeg
|
||||||
Valid Range: 0x01-0x0F, 0x20-0x2F
|
Valid Range: 0x01-0x0F, 0x20-0x2F
|
||||||
Default Value: 0x2F
|
Default Value: 0x2F
|
||||||
|
|
||||||
This parameter is a bit mask that specifies which speed and duplex
|
This parameter is a bit-mask that specifies the speed and duplex settings
|
||||||
settings the board advertises. When this parameter is used, the Speed
|
advertised by the adapter. When this parameter is used, the Speed and
|
||||||
and Duplex parameters must not be specified.
|
Duplex parameters must not be specified.
|
||||||
|
|
||||||
NOTE: Refer to the Speed and Duplex section of this readme for more
|
NOTE: Refer to the Speed and Duplex section of this readme for more
|
||||||
information on the AutoNeg parameter.
|
information on the AutoNeg parameter.
|
||||||
|
|
@ -110,14 +113,15 @@ Duplex
|
||||||
Valid Range: 0-2 (0=auto-negotiate, 1=half, 2=full)
|
Valid Range: 0-2 (0=auto-negotiate, 1=half, 2=full)
|
||||||
Default Value: 0
|
Default Value: 0
|
||||||
|
|
||||||
Defines the direction in which data is allowed to flow. Can be either
|
This defines the direction in which data is allowed to flow. Can be
|
||||||
one or two-directional. If both Duplex and the link partner are set to
|
either one or two-directional. If both Duplex and the link partner are
|
||||||
auto-negotiate, the board auto-detects the correct duplex. If the link
|
set to auto-negotiate, the board auto-detects the correct duplex. If the
|
||||||
partner is forced (either full or half), Duplex defaults to half-duplex.
|
link partner is forced (either full or half), Duplex defaults to half-
|
||||||
|
duplex.
|
||||||
|
|
||||||
|
|
||||||
FlowControl
|
FlowControl
|
||||||
----------
|
-----------
|
||||||
Valid Range: 0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx)
|
Valid Range: 0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx)
|
||||||
Default Value: Reads flow control settings from the EEPROM
|
Default Value: Reads flow control settings from the EEPROM
|
||||||
|
|
||||||
|
|
@ -127,57 +131,107 @@ to Ethernet PAUSE frames.
|
||||||
|
|
||||||
InterruptThrottleRate
|
InterruptThrottleRate
|
||||||
---------------------
|
---------------------
|
||||||
(not supported on Intel 82542, 82543 or 82544-based adapters)
|
(not supported on Intel(R) 82542, 82543 or 82544-based adapters)
|
||||||
Valid Range: 100-100000 (0=off, 1=dynamic)
|
Valid Range: 0,1,3,100-100000 (0=off, 1=dynamic, 3=dynamic conservative)
|
||||||
Default Value: 8000
|
Default Value: 3
|
||||||
|
|
||||||
This value represents the maximum number of interrupts per second the
|
The driver can limit the amount of interrupts per second that the adapter
|
||||||
controller generates. InterruptThrottleRate is another setting used in
|
will generate for incoming packets. It does this by writing a value to the
|
||||||
interrupt moderation. Dynamic mode uses a heuristic algorithm to adjust
|
adapter that is based on the maximum amount of interrupts that the adapter
|
||||||
InterruptThrottleRate based on the current traffic load.
|
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
|
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
|
and/or transmit absolute delays does not force the controller to
|
||||||
generate more interrupts than what the Interrupt Throttle Rate
|
generate more interrupts than what the Interrupt Throttle Rate
|
||||||
allows.
|
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
|
(controller 82547), setting InterruptThrottleRate to a value
|
||||||
greater than 75,000, may hang (stop transmitting) adapters
|
greater than 75,000, may hang (stop transmitting) adapters
|
||||||
under certain network conditions. If this occurs a NETDEV
|
under certain network conditions. If this occurs a NETDEV
|
||||||
WATCHDOG message is logged in the system event log. In
|
WATCHDOG message is logged in the system event log. In
|
||||||
addition, the controller is automatically reset, restoring
|
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
|
hang, ensure that InterruptThrottleRate is set no greater
|
||||||
than 75,000 and is not set to 0.
|
than 75,000 and is not set to 0.
|
||||||
|
|
||||||
NOTE: When e1000 is loaded with default settings and multiple adapters
|
NOTE: When e1000 is loaded with default settings and multiple adapters
|
||||||
are in use simultaneously, the CPU utilization may increase non-
|
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
|
the overall throughput, we recommend that you load the driver as
|
||||||
follows:
|
follows:
|
||||||
|
|
||||||
insmod e1000.o InterruptThrottleRate=3000,3000,3000
|
modprobe e1000 InterruptThrottleRate=3000,3000,3000
|
||||||
|
|
||||||
This sets the InterruptThrottleRate to 3000 interrupts/sec for
|
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
|
of 2000 to 3000 interrupts per second works on a majority of
|
||||||
systems and is a good starting point, but the optimal value will
|
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.
|
RX_POLLING (NAPI) and default driver settings.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
RxDescriptors
|
RxDescriptors
|
||||||
-------------
|
-------------
|
||||||
Valid Range: 80-256 for 82542 and 82543-based adapters
|
Valid Range: 80-256 for 82542 and 82543-based adapters
|
||||||
80-4096 for all other supported adapters
|
80-4096 for all other supported adapters
|
||||||
Default Value: 256
|
Default Value: 256
|
||||||
|
|
||||||
This value specifies the number of receive descriptors allocated by the
|
This value specifies the number of receive buffer descriptors allocated
|
||||||
driver. Increasing this value allows the driver to buffer more incoming
|
by the driver. Increasing this value allows the driver to buffer more
|
||||||
packets. Each descriptor is 16 bytes. A receive buffer is also
|
incoming packets, at the expense of increased system memory utilization.
|
||||||
allocated for each descriptor and is 2048.
|
|
||||||
|
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
|
RxIntDelay
|
||||||
|
|
@ -187,17 +241,17 @@ Default Value: 0
|
||||||
|
|
||||||
This value delays the generation of receive interrupts in units of 1.024
|
This value delays the generation of receive interrupts in units of 1.024
|
||||||
microseconds. Receive interrupt reduction can improve CPU efficiency if
|
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
|
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
|
may be set too high, causing the driver to run out of available receive
|
||||||
descriptors.
|
descriptors.
|
||||||
|
|
||||||
CAUTION: When setting RxIntDelay to a value other than 0, adapters may
|
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
|
this occurs a NETDEV WATCHDOG message is logged in the system
|
||||||
event log. In addition, the controller is automatically reset,
|
event log. In addition, the controller is automatically reset,
|
||||||
restoring the network connection. To eliminate the potential
|
restoring the network connection. To eliminate the potential
|
||||||
for the hang ensure that RxIntDelay is set to 0.
|
for the hang ensure that RxIntDelay is set to 0.
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -208,7 +262,7 @@ Valid Range: 0-65535 (0=off)
|
||||||
Default Value: 128
|
Default Value: 128
|
||||||
|
|
||||||
This value, in units of 1.024 microseconds, limits the delay in which a
|
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
|
this value ensures that an interrupt is generated after the initial
|
||||||
packet is received within the set amount of time. Proper tuning,
|
packet is received within the set amount of time. Proper tuning,
|
||||||
along with RxIntDelay, may improve traffic throughput in specific network
|
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)
|
Default Value: 0 (auto-negotiate at all supported speeds)
|
||||||
|
|
||||||
Speed forces the line speed to the specified value in megabits per second
|
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
|
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
|
TxDescriptors
|
||||||
|
|
@ -234,7 +288,7 @@ Valid Range: 80-256 for 82542 and 82543-based adapters
|
||||||
Default Value: 256
|
Default Value: 256
|
||||||
|
|
||||||
This value is the number of transmit descriptors allocated by the driver.
|
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.
|
descriptor is 16 bytes.
|
||||||
|
|
||||||
NOTE: Depending on the available system resources, the request for a
|
NOTE: Depending on the available system resources, the request for a
|
||||||
|
|
@ -248,8 +302,8 @@ Valid Range: 0-65535 (0=off)
|
||||||
Default Value: 64
|
Default Value: 64
|
||||||
|
|
||||||
This value delays the generation of transmit interrupts in units of
|
This value delays the generation of transmit interrupts in units of
|
||||||
1.024 microseconds. Transmit interrupt reduction can improve CPU
|
1.024 microseconds. Transmit interrupt reduction can improve CPU
|
||||||
efficiency if properly tuned for specific network traffic. If the
|
efficiency if properly tuned for specific network traffic. If the
|
||||||
system is reporting dropped transmits, this value may be set too high
|
system is reporting dropped transmits, this value may be set too high
|
||||||
causing the driver to run out of available transmit descriptors.
|
causing the driver to run out of available transmit descriptors.
|
||||||
|
|
||||||
|
|
@ -261,7 +315,7 @@ Valid Range: 0-65535 (0=off)
|
||||||
Default Value: 64
|
Default Value: 64
|
||||||
|
|
||||||
This value, in units of 1.024 microseconds, limits the delay in which a
|
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
|
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,
|
packet is sent on the wire within the set amount of time. Proper tuning,
|
||||||
along with TxIntDelay, may improve traffic throughput in specific
|
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:
|
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
|
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.
|
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
|
If Speed = 1000, limited auto-negotiation is enabled and only 1000 Mbps
|
||||||
is advertised (The 1000BaseT spec requires auto-negotiation.)
|
is advertised (The 1000BaseT spec requires auto-negotiation.)
|
||||||
|
|
||||||
If Speed = 10 or 100, then both Speed and Duplex should be set. Auto-
|
If Speed = 10 or 100, then both Speed and Duplex should be set. Auto-
|
||||||
negotiation is disabled, and the AutoNeg parameter is ignored. Partner
|
negotiation is disabled, and the AutoNeg parameter is ignored. Partner
|
||||||
SHOULD also be forced.
|
SHOULD also be forced.
|
||||||
|
|
||||||
The AutoNeg parameter is used when more control is required over the
|
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
|
speed and duplex combinations are advertised during the auto-negotiation
|
||||||
process.
|
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.
|
determined by the bitmap below.
|
||||||
|
|
||||||
Bit position 7 6 5 4 3 2 1 0
|
Bit position 7 6 5 4 3 2 1 0
|
||||||
|
|
@ -337,20 +391,19 @@ Additional Configurations
|
||||||
|
|
||||||
Configuring the Driver on Different Distributions
|
Configuring the Driver on Different Distributions
|
||||||
-------------------------------------------------
|
-------------------------------------------------
|
||||||
|
|
||||||
Configuring a network driver to load properly when the system is started
|
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
|
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.
|
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,
|
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
|
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
|
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
|
(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 eth0 e1000
|
||||||
alias eth1 e1000
|
alias eth1 e1000
|
||||||
|
|
@ -358,9 +411,8 @@ Additional Configurations
|
||||||
|
|
||||||
Viewing Link Messages
|
Viewing Link Messages
|
||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
Link messages will not be displayed to the console if the distribution is
|
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:
|
on your console, set dmesg to eight by entering the following:
|
||||||
|
|
||||||
dmesg -n 8
|
dmesg -n 8
|
||||||
|
|
@ -369,11 +421,9 @@ Additional Configurations
|
||||||
|
|
||||||
Jumbo Frames
|
Jumbo Frames
|
||||||
------------
|
------------
|
||||||
|
Jumbo Frames support is enabled by changing the MTU to a value larger than
|
||||||
The driver supports Jumbo Frames for all adapters except 82542 and
|
the default of 1500. Use the ifconfig command to increase the MTU size.
|
||||||
82573-based adapters. Jumbo Frames support is enabled by changing the
|
For example:
|
||||||
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
|
ifconfig eth<x> mtu 9000 up
|
||||||
|
|
||||||
|
|
@ -390,26 +440,49 @@ Additional Configurations
|
||||||
|
|
||||||
- To enable Jumbo Frames, increase the MTU size on the interface beyond
|
- To enable Jumbo Frames, increase the MTU size on the interface beyond
|
||||||
1500.
|
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.
|
with the maximum Jumbo Frames size of 16128.
|
||||||
|
|
||||||
- Using Jumbo Frames at 10 or 100 Mbps may result in poor performance or
|
- Using Jumbo Frames at 10 or 100 Mbps may result in poor performance or
|
||||||
loss of link.
|
loss of link.
|
||||||
|
|
||||||
- Some Intel gigabit adapters that support Jumbo Frames have a frame size
|
- 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.
|
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
|
The adapters with this limitation are based on the Intel(R) 82571EB,
|
||||||
82572EI controllers, which correspond to these product names:
|
82572EI, 82573L and 80003ES2LAN controller. These correspond to the
|
||||||
Intel® PRO/1000 PT Dual Port Server Adapter
|
following product names:
|
||||||
Intel® PRO/1000 PF Dual Port Server Adapter
|
Intel(R) PRO/1000 PT Server Adapter
|
||||||
Intel® PRO/1000 PT Server Adapter
|
Intel(R) PRO/1000 PT Desktop Adapter
|
||||||
Intel® PRO/1000 PT Desktop Adapter
|
Intel(R) PRO/1000 PT Network Connection
|
||||||
Intel® PRO/1000 PF Server Adapter
|
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
|
Ethtool
|
||||||
-------
|
-------
|
||||||
|
|
||||||
The driver utilizes the ethtool interface for driver configuration and
|
The driver utilizes the ethtool interface for driver configuration and
|
||||||
diagnostics, as well as displaying statistical information. Ethtool
|
diagnostics, as well as displaying statistical information. Ethtool
|
||||||
version 1.6 or later is required for this functionality.
|
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
|
The latest release of ethtool can be found from
|
||||||
http://sourceforge.net/projects/gkernel.
|
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
|
for a more complete ethtool feature set can be enabled by upgrading
|
||||||
ethtool to ethtool-1.8.1.
|
ethtool to ethtool-1.8.1.
|
||||||
|
|
||||||
Enabling Wake on LAN* (WoL)
|
Enabling Wake on LAN* (WoL)
|
||||||
---------------------------
|
---------------------------
|
||||||
|
WoL is configured through the Ethtool* utility. Ethtool is included with
|
||||||
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,
|
||||||
all versions of Red Hat after Red Hat 7.2. For other Linux distributions,
|
|
||||||
download and install Ethtool from the following website:
|
download and install Ethtool from the following website:
|
||||||
http://sourceforge.net/projects/gkernel.
|
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
|
For this driver version, in order to enable WoL, the e1000 driver must be
|
||||||
loaded when shutting down or rebooting the system.
|
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
|
||||||
----
|
----
|
||||||
|
NAPI (Rx polling mode) is supported in the e1000 driver. NAPI is enabled
|
||||||
NAPI (Rx polling mode) is supported in the e1000 driver. NAPI is enabled
|
or disabled based on the configuration of the kernel. To override
|
||||||
or disabled based on the configuration of the kernel. To override
|
|
||||||
the default, use the following compile-time flags.
|
the default, use the following compile-time flags.
|
||||||
|
|
||||||
To enable NAPI, compile the driver module, passing in a configuration option:
|
To enable NAPI, compile the driver module, passing in a configuration option:
|
||||||
|
|
@ -457,88 +535,105 @@ Additional Configurations
|
||||||
Known Issues
|
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
|
Jumbo Frames System Requirement
|
||||||
of RAM or less that are running Jumbo Frames. If you are using Jumbo
|
-------------------------------
|
||||||
Frames, your system may require more than the advertised minimum
|
Memory allocation failures have been observed on Linux systems with 64 MB
|
||||||
requirement of 64 MB of system memory.
|
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
|
Jumbo Frames on Foundry BigIron 8000 switch
|
||||||
environments. If this is observed, increasing the application's socket
|
-------------------------------------------
|
||||||
buffer size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values
|
There is a known issue using Jumbo frames when connected to a Foundry
|
||||||
may help. See the specific application manual and
|
BigIron 8000 switch. This is a 3rd party limitation. If you experience
|
||||||
/usr/src/linux*/Documentation/
|
loss of packets, lower the MTU size.
|
||||||
networking/ip-sysctl.txt for more details.
|
|
||||||
|
|
||||||
Jumbo frames on Foundry BigIron 8000 switch
|
Allocating Rx Buffers when Using Jumbo Frames
|
||||||
-------------------------------------------
|
---------------------------------------------
|
||||||
There is a known issue using Jumbo frames when connected to a Foundry
|
Allocating Rx buffers when using Jumbo Frames on 2.6.x kernels may fail if
|
||||||
BigIron 8000 switch. This is a 3rd party limitation. If you experience
|
the available memory is heavily fragmented. This issue may be seen with PCI-X
|
||||||
loss of packets, lower the MTU size.
|
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
|
If you have multiple interfaces in a server, either turn on ARP
|
||||||
one system on two IP networks in the same Ethernet broadcast domain
|
filtering by entering:
|
||||||
(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
|
echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
|
||||||
filtering by entering:
|
(this only works if your kernel's version is higher than 2.4.5),
|
||||||
|
|
||||||
echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
|
NOTE: This setting is not saved across reboots. The configuration
|
||||||
(this only works if your kernel's version is higher than 2.4.5),
|
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
|
or,
|
||||||
change can be made permanent by adding the line:
|
|
||||||
net.ipv4.conf.all.arp_filter = 1
|
|
||||||
to the file /etc/sysctl.conf
|
|
||||||
|
|
||||||
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
|
82541/82547 can't link or are slow to link with some link partners
|
||||||
different switches or in a switch partitioned to VLANs).
|
-----------------------------------------------------------------
|
||||||
|
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
|
To workaround this issue, the driver can be compiled with an override
|
||||||
low-end switches where the link will not be established, or will
|
of the PHY's master/slave setting. Forcing master or forcing slave
|
||||||
be slow to establish. In particular, these switches are known to
|
mode will improve time-to-link.
|
||||||
be incompatible with 82541/82547:
|
|
||||||
|
|
||||||
Planex FXG-08TE
|
# make CFLAGS_EXTRA=-DE1000_MASTER_SLAVE=<n>
|
||||||
I-O Data ETG-SH8
|
|
||||||
|
|
||||||
To workaround this issue, the driver can be compiled with an override
|
Where <n> is:
|
||||||
of the PHY's master/slave setting. Forcing master or forcing slave
|
|
||||||
mode will improve time-to-link.
|
|
||||||
|
|
||||||
# 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
|
For example:
|
||||||
1 = Master mode
|
|
||||||
2 = Slave mode
|
|
||||||
3 = Auto master/slave
|
|
||||||
|
|
||||||
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
|
Unplugging network cable while ethtool -p is running
|
||||||
off auto-negotiation on the same command line.
|
----------------------------------------------------
|
||||||
|
In kernel versions 2.5.50 and later (including 2.6 kernel), unplugging
|
||||||
For example:
|
the network cable while ethtool -p is running will cause the system to
|
||||||
|
become unresponsive to keyboard commands, except for control-alt-delete.
|
||||||
ethtool -A eth? autoneg off rx off
|
Restarting the system appears to be the only remedy.
|
||||||
|
|
||||||
|
|
||||||
Support
|
Support
|
||||||
|
|
@ -548,24 +643,10 @@ For general information, go to the Intel support website at:
|
||||||
|
|
||||||
http://support.intel.com
|
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
|
http://sourceforge.net/projects/e1000
|
||||||
|
|
||||||
If an issue is identified with the released source code on the supported
|
If an issue is identified with the released source code on the supported
|
||||||
kernel with a supported adapter, email the specific information related
|
kernel with a supported adapter, email the specific information related
|
||||||
to the issue to e1000-devel@lists.sourceforge.net
|
to the issue to e1000-devel@lists.sf.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.
|
|
||||||
|
|
|
||||||
|
|
@ -101,6 +101,11 @@ inet_peer_gc_maxtime - INTEGER
|
||||||
|
|
||||||
TCP variables:
|
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
|
tcp_abc - INTEGER
|
||||||
Controls Appropriate Byte Count (ABC) defined in RFC3465.
|
Controls Appropriate Byte Count (ABC) defined in RFC3465.
|
||||||
ABC is a way of increasing congestion window (cwnd) more slowly
|
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.
|
of two segments to compensate for delayed acknowledgments.
|
||||||
Default: 0 (off)
|
Default: 0 (off)
|
||||||
|
|
||||||
tcp_syn_retries - INTEGER
|
tcp_abort_on_overflow - BOOLEAN
|
||||||
Number of times initial SYNs for an active TCP connection attempt
|
If listening service is too slow to accept new connections,
|
||||||
will be retransmitted. Should not be higher than 255. Default value
|
reset them. Default state is FALSE. It means that if overflow
|
||||||
is 5, which corresponds to ~180seconds.
|
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
|
tcp_adv_win_scale - INTEGER
|
||||||
Number of times SYNACKs for a passive TCP connection attempt will
|
Count buffering overhead as bytes/2^tcp_adv_win_scale
|
||||||
be retransmitted. Should not be higher than 255. Default value
|
(if tcp_adv_win_scale > 0) or bytes-bytes/2^(-tcp_adv_win_scale),
|
||||||
is 5, which corresponds to ~180seconds.
|
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
|
tcp_keepalive_time - INTEGER
|
||||||
How often TCP sends out keepalive messages when keepalive is enabled.
|
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
|
after probes started. Default value: 75sec i.e. connection
|
||||||
will be aborted after ~11 minutes of retries.
|
will be aborted after ~11 minutes of retries.
|
||||||
|
|
||||||
tcp_retries1 - INTEGER
|
tcp_low_latency - BOOLEAN
|
||||||
How many times to retry before deciding that something is wrong
|
If set, the TCP stack makes decisions that prefer lower
|
||||||
and it is necessary to report this suspicion to network layer.
|
latency as opposed to higher throughput. By default, this
|
||||||
Minimal RFC value is 3, it is default, which corresponds
|
option is not set meaning that higher throughput is preferred.
|
||||||
to ~3sec-8min depending on RTO.
|
An example of an application where this default should be
|
||||||
|
changed would be a Beowulf compute cluster.
|
||||||
tcp_retries2 - INTEGER
|
Default: 0
|
||||||
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_max_orphans - INTEGER
|
tcp_max_orphans - INTEGER
|
||||||
Maximal number of TCP sockets not attached to any user file handle,
|
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
|
more aggressively. Let me to remind again: each orphan eats
|
||||||
up to ~64K of unswappable memory.
|
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
|
tcp_max_syn_backlog - INTEGER
|
||||||
Maximal number of remembered connection requests, which are
|
Maximal number of remembered connection requests, which are
|
||||||
still did not receive an acknowledgment from connecting client.
|
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,
|
and 128 for low memory machines. If server suffers of overload,
|
||||||
try to increase this number.
|
try to increase this number.
|
||||||
|
|
||||||
tcp_window_scaling - BOOLEAN
|
tcp_max_tw_buckets - INTEGER
|
||||||
Enable window scaling as defined in RFC1323.
|
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
|
tcp_mem - vector of 3 INTEGERs: min, pressure, max
|
||||||
Enable timestamps as defined in RFC1323.
|
min: below this number of pages TCP is not bothered about its
|
||||||
|
memory appetite.
|
||||||
|
|
||||||
tcp_sack - BOOLEAN
|
pressure: when amount of memory allocated by TCP exceeds this number
|
||||||
Enable select acknowledgments (SACKS).
|
of pages, TCP moderates its memory consumption and enters memory
|
||||||
|
pressure mode, which is exited when memory consumption falls
|
||||||
|
under "min".
|
||||||
|
|
||||||
tcp_fack - BOOLEAN
|
max: number of pages allowed for queueing by all TCP sockets.
|
||||||
Enable FACK congestion avoidance and fast retransmission.
|
|
||||||
The value is not used, if tcp_sack is not enabled.
|
|
||||||
|
|
||||||
tcp_dsack - BOOLEAN
|
Defaults are calculated at boot time from amount of available
|
||||||
Allows TCP to send "duplicate" SACKs.
|
memory.
|
||||||
|
|
||||||
tcp_ecn - BOOLEAN
|
tcp_orphan_retries - INTEGER
|
||||||
Enable Explicit Congestion Notification in TCP.
|
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
|
tcp_reordering - INTEGER
|
||||||
Maximal reordering of packets in a TCP stream.
|
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
|
On retransmit try to send bigger packets to work around bugs in
|
||||||
certain TCP stacks.
|
certain TCP stacks.
|
||||||
|
|
||||||
tcp_wmem - vector of 3 INTEGERs: min, default, max
|
tcp_retries1 - INTEGER
|
||||||
min: Amount of memory reserved for send buffers for TCP socket.
|
How many times to retry before deciding that something is wrong
|
||||||
Each TCP socket has rights to use it due to fact of its birth.
|
and it is necessary to report this suspicion to network layer.
|
||||||
Default: 4K
|
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
|
tcp_retries2 - INTEGER
|
||||||
by default. This value overrides net.core.wmem_default used
|
How may times to retry before killing alive TCP connection.
|
||||||
by other protocols, it is usually lower than net.core.wmem_default.
|
RFC1122 says that the limit should be longer than 100 sec.
|
||||||
Default: 16K
|
It is too small number. Default value 15 corresponds to ~13-30min
|
||||||
|
depending on RTO.
|
||||||
|
|
||||||
max: Maximal amount of memory allowed for automatically selected
|
tcp_rfc1337 - BOOLEAN
|
||||||
send buffers for TCP socket. This value does not override
|
If set, the TCP stack behaves conforming to RFC1337. If unset,
|
||||||
net.core.wmem_max, "static" selection via SO_SNDBUF does not use this.
|
we are not conforming to RFC, but prevent TCP TIME_WAIT
|
||||||
Default: 128K
|
assassination.
|
||||||
|
Default: 0
|
||||||
|
|
||||||
tcp_rmem - vector of 3 INTEGERs: min, default, max
|
tcp_rmem - vector of 3 INTEGERs: min, default, max
|
||||||
min: Minimal size of receive buffer used by TCP sockets.
|
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.
|
net.core.rmem_max, "static" selection via SO_RCVBUF does not use this.
|
||||||
Default: 87380*2 bytes.
|
Default: 87380*2 bytes.
|
||||||
|
|
||||||
tcp_mem - vector of 3 INTEGERs: min, pressure, max
|
tcp_sack - BOOLEAN
|
||||||
min: below this number of pages TCP is not bothered about its
|
Enable select acknowledgments (SACKS).
|
||||||
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_slow_start_after_idle - BOOLEAN
|
tcp_slow_start_after_idle - BOOLEAN
|
||||||
If set, provide RFC2861 behavior and time out the congestion
|
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.
|
be timed out after an idle period.
|
||||||
Default: 1
|
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:
|
CIPSOv4 Variables:
|
||||||
|
|
||||||
cipso_cache_enable - BOOLEAN
|
cipso_cache_enable - BOOLEAN
|
||||||
|
|
@ -974,4 +986,3 @@ no_cong_thresh FIXME
|
||||||
slot_timeout FIXME
|
slot_timeout FIXME
|
||||||
warn_noreply_time FIXME
|
warn_noreply_time FIXME
|
||||||
|
|
||||||
$Id: ip-sysctl.txt,v 1.20 2001/12/13 09:00:18 davem Exp $
|
|
||||||
|
|
|
||||||
|
|
@ -81,7 +81,7 @@ Installation
|
||||||
1M. The RAM size decides the number of buffers and buffer size. The default
|
1M. The RAM size decides the number of buffers and buffer size. The default
|
||||||
size and number of buffers are set as following:
|
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
|
RAM size size size size size cnt cnt
|
||||||
-------- ------ ------ ------ ------ ------ ------
|
-------- ------ ------ ------ ------ ------ ------
|
||||||
128K 64K 64K 10K 10K 6 6
|
128K 64K 64K 10K 10K 6 6
|
||||||
|
|
|
||||||
|
|
@ -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
|
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
|
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
|
meta information like timestamp. So what we draw here a frame it's really
|
||||||
the following (from include/linux/if_packet.h):
|
the following (from include/linux/if_packet.h):
|
||||||
|
|
|
||||||
|
|
@ -1,7 +1,7 @@
|
||||||
|
|
||||||
-------
|
-------
|
||||||
PHY Abstraction Layer
|
PHY Abstraction Layer
|
||||||
(Updated 2005-07-21)
|
(Updated 2006-11-30)
|
||||||
|
|
||||||
Purpose
|
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.
|
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
|
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:
|
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
|
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
|
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
|
This is useful if the system has put hardware restrictions on
|
||||||
the PHY/controller, of which the PHY needs to be aware.
|
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
|
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
|
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
|
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.
|
start, or disables then frees them for stop.
|
||||||
|
|
||||||
struct phy_device * phy_attach(struct net_device *dev, const char *phy_id,
|
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
|
Attaches a network device to a particular PHY, binding the PHY to a generic
|
||||||
driver if none was found during bus initialization. Passes in
|
driver if none was found during bus initialization. Passes in
|
||||||
|
|
|
||||||
|
|
@ -63,8 +63,8 @@ Current:
|
||||||
Result: OK: 13101142(c12220741+d880401) usec, 10000000 (60byte,0frags)
|
Result: OK: 13101142(c12220741+d880401) usec, 10000000 (60byte,0frags)
|
||||||
763292pps 390Mb/sec (390805504bps) errors: 39664
|
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
|
This is done via the /proc interface easiest done via pgset in the scripts
|
||||||
|
|
||||||
Examples:
|
Examples:
|
||||||
|
|
@ -116,7 +116,7 @@ Examples:
|
||||||
there must be no spaces between the
|
there must be no spaces between the
|
||||||
arguments. Leading zeros are required.
|
arguments. Leading zeros are required.
|
||||||
Do not set the bottom of stack bit,
|
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
|
set the bottom of stack bit, that
|
||||||
indicates that you want to randomly
|
indicates that you want to randomly
|
||||||
generate that address and the flag
|
generate that address and the flag
|
||||||
|
|
|
||||||
|
|
@ -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
|
1000 0 54165785 4 cd1e6040 25 4 27 3 -1
|
||||||
| | | | | | | | | |--> slow start size threshold,
|
| | | | | | | | | |--> slow start size threshold,
|
||||||
| | | | | | | | | or -1 if the treshold
|
| | | | | | | | | or -1 if the threshold
|
||||||
| | | | | | | | | is >= 0xFFFF
|
| | | | | | | | | is >= 0xFFFF
|
||||||
| | | | | | | | |----> sending congestion window
|
| | | | | | | | |----> sending congestion window
|
||||||
| | | | | | | |-------> (ack.quick<<1)|ack.pingpong
|
| | | | | | | |-------> (ack.quick<<1)|ack.pingpong
|
||||||
|
|
|
||||||
|
|
@ -346,7 +346,7 @@ Possible modes:
|
||||||
depending on the load of the system. If the driver detects that the
|
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
|
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
|
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.
|
negligible) the interrupt moderation will automatically be disabled.
|
||||||
|
|
||||||
Interrupt moderation should be used when the driver has to handle one or more
|
Interrupt moderation should be used when the driver has to handle one or more
|
||||||
|
|
|
||||||
|
|
@ -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
|
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
|
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 0 >boardnum
|
||||||
# echo internal >clock_source
|
# echo internal >clock_source
|
||||||
|
|
|
||||||
|
|
@ -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>.
|
||||||
|
|
@ -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.
|
beta3-2.1.4 Jul 2000 o X25 M_BIT Problem fix.
|
||||||
o Added the Multi-Port PPP
|
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
|
2.1.4 Aut 2000
|
||||||
o In X25API:
|
o In X25API:
|
||||||
|
|
@ -444,13 +444,13 @@ beta1-2.1.5 Nov 15 2000
|
||||||
|
|
||||||
o Cpipemon
|
o Cpipemon
|
||||||
- Added set FT1 commands to the cpipemon. Thus CSU/DSU
|
- 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
|
All systems that cannot run cfgft1 GUI utility should
|
||||||
use cpipemon to configure the on board CSU/DSU.
|
use cpipemon to configure the on board CSU/DSU.
|
||||||
|
|
||||||
|
|
||||||
o Keyboard Led Monitor/Debugger
|
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
|
to convey operational statistic information of the
|
||||||
Sangoma WANPIPE cards.
|
Sangoma WANPIPE cards.
|
||||||
NUM_LOCK = Line State (On=connected, Off=disconnected)
|
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
|
- Appropriate number of devices are dynamically loaded
|
||||||
based on the number of Sangoma cards found.
|
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.
|
CONFIG_WANPIPE_CARDS has been taken out.
|
||||||
|
|
||||||
o Fixed the Frame Relay and Chdlc network interfaces so they are
|
o Fixed the Frame Relay and Chdlc network interfaces so they are
|
||||||
|
|
|
||||||
|
|
@ -47,10 +47,13 @@ aevent_id structure looks like:
|
||||||
|
|
||||||
struct xfrm_aevent_id {
|
struct xfrm_aevent_id {
|
||||||
struct xfrm_usersa_id sa_id;
|
struct xfrm_usersa_id sa_id;
|
||||||
|
xfrm_address_t saddr;
|
||||||
__u32 flags;
|
__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 used to indicate different things. The possible
|
||||||
flags are:
|
flags are:
|
||||||
|
|
|
||||||
|
|
@ -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
|
Please note that the character 'X' can be used as a wild card in the function
|
||||||
portion (last four characters).
|
portion (last four characters).
|
||||||
ex:
|
ex:
|
||||||
/* Unkown PnP modems */
|
/* Unknown PnP modems */
|
||||||
{ "PNPCXXX", UNKNOWN_DEV },
|
{ "PNPCXXX", UNKNOWN_DEV },
|
||||||
|
|
||||||
Supported PnP card IDs can optionally be defined.
|
Supported PnP card IDs can optionally be defined.
|
||||||
|
|
|
||||||
|
|
@ -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
|
that is known a priori. But, the user may choose 'shutdown' or
|
||||||
'reboot' as alternatives.
|
'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
|
Reading from this file will display what the mode is currently set
|
||||||
to. Writing to this file will accept one of
|
to. Writing to this file will accept one of
|
||||||
|
|
||||||
|
|
@ -37,6 +48,8 @@ to. Writing to this file will accept one of
|
||||||
'platform'
|
'platform'
|
||||||
'shutdown'
|
'shutdown'
|
||||||
'reboot'
|
'reboot'
|
||||||
|
'testproc'
|
||||||
|
'test'
|
||||||
|
|
||||||
It will only change to 'firmware' or 'platform' if the system supports
|
It will only change to 'firmware' or 'platform' if the system supports
|
||||||
it.
|
it.
|
||||||
|
|
|
||||||
|
|
@ -153,7 +153,7 @@ Description:
|
||||||
events, which is implicit if it doesn't even support it in the first
|
events, which is implicit if it doesn't even support it in the first
|
||||||
place).
|
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
|
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
|
D3cold is bit 4. So, while a value of 4 as the state may not seem
|
||||||
semantically correct, it is.
|
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.)
|
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
|
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:
|
wake event from:
|
||||||
|
|
||||||
+------------------+
|
+------------------+
|
||||||
|
|
|
||||||
|
|
@ -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
|
inconvenience, this method requires minimal work by the kernel, since
|
||||||
the firmware will also handle restoring memory contents on resume.
|
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
|
called 'swsusp' (Swap Suspend) is used to write memory contents to
|
||||||
free swap space. swsusp has some restrictive requirements, but should
|
free swap space. swsusp has some restrictive requirements, but should
|
||||||
work in most cases. Some, albeit outdated, documentation can be found
|
work in most cases. Some, albeit outdated, documentation can be found
|
||||||
|
|
|
||||||
|
|
@ -153,7 +153,7 @@ add:
|
||||||
|
|
||||||
If the thread is needed for writing the image to storage, you should
|
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
|
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
|
Q: What is the difference between "platform", "shutdown" and
|
||||||
|
|
|
||||||
|
|
@ -33,13 +33,13 @@
|
||||||
- Change version 16 format to always align
|
- Change version 16 format to always align
|
||||||
property data to 4 bytes. Since tokens are
|
property data to 4 bytes. Since tokens are
|
||||||
already aligned, that means no specific
|
already aligned, that means no specific
|
||||||
required alignement between property size
|
required alignment between property size
|
||||||
and property data. The old style variable
|
and property data. The old style variable
|
||||||
alignment would make it impossible to do
|
alignment would make it impossible to do
|
||||||
"simple" insertion of properties using
|
"simple" insertion of properties using
|
||||||
memove (thanks Milton for
|
memove (thanks Milton for
|
||||||
noticing). Updated kernel patch as well
|
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
|
- Add a chapter about the device-tree
|
||||||
compiler and the textural representation of
|
compiler and the textural representation of
|
||||||
the tree that can be "compiled" by dtc.
|
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
|
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
|
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
|
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
|
set_preferred_console() in arch/ppc64/kernel/setup.c, you'll see
|
||||||
that the kernel tries to find out the default console and has
|
that the kernel tries to find out the default console and has
|
||||||
knowledge of various types like 8250 serial ports. You may want
|
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
|
- interrupt-parent : contains the phandle of the interrupt
|
||||||
controller which handles interrupts for this device
|
controller which handles interrupts for this device
|
||||||
- interrupts : a list of tuples representing the interrupt
|
- 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.
|
for this device.
|
||||||
|
|
||||||
This information is used by the kernel to build the interrupt table
|
This information is used by the kernel to build the interrupt table
|
||||||
|
|
|
||||||
|
|
@ -170,7 +170,7 @@ any point:
|
||||||
1) the 'head' pointer or an subsequent linked list pointer
|
1) the 'head' pointer or an subsequent linked list pointer
|
||||||
is not a valid address of a user space word
|
is not a valid address of a user space word
|
||||||
2) the calculated location of the 'lock word' (address plus
|
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
|
word
|
||||||
3) if the list contains more than 1 million (subject to
|
3) if the list contains more than 1 million (subject to
|
||||||
future kernel configuration changes) elements.
|
future kernel configuration changes) elements.
|
||||||
|
|
|
||||||
|
|
@ -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,
|
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
|
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
|
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.
|
robust and normal futexes.
|
||||||
|
|
||||||
If a futex is found to be held at exit time, the kernel sets the
|
If a futex is found to be held at exit time, the kernel sets the
|
||||||
|
|
|
||||||
|
|
@ -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.
|
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
|
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
|
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.
|
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
|
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
|
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
|
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
|
perhaps more useful to include a small test program that demonstrates
|
||||||
how to use them, and demonstrates the features of the driver. This is
|
how to use them, and demonstrates the features of the driver. This is
|
||||||
probably a lot more useful to people interested in writing applications
|
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< -----------------------------
|
-------------------- 8< ---------------- 8< -----------------------------
|
||||||
|
|
||||||
/*
|
/*
|
||||||
* Real Time Clock Driver Test/Example Program
|
* Real Time Clock Driver Test/Example Program
|
||||||
*
|
*
|
||||||
* Compile with:
|
* Compile with:
|
||||||
* gcc -s -Wall -Wstrict-prototypes rtctest.c -o rtctest
|
* 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,
|
* Released under the GNU General Public License, version 2,
|
||||||
* included herein by reference.
|
* included herein by reference.
|
||||||
*
|
*
|
||||||
*/
|
*/
|
||||||
|
|
||||||
#include <stdio.h>
|
#include <stdio.h>
|
||||||
#include <stdlib.h>
|
|
||||||
#include <linux/rtc.h>
|
#include <linux/rtc.h>
|
||||||
#include <sys/ioctl.h>
|
#include <sys/ioctl.h>
|
||||||
#include <sys/time.h>
|
#include <sys/time.h>
|
||||||
#include <sys/types.h>
|
#include <sys/types.h>
|
||||||
#include <fcntl.h>
|
#include <fcntl.h>
|
||||||
#include <unistd.h>
|
#include <unistd.h>
|
||||||
|
#include <stdlib.h>
|
||||||
#include <errno.h>
|
#include <errno.h>
|
||||||
|
|
||||||
int main(void) {
|
|
||||||
|
|
||||||
int i, fd, retval, irqcount = 0;
|
/*
|
||||||
unsigned long tmp, data;
|
* This expects the new RTC class driver framework, working with
|
||||||
struct rtc_time rtc_tm;
|
* 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) {
|
int main(int argc, char **argv)
|
||||||
perror("/dev/rtc");
|
{
|
||||||
exit(errno);
|
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) */
|
fd = open(rtc, O_RDONLY);
|
||||||
retval = ioctl(fd, RTC_UIE_ON, 0);
|
|
||||||
if (retval == -1) {
|
|
||||||
perror("ioctl");
|
|
||||||
exit(errno);
|
|
||||||
}
|
|
||||||
|
|
||||||
fprintf(stderr, "Counting 5 update (1/sec) interrupts from reading /dev/rtc:");
|
if (fd == -1) {
|
||||||
fflush(stderr);
|
perror(rtc);
|
||||||
for (i=1; i<6; i++) {
|
|
||||||
/* This read will block */
|
|
||||||
retval = read(fd, &data, sizeof(unsigned long));
|
|
||||||
if (retval == -1) {
|
|
||||||
perror("read");
|
|
||||||
exit(errno);
|
exit(errno);
|
||||||
}
|
}
|
||||||
fprintf(stderr, " %d",i);
|
|
||||||
fflush(stderr);
|
|
||||||
irqcount++;
|
|
||||||
}
|
|
||||||
|
|
||||||
fprintf(stderr, "\nAgain, from using select(2) on /dev/rtc:");
|
fprintf(stderr, "\n\t\t\tRTC Driver Test Example.\n\n");
|
||||||
fflush(stderr);
|
|
||||||
for (i=1; i<6; i++) {
|
|
||||||
struct timeval tv = {5, 0}; /* 5 second timeout on select */
|
|
||||||
fd_set readfds;
|
|
||||||
|
|
||||||
FD_ZERO(&readfds);
|
/* Turn on update interrupts (one per second) */
|
||||||
FD_SET(fd, &readfds);
|
retval = ioctl(fd, RTC_UIE_ON, 0);
|
||||||
/* 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);
|
|
||||||
if (retval == -1) {
|
if (retval == -1) {
|
||||||
|
if (errno == ENOTTY) {
|
||||||
|
fprintf(stderr,
|
||||||
|
"\n...Update IRQs not supported.\n");
|
||||||
|
goto test_READ;
|
||||||
|
}
|
||||||
perror("ioctl");
|
perror("ioctl");
|
||||||
exit(errno);
|
exit(errno);
|
||||||
}
|
}
|
||||||
|
|
||||||
fprintf(stderr, "\n%ldHz:\t", tmp);
|
fprintf(stderr, "Counting 5 update (1/sec) interrupts from reading %s:",
|
||||||
|
rtc);
|
||||||
fflush(stderr);
|
fflush(stderr);
|
||||||
|
for (i=1; i<6; i++) {
|
||||||
/* Enable periodic interrupts */
|
/* This read will block */
|
||||||
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));
|
retval = read(fd, &data, sizeof(unsigned long));
|
||||||
if (retval == -1) {
|
if (retval == -1) {
|
||||||
perror("read");
|
perror("read");
|
||||||
exit(errno);
|
exit(errno);
|
||||||
}
|
}
|
||||||
fprintf(stderr, " %d",i);
|
fprintf(stderr, " %d",i);
|
||||||
fflush(stderr);
|
fflush(stderr);
|
||||||
irqcount++;
|
irqcount++;
|
||||||
}
|
}
|
||||||
|
|
||||||
/* Disable periodic interrupts */
|
fprintf(stderr, "\nAgain, from using select(2) on /dev/rtc:");
|
||||||
retval = ioctl(fd, RTC_PIE_OFF, 0);
|
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) {
|
if (retval == -1) {
|
||||||
perror("ioctl");
|
perror("ioctl");
|
||||||
exit(errno);
|
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 */
|
|
||||||
|
|
|
||||||
|
|
@ -66,7 +66,7 @@ Command line parameters
|
||||||
|
|
||||||
When a device is un-ignored, device recognition and sensing is performed and
|
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
|
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
|
You can also add ranges of devices to be ignored by piping to
|
||||||
/proc/cio_ignore; "add <device range>, <device range>, ..." will ignore the
|
/proc/cio_ignore; "add <device range>, <device range>, ..." will ignore the
|
||||||
|
|
|
||||||
|
|
@ -174,14 +174,10 @@ read_dev_chars() - Read Device Characteristics
|
||||||
|
|
||||||
This routine returns the characteristics for the device specified.
|
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.
|
at earliest during set_online() processing.
|
||||||
|
|
||||||
While the request is processed synchronously, the device interrupt
|
The ccw_device must not be locked prior to calling read_dev_chars().
|
||||||
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 function may be called enabled or disabled.
|
The function may be called enabled or disabled.
|
||||||
|
|
||||||
|
|
@ -410,26 +406,7 @@ individual flag meanings.
|
||||||
|
|
||||||
Usage Notes :
|
Usage Notes :
|
||||||
|
|
||||||
Prior to call ccw_device_start() the device driver must assure disabled state,
|
ccw_device_start() must be called disabled and with the ccw device lock held.
|
||||||
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.
|
|
||||||
|
|
||||||
The device driver is allowed to issue the next ccw_device_start() call from
|
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
|
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
|
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
|
0 - suspended channel program is resumed
|
||||||
-EBUSY - status pending
|
-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()
|
a halt subchannel (HSCH) I/O command. For those purposes the ccw_device_halt()
|
||||||
command is provided.
|
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,
|
int ccw_device_halt(struct ccw_device *cdev,
|
||||||
unsigned long intparm);
|
unsigned long intparm);
|
||||||
|
|
||||||
|
|
@ -517,7 +496,7 @@ intparm : interruption parameter; value is only used if no I/O
|
||||||
|
|
||||||
The ccw_device_halt() function returns :
|
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.
|
-EBUSY - the device is currently busy, or status pending.
|
||||||
-ENODEV - cdev invalid.
|
-ENODEV - cdev invalid.
|
||||||
-EINVAL - The device is not operational or the ccw device is not online.
|
-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()
|
read to a network device (with or without PCI flag) a ccw_device_halt()
|
||||||
is required to end the pending operation.
|
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
|
Miscellaneous Support Routines
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -75,8 +75,8 @@ name of the respective module is given in square brackets.
|
||||||
|
|
||||||
- SHA1 Digest Algorithm [sha1 -> sha1_z990]
|
- SHA1 Digest Algorithm [sha1 -> sha1_z990]
|
||||||
- DES Encrypt/Decrypt Algorithm (64bit key) [des -> des_z990]
|
- DES Encrypt/Decrypt Algorithm (64bit key) [des -> des_z990]
|
||||||
- Tripple DES Encrypt/Decrypt Algorithm (128bit key) [des3_ede128 -> des_z990]
|
- Triple 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 (192bit key) [des3_ede -> des_z990]
|
||||||
|
|
||||||
In order to load, for example, the sha1_z990 module when the sha1 algorithm is
|
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.
|
requested (see 3.2.) add 'alias sha1 sha1_z990' to /etc/modprobe.conf.
|
||||||
|
|
|
||||||
|
|
@ -239,6 +239,9 @@ status - Can be 'online' or 'offline'.
|
||||||
|
|
||||||
type - The physical type of the channel path.
|
type - The physical type of the channel path.
|
||||||
|
|
||||||
|
shared - Whether the channel path is shared.
|
||||||
|
|
||||||
|
cmg - The channel measurement group.
|
||||||
|
|
||||||
3. System devices
|
3. System devices
|
||||||
-----------------
|
-----------------
|
||||||
|
|
|
||||||
|
|
@ -127,7 +127,7 @@ The following information is available in this file:
|
||||||
- Correct a reference to free'ed memory during controller
|
- Correct a reference to free'ed memory during controller
|
||||||
shutdown.
|
shutdown.
|
||||||
- Reset the bus on an SE->LVD change. This is required
|
- 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)
|
1.3.5 (March 24th, 2003)
|
||||||
- Fix a few register window mode bugs.
|
- 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)
|
1.3.0 (January 21st, 2003)
|
||||||
- Full regression testing for all U320 products completed.
|
- Full regression testing for all U320 products completed.
|
||||||
- Added abort and target/lun reset error recovery handler and
|
- Added abort and target/lun reset error recovery handler and
|
||||||
interrupt coalessing.
|
interrupt coalescing.
|
||||||
|
|
||||||
1.2.0 (November 14th, 2002)
|
1.2.0 (November 14th, 2002)
|
||||||
- Added support for Domain Validation
|
- Added support for Domain Validation
|
||||||
|
|
|
||||||
|
|
@ -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
|
En/Disable High Byte LVD Termination
|
||||||
|
|
||||||
The upper 2 bits that deal with LVD termination only apply to Ultra2
|
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
|
designs, these bits are tied together such that setting either bit
|
||||||
enables both low and high byte LVD termination. It is not possible
|
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
|
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
|
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
|
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
|
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
|
a comma inside of those quotes as starting a new variable, resulting
|
||||||
in memory scribbles if you don't switch the commas to periods.
|
in memory scribbles if you don't switch the commas to periods.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -461,7 +461,7 @@
|
||||||
This needs the RD-Bit to be disabled on IM_OTHER_SCSI_CMD_CMD which
|
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
|
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
|
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.
|
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
|
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
|
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
|
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
|
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
|
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,
|
decisive 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
|
it seems to work far better and more stable. Let us see what
|
||||||
the world thinks of it...
|
the world thinks of it...
|
||||||
3) By the way, only Sony DAT-drives seem to show density code 0x13. A
|
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-
|
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
|
A long period of collecting bugreports from all corners of the world
|
||||||
now lead to the following corrections to the code:
|
now lead to the following corrections to the code:
|
||||||
1) SCSI-2 F/W support crashed with a COMMAND ERROR. The reason for this
|
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.
|
was that it is possible to disable Fast-SCSI for the external bus.
|
||||||
The feature-control command, where this crash appeared regularly tried
|
The feature-control command, where this crash appeared regularly, tried
|
||||||
to set the maximum speed of 10MHz synchronous transfer speed and that
|
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
|
the feature-command probes down from maximum speed until the adapter
|
||||||
stops to complain, which is at the same time the maximum possible
|
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
|
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
|
completed in such a way, that they are now completely conform to the
|
||||||
demands in the technical description of IBM. Main candidates were the
|
demands in the technical description of IBM. Main candidates were the
|
||||||
DEVICE_INQUIRY, REQUEST_SENSE and DEVICE_CAPACITY commands. They must
|
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
|
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
|
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
|
is not allowed by the technical references of IBM. (Sorry, folks, the
|
||||||
|
|
|
||||||
|
|
@ -24,7 +24,7 @@ UPDATE NEWS: version 1.32 - 28 Mar 98
|
||||||
UPDATE NEWS: version 1.31 - 6 Jul 97
|
UPDATE NEWS: version 1.31 - 6 Jul 97
|
||||||
|
|
||||||
Fixed a bug that caused incorrect SCSI status bytes to be
|
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
|
means that CDROM changers work now! Fixed a bug in the
|
||||||
handling of command-line arguments when loaded as a module.
|
handling of command-line arguments when loaded as a module.
|
||||||
Also put all the header data in in2000.h where it belongs.
|
Also put all the header data in in2000.h where it belongs.
|
||||||
|
|
|
||||||
|
|
@ -393,7 +393,7 @@ struct sas_task {
|
||||||
task_proto -- _one_ of enum sas_proto
|
task_proto -- _one_ of enum sas_proto
|
||||||
scatter -- pointer to scatter gather list array
|
scatter -- pointer to scatter gather list array
|
||||||
num_scatter -- number of elements in scatter
|
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_...
|
data_dir -- PCI_DMA_...
|
||||||
task_done -- callback when the task has finished execution
|
task_done -- callback when the task has finished execution
|
||||||
};
|
};
|
||||||
|
|
|
||||||
|
|
@ -115,7 +115,7 @@ SCSI standard documentations are available at SYMBIOS ftp server:
|
||||||
|
|
||||||
ftp://ftp.symbios.com/
|
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/scsiinfo-X.Y.tar.gz
|
||||||
ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/scsidev-X.Y.tar.gz
|
ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/scsidev-X.Y.tar.gz
|
||||||
|
|
|
||||||
|
|
@ -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
|
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
|
/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*
|
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:
|
broken devices. So you can try:
|
||||||
|
|
||||||
1) echo "scsi add-single-device 0 0 ID 1" > /proc/scsi/scsi
|
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.
|
strings then.
|
||||||
|
|
||||||
You can display these messages with the dmesg command (or check the
|
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.
|
driver, please include these messages.
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -75,7 +75,7 @@ with the command.
|
||||||
|
|
||||||
- otherwise
|
- otherwise
|
||||||
scsi_eh_scmd_add(scmd, 0) is invoked for the command. See
|
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
|
[1-2-2] Completing a scmd w/ timeout
|
||||||
|
|
|
||||||
|
|
@ -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
|
used instead of the equal mark. The definition is prepended by the
|
||||||
string st=. Here is an example:
|
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:
|
The following syntax used by the old kernel versions is also supported:
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -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
|
be sure I will receive it. Obviously, a bug in the driver code is
|
||||||
possible.
|
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
|
Allowing disconnections is important if you use several devices on
|
||||||
your SCSI bus but often causes problems with buggy devices.
|
your SCSI bus but often causes problems with buggy devices.
|
||||||
|
|
|
||||||
|
|
@ -942,13 +942,13 @@ replicas continue to be exactly same.
|
||||||
->mnt_slave
|
->mnt_slave
|
||||||
->mnt_master
|
->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.
|
send/receives propagation events.
|
||||||
|
|
||||||
->mnt_slave_list links all the mounts to which this vfsmount propagates
|
->mnt_slave_list links all the mounts to which this vfsmount propagates
|
||||||
to.
|
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.
|
propagates to.
|
||||||
|
|
||||||
->mnt_master points to the master vfsmount from which this vfsmount
|
->mnt_master points to the master vfsmount from which this vfsmount
|
||||||
|
|
|
||||||
|
|
@ -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)
|
position_fix - Fix DMA pointer (0 = auto, 1 = none, 2 = POSBUF, 3 = FIFO size)
|
||||||
single_cmd - Use single immediate commands to communicate with
|
single_cmd - Use single immediate commands to communicate with
|
||||||
codecs (for debugging only)
|
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.
|
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,
|
dmx6fire, dsp24, dsp24_value, dsp24_71, ez8,
|
||||||
phase88, mediastation
|
phase88, mediastation
|
||||||
omni - Omni I/O support for MidiMan M-Audio Delta44/66
|
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)
|
in msec resolution, default value is 500 (0.5 sec)
|
||||||
|
|
||||||
This module supports multiple cards and autoprobe. Note: The consumer part
|
This module supports multiple cards and autoprobe. Note: The consumer part
|
||||||
|
|
|
||||||
|
|
@ -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
|
The EMU10K2 chips have a DSP part which can be programmed to support
|
||||||
various ways of sample processing, which is described here.
|
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.)
|
EMU10K2 chips. See the manuals section for further details.)
|
||||||
|
|
||||||
The ALSA driver programs this portion of chip by default code
|
The ALSA driver programs this portion of chip by default code
|
||||||
|
|
|
||||||
|
|
@ -5,7 +5,7 @@
|
||||||
|
|
||||||
The EMU10K1 chips have a DSP part which can be programmed to support
|
The EMU10K1 chips have a DSP part which can be programmed to support
|
||||||
various ways of sample processing, which is described here.
|
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.)
|
EMU10K1 chips. See the manuals section for further details.)
|
||||||
|
|
||||||
The ALSA driver programs this portion of chip by default code
|
The ALSA driver programs this portion of chip by default code
|
||||||
|
|
|
||||||
|
|
@ -50,7 +50,7 @@ Review cycle:
|
||||||
Contact the kernel security team for more details on this procedure.
|
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 is made up of a number of kernel developers who have volunteered for
|
||||||
this task, and a few that haven't.
|
this task, and a few that haven't.
|
||||||
|
|
|
||||||
|
|
@ -146,7 +146,7 @@ or otherwise protected/tainted binaries. The modes are
|
||||||
readable by root only. This allows the end user to remove
|
readable by root only. This allows the end user to remove
|
||||||
such a dump but not access it directly. For security reasons
|
such a dump but not access it directly. For security reasons
|
||||||
core dumps in this mode will not overwrite one another or
|
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.
|
attempting to debug problems in a normal environment.
|
||||||
|
|
||||||
==============================================================
|
==============================================================
|
||||||
|
|
|
||||||
|
|
@ -129,7 +129,7 @@ the high water marks for each per cpu page list.
|
||||||
|
|
||||||
zone_reclaim_mode:
|
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
|
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
|
zone reclaim occurs. Allocations will be satisfied from other zones / nodes
|
||||||
in the system.
|
in the system.
|
||||||
|
|
|
||||||
|
|
@ -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-
|
exploitable as a security hole. However, it does allow anyone to cre-
|
||||||
ate useless tap devices (useless because they can't configure them),
|
ate useless tap devices (useless because they can't configure them),
|
||||||
which is a DOS attack. A somewhat more secure alternative would to be
|
which is a DOS attack. A somewhat more secure alternative would to be
|
||||||
|
|
|
||||||
|
|
@ -8,7 +8,7 @@ interfaces, but have similar sorts of communication needs. The two big
|
||||||
examples for this are power devices (especially uninterruptable power
|
examples for this are power devices (especially uninterruptable power
|
||||||
supplies) and monitor control on higher end monitors.
|
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:
|
HID events to two separate interfaces:
|
||||||
* the input subsystem, which converts HID events into normal input
|
* the input subsystem, which converts HID events into normal input
|
||||||
device interfaces (such as keyboard, mouse and joystick) and a
|
device interfaces (such as keyboard, mouse and joystick) and a
|
||||||
|
|
|
||||||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче