mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-29 03:01:39 -04:00
Merge branch 'linus' into x86/memory-corruption-check
This commit is contained in:
Ingo Molnar
commit
a9b9e81c91
3879 changed files with 196633 additions and 93986 deletions
|
|
@ -251,8 +251,6 @@ mono.txt
|
|||
- how to execute Mono-based .NET binaries with the help of BINFMT_MISC.
|
||||
moxa-smartio
|
||||
- file with info on installing/using Moxa multiport serial driver.
|
||||
mtrr.txt
|
||||
- how to use PPro Memory Type Range Registers to increase performance.
|
||||
mutex-design.txt
|
||||
- info on the generic mutex subsystem.
|
||||
namespaces/
|
||||
|
|
|
|||
26
Documentation/ABI/testing/sysfs-gpio
Normal file
26
Documentation/ABI/testing/sysfs-gpio
Normal file
|
|
@ -0,0 +1,26 @@
|
|||
What: /sys/class/gpio/
|
||||
Date: July 2008
|
||||
KernelVersion: 2.6.27
|
||||
Contact: David Brownell <[email protected]>
|
||||
Description:
|
||||
|
||||
As a Kconfig option, individual GPIO signals may be accessed from
|
||||
userspace. GPIOs are only made available to userspace by an explicit
|
||||
"export" operation. If a given GPIO is not claimed for use by
|
||||
kernel code, it may be exported by userspace (and unexported later).
|
||||
Kernel code may export it for complete or partial access.
|
||||
|
||||
GPIOs are identified as they are inside the kernel, using integers in
|
||||
the range 0..INT_MAX. See Documentation/gpio.txt for more information.
|
||||
|
||||
/sys/class/gpio
|
||||
/export ... asks the kernel to export a GPIO to userspace
|
||||
/unexport ... to return a GPIO to the kernel
|
||||
/gpioN ... for each exported GPIO #N
|
||||
/value ... always readable, writes fail for input GPIOs
|
||||
/direction ... r/w as: in, out (default low); write: high, low
|
||||
/gpiochipN ... for each gpiochip; #N is its first GPIO
|
||||
/base ... (r/o) same as N
|
||||
/label ... (r/o) descriptive, not necessarily unique
|
||||
/ngpio ... (r/o) number of GPIOs; numbered N to N + (ngpio - 1)
|
||||
|
||||
|
|
@ -337,7 +337,7 @@ With scatterlists, you use the resulting mapping like this:
|
|||
int i, count = dma_map_sg(dev, sglist, nents, direction);
|
||||
struct scatterlist *sg;
|
||||
|
||||
for (i = 0, sg = sglist; i < count; i++, sg++) {
|
||||
for_each_sg(sglist, sg, count, i) {
|
||||
hw_address[i] = sg_dma_address(sg);
|
||||
hw_len[i] = sg_dma_len(sg);
|
||||
}
|
||||
|
|
|
|||
|
|
@ -740,7 +740,7 @@ failure can be determined by:
|
|||
dma_addr_t dma_handle;
|
||||
|
||||
dma_handle = pci_map_single(pdev, addr, size, direction);
|
||||
if (pci_dma_mapping_error(dma_handle)) {
|
||||
if (pci_dma_mapping_error(pdev, dma_handle)) {
|
||||
/*
|
||||
* reduce current DMA mapping usage,
|
||||
* delay and try again later or
|
||||
|
|
|
|||
|
|
@ -283,6 +283,7 @@ X!Earch/x86/kernel/mca_32.c
|
|||
<chapter id="security">
|
||||
<title>Security Framework</title>
|
||||
!Isecurity/security.c
|
||||
!Esecurity/inode.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="audit">
|
||||
|
|
@ -364,6 +365,10 @@ X!Edrivers/pnp/system.c
|
|||
!Eblock/blk-barrier.c
|
||||
!Eblock/blk-tag.c
|
||||
!Iblock/blk-tag.c
|
||||
!Eblock/blk-integrity.c
|
||||
!Iblock/blktrace.c
|
||||
!Iblock/genhd.c
|
||||
!Eblock/genhd.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="chrdev">
|
||||
|
|
|
|||
|
|
@ -145,7 +145,6 @@ usage should require reading the full document.
|
|||
this though and the recommendation to allow only a single
|
||||
interface in STA mode at first!
|
||||
</para>
|
||||
!Finclude/net/mac80211.h ieee80211_if_types
|
||||
!Finclude/net/mac80211.h ieee80211_if_init_conf
|
||||
!Finclude/net/mac80211.h ieee80211_if_conf
|
||||
</chapter>
|
||||
|
|
@ -177,8 +176,7 @@ usage should require reading the full document.
|
|||
<title>functions/definitions</title>
|
||||
!Finclude/net/mac80211.h ieee80211_rx_status
|
||||
!Finclude/net/mac80211.h mac80211_rx_flags
|
||||
!Finclude/net/mac80211.h ieee80211_tx_control
|
||||
!Finclude/net/mac80211.h ieee80211_tx_status_flags
|
||||
!Finclude/net/mac80211.h ieee80211_tx_info
|
||||
!Finclude/net/mac80211.h ieee80211_rx
|
||||
!Finclude/net/mac80211.h ieee80211_rx_irqsafe
|
||||
!Finclude/net/mac80211.h ieee80211_tx_status
|
||||
|
|
@ -189,12 +187,11 @@ usage should require reading the full document.
|
|||
!Finclude/net/mac80211.h ieee80211_ctstoself_duration
|
||||
!Finclude/net/mac80211.h ieee80211_generic_frame_duration
|
||||
!Finclude/net/mac80211.h ieee80211_get_hdrlen_from_skb
|
||||
!Finclude/net/mac80211.h ieee80211_get_hdrlen
|
||||
!Finclude/net/mac80211.h ieee80211_hdrlen
|
||||
!Finclude/net/mac80211.h ieee80211_wake_queue
|
||||
!Finclude/net/mac80211.h ieee80211_stop_queue
|
||||
!Finclude/net/mac80211.h ieee80211_start_queues
|
||||
!Finclude/net/mac80211.h ieee80211_stop_queues
|
||||
!Finclude/net/mac80211.h ieee80211_wake_queues
|
||||
!Finclude/net/mac80211.h ieee80211_stop_queues
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
|
|
@ -230,8 +227,7 @@ usage should require reading the full document.
|
|||
<title>Multiple queues and QoS support</title>
|
||||
<para>TBD</para>
|
||||
!Finclude/net/mac80211.h ieee80211_tx_queue_params
|
||||
!Finclude/net/mac80211.h ieee80211_tx_queue_stats_data
|
||||
!Finclude/net/mac80211.h ieee80211_tx_queue
|
||||
!Finclude/net/mac80211.h ieee80211_tx_queue_stats
|
||||
</chapter>
|
||||
|
||||
<chapter id="AP">
|
||||
|
|
|
|||
|
|
@ -77,7 +77,8 @@ documentation files are also added which explain how to use the feature.
|
|||
When a kernel change causes the interface that the kernel exposes to
|
||||
userspace to change, it is recommended that you send the information or
|
||||
a patch to the manual pages explaining the change to the manual pages
|
||||
maintainer at [email protected].
|
||||
maintainer at [email protected], and CC the list
|
||||
[email protected].
|
||||
|
||||
Here is a list of files that are in the kernel source tree that are
|
||||
required reading:
|
||||
|
|
|
|||
|
|
@ -210,7 +210,7 @@ over a rather long period of time, but improvements are always welcome!
|
|||
number of updates per grace period.
|
||||
|
||||
9. All RCU list-traversal primitives, which include
|
||||
rcu_dereference(), list_for_each_rcu(), list_for_each_entry_rcu(),
|
||||
rcu_dereference(), list_for_each_entry_rcu(),
|
||||
list_for_each_continue_rcu(), and list_for_each_safe_rcu(),
|
||||
must be either within an RCU read-side critical section or
|
||||
must be protected by appropriate update-side locks. RCU
|
||||
|
|
|
|||
|
|
@ -29,9 +29,9 @@ release_referenced() delete()
|
|||
}
|
||||
|
||||
If this list/array is made lock free using RCU as in changing the
|
||||
write_lock() in add() and delete() to spin_lock and changing read_lock
|
||||
in search_and_reference to rcu_read_lock(), the atomic_get in
|
||||
search_and_reference could potentially hold reference to an element which
|
||||
write_lock() in add() and delete() to spin_lock() and changing read_lock()
|
||||
in search_and_reference() to rcu_read_lock(), the atomic_inc() in
|
||||
search_and_reference() could potentially hold reference to an element which
|
||||
has already been deleted from the list/array. Use atomic_inc_not_zero()
|
||||
in this scenario as follows:
|
||||
|
||||
|
|
@ -40,20 +40,20 @@ add() search_and_reference()
|
|||
{ {
|
||||
alloc_object rcu_read_lock();
|
||||
... search_for_element
|
||||
atomic_set(&el->rc, 1); if (atomic_inc_not_zero(&el->rc)) {
|
||||
write_lock(&list_lock); rcu_read_unlock();
|
||||
atomic_set(&el->rc, 1); if (!atomic_inc_not_zero(&el->rc)) {
|
||||
spin_lock(&list_lock); rcu_read_unlock();
|
||||
return FAIL;
|
||||
add_element }
|
||||
... ...
|
||||
write_unlock(&list_lock); rcu_read_unlock();
|
||||
spin_unlock(&list_lock); rcu_read_unlock();
|
||||
} }
|
||||
3. 4.
|
||||
release_referenced() delete()
|
||||
{ {
|
||||
... write_lock(&list_lock);
|
||||
... spin_lock(&list_lock);
|
||||
if (atomic_dec_and_test(&el->rc)) ...
|
||||
call_rcu(&el->head, el_free); delete_element
|
||||
... write_unlock(&list_lock);
|
||||
... spin_unlock(&list_lock);
|
||||
} ...
|
||||
if (atomic_dec_and_test(&el->rc))
|
||||
call_rcu(&el->head, el_free);
|
||||
|
|
|
|||
|
|
@ -786,8 +786,6 @@ RCU pointer/list traversal:
|
|||
list_for_each_entry_rcu
|
||||
hlist_for_each_entry_rcu
|
||||
|
||||
list_for_each_rcu (to be deprecated in favor of
|
||||
list_for_each_entry_rcu)
|
||||
list_for_each_continue_rcu (to be deprecated in favor of new
|
||||
list_for_each_entry_continue_rcu)
|
||||
|
||||
|
|
|
|||
27
Documentation/SELinux.txt
Normal file
27
Documentation/SELinux.txt
Normal file
|
|
@ -0,0 +1,27 @@
|
|||
If you want to use SELinux, chances are you will want
|
||||
to use the distro-provided policies, or install the
|
||||
latest reference policy release from
|
||||
http://oss.tresys.com/projects/refpolicy
|
||||
|
||||
However, if you want to install a dummy policy for
|
||||
testing, you can do using 'mdp' provided under
|
||||
scripts/selinux. Note that this requires the selinux
|
||||
userspace to be installed - in particular you will
|
||||
need checkpolicy to compile a kernel, and setfiles and
|
||||
fixfiles to label the filesystem.
|
||||
|
||||
1. Compile the kernel with selinux enabled.
|
||||
2. Type 'make' to compile mdp.
|
||||
3. Make sure that you are not running with
|
||||
SELinux enabled and a real policy. If
|
||||
you are, reboot with selinux disabled
|
||||
before continuing.
|
||||
4. Run install_policy.sh:
|
||||
cd scripts/selinux
|
||||
sh install_policy.sh
|
||||
|
||||
Step 4 will create a new dummy policy valid for your
|
||||
kernel, with a single selinux user, role, and type.
|
||||
It will compile the policy, will set your SELINUXTYPE to
|
||||
dummy in /etc/selinux/config, install the compiled policy
|
||||
as 'dummy', and relabel your filesystem.
|
||||
|
|
@ -67,6 +67,8 @@ kernel patches.
|
|||
|
||||
19: All new userspace interfaces are documented in Documentation/ABI/.
|
||||
See Documentation/ABI/README for more information.
|
||||
Patches that change userspace interfaces should be CCed to
|
||||
[email protected].
|
||||
|
||||
20: Check that it all passes `make headers_check'.
|
||||
|
||||
|
|
|
|||
|
|
@ -30,12 +30,18 @@ write_expire (in ms)
|
|||
Similar to read_expire mentioned above, but for writes.
|
||||
|
||||
|
||||
fifo_batch
|
||||
fifo_batch (number of requests)
|
||||
----------
|
||||
|
||||
When a read request expires its deadline, we must move some requests from
|
||||
the sorted io scheduler list to the block device dispatch queue. fifo_batch
|
||||
controls how many requests we move.
|
||||
Requests are grouped into ``batches'' of a particular data direction (read or
|
||||
write) which are serviced in increasing sector order. To limit extra seeking,
|
||||
deadline expiries are only checked between batches. fifo_batch controls the
|
||||
maximum number of requests per batch.
|
||||
|
||||
This parameter tunes the balance between per-request latency and aggregate
|
||||
throughput. When low latency is the primary concern, smaller is better (where
|
||||
a value of 1 yields first-come first-served behaviour). Increasing fifo_batch
|
||||
generally improves throughput, at the cost of latency variation.
|
||||
|
||||
|
||||
writes_starved (number of dispatches)
|
||||
|
|
|
|||
|
|
@ -145,8 +145,7 @@ useful for reading photocds.
|
|||
|
||||
To play an audio CD, you should first unmount and remove any data
|
||||
CDROM. Any of the CDROM player programs should then work (workman,
|
||||
workbone, cdplayer, etc.). Lacking anything else, you could use the
|
||||
cdtester program in Documentation/cdrom/sbpcd.
|
||||
workbone, cdplayer, etc.).
|
||||
|
||||
On a few drives, you can read digital audio directly using a program
|
||||
such as cdda2wav. The only types of drive which I've heard support
|
||||
|
|
|
|||
|
|
@ -35,11 +35,9 @@ Mailing List
|
|||
------------
|
||||
There is a CPU frequency changing CVS commit and general list where
|
||||
you can report bugs, problems or submit patches. To post a message,
|
||||
send an email to [email protected], to subscribe go to
|
||||
http://lists.linux.org.uk/mailman/listinfo/cpufreq. Previous post to the
|
||||
mailing list are available to subscribers at
|
||||
http://lists.linux.org.uk/mailman/private/cpufreq/.
|
||||
|
||||
send an email to [email protected], to subscribe go to
|
||||
http://vger.kernel.org/vger-lists.html#cpufreq and follow the
|
||||
instructions there.
|
||||
|
||||
Links
|
||||
-----
|
||||
|
|
@ -50,7 +48,7 @@ how to access the CVS repository:
|
|||
* http://cvs.arm.linux.org.uk/
|
||||
|
||||
the CPUFreq Mailing list:
|
||||
* http://lists.linux.org.uk/mailman/listinfo/cpufreq
|
||||
* http://vger.kernel.org/vger-lists.html#cpufreq
|
||||
|
||||
Clock and voltage scaling for the SA-1100:
|
||||
* http://www.lartmaker.nl/projects/scaling
|
||||
|
|
|
|||
|
|
@ -635,14 +635,16 @@ prior 'mems' setting, will not be moved.
|
|||
|
||||
There is an exception to the above. If hotplug functionality is used
|
||||
to remove all the CPUs that are currently assigned to a cpuset,
|
||||
then the kernel will automatically update the cpus_allowed of all
|
||||
tasks attached to CPUs in that cpuset to allow all CPUs. When memory
|
||||
hotplug functionality for removing Memory Nodes is available, a
|
||||
similar exception is expected to apply there as well. In general,
|
||||
the kernel prefers to violate cpuset placement, over starving a task
|
||||
that has had all its allowed CPUs or Memory Nodes taken offline. User
|
||||
code should reconfigure cpusets to only refer to online CPUs and Memory
|
||||
Nodes when using hotplug to add or remove such resources.
|
||||
then all the tasks in that cpuset will be moved to the nearest ancestor
|
||||
with non-empty cpus. But the moving of some (or all) tasks might fail if
|
||||
cpuset is bound with another cgroup subsystem which has some restrictions
|
||||
on task attaching. In this failing case, those tasks will stay
|
||||
in the original cpuset, and the kernel will automatically update
|
||||
their cpus_allowed to allow all online CPUs. When memory hotplug
|
||||
functionality for removing Memory Nodes is available, a similar exception
|
||||
is expected to apply there as well. In general, the kernel prefers to
|
||||
violate cpuset placement, over starving a task that has had all
|
||||
its allowed CPUs or Memory Nodes taken offline.
|
||||
|
||||
There is a second exception to the above. GFP_ATOMIC requests are
|
||||
kernel internal allocations that must be satisfied, immediately.
|
||||
|
|
|
|||
|
|
@ -6,6 +6,24 @@ be removed from this file.
|
|||
|
||||
---------------------------
|
||||
|
||||
What: old static regulatory information and ieee80211_regdom module parameter
|
||||
When: 2.6.29
|
||||
Why: The old regulatory infrastructure has been replaced with a new one
|
||||
which does not require statically defined regulatory domains. We do
|
||||
not want to keep static regulatory domains in the kernel due to the
|
||||
the dynamic nature of regulatory law and localization. We kept around
|
||||
the old static definitions for the regulatory domains of:
|
||||
* US
|
||||
* JP
|
||||
* EU
|
||||
and used by default the US when CONFIG_WIRELESS_OLD_REGULATORY was
|
||||
set. We also kept around the ieee80211_regdom module parameter in case
|
||||
some applications were relying on it. Changing regulatory domains
|
||||
can now be done instead by using nl80211, as is done with iw.
|
||||
Who: Luis R. Rodriguez <[email protected]>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: dev->power.power_state
|
||||
When: July 2007
|
||||
Why: Broken design for runtime control over driver power states, confusing
|
||||
|
|
@ -232,6 +250,9 @@ What (Why):
|
|||
- xt_mark match revision 0
|
||||
(superseded by xt_mark match revision 1)
|
||||
|
||||
- xt_recent: the old ipt_recent proc dir
|
||||
(superseded by /proc/net/xt_recent)
|
||||
|
||||
When: January 2009 or Linux 2.7.0, whichever comes first
|
||||
Why: Superseded by newer revisions or modules
|
||||
Who: Jan Engelhardt <[email protected]>
|
||||
|
|
@ -322,3 +343,11 @@ Why: Accounting can now be enabled/disabled without kernel recompilation.
|
|||
controlled by a kernel/module/sysfs/sysctl parameter.
|
||||
Who: Krzysztof Piotr Oledzki <[email protected]>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: ide-scsi (BLK_DEV_IDESCSI)
|
||||
When: 2.6.29
|
||||
Why: The 2.6 kernel supports direct writing to ide CD drives, which
|
||||
eliminates the need for ide-scsi. The new method is more
|
||||
efficient in every way.
|
||||
Who: FUJITA Tomonori <[email protected]>
|
||||
|
|
|
|||
|
|
@ -32,9 +32,9 @@ Mailing list: [email protected]
|
|||
you will need to merge your changes with the version from e2fsprogs
|
||||
1.41.x.
|
||||
|
||||
- Create a new filesystem using the ext4dev filesystem type:
|
||||
- Create a new filesystem using the ext4 filesystem type:
|
||||
|
||||
# mke2fs -t ext4dev /dev/hda1
|
||||
# mke2fs -t ext4 /dev/hda1
|
||||
|
||||
Or configure an existing ext3 filesystem to support extents and set
|
||||
the test_fs flag to indicate that it's ok for an in-development
|
||||
|
|
@ -47,13 +47,13 @@ Mailing list: [email protected]
|
|||
|
||||
# tune2fs -I 256 /dev/hda1
|
||||
|
||||
(Note: we currently do not have tools to convert an ext4dev
|
||||
(Note: we currently do not have tools to convert an ext4
|
||||
filesystem back to ext3; so please do not do try this on production
|
||||
filesystems.)
|
||||
|
||||
- Mounting:
|
||||
|
||||
# mount -t ext4dev /dev/hda1 /wherever
|
||||
# mount -t ext4 /dev/hda1 /wherever
|
||||
|
||||
- When comparing performance with other filesystems, remember that
|
||||
ext3/4 by default offers higher data integrity guarantees than most.
|
||||
|
|
@ -177,6 +177,11 @@ barrier=<0|1(*)> This enables/disables the use of write barriers in
|
|||
your disks are battery-backed in one way or another,
|
||||
disabling barriers may safely improve performance.
|
||||
|
||||
inode_readahead=n This tuning parameter controls the maximum
|
||||
number of inode table blocks that ext4's inode
|
||||
table readahead algorithm will pre-read into
|
||||
the buffer cache. The default value is 32 blocks.
|
||||
|
||||
orlov (*) This enables the new Orlov block allocator. It is
|
||||
enabled by default.
|
||||
|
||||
|
|
@ -252,6 +257,7 @@ stripe=n Number of filesystem blocks that mballoc will try
|
|||
delalloc (*) Deferring block allocation until write-out time.
|
||||
nodelalloc Disable delayed allocation. Blocks are allocation
|
||||
when data is copied from user to page cache.
|
||||
|
||||
Data Mode
|
||||
=========
|
||||
There are 3 different data modes:
|
||||
|
|
|
|||
228
Documentation/filesystems/fiemap.txt
Normal file
228
Documentation/filesystems/fiemap.txt
Normal file
|
|
@ -0,0 +1,228 @@
|
|||
============
|
||||
Fiemap Ioctl
|
||||
============
|
||||
|
||||
The fiemap ioctl is an efficient method for userspace to get file
|
||||
extent mappings. Instead of block-by-block mapping (such as bmap), fiemap
|
||||
returns a list of extents.
|
||||
|
||||
|
||||
Request Basics
|
||||
--------------
|
||||
|
||||
A fiemap request is encoded within struct fiemap:
|
||||
|
||||
struct fiemap {
|
||||
__u64 fm_start; /* logical offset (inclusive) at
|
||||
* which to start mapping (in) */
|
||||
__u64 fm_length; /* logical length of mapping which
|
||||
* userspace cares about (in) */
|
||||
__u32 fm_flags; /* FIEMAP_FLAG_* flags for request (in/out) */
|
||||
__u32 fm_mapped_extents; /* number of extents that were
|
||||
* mapped (out) */
|
||||
__u32 fm_extent_count; /* size of fm_extents array (in) */
|
||||
__u32 fm_reserved;
|
||||
struct fiemap_extent fm_extents[0]; /* array of mapped extents (out) */
|
||||
};
|
||||
|
||||
|
||||
fm_start, and fm_length specify the logical range within the file
|
||||
which the process would like mappings for. Extents returned mirror
|
||||
those on disk - that is, the logical offset of the 1st returned extent
|
||||
may start before fm_start, and the range covered by the last returned
|
||||
extent may end after fm_length. All offsets and lengths are in bytes.
|
||||
|
||||
Certain flags to modify the way in which mappings are looked up can be
|
||||
set in fm_flags. If the kernel doesn't understand some particular
|
||||
flags, it will return EBADR and the contents of fm_flags will contain
|
||||
the set of flags which caused the error. If the kernel is compatible
|
||||
with all flags passed, the contents of fm_flags will be unmodified.
|
||||
It is up to userspace to determine whether rejection of a particular
|
||||
flag is fatal to it's operation. This scheme is intended to allow the
|
||||
fiemap interface to grow in the future but without losing
|
||||
compatibility with old software.
|
||||
|
||||
fm_extent_count specifies the number of elements in the fm_extents[] array
|
||||
that can be used to return extents. If fm_extent_count is zero, then the
|
||||
fm_extents[] array is ignored (no extents will be returned), and the
|
||||
fm_mapped_extents count will hold the number of extents needed in
|
||||
fm_extents[] to hold the file's current mapping. Note that there is
|
||||
nothing to prevent the file from changing between calls to FIEMAP.
|
||||
|
||||
The following flags can be set in fm_flags:
|
||||
|
||||
* FIEMAP_FLAG_SYNC
|
||||
If this flag is set, the kernel will sync the file before mapping extents.
|
||||
|
||||
* FIEMAP_FLAG_XATTR
|
||||
If this flag is set, the extents returned will describe the inodes
|
||||
extended attribute lookup tree, instead of it's data tree.
|
||||
|
||||
|
||||
Extent Mapping
|
||||
--------------
|
||||
|
||||
Extent information is returned within the embedded fm_extents array
|
||||
which userspace must allocate along with the fiemap structure. The
|
||||
number of elements in the fiemap_extents[] array should be passed via
|
||||
fm_extent_count. The number of extents mapped by kernel will be
|
||||
returned via fm_mapped_extents. If the number of fiemap_extents
|
||||
allocated is less than would be required to map the requested range,
|
||||
the maximum number of extents that can be mapped in the fm_extent[]
|
||||
array will be returned and fm_mapped_extents will be equal to
|
||||
fm_extent_count. In that case, the last extent in the array will not
|
||||
complete the requested range and will not have the FIEMAP_EXTENT_LAST
|
||||
flag set (see the next section on extent flags).
|
||||
|
||||
Each extent is described by a single fiemap_extent structure as
|
||||
returned in fm_extents.
|
||||
|
||||
struct fiemap_extent {
|
||||
__u64 fe_logical; /* logical offset in bytes for the start of
|
||||
* the extent */
|
||||
__u64 fe_physical; /* physical offset in bytes for the start
|
||||
* of the extent */
|
||||
__u64 fe_length; /* length in bytes for the extent */
|
||||
__u64 fe_reserved64[2];
|
||||
__u32 fe_flags; /* FIEMAP_EXTENT_* flags for this extent */
|
||||
__u32 fe_reserved[3];
|
||||
};
|
||||
|
||||
All offsets and lengths are in bytes and mirror those on disk. It is valid
|
||||
for an extents logical offset to start before the request or it's logical
|
||||
length to extend past the request. Unless FIEMAP_EXTENT_NOT_ALIGNED is
|
||||
returned, fe_logical, fe_physical, and fe_length will be aligned to the
|
||||
block size of the file system. With the exception of extents flagged as
|
||||
FIEMAP_EXTENT_MERGED, adjacent extents will not be merged.
|
||||
|
||||
The fe_flags field contains flags which describe the extent returned.
|
||||
A special flag, FIEMAP_EXTENT_LAST is always set on the last extent in
|
||||
the file so that the process making fiemap calls can determine when no
|
||||
more extents are available, without having to call the ioctl again.
|
||||
|
||||
Some flags are intentionally vague and will always be set in the
|
||||
presence of other more specific flags. This way a program looking for
|
||||
a general property does not have to know all existing and future flags
|
||||
which imply that property.
|
||||
|
||||
For example, if FIEMAP_EXTENT_DATA_INLINE or FIEMAP_EXTENT_DATA_TAIL
|
||||
are set, FIEMAP_EXTENT_NOT_ALIGNED will also be set. A program looking
|
||||
for inline or tail-packed data can key on the specific flag. Software
|
||||
which simply cares not to try operating on non-aligned extents
|
||||
however, can just key on FIEMAP_EXTENT_NOT_ALIGNED, and not have to
|
||||
worry about all present and future flags which might imply unaligned
|
||||
data. Note that the opposite is not true - it would be valid for
|
||||
FIEMAP_EXTENT_NOT_ALIGNED to appear alone.
|
||||
|
||||
* FIEMAP_EXTENT_LAST
|
||||
This is the last extent in the file. A mapping attempt past this
|
||||
extent will return nothing.
|
||||
|
||||
* FIEMAP_EXTENT_UNKNOWN
|
||||
The location of this extent is currently unknown. This may indicate
|
||||
the data is stored on an inaccessible volume or that no storage has
|
||||
been allocated for the file yet.
|
||||
|
||||
* FIEMAP_EXTENT_DELALLOC
|
||||
- This will also set FIEMAP_EXTENT_UNKNOWN.
|
||||
Delayed allocation - while there is data for this extent, it's
|
||||
physical location has not been allocated yet.
|
||||
|
||||
* FIEMAP_EXTENT_ENCODED
|
||||
This extent does not consist of plain filesystem blocks but is
|
||||
encoded (e.g. encrypted or compressed). Reading the data in this
|
||||
extent via I/O to the block device will have undefined results.
|
||||
|
||||
Note that it is *always* undefined to try to update the data
|
||||
in-place by writing to the indicated location without the
|
||||
assistance of the filesystem, or to access the data using the
|
||||
information returned by the FIEMAP interface while the filesystem
|
||||
is mounted. In other words, user applications may only read the
|
||||
extent data via I/O to the block device while the filesystem is
|
||||
unmounted, and then only if the FIEMAP_EXTENT_ENCODED flag is
|
||||
clear; user applications must not try reading or writing to the
|
||||
filesystem via the block device under any other circumstances.
|
||||
|
||||
* FIEMAP_EXTENT_DATA_ENCRYPTED
|
||||
- This will also set FIEMAP_EXTENT_ENCODED
|
||||
The data in this extent has been encrypted by the file system.
|
||||
|
||||
* FIEMAP_EXTENT_NOT_ALIGNED
|
||||
Extent offsets and length are not guaranteed to be block aligned.
|
||||
|
||||
* FIEMAP_EXTENT_DATA_INLINE
|
||||
This will also set FIEMAP_EXTENT_NOT_ALIGNED
|
||||
Data is located within a meta data block.
|
||||
|
||||
* FIEMAP_EXTENT_DATA_TAIL
|
||||
This will also set FIEMAP_EXTENT_NOT_ALIGNED
|
||||
Data is packed into a block with data from other files.
|
||||
|
||||
* FIEMAP_EXTENT_UNWRITTEN
|
||||
Unwritten extent - the extent is allocated but it's data has not been
|
||||
initialized. This indicates the extent's data will be all zero if read
|
||||
through the filesystem but the contents are undefined if read directly from
|
||||
the device.
|
||||
|
||||
* FIEMAP_EXTENT_MERGED
|
||||
This will be set when a file does not support extents, i.e., it uses a block
|
||||
based addressing scheme. Since returning an extent for each block back to
|
||||
userspace would be highly inefficient, the kernel will try to merge most
|
||||
adjacent blocks into 'extents'.
|
||||
|
||||
|
||||
VFS -> File System Implementation
|
||||
---------------------------------
|
||||
|
||||
File systems wishing to support fiemap must implement a ->fiemap callback on
|
||||
their inode_operations structure. The fs ->fiemap call is responsible for
|
||||
defining it's set of supported fiemap flags, and calling a helper function on
|
||||
each discovered extent:
|
||||
|
||||
struct inode_operations {
|
||||
...
|
||||
|
||||
int (*fiemap)(struct inode *, struct fiemap_extent_info *, u64 start,
|
||||
u64 len);
|
||||
|
||||
->fiemap is passed struct fiemap_extent_info which describes the
|
||||
fiemap request:
|
||||
|
||||
struct fiemap_extent_info {
|
||||
unsigned int fi_flags; /* Flags as passed from user */
|
||||
unsigned int fi_extents_mapped; /* Number of mapped extents */
|
||||
unsigned int fi_extents_max; /* Size of fiemap_extent array */
|
||||
struct fiemap_extent *fi_extents_start; /* Start of fiemap_extent array */
|
||||
};
|
||||
|
||||
It is intended that the file system should not need to access any of this
|
||||
structure directly.
|
||||
|
||||
|
||||
Flag checking should be done at the beginning of the ->fiemap callback via the
|
||||
fiemap_check_flags() helper:
|
||||
|
||||
int fiemap_check_flags(struct fiemap_extent_info *fieinfo, u32 fs_flags);
|
||||
|
||||
The struct fieinfo should be passed in as recieved from ioctl_fiemap(). The
|
||||
set of fiemap flags which the fs understands should be passed via fs_flags. If
|
||||
fiemap_check_flags finds invalid user flags, it will place the bad values in
|
||||
fieinfo->fi_flags and return -EBADR. If the file system gets -EBADR, from
|
||||
fiemap_check_flags(), it should immediately exit, returning that error back to
|
||||
ioctl_fiemap().
|
||||
|
||||
|
||||
For each extent in the request range, the file system should call
|
||||
the helper function, fiemap_fill_next_extent():
|
||||
|
||||
int fiemap_fill_next_extent(struct fiemap_extent_info *info, u64 logical,
|
||||
u64 phys, u64 len, u32 flags, u32 dev);
|
||||
|
||||
fiemap_fill_next_extent() will use the passed values to populate the
|
||||
next free extent in the fm_extents array. 'General' extent flags will
|
||||
automatically be set from specific flags on behalf of the calling file
|
||||
system so that the userspace API is not broken.
|
||||
|
||||
fiemap_fill_next_extent() returns 0 on success, and 1 when the
|
||||
user-supplied fm_extents array is full. If an error is encountered
|
||||
while copying the extent to user memory, -EFAULT will be returned.
|
||||
|
|
@ -923,45 +923,44 @@ CPUs.
|
|||
The "procs_blocked" line gives the number of processes currently blocked,
|
||||
waiting for I/O to complete.
|
||||
|
||||
|
||||
1.9 Ext4 file system parameters
|
||||
------------------------------
|
||||
Ext4 file system have one directory per partition under /proc/fs/ext4/
|
||||
# ls /proc/fs/ext4/hdc/
|
||||
group_prealloc max_to_scan mb_groups mb_history min_to_scan order2_req
|
||||
stats stream_req
|
||||
|
||||
mb_groups:
|
||||
This file gives the details of multiblock allocator buddy cache of free blocks
|
||||
Information about mounted ext4 file systems can be found in
|
||||
/proc/fs/ext4. Each mounted filesystem will have a directory in
|
||||
/proc/fs/ext4 based on its device name (i.e., /proc/fs/ext4/hdc or
|
||||
/proc/fs/ext4/dm-0). The files in each per-device directory are shown
|
||||
in Table 1-10, below.
|
||||
|
||||
mb_history:
|
||||
Multiblock allocation history.
|
||||
Table 1-10: Files in /proc/fs/ext4/<devname>
|
||||
..............................................................................
|
||||
File Content
|
||||
mb_groups details of multiblock allocator buddy cache of free blocks
|
||||
mb_history multiblock allocation history
|
||||
stats controls whether the multiblock allocator should start
|
||||
collecting statistics, which are shown during the unmount
|
||||
group_prealloc the multiblock allocator will round up allocation
|
||||
requests to a multiple of this tuning parameter if the
|
||||
stripe size is not set in the ext4 superblock
|
||||
max_to_scan The maximum number of extents the multiblock allocator
|
||||
will search to find the best extent
|
||||
min_to_scan The minimum number of extents the multiblock allocator
|
||||
will search to find the best extent
|
||||
order2_req Tuning parameter which controls the minimum size for
|
||||
requests (as a power of 2) where the buddy cache is
|
||||
used
|
||||
stream_req Files which have fewer blocks than this tunable
|
||||
parameter will have their blocks allocated out of a
|
||||
block group specific preallocation pool, so that small
|
||||
files are packed closely together. Each large file
|
||||
will have its blocks allocated out of its own unique
|
||||
preallocation pool.
|
||||
inode_readahead Tuning parameter which controls the maximum number of
|
||||
inode table blocks that ext4's inode table readahead
|
||||
algorithm will pre-read into the buffer cache
|
||||
..............................................................................
|
||||
|
||||
stats:
|
||||
This file indicate whether the multiblock allocator should start collecting
|
||||
statistics. The statistics are shown during unmount
|
||||
|
||||
group_prealloc:
|
||||
The multiblock allocator normalize the block allocation request to
|
||||
group_prealloc filesystem blocks if we don't have strip value set.
|
||||
The stripe value can be specified at mount time or during mke2fs.
|
||||
|
||||
max_to_scan:
|
||||
How long multiblock allocator can look for a best extent (in found extents)
|
||||
|
||||
min_to_scan:
|
||||
How long multiblock allocator must look for a best extent
|
||||
|
||||
order2_req:
|
||||
Multiblock allocator use 2^N search using buddies only for requests greater
|
||||
than or equal to order2_req. The request size is specfied in file system
|
||||
blocks. A value of 2 indicate only if the requests are greater than or equal
|
||||
to 4 blocks.
|
||||
|
||||
stream_req:
|
||||
Files smaller than stream_req are served by the stream allocator, whose
|
||||
purpose is to pack requests as close each to other as possible to
|
||||
produce smooth I/O traffic. Avalue of 16 indicate that file smaller than 16
|
||||
filesystem block size will use group based preallocation.
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
Summary
|
||||
|
|
@ -2413,6 +2412,8 @@ The following 4 memory types are supported:
|
|||
- (bit 1) anonymous shared memory
|
||||
- (bit 2) file-backed private memory
|
||||
- (bit 3) file-backed shared memory
|
||||
- (bit 4) ELF header pages in file-backed private memory areas (it is
|
||||
effective only if the bit 2 is cleared)
|
||||
|
||||
Note that MMIO pages such as frame buffer are never dumped and vDSO pages
|
||||
are always dumped regardless of the bitmask status.
|
||||
|
|
|
|||
|
|
@ -14,14 +14,14 @@ Description
|
|||
|
||||
This driver implements support for the Analog Devices ADT7473 chip family.
|
||||
|
||||
The LM85 uses the 2-wire interface compatible with the SMBUS 2.0
|
||||
The ADT7473 uses the 2-wire interface compatible with the SMBUS 2.0
|
||||
specification. Using an analog to digital converter it measures three (3)
|
||||
temperatures and two (2) voltages. It has three (3) 16-bit counters for
|
||||
temperatures and two (2) voltages. It has four (4) 16-bit counters for
|
||||
measuring fan speed. There are three (3) PWM outputs that can be used
|
||||
to control fan speed.
|
||||
|
||||
A sophisticated control system for the PWM outputs is designed into the
|
||||
LM85 that allows fan speed to be adjusted automatically based on any of the
|
||||
ADT7473 that allows fan speed to be adjusted automatically based on any of the
|
||||
three temperature sensors. Each PWM output is individually adjustable and
|
||||
programmable. Once configured, the ADT7473 will adjust the PWM outputs in
|
||||
response to the measured temperatures without further host intervention.
|
||||
|
|
@ -46,14 +46,6 @@ from the raw value to get the temperature value.
|
|||
The Analog Devices datasheet is very detailed and describes a procedure for
|
||||
determining an optimal configuration for the automatic PWM control.
|
||||
|
||||
Hardware Configurations
|
||||
-----------------------
|
||||
|
||||
The ADT7473 chips have an optional SMBALERT output that can be used to
|
||||
signal the chipset in case a limit is exceeded or the temperature sensors
|
||||
fail. Individual sensor interrupts can be masked so they won't trigger
|
||||
SMBALERT. The SMBALERT output if configured replaces the PWM2 function.
|
||||
|
||||
Configuration Notes
|
||||
-------------------
|
||||
|
||||
|
|
@ -61,8 +53,8 @@ Besides standard interfaces driver adds the following:
|
|||
|
||||
* PWM Control
|
||||
|
||||
* pwm#_auto_point1_pwm and pwm#_auto_point1_temp and
|
||||
* pwm#_auto_point2_pwm and pwm#_auto_point2_temp -
|
||||
* pwm#_auto_point1_pwm and temp#_auto_point1_temp and
|
||||
* pwm#_auto_point2_pwm and temp#_auto_point2_temp -
|
||||
|
||||
point1: Set the pwm speed at a lower temperature bound.
|
||||
point2: Set the pwm speed at a higher temperature bound.
|
||||
|
|
|
|||
|
|
@ -329,6 +329,10 @@ power[1-*]_average Average power use
|
|||
Unit: microWatt
|
||||
RO
|
||||
|
||||
power[1-*]_average_interval Power use averaging interval
|
||||
Unit: milliseconds
|
||||
RW
|
||||
|
||||
power[1-*]_average_highest Historical average maximum power use
|
||||
Unit: microWatt
|
||||
RO
|
||||
|
|
@ -353,6 +357,14 @@ power[1-*]_reset_history Reset input_highest, input_lowest,
|
|||
average_highest and average_lowest.
|
||||
WO
|
||||
|
||||
**********
|
||||
* Energy *
|
||||
**********
|
||||
|
||||
energy[1-*]_input Cumulative energy use
|
||||
Unit: microJoule
|
||||
RO
|
||||
|
||||
**********
|
||||
* Alarms *
|
||||
**********
|
||||
|
|
|
|||
|
|
@ -271,14 +271,14 @@ CDROMCLOSETRAY pendant of CDROMEJECT
|
|||
|
||||
usage:
|
||||
|
||||
ioctl(fd, CDROMEJECT, 0);
|
||||
ioctl(fd, CDROMCLOSETRAY, 0);
|
||||
|
||||
inputs: none
|
||||
|
||||
outputs: none
|
||||
|
||||
error returns:
|
||||
ENOSYS cd drive not capable of ejecting
|
||||
ENOSYS cd drive not capable of closing the tray
|
||||
EBUSY other processes are accessing drive, or door is locked
|
||||
|
||||
notes:
|
||||
|
|
|
|||
|
|
@ -168,10 +168,10 @@ if ($#ARGV < 0) {
|
|||
mkdir $ARGV[0],0777;
|
||||
$state = 0;
|
||||
while (<STDIN>) {
|
||||
if (/^\.TH \"[^\"]*\" 4 \"([^\"]*)\"/) {
|
||||
if (/^\.TH \"[^\"]*\" 9 \"([^\"]*)\"/) {
|
||||
if ($state == 1) { close OUT }
|
||||
$state = 1;
|
||||
$fn = "$ARGV[0]/$1.4";
|
||||
$fn = "$ARGV[0]/$1.9";
|
||||
print STDERR "Creating $fn\n";
|
||||
open OUT, ">$fn" or die "can't open $fn: $!\n";
|
||||
print OUT $_;
|
||||
|
|
|
|||
|
|
@ -284,6 +284,11 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
isolate - enable device isolation (each device, as far
|
||||
as possible, will get its own protection
|
||||
domain)
|
||||
fullflush - enable flushing of IO/TLB entries when
|
||||
they are unmapped. Otherwise they are
|
||||
flushed before they will be reused, which
|
||||
is a lot of faster
|
||||
|
||||
amd_iommu_size= [HW,X86-64]
|
||||
Define the size of the aperture for the AMD IOMMU
|
||||
driver. Possible values are:
|
||||
|
|
@ -463,12 +468,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
Range: 0 - 8192
|
||||
Default: 64
|
||||
|
||||
disable_8254_timer
|
||||
enable_8254_timer
|
||||
[IA32/X86_64] Disable/Enable interrupt 0 timer routing
|
||||
over the 8254 in addition to over the IO-APIC. The
|
||||
kernel tries to set a sensible default.
|
||||
|
||||
hpet= [X86-32,HPET] option to control HPET usage
|
||||
Format: { enable (default) | disable | force }
|
||||
disable: disable HPET and use PIT instead
|
||||
|
|
@ -1020,6 +1019,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
(only serial suported for now)
|
||||
Format: <serial_device>[,baud]
|
||||
|
||||
kmac= [MIPS] korina ethernet MAC address.
|
||||
Configure the RouterBoard 532 series on-chip
|
||||
Ethernet adapter MAC address.
|
||||
|
||||
l2cr= [PPC]
|
||||
|
||||
l3cr= [PPC]
|
||||
|
|
@ -1448,6 +1451,12 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
|
||||
nolapic_timer [X86-32,APIC] Do not use the local APIC timer.
|
||||
|
||||
nox2apic [X86-64,APIC] Do not enable x2APIC mode.
|
||||
|
||||
x2apic_phys [X86-64,APIC] Use x2apic physical mode instead of
|
||||
default x2apic cluster mode on platforms
|
||||
supporting x2apic.
|
||||
|
||||
noltlbs [PPC] Do not use large page/tlb entries for kernel
|
||||
lowmem mapping on PPC40x.
|
||||
|
||||
|
|
@ -1905,6 +1914,12 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
shapers= [NET]
|
||||
Maximal number of shapers.
|
||||
|
||||
show_msr= [x86] show boot-time MSR settings
|
||||
Format: { <integer> }
|
||||
Show boot-time (BIOS-initialized) MSR settings.
|
||||
The parameter means the number of CPUs to show,
|
||||
for example 1 means boot CPU only.
|
||||
|
||||
sim710= [SCSI,HW]
|
||||
See header of drivers/scsi/sim710.c.
|
||||
|
||||
|
|
|
|||
46
Documentation/networking/LICENSE.qlge
Normal file
46
Documentation/networking/LICENSE.qlge
Normal file
|
|
@ -0,0 +1,46 @@
|
|||
Copyright (c) 2003-2008 QLogic Corporation
|
||||
QLogic Linux Networking HBA Driver
|
||||
|
||||
This program includes a device driver for Linux 2.6 that may be
|
||||
distributed with QLogic hardware specific firmware binary file.
|
||||
You may modify and redistribute the device driver code under the
|
||||
GNU General Public License as published by the Free Software
|
||||
Foundation (version 2 or a later version).
|
||||
|
||||
You may redistribute the hardware specific firmware binary file
|
||||
under the following terms:
|
||||
|
||||
1. Redistribution of source code (only if applicable),
|
||||
must retain the above copyright notice, this list of
|
||||
conditions and the following disclaimer.
|
||||
|
||||
2. Redistribution in binary form must reproduce the above
|
||||
copyright notice, this list of conditions and the
|
||||
following disclaimer in the documentation and/or other
|
||||
materials provided with the distribution.
|
||||
|
||||
3. The name of QLogic Corporation may not be used to
|
||||
endorse or promote products derived from this software
|
||||
without specific prior written permission
|
||||
|
||||
REGARDLESS OF WHAT LICENSING MECHANISM IS USED OR APPLICABLE,
|
||||
THIS PROGRAM IS PROVIDED BY QLOGIC CORPORATION "AS IS'' AND ANY
|
||||
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
||||
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
|
||||
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR
|
||||
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
|
||||
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
|
||||
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
||||
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
|
||||
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
|
||||
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
||||
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
||||
POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
USER ACKNOWLEDGES AND AGREES THAT USE OF THIS PROGRAM WILL NOT
|
||||
CREATE OR GIVE GROUNDS FOR A LICENSE BY IMPLICATION, ESTOPPEL, OR
|
||||
OTHERWISE IN ANY INTELLECTUAL PROPERTY RIGHTS (PATENT, COPYRIGHT,
|
||||
TRADE SECRET, MASK WORK, OR OTHER PROPRIETARY RIGHT) EMBODIED IN
|
||||
ANY OTHER QLOGIC HARDWARE OR SOFTWARE EITHER SOLELY OR IN
|
||||
COMBINATION WITH THIS PROGRAM.
|
||||
|
||||
|
|
@ -35,8 +35,9 @@ This file contains
|
|||
6.1 general settings
|
||||
6.2 local loopback of sent frames
|
||||
6.3 CAN controller hardware filters
|
||||
6.4 currently supported CAN hardware
|
||||
6.5 todo
|
||||
6.4 The virtual CAN driver (vcan)
|
||||
6.5 currently supported CAN hardware
|
||||
6.6 todo
|
||||
|
||||
7 Credits
|
||||
|
||||
|
|
@ -584,7 +585,42 @@ solution for a couple of reasons:
|
|||
@133MHz with four SJA1000 CAN controllers from 2002 under heavy bus
|
||||
load without any problems ...
|
||||
|
||||
6.4 currently supported CAN hardware (September 2007)
|
||||
6.4 The virtual CAN driver (vcan)
|
||||
|
||||
Similar to the network loopback devices, vcan offers a virtual local
|
||||
CAN interface. A full qualified address on CAN consists of
|
||||
|
||||
- a unique CAN Identifier (CAN ID)
|
||||
- the CAN bus this CAN ID is transmitted on (e.g. can0)
|
||||
|
||||
so in common use cases more than one virtual CAN interface is needed.
|
||||
|
||||
The virtual CAN interfaces allow the transmission and reception of CAN
|
||||
frames without real CAN controller hardware. Virtual CAN network
|
||||
devices are usually named 'vcanX', like vcan0 vcan1 vcan2 ...
|
||||
When compiled as a module the virtual CAN driver module is called vcan.ko
|
||||
|
||||
Since Linux Kernel version 2.6.24 the vcan driver supports the Kernel
|
||||
netlink interface to create vcan network devices. The creation and
|
||||
removal of vcan network devices can be managed with the ip(8) tool:
|
||||
|
||||
- Create a virtual CAN network interface:
|
||||
ip link add type vcan
|
||||
|
||||
- Create a virtual CAN network interface with a specific name 'vcan42':
|
||||
ip link add dev vcan42 type vcan
|
||||
|
||||
- Remove a (virtual CAN) network interface 'vcan42':
|
||||
ip link del vcan42
|
||||
|
||||
The tool 'vcan' from the SocketCAN SVN repository on BerliOS is obsolete.
|
||||
|
||||
Virtual CAN network device creation in older Kernels:
|
||||
In Linux Kernel versions < 2.6.24 the vcan driver creates 4 vcan
|
||||
netdevices at module load time by default. This value can be changed
|
||||
with the module parameter 'numdev'. E.g. 'modprobe vcan numdev=8'
|
||||
|
||||
6.5 currently supported CAN hardware
|
||||
|
||||
On the project website http://developer.berlios.de/projects/socketcan
|
||||
there are different drivers available:
|
||||
|
|
@ -603,7 +639,7 @@ solution for a couple of reasons:
|
|||
|
||||
Please check the Mailing Lists on the berlios OSS project website.
|
||||
|
||||
6.5 todo (September 2007)
|
||||
6.6 todo
|
||||
|
||||
The configuration interface for CAN network drivers is still an open
|
||||
issue that has not been finalized in the socketcan project. Also the
|
||||
|
|
|
|||
|
|
@ -24,4 +24,56 @@ netif_{start|stop|wake}_subqueue() functions to manage each queue while the
|
|||
device is still operational. netdev->queue_lock is still used when the device
|
||||
comes online or when it's completely shut down (unregister_netdev(), etc.).
|
||||
|
||||
Author: Peter P. Waskiewicz Jr. <[email protected]>
|
||||
|
||||
Section 2: Qdisc support for multiqueue devices
|
||||
|
||||
-----------------------------------------------
|
||||
|
||||
Currently two qdiscs are optimized for multiqueue devices. The first is the
|
||||
default pfifo_fast qdisc. This qdisc supports one qdisc per hardware queue.
|
||||
A new round-robin qdisc, sch_multiq also supports multiple hardware queues. The
|
||||
qdisc is responsible for classifying the skb's and then directing the skb's to
|
||||
bands and queues based on the value in skb->queue_mapping. Use this field in
|
||||
the base driver to determine which queue to send the skb to.
|
||||
|
||||
sch_multiq has been added for hardware that wishes to avoid head-of-line
|
||||
blocking. It will cycle though the bands and verify that the hardware queue
|
||||
associated with the band is not stopped prior to dequeuing a packet.
|
||||
|
||||
On qdisc load, the number of bands is based on the number of queues on the
|
||||
hardware. Once the association is made, any skb with skb->queue_mapping set,
|
||||
will be queued to the band associated with the hardware queue.
|
||||
|
||||
|
||||
Section 3: Brief howto using MULTIQ for multiqueue devices
|
||||
---------------------------------------------------------------
|
||||
|
||||
The userspace command 'tc,' part of the iproute2 package, is used to configure
|
||||
qdiscs. To add the MULTIQ qdisc to your network device, assuming the device
|
||||
is called eth0, run the following command:
|
||||
|
||||
# tc qdisc add dev eth0 root handle 1: multiq
|
||||
|
||||
The qdisc will allocate the number of bands to equal the number of queues that
|
||||
the device reports, and bring the qdisc online. Assuming eth0 has 4 Tx
|
||||
queues, the band mapping would look like:
|
||||
|
||||
band 0 => queue 0
|
||||
band 1 => queue 1
|
||||
band 2 => queue 2
|
||||
band 3 => queue 3
|
||||
|
||||
Traffic will begin flowing through each queue based on either the simple_tx_hash
|
||||
function or based on netdev->select_queue() if you have it defined.
|
||||
|
||||
The behavior of tc filters remains the same. However a new tc action,
|
||||
skbedit, has been added. Assuming you wanted to route all traffic to a
|
||||
specific host, for example 192.168.0.3, through a specific queue you could use
|
||||
this action and establish a filter such as:
|
||||
|
||||
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \
|
||||
match ip dst 192.168.0.3 \
|
||||
action skbedit queue_mapping 3
|
||||
|
||||
Author: Alexander Duyck <[email protected]>
|
||||
Original Author: Peter P. Waskiewicz Jr. <[email protected]>
|
||||
|
|
|
|||
175
Documentation/networking/phonet.txt
Normal file
175
Documentation/networking/phonet.txt
Normal file
|
|
@ -0,0 +1,175 @@
|
|||
Linux Phonet protocol family
|
||||
============================
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
Phonet is a packet protocol used by Nokia cellular modems for both IPC
|
||||
and RPC. With the Linux Phonet socket family, Linux host processes can
|
||||
receive and send messages from/to the modem, or any other external
|
||||
device attached to the modem. The modem takes care of routing.
|
||||
|
||||
Phonet packets can be exchanged through various hardware connections
|
||||
depending on the device, such as:
|
||||
- USB with the CDC Phonet interface,
|
||||
- infrared,
|
||||
- Bluetooth,
|
||||
- an RS232 serial port (with a dedicated "FBUS" line discipline),
|
||||
- the SSI bus with some TI OMAP processors.
|
||||
|
||||
|
||||
Packets format
|
||||
--------------
|
||||
|
||||
Phonet packets have a common header as follows:
|
||||
|
||||
struct phonethdr {
|
||||
uint8_t pn_media; /* Media type (link-layer identifier) */
|
||||
uint8_t pn_rdev; /* Receiver device ID */
|
||||
uint8_t pn_sdev; /* Sender device ID */
|
||||
uint8_t pn_res; /* Resource ID or function */
|
||||
uint16_t pn_length; /* Big-endian message byte length (minus 6) */
|
||||
uint8_t pn_robj; /* Receiver object ID */
|
||||
uint8_t pn_sobj; /* Sender object ID */
|
||||
};
|
||||
|
||||
On Linux, the link-layer header includes the pn_media byte (see below).
|
||||
The next 7 bytes are part of the network-layer header.
|
||||
|
||||
The device ID is split: the 6 higher-order bits consitute the device
|
||||
address, while the 2 lower-order bits are used for multiplexing, as are
|
||||
the 8-bit object identifiers. As such, Phonet can be considered as a
|
||||
network layer with 6 bits of address space and 10 bits for transport
|
||||
protocol (much like port numbers in IP world).
|
||||
|
||||
The modem always has address number zero. All other device have a their
|
||||
own 6-bit address.
|
||||
|
||||
|
||||
Link layer
|
||||
----------
|
||||
|
||||
Phonet links are always point-to-point links. The link layer header
|
||||
consists of a single Phonet media type byte. It uniquely identifies the
|
||||
link through which the packet is transmitted, from the modem's
|
||||
perspective. Each Phonet network device shall prepend and set the media
|
||||
type byte as appropriate. For convenience, a common phonet_header_ops
|
||||
link-layer header operations structure is provided. It sets the
|
||||
media type according to the network device hardware address.
|
||||
|
||||
Linux Phonet network interfaces support a dedicated link layer packets
|
||||
type (ETH_P_PHONET) which is out of the Ethernet type range. They can
|
||||
only send and receive Phonet packets.
|
||||
|
||||
The virtual TUN tunnel device driver can also be used for Phonet. This
|
||||
requires IFF_TUN mode, _without_ the IFF_NO_PI flag. In this case,
|
||||
there is no link-layer header, so there is no Phonet media type byte.
|
||||
|
||||
Note that Phonet interfaces are not allowed to re-order packets, so
|
||||
only the (default) Linux FIFO qdisc should be used with them.
|
||||
|
||||
|
||||
Network layer
|
||||
-------------
|
||||
|
||||
The Phonet socket address family maps the Phonet packet header:
|
||||
|
||||
struct sockaddr_pn {
|
||||
sa_family_t spn_family; /* AF_PHONET */
|
||||
uint8_t spn_obj; /* Object ID */
|
||||
uint8_t spn_dev; /* Device ID */
|
||||
uint8_t spn_resource; /* Resource or function */
|
||||
uint8_t spn_zero[...]; /* Padding */
|
||||
};
|
||||
|
||||
The resource field is only used when sending and receiving;
|
||||
It is ignored by bind() and getsockname().
|
||||
|
||||
|
||||
Low-level datagram protocol
|
||||
---------------------------
|
||||
|
||||
Applications can send Phonet messages using the Phonet datagram socket
|
||||
protocol from the PF_PHONET family. Each socket is bound to one of the
|
||||
2^10 object IDs available, and can send and receive packets with any
|
||||
other peer.
|
||||
|
||||
struct sockaddr_pn addr = { .spn_family = AF_PHONET, };
|
||||
ssize_t len;
|
||||
socklen_t addrlen = sizeof(addr);
|
||||
int fd;
|
||||
|
||||
fd = socket(PF_PHONET, SOCK_DGRAM, 0);
|
||||
bind(fd, (struct sockaddr *)&addr, sizeof(addr));
|
||||
/* ... */
|
||||
|
||||
sendto(fd, msg, msglen, 0, (struct sockaddr *)&addr, sizeof(addr));
|
||||
len = recvfrom(fd, buf, sizeof(buf), 0,
|
||||
(struct sockaddr *)&addr, &addrlen);
|
||||
|
||||
This protocol follows the SOCK_DGRAM connection-less semantics.
|
||||
However, connect() and getpeername() are not supported, as they did
|
||||
not seem useful with Phonet usages (could be added easily).
|
||||
|
||||
|
||||
Phonet Pipe protocol
|
||||
--------------------
|
||||
|
||||
The Phonet Pipe protocol is a simple sequenced packets protocol
|
||||
with end-to-end congestion control. It uses the passive listening
|
||||
socket paradigm. The listening socket is bound to an unique free object
|
||||
ID. Each listening socket can handle up to 255 simultaneous
|
||||
connections, one per accept()'d socket.
|
||||
|
||||
int lfd, cfd;
|
||||
|
||||
lfd = socket(PF_PHONET, SOCK_SEQPACKET, PN_PROTO_PIPE);
|
||||
listen (lfd, INT_MAX);
|
||||
|
||||
/* ... */
|
||||
cfd = accept(lfd, NULL, NULL);
|
||||
for (;;)
|
||||
{
|
||||
char buf[...];
|
||||
ssize_t len = read(cfd, buf, sizeof(buf));
|
||||
|
||||
/* ... */
|
||||
|
||||
write(cfd, msg, msglen);
|
||||
}
|
||||
|
||||
Connections are established between two endpoints by a "third party"
|
||||
application. This means that both endpoints are passive; so connect()
|
||||
is not possible.
|
||||
|
||||
WARNING:
|
||||
When polling a connected pipe socket for writability, there is an
|
||||
intrinsic race condition whereby writability might be lost between the
|
||||
polling and the writing system calls. In this case, the socket will
|
||||
block until write because possible again, unless non-blocking mode
|
||||
becomes enabled.
|
||||
|
||||
|
||||
The pipe protocol provides two socket options at the SOL_PNPIPE level:
|
||||
|
||||
PNPIPE_ENCAP accepts one integer value (int) of:
|
||||
|
||||
PNPIPE_ENCAP_NONE: The socket operates normally (default).
|
||||
|
||||
PNPIPE_ENCAP_IP: The socket is used as a backend for a virtual IP
|
||||
interface. This requires CAP_NET_ADMIN capability. GPRS data
|
||||
support on Nokia modems can use this. Note that the socket cannot
|
||||
be reliably poll()'d or read() from while in this mode.
|
||||
|
||||
PNPIPE_IFINDEX is a read-only integer value. It contains the
|
||||
interface index of the network interface created by PNPIPE_ENCAP,
|
||||
or zero if encapsulation is off.
|
||||
|
||||
|
||||
Authors
|
||||
-------
|
||||
|
||||
Linux Phonet was initially written by Sakari Ailus.
|
||||
Other contributors include Mikä Liljeberg, Andras Domokos,
|
||||
Carlos Chinea and Rémi Denis-Courmont.
|
||||
Copyright (C) 2008 Nokia Corporation.
|
||||
194
Documentation/networking/regulatory.txt
Normal file
194
Documentation/networking/regulatory.txt
Normal file
|
|
@ -0,0 +1,194 @@
|
|||
Linux wireless regulatory documentation
|
||||
---------------------------------------
|
||||
|
||||
This document gives a brief review over how the Linux wireless
|
||||
regulatory infrastructure works.
|
||||
|
||||
More up to date information can be obtained at the project's web page:
|
||||
|
||||
http://wireless.kernel.org/en/developers/Regulatory
|
||||
|
||||
Keeping regulatory domains in userspace
|
||||
---------------------------------------
|
||||
|
||||
Due to the dynamic nature of regulatory domains we keep them
|
||||
in userspace and provide a framework for userspace to upload
|
||||
to the kernel one regulatory domain to be used as the central
|
||||
core regulatory domain all wireless devices should adhere to.
|
||||
|
||||
How to get regulatory domains to the kernel
|
||||
-------------------------------------------
|
||||
|
||||
Userspace gets a regulatory domain in the kernel by having
|
||||
a userspace agent build it and send it via nl80211. Only
|
||||
expected regulatory domains will be respected by the kernel.
|
||||
|
||||
A currently available userspace agent which can accomplish this
|
||||
is CRDA - central regulatory domain agent. Its documented here:
|
||||
|
||||
http://wireless.kernel.org/en/developers/Regulatory/CRDA
|
||||
|
||||
Essentially the kernel will send a udev event when it knows
|
||||
it needs a new regulatory domain. A udev rule can be put in place
|
||||
to trigger crda to send the respective regulatory domain for a
|
||||
specific ISO/IEC 3166 alpha2.
|
||||
|
||||
Below is an example udev rule which can be used:
|
||||
|
||||
# Example file, should be put in /etc/udev/rules.d/regulatory.rules
|
||||
KERNEL=="regulatory*", ACTION=="change", SUBSYSTEM=="platform", RUN+="/sbin/crda"
|
||||
|
||||
The alpha2 is passed as an environment variable under the variable COUNTRY.
|
||||
|
||||
Who asks for regulatory domains?
|
||||
--------------------------------
|
||||
|
||||
* Users
|
||||
|
||||
Users can use iw:
|
||||
|
||||
http://wireless.kernel.org/en/users/Documentation/iw
|
||||
|
||||
An example:
|
||||
|
||||
# set regulatory domain to "Costa Rica"
|
||||
iw reg set CR
|
||||
|
||||
This will request the kernel to set the regulatory domain to
|
||||
the specificied alpha2. The kernel in turn will then ask userspace
|
||||
to provide a regulatory domain for the alpha2 specified by the user
|
||||
by sending a uevent.
|
||||
|
||||
* Wireless subsystems for Country Information elements
|
||||
|
||||
The kernel will send a uevent to inform userspace a new
|
||||
regulatory domain is required. More on this to be added
|
||||
as its integration is added.
|
||||
|
||||
* Drivers
|
||||
|
||||
If drivers determine they need a specific regulatory domain
|
||||
set they can inform the wireless core using regulatory_hint().
|
||||
They have two options -- they either provide an alpha2 so that
|
||||
crda can provide back a regulatory domain for that country or
|
||||
they can build their own regulatory domain based on internal
|
||||
custom knowledge so the wireless core can respect it.
|
||||
|
||||
*Most* drivers will rely on the first mechanism of providing a
|
||||
regulatory hint with an alpha2. For these drivers there is an additional
|
||||
check that can be used to ensure compliance based on custom EEPROM
|
||||
regulatory data. This additional check can be used by drivers by
|
||||
registering on its struct wiphy a reg_notifier() callback. This notifier
|
||||
is called when the core's regulatory domain has been changed. The driver
|
||||
can use this to review the changes made and also review who made them
|
||||
(driver, user, country IE) and determine what to allow based on its
|
||||
internal EEPROM data. Devices drivers wishing to be capable of world
|
||||
roaming should use this callback. More on world roaming will be
|
||||
added to this document when its support is enabled.
|
||||
|
||||
Device drivers who provide their own built regulatory domain
|
||||
do not need a callback as the channels registered by them are
|
||||
the only ones that will be allowed and therefore *additional*
|
||||
cannels cannot be enabled.
|
||||
|
||||
Example code - drivers hinting an alpha2:
|
||||
------------------------------------------
|
||||
|
||||
This example comes from the zd1211rw device driver. You can start
|
||||
by having a mapping of your device's EEPROM country/regulatory
|
||||
domain value to to a specific alpha2 as follows:
|
||||
|
||||
static struct zd_reg_alpha2_map reg_alpha2_map[] = {
|
||||
{ ZD_REGDOMAIN_FCC, "US" },
|
||||
{ ZD_REGDOMAIN_IC, "CA" },
|
||||
{ ZD_REGDOMAIN_ETSI, "DE" }, /* Generic ETSI, use most restrictive */
|
||||
{ ZD_REGDOMAIN_JAPAN, "JP" },
|
||||
{ ZD_REGDOMAIN_JAPAN_ADD, "JP" },
|
||||
{ ZD_REGDOMAIN_SPAIN, "ES" },
|
||||
{ ZD_REGDOMAIN_FRANCE, "FR" },
|
||||
|
||||
Then you can define a routine to map your read EEPROM value to an alpha2,
|
||||
as follows:
|
||||
|
||||
static int zd_reg2alpha2(u8 regdomain, char *alpha2)
|
||||
{
|
||||
unsigned int i;
|
||||
struct zd_reg_alpha2_map *reg_map;
|
||||
for (i = 0; i < ARRAY_SIZE(reg_alpha2_map); i++) {
|
||||
reg_map = ®_alpha2_map[i];
|
||||
if (regdomain == reg_map->reg) {
|
||||
alpha2[0] = reg_map->alpha2[0];
|
||||
alpha2[1] = reg_map->alpha2[1];
|
||||
return 0;
|
||||
}
|
||||
}
|
||||
return 1;
|
||||
}
|
||||
|
||||
Lastly, you can then hint to the core of your discovered alpha2, if a match
|
||||
was found. You need to do this after you have registered your wiphy. You
|
||||
are expected to do this during initialization.
|
||||
|
||||
r = zd_reg2alpha2(mac->regdomain, alpha2);
|
||||
if (!r)
|
||||
regulatory_hint(hw->wiphy, alpha2, NULL);
|
||||
|
||||
Example code - drivers providing a built in regulatory domain:
|
||||
--------------------------------------------------------------
|
||||
|
||||
If you have regulatory information you can obtain from your
|
||||
driver and you *need* to use this we let you build a regulatory domain
|
||||
structure and pass it to the wireless core. To do this you should
|
||||
kmalloc() a structure big enough to hold your regulatory domain
|
||||
structure and you should then fill it with your data. Finally you simply
|
||||
call regulatory_hint() with the regulatory domain structure in it.
|
||||
|
||||
Bellow is a simple example, with a regulatory domain cached using the stack.
|
||||
Your implementation may vary (read EEPROM cache instead, for example).
|
||||
|
||||
Example cache of some regulatory domain
|
||||
|
||||
struct ieee80211_regdomain mydriver_jp_regdom = {
|
||||
.n_reg_rules = 3,
|
||||
.alpha2 = "JP",
|
||||
//.alpha2 = "99", /* If I have no alpha2 to map it to */
|
||||
.reg_rules = {
|
||||
/* IEEE 802.11b/g, channels 1..14 */
|
||||
REG_RULE(2412-20, 2484+20, 40, 6, 20, 0),
|
||||
/* IEEE 802.11a, channels 34..48 */
|
||||
REG_RULE(5170-20, 5240+20, 40, 6, 20,
|
||||
NL80211_RRF_PASSIVE_SCAN),
|
||||
/* IEEE 802.11a, channels 52..64 */
|
||||
REG_RULE(5260-20, 5320+20, 40, 6, 20,
|
||||
NL80211_RRF_NO_IBSS |
|
||||
NL80211_RRF_DFS),
|
||||
}
|
||||
};
|
||||
|
||||
Then in some part of your code after your wiphy has been registered:
|
||||
|
||||
int r;
|
||||
struct ieee80211_regdomain *rd;
|
||||
int size_of_regd;
|
||||
int num_rules = mydriver_jp_regdom.n_reg_rules;
|
||||
unsigned int i;
|
||||
|
||||
size_of_regd = sizeof(struct ieee80211_regdomain) +
|
||||
(num_rules * sizeof(struct ieee80211_reg_rule));
|
||||
|
||||
rd = kzalloc(size_of_regd, GFP_KERNEL);
|
||||
if (!rd)
|
||||
return -ENOMEM;
|
||||
|
||||
memcpy(rd, &mydriver_jp_regdom, sizeof(struct ieee80211_regdomain));
|
||||
|
||||
for (i=0; i < num_rules; i++) {
|
||||
memcpy(&rd->reg_rules[i], &mydriver_jp_regdom.reg_rules[i],
|
||||
sizeof(struct ieee80211_reg_rule));
|
||||
}
|
||||
r = regulatory_hint(hw->wiphy, NULL, rd);
|
||||
if (r) {
|
||||
kfree(rd);
|
||||
return r;
|
||||
}
|
||||
|
||||
85
Documentation/networking/tproxy.txt
Normal file
85
Documentation/networking/tproxy.txt
Normal file
|
|
@ -0,0 +1,85 @@
|
|||
Transparent proxy support
|
||||
=========================
|
||||
|
||||
This feature adds Linux 2.2-like transparent proxy support to current kernels.
|
||||
To use it, enable NETFILTER_TPROXY, the socket match and the TPROXY target in
|
||||
your kernel config. You will need policy routing too, so be sure to enable that
|
||||
as well.
|
||||
|
||||
|
||||
1. Making non-local sockets work
|
||||
================================
|
||||
|
||||
The idea is that you identify packets with destination address matching a local
|
||||
socket on your box, set the packet mark to a certain value, and then match on that
|
||||
value using policy routing to have those packets delivered locally:
|
||||
|
||||
# iptables -t mangle -N DIVERT
|
||||
# iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
|
||||
# iptables -t mangle -A DIVERT -j MARK --set-mark 1
|
||||
# iptables -t mangle -A DIVERT -j ACCEPT
|
||||
|
||||
# ip rule add fwmark 1 lookup 100
|
||||
# ip route add local 0.0.0.0/0 dev lo table 100
|
||||
|
||||
Because of certain restrictions in the IPv4 routing output code you'll have to
|
||||
modify your application to allow it to send datagrams _from_ non-local IP
|
||||
addresses. All you have to do is enable the (SOL_IP, IP_TRANSPARENT) socket
|
||||
option before calling bind:
|
||||
|
||||
fd = socket(AF_INET, SOCK_STREAM, 0);
|
||||
/* - 8< -*/
|
||||
int value = 1;
|
||||
setsockopt(fd, SOL_IP, IP_TRANSPARENT, &value, sizeof(value));
|
||||
/* - 8< -*/
|
||||
name.sin_family = AF_INET;
|
||||
name.sin_port = htons(0xCAFE);
|
||||
name.sin_addr.s_addr = htonl(0xDEADBEEF);
|
||||
bind(fd, &name, sizeof(name));
|
||||
|
||||
A trivial patch for netcat is available here:
|
||||
http://people.netfilter.org/hidden/tproxy/netcat-ip_transparent-support.patch
|
||||
|
||||
|
||||
2. Redirecting traffic
|
||||
======================
|
||||
|
||||
Transparent proxying often involves "intercepting" traffic on a router. This is
|
||||
usually done with the iptables REDIRECT target; however, there are serious
|
||||
limitations of that method. One of the major issues is that it actually
|
||||
modifies the packets to change the destination address -- which might not be
|
||||
acceptable in certain situations. (Think of proxying UDP for example: you won't
|
||||
be able to find out the original destination address. Even in case of TCP
|
||||
getting the original destination address is racy.)
|
||||
|
||||
The 'TPROXY' target provides similar functionality without relying on NAT. Simply
|
||||
add rules like this to the iptables ruleset above:
|
||||
|
||||
# iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY \
|
||||
--tproxy-mark 0x1/0x1 --on-port 50080
|
||||
|
||||
Note that for this to work you'll have to modify the proxy to enable (SOL_IP,
|
||||
IP_TRANSPARENT) for the listening socket.
|
||||
|
||||
|
||||
3. Iptables extensions
|
||||
======================
|
||||
|
||||
To use tproxy you'll need to have the 'socket' and 'TPROXY' modules
|
||||
compiled for iptables. A patched version of iptables is available
|
||||
here: http://git.balabit.hu/?p=bazsi/iptables-tproxy.git
|
||||
|
||||
|
||||
4. Application support
|
||||
======================
|
||||
|
||||
4.1. Squid
|
||||
----------
|
||||
|
||||
Squid 3.HEAD has support built-in. To use it, pass
|
||||
'--enable-linux-netfilter' to configure and set the 'tproxy' option on
|
||||
the HTTP listener you redirect traffic to with the TPROXY iptables
|
||||
target.
|
||||
|
||||
For more information please consult the following page on the Squid
|
||||
wiki: http://wiki.squid-cache.org/Features/Tproxy4
|
||||
|
|
@ -341,6 +341,8 @@ key that does nothing by itself, as well as any hot key that is type-specific
|
|||
3.1 Guidelines for wireless device drivers
|
||||
------------------------------------------
|
||||
|
||||
(in this text, rfkill->foo means the foo field of struct rfkill).
|
||||
|
||||
1. Each independent transmitter in a wireless device (usually there is only one
|
||||
transmitter per device) should have a SINGLE rfkill class attached to it.
|
||||
|
||||
|
|
@ -363,10 +365,32 @@ This rule exists because users of the rfkill subsystem expect to get (and set,
|
|||
when possible) the overall transmitter rfkill state, not of a particular rfkill
|
||||
line.
|
||||
|
||||
5. During suspend, the rfkill class will attempt to soft-block the radio
|
||||
through a call to rfkill->toggle_radio, and will try to restore its previous
|
||||
state during resume. After a rfkill class is suspended, it will *not* call
|
||||
rfkill->toggle_radio until it is resumed.
|
||||
5. The wireless device driver MUST NOT leave the transmitter enabled during
|
||||
suspend and hibernation unless:
|
||||
|
||||
5.1. The transmitter has to be enabled for some sort of functionality
|
||||
like wake-on-wireless-packet or autonomous packed forwarding in a mesh
|
||||
network, and that functionality is enabled for this suspend/hibernation
|
||||
cycle.
|
||||
|
||||
AND
|
||||
|
||||
5.2. The device was not on a user-requested BLOCKED state before
|
||||
the suspend (i.e. the driver must NOT unblock a device, not even
|
||||
to support wake-on-wireless-packet or remain in the mesh).
|
||||
|
||||
In other words, there is absolutely no allowed scenario where a driver can
|
||||
automatically take action to unblock a rfkill controller (obviously, this deals
|
||||
with scenarios where soft-blocking or both soft and hard blocking is happening.
|
||||
Scenarios where hardware rfkill lines are the only ones blocking the
|
||||
transmitter are outside of this rule, since the wireless device driver does not
|
||||
control its input hardware rfkill lines in the first place).
|
||||
|
||||
6. During resume, rfkill will try to restore its previous state.
|
||||
|
||||
7. After a rfkill class is suspended, it will *not* call rfkill->toggle_radio
|
||||
until it is resumed.
|
||||
|
||||
|
||||
Example of a WLAN wireless driver connected to the rfkill subsystem:
|
||||
--------------------------------------------------------------------
|
||||
|
|
|
|||
|
|
@ -70,13 +70,19 @@ Command line parameters
|
|||
|
||||
Note: While already known devices can be added to the list of devices to be
|
||||
ignored, there will be no effect on then. However, if such a device
|
||||
disappears and then reappears, it will then be ignored.
|
||||
disappears and then reappears, it will then be ignored. To make
|
||||
known devices go away, you need the "purge" command (see below).
|
||||
|
||||
For example,
|
||||
"echo add 0.0.a000-0.0.accc, 0.0.af00-0.0.afff > /proc/cio_ignore"
|
||||
will add 0.0.a000-0.0.accc and 0.0.af00-0.0.afff to the list of ignored
|
||||
devices.
|
||||
|
||||
You can remove already known but now ignored devices via
|
||||
"echo purge > /proc/cio_ignore"
|
||||
All devices ignored but still registered and not online (= not in use)
|
||||
will be deregistered and thus removed from the system.
|
||||
|
||||
The devices can be specified either by bus id (0.x.abcd) or, for 2.4 backward
|
||||
compatibility, by the device number in hexadecimal (0xabcd or abcd). Device
|
||||
numbers given as 0xabcd will be interpreted as 0.0.abcd.
|
||||
|
|
@ -98,8 +104,7 @@ debugfs entries
|
|||
handling).
|
||||
|
||||
- /sys/kernel/debug/s390dbf/cio_msg/sprintf
|
||||
Various debug messages from the common I/O-layer, including messages
|
||||
printed when cio_msg=yes.
|
||||
Various debug messages from the common I/O-layer.
|
||||
|
||||
- /sys/kernel/debug/s390dbf/cio_trace/hex_ascii
|
||||
Logs the calling of functions in the common I/O-layer and, if applicable,
|
||||
|
|
|
|||
|
|
@ -1,151 +1,242 @@
|
|||
|
||||
This is the CFS scheduler.
|
||||
|
||||
80% of CFS's design can be summed up in a single sentence: CFS basically
|
||||
models an "ideal, precise multi-tasking CPU" on real hardware.
|
||||
|
||||
"Ideal multi-tasking CPU" is a (non-existent :-)) CPU that has 100%
|
||||
physical power and which can run each task at precise equal speed, in
|
||||
parallel, each at 1/nr_running speed. For example: if there are 2 tasks
|
||||
running then it runs each at 50% physical power - totally in parallel.
|
||||
|
||||
On real hardware, we can run only a single task at once, so while that
|
||||
one task runs, the other tasks that are waiting for the CPU are at a
|
||||
disadvantage - the current task gets an unfair amount of CPU time. In
|
||||
CFS this fairness imbalance is expressed and tracked via the per-task
|
||||
p->wait_runtime (nanosec-unit) value. "wait_runtime" is the amount of
|
||||
time the task should now run on the CPU for it to become completely fair
|
||||
and balanced.
|
||||
|
||||
( small detail: on 'ideal' hardware, the p->wait_runtime value would
|
||||
always be zero - no task would ever get 'out of balance' from the
|
||||
'ideal' share of CPU time. )
|
||||
|
||||
CFS's task picking logic is based on this p->wait_runtime value and it
|
||||
is thus very simple: it always tries to run the task with the largest
|
||||
p->wait_runtime value. In other words, CFS tries to run the task with
|
||||
the 'gravest need' for more CPU time. So CFS always tries to split up
|
||||
CPU time between runnable tasks as close to 'ideal multitasking
|
||||
hardware' as possible.
|
||||
|
||||
Most of the rest of CFS's design just falls out of this really simple
|
||||
concept, with a few add-on embellishments like nice levels,
|
||||
multiprocessing and various algorithm variants to recognize sleepers.
|
||||
|
||||
In practice it works like this: the system runs a task a bit, and when
|
||||
the task schedules (or a scheduler tick happens) the task's CPU usage is
|
||||
'accounted for': the (small) time it just spent using the physical CPU
|
||||
is deducted from p->wait_runtime. [minus the 'fair share' it would have
|
||||
gotten anyway]. Once p->wait_runtime gets low enough so that another
|
||||
task becomes the 'leftmost task' of the time-ordered rbtree it maintains
|
||||
(plus a small amount of 'granularity' distance relative to the leftmost
|
||||
task so that we do not over-schedule tasks and trash the cache) then the
|
||||
new leftmost task is picked and the current task is preempted.
|
||||
|
||||
The rq->fair_clock value tracks the 'CPU time a runnable task would have
|
||||
fairly gotten, had it been runnable during that time'. So by using
|
||||
rq->fair_clock values we can accurately timestamp and measure the
|
||||
'expected CPU time' a task should have gotten. All runnable tasks are
|
||||
sorted in the rbtree by the "rq->fair_clock - p->wait_runtime" key, and
|
||||
CFS picks the 'leftmost' task and sticks to it. As the system progresses
|
||||
forwards, newly woken tasks are put into the tree more and more to the
|
||||
right - slowly but surely giving a chance for every task to become the
|
||||
'leftmost task' and thus get on the CPU within a deterministic amount of
|
||||
time.
|
||||
|
||||
Some implementation details:
|
||||
|
||||
- the introduction of Scheduling Classes: an extensible hierarchy of
|
||||
scheduler modules. These modules encapsulate scheduling policy
|
||||
details and are handled by the scheduler core without the core
|
||||
code assuming about them too much.
|
||||
|
||||
- sched_fair.c implements the 'CFS desktop scheduler': it is a
|
||||
replacement for the vanilla scheduler's SCHED_OTHER interactivity
|
||||
code.
|
||||
|
||||
I'd like to give credit to Con Kolivas for the general approach here:
|
||||
he has proven via RSDL/SD that 'fair scheduling' is possible and that
|
||||
it results in better desktop scheduling. Kudos Con!
|
||||
|
||||
The CFS patch uses a completely different approach and implementation
|
||||
from RSDL/SD. My goal was to make CFS's interactivity quality exceed
|
||||
that of RSDL/SD, which is a high standard to meet :-) Testing
|
||||
feedback is welcome to decide this one way or another. [ and, in any
|
||||
case, all of SD's logic could be added via a kernel/sched_sd.c module
|
||||
as well, if Con is interested in such an approach. ]
|
||||
|
||||
CFS's design is quite radical: it does not use runqueues, it uses a
|
||||
time-ordered rbtree to build a 'timeline' of future task execution,
|
||||
and thus has no 'array switch' artifacts (by which both the vanilla
|
||||
scheduler and RSDL/SD are affected).
|
||||
|
||||
CFS uses nanosecond granularity accounting and does not rely on any
|
||||
jiffies or other HZ detail. Thus the CFS scheduler has no notion of
|
||||
'timeslices' and has no heuristics whatsoever. There is only one
|
||||
central tunable (you have to switch on CONFIG_SCHED_DEBUG):
|
||||
|
||||
/proc/sys/kernel/sched_granularity_ns
|
||||
|
||||
which can be used to tune the scheduler from 'desktop' (low
|
||||
latencies) to 'server' (good batching) workloads. It defaults to a
|
||||
setting suitable for desktop workloads. SCHED_BATCH is handled by the
|
||||
CFS scheduler module too.
|
||||
|
||||
Due to its design, the CFS scheduler is not prone to any of the
|
||||
'attacks' that exist today against the heuristics of the stock
|
||||
scheduler: fiftyp.c, thud.c, chew.c, ring-test.c, massive_intr.c all
|
||||
work fine and do not impact interactivity and produce the expected
|
||||
behavior.
|
||||
|
||||
the CFS scheduler has a much stronger handling of nice levels and
|
||||
SCHED_BATCH: both types of workloads should be isolated much more
|
||||
agressively than under the vanilla scheduler.
|
||||
|
||||
( another detail: due to nanosec accounting and timeline sorting,
|
||||
sched_yield() support is very simple under CFS, and in fact under
|
||||
CFS sched_yield() behaves much better than under any other
|
||||
scheduler i have tested so far. )
|
||||
|
||||
- sched_rt.c implements SCHED_FIFO and SCHED_RR semantics, in a simpler
|
||||
way than the vanilla scheduler does. It uses 100 runqueues (for all
|
||||
100 RT priority levels, instead of 140 in the vanilla scheduler)
|
||||
and it needs no expired array.
|
||||
|
||||
- reworked/sanitized SMP load-balancing: the runqueue-walking
|
||||
assumptions are gone from the load-balancing code now, and
|
||||
iterators of the scheduling modules are used. The balancing code got
|
||||
quite a bit simpler as a result.
|
||||
=============
|
||||
CFS Scheduler
|
||||
=============
|
||||
|
||||
|
||||
Group scheduler extension to CFS
|
||||
================================
|
||||
1. OVERVIEW
|
||||
|
||||
Normally the scheduler operates on individual tasks and strives to provide
|
||||
fair CPU time to each task. Sometimes, it may be desirable to group tasks
|
||||
and provide fair CPU time to each such task group. For example, it may
|
||||
be desirable to first provide fair CPU time to each user on the system
|
||||
and then to each task belonging to a user.
|
||||
CFS stands for "Completely Fair Scheduler," and is the new "desktop" process
|
||||
scheduler implemented by Ingo Molnar and merged in Linux 2.6.23. It is the
|
||||
replacement for the previous vanilla scheduler's SCHED_OTHER interactivity
|
||||
code.
|
||||
|
||||
CONFIG_FAIR_GROUP_SCHED strives to achieve exactly that. It lets
|
||||
SCHED_NORMAL/BATCH tasks be be grouped and divides CPU time fairly among such
|
||||
groups. At present, there are two (mutually exclusive) mechanisms to group
|
||||
tasks for CPU bandwidth control purpose:
|
||||
80% of CFS's design can be summed up in a single sentence: CFS basically models
|
||||
an "ideal, precise multi-tasking CPU" on real hardware.
|
||||
|
||||
- Based on user id (CONFIG_FAIR_USER_SCHED)
|
||||
In this option, tasks are grouped according to their user id.
|
||||
- Based on "cgroup" pseudo filesystem (CONFIG_FAIR_CGROUP_SCHED)
|
||||
This options lets the administrator create arbitrary groups
|
||||
of tasks, using the "cgroup" pseudo filesystem. See
|
||||
Documentation/cgroups.txt for more information about this
|
||||
filesystem.
|
||||
"Ideal multi-tasking CPU" is a (non-existent :-)) CPU that has 100% physical
|
||||
power and which can run each task at precise equal speed, in parallel, each at
|
||||
1/nr_running speed. For example: if there are 2 tasks running, then it runs
|
||||
each at 50% physical power --- i.e., actually in parallel.
|
||||
|
||||
On real hardware, we can run only a single task at once, so we have to
|
||||
introduce the concept of "virtual runtime." The virtual runtime of a task
|
||||
specifies when its next timeslice would start execution on the ideal
|
||||
multi-tasking CPU described above. In practice, the virtual runtime of a task
|
||||
is its actual runtime normalized to the total number of running tasks.
|
||||
|
||||
|
||||
|
||||
2. FEW IMPLEMENTATION DETAILS
|
||||
|
||||
In CFS the virtual runtime is expressed and tracked via the per-task
|
||||
p->se.vruntime (nanosec-unit) value. This way, it's possible to accurately
|
||||
timestamp and measure the "expected CPU time" a task should have gotten.
|
||||
|
||||
[ small detail: on "ideal" hardware, at any time all tasks would have the same
|
||||
p->se.vruntime value --- i.e., tasks would execute simultaneously and no task
|
||||
would ever get "out of balance" from the "ideal" share of CPU time. ]
|
||||
|
||||
CFS's task picking logic is based on this p->se.vruntime value and it is thus
|
||||
very simple: it always tries to run the task with the smallest p->se.vruntime
|
||||
value (i.e., the task which executed least so far). CFS always tries to split
|
||||
up CPU time between runnable tasks as close to "ideal multitasking hardware" as
|
||||
possible.
|
||||
|
||||
Most of the rest of CFS's design just falls out of this really simple concept,
|
||||
with a few add-on embellishments like nice levels, multiprocessing and various
|
||||
algorithm variants to recognize sleepers.
|
||||
|
||||
|
||||
|
||||
3. THE RBTREE
|
||||
|
||||
CFS's design is quite radical: it does not use the old data structures for the
|
||||
runqueues, but it uses a time-ordered rbtree to build a "timeline" of future
|
||||
task execution, and thus has no "array switch" artifacts (by which both the
|
||||
previous vanilla scheduler and RSDL/SD are affected).
|
||||
|
||||
CFS also maintains the rq->cfs.min_vruntime value, which is a monotonic
|
||||
increasing value tracking the smallest vruntime among all tasks in the
|
||||
runqueue. The total amount of work done by the system is tracked using
|
||||
min_vruntime; that value is used to place newly activated entities on the left
|
||||
side of the tree as much as possible.
|
||||
|
||||
The total number of running tasks in the runqueue is accounted through the
|
||||
rq->cfs.load value, which is the sum of the weights of the tasks queued on the
|
||||
runqueue.
|
||||
|
||||
CFS maintains a time-ordered rbtree, where all runnable tasks are sorted by the
|
||||
p->se.vruntime key (there is a subtraction using rq->cfs.min_vruntime to
|
||||
account for possible wraparounds). CFS picks the "leftmost" task from this
|
||||
tree and sticks to it.
|
||||
As the system progresses forwards, the executed tasks are put into the tree
|
||||
more and more to the right --- slowly but surely giving a chance for every task
|
||||
to become the "leftmost task" and thus get on the CPU within a deterministic
|
||||
amount of time.
|
||||
|
||||
Summing up, CFS works like this: it runs a task a bit, and when the task
|
||||
schedules (or a scheduler tick happens) the task's CPU usage is "accounted
|
||||
for": the (small) time it just spent using the physical CPU is added to
|
||||
p->se.vruntime. Once p->se.vruntime gets high enough so that another task
|
||||
becomes the "leftmost task" of the time-ordered rbtree it maintains (plus a
|
||||
small amount of "granularity" distance relative to the leftmost task so that we
|
||||
do not over-schedule tasks and trash the cache), then the new leftmost task is
|
||||
picked and the current task is preempted.
|
||||
|
||||
|
||||
|
||||
4. SOME FEATURES OF CFS
|
||||
|
||||
CFS uses nanosecond granularity accounting and does not rely on any jiffies or
|
||||
other HZ detail. Thus the CFS scheduler has no notion of "timeslices" in the
|
||||
way the previous scheduler had, and has no heuristics whatsoever. There is
|
||||
only one central tunable (you have to switch on CONFIG_SCHED_DEBUG):
|
||||
|
||||
/proc/sys/kernel/sched_granularity_ns
|
||||
|
||||
which can be used to tune the scheduler from "desktop" (i.e., low latencies) to
|
||||
"server" (i.e., good batching) workloads. It defaults to a setting suitable
|
||||
for desktop workloads. SCHED_BATCH is handled by the CFS scheduler module too.
|
||||
|
||||
Due to its design, the CFS scheduler is not prone to any of the "attacks" that
|
||||
exist today against the heuristics of the stock scheduler: fiftyp.c, thud.c,
|
||||
chew.c, ring-test.c, massive_intr.c all work fine and do not impact
|
||||
interactivity and produce the expected behavior.
|
||||
|
||||
The CFS scheduler has a much stronger handling of nice levels and SCHED_BATCH
|
||||
than the previous vanilla scheduler: both types of workloads are isolated much
|
||||
more aggressively.
|
||||
|
||||
SMP load-balancing has been reworked/sanitized: the runqueue-walking
|
||||
assumptions are gone from the load-balancing code now, and iterators of the
|
||||
scheduling modules are used. The balancing code got quite a bit simpler as a
|
||||
result.
|
||||
|
||||
|
||||
|
||||
5. Scheduling policies
|
||||
|
||||
CFS implements three scheduling policies:
|
||||
|
||||
- SCHED_NORMAL (traditionally called SCHED_OTHER): The scheduling
|
||||
policy that is used for regular tasks.
|
||||
|
||||
- SCHED_BATCH: Does not preempt nearly as often as regular tasks
|
||||
would, thereby allowing tasks to run longer and make better use of
|
||||
caches but at the cost of interactivity. This is well suited for
|
||||
batch jobs.
|
||||
|
||||
- SCHED_IDLE: This is even weaker than nice 19, but its not a true
|
||||
idle timer scheduler in order to avoid to get into priority
|
||||
inversion problems which would deadlock the machine.
|
||||
|
||||
SCHED_FIFO/_RR are implemented in sched_rt.c and are as specified by
|
||||
POSIX.
|
||||
|
||||
The command chrt from util-linux-ng 2.13.1.1 can set all of these except
|
||||
SCHED_IDLE.
|
||||
|
||||
|
||||
|
||||
6. SCHEDULING CLASSES
|
||||
|
||||
The new CFS scheduler has been designed in such a way to introduce "Scheduling
|
||||
Classes," an extensible hierarchy of scheduler modules. These modules
|
||||
encapsulate scheduling policy details and are handled by the scheduler core
|
||||
without the core code assuming too much about them.
|
||||
|
||||
sched_fair.c implements the CFS scheduler described above.
|
||||
|
||||
sched_rt.c implements SCHED_FIFO and SCHED_RR semantics, in a simpler way than
|
||||
the previous vanilla scheduler did. It uses 100 runqueues (for all 100 RT
|
||||
priority levels, instead of 140 in the previous scheduler) and it needs no
|
||||
expired array.
|
||||
|
||||
Scheduling classes are implemented through the sched_class structure, which
|
||||
contains hooks to functions that must be called whenever an interesting event
|
||||
occurs.
|
||||
|
||||
This is the (partial) list of the hooks:
|
||||
|
||||
- enqueue_task(...)
|
||||
|
||||
Called when a task enters a runnable state.
|
||||
It puts the scheduling entity (task) into the red-black tree and
|
||||
increments the nr_running variable.
|
||||
|
||||
- dequeue_tree(...)
|
||||
|
||||
When a task is no longer runnable, this function is called to keep the
|
||||
corresponding scheduling entity out of the red-black tree. It decrements
|
||||
the nr_running variable.
|
||||
|
||||
- yield_task(...)
|
||||
|
||||
This function is basically just a dequeue followed by an enqueue, unless the
|
||||
compat_yield sysctl is turned on; in that case, it places the scheduling
|
||||
entity at the right-most end of the red-black tree.
|
||||
|
||||
- check_preempt_curr(...)
|
||||
|
||||
This function checks if a task that entered the runnable state should
|
||||
preempt the currently running task.
|
||||
|
||||
- pick_next_task(...)
|
||||
|
||||
This function chooses the most appropriate task eligible to run next.
|
||||
|
||||
- set_curr_task(...)
|
||||
|
||||
This function is called when a task changes its scheduling class or changes
|
||||
its task group.
|
||||
|
||||
- task_tick(...)
|
||||
|
||||
This function is mostly called from time tick functions; it might lead to
|
||||
process switch. This drives the running preemption.
|
||||
|
||||
- task_new(...)
|
||||
|
||||
The core scheduler gives the scheduling module an opportunity to manage new
|
||||
task startup. The CFS scheduling module uses it for group scheduling, while
|
||||
the scheduling module for a real-time task does not use it.
|
||||
|
||||
|
||||
|
||||
7. GROUP SCHEDULER EXTENSIONS TO CFS
|
||||
|
||||
Normally, the scheduler operates on individual tasks and strives to provide
|
||||
fair CPU time to each task. Sometimes, it may be desirable to group tasks and
|
||||
provide fair CPU time to each such task group. For example, it may be
|
||||
desirable to first provide fair CPU time to each user on the system and then to
|
||||
each task belonging to a user.
|
||||
|
||||
CONFIG_GROUP_SCHED strives to achieve exactly that. It lets tasks to be
|
||||
grouped and divides CPU time fairly among such groups.
|
||||
|
||||
CONFIG_RT_GROUP_SCHED permits to group real-time (i.e., SCHED_FIFO and
|
||||
SCHED_RR) tasks.
|
||||
|
||||
CONFIG_FAIR_GROUP_SCHED permits to group CFS (i.e., SCHED_NORMAL and
|
||||
SCHED_BATCH) tasks.
|
||||
|
||||
At present, there are two (mutually exclusive) mechanisms to group tasks for
|
||||
CPU bandwidth control purposes:
|
||||
|
||||
- Based on user id (CONFIG_USER_SCHED)
|
||||
|
||||
With this option, tasks are grouped according to their user id.
|
||||
|
||||
- Based on "cgroup" pseudo filesystem (CONFIG_CGROUP_SCHED)
|
||||
|
||||
This options needs CONFIG_CGROUPS to be defined, and lets the administrator
|
||||
create arbitrary groups of tasks, using the "cgroup" pseudo filesystem. See
|
||||
Documentation/cgroups.txt for more information about this filesystem.
|
||||
|
||||
Only one of these options to group tasks can be chosen and not both.
|
||||
|
||||
Group scheduler tunables:
|
||||
|
||||
When CONFIG_FAIR_USER_SCHED is defined, a directory is created in sysfs for
|
||||
each new user and a "cpu_share" file is added in that directory.
|
||||
When CONFIG_USER_SCHED is defined, a directory is created in sysfs for each new
|
||||
user and a "cpu_share" file is added in that directory.
|
||||
|
||||
# cd /sys/kernel/uids
|
||||
# cat 512/cpu_share # Display user 512's CPU share
|
||||
|
|
@ -155,16 +246,14 @@ each new user and a "cpu_share" file is added in that directory.
|
|||
2048
|
||||
#
|
||||
|
||||
CPU bandwidth between two users are divided in the ratio of their CPU shares.
|
||||
For ex: if you would like user "root" to get twice the bandwidth of user
|
||||
"guest", then set the cpu_share for both the users such that "root"'s
|
||||
cpu_share is twice "guest"'s cpu_share
|
||||
CPU bandwidth between two users is divided in the ratio of their CPU shares.
|
||||
For example: if you would like user "root" to get twice the bandwidth of user
|
||||
"guest," then set the cpu_share for both the users such that "root"'s cpu_share
|
||||
is twice "guest"'s cpu_share.
|
||||
|
||||
|
||||
When CONFIG_FAIR_CGROUP_SCHED is defined, a "cpu.shares" file is created
|
||||
for each group created using the pseudo filesystem. See example steps
|
||||
below to create task groups and modify their CPU share using the "cgroups"
|
||||
pseudo filesystem
|
||||
When CONFIG_CGROUP_SCHED is defined, a "cpu.shares" file is created for each
|
||||
group created using the pseudo filesystem. See example steps below to create
|
||||
task groups and modify their CPU share using the "cgroups" pseudo filesystem.
|
||||
|
||||
# mkdir /dev/cpuctl
|
||||
# mount -t cgroup -ocpu none /dev/cpuctl
|
||||
|
|
|
|||
|
|
@ -436,6 +436,42 @@ Other:
|
|||
was updated to remove all vports for the fc_host as well.
|
||||
|
||||
|
||||
Transport supplied functions
|
||||
----------------------------
|
||||
|
||||
The following functions are supplied by the FC-transport for use by LLDs.
|
||||
|
||||
fc_vport_create - create a vport
|
||||
fc_vport_terminate - detach and remove a vport
|
||||
|
||||
Details:
|
||||
|
||||
/**
|
||||
* fc_vport_create - Admin App or LLDD requests creation of a vport
|
||||
* @shost: scsi host the virtual port is connected to.
|
||||
* @ids: The world wide names, FC4 port roles, etc for
|
||||
* the virtual port.
|
||||
*
|
||||
* Notes:
|
||||
* This routine assumes no locks are held on entry.
|
||||
*/
|
||||
struct fc_vport *
|
||||
fc_vport_create(struct Scsi_Host *shost, struct fc_vport_identifiers *ids)
|
||||
|
||||
/**
|
||||
* fc_vport_terminate - Admin App or LLDD requests termination of a vport
|
||||
* @vport: fc_vport to be terminated
|
||||
*
|
||||
* Calls the LLDD vport_delete() function, then deallocates and removes
|
||||
* the vport from the shost and object tree.
|
||||
*
|
||||
* Notes:
|
||||
* This routine assumes no locks are held on entry.
|
||||
*/
|
||||
int
|
||||
fc_vport_terminate(struct fc_vport *vport)
|
||||
|
||||
|
||||
Credits
|
||||
=======
|
||||
The following people have contributed to this document:
|
||||
|
|
|
|||
|
|
@ -746,8 +746,10 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
Module snd-hda-intel
|
||||
--------------------
|
||||
|
||||
Module for Intel HD Audio (ICH6, ICH6M, ESB2, ICH7, ICH8),
|
||||
ATI SB450, SB600, RS600,
|
||||
Module for Intel HD Audio (ICH6, ICH6M, ESB2, ICH7, ICH8, ICH9, ICH10,
|
||||
PCH, SCH),
|
||||
ATI SB450, SB600, R600, RS600, RS690, RS780, RV610, RV620,
|
||||
RV630, RV635, RV670, RV770,
|
||||
VIA VT8251/VT8237A,
|
||||
SIS966, ULI M5461
|
||||
|
||||
|
|
@ -807,6 +809,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
ALC260
|
||||
hp HP machines
|
||||
hp-3013 HP machines (3013-variant)
|
||||
hp-dc7600 HP DC7600
|
||||
fujitsu Fujitsu S7020
|
||||
acer Acer TravelMate
|
||||
will Will laptops (PB V7900)
|
||||
|
|
@ -828,8 +831,11 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
hippo Hippo (ATI) with jack detection, Sony UX-90s
|
||||
hippo_1 Hippo (Benq) with jack detection
|
||||
sony-assamd Sony ASSAMD
|
||||
toshiba-s06 Toshiba S06
|
||||
toshiba-rx1 Toshiba RX1
|
||||
ultra Samsung Q1 Ultra Vista model
|
||||
lenovo-3000 Lenovo 3000 y410
|
||||
nec NEC Versa S9100
|
||||
basic fixed pin assignment w/o SPDIF
|
||||
auto auto-config reading BIOS (default)
|
||||
|
||||
|
|
@ -838,6 +844,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
3stack 3-stack model
|
||||
toshiba Toshiba A205
|
||||
acer Acer laptops
|
||||
acer-aspire Acer Aspire One
|
||||
dell Dell OEM laptops (Vostro 1200)
|
||||
zepto Zepto laptops
|
||||
test for testing/debugging purpose, almost all controls can
|
||||
|
|
@ -847,6 +854,9 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
|
||||
ALC269
|
||||
basic Basic preset
|
||||
quanta Quanta FL1
|
||||
eeepc-p703 ASUS Eeepc P703 P900A
|
||||
eeepc-p901 ASUS Eeepc P901 S101
|
||||
|
||||
ALC662/663
|
||||
3stack-dig 3-stack (2-channel) with SPDIF
|
||||
|
|
@ -856,10 +866,17 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
lenovo-101e Lenovo laptop
|
||||
eeepc-p701 ASUS Eeepc P701
|
||||
eeepc-ep20 ASUS Eeepc EP20
|
||||
ecs ECS/Foxconn mobo
|
||||
m51va ASUS M51VA
|
||||
g71v ASUS G71V
|
||||
h13 ASUS H13
|
||||
g50v ASUS G50V
|
||||
asus-mode1 ASUS
|
||||
asus-mode2 ASUS
|
||||
asus-mode3 ASUS
|
||||
asus-mode4 ASUS
|
||||
asus-mode5 ASUS
|
||||
asus-mode6 ASUS
|
||||
auto auto-config reading BIOS (default)
|
||||
|
||||
ALC882/885
|
||||
|
|
@ -891,12 +908,14 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
lenovo-101e Lenovo 101E
|
||||
lenovo-nb0763 Lenovo NB0763
|
||||
lenovo-ms7195-dig Lenovo MS7195
|
||||
lenovo-sky Lenovo Sky
|
||||
haier-w66 Haier W66
|
||||
3stack-hp HP machines with 3stack (Lucknow, Samba boards)
|
||||
6stack-dell Dell machines with 6stack (Inspiron 530)
|
||||
mitac Mitac 8252D
|
||||
clevo-m720 Clevo M720 laptop series
|
||||
fujitsu-pi2515 Fujitsu AMILO Pi2515
|
||||
3stack-6ch-intel Intel DG33* boards
|
||||
auto auto-config reading BIOS (default)
|
||||
|
||||
ALC861/660
|
||||
|
|
@ -929,7 +948,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
allout 5-jack in back, 2-jack in front, SPDIF out
|
||||
auto auto-config reading BIOS (default)
|
||||
|
||||
AD1882
|
||||
AD1882 / AD1882A
|
||||
3stack 3-stack mode (default)
|
||||
6stack 6-stack mode
|
||||
|
||||
|
|
@ -1079,7 +1098,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
register value without FIFO size correction as the current
|
||||
DMA pointer. position_fix=2 will make the driver to use
|
||||
the position buffer instead of reading SD_LPIB register.
|
||||
(Usually SD_LPLIB register is more accurate than the
|
||||
(Usually SD_LPIB register is more accurate than the
|
||||
position buffer.)
|
||||
|
||||
NB: If you get many "azx_get_response timeout" messages at
|
||||
|
|
@ -1166,6 +1185,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
* Event Electronics, EZ8
|
||||
* Digigram VX442
|
||||
* Lionstracs, Mediastaton
|
||||
* Terrasoniq TS 88
|
||||
|
||||
model - Use the given board model, one of the following:
|
||||
delta1010, dio2496, delta66, delta44, audiophile, delta410,
|
||||
|
|
@ -1200,7 +1220,10 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
* TerraTec Phase 22
|
||||
* TerraTec Phase 28
|
||||
* AudioTrak Prodigy 7.1
|
||||
* AudioTrak Prodigy 7.1LT
|
||||
* AudioTrak Prodigy 7.1 LT
|
||||
* AudioTrak Prodigy 7.1 XT
|
||||
* AudioTrak Prodigy 7.1 HIFI
|
||||
* AudioTrak Prodigy 7.1 HD2
|
||||
* AudioTrak Prodigy 192
|
||||
* Pontis MS300
|
||||
* Albatron K8X800 Pro II
|
||||
|
|
@ -1211,12 +1234,16 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
* Shuttle SN25P
|
||||
* Onkyo SE-90PCI
|
||||
* Onkyo SE-200PCI
|
||||
* ESI Juli@
|
||||
* Hercules Fortissimo IV
|
||||
* EGO-SYS WaveTerminal 192M
|
||||
|
||||
model - Use the given board model, one of the following:
|
||||
revo51, revo71, amp2000, prodigy71, prodigy71lt,
|
||||
prodigy192, aureon51, aureon71, universe, ap192,
|
||||
k8x800, phase22, phase28, ms300, av710, se200pci,
|
||||
se90pci
|
||||
prodigy71xt, prodigy71hifi, prodigyhd2, prodigy192,
|
||||
juli, aureon51, aureon71, universe, ap192, k8x800,
|
||||
phase22, phase28, ms300, av710, se200pci, se90pci,
|
||||
fortissimo4, sn25p, WT192M
|
||||
|
||||
This module supports multiple cards and autoprobe.
|
||||
|
||||
|
|
@ -1255,7 +1282,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
|
||||
Module for AC'97 motherboards from Intel and compatibles.
|
||||
* Intel i810/810E, i815, i820, i830, i84x, MX440
|
||||
ICH5, ICH6, ICH7, ESB2
|
||||
ICH5, ICH6, ICH7, 6300ESB, ESB2
|
||||
* SiS 7012 (SiS 735)
|
||||
* NVidia NForce, NForce2, NForce3, MCP04, CK804
|
||||
CK8, CK8S, MCP501
|
||||
|
|
@ -1951,6 +1978,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
* CHIC True Sound 4Dwave
|
||||
* Shark Predator4D-PCI
|
||||
* Jaton SonicWave 4D
|
||||
* SiS SI7018 PCI Audio
|
||||
* Hoontech SoundTrack Digital 4DWave NX
|
||||
|
||||
pcm_channels - max channels (voices) reserved for PCM
|
||||
wavetable_size - max wavetable size in kB (4-?kb)
|
||||
|
|
@ -1966,12 +1995,25 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
|
||||
vid - Vendor ID for the device (optional)
|
||||
pid - Product ID for the device (optional)
|
||||
nrpacks - Max. number of packets per URB (default: 8)
|
||||
async_unlink - Use async unlink mode (default: yes)
|
||||
device_setup - Device specific magic number (optional)
|
||||
- Influence depends on the device
|
||||
- Default: 0x0000
|
||||
ignore_ctl_error - Ignore any USB-controller regarding mixer
|
||||
interface (default: no)
|
||||
|
||||
This module supports multiple devices, autoprobe and hotplugging.
|
||||
|
||||
NB: nrpacks parameter can be modified dynamically via sysfs.
|
||||
Don't put the value over 20. Changing via sysfs has no sanity
|
||||
check.
|
||||
NB: async_unlink=0 would cause Oops. It remains just for
|
||||
debugging purpose (if any).
|
||||
NB: ignore_ctl_error=1 may help when you get an error at accessing
|
||||
the mixer element such as URB error -22. This happens on some
|
||||
buggy USB device or the controller.
|
||||
|
||||
Module snd-usb-caiaq
|
||||
--------------------
|
||||
|
||||
|
|
@ -2078,7 +2120,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
-------------------
|
||||
|
||||
Module for sound cards based on the Asus AV100/AV200 chips,
|
||||
i.e., Xonar D1, DX, D2 and D2X.
|
||||
i.e., Xonar D1, DX, D2, D2X and HDAV1.3 (Deluxe).
|
||||
|
||||
This module supports autoprobe and multiple cards.
|
||||
|
||||
|
|
|
|||
|
|
@ -6135,44 +6135,58 @@ struct _snd_pcm_runtime {
|
|||
</para>
|
||||
</section>
|
||||
|
||||
<section id="useful-functions-snd-assert">
|
||||
<title><function>snd_assert()</function></title>
|
||||
<para>
|
||||
<function>snd_assert()</function> macro is similar with the
|
||||
normal <function>assert()</function> macro. For example,
|
||||
|
||||
<informalexample>
|
||||
<programlisting>
|
||||
<![CDATA[
|
||||
snd_assert(pointer != NULL, return -EINVAL);
|
||||
]]>
|
||||
</programlisting>
|
||||
</informalexample>
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The first argument is the expression to evaluate, and the
|
||||
second argument is the action if it fails. When
|
||||
<constant>CONFIG_SND_DEBUG</constant>, is set, it will show an
|
||||
error message such as <computeroutput>BUG? (xxx)</computeroutput>
|
||||
together with stack trace.
|
||||
</para>
|
||||
<para>
|
||||
When no debug flag is set, this macro is ignored.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id="useful-functions-snd-bug">
|
||||
<title><function>snd_BUG()</function></title>
|
||||
<para>
|
||||
It shows the <computeroutput>BUG?</computeroutput> message and
|
||||
stack trace as well as <function>snd_assert</function> at the point.
|
||||
stack trace as well as <function>snd_BUG_ON</function> at the point.
|
||||
It's useful to show that a fatal error happens there.
|
||||
</para>
|
||||
<para>
|
||||
When no debug flag is set, this macro is ignored.
|
||||
</para>
|
||||
</section>
|
||||
|
||||
<section id="useful-functions-snd-bug-on">
|
||||
<title><function>snd_BUG_ON()</function></title>
|
||||
<para>
|
||||
<function>snd_BUG_ON()</function> macro is similar with
|
||||
<function>WARN_ON()</function> macro. For example,
|
||||
|
||||
<informalexample>
|
||||
<programlisting>
|
||||
<![CDATA[
|
||||
snd_BUG_ON(!pointer);
|
||||
]]>
|
||||
</programlisting>
|
||||
</informalexample>
|
||||
|
||||
or it can be used as the condition,
|
||||
<informalexample>
|
||||
<programlisting>
|
||||
<![CDATA[
|
||||
if (snd_BUG_ON(non_zero_is_bug))
|
||||
return -EINVAL;
|
||||
]]>
|
||||
</programlisting>
|
||||
</informalexample>
|
||||
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The macro takes an conditional expression to evaluate.
|
||||
When <constant>CONFIG_SND_DEBUG</constant>, is set, the
|
||||
expression is actually evaluated. If it's non-zero, it shows
|
||||
the warning message such as
|
||||
<computeroutput>BUG? (xxx)</computeroutput>
|
||||
normally followed by stack trace. It returns the evaluated
|
||||
value.
|
||||
When no <constant>CONFIG_SND_DEBUG</constant> is set, this
|
||||
macro always returns zero.
|
||||
</para>
|
||||
|
||||
</section>
|
||||
|
||||
</chapter>
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -135,11 +135,7 @@ when the Mic is inserted:-
|
|||
|
||||
static int spitz_mic_bias(struct snd_soc_dapm_widget* w, int event)
|
||||
{
|
||||
if(SND_SOC_DAPM_EVENT_ON(event))
|
||||
set_scoop_gpio(&spitzscoop2_device.dev, SPITZ_SCP2_MIC_BIAS);
|
||||
else
|
||||
reset_scoop_gpio(&spitzscoop2_device.dev, SPITZ_SCP2_MIC_BIAS);
|
||||
|
||||
gpio_set_value(SPITZ_GPIO_MIC_BIAS, SND_SOC_DAPM_EVENT_ON(event));
|
||||
return 0;
|
||||
}
|
||||
|
||||
|
|
@ -269,11 +265,7 @@ powered only when the spk is in use.
|
|||
/* turn speaker amplifier on/off depending on use */
|
||||
static int corgi_amp_event(struct snd_soc_dapm_widget *w, int event)
|
||||
{
|
||||
if (SND_SOC_DAPM_EVENT_ON(event))
|
||||
set_scoop_gpio(&corgiscoop_device.dev, CORGI_SCP_APM_ON);
|
||||
else
|
||||
reset_scoop_gpio(&corgiscoop_device.dev, CORGI_SCP_APM_ON);
|
||||
|
||||
gpio_set_value(CORGI_GPIO_APM_ON, SND_SOC_DAPM_EVENT_ON(event));
|
||||
return 0;
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -351,9 +351,10 @@ kernel. This value defaults to SHMMAX.
|
|||
|
||||
softlockup_thresh:
|
||||
|
||||
This value can be used to lower the softlockup tolerance
|
||||
threshold. The default threshold is 10s. If a cpu is locked up
|
||||
for 10s, the kernel complains. Valid values are 1-60s.
|
||||
This value can be used to lower the softlockup tolerance threshold. The
|
||||
default threshold is 60 seconds. If a cpu is locked up for 60 seconds,
|
||||
the kernel complains. Valid values are 1-60 seconds. Setting this
|
||||
tunable to zero will disable the softlockup detection altogether.
|
||||
|
||||
==============================================================
|
||||
|
||||
|
|
|
|||
|
|
@ -42,9 +42,21 @@ This function kills all URBs associated with an anchor. The URBs
|
|||
are called in the reverse temporal order they were submitted.
|
||||
This way no data can be reordered.
|
||||
|
||||
usb_unlink_anchored_urbs()
|
||||
--------------------------
|
||||
|
||||
This function unlinks all URBs associated with an anchor. The URBs
|
||||
are processed in the reverse temporal order they were submitted.
|
||||
This is similar to usb_kill_anchored_urbs(), but it will not sleep.
|
||||
Therefore no guarantee is made that the URBs have been unlinked when
|
||||
the call returns. They may be unlinked later but will be unlinked in
|
||||
finite time.
|
||||
|
||||
usb_wait_anchor_empty_timeout()
|
||||
-------------------------------
|
||||
|
||||
This function waits for all URBs associated with an anchor to finish
|
||||
or a timeout, whichever comes first. Its return value will tell you
|
||||
whether the timeout was reached.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@
|
|||
45 -> Pinnacle PCTV DVB-T (em2870)
|
||||
46 -> Compro, VideoMate U3 (em2870) [185b:2870]
|
||||
47 -> KWorld DVB-T 305U (em2880) [eb1a:e305]
|
||||
48 -> KWorld DVB-T 310U (em2880)
|
||||
48 -> KWorld DVB-T 310U (em2880) [eb1a:e310]
|
||||
49 -> MSI DigiVox A/D (em2880) [eb1a:e310]
|
||||
50 -> MSI DigiVox A/D II (em2880) [eb1a:e320]
|
||||
51 -> Terratec Hybrid XS Secam (em2880) [0ccd:004c]
|
||||
|
|
|
|||
|
|
@ -190,6 +190,7 @@ pac7311 093a:260f SnakeCam
|
|||
pac7311 093a:2621 PAC731x
|
||||
pac7311 093a:2624 PAC7302
|
||||
pac7311 093a:2626 Labtec 2200
|
||||
pac7311 093a:262a Webcam 300k
|
||||
zc3xx 0ac8:0302 Z-star Vimicro zc0302
|
||||
vc032x 0ac8:0321 Vimicro generic vc0321
|
||||
vc032x 0ac8:0323 Vimicro Vc0323
|
||||
|
|
|
|||
4
Documentation/x86/00-INDEX
Normal file
4
Documentation/x86/00-INDEX
Normal file
|
|
@ -0,0 +1,4 @@
|
|||
00-INDEX
|
||||
- this file
|
||||
mtrr.txt
|
||||
- how to use x86 Memory Type Range Registers to increase performance
|
||||
|
|
@ -308,7 +308,7 @@ Protocol: 2.00+
|
|||
|
||||
Field name: start_sys
|
||||
Type: read
|
||||
Offset/size: 0x20c/4
|
||||
Offset/size: 0x20c/2
|
||||
Protocol: 2.00+
|
||||
|
||||
The load low segment (0x1000). Obsolete.
|
||||
|
|
@ -18,7 +18,7 @@ Richard Gooch
|
|||
The AMD K6-2 (stepping 8 and above) and K6-3 processors have two
|
||||
MTRRs. These are supported. The AMD Athlon family provide 8 Intel
|
||||
style MTRRs.
|
||||
|
||||
|
||||
The Centaur C6 (WinChip) has 8 MCRs, allowing write-combining. These
|
||||
are supported.
|
||||
|
||||
|
|
@ -87,7 +87,7 @@ reg00: base=0x00000000 ( 0MB), size= 64MB: write-back, count=1
|
|||
reg01: base=0xfb000000 (4016MB), size= 16MB: write-combining, count=1
|
||||
reg02: base=0xfb000000 (4016MB), size= 4kB: uncachable, count=1
|
||||
|
||||
Some cards (especially Voodoo Graphics boards) need this 4 kB area
|
||||
Some cards (especially Voodoo Graphics boards) need this 4 kB area
|
||||
excluded from the beginning of the region because it is used for
|
||||
registers.
|
||||
|
||||
|
|
@ -14,6 +14,10 @@ PAT allows for different types of memory attributes. The most commonly used
|
|||
ones that will be supported at this time are Write-back, Uncached,
|
||||
Write-combined and Uncached Minus.
|
||||
|
||||
|
||||
PAT APIs
|
||||
--------
|
||||
|
||||
There are many different APIs in the kernel that allows setting of memory
|
||||
attributes at the page level. In order to avoid aliasing, these interfaces
|
||||
should be used thoughtfully. Below is a table of interfaces available,
|
||||
|
|
@ -26,38 +30,38 @@ address range to avoid any aliasing.
|
|||
API | RAM | ACPI,... | Reserved/Holes |
|
||||
-----------------------|----------|------------|------------------|
|
||||
| | | |
|
||||
ioremap | -- | UC | UC |
|
||||
ioremap | -- | UC- | UC- |
|
||||
| | | |
|
||||
ioremap_cache | -- | WB | WB |
|
||||
| | | |
|
||||
ioremap_nocache | -- | UC | UC |
|
||||
ioremap_nocache | -- | UC- | UC- |
|
||||
| | | |
|
||||
ioremap_wc | -- | -- | WC |
|
||||
| | | |
|
||||
set_memory_uc | UC | -- | -- |
|
||||
set_memory_uc | UC- | -- | -- |
|
||||
set_memory_wb | | | |
|
||||
| | | |
|
||||
set_memory_wc | WC | -- | -- |
|
||||
set_memory_wb | | | |
|
||||
| | | |
|
||||
pci sysfs resource | -- | -- | UC |
|
||||
pci sysfs resource | -- | -- | UC- |
|
||||
| | | |
|
||||
pci sysfs resource_wc | -- | -- | WC |
|
||||
is IORESOURCE_PREFETCH| | | |
|
||||
| | | |
|
||||
pci proc | -- | -- | UC |
|
||||
pci proc | -- | -- | UC- |
|
||||
!PCIIOC_WRITE_COMBINE | | | |
|
||||
| | | |
|
||||
pci proc | -- | -- | WC |
|
||||
PCIIOC_WRITE_COMBINE | | | |
|
||||
| | | |
|
||||
/dev/mem | -- | UC | UC |
|
||||
/dev/mem | -- | WB/WC/UC- | WB/WC/UC- |
|
||||
read-write | | | |
|
||||
| | | |
|
||||
/dev/mem | -- | UC | UC |
|
||||
/dev/mem | -- | UC- | UC- |
|
||||
mmap SYNC flag | | | |
|
||||
| | | |
|
||||
/dev/mem | -- | WB/WC/UC | WB/WC/UC |
|
||||
/dev/mem | -- | WB/WC/UC- | WB/WC/UC- |
|
||||
mmap !SYNC flag | |(from exist-| (from exist- |
|
||||
and | | ing alias)| ing alias) |
|
||||
any alias to this area| | | |
|
||||
|
|
@ -68,7 +72,7 @@ pci proc | -- | -- | WC |
|
|||
and | | | |
|
||||
MTRR says WB | | | |
|
||||
| | | |
|
||||
/dev/mem | -- | -- | UC_MINUS |
|
||||
/dev/mem | -- | -- | UC- |
|
||||
mmap !SYNC flag | | | |
|
||||
no alias to this area | | | |
|
||||
and | | | |
|
||||
|
|
@ -98,3 +102,35 @@ types.
|
|||
|
||||
Drivers should use set_memory_[uc|wc] to set access type for RAM ranges.
|
||||
|
||||
|
||||
PAT debugging
|
||||
-------------
|
||||
|
||||
With CONFIG_DEBUG_FS enabled, PAT memtype list can be examined by
|
||||
|
||||
# mount -t debugfs debugfs /sys/kernel/debug
|
||||
# cat /sys/kernel/debug/x86/pat_memtype_list
|
||||
PAT memtype list:
|
||||
uncached-minus @ 0x7fadf000-0x7fae0000
|
||||
uncached-minus @ 0x7fb19000-0x7fb1a000
|
||||
uncached-minus @ 0x7fb1a000-0x7fb1b000
|
||||
uncached-minus @ 0x7fb1b000-0x7fb1c000
|
||||
uncached-minus @ 0x7fb1c000-0x7fb1d000
|
||||
uncached-minus @ 0x7fb1d000-0x7fb1e000
|
||||
uncached-minus @ 0x7fb1e000-0x7fb25000
|
||||
uncached-minus @ 0x7fb25000-0x7fb26000
|
||||
uncached-minus @ 0x7fb26000-0x7fb27000
|
||||
uncached-minus @ 0x7fb27000-0x7fb28000
|
||||
uncached-minus @ 0x7fb28000-0x7fb2e000
|
||||
uncached-minus @ 0x7fb2e000-0x7fb2f000
|
||||
uncached-minus @ 0x7fb2f000-0x7fb30000
|
||||
uncached-minus @ 0x7fb31000-0x7fb32000
|
||||
uncached-minus @ 0x80000000-0x90000000
|
||||
|
||||
This list shows physical address ranges and various PAT settings used to
|
||||
access those physical address ranges.
|
||||
|
||||
Another, more verbose way of getting PAT related debug messages is with
|
||||
"debugpat" boot parameter. With this parameter, various debug messages are
|
||||
printed to dmesg log.
|
||||
|
||||
|
|
|
|||
|
|
@ -54,10 +54,6 @@ APICs
|
|||
apicmaintimer. Useful when your PIT timer is totally
|
||||
broken.
|
||||
|
||||
disable_8254_timer / enable_8254_timer
|
||||
Enable interrupt 0 timer routing over the 8254 in addition to over
|
||||
the IO-APIC. The kernel tries to set a sensible default.
|
||||
|
||||
Early Console
|
||||
|
||||
syntax: earlyprintk=vga
|
||||
|
|
|
|||
Loading…
Reference in a new issue