Merge ../linus
Conflicts: drivers/cpufreq/cpufreq.c
This commit is contained in:
Коммит
c4366889dd
|
@ -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
|
||||||
|
|
19
CREDITS
19
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
|
||||||
|
@ -1808,6 +1808,14 @@ S: Kruislaan 419
|
||||||
S: 1098 VA Amsterdam
|
S: 1098 VA Amsterdam
|
||||||
S: The Netherlands
|
S: The Netherlands
|
||||||
|
|
||||||
|
N: Jiri Kosina
|
||||||
|
E: jikos@jikos.cz
|
||||||
|
E: jkosina@suse.cz
|
||||||
|
D: Generic HID layer - original code split, fixes
|
||||||
|
D: Various ACPI fixes, keeping correct battery state through suspend
|
||||||
|
D: various lockdep annotations, autofs and other random bugfixes
|
||||||
|
S: Prague, Czech Republic
|
||||||
|
|
||||||
N: Gene Kozin
|
N: Gene Kozin
|
||||||
E: 74604.152@compuserve.com
|
E: 74604.152@compuserve.com
|
||||||
W: http://www.sangoma.com
|
W: http://www.sangoma.com
|
||||||
|
@ -2598,6 +2606,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 +3522,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
|
||||||
|
|
|
@ -104,8 +104,6 @@ firmware_class/
|
||||||
- request_firmware() hotplug interface info.
|
- request_firmware() hotplug interface info.
|
||||||
floppy.txt
|
floppy.txt
|
||||||
- notes and driver options for the floppy disk driver.
|
- notes and driver options for the floppy disk driver.
|
||||||
ftape.txt
|
|
||||||
- notes about the floppy tape device driver.
|
|
||||||
hayes-esp.txt
|
hayes-esp.txt
|
||||||
- info on using the Hayes ESP serial driver.
|
- info on using the Hayes ESP serial driver.
|
||||||
highuid.txt
|
highuid.txt
|
||||||
|
|
|
@ -0,0 +1,20 @@
|
||||||
|
What: /debug/pktcdvd/pktcdvd[0-7]
|
||||||
|
Date: Oct. 2006
|
||||||
|
KernelVersion: 2.6.19
|
||||||
|
Contact: Thomas Maier <balagi@justmail.de>
|
||||||
|
Description:
|
||||||
|
|
||||||
|
debugfs interface
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
The pktcdvd module (packet writing driver) creates
|
||||||
|
these files in debugfs:
|
||||||
|
|
||||||
|
/debug/pktcdvd/pktcdvd[0-7]/
|
||||||
|
info (0444) Lots of human readable driver
|
||||||
|
statistics and infos. Multiple lines!
|
||||||
|
|
||||||
|
Example:
|
||||||
|
-------
|
||||||
|
|
||||||
|
cat /debug/pktcdvd/pktcdvd0/info
|
|
@ -0,0 +1,72 @@
|
||||||
|
What: /sys/class/pktcdvd/
|
||||||
|
Date: Oct. 2006
|
||||||
|
KernelVersion: 2.6.19
|
||||||
|
Contact: Thomas Maier <balagi@justmail.de>
|
||||||
|
Description:
|
||||||
|
|
||||||
|
sysfs interface
|
||||||
|
---------------
|
||||||
|
|
||||||
|
The pktcdvd module (packet writing driver) creates
|
||||||
|
these files in the sysfs:
|
||||||
|
(<devid> is in format major:minor )
|
||||||
|
|
||||||
|
/sys/class/pktcdvd/
|
||||||
|
add (0200) Write a block device id (major:minor)
|
||||||
|
to create a new pktcdvd device and map
|
||||||
|
it to the block device.
|
||||||
|
|
||||||
|
remove (0200) Write the pktcdvd device id (major:minor)
|
||||||
|
to it to remove the pktcdvd device.
|
||||||
|
|
||||||
|
device_map (0444) Shows the device mapping in format:
|
||||||
|
pktcdvd[0-7] <pktdevid> <blkdevid>
|
||||||
|
|
||||||
|
/sys/class/pktcdvd/pktcdvd[0-7]/
|
||||||
|
dev (0444) Device id
|
||||||
|
uevent (0200) To send an uevent.
|
||||||
|
|
||||||
|
/sys/class/pktcdvd/pktcdvd[0-7]/stat/
|
||||||
|
packets_started (0444) Number of started packets.
|
||||||
|
packets_finished (0444) Number of finished packets.
|
||||||
|
|
||||||
|
kb_written (0444) kBytes written.
|
||||||
|
kb_read (0444) kBytes read.
|
||||||
|
kb_read_gather (0444) kBytes read to fill write packets.
|
||||||
|
|
||||||
|
reset (0200) Write any value to it to reset
|
||||||
|
pktcdvd device statistic values, like
|
||||||
|
bytes read/written.
|
||||||
|
|
||||||
|
/sys/class/pktcdvd/pktcdvd[0-7]/write_queue/
|
||||||
|
size (0444) Contains the size of the bio write
|
||||||
|
queue.
|
||||||
|
|
||||||
|
congestion_off (0644) If bio write queue size is below
|
||||||
|
this mark, accept new bio requests
|
||||||
|
from the block layer.
|
||||||
|
|
||||||
|
congestion_on (0644) If bio write queue size is higher
|
||||||
|
as this mark, do no longer accept
|
||||||
|
bio write requests from the block
|
||||||
|
layer and wait till the pktcdvd
|
||||||
|
device has processed enough bio's
|
||||||
|
so that bio write queue size is
|
||||||
|
below congestion off mark.
|
||||||
|
A value of <= 0 disables congestion
|
||||||
|
control.
|
||||||
|
|
||||||
|
|
||||||
|
Example:
|
||||||
|
--------
|
||||||
|
To use the pktcdvd sysfs interface directly, you can do:
|
||||||
|
|
||||||
|
# create a new pktcdvd device mapped to /dev/hdc
|
||||||
|
echo "22:0" >/sys/class/pktcdvd/add
|
||||||
|
cat /sys/class/pktcdvd/device_map
|
||||||
|
# assuming device pktcdvd0 was created, look at stat's
|
||||||
|
cat /sys/class/pktcdvd/pktcdvd0/stat/kb_written
|
||||||
|
# print the device id of the mapped block device
|
||||||
|
fgrep pktcdvd0 /sys/class/pktcdvd/device_map
|
||||||
|
# remove device, using pktcdvd0 device id 253:0
|
||||||
|
echo "253:0" >/sys/class/pktcdvd/remove
|
|
@ -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
|
||||||
|
|
|
@ -35,12 +35,37 @@ In short, 8-char indents make things easier to read, and have the added
|
||||||
benefit of warning you when you're nesting your functions too deep.
|
benefit of warning you when you're nesting your functions too deep.
|
||||||
Heed that warning.
|
Heed that warning.
|
||||||
|
|
||||||
|
The preferred way to ease multiple indentation levels in a switch statement is
|
||||||
|
to align the "switch" and its subordinate "case" labels in the same column
|
||||||
|
instead of "double-indenting" the "case" labels. E.g.:
|
||||||
|
|
||||||
|
switch (suffix) {
|
||||||
|
case 'G':
|
||||||
|
case 'g':
|
||||||
|
mem <<= 30;
|
||||||
|
break;
|
||||||
|
case 'M':
|
||||||
|
case 'm':
|
||||||
|
mem <<= 20;
|
||||||
|
break;
|
||||||
|
case 'K':
|
||||||
|
case 'k':
|
||||||
|
mem <<= 10;
|
||||||
|
/* fall through */
|
||||||
|
default:
|
||||||
|
break;
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
Don't put multiple statements on a single line unless you have
|
Don't put multiple statements on a single line unless you have
|
||||||
something to hide:
|
something to hide:
|
||||||
|
|
||||||
if (condition) do_this;
|
if (condition) do_this;
|
||||||
do_something_everytime;
|
do_something_everytime;
|
||||||
|
|
||||||
|
Don't put multiple assignments on a single line either. Kernel coding style
|
||||||
|
is super simple. Avoid tricky expressions.
|
||||||
|
|
||||||
Outside of comments, documentation and except in Kconfig, spaces are never
|
Outside of comments, documentation and except in Kconfig, spaces are never
|
||||||
used for indentation, and the above example is deliberately broken.
|
used for indentation, and the above example is deliberately broken.
|
||||||
|
|
||||||
|
@ -69,7 +94,7 @@ void fun(int a, int b, int c)
|
||||||
next_statement;
|
next_statement;
|
||||||
}
|
}
|
||||||
|
|
||||||
Chapter 3: Placing Braces
|
Chapter 3: Placing Braces and Spaces
|
||||||
|
|
||||||
The other issue that always comes up in C styling is the placement of
|
The other issue that always comes up in C styling is the placement of
|
||||||
braces. Unlike the indent size, there are few technical reasons to
|
braces. Unlike the indent size, there are few technical reasons to
|
||||||
|
@ -81,6 +106,20 @@ brace last on the line, and put the closing brace first, thusly:
|
||||||
we do y
|
we do y
|
||||||
}
|
}
|
||||||
|
|
||||||
|
This applies to all non-function statement blocks (if, switch, for,
|
||||||
|
while, do). E.g.:
|
||||||
|
|
||||||
|
switch (action) {
|
||||||
|
case KOBJ_ADD:
|
||||||
|
return "add";
|
||||||
|
case KOBJ_REMOVE:
|
||||||
|
return "remove";
|
||||||
|
case KOBJ_CHANGE:
|
||||||
|
return "change";
|
||||||
|
default:
|
||||||
|
return NULL;
|
||||||
|
}
|
||||||
|
|
||||||
However, there is one special case, namely functions: they have the
|
However, there is one special case, namely functions: they have the
|
||||||
opening brace at the beginning of the next line, thus:
|
opening brace at the beginning of the next line, thus:
|
||||||
|
|
||||||
|
@ -121,6 +160,49 @@ supply of new-lines on your screen is not a renewable resource (think
|
||||||
25-line terminal screens here), you have more empty lines to put
|
25-line terminal screens here), you have more empty lines to put
|
||||||
comments on.
|
comments on.
|
||||||
|
|
||||||
|
3.1: Spaces
|
||||||
|
|
||||||
|
Linux kernel style for use of spaces depends (mostly) on
|
||||||
|
function-versus-keyword usage. Use a space after (most) keywords. The
|
||||||
|
notable exceptions are sizeof, typeof, alignof, and __attribute__, which look
|
||||||
|
somewhat like functions (and are usually used with parentheses in Linux,
|
||||||
|
although they are not required in the language, as in: "sizeof info" after
|
||||||
|
"struct fileinfo info;" is declared).
|
||||||
|
|
||||||
|
So use a space after these keywords:
|
||||||
|
if, switch, case, for, do, while
|
||||||
|
but not with sizeof, typeof, alignof, or __attribute__. E.g.,
|
||||||
|
s = sizeof(struct file);
|
||||||
|
|
||||||
|
Do not add spaces around (inside) parenthesized expressions. This example is
|
||||||
|
*bad*:
|
||||||
|
|
||||||
|
s = sizeof( struct file );
|
||||||
|
|
||||||
|
When declaring pointer data or a function that returns a pointer type, the
|
||||||
|
preferred use of '*' is adjacent to the data name or function name and not
|
||||||
|
adjacent to the type name. Examples:
|
||||||
|
|
||||||
|
char *linux_banner;
|
||||||
|
unsigned long long memparse(char *ptr, char **retptr);
|
||||||
|
char *match_strdup(substring_t *s);
|
||||||
|
|
||||||
|
Use one space around (on each side of) most binary and ternary operators,
|
||||||
|
such as any of these:
|
||||||
|
|
||||||
|
= + - < > * / % | & ^ <= >= == != ? :
|
||||||
|
|
||||||
|
but no space after unary operators:
|
||||||
|
& * + - ~ ! sizeof typeof alignof __attribute__ defined
|
||||||
|
|
||||||
|
no space before the postfix increment & decrement unary operators:
|
||||||
|
++ --
|
||||||
|
|
||||||
|
no space after the prefix increment & decrement unary operators:
|
||||||
|
++ --
|
||||||
|
|
||||||
|
and no space around the '.' and "->" structure member operators.
|
||||||
|
|
||||||
|
|
||||||
Chapter 4: Naming
|
Chapter 4: Naming
|
||||||
|
|
||||||
|
@ -152,7 +234,7 @@ variable that is used to hold a temporary value.
|
||||||
|
|
||||||
If you are afraid to mix up your local variable names, you have another
|
If you are afraid to mix up your local variable names, you have another
|
||||||
problem, which is called the function-growth-hormone-imbalance syndrome.
|
problem, which is called the function-growth-hormone-imbalance syndrome.
|
||||||
See next chapter.
|
See chapter 6 (Functions).
|
||||||
|
|
||||||
|
|
||||||
Chapter 5: Typedefs
|
Chapter 5: Typedefs
|
||||||
|
@ -258,6 +340,20 @@ generally easily keep track of about 7 different things, anything more
|
||||||
and it gets confused. You know you're brilliant, but maybe you'd like
|
and it gets confused. You know you're brilliant, but maybe you'd like
|
||||||
to understand what you did 2 weeks from now.
|
to understand what you did 2 weeks from now.
|
||||||
|
|
||||||
|
In source files, separate functions with one blank line. If the function is
|
||||||
|
exported, the EXPORT* macro for it should follow immediately after the closing
|
||||||
|
function brace line. E.g.:
|
||||||
|
|
||||||
|
int system_is_up(void)
|
||||||
|
{
|
||||||
|
return system_state == SYSTEM_RUNNING;
|
||||||
|
}
|
||||||
|
EXPORT_SYMBOL(system_is_up);
|
||||||
|
|
||||||
|
In function prototypes, include parameter names with their data types.
|
||||||
|
Although this is not required by the C language, it is preferred in Linux
|
||||||
|
because it is a simple way to add valuable information for the reader.
|
||||||
|
|
||||||
|
|
||||||
Chapter 7: Centralized exiting of functions
|
Chapter 7: Centralized exiting of functions
|
||||||
|
|
||||||
|
@ -306,16 +402,36 @@ time to explain badly written code.
|
||||||
Generally, you want your comments to tell WHAT your code does, not HOW.
|
Generally, you want your comments to tell WHAT your code does, not HOW.
|
||||||
Also, try to avoid putting comments inside a function body: if the
|
Also, try to avoid putting comments inside a function body: if the
|
||||||
function is so complex that you need to separately comment parts of it,
|
function is so complex that you need to separately comment parts of it,
|
||||||
you should probably go back to chapter 5 for a while. You can make
|
you should probably go back to chapter 6 for a while. You can make
|
||||||
small comments to note or warn about something particularly clever (or
|
small comments to note or warn about something particularly clever (or
|
||||||
ugly), but try to avoid excess. Instead, put the comments at the head
|
ugly), but try to avoid excess. Instead, put the comments at the head
|
||||||
of the function, telling people what it does, and possibly WHY it does
|
of the function, telling people what it does, and possibly WHY it does
|
||||||
it.
|
it.
|
||||||
|
|
||||||
When commenting the kernel API functions, please use the kerneldoc format.
|
When commenting the kernel API functions, please use the kernel-doc format.
|
||||||
See the files Documentation/kernel-doc-nano-HOWTO.txt and scripts/kernel-doc
|
See the files Documentation/kernel-doc-nano-HOWTO.txt and scripts/kernel-doc
|
||||||
for details.
|
for details.
|
||||||
|
|
||||||
|
Linux style for comments is the C89 "/* ... */" style.
|
||||||
|
Don't use C99-style "// ..." comments.
|
||||||
|
|
||||||
|
The preferred style for long (multi-line) comments is:
|
||||||
|
|
||||||
|
/*
|
||||||
|
* This is the preferred style for multi-line
|
||||||
|
* comments in the Linux kernel source code.
|
||||||
|
* Please use it consistently.
|
||||||
|
*
|
||||||
|
* Description: A column of asterisks on the left side,
|
||||||
|
* with beginning and ending almost-blank lines.
|
||||||
|
*/
|
||||||
|
|
||||||
|
It's also important to comment data, whether they are basic types or derived
|
||||||
|
types. To this end, use just one data declaration per line (no commas for
|
||||||
|
multiple data declarations). This leaves you room for a small comment on each
|
||||||
|
item, explaining its use.
|
||||||
|
|
||||||
|
|
||||||
Chapter 9: You've made a mess of it
|
Chapter 9: You've made a mess of it
|
||||||
|
|
||||||
That's OK, we all do. You've probably been told by your long-time Unix
|
That's OK, we all do. You've probably been told by your long-time Unix
|
||||||
|
@ -591,4 +707,4 @@ Kernel CodingStyle, by greg@kroah.com at OLS 2002:
|
||||||
http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/
|
http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/
|
||||||
|
|
||||||
--
|
--
|
||||||
Last updated on 30 April 2006.
|
Last updated on 2006-December-06.
|
||||||
|
|
|
@ -77,7 +77,7 @@ To get this part of the dma_ API, you must #include <linux/dmapool.h>
|
||||||
Many drivers need lots of small dma-coherent memory regions for DMA
|
Many drivers need lots of small dma-coherent memory regions for DMA
|
||||||
descriptors or I/O buffers. Rather than allocating in units of a page
|
descriptors or I/O buffers. Rather than allocating in units of a page
|
||||||
or more using dma_alloc_coherent(), you can use DMA pools. These work
|
or more using dma_alloc_coherent(), you can use DMA pools. These work
|
||||||
much like a kmem_cache_t, except that they use the dma-coherent allocator
|
much like a struct kmem_cache, except that they use the dma-coherent allocator
|
||||||
not __get_free_pages(). Also, they understand common hardware constraints
|
not __get_free_pages(). Also, they understand common hardware constraints
|
||||||
for alignment, like queue heads needing to be aligned on N byte boundaries.
|
for alignment, like queue heads needing to be aligned on N byte boundaries.
|
||||||
|
|
||||||
|
@ -94,7 +94,7 @@ The pool create() routines initialize a pool of dma-coherent buffers
|
||||||
for use with a given device. It must be called in a context which
|
for use with a given device. It must be called in a context which
|
||||||
can sleep.
|
can sleep.
|
||||||
|
|
||||||
The "name" is for diagnostics (like a kmem_cache_t name); dev and size
|
The "name" is for diagnostics (like a struct kmem_cache name); dev and size
|
||||||
are like what you'd pass to dma_alloc_coherent(). The device's hardware
|
are like what you'd pass to dma_alloc_coherent(). The device's hardware
|
||||||
alignment requirement for this type of data is "align" (which is expressed
|
alignment requirement for this type of data is "align" (which is expressed
|
||||||
in bytes, and must be a power of two). If your device has no boundary
|
in bytes, and must be a power of two). If your device has no boundary
|
||||||
|
@ -431,10 +431,10 @@ be identical to those passed in (and returned by
|
||||||
dma_alloc_noncoherent()).
|
dma_alloc_noncoherent()).
|
||||||
|
|
||||||
int
|
int
|
||||||
dma_is_consistent(dma_addr_t dma_handle)
|
dma_is_consistent(struct device *dev, dma_addr_t dma_handle)
|
||||||
|
|
||||||
returns true if the memory pointed to by the dma_handle is actually
|
returns true if the device dev is performing consistent DMA on the memory
|
||||||
consistent.
|
area pointed to by the dma_handle.
|
||||||
|
|
||||||
int
|
int
|
||||||
dma_get_cache_alignment(void)
|
dma_get_cache_alignment(void)
|
||||||
|
@ -459,7 +459,7 @@ anything like this. You must also be extra careful about accessing
|
||||||
memory you intend to sync partially.
|
memory you intend to sync partially.
|
||||||
|
|
||||||
void
|
void
|
||||||
dma_cache_sync(void *vaddr, size_t size,
|
dma_cache_sync(struct device *dev, void *vaddr, size_t size,
|
||||||
enum dma_data_direction direction)
|
enum dma_data_direction direction)
|
||||||
|
|
||||||
Do a partial sync of memory that was allocated by
|
Do a partial sync of memory that was allocated by
|
||||||
|
@ -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
|
||||||
|
|
||||||
|
@ -190,9 +190,13 @@ quiet_cmd_fig2png = FIG2PNG $@
|
||||||
###
|
###
|
||||||
# Help targets as used by the top-level makefile
|
# Help targets as used by the top-level makefile
|
||||||
dochelp:
|
dochelp:
|
||||||
@echo ' Linux kernel internal documentation in different formats:'
|
@echo ' Linux kernel internal documentation in different formats:'
|
||||||
@echo ' xmldocs (XML DocBook), psdocs (Postscript), pdfdocs (PDF)'
|
@echo ' htmldocs - HTML'
|
||||||
@echo ' htmldocs (HTML), mandocs (man pages, use installmandocs to install)'
|
@echo ' installmandocs - install man pages generated by mandocs'
|
||||||
|
@echo ' mandocs - man pages'
|
||||||
|
@echo ' pdfdocs - PDF'
|
||||||
|
@echo ' psdocs - Postscript'
|
||||||
|
@echo ' xmldocs - XML DocBook'
|
||||||
|
|
||||||
###
|
###
|
||||||
# Temporary files left by various tools
|
# Temporary files left by various tools
|
||||||
|
|
|
@ -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>
|
||||||
|
|
||||||
|
@ -478,9 +418,35 @@ X!Edrivers/pnp/system.c
|
||||||
!Idrivers/parport/daisy.c
|
!Idrivers/parport/daisy.c
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
||||||
<chapter id="viddev">
|
<chapter id="message_devices">
|
||||||
<title>Video4Linux</title>
|
<title>Message-based devices</title>
|
||||||
!Edrivers/media/video/videodev.c
|
<sect1><title>Fusion message devices</title>
|
||||||
|
!Edrivers/message/fusion/mptbase.c
|
||||||
|
!Idrivers/message/fusion/mptbase.c
|
||||||
|
!Edrivers/message/fusion/mptscsih.c
|
||||||
|
!Idrivers/message/fusion/mptscsih.c
|
||||||
|
!Idrivers/message/fusion/mptctl.c
|
||||||
|
!Idrivers/message/fusion/mptspi.c
|
||||||
|
!Idrivers/message/fusion/mptfc.c
|
||||||
|
!Idrivers/message/fusion/mptlan.c
|
||||||
|
</sect1>
|
||||||
|
<sect1><title>I2O message devices</title>
|
||||||
|
!Iinclude/linux/i2o.h
|
||||||
|
!Idrivers/message/i2o/core.h
|
||||||
|
!Edrivers/message/i2o/iop.c
|
||||||
|
!Idrivers/message/i2o/iop.c
|
||||||
|
!Idrivers/message/i2o/config-osm.c
|
||||||
|
!Edrivers/message/i2o/exec-osm.c
|
||||||
|
!Idrivers/message/i2o/exec-osm.c
|
||||||
|
!Idrivers/message/i2o/bus-osm.c
|
||||||
|
!Edrivers/message/i2o/device.c
|
||||||
|
!Idrivers/message/i2o/device.c
|
||||||
|
!Idrivers/message/i2o/driver.c
|
||||||
|
!Idrivers/message/i2o/pci.c
|
||||||
|
!Idrivers/message/i2o/i2o_block.c
|
||||||
|
!Idrivers/message/i2o/i2o_scsi.c
|
||||||
|
!Idrivers/message/i2o/i2o_proc.c
|
||||||
|
</sect1>
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
||||||
<chapter id="snddev">
|
<chapter id="snddev">
|
||||||
|
@ -593,4 +559,12 @@ X!Idrivers/video/console/fonts.c
|
||||||
-->
|
-->
|
||||||
</sect1>
|
</sect1>
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
||||||
|
<chapter id="input_subsystem">
|
||||||
|
<title>Input Subsystem</title>
|
||||||
|
!Iinclude/linux/input.h
|
||||||
|
!Edrivers/input/input.c
|
||||||
|
!Edrivers/input/ff-core.c
|
||||||
|
!Edrivers/input/ff-memless.c
|
||||||
|
</chapter>
|
||||||
</book>
|
</book>
|
||||||
|
|
|
@ -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
|
||||||
-------------
|
-------------
|
||||||
|
|
||||||
|
|
|
@ -365,6 +365,7 @@ You can change this at module load time (for a module) with:
|
||||||
regshifts=<shift1>,<shift2>,...
|
regshifts=<shift1>,<shift2>,...
|
||||||
slave_addrs=<addr1>,<addr2>,...
|
slave_addrs=<addr1>,<addr2>,...
|
||||||
force_kipmid=<enable1>,<enable2>,...
|
force_kipmid=<enable1>,<enable2>,...
|
||||||
|
unload_when_empty=[0|1]
|
||||||
|
|
||||||
Each of these except si_trydefaults is a list, the first item for the
|
Each of these except si_trydefaults is a list, the first item for the
|
||||||
first interface, second item for the second interface, etc.
|
first interface, second item for the second interface, etc.
|
||||||
|
@ -416,6 +417,11 @@ by the driver, but systems with broken interrupts might need an enable,
|
||||||
or users that don't want the daemon (don't need the performance, don't
|
or users that don't want the daemon (don't need the performance, don't
|
||||||
want the CPU hit) can disable it.
|
want the CPU hit) can disable it.
|
||||||
|
|
||||||
|
If unload_when_empty is set to 1, the driver will be unloaded if it
|
||||||
|
doesn't find any interfaces or all the interfaces fail to work. The
|
||||||
|
default is one. Setting to 0 is useful with the hotmod, but is
|
||||||
|
obviously only useful for modules.
|
||||||
|
|
||||||
When compiled into the kernel, the parameters can be specified on the
|
When compiled into the kernel, the parameters can be specified on the
|
||||||
kernel command line as:
|
kernel command line as:
|
||||||
|
|
||||||
|
@ -441,6 +447,25 @@ have high-res timers enabled in the kernel and you don't have
|
||||||
interrupts enabled, the driver will run VERY slowly. Don't blame me,
|
interrupts enabled, the driver will run VERY slowly. Don't blame me,
|
||||||
these interfaces suck.
|
these interfaces suck.
|
||||||
|
|
||||||
|
The driver supports a hot add and remove of interfaces. This way,
|
||||||
|
interfaces can be added or removed after the kernel is up and running.
|
||||||
|
This is done using /sys/modules/ipmi_si/hotmod, which is a write-only
|
||||||
|
parameter. You write a string to this interface. The string has the
|
||||||
|
format:
|
||||||
|
<op1>[:op2[:op3...]]
|
||||||
|
The "op"s are:
|
||||||
|
add|remove,kcs|bt|smic,mem|i/o,<address>[,<opt1>[,<opt2>[,...]]]
|
||||||
|
You can specify more than one interface on the line. The "opt"s are:
|
||||||
|
rsp=<regspacing>
|
||||||
|
rsi=<regsize>
|
||||||
|
rsh=<regshift>
|
||||||
|
irq=<irq>
|
||||||
|
ipmb=<ipmb slave addr>
|
||||||
|
and these have the same meanings as discussed above. Note that you
|
||||||
|
can also use this on the kernel command line for a more compact format
|
||||||
|
for specifying an interface. Note that when removing an interface,
|
||||||
|
only the first three parameters (si type, address type, and address)
|
||||||
|
are used for the comparison. Any options are ignored for removing.
|
||||||
|
|
||||||
The SMBus Driver
|
The SMBus Driver
|
||||||
----------------
|
----------------
|
||||||
|
@ -502,7 +527,10 @@ used to control it:
|
||||||
|
|
||||||
modprobe ipmi_watchdog timeout=<t> pretimeout=<t> action=<action type>
|
modprobe ipmi_watchdog timeout=<t> pretimeout=<t> action=<action type>
|
||||||
preaction=<preaction type> preop=<preop type> start_now=x
|
preaction=<preaction type> preop=<preop type> start_now=x
|
||||||
nowayout=x
|
nowayout=x ifnum_to_use=n
|
||||||
|
|
||||||
|
ifnum_to_use specifies which interface the watchdog timer should use.
|
||||||
|
The default is -1, which means to pick the first one registered.
|
||||||
|
|
||||||
The timeout is the number of seconds to the action, and the pretimeout
|
The timeout is the number of seconds to the action, and the pretimeout
|
||||||
is the amount of seconds before the reset that the pre-timeout panic will
|
is the amount of seconds before the reset that the pre-timeout panic will
|
||||||
|
@ -624,5 +652,9 @@ command line. The parameter is also available via the proc filesystem
|
||||||
in /proc/sys/dev/ipmi/poweroff_powercycle. Note that if the system
|
in /proc/sys/dev/ipmi/poweroff_powercycle. Note that if the system
|
||||||
does not support power cycling, it will always do the power off.
|
does not support power cycling, it will always do the power off.
|
||||||
|
|
||||||
|
The "ifnum_to_use" parameter specifies which interface the poweroff
|
||||||
|
code should use. The default is -1, which means to pick the first one
|
||||||
|
registered.
|
||||||
|
|
||||||
Note that if you have ACPI enabled, the system will prefer using ACPI to
|
Note that if you have ACPI enabled, the system will prefer using ACPI to
|
||||||
power off.
|
power off.
|
||||||
|
|
|
@ -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?
|
||||||
|
|
||||||
|
|
|
@ -66,3 +66,9 @@ kernel patches.
|
||||||
See Documentation/ABI/README for more information.
|
See Documentation/ABI/README for more information.
|
||||||
|
|
||||||
20: Check that it all passes `make headers_check'.
|
20: Check that it all passes `make headers_check'.
|
||||||
|
|
||||||
|
21: Has been checked with injection of at least slab and page-allocation
|
||||||
|
fauilures. See Documentation/fault-injection/.
|
||||||
|
|
||||||
|
If the new code is substantial, addition of subsystem-specific fault
|
||||||
|
injection might be appropriate.
|
||||||
|
|
|
@ -7,6 +7,8 @@
|
||||||
* Copyright (C) Balbir Singh, IBM Corp. 2006
|
* Copyright (C) Balbir Singh, IBM Corp. 2006
|
||||||
* Copyright (c) Jay Lan, SGI. 2006
|
* Copyright (c) Jay Lan, SGI. 2006
|
||||||
*
|
*
|
||||||
|
* Compile with
|
||||||
|
* gcc -I/usr/src/linux/include getdelays.c -o getdelays
|
||||||
*/
|
*/
|
||||||
|
|
||||||
#include <stdio.h>
|
#include <stdio.h>
|
||||||
|
@ -35,13 +37,20 @@
|
||||||
#define NLA_DATA(na) ((void *)((char*)(na) + NLA_HDRLEN))
|
#define NLA_DATA(na) ((void *)((char*)(na) + NLA_HDRLEN))
|
||||||
#define NLA_PAYLOAD(len) (len - NLA_HDRLEN)
|
#define NLA_PAYLOAD(len) (len - NLA_HDRLEN)
|
||||||
|
|
||||||
#define err(code, fmt, arg...) do { printf(fmt, ##arg); exit(code); } while (0)
|
#define err(code, fmt, arg...) \
|
||||||
int done = 0;
|
do { \
|
||||||
int rcvbufsz=0;
|
fprintf(stderr, fmt, ##arg); \
|
||||||
|
exit(code); \
|
||||||
|
} while (0)
|
||||||
|
|
||||||
char name[100];
|
int done;
|
||||||
int dbg=0, print_delays=0;
|
int rcvbufsz;
|
||||||
|
char name[100];
|
||||||
|
int dbg;
|
||||||
|
int print_delays;
|
||||||
|
int print_io_accounting;
|
||||||
__u64 stime, utime;
|
__u64 stime, utime;
|
||||||
|
|
||||||
#define PRINTF(fmt, arg...) { \
|
#define PRINTF(fmt, arg...) { \
|
||||||
if (dbg) { \
|
if (dbg) { \
|
||||||
printf(fmt, ##arg); \
|
printf(fmt, ##arg); \
|
||||||
|
@ -49,7 +58,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 */
|
||||||
|
@ -78,8 +87,9 @@ static int create_nl_socket(int protocol)
|
||||||
if (rcvbufsz)
|
if (rcvbufsz)
|
||||||
if (setsockopt(fd, SOL_SOCKET, SO_RCVBUF,
|
if (setsockopt(fd, SOL_SOCKET, SO_RCVBUF,
|
||||||
&rcvbufsz, sizeof(rcvbufsz)) < 0) {
|
&rcvbufsz, sizeof(rcvbufsz)) < 0) {
|
||||||
printf("Unable to set socket rcv buf size to %d\n",
|
fprintf(stderr, "Unable to set socket rcv buf size "
|
||||||
rcvbufsz);
|
"to %d\n",
|
||||||
|
rcvbufsz);
|
||||||
return -1;
|
return -1;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@ -186,6 +196,15 @@ void print_delayacct(struct taskstats *t)
|
||||||
"count", "delay total", t->swapin_count, t->swapin_delay_total);
|
"count", "delay total", t->swapin_count, t->swapin_delay_total);
|
||||||
}
|
}
|
||||||
|
|
||||||
|
void print_ioacct(struct taskstats *t)
|
||||||
|
{
|
||||||
|
printf("%s: read=%llu, write=%llu, cancelled_write=%llu\n",
|
||||||
|
t->ac_comm,
|
||||||
|
(unsigned long long)t->read_bytes,
|
||||||
|
(unsigned long long)t->write_bytes,
|
||||||
|
(unsigned long long)t->cancelled_write_bytes);
|
||||||
|
}
|
||||||
|
|
||||||
int main(int argc, char *argv[])
|
int main(int argc, char *argv[])
|
||||||
{
|
{
|
||||||
int c, rc, rep_len, aggr_len, len2, cmd_type;
|
int c, rc, rep_len, aggr_len, len2, cmd_type;
|
||||||
|
@ -208,7 +227,7 @@ int main(int argc, char *argv[])
|
||||||
struct msgtemplate msg;
|
struct msgtemplate msg;
|
||||||
|
|
||||||
while (1) {
|
while (1) {
|
||||||
c = getopt(argc, argv, "dw:r:m:t:p:v:l");
|
c = getopt(argc, argv, "diw:r:m:t:p:v:l");
|
||||||
if (c < 0)
|
if (c < 0)
|
||||||
break;
|
break;
|
||||||
|
|
||||||
|
@ -217,6 +236,10 @@ int main(int argc, char *argv[])
|
||||||
printf("print delayacct stats ON\n");
|
printf("print delayacct stats ON\n");
|
||||||
print_delays = 1;
|
print_delays = 1;
|
||||||
break;
|
break;
|
||||||
|
case 'i':
|
||||||
|
printf("printing IO accounting\n");
|
||||||
|
print_io_accounting = 1;
|
||||||
|
break;
|
||||||
case 'w':
|
case 'w':
|
||||||
strncpy(logfile, optarg, MAX_FILENAME);
|
strncpy(logfile, optarg, MAX_FILENAME);
|
||||||
printf("write to file %s\n", logfile);
|
printf("write to file %s\n", logfile);
|
||||||
|
@ -238,14 +261,12 @@ int main(int argc, char *argv[])
|
||||||
if (!tid)
|
if (!tid)
|
||||||
err(1, "Invalid tgid\n");
|
err(1, "Invalid tgid\n");
|
||||||
cmd_type = TASKSTATS_CMD_ATTR_TGID;
|
cmd_type = TASKSTATS_CMD_ATTR_TGID;
|
||||||
print_delays = 1;
|
|
||||||
break;
|
break;
|
||||||
case 'p':
|
case 'p':
|
||||||
tid = atoi(optarg);
|
tid = atoi(optarg);
|
||||||
if (!tid)
|
if (!tid)
|
||||||
err(1, "Invalid pid\n");
|
err(1, "Invalid pid\n");
|
||||||
cmd_type = TASKSTATS_CMD_ATTR_PID;
|
cmd_type = TASKSTATS_CMD_ATTR_PID;
|
||||||
print_delays = 1;
|
|
||||||
break;
|
break;
|
||||||
case 'v':
|
case 'v':
|
||||||
printf("debug on\n");
|
printf("debug on\n");
|
||||||
|
@ -277,7 +298,7 @@ int main(int argc, char *argv[])
|
||||||
mypid = getpid();
|
mypid = getpid();
|
||||||
id = get_family_id(nl_sd);
|
id = get_family_id(nl_sd);
|
||||||
if (!id) {
|
if (!id) {
|
||||||
printf("Error getting family id, errno %d", errno);
|
fprintf(stderr, "Error getting family id, errno %d\n", errno);
|
||||||
goto err;
|
goto err;
|
||||||
}
|
}
|
||||||
PRINTF("family id %d\n", id);
|
PRINTF("family id %d\n", id);
|
||||||
|
@ -288,7 +309,7 @@ int main(int argc, char *argv[])
|
||||||
&cpumask, strlen(cpumask) + 1);
|
&cpumask, strlen(cpumask) + 1);
|
||||||
PRINTF("Sent register cpumask, retval %d\n", rc);
|
PRINTF("Sent register cpumask, retval %d\n", rc);
|
||||||
if (rc < 0) {
|
if (rc < 0) {
|
||||||
printf("error sending register cpumask\n");
|
fprintf(stderr, "error sending register cpumask\n");
|
||||||
goto err;
|
goto err;
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
@ -298,7 +319,7 @@ int main(int argc, char *argv[])
|
||||||
cmd_type, &tid, sizeof(__u32));
|
cmd_type, &tid, sizeof(__u32));
|
||||||
PRINTF("Sent pid/tgid, retval %d\n", rc);
|
PRINTF("Sent pid/tgid, retval %d\n", rc);
|
||||||
if (rc < 0) {
|
if (rc < 0) {
|
||||||
printf("error sending tid/tgid cmd\n");
|
fprintf(stderr, "error sending tid/tgid cmd\n");
|
||||||
goto done;
|
goto done;
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
@ -310,13 +331,15 @@ int main(int argc, char *argv[])
|
||||||
PRINTF("received %d bytes\n", rep_len);
|
PRINTF("received %d bytes\n", rep_len);
|
||||||
|
|
||||||
if (rep_len < 0) {
|
if (rep_len < 0) {
|
||||||
printf("nonfatal reply error: errno %d\n", errno);
|
fprintf(stderr, "nonfatal reply error: errno %d\n",
|
||||||
|
errno);
|
||||||
continue;
|
continue;
|
||||||
}
|
}
|
||||||
if (msg.n.nlmsg_type == NLMSG_ERROR ||
|
if (msg.n.nlmsg_type == NLMSG_ERROR ||
|
||||||
!NLMSG_OK((&msg.n), rep_len)) {
|
!NLMSG_OK((&msg.n), rep_len)) {
|
||||||
struct nlmsgerr *err = NLMSG_DATA(&msg);
|
struct nlmsgerr *err = NLMSG_DATA(&msg);
|
||||||
printf("fatal reply error, errno %d\n", err->error);
|
fprintf(stderr, "fatal reply error, errno %d\n",
|
||||||
|
err->error);
|
||||||
goto done;
|
goto done;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@ -356,6 +379,8 @@ int main(int argc, char *argv[])
|
||||||
count++;
|
count++;
|
||||||
if (print_delays)
|
if (print_delays)
|
||||||
print_delayacct((struct taskstats *) NLA_DATA(na));
|
print_delayacct((struct taskstats *) NLA_DATA(na));
|
||||||
|
if (print_io_accounting)
|
||||||
|
print_ioacct((struct taskstats *) NLA_DATA(na));
|
||||||
if (fd) {
|
if (fd) {
|
||||||
if (write(fd, NLA_DATA(na), na->nla_len) < 0) {
|
if (write(fd, NLA_DATA(na), na->nla_len) < 0) {
|
||||||
err(1,"write error\n");
|
err(1,"write error\n");
|
||||||
|
@ -365,7 +390,9 @@ int main(int argc, char *argv[])
|
||||||
goto done;
|
goto done;
|
||||||
break;
|
break;
|
||||||
default:
|
default:
|
||||||
printf("Unknown nested nla_type %d\n", na->nla_type);
|
fprintf(stderr, "Unknown nested"
|
||||||
|
" nla_type %d\n",
|
||||||
|
na->nla_type);
|
||||||
break;
|
break;
|
||||||
}
|
}
|
||||||
len2 += NLA_ALIGN(na->nla_len);
|
len2 += NLA_ALIGN(na->nla_len);
|
||||||
|
@ -374,7 +401,8 @@ int main(int argc, char *argv[])
|
||||||
break;
|
break;
|
||||||
|
|
||||||
default:
|
default:
|
||||||
printf("Unknown nla_type %d\n", na->nla_type);
|
fprintf(stderr, "Unknown nla_type %d\n",
|
||||||
|
na->nla_type);
|
||||||
break;
|
break;
|
||||||
}
|
}
|
||||||
na = (struct nlattr *) (GENLMSG_DATA(&msg) + len);
|
na = (struct nlattr *) (GENLMSG_DATA(&msg) + len);
|
||||||
|
|
|
@ -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
|
||||||
|
|
|
@ -24,8 +24,10 @@ very similar behavior to the deadline IO scheduler.
|
||||||
Selecting IO schedulers
|
Selecting IO schedulers
|
||||||
-----------------------
|
-----------------------
|
||||||
To choose IO schedulers at boot time, use the argument 'elevator=deadline'.
|
To choose IO schedulers at boot time, use the argument 'elevator=deadline'.
|
||||||
'noop' and 'as' (the default) are also available. IO schedulers are assigned
|
'noop', 'as' and 'cfq' (the default) are also available. IO schedulers are
|
||||||
globally at boot time only presently.
|
assigned globally at boot time only presently. It's also possible to change
|
||||||
|
the IO scheduler for a determined device on the fly, as described in
|
||||||
|
Documentation/block/switching-sched.txt.
|
||||||
|
|
||||||
|
|
||||||
Anticipatory IO scheduler Policies
|
Anticipatory IO scheduler Policies
|
||||||
|
|
|
@ -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.
|
||||||
|
|
||||||
|
|
|
@ -90,6 +90,41 @@ Notes
|
||||||
to create an ext2 filesystem on the disc.
|
to create an ext2 filesystem on the disc.
|
||||||
|
|
||||||
|
|
||||||
|
Using the pktcdvd sysfs interface
|
||||||
|
---------------------------------
|
||||||
|
|
||||||
|
Since Linux 2.6.19, the pktcdvd module has a sysfs interface
|
||||||
|
and can be controlled by it. For example the "pktcdvd" tool uses
|
||||||
|
this interface. (see http://people.freenet.de/BalaGi#pktcdvd )
|
||||||
|
|
||||||
|
"pktcdvd" works similar to "pktsetup", e.g.:
|
||||||
|
|
||||||
|
# pktcdvd -a dev_name /dev/hdc
|
||||||
|
# mkudffs /dev/pktcdvd/dev_name
|
||||||
|
# mount -t udf -o rw,noatime /dev/pktcdvd/dev_name /dvdram
|
||||||
|
# cp files /dvdram
|
||||||
|
# umount /dvdram
|
||||||
|
# pktcdvd -r dev_name
|
||||||
|
|
||||||
|
|
||||||
|
For a description of the sysfs interface look into the file:
|
||||||
|
|
||||||
|
Documentation/ABI/testing/sysfs-block-pktcdvd
|
||||||
|
|
||||||
|
|
||||||
|
Using the pktcdvd debugfs interface
|
||||||
|
-----------------------------------
|
||||||
|
|
||||||
|
To read pktcdvd device infos in human readable form, do:
|
||||||
|
|
||||||
|
# cat /debug/pktcdvd/pktcdvd[0-7]/info
|
||||||
|
|
||||||
|
For a description of the debugfs interface look into the file:
|
||||||
|
|
||||||
|
Documentation/ABI/testing/debugfs-pktcdvd
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Links
|
Links
|
||||||
-----
|
-----
|
||||||
|
|
||||||
|
|
|
@ -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.
|
||||||
|
|
|
@ -3,7 +3,7 @@
|
||||||
|
|
||||||
Maintained by Torben Mathiasen <device@lanana.org>
|
Maintained by Torben Mathiasen <device@lanana.org>
|
||||||
|
|
||||||
Last revised: 15 May 2006
|
Last revised: 29 November 2006
|
||||||
|
|
||||||
This list is the Linux Device List, the official registry of allocated
|
This list is the Linux Device List, the official registry of allocated
|
||||||
device numbers and /dev directory nodes for the Linux operating
|
device numbers and /dev directory nodes for the Linux operating
|
||||||
|
@ -92,8 +92,9 @@ 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
|
||||||
1 = /dev/ram1 Second RAM disk
|
1 = /dev/ram1 Second RAM disk
|
||||||
|
@ -122,7 +123,7 @@ Your cooperation is appreciated.
|
||||||
devices are on major 128 and above and use the PTY
|
devices are on major 128 and above and use the PTY
|
||||||
master multiplex (/dev/ptmx) to acquire a PTY on
|
master multiplex (/dev/ptmx) to acquire a PTY on
|
||||||
demand.
|
demand.
|
||||||
|
|
||||||
2 block Floppy disks
|
2 block Floppy disks
|
||||||
0 = /dev/fd0 Controller 0, drive 0, autodetect
|
0 = /dev/fd0 Controller 0, drive 0, autodetect
|
||||||
1 = /dev/fd1 Controller 0, drive 1, autodetect
|
1 = /dev/fd1 Controller 0, drive 1, autodetect
|
||||||
|
@ -257,7 +258,7 @@ Your cooperation is appreciated.
|
||||||
129 = /dev/vcsa1 tty1 text/attribute contents
|
129 = /dev/vcsa1 tty1 text/attribute contents
|
||||||
...
|
...
|
||||||
191 = /dev/vcsa63 tty63 text/attribute contents
|
191 = /dev/vcsa63 tty63 text/attribute contents
|
||||||
|
|
||||||
NOTE: These devices permit both read and write access.
|
NOTE: These devices permit both read and write access.
|
||||||
|
|
||||||
7 block Loopback devices
|
7 block Loopback devices
|
||||||
|
@ -411,7 +412,7 @@ Your cooperation is appreciated.
|
||||||
207 = /dev/video/em8300_sp EM8300 DVD decoder subpicture
|
207 = /dev/video/em8300_sp EM8300 DVD decoder subpicture
|
||||||
208 = /dev/compaq/cpqphpc Compaq PCI Hot Plug Controller
|
208 = /dev/compaq/cpqphpc Compaq PCI Hot Plug Controller
|
||||||
209 = /dev/compaq/cpqrid Compaq Remote Insight Driver
|
209 = /dev/compaq/cpqrid Compaq Remote Insight Driver
|
||||||
210 = /dev/impi/bt IMPI coprocessor block transfer
|
210 = /dev/impi/bt IMPI coprocessor block transfer
|
||||||
211 = /dev/impi/smic IMPI coprocessor stream interface
|
211 = /dev/impi/smic IMPI coprocessor stream interface
|
||||||
212 = /dev/watchdogs/0 First watchdog device
|
212 = /dev/watchdogs/0 First watchdog device
|
||||||
213 = /dev/watchdogs/1 Second watchdog device
|
213 = /dev/watchdogs/1 Second watchdog device
|
||||||
|
@ -506,6 +507,7 @@ Your cooperation is appreciated.
|
||||||
33 = /dev/patmgr1 Sequencer patch manager
|
33 = /dev/patmgr1 Sequencer patch manager
|
||||||
34 = /dev/midi02 Third MIDI port
|
34 = /dev/midi02 Third MIDI port
|
||||||
50 = /dev/midi03 Fourth MIDI port
|
50 = /dev/midi03 Fourth MIDI port
|
||||||
|
|
||||||
14 block BIOS harddrive callback support {2.6}
|
14 block BIOS harddrive callback support {2.6}
|
||||||
0 = /dev/dos_hda First BIOS harddrive whole disk
|
0 = /dev/dos_hda First BIOS harddrive whole disk
|
||||||
64 = /dev/dos_hdb Second BIOS harddrive whole disk
|
64 = /dev/dos_hdb Second BIOS harddrive whole disk
|
||||||
|
@ -527,6 +529,7 @@ Your cooperation is appreciated.
|
||||||
|
|
||||||
16 char Non-SCSI scanners
|
16 char Non-SCSI scanners
|
||||||
0 = /dev/gs4500 Genius 4500 handheld scanner
|
0 = /dev/gs4500 Genius 4500 handheld scanner
|
||||||
|
|
||||||
16 block GoldStar CD-ROM
|
16 block GoldStar CD-ROM
|
||||||
0 = /dev/gscd GoldStar CD-ROM
|
0 = /dev/gscd GoldStar CD-ROM
|
||||||
|
|
||||||
|
@ -548,6 +551,7 @@ Your cooperation is appreciated.
|
||||||
0 = /dev/ttyC0 First Cyclades port
|
0 = /dev/ttyC0 First Cyclades port
|
||||||
...
|
...
|
||||||
31 = /dev/ttyC31 32nd Cyclades port
|
31 = /dev/ttyC31 32nd Cyclades port
|
||||||
|
|
||||||
19 block "Double" compressed disk
|
19 block "Double" compressed disk
|
||||||
0 = /dev/double0 First compressed disk
|
0 = /dev/double0 First compressed disk
|
||||||
...
|
...
|
||||||
|
@ -563,6 +567,7 @@ Your cooperation is appreciated.
|
||||||
0 = /dev/cub0 Callout device for ttyC0
|
0 = /dev/cub0 Callout device for ttyC0
|
||||||
...
|
...
|
||||||
31 = /dev/cub31 Callout device for ttyC31
|
31 = /dev/cub31 Callout device for ttyC31
|
||||||
|
|
||||||
20 block Hitachi CD-ROM (under development)
|
20 block Hitachi CD-ROM (under development)
|
||||||
0 = /dev/hitcd Hitachi CD-ROM
|
0 = /dev/hitcd Hitachi CD-ROM
|
||||||
|
|
||||||
|
@ -582,7 +587,7 @@ Your cooperation is appreciated.
|
||||||
|
|
||||||
This device is used on the ARM-based Acorn RiscPC.
|
This device is used on the ARM-based Acorn RiscPC.
|
||||||
Partitions are handled the same way as for IDE disks
|
Partitions are handled the same way as for IDE disks
|
||||||
(see major number 3).
|
(see major number 3).
|
||||||
|
|
||||||
22 char Digiboard serial card
|
22 char Digiboard serial card
|
||||||
0 = /dev/ttyD0 First Digiboard port
|
0 = /dev/ttyD0 First Digiboard port
|
||||||
|
@ -591,7 +596,7 @@ Your cooperation is appreciated.
|
||||||
22 block Second IDE hard disk/CD-ROM interface
|
22 block Second IDE hard disk/CD-ROM interface
|
||||||
0 = /dev/hdc Master: whole disk (or CD-ROM)
|
0 = /dev/hdc Master: whole disk (or CD-ROM)
|
||||||
64 = /dev/hdd Slave: whole disk (or CD-ROM)
|
64 = /dev/hdd Slave: whole disk (or CD-ROM)
|
||||||
|
|
||||||
Partitions are handled the same way as for the first
|
Partitions are handled the same way as for the first
|
||||||
interface (see major number 3).
|
interface (see major number 3).
|
||||||
|
|
||||||
|
@ -639,6 +644,7 @@ Your cooperation is appreciated.
|
||||||
|
|
||||||
26 char Quanta WinVision frame grabber {2.6}
|
26 char Quanta WinVision frame grabber {2.6}
|
||||||
0 = /dev/wvisfgrab Quanta WinVision frame grabber
|
0 = /dev/wvisfgrab Quanta WinVision frame grabber
|
||||||
|
|
||||||
26 block Second Matsushita (Panasonic/SoundBlaster) CD-ROM
|
26 block Second Matsushita (Panasonic/SoundBlaster) CD-ROM
|
||||||
0 = /dev/sbpcd4 Panasonic CD-ROM controller 1 unit 0
|
0 = /dev/sbpcd4 Panasonic CD-ROM controller 1 unit 0
|
||||||
1 = /dev/sbpcd5 Panasonic CD-ROM controller 1 unit 1
|
1 = /dev/sbpcd5 Panasonic CD-ROM controller 1 unit 1
|
||||||
|
@ -670,6 +676,7 @@ Your cooperation is appreciated.
|
||||||
37 = /dev/nrawqft1 Unit 1, no rewind-on-close, no file marks
|
37 = /dev/nrawqft1 Unit 1, no rewind-on-close, no file marks
|
||||||
38 = /dev/nrawqft2 Unit 2, no rewind-on-close, no file marks
|
38 = /dev/nrawqft2 Unit 2, no rewind-on-close, no file marks
|
||||||
39 = /dev/nrawqft3 Unit 3, no rewind-on-close, no file marks
|
39 = /dev/nrawqft3 Unit 3, no rewind-on-close, no file marks
|
||||||
|
|
||||||
27 block Third Matsushita (Panasonic/SoundBlaster) CD-ROM
|
27 block Third Matsushita (Panasonic/SoundBlaster) CD-ROM
|
||||||
0 = /dev/sbpcd8 Panasonic CD-ROM controller 2 unit 0
|
0 = /dev/sbpcd8 Panasonic CD-ROM controller 2 unit 0
|
||||||
1 = /dev/sbpcd9 Panasonic CD-ROM controller 2 unit 1
|
1 = /dev/sbpcd9 Panasonic CD-ROM controller 2 unit 1
|
||||||
|
@ -681,6 +688,7 @@ Your cooperation is appreciated.
|
||||||
1 = /dev/staliomem1 Second Stallion card I/O memory
|
1 = /dev/staliomem1 Second Stallion card I/O memory
|
||||||
2 = /dev/staliomem2 Third Stallion card I/O memory
|
2 = /dev/staliomem2 Third Stallion card I/O memory
|
||||||
3 = /dev/staliomem3 Fourth Stallion card I/O memory
|
3 = /dev/staliomem3 Fourth Stallion card I/O memory
|
||||||
|
|
||||||
28 char Atari SLM ACSI laser printer (68k/Atari)
|
28 char Atari SLM ACSI laser printer (68k/Atari)
|
||||||
0 = /dev/slm0 First SLM laser printer
|
0 = /dev/slm0 First SLM laser printer
|
||||||
1 = /dev/slm1 Second SLM laser printer
|
1 = /dev/slm1 Second SLM laser printer
|
||||||
|
@ -690,6 +698,7 @@ Your cooperation is appreciated.
|
||||||
1 = /dev/sbpcd13 Panasonic CD-ROM controller 3 unit 1
|
1 = /dev/sbpcd13 Panasonic CD-ROM controller 3 unit 1
|
||||||
2 = /dev/sbpcd14 Panasonic CD-ROM controller 3 unit 2
|
2 = /dev/sbpcd14 Panasonic CD-ROM controller 3 unit 2
|
||||||
3 = /dev/sbpcd15 Panasonic CD-ROM controller 3 unit 3
|
3 = /dev/sbpcd15 Panasonic CD-ROM controller 3 unit 3
|
||||||
|
|
||||||
28 block ACSI disk (68k/Atari)
|
28 block ACSI disk (68k/Atari)
|
||||||
0 = /dev/ada First ACSI disk whole disk
|
0 = /dev/ada First ACSI disk whole disk
|
||||||
16 = /dev/adb Second ACSI disk whole disk
|
16 = /dev/adb Second ACSI disk whole disk
|
||||||
|
@ -750,6 +759,7 @@ Your cooperation is appreciated.
|
||||||
31 char MPU-401 MIDI
|
31 char MPU-401 MIDI
|
||||||
0 = /dev/mpu401data MPU-401 data port
|
0 = /dev/mpu401data MPU-401 data port
|
||||||
1 = /dev/mpu401stat MPU-401 status port
|
1 = /dev/mpu401stat MPU-401 status port
|
||||||
|
|
||||||
31 block ROM/flash memory card
|
31 block ROM/flash memory card
|
||||||
0 = /dev/rom0 First ROM card (rw)
|
0 = /dev/rom0 First ROM card (rw)
|
||||||
...
|
...
|
||||||
|
@ -801,7 +811,7 @@ Your cooperation is appreciated.
|
||||||
34 block Fourth IDE hard disk/CD-ROM interface
|
34 block Fourth IDE hard disk/CD-ROM interface
|
||||||
0 = /dev/hdg Master: whole disk (or CD-ROM)
|
0 = /dev/hdg Master: whole disk (or CD-ROM)
|
||||||
64 = /dev/hdh Slave: whole disk (or CD-ROM)
|
64 = /dev/hdh Slave: whole disk (or CD-ROM)
|
||||||
|
|
||||||
Partitions are handled the same way as for the first
|
Partitions are handled the same way as for the first
|
||||||
interface (see major number 3).
|
interface (see major number 3).
|
||||||
|
|
||||||
|
@ -818,6 +828,7 @@ Your cooperation is appreciated.
|
||||||
129 = /dev/smpte1 Second MIDI port, SMPTE timed
|
129 = /dev/smpte1 Second MIDI port, SMPTE timed
|
||||||
130 = /dev/smpte2 Third MIDI port, SMPTE timed
|
130 = /dev/smpte2 Third MIDI port, SMPTE timed
|
||||||
131 = /dev/smpte3 Fourth MIDI port, SMPTE timed
|
131 = /dev/smpte3 Fourth MIDI port, SMPTE timed
|
||||||
|
|
||||||
35 block Slow memory ramdisk
|
35 block Slow memory ramdisk
|
||||||
0 = /dev/slram Slow memory ramdisk
|
0 = /dev/slram Slow memory ramdisk
|
||||||
|
|
||||||
|
@ -828,6 +839,7 @@ Your cooperation is appreciated.
|
||||||
16 = /dev/tap0 First Ethertap device
|
16 = /dev/tap0 First Ethertap device
|
||||||
...
|
...
|
||||||
31 = /dev/tap15 16th Ethertap device
|
31 = /dev/tap15 16th Ethertap device
|
||||||
|
|
||||||
36 block MCA ESDI hard disk
|
36 block MCA ESDI hard disk
|
||||||
0 = /dev/eda First ESDI disk whole disk
|
0 = /dev/eda First ESDI disk whole disk
|
||||||
64 = /dev/edb Second ESDI disk whole disk
|
64 = /dev/edb Second ESDI disk whole disk
|
||||||
|
@ -882,6 +894,7 @@ Your cooperation is appreciated.
|
||||||
|
|
||||||
40 char Matrox Meteor frame grabber {2.6}
|
40 char Matrox Meteor frame grabber {2.6}
|
||||||
0 = /dev/mmetfgrab Matrox Meteor frame grabber
|
0 = /dev/mmetfgrab Matrox Meteor frame grabber
|
||||||
|
|
||||||
40 block Syquest EZ135 parallel port removable drive
|
40 block Syquest EZ135 parallel port removable drive
|
||||||
0 = /dev/eza Parallel EZ135 drive, whole disk
|
0 = /dev/eza Parallel EZ135 drive, whole disk
|
||||||
|
|
||||||
|
@ -893,6 +906,7 @@ Your cooperation is appreciated.
|
||||||
|
|
||||||
41 char Yet Another Micro Monitor
|
41 char Yet Another Micro Monitor
|
||||||
0 = /dev/yamm Yet Another Micro Monitor
|
0 = /dev/yamm Yet Another Micro Monitor
|
||||||
|
|
||||||
41 block MicroSolutions BackPack parallel port CD-ROM
|
41 block MicroSolutions BackPack parallel port CD-ROM
|
||||||
0 = /dev/bpcd BackPack CD-ROM
|
0 = /dev/bpcd BackPack CD-ROM
|
||||||
|
|
||||||
|
@ -901,6 +915,7 @@ Your cooperation is appreciated.
|
||||||
the parallel port ATAPI CD-ROM driver at major number 46.
|
the parallel port ATAPI CD-ROM driver at major number 46.
|
||||||
|
|
||||||
42 char Demo/sample use
|
42 char Demo/sample use
|
||||||
|
|
||||||
42 block Demo/sample use
|
42 block Demo/sample use
|
||||||
|
|
||||||
This number is intended for use in sample code, as
|
This number is intended for use in sample code, as
|
||||||
|
@ -918,6 +933,7 @@ Your cooperation is appreciated.
|
||||||
0 = /dev/ttyI0 First virtual modem
|
0 = /dev/ttyI0 First virtual modem
|
||||||
...
|
...
|
||||||
63 = /dev/ttyI63 64th virtual modem
|
63 = /dev/ttyI63 64th virtual modem
|
||||||
|
|
||||||
43 block Network block devices
|
43 block Network block devices
|
||||||
0 = /dev/nb0 First network block device
|
0 = /dev/nb0 First network block device
|
||||||
1 = /dev/nb1 Second network block device
|
1 = /dev/nb1 Second network block device
|
||||||
|
@ -934,12 +950,13 @@ Your cooperation is appreciated.
|
||||||
0 = /dev/cui0 Callout device for ttyI0
|
0 = /dev/cui0 Callout device for ttyI0
|
||||||
...
|
...
|
||||||
63 = /dev/cui63 Callout device for ttyI63
|
63 = /dev/cui63 Callout device for ttyI63
|
||||||
|
|
||||||
44 block Flash Translation Layer (FTL) filesystems
|
44 block Flash Translation Layer (FTL) filesystems
|
||||||
0 = /dev/ftla FTL on first Memory Technology Device
|
0 = /dev/ftla FTL on first Memory Technology Device
|
||||||
16 = /dev/ftlb FTL on second Memory Technology Device
|
16 = /dev/ftlb FTL on second Memory Technology Device
|
||||||
32 = /dev/ftlc FTL on third Memory Technology Device
|
32 = /dev/ftlc FTL on third Memory Technology Device
|
||||||
...
|
...
|
||||||
240 = /dev/ftlp FTL on 16th Memory Technology Device
|
240 = /dev/ftlp FTL on 16th Memory Technology Device
|
||||||
|
|
||||||
Partitions are handled in the same way as for IDE
|
Partitions are handled in the same way as for IDE
|
||||||
disks (see major number 3) except that the partition
|
disks (see major number 3) except that the partition
|
||||||
|
@ -958,6 +975,7 @@ Your cooperation is appreciated.
|
||||||
191 = /dev/ippp63 64th SyncPPP device
|
191 = /dev/ippp63 64th SyncPPP device
|
||||||
|
|
||||||
255 = /dev/isdninfo ISDN monitor interface
|
255 = /dev/isdninfo ISDN monitor interface
|
||||||
|
|
||||||
45 block Parallel port IDE disk devices
|
45 block Parallel port IDE disk devices
|
||||||
0 = /dev/pda First parallel port IDE disk
|
0 = /dev/pda First parallel port IDE disk
|
||||||
16 = /dev/pdb Second parallel port IDE disk
|
16 = /dev/pdb Second parallel port IDE disk
|
||||||
|
@ -1044,6 +1062,7 @@ Your cooperation is appreciated.
|
||||||
1 = /dev/dcbri1 Second DataComm card
|
1 = /dev/dcbri1 Second DataComm card
|
||||||
2 = /dev/dcbri2 Third DataComm card
|
2 = /dev/dcbri2 Third DataComm card
|
||||||
3 = /dev/dcbri3 Fourth DataComm card
|
3 = /dev/dcbri3 Fourth DataComm card
|
||||||
|
|
||||||
52 block Mylex DAC960 PCI RAID controller; fifth controller
|
52 block Mylex DAC960 PCI RAID controller; fifth controller
|
||||||
0 = /dev/rd/c4d0 First disk, whole disk
|
0 = /dev/rd/c4d0 First disk, whole disk
|
||||||
8 = /dev/rd/c4d1 Second disk, whole disk
|
8 = /dev/rd/c4d1 Second disk, whole disk
|
||||||
|
@ -1093,7 +1112,8 @@ 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
|
||||||
...
|
...
|
||||||
|
@ -1130,6 +1150,7 @@ Your cooperation is appreciated.
|
||||||
0 = /dev/cup0 Callout device for ttyP0
|
0 = /dev/cup0 Callout device for ttyP0
|
||||||
1 = /dev/cup1 Callout device for ttyP1
|
1 = /dev/cup1 Callout device for ttyP1
|
||||||
...
|
...
|
||||||
|
|
||||||
58 block Reserved for logical volume manager
|
58 block Reserved for logical volume manager
|
||||||
|
|
||||||
59 char sf firewall package
|
59 char sf firewall package
|
||||||
|
@ -1149,6 +1170,7 @@ Your cooperation is appreciated.
|
||||||
NAMING CONFLICT -- PROPOSED REVISED NAME /dev/rpda0 etc
|
NAMING CONFLICT -- PROPOSED REVISED NAME /dev/rpda0 etc
|
||||||
|
|
||||||
60-63 char LOCAL/EXPERIMENTAL USE
|
60-63 char LOCAL/EXPERIMENTAL USE
|
||||||
|
|
||||||
60-63 block LOCAL/EXPERIMENTAL USE
|
60-63 block LOCAL/EXPERIMENTAL USE
|
||||||
Allocated for local/experimental use. For devices not
|
Allocated for local/experimental use. For devices not
|
||||||
assigned official numbers, these ranges should be
|
assigned official numbers, these ranges should be
|
||||||
|
@ -1434,7 +1456,6 @@ Your cooperation is appreciated.
|
||||||
DAC960 (see major number 48) except that the limit on
|
DAC960 (see major number 48) except that the limit on
|
||||||
partitions is 15.
|
partitions is 15.
|
||||||
|
|
||||||
|
|
||||||
78 char PAM Software's multimodem boards
|
78 char PAM Software's multimodem boards
|
||||||
0 = /dev/ttyM0 First PAM modem
|
0 = /dev/ttyM0 First PAM modem
|
||||||
1 = /dev/ttyM1 Second PAM modem
|
1 = /dev/ttyM1 Second PAM modem
|
||||||
|
@ -1450,13 +1471,12 @@ Your cooperation is appreciated.
|
||||||
DAC960 (see major number 48) except that the limit on
|
DAC960 (see major number 48) except that the limit on
|
||||||
partitions is 15.
|
partitions is 15.
|
||||||
|
|
||||||
|
|
||||||
79 char PAM Software's multimodem boards - alternate devices
|
79 char PAM Software's multimodem boards - alternate devices
|
||||||
0 = /dev/cum0 Callout device for ttyM0
|
0 = /dev/cum0 Callout device for ttyM0
|
||||||
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
|
||||||
...
|
...
|
||||||
|
@ -1466,7 +1486,6 @@ Your cooperation is appreciated.
|
||||||
DAC960 (see major number 48) except that the limit on
|
DAC960 (see major number 48) except that the limit on
|
||||||
partitions is 15.
|
partitions is 15.
|
||||||
|
|
||||||
|
|
||||||
80 char Photometrics AT200 CCD camera
|
80 char Photometrics AT200 CCD camera
|
||||||
0 = /dev/at200 Photometrics AT200 CCD camera
|
0 = /dev/at200 Photometrics AT200 CCD camera
|
||||||
|
|
||||||
|
@ -1679,7 +1698,7 @@ Your cooperation is appreciated.
|
||||||
1 = /dev/dcxx1 Second capture card
|
1 = /dev/dcxx1 Second capture card
|
||||||
...
|
...
|
||||||
|
|
||||||
94 block IBM S/390 DASD block storage
|
94 block IBM S/390 DASD block storage
|
||||||
0 = /dev/dasda First DASD device, major
|
0 = /dev/dasda First DASD device, major
|
||||||
1 = /dev/dasda1 First DASD device, block 1
|
1 = /dev/dasda1 First DASD device, block 1
|
||||||
2 = /dev/dasda2 First DASD device, block 2
|
2 = /dev/dasda2 First DASD device, block 2
|
||||||
|
@ -1695,7 +1714,7 @@ Your cooperation is appreciated.
|
||||||
1 = /dev/ipnat NAT control device/log file
|
1 = /dev/ipnat NAT control device/log file
|
||||||
2 = /dev/ipstate State information log file
|
2 = /dev/ipstate State information log file
|
||||||
3 = /dev/ipauth Authentication control device/log file
|
3 = /dev/ipauth Authentication control device/log file
|
||||||
...
|
...
|
||||||
|
|
||||||
96 char Parallel port ATAPI tape devices
|
96 char Parallel port ATAPI tape devices
|
||||||
0 = /dev/pt0 First parallel port ATAPI tape
|
0 = /dev/pt0 First parallel port ATAPI tape
|
||||||
|
@ -1705,7 +1724,7 @@ Your cooperation is appreciated.
|
||||||
129 = /dev/npt1 Second p.p. ATAPI tape, no rewind
|
129 = /dev/npt1 Second p.p. ATAPI tape, no rewind
|
||||||
...
|
...
|
||||||
|
|
||||||
96 block Inverse NAND Flash Translation Layer
|
96 block Inverse NAND Flash Translation Layer
|
||||||
0 = /dev/inftla First INFTL layer
|
0 = /dev/inftla First INFTL layer
|
||||||
16 = /dev/inftlb Second INFTL layer
|
16 = /dev/inftlb Second INFTL layer
|
||||||
...
|
...
|
||||||
|
@ -1900,7 +1919,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
|
||||||
...
|
...
|
||||||
|
@ -1937,7 +1956,6 @@ Your cooperation is appreciated.
|
||||||
...
|
...
|
||||||
|
|
||||||
113 block IBM iSeries virtual CD-ROM
|
113 block IBM iSeries virtual CD-ROM
|
||||||
|
|
||||||
0 = /dev/iseries/vcda First virtual CD-ROM
|
0 = /dev/iseries/vcda First virtual CD-ROM
|
||||||
1 = /dev/iseries/vcdb Second virtual CD-ROM
|
1 = /dev/iseries/vcdb Second virtual CD-ROM
|
||||||
...
|
...
|
||||||
|
@ -2059,11 +2077,12 @@ Your cooperation is appreciated.
|
||||||
...
|
...
|
||||||
|
|
||||||
119 char VMware virtual network control
|
119 char VMware virtual network control
|
||||||
0 = /dev/vnet0 1st virtual network
|
0 = /dev/vmnet0 1st virtual network
|
||||||
1 = /dev/vnet1 2nd virtual network
|
1 = /dev/vmnet1 2nd virtual network
|
||||||
...
|
...
|
||||||
|
|
||||||
120-127 char LOCAL/EXPERIMENTAL USE
|
120-127 char LOCAL/EXPERIMENTAL USE
|
||||||
|
|
||||||
120-127 block LOCAL/EXPERIMENTAL USE
|
120-127 block LOCAL/EXPERIMENTAL USE
|
||||||
Allocated for local/experimental use. For devices not
|
Allocated for local/experimental use. For devices not
|
||||||
assigned official numbers, these ranges should be
|
assigned official numbers, these ranges should be
|
||||||
|
@ -2075,7 +2094,6 @@ Your cooperation is appreciated.
|
||||||
nodes; instead they should be accessed through the
|
nodes; instead they should be accessed through the
|
||||||
/dev/ptmx cloning interface.
|
/dev/ptmx cloning interface.
|
||||||
|
|
||||||
|
|
||||||
128 block SCSI disk devices (128-143)
|
128 block SCSI disk devices (128-143)
|
||||||
0 = /dev/sddy 129th SCSI disk whole disk
|
0 = /dev/sddy 129th SCSI disk whole disk
|
||||||
16 = /dev/sddz 130th SCSI disk whole disk
|
16 = /dev/sddz 130th SCSI disk whole disk
|
||||||
|
@ -2087,7 +2105,6 @@ Your cooperation is appreciated.
|
||||||
disks (see major number 3) except that the limit on
|
disks (see major number 3) except that the limit on
|
||||||
partitions is 15.
|
partitions is 15.
|
||||||
|
|
||||||
|
|
||||||
129 block SCSI disk devices (144-159)
|
129 block SCSI disk devices (144-159)
|
||||||
0 = /dev/sdeo 145th SCSI disk whole disk
|
0 = /dev/sdeo 145th SCSI disk whole disk
|
||||||
16 = /dev/sdep 146th SCSI disk whole disk
|
16 = /dev/sdep 146th SCSI disk whole disk
|
||||||
|
@ -2123,7 +2140,6 @@ Your cooperation is appreciated.
|
||||||
disks (see major number 3) except that the limit on
|
disks (see major number 3) except that the limit on
|
||||||
partitions is 15.
|
partitions is 15.
|
||||||
|
|
||||||
|
|
||||||
132 block SCSI disk devices (192-207)
|
132 block SCSI disk devices (192-207)
|
||||||
0 = /dev/sdgk 193rd SCSI disk whole disk
|
0 = /dev/sdgk 193rd SCSI disk whole disk
|
||||||
16 = /dev/sdgl 194th SCSI disk whole disk
|
16 = /dev/sdgl 194th SCSI disk whole disk
|
||||||
|
@ -2135,7 +2151,6 @@ Your cooperation is appreciated.
|
||||||
disks (see major number 3) except that the limit on
|
disks (see major number 3) except that the limit on
|
||||||
partitions is 15.
|
partitions is 15.
|
||||||
|
|
||||||
|
|
||||||
133 block SCSI disk devices (208-223)
|
133 block SCSI disk devices (208-223)
|
||||||
0 = /dev/sdha 209th SCSI disk whole disk
|
0 = /dev/sdha 209th SCSI disk whole disk
|
||||||
16 = /dev/sdhb 210th SCSI disk whole disk
|
16 = /dev/sdhb 210th SCSI disk whole disk
|
||||||
|
@ -2147,7 +2162,6 @@ Your cooperation is appreciated.
|
||||||
disks (see major number 3) except that the limit on
|
disks (see major number 3) except that the limit on
|
||||||
partitions is 15.
|
partitions is 15.
|
||||||
|
|
||||||
|
|
||||||
134 block SCSI disk devices (224-239)
|
134 block SCSI disk devices (224-239)
|
||||||
0 = /dev/sdhq 225th SCSI disk whole disk
|
0 = /dev/sdhq 225th SCSI disk whole disk
|
||||||
16 = /dev/sdhr 226th SCSI disk whole disk
|
16 = /dev/sdhr 226th SCSI disk whole disk
|
||||||
|
@ -2159,7 +2173,6 @@ Your cooperation is appreciated.
|
||||||
disks (see major number 3) except that the limit on
|
disks (see major number 3) except that the limit on
|
||||||
partitions is 15.
|
partitions is 15.
|
||||||
|
|
||||||
|
|
||||||
135 block SCSI disk devices (240-255)
|
135 block SCSI disk devices (240-255)
|
||||||
0 = /dev/sdig 241st SCSI disk whole disk
|
0 = /dev/sdig 241st SCSI disk whole disk
|
||||||
16 = /dev/sdih 242nd SCSI disk whole disk
|
16 = /dev/sdih 242nd SCSI disk whole disk
|
||||||
|
@ -2171,7 +2184,6 @@ Your cooperation is appreciated.
|
||||||
disks (see major number 3) except that the limit on
|
disks (see major number 3) except that the limit on
|
||||||
partitions is 15.
|
partitions is 15.
|
||||||
|
|
||||||
|
|
||||||
136-143 char Unix98 PTY slaves
|
136-143 char Unix98 PTY slaves
|
||||||
0 = /dev/pts/0 First Unix98 pseudo-TTY
|
0 = /dev/pts/0 First Unix98 pseudo-TTY
|
||||||
1 = /dev/pts/1 Second Unix98 pesudo-TTY
|
1 = /dev/pts/1 Second Unix98 pesudo-TTY
|
||||||
|
@ -2384,6 +2396,7 @@ Your cooperation is appreciated.
|
||||||
...
|
...
|
||||||
|
|
||||||
159 char RESERVED
|
159 char RESERVED
|
||||||
|
|
||||||
159 block RESERVED
|
159 block RESERVED
|
||||||
|
|
||||||
160 char General Purpose Instrument Bus (GPIB)
|
160 char General Purpose Instrument Bus (GPIB)
|
||||||
|
@ -2427,7 +2440,7 @@ Your cooperation is appreciated.
|
||||||
|
|
||||||
Partitions are handled in the same way as for IDE
|
Partitions are handled in the same way as for IDE
|
||||||
disks (see major number 3) except that the limit on
|
disks (see major number 3) except that the limit on
|
||||||
partitions is 31.
|
partitions is 31.
|
||||||
|
|
||||||
162 char Raw block device interface
|
162 char Raw block device interface
|
||||||
0 = /dev/rawctl Raw I/O control device
|
0 = /dev/rawctl Raw I/O control device
|
||||||
|
@ -2483,7 +2496,6 @@ Your cooperation is appreciated.
|
||||||
|
|
||||||
171 char Reserved for IEEE 1394 (Firewire)
|
171 char Reserved for IEEE 1394 (Firewire)
|
||||||
|
|
||||||
|
|
||||||
172 char Moxa Intellio serial card
|
172 char Moxa Intellio serial card
|
||||||
0 = /dev/ttyMX0 First Moxa port
|
0 = /dev/ttyMX0 First Moxa port
|
||||||
1 = /dev/ttyMX1 Second Moxa port
|
1 = /dev/ttyMX1 Second Moxa port
|
||||||
|
@ -2543,9 +2555,6 @@ Your cooperation is appreciated.
|
||||||
64 = /dev/usb/rio500 Diamond Rio 500
|
64 = /dev/usb/rio500 Diamond Rio 500
|
||||||
65 = /dev/usb/usblcd USBLCD Interface (info@usblcd.de)
|
65 = /dev/usb/usblcd USBLCD Interface (info@usblcd.de)
|
||||||
66 = /dev/usb/cpad0 Synaptics cPad (mouse/LCD)
|
66 = /dev/usb/cpad0 Synaptics cPad (mouse/LCD)
|
||||||
67 = /dev/usb/adutux0 1st Ontrak ADU device
|
|
||||||
...
|
|
||||||
76 = /dev/usb/adutux10 10th Ontrak ADU device
|
|
||||||
96 = /dev/usb/hiddev0 1st USB HID device
|
96 = /dev/usb/hiddev0 1st USB HID device
|
||||||
...
|
...
|
||||||
111 = /dev/usb/hiddev15 16th USB HID device
|
111 = /dev/usb/hiddev15 16th USB HID device
|
||||||
|
@ -2558,7 +2567,7 @@ Your cooperation is appreciated.
|
||||||
132 = /dev/usb/idmouse ID Mouse (fingerprint scanner) device
|
132 = /dev/usb/idmouse ID Mouse (fingerprint scanner) device
|
||||||
133 = /dev/usb/sisusbvga1 First SiSUSB VGA device
|
133 = /dev/usb/sisusbvga1 First SiSUSB VGA device
|
||||||
...
|
...
|
||||||
140 = /dev/usb/sisusbvga8 Eigth SISUSB VGA device
|
140 = /dev/usb/sisusbvga8 Eighth SISUSB VGA device
|
||||||
144 = /dev/usb/lcd USB LCD device
|
144 = /dev/usb/lcd USB LCD device
|
||||||
160 = /dev/usb/legousbtower0 1st USB Legotower device
|
160 = /dev/usb/legousbtower0 1st USB Legotower device
|
||||||
...
|
...
|
||||||
|
@ -2571,7 +2580,7 @@ Your cooperation is appreciated.
|
||||||
0 = /dev/uba First USB block device
|
0 = /dev/uba First USB block device
|
||||||
8 = /dev/ubb Second USB block device
|
8 = /dev/ubb Second USB block device
|
||||||
16 = /dev/ubc Third USB block device
|
16 = /dev/ubc Third USB block device
|
||||||
...
|
...
|
||||||
|
|
||||||
181 char Conrad Electronic parallel port radio clocks
|
181 char Conrad Electronic parallel port radio clocks
|
||||||
0 = /dev/pcfclock0 First Conrad radio clock
|
0 = /dev/pcfclock0 First Conrad radio clock
|
||||||
|
@ -2657,7 +2666,7 @@ Your cooperation is appreciated.
|
||||||
32 = /dev/mvideo/status2 Third device
|
32 = /dev/mvideo/status2 Third device
|
||||||
...
|
...
|
||||||
...
|
...
|
||||||
240 = /dev/mvideo/status15 16th device
|
240 = /dev/mvideo/status15 16th device
|
||||||
...
|
...
|
||||||
|
|
||||||
195 char Nvidia graphics devices
|
195 char Nvidia graphics devices
|
||||||
|
@ -2795,6 +2804,10 @@ Your cooperation is appreciated.
|
||||||
...
|
...
|
||||||
185 = /dev/ttyNX15 Hilscher netX serial port 15
|
185 = /dev/ttyNX15 Hilscher netX serial port 15
|
||||||
186 = /dev/ttyJ0 JTAG1 DCC protocol based serial port emulation
|
186 = /dev/ttyJ0 JTAG1 DCC protocol based serial port emulation
|
||||||
|
187 = /dev/ttyUL0 Xilinx uartlite - port 0
|
||||||
|
...
|
||||||
|
190 = /dev/ttyUL3 Xilinx uartlite - port 3
|
||||||
|
191 = /dev/xvc0 Xen virtual console - port 0
|
||||||
|
|
||||||
205 char Low-density serial ports (alternate device)
|
205 char Low-density serial ports (alternate device)
|
||||||
0 = /dev/culu0 Callout device for ttyLU0
|
0 = /dev/culu0 Callout device for ttyLU0
|
||||||
|
@ -2832,7 +2845,6 @@ Your cooperation is appreciated.
|
||||||
82 = /dev/cuvr0 Callout device for ttyVR0
|
82 = /dev/cuvr0 Callout device for ttyVR0
|
||||||
83 = /dev/cuvr1 Callout device for ttyVR1
|
83 = /dev/cuvr1 Callout device for ttyVR1
|
||||||
|
|
||||||
|
|
||||||
206 char OnStream SC-x0 tape devices
|
206 char OnStream SC-x0 tape devices
|
||||||
0 = /dev/osst0 First OnStream SCSI tape, mode 0
|
0 = /dev/osst0 First OnStream SCSI tape, mode 0
|
||||||
1 = /dev/osst1 Second OnStream SCSI tape, mode 0
|
1 = /dev/osst1 Second OnStream SCSI tape, mode 0
|
||||||
|
@ -2922,7 +2934,6 @@ Your cooperation is appreciated.
|
||||||
...
|
...
|
||||||
|
|
||||||
212 char LinuxTV.org DVB driver subsystem
|
212 char LinuxTV.org DVB driver subsystem
|
||||||
|
|
||||||
0 = /dev/dvb/adapter0/video0 first video decoder of first card
|
0 = /dev/dvb/adapter0/video0 first video decoder of first card
|
||||||
1 = /dev/dvb/adapter0/audio0 first audio decoder of first card
|
1 = /dev/dvb/adapter0/audio0 first audio decoder of first card
|
||||||
2 = /dev/dvb/adapter0/sec0 (obsolete/unused)
|
2 = /dev/dvb/adapter0/sec0 (obsolete/unused)
|
||||||
|
@ -3008,9 +3019,9 @@ Your cooperation is appreciated.
|
||||||
2 = /dev/3270/tub2 Second 3270 terminal
|
2 = /dev/3270/tub2 Second 3270 terminal
|
||||||
...
|
...
|
||||||
|
|
||||||
229 char IBM iSeries virtual console
|
229 char IBM iSeries/pSeries virtual console
|
||||||
0 = /dev/iseries/vtty0 First console port
|
0 = /dev/hvc0 First console port
|
||||||
1 = /dev/iseries/vtty1 Second console port
|
1 = /dev/hvc1 Second console port
|
||||||
...
|
...
|
||||||
|
|
||||||
230 char IBM iSeries virtual tape
|
230 char IBM iSeries virtual tape
|
||||||
|
@ -3083,12 +3094,14 @@ Your cooperation is appreciated.
|
||||||
234-239 UNASSIGNED
|
234-239 UNASSIGNED
|
||||||
|
|
||||||
240-254 char LOCAL/EXPERIMENTAL USE
|
240-254 char LOCAL/EXPERIMENTAL USE
|
||||||
|
|
||||||
240-254 block LOCAL/EXPERIMENTAL USE
|
240-254 block LOCAL/EXPERIMENTAL USE
|
||||||
Allocated for local/experimental use. For devices not
|
Allocated for local/experimental use. For devices not
|
||||||
assigned official numbers, these ranges should be
|
assigned official numbers, these ranges should be
|
||||||
used in order to avoid conflicting with future assignments.
|
used in order to avoid conflicting with future assignments.
|
||||||
|
|
||||||
255 char RESERVED
|
255 char RESERVED
|
||||||
|
|
||||||
255 block RESERVED
|
255 block RESERVED
|
||||||
|
|
||||||
This major is reserved to assist the expansion to a
|
This major is reserved to assist the expansion to a
|
||||||
|
@ -3115,7 +3128,20 @@ Your cooperation is appreciated.
|
||||||
257 char Phoenix Technologies Cryptographic Services Driver
|
257 char Phoenix Technologies Cryptographic Services Driver
|
||||||
0 = /dev/ptlsec Crypto Services Driver
|
0 = /dev/ptlsec Crypto Services Driver
|
||||||
|
|
||||||
|
257 block SSFDC Flash Translation Layer filesystem
|
||||||
|
0 = /dev/ssfdca First SSFDC layer
|
||||||
|
8 = /dev/ssfdcb Second SSFDC layer
|
||||||
|
16 = /dev/ssfdcc Third SSFDC layer
|
||||||
|
24 = /dev/ssfdcd 4th SSFDC layer
|
||||||
|
32 = /dev/ssfdce 5th SSFDC layer
|
||||||
|
40 = /dev/ssfdcf 6th SSFDC layer
|
||||||
|
48 = /dev/ssfdcg 7th SSFDC layer
|
||||||
|
56 = /dev/ssfdch 8th SSFDC layer
|
||||||
|
|
||||||
|
258 block ROM/Flash read-only translation layer
|
||||||
|
0 = /dev/blockrom0 First ROM card's translation layer interface
|
||||||
|
1 = /dev/blockrom1 Second ROM card's translation layer interface
|
||||||
|
...
|
||||||
|
|
||||||
**** ADDITIONAL /dev DIRECTORY ENTRIES
|
**** ADDITIONAL /dev DIRECTORY ENTRIES
|
||||||
|
|
||||||
|
|
|
@ -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 {
|
||||||
|
|
|
@ -22,10 +22,10 @@ o Frontends drivers:
|
||||||
- ves1x93 : Alps BSRV2 (ves1893 demodulator) and dbox2 (ves1993)
|
- ves1x93 : Alps BSRV2 (ves1893 demodulator) and dbox2 (ves1993)
|
||||||
- cx24110 : Conexant HM1221/HM1811 (cx24110 or cx24106 demod, cx24108 PLL)
|
- cx24110 : Conexant HM1221/HM1811 (cx24110 or cx24106 demod, cx24108 PLL)
|
||||||
- grundig_29504-491 : Grundig 29504-491 (Philips TDA8083 demodulator), tsa5522 PLL
|
- grundig_29504-491 : Grundig 29504-491 (Philips TDA8083 demodulator), tsa5522 PLL
|
||||||
- mt312 : Zarlink mt312 or Mitel vp310 demodulator, sl1935 or tsa5059 PLL
|
- mt312 : Zarlink mt312 or Mitel vp310 demodulator, sl1935 or tsa5059 PLLi, Technisat Sky2Pc with bios Rev. 2.3
|
||||||
- stv0299 : Alps BSRU6 (tsa5059 PLL), LG TDQB-S00x (tsa5059 PLL),
|
- stv0299 : Alps BSRU6 (tsa5059 PLL), LG TDQB-S00x (tsa5059 PLL),
|
||||||
LG TDQF-S001F (sl1935 PLL), Philips SU1278 (tua6100 PLL),
|
LG TDQF-S001F (sl1935 PLL), Philips SU1278 (tua6100 PLL),
|
||||||
Philips SU1278SH (tsa5059 PLL), Samsung TBMU24112IMB
|
Philips SU1278SH (tsa5059 PLL), Samsung TBMU24112IMB, Technisat Sky2Pc with bios Rev. 2.6
|
||||||
DVB-C:
|
DVB-C:
|
||||||
- ves1820 : various (ves1820 demodulator, sp5659c or spXXXX PLL)
|
- ves1820 : various (ves1820 demodulator, sp5659c or spXXXX PLL)
|
||||||
- at76c651 : Atmel AT76c651(B) with DAT7021 PLL
|
- at76c651 : Atmel AT76c651(B) with DAT7021 PLL
|
||||||
|
|
|
@ -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 :
|
||||||
|
|
|
@ -0,0 +1,4 @@
|
||||||
|
#!/bin/bash
|
||||||
|
|
||||||
|
echo 1 > /proc/self/make-it-fail
|
||||||
|
exec $*
|
|
@ -0,0 +1,31 @@
|
||||||
|
#!/bin/bash
|
||||||
|
#
|
||||||
|
# Usage: failmodule <failname> <modulename> [stacktrace-depth]
|
||||||
|
#
|
||||||
|
# <failname>: "failslab", "fail_alloc_page", or "fail_make_request"
|
||||||
|
#
|
||||||
|
# <modulename>: module name that you want to inject faults.
|
||||||
|
#
|
||||||
|
# [stacktrace-depth]: the maximum number of stacktrace walking allowed
|
||||||
|
#
|
||||||
|
|
||||||
|
STACKTRACE_DEPTH=5
|
||||||
|
if [ $# -gt 2 ]; then
|
||||||
|
STACKTRACE_DEPTH=$3
|
||||||
|
fi
|
||||||
|
|
||||||
|
if [ ! -d /debug/$1 ]; then
|
||||||
|
echo "Fault-injection $1 does not exist" >&2
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
if [ ! -d /sys/module/$2 ]; then
|
||||||
|
echo "Module $2 does not exist" >&2
|
||||||
|
exit 1
|
||||||
|
fi
|
||||||
|
|
||||||
|
# Disable any fault injection
|
||||||
|
echo 0 > /debug/$1/stacktrace-depth
|
||||||
|
|
||||||
|
echo `cat /sys/module/$2/sections/.text` > /debug/$1/require-start
|
||||||
|
echo `cat /sys/module/$2/sections/.exit.text` > /debug/$1/require-end
|
||||||
|
echo $STACKTRACE_DEPTH > /debug/$1/stacktrace-depth
|
|
@ -0,0 +1,225 @@
|
||||||
|
Fault injection capabilities infrastructure
|
||||||
|
===========================================
|
||||||
|
|
||||||
|
See also drivers/md/faulty.c and "every_nth" module option for scsi_debug.
|
||||||
|
|
||||||
|
|
||||||
|
Available fault injection capabilities
|
||||||
|
--------------------------------------
|
||||||
|
|
||||||
|
o failslab
|
||||||
|
|
||||||
|
injects slab allocation failures. (kmalloc(), kmem_cache_alloc(), ...)
|
||||||
|
|
||||||
|
o fail_page_alloc
|
||||||
|
|
||||||
|
injects page allocation failures. (alloc_pages(), get_free_pages(), ...)
|
||||||
|
|
||||||
|
o fail_make_request
|
||||||
|
|
||||||
|
injects disk IO errors on devices permitted by setting
|
||||||
|
/sys/block/<device>/make-it-fail or
|
||||||
|
/sys/block/<device>/<partition>/make-it-fail. (generic_make_request())
|
||||||
|
|
||||||
|
Configure fault-injection capabilities behavior
|
||||||
|
-----------------------------------------------
|
||||||
|
|
||||||
|
o debugfs entries
|
||||||
|
|
||||||
|
fault-inject-debugfs kernel module provides some debugfs entries for runtime
|
||||||
|
configuration of fault-injection capabilities.
|
||||||
|
|
||||||
|
- /debug/fail*/probability:
|
||||||
|
|
||||||
|
likelihood of failure injection, in percent.
|
||||||
|
Format: <percent>
|
||||||
|
|
||||||
|
Note that one-failure-per-hundred is a very high error rate
|
||||||
|
for some testcases. Consider setting probability=100 and configure
|
||||||
|
/debug/fail*/interval for such testcases.
|
||||||
|
|
||||||
|
- /debug/fail*/interval:
|
||||||
|
|
||||||
|
specifies the interval between failures, for calls to
|
||||||
|
should_fail() that pass all the other tests.
|
||||||
|
|
||||||
|
Note that if you enable this, by setting interval>1, you will
|
||||||
|
probably want to set probability=100.
|
||||||
|
|
||||||
|
- /debug/fail*/times:
|
||||||
|
|
||||||
|
specifies how many times failures may happen at most.
|
||||||
|
A value of -1 means "no limit".
|
||||||
|
|
||||||
|
- /debug/fail*/space:
|
||||||
|
|
||||||
|
specifies an initial resource "budget", decremented by "size"
|
||||||
|
on each call to should_fail(,size). Failure injection is
|
||||||
|
suppressed until "space" reaches zero.
|
||||||
|
|
||||||
|
- /debug/fail*/verbose
|
||||||
|
|
||||||
|
Format: { 0 | 1 | 2 }
|
||||||
|
specifies the verbosity of the messages when failure is
|
||||||
|
injected. '0' means no messages; '1' will print only a single
|
||||||
|
log line per failure; '2' will print a call trace too -- useful
|
||||||
|
to debug the problems revealed by fault injection.
|
||||||
|
|
||||||
|
- /debug/fail*/task-filter:
|
||||||
|
|
||||||
|
Format: { 'Y' | 'N' }
|
||||||
|
A value of 'N' disables filtering by process (default).
|
||||||
|
Any positive value limits failures to only processes indicated by
|
||||||
|
/proc/<pid>/make-it-fail==1.
|
||||||
|
|
||||||
|
- /debug/fail*/require-start:
|
||||||
|
- /debug/fail*/require-end:
|
||||||
|
- /debug/fail*/reject-start:
|
||||||
|
- /debug/fail*/reject-end:
|
||||||
|
|
||||||
|
specifies the range of virtual addresses tested during
|
||||||
|
stacktrace walking. Failure is injected only if some caller
|
||||||
|
in the walked stacktrace lies within the required range, and
|
||||||
|
none lies within the rejected range.
|
||||||
|
Default required range is [0,ULONG_MAX) (whole of virtual address space).
|
||||||
|
Default rejected range is [0,0).
|
||||||
|
|
||||||
|
- /debug/fail*/stacktrace-depth:
|
||||||
|
|
||||||
|
specifies the maximum stacktrace depth walked during search
|
||||||
|
for a caller within [require-start,require-end) OR
|
||||||
|
[reject-start,reject-end).
|
||||||
|
|
||||||
|
- /debug/fail_page_alloc/ignore-gfp-highmem:
|
||||||
|
|
||||||
|
Format: { 'Y' | 'N' }
|
||||||
|
default is 'N', setting it to 'Y' won't inject failures into
|
||||||
|
highmem/user allocations.
|
||||||
|
|
||||||
|
- /debug/failslab/ignore-gfp-wait:
|
||||||
|
- /debug/fail_page_alloc/ignore-gfp-wait:
|
||||||
|
|
||||||
|
Format: { 'Y' | 'N' }
|
||||||
|
default is 'N', setting it to 'Y' will inject failures
|
||||||
|
only into non-sleep allocations (GFP_ATOMIC allocations).
|
||||||
|
|
||||||
|
o Boot option
|
||||||
|
|
||||||
|
In order to inject faults while debugfs is not available (early boot time),
|
||||||
|
use the boot option:
|
||||||
|
|
||||||
|
failslab=
|
||||||
|
fail_page_alloc=
|
||||||
|
fail_make_request=<interval>,<probability>,<space>,<times>
|
||||||
|
|
||||||
|
How to add new fault injection capability
|
||||||
|
-----------------------------------------
|
||||||
|
|
||||||
|
o #include <linux/fault-inject.h>
|
||||||
|
|
||||||
|
o define the fault attributes
|
||||||
|
|
||||||
|
DECLARE_FAULT_INJECTION(name);
|
||||||
|
|
||||||
|
Please see the definition of struct fault_attr in fault-inject.h
|
||||||
|
for details.
|
||||||
|
|
||||||
|
o provide a way to configure fault attributes
|
||||||
|
|
||||||
|
- boot option
|
||||||
|
|
||||||
|
If you need to enable the fault injection capability from boot time, you can
|
||||||
|
provide boot option to configure it. There is a helper function for it:
|
||||||
|
|
||||||
|
setup_fault_attr(attr, str);
|
||||||
|
|
||||||
|
- debugfs entries
|
||||||
|
|
||||||
|
failslab, fail_page_alloc, and fail_make_request use this way.
|
||||||
|
Helper functions:
|
||||||
|
|
||||||
|
init_fault_attr_entries(entries, attr, name);
|
||||||
|
void cleanup_fault_attr_entries(entries);
|
||||||
|
|
||||||
|
- module parameters
|
||||||
|
|
||||||
|
If the scope of the fault injection capability is limited to a
|
||||||
|
single kernel module, it is better to provide module parameters to
|
||||||
|
configure the fault attributes.
|
||||||
|
|
||||||
|
o add a hook to insert failures
|
||||||
|
|
||||||
|
Upon should_fail() returning true, client code should inject a failure.
|
||||||
|
|
||||||
|
should_fail(attr, size);
|
||||||
|
|
||||||
|
Application Examples
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
o inject slab allocation failures into module init/cleanup code
|
||||||
|
|
||||||
|
------------------------------------------------------------------------------
|
||||||
|
#!/bin/bash
|
||||||
|
|
||||||
|
FAILCMD=Documentation/fault-injection/failcmd.sh
|
||||||
|
BLACKLIST="root_plug evbug"
|
||||||
|
|
||||||
|
FAILNAME=failslab
|
||||||
|
echo Y > /debug/$FAILNAME/task-filter
|
||||||
|
echo 10 > /debug/$FAILNAME/probability
|
||||||
|
echo 100 > /debug/$FAILNAME/interval
|
||||||
|
echo -1 > /debug/$FAILNAME/times
|
||||||
|
echo 2 > /debug/$FAILNAME/verbose
|
||||||
|
echo 1 > /debug/$FAILNAME/ignore-gfp-wait
|
||||||
|
|
||||||
|
blacklist()
|
||||||
|
{
|
||||||
|
echo $BLACKLIST | grep $1 > /dev/null 2>&1
|
||||||
|
}
|
||||||
|
|
||||||
|
oops()
|
||||||
|
{
|
||||||
|
dmesg | grep BUG > /dev/null 2>&1
|
||||||
|
}
|
||||||
|
|
||||||
|
find /lib/modules/`uname -r` -name '*.ko' -exec basename {} .ko \; |
|
||||||
|
while read i
|
||||||
|
do
|
||||||
|
oops && exit 1
|
||||||
|
|
||||||
|
if ! blacklist $i
|
||||||
|
then
|
||||||
|
echo inserting $i...
|
||||||
|
bash $FAILCMD modprobe $i
|
||||||
|
fi
|
||||||
|
done
|
||||||
|
|
||||||
|
lsmod | awk '{ if ($3 == 0) { print $1 } }' |
|
||||||
|
while read i
|
||||||
|
do
|
||||||
|
oops && exit 1
|
||||||
|
|
||||||
|
if ! blacklist $i
|
||||||
|
then
|
||||||
|
echo removing $i...
|
||||||
|
bash $FAILCMD modprobe -r $i
|
||||||
|
fi
|
||||||
|
done
|
||||||
|
|
||||||
|
------------------------------------------------------------------------------
|
||||||
|
|
||||||
|
o inject slab allocation failures only for a specific module
|
||||||
|
|
||||||
|
------------------------------------------------------------------------------
|
||||||
|
#!/bin/bash
|
||||||
|
|
||||||
|
FAILMOD=Documentation/fault-injection/failmodule.sh
|
||||||
|
|
||||||
|
echo injecting errors into the module $1...
|
||||||
|
|
||||||
|
modprobe $1
|
||||||
|
bash $FAILMOD failslab $1 10
|
||||||
|
echo 25 > /debug/failslab/probability
|
||||||
|
|
||||||
|
------------------------------------------------------------------------------
|
||||||
|
|
|
@ -30,11 +30,39 @@ Who: Adrian Bunk <bunk@stusta.de>
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
What: raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN
|
What: raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN
|
||||||
When: November 2006
|
When: June 2007
|
||||||
Why: Deprecated in favour of the new ioctl-based rawiso interface, which is
|
Why: Deprecated in favour of the more efficient and robust rawiso interface.
|
||||||
more efficient. You should really be using libraw1394 for raw1394
|
Affected are applications which use the deprecated part of libraw1394
|
||||||
access anyway.
|
(raw1394_iso_write, raw1394_start_iso_write, raw1394_start_iso_rcv,
|
||||||
Who: Jody McIntyre <scjody@modernduck.com>
|
raw1394_stop_iso_rcv) or bypass libraw1394.
|
||||||
|
Who: Dan Dennedy <dan@dennedy.org>, Stefan Richter <stefanr@s5r6.in-berlin.de>
|
||||||
|
|
||||||
|
---------------------------
|
||||||
|
|
||||||
|
What: dv1394 driver (CONFIG_IEEE1394_DV1394)
|
||||||
|
When: June 2007
|
||||||
|
Why: Replaced by raw1394 + userspace libraries, notably libiec61883. This
|
||||||
|
shift of application support has been indicated on www.linux1394.org
|
||||||
|
and developers' mailinglists for quite some time. Major applications
|
||||||
|
have been converted, with the exception of ffmpeg and hence xine.
|
||||||
|
Piped output of dvgrab2 is a partial equivalent to dv1394.
|
||||||
|
Who: Dan Dennedy <dan@dennedy.org>, Stefan Richter <stefanr@s5r6.in-berlin.de>
|
||||||
|
|
||||||
|
---------------------------
|
||||||
|
|
||||||
|
What: ieee1394 core's unused exports (CONFIG_IEEE1394_EXPORT_FULL_API)
|
||||||
|
When: January 2007
|
||||||
|
Why: There are no projects known to use these exported symbols, except
|
||||||
|
dfg1394 (uses one symbol whose functionality is core-internal now).
|
||||||
|
Who: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
||||||
|
|
||||||
|
---------------------------
|
||||||
|
|
||||||
|
What: ieee1394's *_oui sysfs attributes (CONFIG_IEEE1394_OUI_DB)
|
||||||
|
When: January 2007
|
||||||
|
Files: drivers/ieee1394/: oui.db, oui2c.sh
|
||||||
|
Why: big size, little value
|
||||||
|
Who: Stefan Richter <stefanr@s5r6.in-berlin.de>
|
||||||
|
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
|
@ -53,18 +81,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 +98,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
|
||||||
|
@ -212,17 +216,6 @@ Who: Thomas Gleixner <tglx@linutronix.de>
|
||||||
|
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
What: i2c-ite and i2c-algo-ite drivers
|
|
||||||
When: September 2006
|
|
||||||
Why: These drivers never compiled since they were added to the kernel
|
|
||||||
tree 5 years ago. This feature removal can be reevaluated if
|
|
||||||
someone shows interest in the drivers, fixes them and takes over
|
|
||||||
maintenance.
|
|
||||||
http://marc.theaimsgroup.com/?l=linux-mips&m=115040510817448
|
|
||||||
Who: Jean Delvare <khali@linux-fr.org>
|
|
||||||
|
|
||||||
---------------------------
|
|
||||||
|
|
||||||
What: Bridge netfilter deferred IPv4/IPv6 output hook calling
|
What: Bridge netfilter deferred IPv4/IPv6 output hook calling
|
||||||
When: January 2007
|
When: January 2007
|
||||||
Why: The deferred output hooks are a layering violation causing unusual
|
Why: The deferred output hooks are a layering violation causing unusual
|
||||||
|
@ -239,23 +232,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
|
||||||
|
@ -273,11 +251,12 @@ Who: Jean Delvare <khali@linux-fr.org>
|
||||||
|
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
What: ftape
|
What: IPv4 only connection tracking/NAT/helpers
|
||||||
When: 2.6.20
|
When: 2.6.22
|
||||||
Why: Orphaned for ages. SMP bugs long unfixed. Few users left
|
Why: The new layer 3 independant connection tracking replaces the old
|
||||||
in the world.
|
IPv4 only version. After some stabilization of the new code the
|
||||||
Who: Jeff Garzik <jeff@garzik.org>
|
old one will be removed.
|
||||||
|
Who: Patrick McHardy <kaber@trash.net>
|
||||||
|
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
|
|
|
@ -124,7 +124,7 @@ sync_fs: no no read
|
||||||
write_super_lockfs: ?
|
write_super_lockfs: ?
|
||||||
unlockfs: ?
|
unlockfs: ?
|
||||||
statfs: no no no
|
statfs: no no no
|
||||||
remount_fs: no yes maybe (see below)
|
remount_fs: yes yes maybe (see below)
|
||||||
clear_inode: no
|
clear_inode: no
|
||||||
umount_begin: yes no no
|
umount_begin: yes no no
|
||||||
show_options: no (vfsmount->sem)
|
show_options: no (vfsmount->sem)
|
||||||
|
|
|
@ -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 {
|
||||||
|
|
|
@ -51,6 +51,22 @@ homepage:
|
||||||
|
|
||||||
http://fuse.sourceforge.net/
|
http://fuse.sourceforge.net/
|
||||||
|
|
||||||
|
Filesystem type
|
||||||
|
~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
The filesystem type given to mount(2) can be one of the following:
|
||||||
|
|
||||||
|
'fuse'
|
||||||
|
|
||||||
|
This is the usual way to mount a FUSE filesystem. The first
|
||||||
|
argument of the mount system call may contain an arbitrary string,
|
||||||
|
which is not interpreted by the kernel.
|
||||||
|
|
||||||
|
'fuseblk'
|
||||||
|
|
||||||
|
The filesystem is block device based. The first argument of the
|
||||||
|
mount system call is interpreted as the name of the device.
|
||||||
|
|
||||||
Mount options
|
Mount options
|
||||||
~~~~~~~~~~~~~
|
~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
@ -94,6 +110,11 @@ Mount options
|
||||||
The default is infinite. Note that the size of read requests is
|
The default is infinite. Note that the size of read requests is
|
||||||
limited anyway to 32 pages (which is 128kbyte on i386).
|
limited anyway to 32 pages (which is 128kbyte on i386).
|
||||||
|
|
||||||
|
'blksize=N'
|
||||||
|
|
||||||
|
Set the block size for the filesystem. The default is 512. This
|
||||||
|
option is only valid for 'fuseblk' type mounts.
|
||||||
|
|
||||||
Control filesystem
|
Control filesystem
|
||||||
~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
@ -111,7 +132,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 +157,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
|
||||||
|
@ -54,3 +54,6 @@ errors=panic Panic and halt the machine if an error occurs.
|
||||||
intr (*) Allow signals to interrupt cluster operations.
|
intr (*) Allow signals to interrupt cluster operations.
|
||||||
nointr Do not allow signals to interrupt cluster
|
nointr Do not allow signals to interrupt cluster
|
||||||
operations.
|
operations.
|
||||||
|
atime_quantum=60(*) OCFS2 will not update atime unless this number
|
||||||
|
of seconds has passed since the last update.
|
||||||
|
Set to zero to always update atime.
|
||||||
|
|
|
@ -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-
|
||||||
|
|
|
@ -1,11 +1,8 @@
|
||||||
This is the implementation of the SystemV/Coherent filesystem for Linux.
|
|
||||||
It implements all of
|
It implements all of
|
||||||
- Xenix FS,
|
- Xenix FS,
|
||||||
- SystemV/386 FS,
|
- SystemV/386 FS,
|
||||||
- Coherent FS.
|
- Coherent FS.
|
||||||
|
|
||||||
This is version beta 4.
|
|
||||||
|
|
||||||
To install:
|
To install:
|
||||||
* Answer the 'System V and Coherent filesystem support' question with 'y'
|
* Answer the 'System V and Coherent filesystem support' question with 'y'
|
||||||
when configuring the kernel.
|
when configuring the kernel.
|
||||||
|
@ -28,11 +25,173 @@ Bugs in the present implementation:
|
||||||
for this FS on hard disk yet.
|
for this FS on hard disk yet.
|
||||||
|
|
||||||
|
|
||||||
Please report any bugs and suggestions to
|
These filesystems are rather similar. Here is a comparison with Minix FS:
|
||||||
Bruno Haible <haible@ma2s2.mathematik.uni-karlsruhe.de>
|
|
||||||
Pascal Haible <haible@izfm.uni-stuttgart.de>
|
|
||||||
Krzysztof G. Baranowski <kgb@manjak.knm.org.pl>
|
|
||||||
|
|
||||||
Bruno Haible
|
* Linux fdisk reports on partitions
|
||||||
<haible@ma2s2.mathematik.uni-karlsruhe.de>
|
- Minix FS 0x81 Linux/Minix
|
||||||
|
- Xenix FS ??
|
||||||
|
- SystemV FS ??
|
||||||
|
- Coherent FS 0x08 AIX bootable
|
||||||
|
|
||||||
|
* Size of a block or zone (data allocation unit on disk)
|
||||||
|
- Minix FS 1024
|
||||||
|
- Xenix FS 1024 (also 512 ??)
|
||||||
|
- SystemV FS 1024 (also 512 and 2048)
|
||||||
|
- Coherent FS 512
|
||||||
|
|
||||||
|
* General layout: all have one boot block, one super block and
|
||||||
|
separate areas for inodes and for directories/data.
|
||||||
|
On SystemV Release 2 FS (e.g. Microport) the first track is reserved and
|
||||||
|
all the block numbers (including the super block) are offset by one track.
|
||||||
|
|
||||||
|
* Byte ordering of "short" (16 bit entities) on disk:
|
||||||
|
- Minix FS little endian 0 1
|
||||||
|
- Xenix FS little endian 0 1
|
||||||
|
- SystemV FS little endian 0 1
|
||||||
|
- Coherent FS little endian 0 1
|
||||||
|
Of course, this affects only the file system, not the data of files on it!
|
||||||
|
|
||||||
|
* Byte ordering of "long" (32 bit entities) on disk:
|
||||||
|
- Minix FS little endian 0 1 2 3
|
||||||
|
- Xenix FS little endian 0 1 2 3
|
||||||
|
- SystemV FS little endian 0 1 2 3
|
||||||
|
- Coherent FS PDP-11 2 3 0 1
|
||||||
|
Of course, this affects only the file system, not the data of files on it!
|
||||||
|
|
||||||
|
* Inode on disk: "short", 0 means non-existent, the root dir ino is:
|
||||||
|
- Minix FS 1
|
||||||
|
- Xenix FS, SystemV FS, Coherent FS 2
|
||||||
|
|
||||||
|
* Maximum number of hard links to a file:
|
||||||
|
- Minix FS 250
|
||||||
|
- Xenix FS ??
|
||||||
|
- SystemV FS ??
|
||||||
|
- Coherent FS >=10000
|
||||||
|
|
||||||
|
* Free inode management:
|
||||||
|
- Minix FS a bitmap
|
||||||
|
- Xenix FS, SystemV FS, Coherent FS
|
||||||
|
There is a cache of a certain number of free inodes in the super-block.
|
||||||
|
When it is exhausted, new free inodes are found using a linear search.
|
||||||
|
|
||||||
|
* Free block management:
|
||||||
|
- Minix FS a bitmap
|
||||||
|
- Xenix FS, SystemV FS, Coherent FS
|
||||||
|
Free blocks are organized in a "free list". Maybe a misleading term,
|
||||||
|
since it is not true that every free block contains a pointer to
|
||||||
|
the next free block. Rather, the free blocks are organized in chunks
|
||||||
|
of limited size, and every now and then a free block contains pointers
|
||||||
|
to the free blocks pertaining to the next chunk; the first of these
|
||||||
|
contains pointers and so on. The list terminates with a "block number"
|
||||||
|
0 on Xenix FS and SystemV FS, with a block zeroed out on Coherent FS.
|
||||||
|
|
||||||
|
* Super-block location:
|
||||||
|
- Minix FS block 1 = bytes 1024..2047
|
||||||
|
- Xenix FS block 1 = bytes 1024..2047
|
||||||
|
- SystemV FS bytes 512..1023
|
||||||
|
- Coherent FS block 1 = bytes 512..1023
|
||||||
|
|
||||||
|
* Super-block layout:
|
||||||
|
- Minix FS
|
||||||
|
unsigned short s_ninodes;
|
||||||
|
unsigned short s_nzones;
|
||||||
|
unsigned short s_imap_blocks;
|
||||||
|
unsigned short s_zmap_blocks;
|
||||||
|
unsigned short s_firstdatazone;
|
||||||
|
unsigned short s_log_zone_size;
|
||||||
|
unsigned long s_max_size;
|
||||||
|
unsigned short s_magic;
|
||||||
|
- Xenix FS, SystemV FS, Coherent FS
|
||||||
|
unsigned short s_firstdatazone;
|
||||||
|
unsigned long s_nzones;
|
||||||
|
unsigned short s_fzone_count;
|
||||||
|
unsigned long s_fzones[NICFREE];
|
||||||
|
unsigned short s_finode_count;
|
||||||
|
unsigned short s_finodes[NICINOD];
|
||||||
|
char s_flock;
|
||||||
|
char s_ilock;
|
||||||
|
char s_modified;
|
||||||
|
char s_rdonly;
|
||||||
|
unsigned long s_time;
|
||||||
|
short s_dinfo[4]; -- SystemV FS only
|
||||||
|
unsigned long s_free_zones;
|
||||||
|
unsigned short s_free_inodes;
|
||||||
|
short s_dinfo[4]; -- Xenix FS only
|
||||||
|
unsigned short s_interleave_m,s_interleave_n; -- Coherent FS only
|
||||||
|
char s_fname[6];
|
||||||
|
char s_fpack[6];
|
||||||
|
then they differ considerably:
|
||||||
|
Xenix FS
|
||||||
|
char s_clean;
|
||||||
|
char s_fill[371];
|
||||||
|
long s_magic;
|
||||||
|
long s_type;
|
||||||
|
SystemV FS
|
||||||
|
long s_fill[12 or 14];
|
||||||
|
long s_state;
|
||||||
|
long s_magic;
|
||||||
|
long s_type;
|
||||||
|
Coherent FS
|
||||||
|
unsigned long s_unique;
|
||||||
|
Note that Coherent FS has no magic.
|
||||||
|
|
||||||
|
* Inode layout:
|
||||||
|
- Minix FS
|
||||||
|
unsigned short i_mode;
|
||||||
|
unsigned short i_uid;
|
||||||
|
unsigned long i_size;
|
||||||
|
unsigned long i_time;
|
||||||
|
unsigned char i_gid;
|
||||||
|
unsigned char i_nlinks;
|
||||||
|
unsigned short i_zone[7+1+1];
|
||||||
|
- Xenix FS, SystemV FS, Coherent FS
|
||||||
|
unsigned short i_mode;
|
||||||
|
unsigned short i_nlink;
|
||||||
|
unsigned short i_uid;
|
||||||
|
unsigned short i_gid;
|
||||||
|
unsigned long i_size;
|
||||||
|
unsigned char i_zone[3*(10+1+1+1)];
|
||||||
|
unsigned long i_atime;
|
||||||
|
unsigned long i_mtime;
|
||||||
|
unsigned long i_ctime;
|
||||||
|
|
||||||
|
* Regular file data blocks are organized as
|
||||||
|
- Minix FS
|
||||||
|
7 direct blocks
|
||||||
|
1 indirect block (pointers to blocks)
|
||||||
|
1 double-indirect block (pointer to pointers to blocks)
|
||||||
|
- Xenix FS, SystemV FS, Coherent FS
|
||||||
|
10 direct blocks
|
||||||
|
1 indirect block (pointers to blocks)
|
||||||
|
1 double-indirect block (pointer to pointers to blocks)
|
||||||
|
1 triple-indirect block (pointer to pointers to pointers to blocks)
|
||||||
|
|
||||||
|
* Inode size, inodes per block
|
||||||
|
- Minix FS 32 32
|
||||||
|
- Xenix FS 64 16
|
||||||
|
- SystemV FS 64 16
|
||||||
|
- Coherent FS 64 8
|
||||||
|
|
||||||
|
* Directory entry on disk
|
||||||
|
- Minix FS
|
||||||
|
unsigned short inode;
|
||||||
|
char name[14/30];
|
||||||
|
- Xenix FS, SystemV FS, Coherent FS
|
||||||
|
unsigned short inode;
|
||||||
|
char name[14];
|
||||||
|
|
||||||
|
* Dir entry size, dir entries per block
|
||||||
|
- Minix FS 16/32 64/32
|
||||||
|
- Xenix FS 16 64
|
||||||
|
- SystemV FS 16 64
|
||||||
|
- Coherent FS 16 32
|
||||||
|
|
||||||
|
* How to implement symbolic links such that the host fsck doesn't scream:
|
||||||
|
- Minix FS normal
|
||||||
|
- Xenix FS kludge: as regular files with chmod 1000
|
||||||
|
- SystemV FS ??
|
||||||
|
- Coherent FS kludge: as regular files with chmod 1000
|
||||||
|
|
||||||
|
|
||||||
|
Notation: We often speak of a "block" but mean a zone (the allocation unit)
|
||||||
|
and not the disk driver's notion of "block".
|
||||||
|
|
|
@ -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:
|
||||||
|
|
|
@ -1,307 +0,0 @@
|
||||||
Intro
|
|
||||||
=====
|
|
||||||
|
|
||||||
This file describes some issues involved when using the "ftape"
|
|
||||||
floppy tape device driver that comes with the Linux kernel.
|
|
||||||
|
|
||||||
ftape has a home page at
|
|
||||||
|
|
||||||
http://ftape.dot-heine.de/
|
|
||||||
|
|
||||||
which contains further information about ftape. Please cross check
|
|
||||||
this WWW address against the address given (if any) in the MAINTAINERS
|
|
||||||
file located in the top level directory of the Linux kernel source
|
|
||||||
tree.
|
|
||||||
|
|
||||||
NOTE: This is an unmaintained set of drivers, and it is not guaranteed to work.
|
|
||||||
If you are interested in taking over maintenance, contact Claus-Justus Heine
|
|
||||||
<ch@dot-heine.de>, the former maintainer.
|
|
||||||
|
|
||||||
Contents
|
|
||||||
========
|
|
||||||
|
|
||||||
A minus 1: Ftape documentation
|
|
||||||
|
|
||||||
A. Changes
|
|
||||||
1. Goal
|
|
||||||
2. I/O Block Size
|
|
||||||
3. Write Access when not at EOD (End Of Data) or BOT (Begin Of Tape)
|
|
||||||
4. Formatting
|
|
||||||
5. Interchanging cartridges with other operating systems
|
|
||||||
|
|
||||||
B. Debugging Output
|
|
||||||
1. Introduction
|
|
||||||
2. Tuning the debugging output
|
|
||||||
|
|
||||||
C. Boot and load time configuration
|
|
||||||
1. Setting boot time parameters
|
|
||||||
2. Module load time parameters
|
|
||||||
3. Ftape boot- and load time options
|
|
||||||
4. Example kernel parameter setting
|
|
||||||
5. Example module parameter setting
|
|
||||||
|
|
||||||
D. Support and contacts
|
|
||||||
|
|
||||||
*******************************************************************************
|
|
||||||
|
|
||||||
A minus 1. Ftape documentation
|
|
||||||
==============================
|
|
||||||
|
|
||||||
Unluckily, the ftape-HOWTO is out of date. This really needs to be
|
|
||||||
changed. Up to date documentation as well as recent development
|
|
||||||
versions of ftape and useful links to related topics can be found at
|
|
||||||
the ftape home page at
|
|
||||||
|
|
||||||
http://ftape.dot-heine.de/
|
|
||||||
|
|
||||||
*******************************************************************************
|
|
||||||
|
|
||||||
A. Changes
|
|
||||||
==========
|
|
||||||
|
|
||||||
1. Goal
|
|
||||||
~~~~
|
|
||||||
The goal of all that incompatibilities was to give ftape an interface
|
|
||||||
that resembles the interface provided by SCSI tape drives as close
|
|
||||||
as possible. Thus any Unix backup program that is known to work
|
|
||||||
with SCSI tape drives should also work.
|
|
||||||
|
|
||||||
The concept of a fixed block size for read/write transfers is
|
|
||||||
rather unrelated to this SCSI tape compatibility at the file system
|
|
||||||
interface level. It developed out of a feature of zftape, a
|
|
||||||
block wise user transparent on-the-fly compression. That compression
|
|
||||||
support will not be dropped in future releases for compatibility
|
|
||||||
reasons with previous releases of zftape.
|
|
||||||
|
|
||||||
2. I/O Block Size
|
|
||||||
~~~~~~~~~~~~~~
|
|
||||||
The block size defaults to 10k which is the default block size of
|
|
||||||
GNU tar.
|
|
||||||
|
|
||||||
The block size can be tuned either during kernel configuration or
|
|
||||||
at runtime with the MTIOCTOP ioctl using the MTSETBLK operation
|
|
||||||
(i.e. do "mt -f /dev/qft0" setblk #BLKSZ). A block size of 0
|
|
||||||
switches to variable block size mode i.e. "mt setblk 0" switches
|
|
||||||
off the block size restriction. However, this disables zftape's
|
|
||||||
built in on-the-fly compression which doesn't work with variable
|
|
||||||
block size mode.
|
|
||||||
|
|
||||||
The BLKSZ parameter must be given as a byte count and must be a
|
|
||||||
multiple of 32k or 0, i.e. use "mt setblk 32768" to switch to a
|
|
||||||
block size of 32k.
|
|
||||||
|
|
||||||
The typical symptom of a block size mismatch is an "invalid
|
|
||||||
argument" error message.
|
|
||||||
|
|
||||||
3. Write Access when not at EOD (End Of Data) or BOT (Begin Of Tape)
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
zftape (the file system interface of ftape-3.x) denies write access
|
|
||||||
to the tape cartridge when it isn't positioned either at BOT or
|
|
||||||
EOD.
|
|
||||||
|
|
||||||
4. Formatting
|
|
||||||
~~~~~~~~~~
|
|
||||||
ftape DOES support formatting of floppy tape cartridges. You need the
|
|
||||||
`ftformat' program that is shipped with the modules version of ftape.
|
|
||||||
Please get the latest version of ftape from
|
|
||||||
|
|
||||||
ftp://sunsite.unc.edu/pub/Linux/kernel/tapes
|
|
||||||
|
|
||||||
or from the ftape home page at
|
|
||||||
|
|
||||||
http://ftape.dot-heine.de/
|
|
||||||
|
|
||||||
`ftformat' is contained in the `./contrib/' subdirectory of that
|
|
||||||
separate ftape package.
|
|
||||||
|
|
||||||
5. Interchanging cartridges with other operating systems
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
The internal emulation of Unix tape device file marks has changed
|
|
||||||
completely. ftape now uses the volume table segment as specified
|
|
||||||
by the QIC-40/80/3010/3020/113 standards to emulate file marks. As
|
|
||||||
a consequence there is limited support to interchange cartridges
|
|
||||||
with other operating systems.
|
|
||||||
|
|
||||||
To be more precise: ftape will detect volumes written by other OS's
|
|
||||||
programs and other OS's programs will detect volumes written by
|
|
||||||
ftape.
|
|
||||||
|
|
||||||
However, it isn't possible to extract the data dumped to the tape
|
|
||||||
by some MSDOS program with ftape. This exceeds the scope of a
|
|
||||||
kernel device driver. If you need such functionality, then go ahead
|
|
||||||
and write a user space utility that is able to do that. ftape already
|
|
||||||
provides all kernel level support necessary to do that.
|
|
||||||
|
|
||||||
*******************************************************************************
|
|
||||||
|
|
||||||
B. Debugging Output
|
|
||||||
================
|
|
||||||
|
|
||||||
1. Introduction
|
|
||||||
~~~~~~~~~~~~
|
|
||||||
The ftape driver can be very noisy in that is can print lots of
|
|
||||||
debugging messages to the kernel log files and the system console.
|
|
||||||
While this is useful for debugging it might be annoying during
|
|
||||||
normal use and enlarges the size of the driver by several kilobytes.
|
|
||||||
|
|
||||||
To reduce the size of the driver you can trim the maximal amount of
|
|
||||||
debugging information available during kernel configuration. Please
|
|
||||||
refer to the kernel configuration script and its on-line help
|
|
||||||
functionality.
|
|
||||||
|
|
||||||
The amount of debugging output maps to the "tracing" boot time
|
|
||||||
option and the "ft_tracing" modules option as follows:
|
|
||||||
|
|
||||||
0 bugs
|
|
||||||
1 + errors (with call-stack dump)
|
|
||||||
2 + warnings
|
|
||||||
3 + information
|
|
||||||
4 + more information
|
|
||||||
5 + program flow
|
|
||||||
6 + fdc/dma info
|
|
||||||
7 + data flow
|
|
||||||
8 + everything else
|
|
||||||
|
|
||||||
2. Tuning the debugging output
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
To reduce the amount of debugging output printed to the system
|
|
||||||
console you can
|
|
||||||
|
|
||||||
i) trim the debugging output at run-time with
|
|
||||||
|
|
||||||
mt -f /dev/nqft0 setdensity #DBGLVL
|
|
||||||
|
|
||||||
where "#DBGLVL" is a number between 0 and 9
|
|
||||||
|
|
||||||
ii) trim the debugging output at module load time with
|
|
||||||
|
|
||||||
modprobe ftape ft_tracing=#DBGLVL
|
|
||||||
|
|
||||||
Of course, this applies only if you have configured ftape to be
|
|
||||||
compiled as a module.
|
|
||||||
|
|
||||||
iii) trim the debugging output during system boot time. Add the
|
|
||||||
following to the kernel command line:
|
|
||||||
|
|
||||||
ftape=#DBGLVL,tracing
|
|
||||||
|
|
||||||
Please refer also to the next section if you don't know how to
|
|
||||||
set boot time parameters.
|
|
||||||
|
|
||||||
*******************************************************************************
|
|
||||||
|
|
||||||
C. Boot and load time configuration
|
|
||||||
================================
|
|
||||||
|
|
||||||
1. Setting boot time parameters
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
Assuming that you use lilo, the LI)nux LO)ader, boot time kernel
|
|
||||||
parameters can be set by adding a line
|
|
||||||
|
|
||||||
append some_kernel_boot_time_parameter
|
|
||||||
|
|
||||||
to `/etc/lilo.conf' or at real boot time by typing in the options
|
|
||||||
at the prompt provided by LILO. I can't give you advice on how to
|
|
||||||
specify those parameters with other loaders as I don't use them.
|
|
||||||
|
|
||||||
For ftape, each "some_kernel_boot_time_parameter" looks like
|
|
||||||
"ftape=value,option". As an example, the debugging output can be
|
|
||||||
increased with
|
|
||||||
|
|
||||||
ftape=4,tracing
|
|
||||||
|
|
||||||
NOTE: the value precedes the option name.
|
|
||||||
|
|
||||||
2. Module load time parameters
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
Module parameters can be specified either directly when invoking
|
|
||||||
the program 'modprobe' at the shell prompt:
|
|
||||||
|
|
||||||
modprobe ftape ft_tracing=4
|
|
||||||
|
|
||||||
or by editing the file `/etc/modprobe.conf' in which case they take
|
|
||||||
effect each time when the module is loaded with `modprobe' (please
|
|
||||||
refer to the respective manual pages). Thus, you should add a line
|
|
||||||
|
|
||||||
options ftape ft_tracing=4
|
|
||||||
|
|
||||||
to `/etc/modprobe.conf` if you intend to increase the debugging
|
|
||||||
output of the driver.
|
|
||||||
|
|
||||||
|
|
||||||
3. Ftape boot- and load time options
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
|
|
||||||
i. Controlling the amount of debugging output
|
|
||||||
DBGLVL has to be replaced by a number between 0 and 8.
|
|
||||||
|
|
||||||
module | kernel command line
|
|
||||||
-----------------------|----------------------
|
|
||||||
ft_tracing=DBGLVL | ftape=DBGLVL,tracing
|
|
||||||
|
|
||||||
ii. Hardware setup
|
|
||||||
BASE is the base address of your floppy disk controller,
|
|
||||||
IRQ and DMA give its interrupt and DMA channel, respectively.
|
|
||||||
BOOL is an integer, "0" means "no"; any other value means
|
|
||||||
"yes". You don't need to specify anything if connecting your tape
|
|
||||||
drive to the standard floppy disk controller. All of these
|
|
||||||
values have reasonable defaults. The defaults can be modified
|
|
||||||
during kernel configuration, i.e. while running "make config",
|
|
||||||
"make menuconfig" or "make xconfig" in the top level directory
|
|
||||||
of the Linux kernel source tree. Please refer also to the on
|
|
||||||
line documentation provided during that kernel configuration
|
|
||||||
process.
|
|
||||||
|
|
||||||
ft_probe_fc10 is set to a non-zero value if you wish for ftape to
|
|
||||||
probe for a Colorado FC-10 or FC-20 controller.
|
|
||||||
|
|
||||||
ft_mach2 is set to a non-zero value if you wish for ftape to probe
|
|
||||||
for a Mountain MACH-2 controller.
|
|
||||||
|
|
||||||
module | kernel command line
|
|
||||||
-----------------------|----------------------
|
|
||||||
ft_fdc_base=BASE | ftape=BASE,ioport
|
|
||||||
ft_fdc_irq=IRQ | ftape=IRQ,irq
|
|
||||||
ft_fdc_dma=DMA | ftape=DMA,dma
|
|
||||||
ft_probe_fc10=BOOL | ftape=BOOL,fc10
|
|
||||||
ft_mach2=BOOL | ftape=BOOL,mach2
|
|
||||||
ft_fdc_threshold=THR | ftape=THR,threshold
|
|
||||||
ft_fdc_rate_limit=RATE | ftape=RATE,datarate
|
|
||||||
|
|
||||||
4. Example kernel parameter setting
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
To configure ftape to probe for a Colorado FC-10/FC-20 controller
|
|
||||||
and to increase the amount of debugging output a little bit, add
|
|
||||||
the following line to `/etc/lilo.conf':
|
|
||||||
|
|
||||||
append ftape=1,fc10 ftape=4,tracing
|
|
||||||
|
|
||||||
5. Example module parameter setting
|
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
||||||
To do the same, but with ftape compiled as a loadable kernel
|
|
||||||
module, add the following line to `/etc/modprobe.conf':
|
|
||||||
|
|
||||||
options ftape ft_probe_fc10=1 ft_tracing=4
|
|
||||||
|
|
||||||
*******************************************************************************
|
|
||||||
|
|
||||||
D. Support and contacts
|
|
||||||
====================
|
|
||||||
|
|
||||||
Ftape is distributed under the GNU General Public License. There is
|
|
||||||
absolutely no warranty for this software. However, you can reach
|
|
||||||
the current maintainer of the ftape package under the email address
|
|
||||||
given in the MAINTAINERS file which is located in the top level
|
|
||||||
directory of the Linux kernel source tree. There you'll find also
|
|
||||||
the relevant mailing list to use as a discussion forum and the web
|
|
||||||
page to query for the most recent documentation, related work and
|
|
||||||
development versions of ftape.
|
|
||||||
|
|
||||||
Changelog:
|
|
||||||
==========
|
|
||||||
|
|
||||||
~1996: Original Document
|
|
||||||
|
|
||||||
10-24-2004: General cleanup and updating, noting additional module options.
|
|
||||||
James Nelson <james4765@gmail.com>
|
|
|
@ -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.
|
||||||
|
|
|
@ -5,7 +5,7 @@ Supported adapters:
|
||||||
|
|
||||||
Datasheets:
|
Datasheets:
|
||||||
AMD datasheet not yet available, but almost everything can be found
|
AMD datasheet not yet available, but almost everything can be found
|
||||||
in publically available ACPI 2.0 specification, which the adapter
|
in the publicly available ACPI 2.0 specification, which the adapter
|
||||||
follows.
|
follows.
|
||||||
|
|
||||||
Author: Vojtech Pavlik <vojtech@suse.cz>
|
Author: Vojtech Pavlik <vojtech@suse.cz>
|
||||||
|
|
|
@ -9,7 +9,10 @@ Supported adapters:
|
||||||
* Intel 82801EB/ER (ICH5) (HW PEC supported, 32 byte buffer not supported)
|
* Intel 82801EB/ER (ICH5) (HW PEC supported, 32 byte buffer not supported)
|
||||||
* Intel 6300ESB
|
* Intel 6300ESB
|
||||||
* Intel 82801FB/FR/FW/FRW (ICH6)
|
* Intel 82801FB/FR/FW/FRW (ICH6)
|
||||||
* Intel ICH7
|
* Intel 82801G (ICH7)
|
||||||
|
* Intel 631xESB/632xESB (ESB2)
|
||||||
|
* Intel 82801H (ICH8)
|
||||||
|
* Intel ICH9
|
||||||
Datasheets: Publicly available at the Intel website
|
Datasheets: Publicly available at the Intel website
|
||||||
|
|
||||||
Authors:
|
Authors:
|
||||||
|
|
|
@ -10,11 +10,11 @@ Supported adapters:
|
||||||
* nForce4 MCP51 10de:0264
|
* nForce4 MCP51 10de:0264
|
||||||
* nForce4 MCP55 10de:0368
|
* nForce4 MCP55 10de:0368
|
||||||
|
|
||||||
Datasheet: not publically available, but seems to be similar to the
|
Datasheet: not publicly available, but seems to be similar to the
|
||||||
AMD-8111 SMBus 2.0 adapter.
|
AMD-8111 SMBus 2.0 adapter.
|
||||||
|
|
||||||
Authors:
|
Authors:
|
||||||
Hans-Frieder Vogt <hfvogt@arcor.de>,
|
Hans-Frieder Vogt <hfvogt@gmx.net>,
|
||||||
Thomas Leibold <thomas@plx.com>,
|
Thomas Leibold <thomas@plx.com>,
|
||||||
Patrick Dreker <patrick@dreker.de>
|
Patrick Dreker <patrick@dreker.de>
|
||||||
|
|
||||||
|
@ -38,7 +38,7 @@ Notes
|
||||||
-----
|
-----
|
||||||
|
|
||||||
The SMBus adapter in the nForce2 chipset seems to be very similar to the
|
The SMBus adapter in the nForce2 chipset seems to be very similar to the
|
||||||
SMBus 2.0 adapter in the AMD-8111 southbridge. However, I could only get
|
SMBus 2.0 adapter in the AMD-8111 south bridge. However, I could only get
|
||||||
the driver to work with direct I/O access, which is different to the EC
|
the driver to work with direct I/O access, which is different to the EC
|
||||||
interface of the AMD-8111. Tested on Asus A7N8X. The ACPI DSDT table of the
|
interface of the AMD-8111. Tested on Asus A7N8X. The ACPI DSDT table of the
|
||||||
Asus A7N8X lists two SMBuses, both of which are supported by this driver.
|
Asus A7N8X lists two SMBuses, both of which are supported by this driver.
|
||||||
|
|
|
@ -2,7 +2,7 @@
|
||||||
----------------------------
|
----------------------------
|
||||||
|
|
||||||
H. Peter Anvin <hpa@zytor.com>
|
H. Peter Anvin <hpa@zytor.com>
|
||||||
Last update 2005-09-02
|
Last update 2006-11-17
|
||||||
|
|
||||||
On the i386 platform, the Linux kernel uses a rather complicated boot
|
On the i386 platform, the Linux kernel uses a rather complicated boot
|
||||||
convention. This has evolved partially due to historical aspects, as
|
convention. This has evolved partially due to historical aspects, as
|
||||||
|
@ -35,6 +35,8 @@ Protocol 2.03: (Kernel 2.4.18-pre1) Explicitly makes the highest possible
|
||||||
initrd address available to the bootloader.
|
initrd address available to the bootloader.
|
||||||
|
|
||||||
Protocol 2.04: (Kernel 2.6.14) Extend the syssize field to four bytes.
|
Protocol 2.04: (Kernel 2.6.14) Extend the syssize field to four bytes.
|
||||||
|
Protocol 2.05: (Kernel 2.6.20) Make protected mode kernel relocatable.
|
||||||
|
Introduce relocatable_kernel and kernel_alignment fields.
|
||||||
|
|
||||||
|
|
||||||
**** MEMORY LAYOUT
|
**** MEMORY LAYOUT
|
||||||
|
@ -129,6 +131,8 @@ Offset Proto Name Meaning
|
||||||
0226/2 N/A pad1 Unused
|
0226/2 N/A pad1 Unused
|
||||||
0228/4 2.02+ cmd_line_ptr 32-bit pointer to the kernel command line
|
0228/4 2.02+ cmd_line_ptr 32-bit pointer to the kernel command line
|
||||||
022C/4 2.03+ initrd_addr_max Highest legal initrd address
|
022C/4 2.03+ initrd_addr_max Highest legal initrd address
|
||||||
|
0230/4 2.05+ kernel_alignment Physical addr alignment required for kernel
|
||||||
|
0234/1 2.05+ relocatable_kernel Whether kernel is relocatable or not
|
||||||
|
|
||||||
(1) For backwards compatibility, if the setup_sects field contains 0, the
|
(1) For backwards compatibility, if the setup_sects field contains 0, the
|
||||||
real value is 4.
|
real value is 4.
|
||||||
|
|
|
@ -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.
|
||||||
|
|
|
@ -191,3 +191,5 @@ Code Seq# Include File Comments
|
||||||
<mailto:aherrman@de.ibm.com>
|
<mailto:aherrman@de.ibm.com>
|
||||||
0xF3 00-3F video/sisfb.h sisfb (in development)
|
0xF3 00-3F video/sisfb.h sisfb (in development)
|
||||||
<mailto:thomas@winischhofer.net>
|
<mailto:thomas@winischhofer.net>
|
||||||
|
0xF4 00-1F video/mbxfb.h mbxfb
|
||||||
|
<mailto:raph@8d.com>
|
||||||
|
|
|
@ -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
|
||||||
|
|
|
@ -0,0 +1,24 @@
|
||||||
|
To decode a hex IOCTL code:
|
||||||
|
|
||||||
|
Most architecures use this generic format, but check
|
||||||
|
include/ARCH/ioctl.h for specifics, e.g. powerpc
|
||||||
|
uses 3 bits to encode read/write and 13 bits for size.
|
||||||
|
|
||||||
|
bits meaning
|
||||||
|
31-30 00 - no parameters: uses _IO macro
|
||||||
|
10 - read: _IOR
|
||||||
|
01 - write: _IOW
|
||||||
|
11 - read/write: _IOWR
|
||||||
|
|
||||||
|
29-16 size of arguments
|
||||||
|
|
||||||
|
15-8 ascii character supposedly
|
||||||
|
unique to each driver
|
||||||
|
|
||||||
|
7-0 function #
|
||||||
|
|
||||||
|
|
||||||
|
So for example 0x82187201 is a read with arg length of 0x218,
|
||||||
|
character 'r' function 1. Grepping the source reveals this is:
|
||||||
|
|
||||||
|
#define VFAT_IOCTL_READDIR_BOTH _IOR('r', 1, struct dirent [2])
|
|
@ -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>
|
||||||
|
@ -544,6 +548,13 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
eurwdt= [HW,WDT] Eurotech CPU-1220/1410 onboard watchdog.
|
eurwdt= [HW,WDT] Eurotech CPU-1220/1410 onboard watchdog.
|
||||||
Format: <io>[,<irq>]
|
Format: <io>[,<irq>]
|
||||||
|
|
||||||
|
failslab=
|
||||||
|
fail_page_alloc=
|
||||||
|
fail_make_request=[KNL]
|
||||||
|
General fault injection mechanism.
|
||||||
|
Format: <interval>,<probability>,<space>,<times>
|
||||||
|
See also /Documentation/fault-injection/.
|
||||||
|
|
||||||
fd_mcs= [HW,SCSI]
|
fd_mcs= [HW,SCSI]
|
||||||
See header of drivers/scsi/fd_mcs.c.
|
See header of drivers/scsi/fd_mcs.c.
|
||||||
|
|
||||||
|
@ -553,9 +564,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
floppy= [HW]
|
floppy= [HW]
|
||||||
See Documentation/floppy.txt.
|
See Documentation/floppy.txt.
|
||||||
|
|
||||||
ftape= [HW] Floppy Tape subsystem debugging options.
|
|
||||||
See Documentation/ftape.txt.
|
|
||||||
|
|
||||||
gamecon.map[2|3]=
|
gamecon.map[2|3]=
|
||||||
[HW,JOY] Multisystem joystick and NES/SNES/PSX pad
|
[HW,JOY] Multisystem joystick and NES/SNES/PSX pad
|
||||||
support via parallel port (up to 5 devices per port)
|
support via parallel port (up to 5 devices per port)
|
||||||
|
@ -598,8 +606,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
|
|
||||||
hugepages= [HW,IA-32,IA-64] Maximal number of HugeTLB pages.
|
hugepages= [HW,IA-32,IA-64] Maximal number of HugeTLB pages.
|
||||||
|
|
||||||
noirqbalance [IA-32,SMP,KNL] Disable kernel irq balancing
|
|
||||||
|
|
||||||
i8042.direct [HW] Put keyboard port into non-translated mode
|
i8042.direct [HW] Put keyboard port into non-translated mode
|
||||||
i8042.dumbkbd [HW] Pretend that controller can only read data from
|
i8042.dumbkbd [HW] Pretend that controller can only read data from
|
||||||
keyboard and cannot control its state
|
keyboard and cannot control its state
|
||||||
|
@ -649,6 +655,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
idle= [HW]
|
idle= [HW]
|
||||||
Format: idle=poll or idle=halt
|
Format: idle=poll or idle=halt
|
||||||
|
|
||||||
|
ignore_loglevel [KNL]
|
||||||
|
Ignore loglevel setting - this will print /all/
|
||||||
|
kernel messages to the console. Useful for debugging.
|
||||||
|
|
||||||
ihash_entries= [KNL]
|
ihash_entries= [KNL]
|
||||||
Set number of hash buckets for inode cache.
|
Set number of hash buckets for inode cache.
|
||||||
|
|
||||||
|
@ -713,7 +723,12 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
Format: <RDP>,<reset>,<pci_scan>,<verbosity>
|
Format: <RDP>,<reset>,<pci_scan>,<verbosity>
|
||||||
|
|
||||||
isolcpus= [KNL,SMP] Isolate CPUs from the general scheduler.
|
isolcpus= [KNL,SMP] Isolate CPUs from the general scheduler.
|
||||||
Format: <cpu number>,...,<cpu number>
|
Format:
|
||||||
|
<cpu number>,...,<cpu number>
|
||||||
|
or
|
||||||
|
<cpu number>-<cpu number> (must be a positive range in ascending order)
|
||||||
|
or a mixture
|
||||||
|
<cpu number>,...,<cpu number>-<cpu number>
|
||||||
This option can be used to specify one or more CPUs
|
This option can be used to specify one or more CPUs
|
||||||
to isolate from the general SMP balancing and scheduling
|
to isolate from the general SMP balancing and scheduling
|
||||||
algorithms. The only way to move a process onto or off
|
algorithms. The only way to move a process onto or off
|
||||||
|
@ -1011,6 +1026,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
emulation library even if a 387 maths coprocessor
|
emulation library even if a 387 maths coprocessor
|
||||||
is present.
|
is present.
|
||||||
|
|
||||||
|
noaliencache [MM, NUMA] Disables the allcoation of alien caches in
|
||||||
|
the slab allocator. Saves per-node memory, but will
|
||||||
|
impact performance on real NUMA hardware.
|
||||||
|
|
||||||
noalign [KNL,ARM]
|
noalign [KNL,ARM]
|
||||||
|
|
||||||
noapic [SMP,APIC] Tells the kernel to not make use of any
|
noapic [SMP,APIC] Tells the kernel to not make use of any
|
||||||
|
@ -1051,9 +1070,14 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
in certain environments such as networked servers or
|
in certain environments such as networked servers or
|
||||||
real-time systems.
|
real-time systems.
|
||||||
|
|
||||||
|
noirqbalance [IA-32,SMP,KNL] Disable kernel irq balancing
|
||||||
|
|
||||||
noirqdebug [IA-32] Disables the code which attempts to detect and
|
noirqdebug [IA-32] Disables the code which attempts to detect and
|
||||||
disable unhandled interrupt sources.
|
disable unhandled interrupt sources.
|
||||||
|
|
||||||
|
no_timer_check [IA-32,X86_64,APIC] Disables the code which tests for
|
||||||
|
broken timer IRQ sources.
|
||||||
|
|
||||||
noisapnp [ISAPNP] Disables ISA PnP code.
|
noisapnp [ISAPNP] Disables ISA PnP code.
|
||||||
|
|
||||||
noinitrd [RAM] Tells the kernel not to load any configured
|
noinitrd [RAM] Tells the kernel not to load any configured
|
||||||
|
@ -1231,6 +1255,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]
|
||||||
|
@ -1279,6 +1308,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
Param: "schedule" - profile schedule points.
|
Param: "schedule" - profile schedule points.
|
||||||
Param: <number> - step/bucket size as a power of 2 for
|
Param: <number> - step/bucket size as a power of 2 for
|
||||||
statistical time based profiling.
|
statistical time based profiling.
|
||||||
|
Param: "sleep" - profile D-state sleeping (millisecs)
|
||||||
|
|
||||||
processor.max_cstate= [HW,ACPI]
|
processor.max_cstate= [HW,ACPI]
|
||||||
Limit processor to maximum C-state
|
Limit processor to maximum C-state
|
||||||
|
@ -1360,6 +1390,12 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
resume= [SWSUSP]
|
resume= [SWSUSP]
|
||||||
Specify the partition device for software suspend
|
Specify the partition device for software suspend
|
||||||
|
|
||||||
|
resume_offset= [SWSUSP]
|
||||||
|
Specify the offset from the beginning of the partition
|
||||||
|
given by "resume=" at which the swap header is located,
|
||||||
|
in <PAGE_SIZE> units (needed only for swap files).
|
||||||
|
See Documentation/power/swsusp-and-swap-files.txt
|
||||||
|
|
||||||
rhash_entries= [KNL,NET]
|
rhash_entries= [KNL,NET]
|
||||||
Set number of hash buckets for route cache
|
Set number of hash buckets for route cache
|
||||||
|
|
||||||
|
@ -1410,6 +1446,11 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
|
|
||||||
scsi_logging= [SCSI]
|
scsi_logging= [SCSI]
|
||||||
|
|
||||||
|
scsi_mod.scan= [SCSI] sync (default) scans SCSI busses as they are
|
||||||
|
discovered. async scans them in kernel threads,
|
||||||
|
allowing boot to proceed. none ignores them, expecting
|
||||||
|
user space to do the scan.
|
||||||
|
|
||||||
selinux [SELINUX] Disable or enable SELinux at boot time.
|
selinux [SELINUX] Disable or enable SELinux at boot time.
|
||||||
Format: { "0" | "1" }
|
Format: { "0" | "1" }
|
||||||
See security/selinux/Kconfig help text.
|
See security/selinux/Kconfig help text.
|
||||||
|
@ -1721,6 +1762,9 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
norandmaps Don't use address space randomization
|
norandmaps Don't use address space randomization
|
||||||
Equivalent to echo 0 > /proc/sys/kernel/randomize_va_space
|
Equivalent to echo 0 > /proc/sys/kernel/randomize_va_space
|
||||||
|
|
||||||
|
unwind_debug=N N > 0 will enable dwarf2 unwinder debugging
|
||||||
|
This is useful to get more information why
|
||||||
|
you got a "dwarf2 unwinder stuck"
|
||||||
|
|
||||||
______________________________________________________________________
|
______________________________________________________________________
|
||||||
|
|
||||||
|
|
|
@ -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.
|
|
||||||
|
|
|
@ -58,6 +58,8 @@ fore200e.txt
|
||||||
- FORE Systems PCA-200E/SBA-200E ATM NIC driver info.
|
- FORE Systems PCA-200E/SBA-200E ATM NIC driver info.
|
||||||
framerelay.txt
|
framerelay.txt
|
||||||
- info on using Frame Relay/Data Link Connection Identifier (DLCI).
|
- info on using Frame Relay/Data Link Connection Identifier (DLCI).
|
||||||
|
generic_netlink.txt
|
||||||
|
- info on Generic Netlink
|
||||||
ip-sysctl.txt
|
ip-sysctl.txt
|
||||||
- /proc/sys/net/ipv4/* variables
|
- /proc/sys/net/ipv4/* variables
|
||||||
ip_dynaddr.txt
|
ip_dynaddr.txt
|
||||||
|
|
|
@ -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,40 +19,92 @@ 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 proposed standard RFC status and the homepage for DCCP as a protocol
|
||||||
http://www.icir.org/kohler/dcp/
|
is at:
|
||||||
|
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
|
||||||
==============
|
==============
|
||||||
|
|
||||||
DCCP_SOCKOPT_PACKET_SIZE is used for CCID3 to set default packet size for
|
|
||||||
calculations.
|
|
||||||
|
|
||||||
DCCP_SOCKOPT_SERVICE sets the service. The specification mandates use of
|
DCCP_SOCKOPT_SERVICE sets the service. The specification mandates use of
|
||||||
service codes (RFC 4340, sec. 8.1.2); if this socket option is not set,
|
service codes (RFC 4340, sec. 8.1.2); if this socket option is not set,
|
||||||
the socket will fall back to 0 (which means that no meaningful service code
|
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.
|
|
||||||
|
|
|
@ -0,0 +1,3 @@
|
||||||
|
A wiki document on how to use Generic Netlink can be found here:
|
||||||
|
|
||||||
|
* http://linux-net.osdl.org/index.php/Generic_Netlink_HOWTO
|
|
@ -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:
|
||||||
|
|
||||||
+------------------+
|
+------------------+
|
||||||
|
|
|
@ -0,0 +1,56 @@
|
||||||
|
How to get s2ram working
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
2006 Linus Torvalds
|
||||||
|
2006 Pavel Machek
|
||||||
|
|
||||||
|
1) Check suspend.sf.net, program s2ram there has long whitelist of
|
||||||
|
"known ok" machines, along with tricks to use on each one.
|
||||||
|
|
||||||
|
2) If that does not help, try reading tricks.txt and
|
||||||
|
video.txt. Perhaps problem is as simple as broken module, and
|
||||||
|
simple module unload can fix it.
|
||||||
|
|
||||||
|
3) You can use Linus' TRACE_RESUME infrastructure, described below.
|
||||||
|
|
||||||
|
Using TRACE_RESUME
|
||||||
|
~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
I've been working at making the machines I have able to STR, and almost
|
||||||
|
always it's a driver that is buggy. Thank God for the suspend/resume
|
||||||
|
debugging - the thing that Chuck tried to disable. That's often the _only_
|
||||||
|
way to debug these things, and it's actually pretty powerful (but
|
||||||
|
time-consuming - having to insert TRACE_RESUME() markers into the device
|
||||||
|
driver that doesn't resume and recompile and reboot).
|
||||||
|
|
||||||
|
Anyway, the way to debug this for people who are interested (have a
|
||||||
|
machine that doesn't boot) is:
|
||||||
|
|
||||||
|
- enable PM_DEBUG, and PM_TRACE
|
||||||
|
|
||||||
|
- use a script like this:
|
||||||
|
|
||||||
|
#!/bin/sh
|
||||||
|
sync
|
||||||
|
echo 1 > /sys/power/pm_trace
|
||||||
|
echo mem > /sys/power/state
|
||||||
|
|
||||||
|
to suspend
|
||||||
|
|
||||||
|
- if it doesn't come back up (which is usually the problem), reboot by
|
||||||
|
holding the power button down, and look at the dmesg output for things
|
||||||
|
like
|
||||||
|
|
||||||
|
Magic number: 4:156:725
|
||||||
|
hash matches drivers/base/power/resume.c:28
|
||||||
|
hash matches device 0000:01:00.0
|
||||||
|
|
||||||
|
which means that the last trace event was just before trying to resume
|
||||||
|
device 0000:01:00.0. Then figure out what driver is controlling that
|
||||||
|
device (lspci and /sys/devices/pci* is your friend), and see if you can
|
||||||
|
fix it, disable it, or trace into its resume function.
|
||||||
|
|
||||||
|
For example, the above happens to be the VGA device on my EVO, which I
|
||||||
|
used to run with "radeonfb" (it's an ATI Radeon mobility). It turns out
|
||||||
|
that "radeonfb" simply cannot resume that device - it tries to set the
|
||||||
|
PLL's, and it just _hangs_. Using the regular VGA console and letting X
|
||||||
|
resume it instead works fine.
|
|
@ -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
|
||||||
|
|
|
@ -0,0 +1,60 @@
|
||||||
|
Using swap files with software suspend (swsusp)
|
||||||
|
(C) 2006 Rafael J. Wysocki <rjw@sisk.pl>
|
||||||
|
|
||||||
|
The Linux kernel handles swap files almost in the same way as it handles swap
|
||||||
|
partitions and there are only two differences between these two types of swap
|
||||||
|
areas:
|
||||||
|
(1) swap files need not be contiguous,
|
||||||
|
(2) the header of a swap file is not in the first block of the partition that
|
||||||
|
holds it. From the swsusp's point of view (1) is not a problem, because it is
|
||||||
|
already taken care of by the swap-handling code, but (2) has to be taken into
|
||||||
|
consideration.
|
||||||
|
|
||||||
|
In principle the location of a swap file's header may be determined with the
|
||||||
|
help of appropriate filesystem driver. Unfortunately, however, it requires the
|
||||||
|
filesystem holding the swap file to be mounted, and if this filesystem is
|
||||||
|
journaled, it cannot be mounted during resume from disk. For this reason to
|
||||||
|
identify a swap file swsusp uses the name of the partition that holds the file
|
||||||
|
and the offset from the beginning of the partition at which the swap file's
|
||||||
|
header is located. For convenience, this offset is expressed in <PAGE_SIZE>
|
||||||
|
units.
|
||||||
|
|
||||||
|
In order to use a swap file with swsusp, you need to:
|
||||||
|
|
||||||
|
1) Create the swap file and make it active, eg.
|
||||||
|
|
||||||
|
# dd if=/dev/zero of=<swap_file_path> bs=1024 count=<swap_file_size_in_k>
|
||||||
|
# mkswap <swap_file_path>
|
||||||
|
# swapon <swap_file_path>
|
||||||
|
|
||||||
|
2) Use an application that will bmap the swap file with the help of the
|
||||||
|
FIBMAP ioctl and determine the location of the file's swap header, as the
|
||||||
|
offset, in <PAGE_SIZE> units, from the beginning of the partition which
|
||||||
|
holds the swap file.
|
||||||
|
|
||||||
|
3) Add the following parameters to the kernel command line:
|
||||||
|
|
||||||
|
resume=<swap_file_partition> resume_offset=<swap_file_offset>
|
||||||
|
|
||||||
|
where <swap_file_partition> is the partition on which the swap file is located
|
||||||
|
and <swap_file_offset> is the offset of the swap header determined by the
|
||||||
|
application in 2) (of course, this step may be carried out automatically
|
||||||
|
by the same application that determies the swap file's header offset using the
|
||||||
|
FIBMAP ioctl)
|
||||||
|
|
||||||
|
OR
|
||||||
|
|
||||||
|
Use a userland suspend application that will set the partition and offset
|
||||||
|
with the help of the SNAPSHOT_SET_SWAP_AREA ioctl described in
|
||||||
|
Documentation/power/userland-swsusp.txt (this is the only method to suspend
|
||||||
|
to a swap file allowing the resume to be initiated from an initrd or initramfs
|
||||||
|
image).
|
||||||
|
|
||||||
|
Now, swsusp will use the swap file in the same way in which it would use a swap
|
||||||
|
partition. In particular, the swap file has to be active (ie. be present in
|
||||||
|
/proc/swaps) so that it can be used for suspending.
|
||||||
|
|
||||||
|
Note that if the swap file used for suspending is deleted and recreated,
|
||||||
|
the location of its header need not be the same as before. Thus every time
|
||||||
|
this happens the value of the "resume_offset=" kernel command line parameter
|
||||||
|
has to be updated.
|
|
@ -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
|
||||||
|
@ -297,20 +297,12 @@ system is shut down or suspended. Additionally use the encrypted
|
||||||
suspend image to prevent sensitive data from being stolen after
|
suspend image to prevent sensitive data from being stolen after
|
||||||
resume.
|
resume.
|
||||||
|
|
||||||
Q: Why can't we suspend to a swap file?
|
Q: Can I suspend to a swap file?
|
||||||
|
|
||||||
A: Because accessing swap file needs the filesystem mounted, and
|
A: Generally, yes, you can. However, it requires you to use the "resume=" and
|
||||||
filesystem might do something wrong (like replaying the journal)
|
"resume_offset=" kernel command line parameters, so the resume from a swap file
|
||||||
during mount.
|
cannot be initiated from an initrd or initramfs image. See
|
||||||
|
swsusp-and-swap-files.txt for details.
|
||||||
There are few ways to get that fixed:
|
|
||||||
|
|
||||||
1) Probably could be solved by modifying every filesystem to support
|
|
||||||
some kind of "really read-only!" option. Patches welcome.
|
|
||||||
|
|
||||||
2) suspend2 gets around that by storing absolute positions in on-disk
|
|
||||||
image (and blocksize), with resume parameter pointing directly to
|
|
||||||
suspend header.
|
|
||||||
|
|
||||||
Q: Is there a maximum system RAM size that is supported by swsusp?
|
Q: Is there a maximum system RAM size that is supported by swsusp?
|
||||||
|
|
||||||
|
|
|
@ -9,9 +9,8 @@ done it already.
|
||||||
Now, to use the userland interface for software suspend you need special
|
Now, to use the userland interface for software suspend you need special
|
||||||
utilities that will read/write the system memory snapshot from/to the
|
utilities that will read/write the system memory snapshot from/to the
|
||||||
kernel. Such utilities are available, for example, from
|
kernel. Such utilities are available, for example, from
|
||||||
<http://www.sisk.pl/kernel/utilities/suspend>. You may want to have
|
<http://suspend.sourceforge.net>. You may want to have a look at them if you
|
||||||
a look at them if you are going to develop your own suspend/resume
|
are going to develop your own suspend/resume utilities.
|
||||||
utilities.
|
|
||||||
|
|
||||||
The interface consists of a character device providing the open(),
|
The interface consists of a character device providing the open(),
|
||||||
release(), read(), and write() operations as well as several ioctl()
|
release(), read(), and write() operations as well as several ioctl()
|
||||||
|
@ -21,9 +20,9 @@ be read from /sys/class/misc/snapshot/dev.
|
||||||
|
|
||||||
The device can be open either for reading or for writing. If open for
|
The device can be open either for reading or for writing. If open for
|
||||||
reading, it is considered to be in the suspend mode. Otherwise it is
|
reading, it is considered to be in the suspend mode. Otherwise it is
|
||||||
assumed to be in the resume mode. The device cannot be open for reading
|
assumed to be in the resume mode. The device cannot be open for simultaneous
|
||||||
and writing. It is also impossible to have the device open more than once
|
reading and writing. It is also impossible to have the device open more than
|
||||||
at a time.
|
once at a time.
|
||||||
|
|
||||||
The ioctl() commands recognized by the device are:
|
The ioctl() commands recognized by the device are:
|
||||||
|
|
||||||
|
@ -69,9 +68,46 @@ SNAPSHOT_FREE_SWAP_PAGES - free all swap pages allocated with
|
||||||
SNAPSHOT_SET_SWAP_FILE - set the resume partition (the last ioctl() argument
|
SNAPSHOT_SET_SWAP_FILE - set the resume partition (the last ioctl() argument
|
||||||
should specify the device's major and minor numbers in the old
|
should specify the device's major and minor numbers in the old
|
||||||
two-byte format, as returned by the stat() function in the .st_rdev
|
two-byte format, as returned by the stat() function in the .st_rdev
|
||||||
member of the stat structure); it is recommended to always use this
|
member of the stat structure)
|
||||||
call, because the code to set the resume partition could be removed from
|
|
||||||
future kernels
|
SNAPSHOT_SET_SWAP_AREA - set the resume partition and the offset (in <PAGE_SIZE>
|
||||||
|
units) from the beginning of the partition at which the swap header is
|
||||||
|
located (the last ioctl() argument should point to a struct
|
||||||
|
resume_swap_area, as defined in kernel/power/power.h, containing the
|
||||||
|
resume device specification, as for the SNAPSHOT_SET_SWAP_FILE ioctl(),
|
||||||
|
and the offset); for swap partitions the offset is always 0, but it is
|
||||||
|
different to zero for swap files (please see
|
||||||
|
Documentation/swsusp-and-swap-files.txt for details).
|
||||||
|
The SNAPSHOT_SET_SWAP_AREA ioctl() is considered as a replacement for
|
||||||
|
SNAPSHOT_SET_SWAP_FILE which is regarded as obsolete. It is
|
||||||
|
recommended to always use this call, because the code to set the resume
|
||||||
|
partition may be removed from future kernels
|
||||||
|
|
||||||
|
SNAPSHOT_S2RAM - suspend to RAM; using this call causes the kernel to
|
||||||
|
immediately enter the suspend-to-RAM state, so this call must always
|
||||||
|
be preceded by the SNAPSHOT_FREEZE call and it is also necessary
|
||||||
|
to use the SNAPSHOT_UNFREEZE call after the system wakes up. This call
|
||||||
|
is needed to implement the suspend-to-both mechanism in which the
|
||||||
|
suspend image is first created, as though the system had been suspended
|
||||||
|
to disk, and then the system is suspended to RAM (this makes it possible
|
||||||
|
to resume the system from RAM if there's enough battery power or restore
|
||||||
|
its state on the basis of the saved suspend image otherwise)
|
||||||
|
|
||||||
|
SNAPSHOT_PMOPS - enable the usage of the pmops->prepare, pmops->enter and
|
||||||
|
pmops->finish methods (the in-kernel swsusp knows these as the "platform
|
||||||
|
method") which are needed on many machines to (among others) speed up
|
||||||
|
the resume by letting the BIOS skip some steps or to let the system
|
||||||
|
recognise the correct state of the hardware after the resume (in
|
||||||
|
particular on many machines this ensures that unplugged AC
|
||||||
|
adapters get correctly detected and that kacpid does not run wild after
|
||||||
|
the resume). The last ioctl() argument can take one of the three
|
||||||
|
values, defined in kernel/power/power.h:
|
||||||
|
PMOPS_PREPARE - make the kernel carry out the
|
||||||
|
pm_ops->prepare(PM_SUSPEND_DISK) operation
|
||||||
|
PMOPS_ENTER - make the kernel power off the system by calling
|
||||||
|
pm_ops->enter(PM_SUSPEND_DISK)
|
||||||
|
PMOPS_FINISH - make the kernel carry out the
|
||||||
|
pm_ops->finish(PM_SUSPEND_DISK) operation
|
||||||
|
|
||||||
The device's read() operation can be used to transfer the snapshot image from
|
The device's read() operation can be used to transfer the snapshot image from
|
||||||
the kernel. It has the following limitations:
|
the kernel. It has the following limitations:
|
||||||
|
@ -91,10 +127,12 @@ unfreeze user space processes frozen by SNAPSHOT_UNFREEZE if they are
|
||||||
still frozen when the device is being closed).
|
still frozen when the device is being closed).
|
||||||
|
|
||||||
Currently it is assumed that the userland utilities reading/writing the
|
Currently it is assumed that the userland utilities reading/writing the
|
||||||
snapshot image from/to the kernel will use a swap partition, called the resume
|
snapshot image from/to the kernel will use a swap parition, called the resume
|
||||||
partition, as storage space. However, this is not really required, as they
|
partition, or a swap file as storage space (if a swap file is used, the resume
|
||||||
can use, for example, a special (blank) suspend partition or a file on a partition
|
partition is the partition that holds this file). However, this is not really
|
||||||
that is unmounted before SNAPSHOT_ATOMIC_SNAPSHOT and mounted afterwards.
|
required, as they can use, for example, a special (blank) suspend partition or
|
||||||
|
a file on a partition that is unmounted before SNAPSHOT_ATOMIC_SNAPSHOT and
|
||||||
|
mounted afterwards.
|
||||||
|
|
||||||
These utilities SHOULD NOT make any assumptions regarding the ordering of
|
These utilities SHOULD NOT make any assumptions regarding the ordering of
|
||||||
data within the snapshot image, except for the image header that MAY be
|
data within the snapshot image, except for the image header that MAY be
|
||||||
|
|
|
@ -6,6 +6,8 @@
|
||||||
IBM Corp.
|
IBM Corp.
|
||||||
(c) 2005 Becky Bruce <becky.bruce at freescale.com>,
|
(c) 2005 Becky Bruce <becky.bruce at freescale.com>,
|
||||||
Freescale Semiconductor, FSL SOC and 32-bit additions
|
Freescale Semiconductor, FSL SOC and 32-bit additions
|
||||||
|
(c) 2006 MontaVista Software, Inc.
|
||||||
|
Flash chip node definition
|
||||||
|
|
||||||
May 18, 2005: Rev 0.1 - Initial draft, no chapter III yet.
|
May 18, 2005: Rev 0.1 - Initial draft, no chapter III yet.
|
||||||
|
|
||||||
|
@ -33,13 +35,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 +856,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 +1126,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
|
||||||
|
@ -1693,6 +1695,43 @@ platforms are moved over to use the flattened-device-tree model.
|
||||||
};
|
};
|
||||||
};
|
};
|
||||||
|
|
||||||
|
g) Flash chip nodes
|
||||||
|
|
||||||
|
Flash chips (Memory Technology Devices) are often used for solid state
|
||||||
|
file systems on embedded devices.
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
|
||||||
|
- device_type : has to be "rom"
|
||||||
|
- compatible : Should specify what this ROM device is compatible with
|
||||||
|
(i.e. "onenand"). Currently, this is most likely to be "direct-mapped"
|
||||||
|
(which corresponds to the MTD physmap mapping driver).
|
||||||
|
- regs : Offset and length of the register set (or memory mapping) for
|
||||||
|
the device.
|
||||||
|
|
||||||
|
Recommended properties :
|
||||||
|
|
||||||
|
- bank-width : Width of the flash data bus in bytes. Required
|
||||||
|
for the NOR flashes (compatible == "direct-mapped" and others) ONLY.
|
||||||
|
- partitions : Several pairs of 32-bit values where the first value is
|
||||||
|
partition's offset from the start of the device and the second one is
|
||||||
|
partition size in bytes with LSB used to signify a read only
|
||||||
|
partititon (so, the parition size should always be an even number).
|
||||||
|
- partition-names : The list of concatenated zero terminated strings
|
||||||
|
representing the partition names.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
flash@ff000000 {
|
||||||
|
device_type = "rom";
|
||||||
|
compatible = "direct-mapped";
|
||||||
|
regs = <ff000000 01000000>;
|
||||||
|
bank-width = <4>;
|
||||||
|
partitions = <00000000 00f80000
|
||||||
|
00f80000 00080001>;
|
||||||
|
partition-names = "fs\0firmware";
|
||||||
|
};
|
||||||
|
|
||||||
More devices will be defined as this spec matures.
|
More devices will be defined as this spec matures.
|
||||||
|
|
||||||
|
|
||||||
|
|
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче