Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
Merge the BIOS workarounds from 2.6.32, and the swiotlb fallback on failure.
This commit is contained in:
commit
ec20849193
1
.gitignore
vendored
1
.gitignore
vendored
|
@ -25,6 +25,7 @@
|
|||
*.elf
|
||||
*.bin
|
||||
*.gz
|
||||
*.bz2
|
||||
*.lzma
|
||||
*.patch
|
||||
*.gcno
|
||||
|
|
|
@ -31,3 +31,31 @@ Date: March 2009
|
|||
Kernel Version: 2.6.30
|
||||
Contact: iss_storagedev@hp.com
|
||||
Description: A symbolic link to /sys/block/cciss!cXdY
|
||||
|
||||
Where: /sys/bus/pci/devices/<dev>/ccissX/rescan
|
||||
Date: August 2009
|
||||
Kernel Version: 2.6.31
|
||||
Contact: iss_storagedev@hp.com
|
||||
Description: Kicks of a rescan of the controller to discover logical
|
||||
drive topology changes.
|
||||
|
||||
Where: /sys/bus/pci/devices/<dev>/ccissX/cXdY/lunid
|
||||
Date: August 2009
|
||||
Kernel Version: 2.6.31
|
||||
Contact: iss_storagedev@hp.com
|
||||
Description: Displays the 8-byte LUN ID used to address logical
|
||||
drive Y of controller X.
|
||||
|
||||
Where: /sys/bus/pci/devices/<dev>/ccissX/cXdY/raid_level
|
||||
Date: August 2009
|
||||
Kernel Version: 2.6.31
|
||||
Contact: iss_storagedev@hp.com
|
||||
Description: Displays the RAID level of logical drive Y of
|
||||
controller X.
|
||||
|
||||
Where: /sys/bus/pci/devices/<dev>/ccissX/cXdY/usage_count
|
||||
Date: August 2009
|
||||
Kernel Version: 2.6.31
|
||||
Contact: iss_storagedev@hp.com
|
||||
Description: Displays the usage count (number of opens) of logical drive Y
|
||||
of controller X.
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
What: /sys/class/usb_host/usb_hostN/wusb_chid
|
||||
What: /sys/class/uwb_rc/uwbN/wusbhc/wusb_chid
|
||||
Date: July 2008
|
||||
KernelVersion: 2.6.27
|
||||
Contact: David Vrabel <david.vrabel@csr.com>
|
||||
|
@ -9,7 +9,7 @@ Description:
|
|||
|
||||
Set an all zero CHID to stop the host controller.
|
||||
|
||||
What: /sys/class/usb_host/usb_hostN/wusb_trust_timeout
|
||||
What: /sys/class/uwb_rc/uwbN/wusbhc/wusb_trust_timeout
|
||||
Date: July 2008
|
||||
KernelVersion: 2.6.27
|
||||
Contact: David Vrabel <david.vrabel@csr.com>
|
|
@ -1,18 +0,0 @@
|
|||
What: /sys/devices/system/cpu/cpu*/cache/index*/cache_disable_X
|
||||
Date: August 2008
|
||||
KernelVersion: 2.6.27
|
||||
Contact: mark.langsdorf@amd.com
|
||||
Description: These files exist in every cpu's cache index directories.
|
||||
There are currently 2 cache_disable_# files in each
|
||||
directory. Reading from these files on a supported
|
||||
processor will return that cache disable index value
|
||||
for that processor and node. Writing to one of these
|
||||
files will cause the specificed cache index to be disabled.
|
||||
|
||||
Currently, only AMD Family 10h Processors support cache index
|
||||
disable, and only for their L3 caches. See the BIOS and
|
||||
Kernel Developer's Guide at
|
||||
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116-Public-GH-BKDG_3.20_2-4-09.pdf
|
||||
for formatting information and other details on the
|
||||
cache index disable.
|
||||
Users: joachim.deguara@amd.com
|
156
Documentation/ABI/testing/sysfs-devices-system-cpu
Normal file
156
Documentation/ABI/testing/sysfs-devices-system-cpu
Normal file
|
@ -0,0 +1,156 @@
|
|||
What: /sys/devices/system/cpu/
|
||||
Date: pre-git history
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Description:
|
||||
A collection of both global and individual CPU attributes
|
||||
|
||||
Individual CPU attributes are contained in subdirectories
|
||||
named by the kernel's logical CPU number, e.g.:
|
||||
|
||||
/sys/devices/system/cpu/cpu#/
|
||||
|
||||
What: /sys/devices/system/cpu/sched_mc_power_savings
|
||||
/sys/devices/system/cpu/sched_smt_power_savings
|
||||
Date: June 2006
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Description: Discover and adjust the kernel's multi-core scheduler support.
|
||||
|
||||
Possible values are:
|
||||
|
||||
0 - No power saving load balance (default value)
|
||||
1 - Fill one thread/core/package first for long running threads
|
||||
2 - Also bias task wakeups to semi-idle cpu package for power
|
||||
savings
|
||||
|
||||
sched_mc_power_savings is dependent upon SCHED_MC, which is
|
||||
itself architecture dependent.
|
||||
|
||||
sched_smt_power_savings is dependent upon SCHED_SMT, which
|
||||
is itself architecture dependent.
|
||||
|
||||
The two files are independent of each other. It is possible
|
||||
that one file may be present without the other.
|
||||
|
||||
Introduced by git commit 5c45bf27.
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/kernel_max
|
||||
/sys/devices/system/cpu/offline
|
||||
/sys/devices/system/cpu/online
|
||||
/sys/devices/system/cpu/possible
|
||||
/sys/devices/system/cpu/present
|
||||
Date: December 2008
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Description: CPU topology files that describe kernel limits related to
|
||||
hotplug. Briefly:
|
||||
|
||||
kernel_max: the maximum cpu index allowed by the kernel
|
||||
configuration.
|
||||
|
||||
offline: cpus that are not online because they have been
|
||||
HOTPLUGGED off or exceed the limit of cpus allowed by the
|
||||
kernel configuration (kernel_max above).
|
||||
|
||||
online: cpus that are online and being scheduled.
|
||||
|
||||
possible: cpus that have been allocated resources and can be
|
||||
brought online if they are present.
|
||||
|
||||
present: cpus that have been identified as being present in
|
||||
the system.
|
||||
|
||||
See Documentation/cputopology.txt for more information.
|
||||
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/cpu#/node
|
||||
Date: October 2009
|
||||
Contact: Linux memory management mailing list <linux-mm@kvack.org>
|
||||
Description: Discover NUMA node a CPU belongs to
|
||||
|
||||
When CONFIG_NUMA is enabled, a symbolic link that points
|
||||
to the corresponding NUMA node directory.
|
||||
|
||||
For example, the following symlink is created for cpu42
|
||||
in NUMA node 2:
|
||||
|
||||
/sys/devices/system/cpu/cpu42/node2 -> ../../node/node2
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/cpu#/topology/core_id
|
||||
/sys/devices/system/cpu/cpu#/topology/core_siblings
|
||||
/sys/devices/system/cpu/cpu#/topology/core_siblings_list
|
||||
/sys/devices/system/cpu/cpu#/topology/physical_package_id
|
||||
/sys/devices/system/cpu/cpu#/topology/thread_siblings
|
||||
/sys/devices/system/cpu/cpu#/topology/thread_siblings_list
|
||||
Date: December 2008
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Description: CPU topology files that describe a logical CPU's relationship
|
||||
to other cores and threads in the same physical package.
|
||||
|
||||
One cpu# directory is created per logical CPU in the system,
|
||||
e.g. /sys/devices/system/cpu/cpu42/.
|
||||
|
||||
Briefly, the files above are:
|
||||
|
||||
core_id: the CPU core ID of cpu#. Typically it is the
|
||||
hardware platform's identifier (rather than the kernel's).
|
||||
The actual value is architecture and platform dependent.
|
||||
|
||||
core_siblings: internal kernel map of cpu#'s hardware threads
|
||||
within the same physical_package_id.
|
||||
|
||||
core_siblings_list: human-readable list of the logical CPU
|
||||
numbers within the same physical_package_id as cpu#.
|
||||
|
||||
physical_package_id: physical package id of cpu#. Typically
|
||||
corresponds to a physical socket number, but the actual value
|
||||
is architecture and platform dependent.
|
||||
|
||||
thread_siblings: internel kernel map of cpu#'s hardware
|
||||
threads within the same core as cpu#
|
||||
|
||||
thread_siblings_list: human-readable list of cpu#'s hardware
|
||||
threads within the same core as cpu#
|
||||
|
||||
See Documentation/cputopology.txt for more information.
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/cpuidle/current_driver
|
||||
/sys/devices/system/cpu/cpuidle/current_governer_ro
|
||||
Date: September 2007
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Description: Discover cpuidle policy and mechanism
|
||||
|
||||
Various CPUs today support multiple idle levels that are
|
||||
differentiated by varying exit latencies and power
|
||||
consumption during idle.
|
||||
|
||||
Idle policy (governor) is differentiated from idle mechanism
|
||||
(driver)
|
||||
|
||||
current_driver: displays current idle mechanism
|
||||
|
||||
current_governor_ro: displays current idle policy
|
||||
|
||||
See files in Documentation/cpuidle/ for more information.
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/cpu*/cache/index*/cache_disable_X
|
||||
Date: August 2008
|
||||
KernelVersion: 2.6.27
|
||||
Contact: mark.langsdorf@amd.com
|
||||
Description: These files exist in every cpu's cache index directories.
|
||||
There are currently 2 cache_disable_# files in each
|
||||
directory. Reading from these files on a supported
|
||||
processor will return that cache disable index value
|
||||
for that processor and node. Writing to one of these
|
||||
files will cause the specificed cache index to be disabled.
|
||||
|
||||
Currently, only AMD Family 10h Processors support cache index
|
||||
disable, and only for their L3 caches. See the BIOS and
|
||||
Kernel Developer's Guide at
|
||||
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116-Public-GH-BKDG_3.20_2-4-09.pdf
|
||||
for formatting information and other details on the
|
||||
cache index disable.
|
||||
Users: joachim.deguara@amd.com
|
|
@ -232,7 +232,7 @@ your e-mail client so that it sends your patches untouched.
|
|||
When sending patches to Linus, always follow step #7.
|
||||
|
||||
Large changes are not appropriate for mailing lists, and some
|
||||
maintainers. If your patch, uncompressed, exceeds 40 kB in size,
|
||||
maintainers. If your patch, uncompressed, exceeds 300 kB in size,
|
||||
it is preferred that you store your patch on an Internet-accessible
|
||||
server, and provide instead a URL (link) pointing to your patch.
|
||||
|
||||
|
|
147
Documentation/arm/tcm.txt
Normal file
147
Documentation/arm/tcm.txt
Normal file
|
@ -0,0 +1,147 @@
|
|||
ARM TCM (Tightly-Coupled Memory) handling in Linux
|
||||
----
|
||||
Written by Linus Walleij <linus.walleij@stericsson.com>
|
||||
|
||||
Some ARM SoC:s have a so-called TCM (Tightly-Coupled Memory).
|
||||
This is usually just a few (4-64) KiB of RAM inside the ARM
|
||||
processor.
|
||||
|
||||
Due to being embedded inside the CPU The TCM has a
|
||||
Harvard-architecture, so there is an ITCM (instruction TCM)
|
||||
and a DTCM (data TCM). The DTCM can not contain any
|
||||
instructions, but the ITCM can actually contain data.
|
||||
The size of DTCM or ITCM is minimum 4KiB so the typical
|
||||
minimum configuration is 4KiB ITCM and 4KiB DTCM.
|
||||
|
||||
ARM CPU:s have special registers to read out status, physical
|
||||
location and size of TCM memories. arch/arm/include/asm/cputype.h
|
||||
defines a CPUID_TCM register that you can read out from the
|
||||
system control coprocessor. Documentation from ARM can be found
|
||||
at http://infocenter.arm.com, search for "TCM Status Register"
|
||||
to see documents for all CPUs. Reading this register you can
|
||||
determine if ITCM (bit 0) and/or DTCM (bit 16) is present in the
|
||||
machine.
|
||||
|
||||
There is further a TCM region register (search for "TCM Region
|
||||
Registers" at the ARM site) that can report and modify the location
|
||||
size of TCM memories at runtime. This is used to read out and modify
|
||||
TCM location and size. Notice that this is not a MMU table: you
|
||||
actually move the physical location of the TCM around. At the
|
||||
place you put it, it will mask any underlying RAM from the
|
||||
CPU so it is usually wise not to overlap any physical RAM with
|
||||
the TCM.
|
||||
|
||||
The TCM memory can then be remapped to another address again using
|
||||
the MMU, but notice that the TCM if often used in situations where
|
||||
the MMU is turned off. To avoid confusion the current Linux
|
||||
implementation will map the TCM 1 to 1 from physical to virtual
|
||||
memory in the location specified by the machine.
|
||||
|
||||
TCM is used for a few things:
|
||||
|
||||
- FIQ and other interrupt handlers that need deterministic
|
||||
timing and cannot wait for cache misses.
|
||||
|
||||
- Idle loops where all external RAM is set to self-refresh
|
||||
retention mode, so only on-chip RAM is accessible by
|
||||
the CPU and then we hang inside ITCM waiting for an
|
||||
interrupt.
|
||||
|
||||
- Other operations which implies shutting off or reconfiguring
|
||||
the external RAM controller.
|
||||
|
||||
There is an interface for using TCM on the ARM architecture
|
||||
in <asm/tcm.h>. Using this interface it is possible to:
|
||||
|
||||
- Define the physical address and size of ITCM and DTCM.
|
||||
|
||||
- Tag functions to be compiled into ITCM.
|
||||
|
||||
- Tag data and constants to be allocated to DTCM and ITCM.
|
||||
|
||||
- Have the remaining TCM RAM added to a special
|
||||
allocation pool with gen_pool_create() and gen_pool_add()
|
||||
and provice tcm_alloc() and tcm_free() for this
|
||||
memory. Such a heap is great for things like saving
|
||||
device state when shutting off device power domains.
|
||||
|
||||
A machine that has TCM memory shall select HAVE_TCM in
|
||||
arch/arm/Kconfig for itself, and then the
|
||||
rest of the functionality will depend on the physical
|
||||
location and size of ITCM and DTCM to be defined in
|
||||
mach/memory.h for the machine. Code that needs to use
|
||||
TCM shall #include <asm/tcm.h> If the TCM is not located
|
||||
at the place given in memory.h it will be moved using
|
||||
the TCM Region registers.
|
||||
|
||||
Functions to go into itcm can be tagged like this:
|
||||
int __tcmfunc foo(int bar);
|
||||
|
||||
Variables to go into dtcm can be tagged like this:
|
||||
int __tcmdata foo;
|
||||
|
||||
Constants can be tagged like this:
|
||||
int __tcmconst foo;
|
||||
|
||||
To put assembler into TCM just use
|
||||
.section ".tcm.text" or .section ".tcm.data"
|
||||
respectively.
|
||||
|
||||
Example code:
|
||||
|
||||
#include <asm/tcm.h>
|
||||
|
||||
/* Uninitialized data */
|
||||
static u32 __tcmdata tcmvar;
|
||||
/* Initialized data */
|
||||
static u32 __tcmdata tcmassigned = 0x2BADBABEU;
|
||||
/* Constant */
|
||||
static const u32 __tcmconst tcmconst = 0xCAFEBABEU;
|
||||
|
||||
static void __tcmlocalfunc tcm_to_tcm(void)
|
||||
{
|
||||
int i;
|
||||
for (i = 0; i < 100; i++)
|
||||
tcmvar ++;
|
||||
}
|
||||
|
||||
static void __tcmfunc hello_tcm(void)
|
||||
{
|
||||
/* Some abstract code that runs in ITCM */
|
||||
int i;
|
||||
for (i = 0; i < 100; i++) {
|
||||
tcmvar ++;
|
||||
}
|
||||
tcm_to_tcm();
|
||||
}
|
||||
|
||||
static void __init test_tcm(void)
|
||||
{
|
||||
u32 *tcmem;
|
||||
int i;
|
||||
|
||||
hello_tcm();
|
||||
printk("Hello TCM executed from ITCM RAM\n");
|
||||
|
||||
printk("TCM variable from testrun: %u @ %p\n", tcmvar, &tcmvar);
|
||||
tcmvar = 0xDEADBEEFU;
|
||||
printk("TCM variable: 0x%x @ %p\n", tcmvar, &tcmvar);
|
||||
|
||||
printk("TCM assigned variable: 0x%x @ %p\n", tcmassigned, &tcmassigned);
|
||||
|
||||
printk("TCM constant: 0x%x @ %p\n", tcmconst, &tcmconst);
|
||||
|
||||
/* Allocate some TCM memory from the pool */
|
||||
tcmem = tcm_alloc(20);
|
||||
if (tcmem) {
|
||||
printk("TCM Allocated 20 bytes of TCM @ %p\n", tcmem);
|
||||
tcmem[0] = 0xDEADBEEFU;
|
||||
tcmem[1] = 0x2BADBABEU;
|
||||
tcmem[2] = 0xCAFEBABEU;
|
||||
tcmem[3] = 0xDEADBEEFU;
|
||||
tcmem[4] = 0x2BADBABEU;
|
||||
for (i = 0; i < 5; i++)
|
||||
printk("TCM tcmem[%d] = %08x\n", i, tcmem[i]);
|
||||
tcm_free(tcmem, 20);
|
||||
}
|
||||
}
|
|
@ -194,7 +194,6 @@ static void cfag12864b_blit(void)
|
|||
*/
|
||||
|
||||
#include <stdio.h>
|
||||
#include <string.h>
|
||||
|
||||
#define EXAMPLES 6
|
||||
|
||||
|
|
|
@ -227,7 +227,14 @@ as the path relative to the root of the cgroup file system.
|
|||
Each cgroup is represented by a directory in the cgroup file system
|
||||
containing the following files describing that cgroup:
|
||||
|
||||
- tasks: list of tasks (by pid) attached to that cgroup
|
||||
- tasks: list of tasks (by pid) attached to that cgroup. This list
|
||||
is not guaranteed to be sorted. Writing a thread id into this file
|
||||
moves the thread into this cgroup.
|
||||
- cgroup.procs: list of tgids in the cgroup. This list is not
|
||||
guaranteed to be sorted or free of duplicate tgids, and userspace
|
||||
should sort/uniquify the list if this property is required.
|
||||
Writing a tgid into this file moves all threads with that tgid into
|
||||
this cgroup.
|
||||
- notify_on_release flag: run the release agent on exit?
|
||||
- release_agent: the path to use for release notifications (this file
|
||||
exists in the top cgroup only)
|
||||
|
@ -374,7 +381,7 @@ Now you want to do something with this cgroup.
|
|||
|
||||
In this directory you can find several files:
|
||||
# ls
|
||||
notify_on_release tasks
|
||||
cgroup.procs notify_on_release tasks
|
||||
(plus whatever files added by the attached subsystems)
|
||||
|
||||
Now attach your shell to this cgroup:
|
||||
|
@ -408,6 +415,26 @@ You can attach the current shell task by echoing 0:
|
|||
|
||||
# echo 0 > tasks
|
||||
|
||||
2.3 Mounting hierarchies by name
|
||||
--------------------------------
|
||||
|
||||
Passing the name=<x> option when mounting a cgroups hierarchy
|
||||
associates the given name with the hierarchy. This can be used when
|
||||
mounting a pre-existing hierarchy, in order to refer to it by name
|
||||
rather than by its set of active subsystems. Each hierarchy is either
|
||||
nameless, or has a unique name.
|
||||
|
||||
The name should match [\w.-]+
|
||||
|
||||
When passing a name=<x> option for a new hierarchy, you need to
|
||||
specify subsystems manually; the legacy behaviour of mounting all
|
||||
subsystems when none are explicitly specified is not supported when
|
||||
you give a subsystem a name.
|
||||
|
||||
The name of the subsystem appears as part of the hierarchy description
|
||||
in /proc/mounts and /proc/<pid>/cgroups.
|
||||
|
||||
|
||||
3. Kernel API
|
||||
=============
|
||||
|
||||
|
@ -501,7 +528,7 @@ rmdir() will fail with it. From this behavior, pre_destroy() can be
|
|||
called multiple times against a cgroup.
|
||||
|
||||
int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
|
||||
struct task_struct *task)
|
||||
struct task_struct *task, bool threadgroup)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
Called prior to moving a task into a cgroup; if the subsystem
|
||||
|
@ -509,14 +536,20 @@ returns an error, this will abort the attach operation. If a NULL
|
|||
task is passed, then a successful result indicates that *any*
|
||||
unspecified task can be moved into the cgroup. Note that this isn't
|
||||
called on a fork. If this method returns 0 (success) then this should
|
||||
remain valid while the caller holds cgroup_mutex.
|
||||
remain valid while the caller holds cgroup_mutex. If threadgroup is
|
||||
true, then a successful result indicates that all threads in the given
|
||||
thread's threadgroup can be moved together.
|
||||
|
||||
void attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
|
||||
struct cgroup *old_cgrp, struct task_struct *task)
|
||||
struct cgroup *old_cgrp, struct task_struct *task,
|
||||
bool threadgroup)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
Called after the task has been attached to the cgroup, to allow any
|
||||
post-attachment activity that requires memory allocations or blocking.
|
||||
If threadgroup is true, the subsystem should take care of all threads
|
||||
in the specified thread's threadgroup. Currently does not support any
|
||||
subsystem that might need the old_cgrp for every thread in the group.
|
||||
|
||||
void fork(struct cgroup_subsy *ss, struct task_struct *task)
|
||||
|
||||
|
|
|
@ -179,6 +179,9 @@ The reclaim algorithm has not been modified for cgroups, except that
|
|||
pages that are selected for reclaiming come from the per cgroup LRU
|
||||
list.
|
||||
|
||||
NOTE: Reclaim does not work for the root cgroup, since we cannot set any
|
||||
limits on the root cgroup.
|
||||
|
||||
2. Locking
|
||||
|
||||
The memory controller uses the following hierarchy
|
||||
|
@ -210,6 +213,7 @@ We can alter the memory limit:
|
|||
NOTE: We can use a suffix (k, K, m, M, g or G) to indicate values in kilo,
|
||||
mega or gigabytes.
|
||||
NOTE: We can write "-1" to reset the *.limit_in_bytes(unlimited).
|
||||
NOTE: We cannot set limits on the root cgroup any more.
|
||||
|
||||
# cat /cgroups/0/memory.limit_in_bytes
|
||||
4194304
|
||||
|
@ -375,7 +379,42 @@ cgroups created below it.
|
|||
|
||||
NOTE2: This feature can be enabled/disabled per subtree.
|
||||
|
||||
7. TODO
|
||||
7. Soft limits
|
||||
|
||||
Soft limits allow for greater sharing of memory. The idea behind soft limits
|
||||
is to allow control groups to use as much of the memory as needed, provided
|
||||
|
||||
a. There is no memory contention
|
||||
b. They do not exceed their hard limit
|
||||
|
||||
When the system detects memory contention or low memory control groups
|
||||
are pushed back to their soft limits. If the soft limit of each control
|
||||
group is very high, they are pushed back as much as possible to make
|
||||
sure that one control group does not starve the others of memory.
|
||||
|
||||
Please note that soft limits is a best effort feature, it comes with
|
||||
no guarantees, but it does its best to make sure that when memory is
|
||||
heavily contended for, memory is allocated based on the soft limit
|
||||
hints/setup. Currently soft limit based reclaim is setup such that
|
||||
it gets invoked from balance_pgdat (kswapd).
|
||||
|
||||
7.1 Interface
|
||||
|
||||
Soft limits can be setup by using the following commands (in this example we
|
||||
assume a soft limit of 256 megabytes)
|
||||
|
||||
# echo 256M > memory.soft_limit_in_bytes
|
||||
|
||||
If we want to change this to 1G, we can at any time use
|
||||
|
||||
# echo 1G > memory.soft_limit_in_bytes
|
||||
|
||||
NOTE1: Soft limits take effect over a long period of time, since they involve
|
||||
reclaiming memory for balancing between memory cgroups
|
||||
NOTE2: It is recommended to set the soft limit always below the hard limit,
|
||||
otherwise the hard limit will take precedence.
|
||||
|
||||
8. TODO
|
||||
|
||||
1. Add support for accounting huge pages (as a separate controller)
|
||||
2. Make per-cgroup scanner reclaim not-shared pages first
|
||||
|
|
|
@ -34,7 +34,7 @@ static char cn_test_name[] = "cn_test";
|
|||
static struct sock *nls;
|
||||
static struct timer_list cn_test_timer;
|
||||
|
||||
static void cn_test_callback(struct cn_msg *msg)
|
||||
static void cn_test_callback(struct cn_msg *msg, struct netlink_skb_parms *nsp)
|
||||
{
|
||||
pr_info("%s: %lu: idx=%x, val=%x, seq=%u, ack=%u, len=%d: %s.\n",
|
||||
__func__, jiffies, msg->id.idx, msg->id.val,
|
||||
|
|
|
@ -23,7 +23,7 @@ handling, etc... The Connector driver allows any kernelspace agents to use
|
|||
netlink based networking for inter-process communication in a significantly
|
||||
easier way:
|
||||
|
||||
int cn_add_callback(struct cb_id *id, char *name, void (*callback) (void *));
|
||||
int cn_add_callback(struct cb_id *id, char *name, void (*callback) (struct cn_msg *, struct netlink_skb_parms *));
|
||||
void cn_netlink_send(struct cn_msg *msg, u32 __group, int gfp_mask);
|
||||
|
||||
struct cb_id
|
||||
|
@ -53,15 +53,15 @@ struct cn_msg
|
|||
Connector interfaces.
|
||||
/*****************************************/
|
||||
|
||||
int cn_add_callback(struct cb_id *id, char *name, void (*callback) (void *));
|
||||
int cn_add_callback(struct cb_id *id, char *name, void (*callback) (struct cn_msg *, struct netlink_skb_parms *));
|
||||
|
||||
Registers new callback with connector core.
|
||||
|
||||
struct cb_id *id - unique connector's user identifier.
|
||||
It must be registered in connector.h for legal in-kernel users.
|
||||
char *name - connector's callback symbolic name.
|
||||
void (*callback) (void *) - connector's callback.
|
||||
Argument must be dereferenced to struct cn_msg *.
|
||||
void (*callback) (struct cn..) - connector's callback.
|
||||
cn_msg and the sender's credentials
|
||||
|
||||
|
||||
void cn_del_callback(struct cb_id *id);
|
||||
|
|
|
@ -1,15 +1,28 @@
|
|||
|
||||
Export cpu topology info via sysfs. Items (attributes) are similar
|
||||
Export CPU topology info via sysfs. Items (attributes) are similar
|
||||
to /proc/cpuinfo.
|
||||
|
||||
1) /sys/devices/system/cpu/cpuX/topology/physical_package_id:
|
||||
represent the physical package id of cpu X;
|
||||
|
||||
physical package id of cpuX. Typically corresponds to a physical
|
||||
socket number, but the actual value is architecture and platform
|
||||
dependent.
|
||||
|
||||
2) /sys/devices/system/cpu/cpuX/topology/core_id:
|
||||
represent the cpu core id to cpu X;
|
||||
|
||||
the CPU core ID of cpuX. Typically it is the hardware platform's
|
||||
identifier (rather than the kernel's). The actual value is
|
||||
architecture and platform dependent.
|
||||
|
||||
3) /sys/devices/system/cpu/cpuX/topology/thread_siblings:
|
||||
represent the thread siblings to cpu X in the same core;
|
||||
|
||||
internel kernel map of cpuX's hardware threads within the same
|
||||
core as cpuX
|
||||
|
||||
4) /sys/devices/system/cpu/cpuX/topology/core_siblings:
|
||||
represent the thread siblings to cpu X in the same physical package;
|
||||
|
||||
internal kernel map of cpuX's hardware threads within the same
|
||||
physical_package_id.
|
||||
|
||||
To implement it in an architecture-neutral way, a new source file,
|
||||
drivers/base/topology.c, is to export the 4 attributes.
|
||||
|
@ -32,32 +45,32 @@ not defined by include/asm-XXX/topology.h:
|
|||
3) thread_siblings: just the given CPU
|
||||
4) core_siblings: just the given CPU
|
||||
|
||||
Additionally, cpu topology information is provided under
|
||||
Additionally, CPU topology information is provided under
|
||||
/sys/devices/system/cpu and includes these files. The internal
|
||||
source for the output is in brackets ("[]").
|
||||
|
||||
kernel_max: the maximum cpu index allowed by the kernel configuration.
|
||||
kernel_max: the maximum CPU index allowed by the kernel configuration.
|
||||
[NR_CPUS-1]
|
||||
|
||||
offline: cpus that are not online because they have been
|
||||
offline: CPUs that are not online because they have been
|
||||
HOTPLUGGED off (see cpu-hotplug.txt) or exceed the limit
|
||||
of cpus allowed by the kernel configuration (kernel_max
|
||||
of CPUs allowed by the kernel configuration (kernel_max
|
||||
above). [~cpu_online_mask + cpus >= NR_CPUS]
|
||||
|
||||
online: cpus that are online and being scheduled [cpu_online_mask]
|
||||
online: CPUs that are online and being scheduled [cpu_online_mask]
|
||||
|
||||
possible: cpus that have been allocated resources and can be
|
||||
possible: CPUs that have been allocated resources and can be
|
||||
brought online if they are present. [cpu_possible_mask]
|
||||
|
||||
present: cpus that have been identified as being present in the
|
||||
present: CPUs that have been identified as being present in the
|
||||
system. [cpu_present_mask]
|
||||
|
||||
The format for the above output is compatible with cpulist_parse()
|
||||
[see <linux/cpumask.h>]. Some examples follow.
|
||||
|
||||
In this example, there are 64 cpus in the system but cpus 32-63 exceed
|
||||
In this example, there are 64 CPUs in the system but cpus 32-63 exceed
|
||||
the kernel max which is limited to 0..31 by the NR_CPUS config option
|
||||
being 32. Note also that cpus 2 and 4-31 are not online but could be
|
||||
being 32. Note also that CPUs 2 and 4-31 are not online but could be
|
||||
brought online as they are both present and possible.
|
||||
|
||||
kernel_max: 31
|
||||
|
@ -67,8 +80,8 @@ brought online as they are both present and possible.
|
|||
present: 0-31
|
||||
|
||||
In this example, the NR_CPUS config option is 128, but the kernel was
|
||||
started with possible_cpus=144. There are 4 cpus in the system and cpu2
|
||||
was manually taken offline (and is the only cpu that can be brought
|
||||
started with possible_cpus=144. There are 4 CPUs in the system and cpu2
|
||||
was manually taken offline (and is the only CPU that can be brought
|
||||
online.)
|
||||
|
||||
kernel_max: 127
|
||||
|
@ -78,4 +91,4 @@ online.)
|
|||
present: 0-3
|
||||
|
||||
See cpu-hotplug.txt for the possible_cpus=NUM kernel start parameter
|
||||
as well as more information on the various cpumask's.
|
||||
as well as more information on the various cpumasks.
|
||||
|
|
|
@ -54,20 +54,23 @@ features surfaced as a result:
|
|||
|
||||
3.1 General format of the API:
|
||||
struct dma_async_tx_descriptor *
|
||||
async_<operation>(<op specific parameters>,
|
||||
enum async_tx_flags flags,
|
||||
struct dma_async_tx_descriptor *dependency,
|
||||
dma_async_tx_callback callback_routine,
|
||||
void *callback_parameter);
|
||||
async_<operation>(<op specific parameters>, struct async_submit ctl *submit)
|
||||
|
||||
3.2 Supported operations:
|
||||
memcpy - memory copy between a source and a destination buffer
|
||||
memset - fill a destination buffer with a byte value
|
||||
xor - xor a series of source buffers and write the result to a
|
||||
destination buffer
|
||||
xor_zero_sum - xor a series of source buffers and set a flag if the
|
||||
result is zero. The implementation attempts to prevent
|
||||
writes to memory
|
||||
memcpy - memory copy between a source and a destination buffer
|
||||
memset - fill a destination buffer with a byte value
|
||||
xor - xor a series of source buffers and write the result to a
|
||||
destination buffer
|
||||
xor_val - xor a series of source buffers and set a flag if the
|
||||
result is zero. The implementation attempts to prevent
|
||||
writes to memory
|
||||
pq - generate the p+q (raid6 syndrome) from a series of source buffers
|
||||
pq_val - validate that a p and or q buffer are in sync with a given series of
|
||||
sources
|
||||
datap - (raid6_datap_recov) recover a raid6 data block and the p block
|
||||
from the given sources
|
||||
2data - (raid6_2data_recov) recover 2 raid6 data blocks from the given
|
||||
sources
|
||||
|
||||
3.3 Descriptor management:
|
||||
The return value is non-NULL and points to a 'descriptor' when the operation
|
||||
|
@ -80,8 +83,8 @@ acknowledged by the application before the offload engine driver is allowed to
|
|||
recycle (or free) the descriptor. A descriptor can be acked by one of the
|
||||
following methods:
|
||||
1/ setting the ASYNC_TX_ACK flag if no child operations are to be submitted
|
||||
2/ setting the ASYNC_TX_DEP_ACK flag to acknowledge the parent
|
||||
descriptor of a new operation.
|
||||
2/ submitting an unacknowledged descriptor as a dependency to another
|
||||
async_tx call will implicitly set the acknowledged state.
|
||||
3/ calling async_tx_ack() on the descriptor.
|
||||
|
||||
3.4 When does the operation execute?
|
||||
|
@ -119,30 +122,42 @@ of an operation.
|
|||
Perform a xor->copy->xor operation where each operation depends on the
|
||||
result from the previous operation:
|
||||
|
||||
void complete_xor_copy_xor(void *param)
|
||||
void callback(void *param)
|
||||
{
|
||||
printk("complete\n");
|
||||
struct completion *cmp = param;
|
||||
|
||||
complete(cmp);
|
||||
}
|
||||
|
||||
int run_xor_copy_xor(struct page **xor_srcs,
|
||||
int xor_src_cnt,
|
||||
struct page *xor_dest,
|
||||
size_t xor_len,
|
||||
struct page *copy_src,
|
||||
struct page *copy_dest,
|
||||
size_t copy_len)
|
||||
void run_xor_copy_xor(struct page **xor_srcs,
|
||||
int xor_src_cnt,
|
||||
struct page *xor_dest,
|
||||
size_t xor_len,
|
||||
struct page *copy_src,
|
||||
struct page *copy_dest,
|
||||
size_t copy_len)
|
||||
{
|
||||
struct dma_async_tx_descriptor *tx;
|
||||
addr_conv_t addr_conv[xor_src_cnt];
|
||||
struct async_submit_ctl submit;
|
||||
addr_conv_t addr_conv[NDISKS];
|
||||
struct completion cmp;
|
||||
|
||||
tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len,
|
||||
ASYNC_TX_XOR_DROP_DST, NULL, NULL, NULL);
|
||||
tx = async_memcpy(copy_dest, copy_src, 0, 0, copy_len,
|
||||
ASYNC_TX_DEP_ACK, tx, NULL, NULL);
|
||||
tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len,
|
||||
ASYNC_TX_XOR_DROP_DST | ASYNC_TX_DEP_ACK | ASYNC_TX_ACK,
|
||||
tx, complete_xor_copy_xor, NULL);
|
||||
init_async_submit(&submit, ASYNC_TX_XOR_DROP_DST, NULL, NULL, NULL,
|
||||
addr_conv);
|
||||
tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len, &submit)
|
||||
|
||||
submit->depend_tx = tx;
|
||||
tx = async_memcpy(copy_dest, copy_src, 0, 0, copy_len, &submit);
|
||||
|
||||
init_completion(&cmp);
|
||||
init_async_submit(&submit, ASYNC_TX_XOR_DROP_DST | ASYNC_TX_ACK, tx,
|
||||
callback, &cmp, addr_conv);
|
||||
tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len, &submit);
|
||||
|
||||
async_tx_issue_pending_all();
|
||||
|
||||
wait_for_completion(&cmp);
|
||||
}
|
||||
|
||||
See include/linux/async_tx.h for more information on the flags. See the
|
||||
|
|
|
@ -64,14 +64,14 @@ be used to view the printk buffer of a remote machine, even with live update.
|
|||
|
||||
Bernhard Kaindl enhanced firescope to support accessing 64-bit machines
|
||||
from 32-bit firescope and vice versa:
|
||||
- ftp://ftp.suse.de/private/bk/firewire/tools/firescope-0.2.2.tar.bz2
|
||||
- http://halobates.de/firewire/firescope-0.2.2.tar.bz2
|
||||
|
||||
and he implemented fast system dump (alpha version - read README.txt):
|
||||
- ftp://ftp.suse.de/private/bk/firewire/tools/firedump-0.1.tar.bz2
|
||||
- http://halobates.de/firewire/firedump-0.1.tar.bz2
|
||||
|
||||
There is also a gdb proxy for firewire which allows to use gdb to access
|
||||
data which can be referenced from symbols found by gdb in vmlinux:
|
||||
- ftp://ftp.suse.de/private/bk/firewire/tools/fireproxy-0.33.tar.bz2
|
||||
- http://halobates.de/firewire/fireproxy-0.33.tar.bz2
|
||||
|
||||
The latest version of this gdb proxy (fireproxy-0.34) can communicate (not
|
||||
yet stable) with kgdb over an memory-based communication module (kgdbom).
|
||||
|
@ -178,7 +178,7 @@ Step-by-step instructions for using firescope with early OHCI initialization:
|
|||
|
||||
Notes
|
||||
-----
|
||||
Documentation and specifications: ftp://ftp.suse.de/private/bk/firewire/docs
|
||||
Documentation and specifications: http://halobates.de/firewire/
|
||||
|
||||
FireWire is a trademark of Apple Inc. - for more information please refer to:
|
||||
http://en.wikipedia.org/wiki/FireWire
|
||||
|
|
|
@ -65,6 +65,7 @@ aicdb.h*
|
|||
asm-offsets.h
|
||||
asm_offsets.h
|
||||
autoconf.h*
|
||||
av_permissions.h
|
||||
bbootsect
|
||||
bin2c
|
||||
binkernel.spec
|
||||
|
@ -95,12 +96,14 @@ docproc
|
|||
elf2ecoff
|
||||
elfconfig.h*
|
||||
fixdep
|
||||
flask.h
|
||||
fore200e_mkfirm
|
||||
fore200e_pca_fw.c*
|
||||
gconf
|
||||
gen-devlist
|
||||
gen_crc32table
|
||||
gen_init_cpio
|
||||
genheaders
|
||||
genksyms
|
||||
*_gray256.c
|
||||
ihex2fw
|
||||
|
|
|
@ -312,10 +312,8 @@ and to the following documentation:
|
|||
8. Mailing list
|
||||
---------------
|
||||
|
||||
There are several frame buffer device related mailing lists at SourceForge:
|
||||
- linux-fbdev-announce@lists.sourceforge.net, for announcements,
|
||||
- linux-fbdev-user@lists.sourceforge.net, for generic user support,
|
||||
- linux-fbdev-devel@lists.sourceforge.net, for project developers.
|
||||
There is a frame buffer device related mailing list at kernel.org:
|
||||
linux-fbdev@vger.kernel.org.
|
||||
|
||||
Point your web browser to http://sourceforge.net/projects/linux-fbdev/ for
|
||||
subscription information and archive browsing.
|
||||
|
|
|
@ -354,14 +354,6 @@ Who: Krzysztof Piotr Oledzki <ole@ans.pl>
|
|||
|
||||
---------------------------
|
||||
|
||||
What: fscher and fscpos drivers
|
||||
When: June 2009
|
||||
Why: Deprecated by the new fschmd driver.
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: sysfs ui for changing p4-clockmod parameters
|
||||
When: September 2009
|
||||
Why: See commits 129f8ae9b1b5be94517da76009ea956e89104ce8 and
|
||||
|
@ -426,6 +418,14 @@ When: 2.6.33
|
|||
Why: Should be implemented in userspace, policy daemon.
|
||||
Who: Johannes Berg <johannes@sipsolutions.net>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: CONFIG_INOTIFY
|
||||
When: 2.6.33
|
||||
Why: last user (audit) will be converted to the newer more generic
|
||||
and more easily maintained fsnotify subsystem
|
||||
Who: Eric Paris <eparis@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: lock_policy_rwsem_* and unlock_policy_rwsem_* will not be
|
||||
|
@ -459,3 +459,33 @@ Why: OSS sound_core grabs all legacy minors (0-255) of SOUND_MAJOR
|
|||
will also allow making ALSA OSS emulation independent of
|
||||
sound_core. The dependency will be broken then too.
|
||||
Who: Tejun Heo <tj@kernel.org>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: Support for VMware's guest paravirtuliazation technique [VMI] will be
|
||||
dropped.
|
||||
When: 2.6.37 or earlier.
|
||||
Why: With the recent innovations in CPU hardware acceleration technologies
|
||||
from Intel and AMD, VMware ran a few experiments to compare these
|
||||
techniques to guest paravirtualization technique on VMware's platform.
|
||||
These hardware assisted virtualization techniques have outperformed the
|
||||
performance benefits provided by VMI in most of the workloads. VMware
|
||||
expects that these hardware features will be ubiquitous in a couple of
|
||||
years, as a result, VMware has started a phased retirement of this
|
||||
feature from the hypervisor. We will be removing this feature from the
|
||||
Kernel too. Right now we are targeting 2.6.37 but can retire earlier if
|
||||
technical reasons (read opportunity to remove major chunk of pvops)
|
||||
arise.
|
||||
|
||||
Please note that VMI has always been an optimization and non-VMI kernels
|
||||
still work fine on VMware's platform.
|
||||
Latest versions of VMware's product which support VMI are,
|
||||
Workstation 7.0 and VSphere 4.0 on ESX side, future maintainence
|
||||
releases for these products will continue supporting VMI.
|
||||
|
||||
For more details about VMI retirement take a look at this,
|
||||
http://blogs.vmware.com/guestosguide/2009/09/vmi-retirement.html
|
||||
|
||||
Who: Alok N Kataria <akataria@vmware.com>
|
||||
|
||||
----------------------------
|
||||
|
|
|
@ -18,11 +18,11 @@ the 9p client is available in the form of a USENIX paper:
|
|||
|
||||
Other applications are described in the following papers:
|
||||
* XCPU & Clustering
|
||||
http://www.xcpu.org/xcpu-talk.pdf
|
||||
http://xcpu.org/papers/xcpu-talk.pdf
|
||||
* KVMFS: control file system for KVM
|
||||
http://www.xcpu.org/kvmfs.pdf
|
||||
* CellFS: A New ProgrammingModel for the Cell BE
|
||||
http://www.xcpu.org/cellfs-talk.pdf
|
||||
http://xcpu.org/papers/kvmfs.pdf
|
||||
* CellFS: A New Programming Model for the Cell BE
|
||||
http://xcpu.org/papers/cellfs-talk.pdf
|
||||
* PROSE I/O: Using 9p to enable Application Partitions
|
||||
http://plan9.escet.urjc.es/iwp9/cready/PROSE_iwp9_2006.pdf
|
||||
|
||||
|
@ -48,6 +48,7 @@ OPTIONS
|
|||
(see rfdno and wfdno)
|
||||
virtio - connect to the next virtio channel available
|
||||
(from lguest or KVM with trans_virtio module)
|
||||
rdma - connect to a specified RDMA channel
|
||||
|
||||
uname=name user name to attempt mount as on the remote server. The
|
||||
server may override or ignore this value. Certain user
|
||||
|
@ -59,16 +60,22 @@ OPTIONS
|
|||
cache=mode specifies a caching policy. By default, no caches are used.
|
||||
loose = no attempts are made at consistency,
|
||||
intended for exclusive, read-only mounts
|
||||
fscache = use FS-Cache for a persistent, read-only
|
||||
cache backend.
|
||||
|
||||
debug=n specifies debug level. The debug level is a bitmask.
|
||||
0x01 = display verbose error messages
|
||||
0x02 = developer debug (DEBUG_CURRENT)
|
||||
0x04 = display 9p trace
|
||||
0x08 = display VFS trace
|
||||
0x10 = display Marshalling debug
|
||||
0x20 = display RPC debug
|
||||
0x40 = display transport debug
|
||||
0x80 = display allocation debug
|
||||
0x01 = display verbose error messages
|
||||
0x02 = developer debug (DEBUG_CURRENT)
|
||||
0x04 = display 9p trace
|
||||
0x08 = display VFS trace
|
||||
0x10 = display Marshalling debug
|
||||
0x20 = display RPC debug
|
||||
0x40 = display transport debug
|
||||
0x80 = display allocation debug
|
||||
0x100 = display protocol message debug
|
||||
0x200 = display Fid debug
|
||||
0x400 = display packet debug
|
||||
0x800 = display fscache tracing debug
|
||||
|
||||
rfdno=n the file descriptor for reading with trans=fd
|
||||
|
||||
|
@ -100,6 +107,10 @@ OPTIONS
|
|||
any = v9fs does single attach and performs all
|
||||
operations as one user
|
||||
|
||||
cachetag cache tag to use the specified persistent cache.
|
||||
cache tags for existing cache sessions can be listed at
|
||||
/sys/fs/9p/caches. (applies only to cache=fscache)
|
||||
|
||||
RESOURCES
|
||||
=========
|
||||
|
||||
|
@ -118,7 +129,7 @@ and export.
|
|||
A Linux version of the 9p server is now maintained under the npfs project
|
||||
on sourceforge (http://sourceforge.net/projects/npfs). The currently
|
||||
maintained version is the single-threaded version of the server (named spfs)
|
||||
available from the same CVS repository.
|
||||
available from the same SVN repository.
|
||||
|
||||
There are user and developer mailing lists available through the v9fs project
|
||||
on sourceforge (http://sourceforge.net/projects/v9fs).
|
||||
|
@ -126,7 +137,8 @@ on sourceforge (http://sourceforge.net/projects/v9fs).
|
|||
A stand-alone version of the module (which should build for any 2.6 kernel)
|
||||
is available via (http://github.com/ericvh/9p-sac/tree/master)
|
||||
|
||||
News and other information is maintained on SWiK (http://swik.net/v9fs).
|
||||
News and other information is maintained on SWiK (http://swik.net/v9fs)
|
||||
and the Wiki (http://sf.net/apps/mediawiki/v9fs/index.php).
|
||||
|
||||
Bug reports may be issued through the kernel.org bugzilla
|
||||
(http://bugzilla.kernel.org)
|
||||
|
|
|
@ -235,6 +235,7 @@ proc files.
|
|||
neg=N Number of negative lookups made
|
||||
pos=N Number of positive lookups made
|
||||
crt=N Number of objects created by lookup
|
||||
tmo=N Number of lookups timed out and requeued
|
||||
Updates n=N Number of update cookie requests seen
|
||||
nul=N Number of upd reqs given a NULL parent
|
||||
run=N Number of upd reqs granted CPU time
|
||||
|
@ -250,8 +251,10 @@ proc files.
|
|||
ok=N Number of successful alloc reqs
|
||||
wt=N Number of alloc reqs that waited on lookup completion
|
||||
nbf=N Number of alloc reqs rejected -ENOBUFS
|
||||
int=N Number of alloc reqs aborted -ERESTARTSYS
|
||||
ops=N Number of alloc reqs submitted
|
||||
owt=N Number of alloc reqs waited for CPU time
|
||||
abt=N Number of alloc reqs aborted due to object death
|
||||
Retrvls n=N Number of retrieval (read) requests seen
|
||||
ok=N Number of successful retr reqs
|
||||
wt=N Number of retr reqs that waited on lookup completion
|
||||
|
@ -261,6 +264,7 @@ proc files.
|
|||
oom=N Number of retr reqs failed -ENOMEM
|
||||
ops=N Number of retr reqs submitted
|
||||
owt=N Number of retr reqs waited for CPU time
|
||||
abt=N Number of retr reqs aborted due to object death
|
||||
Stores n=N Number of storage (write) requests seen
|
||||
ok=N Number of successful store reqs
|
||||
agn=N Number of store reqs on a page already pending storage
|
||||
|
@ -268,12 +272,37 @@ proc files.
|
|||
oom=N Number of store reqs failed -ENOMEM
|
||||
ops=N Number of store reqs submitted
|
||||
run=N Number of store reqs granted CPU time
|
||||
pgs=N Number of pages given store req processing time
|
||||
rxd=N Number of store reqs deleted from tracking tree
|
||||
olm=N Number of store reqs over store limit
|
||||
VmScan nos=N Number of release reqs against pages with no pending store
|
||||
gon=N Number of release reqs against pages stored by time lock granted
|
||||
bsy=N Number of release reqs ignored due to in-progress store
|
||||
can=N Number of page stores cancelled due to release req
|
||||
Ops pend=N Number of times async ops added to pending queues
|
||||
run=N Number of times async ops given CPU time
|
||||
enq=N Number of times async ops queued for processing
|
||||
can=N Number of async ops cancelled
|
||||
rej=N Number of async ops rejected due to object lookup/create failure
|
||||
dfr=N Number of async ops queued for deferred release
|
||||
rel=N Number of async ops released
|
||||
gc=N Number of deferred-release async ops garbage collected
|
||||
CacheOp alo=N Number of in-progress alloc_object() cache ops
|
||||
luo=N Number of in-progress lookup_object() cache ops
|
||||
luc=N Number of in-progress lookup_complete() cache ops
|
||||
gro=N Number of in-progress grab_object() cache ops
|
||||
upo=N Number of in-progress update_object() cache ops
|
||||
dro=N Number of in-progress drop_object() cache ops
|
||||
pto=N Number of in-progress put_object() cache ops
|
||||
syn=N Number of in-progress sync_cache() cache ops
|
||||
atc=N Number of in-progress attr_changed() cache ops
|
||||
rap=N Number of in-progress read_or_alloc_page() cache ops
|
||||
ras=N Number of in-progress read_or_alloc_pages() cache ops
|
||||
alp=N Number of in-progress allocate_page() cache ops
|
||||
als=N Number of in-progress allocate_pages() cache ops
|
||||
wrp=N Number of in-progress write_page() cache ops
|
||||
ucp=N Number of in-progress uncache_page() cache ops
|
||||
dsp=N Number of in-progress dissociate_pages() cache ops
|
||||
|
||||
|
||||
(*) /proc/fs/fscache/histogram
|
||||
|
@ -299,6 +328,87 @@ proc files.
|
|||
jiffy range covered, and the SECS field the equivalent number of seconds.
|
||||
|
||||
|
||||
===========
|
||||
OBJECT LIST
|
||||
===========
|
||||
|
||||
If CONFIG_FSCACHE_OBJECT_LIST is enabled, the FS-Cache facility will maintain a
|
||||
list of all the objects currently allocated and allow them to be viewed
|
||||
through:
|
||||
|
||||
/proc/fs/fscache/objects
|
||||
|
||||
This will look something like:
|
||||
|
||||
[root@andromeda ~]# head /proc/fs/fscache/objects
|
||||
OBJECT PARENT STAT CHLDN OPS OOP IPR EX READS EM EV F S | NETFS_COOKIE_DEF TY FL NETFS_DATA OBJECT_KEY, AUX_DATA
|
||||
======== ======== ==== ===== === === === == ===== == == = = | ================ == == ================ ================
|
||||
17e4b 2 ACTV 0 0 0 0 0 0 7b 4 0 8 | NFS.fh DT 0 ffff88001dd82820 010006017edcf8bbc93b43298fdfbe71e50b57b13a172c0117f38472, e567634700000000000000000000000063f2404a000000000000000000000000c9030000000000000000000063f2404a
|
||||
1693a 2 ACTV 0 0 0 0 0 0 7b 4 0 8 | NFS.fh DT 0 ffff88002db23380 010006017edcf8bbc93b43298fdfbe71e50b57b1e0162c01a2df0ea6, 420ebc4a000000000000000000000000420ebc4a0000000000000000000000000e1801000000000000000000420ebc4a
|
||||
|
||||
where the first set of columns before the '|' describe the object:
|
||||
|
||||
COLUMN DESCRIPTION
|
||||
======= ===============================================================
|
||||
OBJECT Object debugging ID (appears as OBJ%x in some debug messages)
|
||||
PARENT Debugging ID of parent object
|
||||
STAT Object state
|
||||
CHLDN Number of child objects of this object
|
||||
OPS Number of outstanding operations on this object
|
||||
OOP Number of outstanding child object management operations
|
||||
IPR
|
||||
EX Number of outstanding exclusive operations
|
||||
READS Number of outstanding read operations
|
||||
EM Object's event mask
|
||||
EV Events raised on this object
|
||||
F Object flags
|
||||
S Object slow-work work item flags
|
||||
|
||||
and the second set of columns describe the object's cookie, if present:
|
||||
|
||||
COLUMN DESCRIPTION
|
||||
=============== =======================================================
|
||||
NETFS_COOKIE_DEF Name of netfs cookie definition
|
||||
TY Cookie type (IX - index, DT - data, hex - special)
|
||||
FL Cookie flags
|
||||
NETFS_DATA Netfs private data stored in the cookie
|
||||
OBJECT_KEY Object key } 1 column, with separating comma
|
||||
AUX_DATA Object aux data } presence may be configured
|
||||
|
||||
The data shown may be filtered by attaching the a key to an appropriate keyring
|
||||
before viewing the file. Something like:
|
||||
|
||||
keyctl add user fscache:objlist <restrictions> @s
|
||||
|
||||
where <restrictions> are a selection of the following letters:
|
||||
|
||||
K Show hexdump of object key (don't show if not given)
|
||||
A Show hexdump of object aux data (don't show if not given)
|
||||
|
||||
and the following paired letters:
|
||||
|
||||
C Show objects that have a cookie
|
||||
c Show objects that don't have a cookie
|
||||
B Show objects that are busy
|
||||
b Show objects that aren't busy
|
||||
W Show objects that have pending writes
|
||||
w Show objects that don't have pending writes
|
||||
R Show objects that have outstanding reads
|
||||
r Show objects that don't have outstanding reads
|
||||
S Show objects that have slow work queued
|
||||
s Show objects that don't have slow work queued
|
||||
|
||||
If neither side of a letter pair is given, then both are implied. For example:
|
||||
|
||||
keyctl add user fscache:objlist KB @s
|
||||
|
||||
shows objects that are busy, and lists their object keys, but does not dump
|
||||
their auxiliary data. It also implies "CcWwRrSs", but as 'B' is given, 'b' is
|
||||
not implied.
|
||||
|
||||
By default all objects and all fields will be shown.
|
||||
|
||||
|
||||
=========
|
||||
DEBUGGING
|
||||
=========
|
||||
|
|
|
@ -641,7 +641,7 @@ data file must be retired (see the relinquish cookie function below).
|
|||
|
||||
Furthermore, note that this does not cancel the asynchronous read or write
|
||||
operation started by the read/alloc and write functions, so the page
|
||||
invalidation and release functions must use:
|
||||
invalidation functions must use:
|
||||
|
||||
bool fscache_check_page_write(struct fscache_cookie *cookie,
|
||||
struct page *page);
|
||||
|
@ -654,6 +654,25 @@ to see if a page is being written to the cache, and:
|
|||
to wait for it to finish if it is.
|
||||
|
||||
|
||||
When releasepage() is being implemented, a special FS-Cache function exists to
|
||||
manage the heuristics of coping with vmscan trying to eject pages, which may
|
||||
conflict with the cache trying to write pages to the cache (which may itself
|
||||
need to allocate memory):
|
||||
|
||||
bool fscache_maybe_release_page(struct fscache_cookie *cookie,
|
||||
struct page *page,
|
||||
gfp_t gfp);
|
||||
|
||||
This takes the netfs cookie, and the page and gfp arguments as supplied to
|
||||
releasepage(). It will return false if the page cannot be released yet for
|
||||
some reason and if it returns true, the page has been uncached and can now be
|
||||
released.
|
||||
|
||||
To make a page available for release, this function may wait for an outstanding
|
||||
storage request to complete, or it may attempt to cancel the storage request -
|
||||
in which case the page will not be stored in the cache this time.
|
||||
|
||||
|
||||
==========================
|
||||
INDEX AND DATA FILE UPDATE
|
||||
==========================
|
||||
|
|
|
@ -123,10 +123,18 @@ resuid=n The user ID which may use the reserved blocks.
|
|||
|
||||
sb=n Use alternate superblock at this location.
|
||||
|
||||
quota
|
||||
noquota
|
||||
grpquota
|
||||
usrquota
|
||||
quota These options are ignored by the filesystem. They
|
||||
noquota are used only by quota tools to recognize volumes
|
||||
grpquota where quota should be turned on. See documentation
|
||||
usrquota in the quota-tools package for more details
|
||||
(http://sourceforge.net/projects/linuxquota).
|
||||
|
||||
jqfmt=<quota type> These options tell filesystem details about quota
|
||||
usrjquota=<file> so that quota information can be properly updated
|
||||
grpjquota=<file> during journal replay. They replace the above
|
||||
quota options. See documentation in the quota-tools
|
||||
package for more details
|
||||
(http://sourceforge.net/projects/linuxquota).
|
||||
|
||||
bh (*) ext3 associates buffer heads to data pages to
|
||||
nobh (a) cache disk block mapping information
|
||||
|
|
|
@ -134,9 +134,15 @@ ro Mount filesystem read only. Note that ext4 will
|
|||
mount options "ro,noload" can be used to prevent
|
||||
writes to the filesystem.
|
||||
|
||||
journal_checksum Enable checksumming of the journal transactions.
|
||||
This will allow the recovery code in e2fsck and the
|
||||
kernel to detect corruption in the kernel. It is a
|
||||
compatible change and will be ignored by older kernels.
|
||||
|
||||
journal_async_commit Commit block can be written to disk without waiting
|
||||
for descriptor blocks. If enabled older kernels cannot
|
||||
mount the device.
|
||||
mount the device. This will enable 'journal_checksum'
|
||||
internally.
|
||||
|
||||
journal=update Update the ext4 file system's journal to the current
|
||||
format.
|
||||
|
@ -282,9 +288,16 @@ stripe=n Number of filesystem blocks that mballoc will try
|
|||
to use for allocation size and alignment. For RAID5/6
|
||||
systems this should be the number of data
|
||||
disks * RAID chunk size in file system blocks.
|
||||
delalloc (*) Deferring block allocation until write-out time.
|
||||
nodelalloc Disable delayed allocation. Blocks are allocation
|
||||
when data is copied from user to page cache.
|
||||
|
||||
delalloc (*) Defer block allocation until just before ext4
|
||||
writes out the block(s) in question. This
|
||||
allows ext4 to better allocation decisions
|
||||
more efficiently.
|
||||
nodelalloc Disable delayed allocation. Blocks are allocated
|
||||
when the data is copied from userspace to the
|
||||
page cache, either via the write(2) system call
|
||||
or when an mmap'ed page which was previously
|
||||
unallocated is written for the first time.
|
||||
|
||||
max_batch_time=usec Maximum amount of time ext4 should wait for
|
||||
additional filesystem operations to be batch
|
||||
|
|
|
@ -20,15 +20,16 @@ Lots of code taken from ext3 and other projects.
|
|||
Authors in alphabetical order:
|
||||
Joel Becker <joel.becker@oracle.com>
|
||||
Zach Brown <zach.brown@oracle.com>
|
||||
Mark Fasheh <mark.fasheh@oracle.com>
|
||||
Mark Fasheh <mfasheh@suse.com>
|
||||
Kurt Hackel <kurt.hackel@oracle.com>
|
||||
Tao Ma <tao.ma@oracle.com>
|
||||
Sunil Mushran <sunil.mushran@oracle.com>
|
||||
Manish Singh <manish.singh@oracle.com>
|
||||
Tiger Yang <tiger.yang@oracle.com>
|
||||
|
||||
Caveats
|
||||
=======
|
||||
Features which OCFS2 does not support yet:
|
||||
- quotas
|
||||
- Directory change notification (F_NOTIFY)
|
||||
- Distributed Caching (F_SETLEASE/F_GETLEASE/break_lease)
|
||||
|
||||
|
@ -70,7 +71,6 @@ commit=nrsec (*) Ocfs2 can be told to sync all its data and metadata
|
|||
performance.
|
||||
localalloc=8(*) Allows custom localalloc size in MB. If the value is too
|
||||
large, the fs will silently revert it to the default.
|
||||
Localalloc is not enabled for local mounts.
|
||||
localflocks This disables cluster aware flock.
|
||||
inode64 Indicates that Ocfs2 is allowed to create inodes at
|
||||
any location in the filesystem, including those which
|
||||
|
|
|
@ -1113,7 +1113,6 @@ Table 1-12: Files in /proc/fs/ext4/<devname>
|
|||
..............................................................................
|
||||
File Content
|
||||
mb_groups details of multiblock allocator buddy cache of free blocks
|
||||
mb_history multiblock allocation history
|
||||
..............................................................................
|
||||
|
||||
|
||||
|
|
|
@ -4,7 +4,7 @@ Shared Subtrees
|
|||
Contents:
|
||||
1) Overview
|
||||
2) Features
|
||||
3) smount command
|
||||
3) Setting mount states
|
||||
4) Use-case
|
||||
5) Detailed semantics
|
||||
6) Quiz
|
||||
|
@ -41,14 +41,14 @@ replicas continue to be exactly same.
|
|||
|
||||
Here is an example:
|
||||
|
||||
Lets say /mnt has a mount that is shared.
|
||||
Let's say /mnt has a mount that is shared.
|
||||
mount --make-shared /mnt
|
||||
|
||||
note: mount command does not yet support the --make-shared flag.
|
||||
I have included a small C program which does the same by executing
|
||||
'smount /mnt shared'
|
||||
Note: mount(8) command now supports the --make-shared flag,
|
||||
so the sample 'smount' program is no longer needed and has been
|
||||
removed.
|
||||
|
||||
#mount --bind /mnt /tmp
|
||||
# mount --bind /mnt /tmp
|
||||
The above command replicates the mount at /mnt to the mountpoint /tmp
|
||||
and the contents of both the mounts remain identical.
|
||||
|
||||
|
@ -58,8 +58,8 @@ replicas continue to be exactly same.
|
|||
#ls /tmp
|
||||
a b c
|
||||
|
||||
Now lets say we mount a device at /tmp/a
|
||||
#mount /dev/sd0 /tmp/a
|
||||
Now let's say we mount a device at /tmp/a
|
||||
# mount /dev/sd0 /tmp/a
|
||||
|
||||
#ls /tmp/a
|
||||
t1 t2 t2
|
||||
|
@ -80,21 +80,20 @@ replicas continue to be exactly same.
|
|||
|
||||
Here is an example:
|
||||
|
||||
Lets say /mnt has a mount which is shared.
|
||||
#mount --make-shared /mnt
|
||||
Let's say /mnt has a mount which is shared.
|
||||
# mount --make-shared /mnt
|
||||
|
||||
Lets bind mount /mnt to /tmp
|
||||
#mount --bind /mnt /tmp
|
||||
Let's bind mount /mnt to /tmp
|
||||
# mount --bind /mnt /tmp
|
||||
|
||||
the new mount at /tmp becomes a shared mount and it is a replica of
|
||||
the mount at /mnt.
|
||||
|
||||
Now lets make the mount at /tmp; a slave of /mnt
|
||||
#mount --make-slave /tmp
|
||||
[or smount /tmp slave]
|
||||
Now let's make the mount at /tmp; a slave of /mnt
|
||||
# mount --make-slave /tmp
|
||||
|
||||
lets mount /dev/sd0 on /mnt/a
|
||||
#mount /dev/sd0 /mnt/a
|
||||
let's mount /dev/sd0 on /mnt/a
|
||||
# mount /dev/sd0 /mnt/a
|
||||
|
||||
#ls /mnt/a
|
||||
t1 t2 t3
|
||||
|
@ -104,9 +103,9 @@ replicas continue to be exactly same.
|
|||
|
||||
Note the mount event has propagated to the mount at /tmp
|
||||
|
||||
However lets see what happens if we mount something on the mount at /tmp
|
||||
However let's see what happens if we mount something on the mount at /tmp
|
||||
|
||||
#mount /dev/sd1 /tmp/b
|
||||
# mount /dev/sd1 /tmp/b
|
||||
|
||||
#ls /tmp/b
|
||||
s1 s2 s3
|
||||
|
@ -124,12 +123,11 @@ replicas continue to be exactly same.
|
|||
|
||||
2d) A unbindable mount is a unbindable private mount
|
||||
|
||||
lets say we have a mount at /mnt and we make is unbindable
|
||||
let's say we have a mount at /mnt and we make is unbindable
|
||||
|
||||
#mount --make-unbindable /mnt
|
||||
[ smount /mnt unbindable ]
|
||||
# mount --make-unbindable /mnt
|
||||
|
||||
Lets try to bind mount this mount somewhere else.
|
||||
Let's try to bind mount this mount somewhere else.
|
||||
# mount --bind /mnt /tmp
|
||||
mount: wrong fs type, bad option, bad superblock on /mnt,
|
||||
or too many mounted file systems
|
||||
|
@ -137,149 +135,15 @@ replicas continue to be exactly same.
|
|||
Binding a unbindable mount is a invalid operation.
|
||||
|
||||
|
||||
3) smount command
|
||||
3) Setting mount states
|
||||
|
||||
Currently the mount command is not aware of shared subtree features.
|
||||
Work is in progress to add the support in mount ( util-linux package ).
|
||||
Till then use the following program.
|
||||
The mount command (util-linux package) can be used to set mount
|
||||
states:
|
||||
|
||||
------------------------------------------------------------------------
|
||||
//
|
||||
//this code was developed my Miklos Szeredi <miklos@szeredi.hu>
|
||||
//and modified by Ram Pai <linuxram@us.ibm.com>
|
||||
// sample usage:
|
||||
// smount /tmp shared
|
||||
//
|
||||
#include <stdio.h>
|
||||
#include <stdlib.h>
|
||||
#include <unistd.h>
|
||||
#include <string.h>
|
||||
#include <sys/mount.h>
|
||||
#include <sys/fsuid.h>
|
||||
|
||||
#ifndef MS_REC
|
||||
#define MS_REC 0x4000 /* 16384: Recursive loopback */
|
||||
#endif
|
||||
|
||||
#ifndef MS_SHARED
|
||||
#define MS_SHARED 1<<20 /* Shared */
|
||||
#endif
|
||||
|
||||
#ifndef MS_PRIVATE
|
||||
#define MS_PRIVATE 1<<18 /* Private */
|
||||
#endif
|
||||
|
||||
#ifndef MS_SLAVE
|
||||
#define MS_SLAVE 1<<19 /* Slave */
|
||||
#endif
|
||||
|
||||
#ifndef MS_UNBINDABLE
|
||||
#define MS_UNBINDABLE 1<<17 /* Unbindable */
|
||||
#endif
|
||||
|
||||
int main(int argc, char *argv[])
|
||||
{
|
||||
int type;
|
||||
if(argc != 3) {
|
||||
fprintf(stderr, "usage: %s dir "
|
||||
"<rshared|rslave|rprivate|runbindable|shared|slave"
|
||||
"|private|unbindable>\n" , argv[0]);
|
||||
return 1;
|
||||
}
|
||||
|
||||
fprintf(stdout, "%s %s %s\n", argv[0], argv[1], argv[2]);
|
||||
|
||||
if (strcmp(argv[2],"rshared")==0)
|
||||
type=(MS_SHARED|MS_REC);
|
||||
else if (strcmp(argv[2],"rslave")==0)
|
||||
type=(MS_SLAVE|MS_REC);
|
||||
else if (strcmp(argv[2],"rprivate")==0)
|
||||
type=(MS_PRIVATE|MS_REC);
|
||||
else if (strcmp(argv[2],"runbindable")==0)
|
||||
type=(MS_UNBINDABLE|MS_REC);
|
||||
else if (strcmp(argv[2],"shared")==0)
|
||||
type=MS_SHARED;
|
||||
else if (strcmp(argv[2],"slave")==0)
|
||||
type=MS_SLAVE;
|
||||
else if (strcmp(argv[2],"private")==0)
|
||||
type=MS_PRIVATE;
|
||||
else if (strcmp(argv[2],"unbindable")==0)
|
||||
type=MS_UNBINDABLE;
|
||||
else {
|
||||
fprintf(stderr, "invalid operation: %s\n", argv[2]);
|
||||
return 1;
|
||||
}
|
||||
setfsuid(getuid());
|
||||
|
||||
if(mount("", argv[1], "dontcare", type, "") == -1) {
|
||||
perror("mount");
|
||||
return 1;
|
||||
}
|
||||
return 0;
|
||||
}
|
||||
-----------------------------------------------------------------------
|
||||
|
||||
Copy the above code snippet into smount.c
|
||||
gcc -o smount smount.c
|
||||
|
||||
|
||||
(i) To mark all the mounts under /mnt as shared execute the following
|
||||
command:
|
||||
|
||||
smount /mnt rshared
|
||||
the corresponding syntax planned for mount command is
|
||||
mount --make-rshared /mnt
|
||||
|
||||
just to mark a mount /mnt as shared, execute the following
|
||||
command:
|
||||
smount /mnt shared
|
||||
the corresponding syntax planned for mount command is
|
||||
mount --make-shared /mnt
|
||||
|
||||
(ii) To mark all the shared mounts under /mnt as slave execute the
|
||||
following
|
||||
|
||||
command:
|
||||
smount /mnt rslave
|
||||
the corresponding syntax planned for mount command is
|
||||
mount --make-rslave /mnt
|
||||
|
||||
just to mark a mount /mnt as slave, execute the following
|
||||
command:
|
||||
smount /mnt slave
|
||||
the corresponding syntax planned for mount command is
|
||||
mount --make-slave /mnt
|
||||
|
||||
(iii) To mark all the mounts under /mnt as private execute the
|
||||
following command:
|
||||
|
||||
smount /mnt rprivate
|
||||
the corresponding syntax planned for mount command is
|
||||
mount --make-rprivate /mnt
|
||||
|
||||
just to mark a mount /mnt as private, execute the following
|
||||
command:
|
||||
smount /mnt private
|
||||
the corresponding syntax planned for mount command is
|
||||
mount --make-private /mnt
|
||||
|
||||
NOTE: by default all the mounts are created as private. But if
|
||||
you want to change some shared/slave/unbindable mount as
|
||||
private at a later point in time, this command can help.
|
||||
|
||||
(iv) To mark all the mounts under /mnt as unbindable execute the
|
||||
following
|
||||
|
||||
command:
|
||||
smount /mnt runbindable
|
||||
the corresponding syntax planned for mount command is
|
||||
mount --make-runbindable /mnt
|
||||
|
||||
just to mark a mount /mnt as unbindable, execute the following
|
||||
command:
|
||||
smount /mnt unbindable
|
||||
the corresponding syntax planned for mount command is
|
||||
mount --make-unbindable /mnt
|
||||
mount --make-shared mountpoint
|
||||
mount --make-slave mountpoint
|
||||
mount --make-private mountpoint
|
||||
mount --make-unbindable mountpoint
|
||||
|
||||
|
||||
4) Use cases
|
||||
|
@ -350,7 +214,7 @@ replicas continue to be exactly same.
|
|||
mount --rbind / /view/v3
|
||||
mount --rbind / /view/v4
|
||||
|
||||
and if /usr has a versioning filesystem mounted, than that
|
||||
and if /usr has a versioning filesystem mounted, then that
|
||||
mount appears at /view/v1/usr, /view/v2/usr, /view/v3/usr and
|
||||
/view/v4/usr too
|
||||
|
||||
|
@ -390,7 +254,7 @@ replicas continue to be exactly same.
|
|||
|
||||
For example:
|
||||
mount --make-shared /mnt
|
||||
mount --bin /mnt /tmp
|
||||
mount --bind /mnt /tmp
|
||||
|
||||
The mount at /mnt and that at /tmp are both shared and belong
|
||||
to the same peer group. Anything mounted or unmounted under
|
||||
|
@ -558,7 +422,7 @@ replicas continue to be exactly same.
|
|||
then the subtree under the unbindable mount is pruned in the new
|
||||
location.
|
||||
|
||||
eg: lets say we have the following mount tree.
|
||||
eg: let's say we have the following mount tree.
|
||||
|
||||
A
|
||||
/ \
|
||||
|
@ -566,7 +430,7 @@ replicas continue to be exactly same.
|
|||
/ \ / \
|
||||
D E F G
|
||||
|
||||
Lets say all the mount except the mount C in the tree are
|
||||
Let's say all the mount except the mount C in the tree are
|
||||
of a type other than unbindable.
|
||||
|
||||
If this tree is rbound to say Z
|
||||
|
@ -683,13 +547,13 @@ replicas continue to be exactly same.
|
|||
'b' on mounts that receive propagation from mount 'B' and does not have
|
||||
sub-mounts within them are unmounted.
|
||||
|
||||
Example: Lets say 'B1', 'B2', 'B3' are shared mounts that propagate to
|
||||
Example: Let's say 'B1', 'B2', 'B3' are shared mounts that propagate to
|
||||
each other.
|
||||
|
||||
lets say 'A1', 'A2', 'A3' are first mounted at dentry 'b' on mount
|
||||
let's say 'A1', 'A2', 'A3' are first mounted at dentry 'b' on mount
|
||||
'B1', 'B2' and 'B3' respectively.
|
||||
|
||||
lets say 'C1', 'C2', 'C3' are next mounted at the same dentry 'b' on
|
||||
let's say 'C1', 'C2', 'C3' are next mounted at the same dentry 'b' on
|
||||
mount 'B1', 'B2' and 'B3' respectively.
|
||||
|
||||
if 'C1' is unmounted, all the mounts that are most-recently-mounted on
|
||||
|
@ -710,7 +574,7 @@ replicas continue to be exactly same.
|
|||
A cloned namespace contains all the mounts as that of the parent
|
||||
namespace.
|
||||
|
||||
Lets say 'A' and 'B' are the corresponding mounts in the parent and the
|
||||
Let's say 'A' and 'B' are the corresponding mounts in the parent and the
|
||||
child namespace.
|
||||
|
||||
If 'A' is shared, then 'B' is also shared and 'A' and 'B' propagate to
|
||||
|
@ -759,11 +623,11 @@ replicas continue to be exactly same.
|
|||
mount --make-slave /mnt
|
||||
|
||||
At this point we have the first mount at /tmp and
|
||||
its root dentry is 1. Lets call this mount 'A'
|
||||
its root dentry is 1. Let's call this mount 'A'
|
||||
And then we have a second mount at /tmp1 with root
|
||||
dentry 2. Lets call this mount 'B'
|
||||
dentry 2. Let's call this mount 'B'
|
||||
Next we have a third mount at /mnt with root dentry
|
||||
mnt. Lets call this mount 'C'
|
||||
mnt. Let's call this mount 'C'
|
||||
|
||||
'B' is the slave of 'A' and 'C' is a slave of 'B'
|
||||
A -> B -> C
|
||||
|
@ -794,7 +658,7 @@ replicas continue to be exactly same.
|
|||
|
||||
Q3 Why is unbindable mount needed?
|
||||
|
||||
Lets say we want to replicate the mount tree at multiple
|
||||
Let's say we want to replicate the mount tree at multiple
|
||||
locations within the same subtree.
|
||||
|
||||
if one rbind mounts a tree within the same subtree 'n' times
|
||||
|
@ -803,7 +667,7 @@ replicas continue to be exactly same.
|
|||
mounts. Here is a example.
|
||||
|
||||
step 1:
|
||||
lets say the root tree has just two directories with
|
||||
let's say the root tree has just two directories with
|
||||
one vfsmount.
|
||||
root
|
||||
/ \
|
||||
|
@ -875,7 +739,7 @@ replicas continue to be exactly same.
|
|||
Unclonable mounts come in handy here.
|
||||
|
||||
step 1:
|
||||
lets say the root tree has just two directories with
|
||||
let's say the root tree has just two directories with
|
||||
one vfsmount.
|
||||
root
|
||||
/ \
|
||||
|
|
|
@ -102,7 +102,7 @@ shortname=lower|win95|winnt|mixed
|
|||
winnt: emulate the Windows NT rule for display/create.
|
||||
mixed: emulate the Windows NT rule for display,
|
||||
emulate the Windows 95 rule for create.
|
||||
Default setting is `lower'.
|
||||
Default setting is `mixed'.
|
||||
|
||||
tz=UTC -- Interpret timestamps as UTC rather than local time.
|
||||
This option disables the conversion of timestamps
|
||||
|
|
|
@ -536,6 +536,7 @@ struct address_space_operations {
|
|||
/* migrate the contents of a page to the specified target */
|
||||
int (*migratepage) (struct page *, struct page *);
|
||||
int (*launder_page) (struct page *);
|
||||
int (*error_remove_page) (struct mapping *mapping, struct page *page);
|
||||
};
|
||||
|
||||
writepage: called by the VM to write a dirty page to backing store.
|
||||
|
@ -694,6 +695,12 @@ struct address_space_operations {
|
|||
prevent redirtying the page, it is kept locked during the whole
|
||||
operation.
|
||||
|
||||
error_remove_page: normally set to generic_error_remove_page if truncation
|
||||
is ok for this address space. Used for memory failure handling.
|
||||
Setting this implies you deal with pages going away under you,
|
||||
unless you have them locked or reference counts increased.
|
||||
|
||||
|
||||
The File Object
|
||||
===============
|
||||
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
Using flexible arrays in the kernel
|
||||
Last updated for 2.6.31
|
||||
Last updated for 2.6.32
|
||||
Jonathan Corbet <corbet@lwn.net>
|
||||
|
||||
Large contiguous memory allocations can be unreliable in the Linux kernel.
|
||||
|
@ -40,6 +40,13 @@ argument is passed directly to the internal memory allocation calls. With
|
|||
the current code, using flags to ask for high memory is likely to lead to
|
||||
notably unpleasant side effects.
|
||||
|
||||
It is also possible to define flexible arrays at compile time with:
|
||||
|
||||
DEFINE_FLEX_ARRAY(name, element_size, total);
|
||||
|
||||
This macro will result in a definition of an array with the given name; the
|
||||
element size and total will be checked for validity at compile time.
|
||||
|
||||
Storing data into a flexible array is accomplished with a call to:
|
||||
|
||||
int flex_array_put(struct flex_array *array, unsigned int element_nr,
|
||||
|
@ -76,16 +83,30 @@ particular element has never been allocated.
|
|||
Note that it is possible to get back a valid pointer for an element which
|
||||
has never been stored in the array. Memory for array elements is allocated
|
||||
one page at a time; a single allocation could provide memory for several
|
||||
adjacent elements. The flexible array code does not know if a specific
|
||||
element has been written; it only knows if the associated memory is
|
||||
present. So a flex_array_get() call on an element which was never stored
|
||||
in the array has the potential to return a pointer to random data. If the
|
||||
caller does not have a separate way to know which elements were actually
|
||||
stored, it might be wise, at least, to add GFP_ZERO to the flags argument
|
||||
to ensure that all elements are zeroed.
|
||||
adjacent elements. Flexible array elements are normally initialized to the
|
||||
value FLEX_ARRAY_FREE (defined as 0x6c in <linux/poison.h>), so errors
|
||||
involving that number probably result from use of unstored array entries.
|
||||
Note that, if array elements are allocated with __GFP_ZERO, they will be
|
||||
initialized to zero and this poisoning will not happen.
|
||||
|
||||
There is no way to remove a single element from the array. It is possible,
|
||||
though, to remove all elements with a call to:
|
||||
Individual elements in the array can be cleared with:
|
||||
|
||||
int flex_array_clear(struct flex_array *array, unsigned int element_nr);
|
||||
|
||||
This function will set the given element to FLEX_ARRAY_FREE and return
|
||||
zero. If storage for the indicated element is not allocated for the array,
|
||||
flex_array_clear() will return -EINVAL instead. Note that clearing an
|
||||
element does not release the storage associated with it; to reduce the
|
||||
allocated size of an array, call:
|
||||
|
||||
int flex_array_shrink(struct flex_array *array);
|
||||
|
||||
The return value will be the number of pages of memory actually freed.
|
||||
This function works by scanning the array for pages containing nothing but
|
||||
FLEX_ARRAY_FREE bytes, so (1) it can be expensive, and (2) it will not work
|
||||
if the array's pages are allocated with __GFP_ZERO.
|
||||
|
||||
It is possible to remove all elements of an array with a call to:
|
||||
|
||||
void flex_array_free_parts(struct flex_array *array);
|
||||
|
||||
|
|
|
@ -4,7 +4,9 @@ Kernel driver coretemp
|
|||
Supported chips:
|
||||
* All Intel Core family
|
||||
Prefix: 'coretemp'
|
||||
CPUID: family 0x6, models 0xe, 0xf, 0x16, 0x17
|
||||
CPUID: family 0x6, models 0xe (Pentium M DC), 0xf (Core 2 DC 65nm),
|
||||
0x16 (Core 2 SC 65nm), 0x17 (Penryn 45nm),
|
||||
0x1a (Nehalem), 0x1c (Atom), 0x1e (Lynnfield)
|
||||
Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual
|
||||
Volume 3A: System Programming Guide
|
||||
http://softwarecommunity.intel.com/Wiki/Mobility/720.htm
|
||||
|
|
|
@ -1,169 +0,0 @@
|
|||
Kernel driver fscher
|
||||
====================
|
||||
|
||||
Supported chips:
|
||||
* Fujitsu-Siemens Hermes chip
|
||||
Prefix: 'fscher'
|
||||
Addresses scanned: I2C 0x73
|
||||
|
||||
Authors:
|
||||
Reinhard Nissl <rnissl@gmx.de> based on work
|
||||
from Hermann Jung <hej@odn.de>,
|
||||
Frodo Looijaard <frodol@dds.nl>,
|
||||
Philip Edelbrock <phil@netroedge.com>
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This driver implements support for the Fujitsu-Siemens Hermes chip. It is
|
||||
described in the 'Register Set Specification BMC Hermes based Systemboard'
|
||||
from Fujitsu-Siemens.
|
||||
|
||||
The Hermes chip implements a hardware-based system management, e.g. for
|
||||
controlling fan speed and core voltage. There is also a watchdog counter on
|
||||
the chip which can trigger an alarm and even shut the system down.
|
||||
|
||||
The chip provides three temperature values (CPU, motherboard and
|
||||
auxiliary), three voltage values (+12V, +5V and battery) and three fans
|
||||
(power supply, CPU and auxiliary).
|
||||
|
||||
Temperatures are measured in degrees Celsius. The resolution is 1 degree.
|
||||
|
||||
Fan rotation speeds are reported in RPM (rotations per minute). The value
|
||||
can be divided by a programmable divider (1, 2 or 4) which is stored on
|
||||
the chip.
|
||||
|
||||
Voltage sensors (also known as "in" sensors) report their values in volts.
|
||||
|
||||
All values are reported as final values from the driver. There is no need
|
||||
for further calculations.
|
||||
|
||||
|
||||
Detailed description
|
||||
--------------------
|
||||
|
||||
Below you'll find a single line description of all the bit values. With
|
||||
this information, you're able to decode e. g. alarms, wdog, etc. To make
|
||||
use of the watchdog, you'll need to set the watchdog time and enable the
|
||||
watchdog. After that it is necessary to restart the watchdog time within
|
||||
the specified period of time, or a system reset will occur.
|
||||
|
||||
* revision
|
||||
READING & 0xff = 0x??: HERMES revision identification
|
||||
|
||||
* alarms
|
||||
READING & 0x80 = 0x80: CPU throttling active
|
||||
READING & 0x80 = 0x00: CPU running at full speed
|
||||
|
||||
READING & 0x10 = 0x10: software event (see control:1)
|
||||
READING & 0x10 = 0x00: no software event
|
||||
|
||||
READING & 0x08 = 0x08: watchdog event (see wdog:2)
|
||||
READING & 0x08 = 0x00: no watchdog event
|
||||
|
||||
READING & 0x02 = 0x02: thermal event (see temp*:1)
|
||||
READING & 0x02 = 0x00: no thermal event
|
||||
|
||||
READING & 0x01 = 0x01: fan event (see fan*:1)
|
||||
READING & 0x01 = 0x00: no fan event
|
||||
|
||||
READING & 0x13 ! 0x00: ALERT LED is flashing
|
||||
|
||||
* control
|
||||
READING & 0x01 = 0x01: software event
|
||||
READING & 0x01 = 0x00: no software event
|
||||
|
||||
WRITING & 0x01 = 0x01: set software event
|
||||
WRITING & 0x01 = 0x00: clear software event
|
||||
|
||||
* watchdog_control
|
||||
READING & 0x80 = 0x80: power off on watchdog event while thermal event
|
||||
READING & 0x80 = 0x00: watchdog power off disabled (just system reset enabled)
|
||||
|
||||
READING & 0x40 = 0x40: watchdog timebase 60 seconds (see also wdog:1)
|
||||
READING & 0x40 = 0x00: watchdog timebase 2 seconds
|
||||
|
||||
READING & 0x10 = 0x10: watchdog enabled
|
||||
READING & 0x10 = 0x00: watchdog disabled
|
||||
|
||||
WRITING & 0x80 = 0x80: enable "power off on watchdog event while thermal event"
|
||||
WRITING & 0x80 = 0x00: disable "power off on watchdog event while thermal event"
|
||||
|
||||
WRITING & 0x40 = 0x40: set watchdog timebase to 60 seconds
|
||||
WRITING & 0x40 = 0x00: set watchdog timebase to 2 seconds
|
||||
|
||||
WRITING & 0x20 = 0x20: disable watchdog
|
||||
|
||||
WRITING & 0x10 = 0x10: enable watchdog / restart watchdog time
|
||||
|
||||
* watchdog_state
|
||||
READING & 0x02 = 0x02: watchdog system reset occurred
|
||||
READING & 0x02 = 0x00: no watchdog system reset occurred
|
||||
|
||||
WRITING & 0x02 = 0x02: clear watchdog event
|
||||
|
||||
* watchdog_preset
|
||||
READING & 0xff = 0x??: configured watch dog time in units (see wdog:3 0x40)
|
||||
|
||||
WRITING & 0xff = 0x??: configure watch dog time in units
|
||||
|
||||
* in* (0: +5V, 1: +12V, 2: onboard 3V battery)
|
||||
READING: actual voltage value
|
||||
|
||||
* temp*_status (1: CPU sensor, 2: onboard sensor, 3: auxiliary sensor)
|
||||
READING & 0x02 = 0x02: thermal event (overtemperature)
|
||||
READING & 0x02 = 0x00: no thermal event
|
||||
|
||||
READING & 0x01 = 0x01: sensor is working
|
||||
READING & 0x01 = 0x00: sensor is faulty
|
||||
|
||||
WRITING & 0x02 = 0x02: clear thermal event
|
||||
|
||||
* temp*_input (1: CPU sensor, 2: onboard sensor, 3: auxiliary sensor)
|
||||
READING: actual temperature value
|
||||
|
||||
* fan*_status (1: power supply fan, 2: CPU fan, 3: auxiliary fan)
|
||||
READING & 0x04 = 0x04: fan event (fan fault)
|
||||
READING & 0x04 = 0x00: no fan event
|
||||
|
||||
WRITING & 0x04 = 0x04: clear fan event
|
||||
|
||||
* fan*_div (1: power supply fan, 2: CPU fan, 3: auxiliary fan)
|
||||
Divisors 2,4 and 8 are supported, both for reading and writing
|
||||
|
||||
* fan*_pwm (1: power supply fan, 2: CPU fan, 3: auxiliary fan)
|
||||
READING & 0xff = 0x00: fan may be switched off
|
||||
READING & 0xff = 0x01: fan must run at least at minimum speed (supply: 6V)
|
||||
READING & 0xff = 0xff: fan must run at maximum speed (supply: 12V)
|
||||
READING & 0xff = 0x??: fan must run at least at given speed (supply: 6V..12V)
|
||||
|
||||
WRITING & 0xff = 0x00: fan may be switched off
|
||||
WRITING & 0xff = 0x01: fan must run at least at minimum speed (supply: 6V)
|
||||
WRITING & 0xff = 0xff: fan must run at maximum speed (supply: 12V)
|
||||
WRITING & 0xff = 0x??: fan must run at least at given speed (supply: 6V..12V)
|
||||
|
||||
* fan*_input (1: power supply fan, 2: CPU fan, 3: auxiliary fan)
|
||||
READING: actual RPM value
|
||||
|
||||
|
||||
Limitations
|
||||
-----------
|
||||
|
||||
* Measuring fan speed
|
||||
It seems that the chip counts "ripples" (typical fans produce 2 ripples per
|
||||
rotation while VERAX fans produce 18) in a 9-bit register. This register is
|
||||
read out every second, then the ripple prescaler (2, 4 or 8) is applied and
|
||||
the result is stored in the 8 bit output register. Due to the limitation of
|
||||
the counting register to 9 bits, it is impossible to measure a VERAX fan
|
||||
properly (even with a prescaler of 8). At its maximum speed of 3500 RPM the
|
||||
fan produces 1080 ripples per second which causes the counting register to
|
||||
overflow twice, leading to only 186 RPM.
|
||||
|
||||
* Measuring input voltages
|
||||
in2 ("battery") reports the voltage of the onboard lithium battery and not
|
||||
+3.3V from the power supply.
|
||||
|
||||
* Undocumented features
|
||||
Fujitsu-Siemens Computers has not documented all features of the chip so
|
||||
far. Their software, System Guard, shows that there are a still some
|
||||
features which cannot be controlled by this implementation.
|
|
@ -22,12 +22,13 @@ Usage Notes
|
|||
-----------
|
||||
|
||||
This driver does not probe for LTC4215 devices, due to the fact that some
|
||||
of the possible addresses are unfriendly to probing. You will need to use
|
||||
the "force" parameter to tell the driver where to find the device.
|
||||
of the possible addresses are unfriendly to probing. You will have to
|
||||
instantiate the devices explicitly.
|
||||
|
||||
Example: the following will load the driver for an LTC4215 at address 0x44
|
||||
on I2C bus #0:
|
||||
$ modprobe ltc4215 force=0,0x44
|
||||
$ modprobe ltc4215
|
||||
$ echo ltc4215 0x44 > /sys/bus/i2c/devices/i2c-0/new_device
|
||||
|
||||
|
||||
Sysfs entries
|
||||
|
|
|
@ -23,12 +23,13 @@ Usage Notes
|
|||
-----------
|
||||
|
||||
This driver does not probe for LTC4245 devices, due to the fact that some
|
||||
of the possible addresses are unfriendly to probing. You will need to use
|
||||
the "force" parameter to tell the driver where to find the device.
|
||||
of the possible addresses are unfriendly to probing. You will have to
|
||||
instantiate the devices explicitly.
|
||||
|
||||
Example: the following will load the driver for an LTC4245 at address 0x23
|
||||
on I2C bus #1:
|
||||
$ modprobe ltc4245 force=1,0x23
|
||||
$ modprobe ltc4245
|
||||
$ echo ltc4245 0x23 > /sys/bus/i2c/devices/i2c-1/new_device
|
||||
|
||||
|
||||
Sysfs entries
|
||||
|
|
|
@ -353,10 +353,20 @@ power[1-*]_average Average power use
|
|||
Unit: microWatt
|
||||
RO
|
||||
|
||||
power[1-*]_average_interval Power use averaging interval
|
||||
power[1-*]_average_interval Power use averaging interval. A poll
|
||||
notification is sent to this file if the
|
||||
hardware changes the averaging interval.
|
||||
Unit: milliseconds
|
||||
RW
|
||||
|
||||
power[1-*]_average_interval_max Maximum power use averaging interval
|
||||
Unit: milliseconds
|
||||
RO
|
||||
|
||||
power[1-*]_average_interval_min Minimum power use averaging interval
|
||||
Unit: milliseconds
|
||||
RO
|
||||
|
||||
power[1-*]_average_highest Historical average maximum power use
|
||||
Unit: microWatt
|
||||
RO
|
||||
|
@ -365,6 +375,18 @@ power[1-*]_average_lowest Historical average minimum power use
|
|||
Unit: microWatt
|
||||
RO
|
||||
|
||||
power[1-*]_average_max A poll notification is sent to
|
||||
power[1-*]_average when power use
|
||||
rises above this value.
|
||||
Unit: microWatt
|
||||
RW
|
||||
|
||||
power[1-*]_average_min A poll notification is sent to
|
||||
power[1-*]_average when power use
|
||||
sinks below this value.
|
||||
Unit: microWatt
|
||||
RW
|
||||
|
||||
power[1-*]_input Instantaneous power use
|
||||
Unit: microWatt
|
||||
RO
|
||||
|
@ -381,6 +403,39 @@ power[1-*]_reset_history Reset input_highest, input_lowest,
|
|||
average_highest and average_lowest.
|
||||
WO
|
||||
|
||||
power[1-*]_accuracy Accuracy of the power meter.
|
||||
Unit: Percent
|
||||
RO
|
||||
|
||||
power[1-*]_alarm 1 if the system is drawing more power than the
|
||||
cap allows; 0 otherwise. A poll notification is
|
||||
sent to this file when the power use exceeds the
|
||||
cap. This file only appears if the cap is known
|
||||
to be enforced by hardware.
|
||||
RO
|
||||
|
||||
power[1-*]_cap If power use rises above this limit, the
|
||||
system should take action to reduce power use.
|
||||
A poll notification is sent to this file if the
|
||||
cap is changed by the hardware. The *_cap
|
||||
files only appear if the cap is known to be
|
||||
enforced by hardware.
|
||||
Unit: microWatt
|
||||
RW
|
||||
|
||||
power[1-*]_cap_hyst Margin of hysteresis built around capping and
|
||||
notification.
|
||||
Unit: microWatt
|
||||
RW
|
||||
|
||||
power[1-*]_cap_max Maximum cap that can be set.
|
||||
Unit: microWatt
|
||||
RO
|
||||
|
||||
power[1-*]_cap_min Minimum cap that can be set.
|
||||
Unit: microWatt
|
||||
RO
|
||||
|
||||
**********
|
||||
* Energy *
|
||||
**********
|
||||
|
|
|
@ -8,7 +8,7 @@ Supported adapters:
|
|||
Datasheet: Only available via NDA from ServerWorks
|
||||
* ATI IXP200, IXP300, IXP400, SB600, SB700 and SB800 southbridges
|
||||
Datasheet: Not publicly available
|
||||
* AMD SB900
|
||||
* AMD Hudson-2
|
||||
Datasheet: Not publicly available
|
||||
* Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge
|
||||
Datasheet: Publicly available at the SMSC website http://www.smsc.com
|
||||
|
|
|
@ -188,7 +188,7 @@ segment, the address is sufficient to uniquely identify the device to be
|
|||
deleted.
|
||||
|
||||
Example:
|
||||
# echo eeprom 0x50 > /sys/class/i2c-adapter/i2c-3/new_device
|
||||
# echo eeprom 0x50 > /sys/bus/i2c/devices/i2c-3/new_device
|
||||
|
||||
While this interface should only be used when in-kernel device declaration
|
||||
can't be done, there is a variety of cases where it can be helpful:
|
||||
|
|
|
@ -128,8 +128,8 @@ Setting IsSM Capability Bit
|
|||
To create the appropriate character device files automatically with
|
||||
udev, a rule like
|
||||
|
||||
KERNEL="umad*", NAME="infiniband/%k"
|
||||
KERNEL="issm*", NAME="infiniband/%k"
|
||||
KERNEL=="umad*", NAME="infiniband/%k"
|
||||
KERNEL=="issm*", NAME="infiniband/%k"
|
||||
|
||||
can be used. This will create device nodes named
|
||||
|
||||
|
|
|
@ -58,7 +58,7 @@ Memory pinning
|
|||
To create the appropriate character device files automatically with
|
||||
udev, a rule like
|
||||
|
||||
KERNEL="uverbs*", NAME="infiniband/%k"
|
||||
KERNEL=="uverbs*", NAME="infiniband/%k"
|
||||
|
||||
can be used. This will create device nodes named
|
||||
|
||||
|
|
|
@ -135,6 +135,7 @@ Code Seq# Include File Comments
|
|||
<http://mikonos.dia.unisa.it/tcfs>
|
||||
'l' 40-7F linux/udf_fs_i.h in development:
|
||||
<http://sourceforge.net/projects/linux-udf/>
|
||||
'm' 00-09 linux/mmtimer.h
|
||||
'm' all linux/mtio.h conflict!
|
||||
'm' all linux/soundcard.h conflict!
|
||||
'm' all linux/synclink.h conflict!
|
||||
|
|
|
@ -60,10 +60,9 @@ open() operation on regular files or character devices.
|
|||
|
||||
After a successful return from register_appl(), CAPI messages from the
|
||||
application may be passed to the driver for the device via calls to the
|
||||
send_message() callback function. The CAPI message to send is stored in the
|
||||
data portion of an skb. Conversely, the driver may call Kernel CAPI's
|
||||
capi_ctr_handle_message() function to pass a received CAPI message to Kernel
|
||||
CAPI for forwarding to an application, specifying its ApplID.
|
||||
send_message() callback function. Conversely, the driver may call Kernel
|
||||
CAPI's capi_ctr_handle_message() function to pass a received CAPI message to
|
||||
Kernel CAPI for forwarding to an application, specifying its ApplID.
|
||||
|
||||
Deregistration requests (CAPI operation CAPI_RELEASE) from applications are
|
||||
forwarded as calls to the release_appl() callback function, passing the same
|
||||
|
@ -142,6 +141,7 @@ u16 (*send_message)(struct capi_ctr *ctrlr, struct sk_buff *skb)
|
|||
to accepting or queueing the message. Errors occurring during the
|
||||
actual processing of the message should be signaled with an
|
||||
appropriate reply message.
|
||||
May be called in process or interrupt context.
|
||||
Calls to this function are not serialized by Kernel CAPI, ie. it must
|
||||
be prepared to be re-entered.
|
||||
|
||||
|
@ -154,7 +154,8 @@ read_proc_t *ctr_read_proc
|
|||
system entry, /proc/capi/controllers/<n>; will be called with a
|
||||
pointer to the device's capi_ctr structure as the last (data) argument
|
||||
|
||||
Note: Callback functions are never called in interrupt context.
|
||||
Note: Callback functions except send_message() are never called in interrupt
|
||||
context.
|
||||
|
||||
- to be filled in before calling capi_ctr_ready():
|
||||
|
||||
|
@ -171,14 +172,40 @@ u8 serial[CAPI_SERIAL_LEN]
|
|||
value to return for CAPI_GET_SERIAL
|
||||
|
||||
|
||||
4.3 The _cmsg Structure
|
||||
4.3 SKBs
|
||||
|
||||
CAPI messages are passed between Kernel CAPI and the driver via send_message()
|
||||
and capi_ctr_handle_message(), stored in the data portion of a socket buffer
|
||||
(skb). Each skb contains a single CAPI message coded according to the CAPI 2.0
|
||||
standard.
|
||||
|
||||
For the data transfer messages, DATA_B3_REQ and DATA_B3_IND, the actual
|
||||
payload data immediately follows the CAPI message itself within the same skb.
|
||||
The Data and Data64 parameters are not used for processing. The Data64
|
||||
parameter may be omitted by setting the length field of the CAPI message to 22
|
||||
instead of 30.
|
||||
|
||||
|
||||
4.4 The _cmsg Structure
|
||||
|
||||
(declared in <linux/isdn/capiutil.h>)
|
||||
|
||||
The _cmsg structure stores the contents of a CAPI 2.0 message in an easily
|
||||
accessible form. It contains members for all possible CAPI 2.0 parameters, of
|
||||
which only those appearing in the message type currently being processed are
|
||||
actually used. Unused members should be set to zero.
|
||||
accessible form. It contains members for all possible CAPI 2.0 parameters,
|
||||
including subparameters of the Additional Info and B Protocol structured
|
||||
parameters, with the following exceptions:
|
||||
|
||||
* second Calling party number (CONNECT_IND)
|
||||
|
||||
* Data64 (DATA_B3_REQ and DATA_B3_IND)
|
||||
|
||||
* Sending complete (subparameter of Additional Info, CONNECT_REQ and INFO_REQ)
|
||||
|
||||
* Global Configuration (subparameter of B Protocol, CONNECT_REQ, CONNECT_RESP
|
||||
and SELECT_B_PROTOCOL_REQ)
|
||||
|
||||
Only those parameters appearing in the message type currently being processed
|
||||
are actually used. Unused members should be set to zero.
|
||||
|
||||
Members are named after the CAPI 2.0 standard names of the parameters they
|
||||
represent. See <linux/isdn/capiutil.h> for the exact spelling. Member data
|
||||
|
@ -190,18 +217,19 @@ u16 for CAPI parameters of type 'word'
|
|||
|
||||
u32 for CAPI parameters of type 'dword'
|
||||
|
||||
_cstruct for CAPI parameters of type 'struct' not containing any
|
||||
variably-sized (struct) subparameters (eg. 'Called Party Number')
|
||||
_cstruct for CAPI parameters of type 'struct'
|
||||
The member is a pointer to a buffer containing the parameter in
|
||||
CAPI encoding (length + content). It may also be NULL, which will
|
||||
be taken to represent an empty (zero length) parameter.
|
||||
Subparameters are stored in encoded form within the content part.
|
||||
|
||||
_cmstruct for CAPI parameters of type 'struct' containing 'struct'
|
||||
subparameters ('Additional Info' and 'B Protocol')
|
||||
_cmstruct alternative representation for CAPI parameters of type 'struct'
|
||||
(used only for the 'Additional Info' and 'B Protocol' parameters)
|
||||
The representation is a single byte containing one of the values:
|
||||
CAPI_DEFAULT: the parameter is empty
|
||||
CAPI_COMPOSE: the values of the subparameters are stored
|
||||
individually in the corresponding _cmsg structure members
|
||||
CAPI_DEFAULT: The parameter is empty/absent.
|
||||
CAPI_COMPOSE: The parameter is present.
|
||||
Subparameter values are stored individually in the corresponding
|
||||
_cmsg structure members.
|
||||
|
||||
Functions capi_cmsg2message() and capi_message2cmsg() are provided to convert
|
||||
messages between their transport encoding described in the CAPI 2.0 standard
|
||||
|
@ -297,3 +325,26 @@ char *capi_cmd2str(u8 Command, u8 Subcommand)
|
|||
be NULL if the command/subcommand is not one of those defined in the
|
||||
CAPI 2.0 standard.
|
||||
|
||||
|
||||
7. Debugging
|
||||
|
||||
The module kernelcapi has a module parameter showcapimsgs controlling some
|
||||
debugging output produced by the module. It can only be set when the module is
|
||||
loaded, via a parameter "showcapimsgs=<n>" to the modprobe command, either on
|
||||
the command line or in the configuration file.
|
||||
|
||||
If the lowest bit of showcapimsgs is set, kernelcapi logs controller and
|
||||
application up and down events.
|
||||
|
||||
In addition, every registered CAPI controller has an associated traceflag
|
||||
parameter controlling how CAPI messages sent from and to tha controller are
|
||||
logged. The traceflag parameter is initialized with the value of the
|
||||
showcapimsgs parameter when the controller is registered, but can later be
|
||||
changed via the MANUFACTURER_REQ command KCAPI_CMD_TRACE.
|
||||
|
||||
If the value of traceflag is non-zero, CAPI messages are logged.
|
||||
DATA_B3 messages are only logged if the value of traceflag is > 2.
|
||||
|
||||
If the lowest bit of traceflag is set, only the command/subcommand and message
|
||||
length are logged. Otherwise, kernelcapi logs a readable representation of
|
||||
the entire message.
|
||||
|
|
|
@ -65,6 +65,22 @@ INSTALL_PATH
|
|||
INSTALL_PATH specifies where to place the updated kernel and system map
|
||||
images. Default is /boot, but you can set it to other values.
|
||||
|
||||
INSTALLKERNEL
|
||||
--------------------------------------------------
|
||||
Install script called when using "make install".
|
||||
The default name is "installkernel".
|
||||
|
||||
The script will be called with the following arguments:
|
||||
$1 - kernel version
|
||||
$2 - kernel image file
|
||||
$3 - kernel map file
|
||||
$4 - default install path (use root directory if blank)
|
||||
|
||||
The implmentation of "make install" is architecture specific
|
||||
and it may differ from the above.
|
||||
|
||||
INSTALLKERNEL is provided to enable the possibility to
|
||||
specify a custom installer when cross compiling a kernel.
|
||||
|
||||
MODLIB
|
||||
--------------------------------------------------
|
||||
|
|
|
@ -18,6 +18,7 @@ This document describes the Linux kernel Makefiles.
|
|||
--- 3.9 Dependency tracking
|
||||
--- 3.10 Special Rules
|
||||
--- 3.11 $(CC) support functions
|
||||
--- 3.12 $(LD) support functions
|
||||
|
||||
=== 4 Host Program support
|
||||
--- 4.1 Simple Host Program
|
||||
|
@ -435,14 +436,14 @@ more details, with real examples.
|
|||
The second argument is optional, and if supplied will be used
|
||||
if first argument is not supported.
|
||||
|
||||
ld-option
|
||||
ld-option is used to check if $(CC) when used to link object files
|
||||
cc-ldoption
|
||||
cc-ldoption is used to check if $(CC) when used to link object files
|
||||
supports the given option. An optional second option may be
|
||||
specified if first option are not supported.
|
||||
|
||||
Example:
|
||||
#arch/i386/kernel/Makefile
|
||||
vsyscall-flags += $(call ld-option, -Wl$(comma)--hash-style=sysv)
|
||||
vsyscall-flags += $(call cc-ldoption, -Wl$(comma)--hash-style=sysv)
|
||||
|
||||
In the above example, vsyscall-flags will be assigned the option
|
||||
-Wl$(comma)--hash-style=sysv if it is supported by $(CC).
|
||||
|
@ -570,6 +571,19 @@ more details, with real examples.
|
|||
endif
|
||||
endif
|
||||
|
||||
--- 3.12 $(LD) support functions
|
||||
|
||||
ld-option
|
||||
ld-option is used to check if $(LD) supports the supplied option.
|
||||
ld-option takes two options as arguments.
|
||||
The second argument is an optional option that can be used if the
|
||||
first option is not supported by $(LD).
|
||||
|
||||
Example:
|
||||
#Makefile
|
||||
LDFLAGS_vmlinux += $(call really-ld-option, -X)
|
||||
|
||||
|
||||
=== 4 Host Program support
|
||||
|
||||
Kbuild supports building executables on the host for use during the
|
||||
|
|
|
@ -85,7 +85,6 @@ parameter is applicable:
|
|||
PPT Parallel port support is enabled.
|
||||
PS2 Appropriate PS/2 support is enabled.
|
||||
RAM RAM disk support is enabled.
|
||||
ROOTPLUG The example Root Plug LSM is enabled.
|
||||
S390 S390 architecture is enabled.
|
||||
SCSI Appropriate SCSI support is enabled.
|
||||
A lot of drivers has their options described inside of
|
||||
|
@ -671,6 +670,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
earlyprintk= [X86,SH,BLACKFIN]
|
||||
earlyprintk=vga
|
||||
earlyprintk=serial[,ttySn[,baudrate]]
|
||||
earlyprintk=ttySn[,baudrate]
|
||||
earlyprintk=dbgp[debugController#]
|
||||
|
||||
Append ",keep" to not disable it when the real console
|
||||
|
@ -2163,15 +2163,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
Useful for devices that are detected asynchronously
|
||||
(e.g. USB and MMC devices).
|
||||
|
||||
root_plug.vendor_id=
|
||||
[ROOTPLUG] Override the default vendor ID
|
||||
|
||||
root_plug.product_id=
|
||||
[ROOTPLUG] Override the default product ID
|
||||
|
||||
root_plug.debug=
|
||||
[ROOTPLUG] Enable debugging output
|
||||
|
||||
rw [KNL] Mount root device read-write on boot
|
||||
|
||||
S [KNL] Run init in single mode
|
||||
|
|
|
@ -199,18 +199,22 @@ kind to allow it (and it often doesn't!).
|
|||
|
||||
Not all bits in the mask can be modified. Not all bits that can be
|
||||
modified do anything. Not all hot keys can be individually controlled
|
||||
by the mask. Some models do not support the mask at all, and in those
|
||||
models, hot keys cannot be controlled individually. The behaviour of
|
||||
the mask is, therefore, highly dependent on the ThinkPad model.
|
||||
by the mask. Some models do not support the mask at all. The behaviour
|
||||
of the mask is, therefore, highly dependent on the ThinkPad model.
|
||||
|
||||
The driver will filter out any unmasked hotkeys, so even if the firmware
|
||||
doesn't allow disabling an specific hotkey, the driver will not report
|
||||
events for unmasked hotkeys.
|
||||
|
||||
Note that unmasking some keys prevents their default behavior. For
|
||||
example, if Fn+F5 is unmasked, that key will no longer enable/disable
|
||||
Bluetooth by itself.
|
||||
Bluetooth by itself in firmware.
|
||||
|
||||
Note also that not all Fn key combinations are supported through ACPI.
|
||||
For example, on the X40, the brightness, volume and "Access IBM" buttons
|
||||
do not generate ACPI events even with this driver. They *can* be used
|
||||
through the "ThinkPad Buttons" utility, see http://www.nongnu.org/tpb/
|
||||
Note also that not all Fn key combinations are supported through ACPI
|
||||
depending on the ThinkPad model and firmware version. On those
|
||||
ThinkPads, it is still possible to support some extra hotkeys by
|
||||
polling the "CMOS NVRAM" at least 10 times per second. The driver
|
||||
attempts to enables this functionality automatically when required.
|
||||
|
||||
procfs notes:
|
||||
|
||||
|
@ -255,18 +259,11 @@ sysfs notes:
|
|||
1: does nothing
|
||||
|
||||
hotkey_mask:
|
||||
bit mask to enable driver-handling (and depending on
|
||||
bit mask to enable reporting (and depending on
|
||||
the firmware, ACPI event generation) for each hot key
|
||||
(see above). Returns the current status of the hot keys
|
||||
mask, and allows one to modify it.
|
||||
|
||||
Note: when NVRAM polling is active, the firmware mask
|
||||
will be different from the value returned by
|
||||
hotkey_mask. The driver will retain enabled bits for
|
||||
hotkeys that are under NVRAM polling even if the
|
||||
firmware refuses them, and will not set these bits on
|
||||
the firmware hot key mask.
|
||||
|
||||
hotkey_all_mask:
|
||||
bit mask that should enable event reporting for all
|
||||
supported hot keys, when echoed to hotkey_mask above.
|
||||
|
@ -279,7 +276,8 @@ sysfs notes:
|
|||
bit mask that should enable event reporting for all
|
||||
supported hot keys, except those which are always
|
||||
handled by the firmware anyway. Echo it to
|
||||
hotkey_mask above, to use.
|
||||
hotkey_mask above, to use. This is the default mask
|
||||
used by the driver.
|
||||
|
||||
hotkey_source_mask:
|
||||
bit mask that selects which hot keys will the driver
|
||||
|
@ -287,9 +285,10 @@ sysfs notes:
|
|||
based on the capabilities reported by the ACPI firmware,
|
||||
but it can be overridden at runtime.
|
||||
|
||||
Hot keys whose bits are set in both hotkey_source_mask
|
||||
and also on hotkey_mask are polled for in NVRAM. Only a
|
||||
few hot keys are available through CMOS NVRAM polling.
|
||||
Hot keys whose bits are set in hotkey_source_mask are
|
||||
polled for in NVRAM, and reported as hotkey events if
|
||||
enabled in hotkey_mask. Only a few hot keys are
|
||||
available through CMOS NVRAM polling.
|
||||
|
||||
Warning: when in NVRAM mode, the volume up/down/mute
|
||||
keys are synthesized according to changes in the mixer,
|
||||
|
@ -525,6 +524,7 @@ compatibility purposes when hotkey_report_mode is set to 1.
|
|||
0x2305 System is waking up from suspend to eject bay
|
||||
0x2404 System is waking up from hibernation to undock
|
||||
0x2405 System is waking up from hibernation to eject bay
|
||||
0x5010 Brightness level changed/control event
|
||||
|
||||
The above events are never propagated by the driver.
|
||||
|
||||
|
@ -532,7 +532,6 @@ The above events are never propagated by the driver.
|
|||
0x4003 Undocked (see 0x2x04), can sleep again
|
||||
0x500B Tablet pen inserted into its storage bay
|
||||
0x500C Tablet pen removed from its storage bay
|
||||
0x5010 Brightness level changed (newer Lenovo BIOSes)
|
||||
|
||||
The above events are propagated by the driver.
|
||||
|
||||
|
@ -621,6 +620,8 @@ For Lenovo models *with* ACPI backlight control:
|
|||
2. Do *NOT* load up ACPI video, enable the hotkeys in thinkpad-acpi,
|
||||
and map them to KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN. Process
|
||||
these keys on userspace somehow (e.g. by calling xbacklight).
|
||||
The driver will do this automatically if it detects that ACPI video
|
||||
has been disabled.
|
||||
|
||||
|
||||
Bluetooth
|
||||
|
@ -1459,3 +1460,8 @@ Sysfs interface changelog:
|
|||
0x020400: Marker for 16 LEDs support. Also, LEDs that are known
|
||||
to not exist in a given model are not registered with
|
||||
the LED sysfs class anymore.
|
||||
|
||||
0x020500: Updated hotkey driver, hotkey_mask is always available
|
||||
and it is always able to disable hot keys. Very old
|
||||
thinkpads are properly supported. hotkey_bios_mask
|
||||
is deprecated and marked for removal.
|
||||
|
|
|
@ -42,7 +42,6 @@
|
|||
#include <signal.h>
|
||||
#include "linux/lguest_launcher.h"
|
||||
#include "linux/virtio_config.h"
|
||||
#include <linux/virtio_ids.h>
|
||||
#include "linux/virtio_net.h"
|
||||
#include "linux/virtio_blk.h"
|
||||
#include "linux/virtio_console.h"
|
||||
|
|
|
@ -42,10 +42,12 @@ General Remarks
|
|||
|
||||
Valid addresses for the MAX6875 are 0x50 and 0x52.
|
||||
Valid addresses for the MAX6874 are 0x50, 0x52, 0x54 and 0x56.
|
||||
The driver does not probe any address, so you must force the address.
|
||||
The driver does not probe any address, so you explicitly instantiate the
|
||||
devices.
|
||||
|
||||
Example:
|
||||
$ modprobe max6875 force=0,0x50
|
||||
$ modprobe max6875
|
||||
$ echo max6875 0x50 > /sys/bus/i2c/devices/i2c-0/new_device
|
||||
|
||||
The MAX6874/MAX6875 ignores address bit 0, so this driver attaches to multiple
|
||||
addresses. For example, for address 0x50, it also reserves 0x51.
|
|
@ -90,6 +90,11 @@ Examples:
|
|||
pgset "dstmac 00:00:00:00:00:00" sets MAC destination address
|
||||
pgset "srcmac 00:00:00:00:00:00" sets MAC source address
|
||||
|
||||
pgset "queue_map_min 0" Sets the min value of tx queue interval
|
||||
pgset "queue_map_max 7" Sets the max value of tx queue interval, for multiqueue devices
|
||||
To select queue 1 of a given device,
|
||||
use queue_map_min=1 and queue_map_max=1
|
||||
|
||||
pgset "src_mac_count 1" Sets the number of MACs we'll range through.
|
||||
The 'minimum' MAC is what you set with srcmac.
|
||||
|
||||
|
@ -101,6 +106,9 @@ Examples:
|
|||
IPDST_RND, UDPSRC_RND,
|
||||
UDPDST_RND, MACSRC_RND, MACDST_RND
|
||||
MPLS_RND, VID_RND, SVID_RND
|
||||
QUEUE_MAP_RND # queue map random
|
||||
QUEUE_MAP_CPU # queue map mirrors smp_processor_id()
|
||||
|
||||
|
||||
pgset "udp_src_min 9" set UDP source port min, If < udp_src_max, then
|
||||
cycle through the port range.
|
||||
|
|
|
@ -381,7 +381,7 @@ int main(int argc, char **argv)
|
|||
memset(&hwtstamp, 0, sizeof(hwtstamp));
|
||||
strncpy(hwtstamp.ifr_name, interface, sizeof(hwtstamp.ifr_name));
|
||||
hwtstamp.ifr_data = (void *)&hwconfig;
|
||||
memset(&hwconfig, 0, sizeof(&hwconfig));
|
||||
memset(&hwconfig, 0, sizeof(hwconfig));
|
||||
hwconfig.tx_type =
|
||||
(so_timestamping_flags & SOF_TIMESTAMPING_TX_HARDWARE) ?
|
||||
HWTSTAMP_TX_ON : HWTSTAMP_TX_OFF;
|
||||
|
|
|
@ -1,5 +1,17 @@
|
|||
This file details changes in 2.6 which affect PCMCIA card driver authors:
|
||||
|
||||
* no cs_error / CS_CHECK / CONFIG_PCMCIA_DEBUG (as of 2.6.33)
|
||||
Instead of the cs_error() callback or the CS_CHECK() macro, please use
|
||||
Linux-style checking of return values, and -- if necessary -- debug
|
||||
messages using "dev_dbg()" or "pr_debug()".
|
||||
|
||||
* New CIS tuple access (as of 2.6.33)
|
||||
Instead of pcmcia_get_{first,next}_tuple(), pcmcia_get_tuple_data() and
|
||||
pcmcia_parse_tuple(), a driver shall use "pcmcia_get_tuple()" if it is
|
||||
only interested in one (raw) tuple, or "pcmcia_loop_tuple()" if it is
|
||||
interested in all tuples of one type. To decode the MAC from CISTPL_FUNCE,
|
||||
a new helper "pcmcia_get_mac_from_cis()" was added.
|
||||
|
||||
* New configuration loop helper (as of 2.6.28)
|
||||
By calling pcmcia_loop_config(), a driver can iterate over all available
|
||||
configuration options. During a driver's probe() phase, one doesn't need
|
||||
|
|
|
@ -76,6 +76,11 @@ STATUS - this attribute represents operating status (charging, full,
|
|||
discharging (i.e. powering a load), etc.). This corresponds to
|
||||
BATTERY_STATUS_* values, as defined in battery.h.
|
||||
|
||||
CHARGE_TYPE - batteries can typically charge at different rates.
|
||||
This defines trickle and fast charges. For batteries that
|
||||
are already charged or discharging, 'n/a' can be displayed (or
|
||||
'unknown', if the status is not known).
|
||||
|
||||
HEALTH - represents health of the battery, values corresponds to
|
||||
POWER_SUPPLY_HEALTH_*, defined in battery.h.
|
||||
|
||||
|
@ -108,6 +113,8 @@ relative, time-based measurements.
|
|||
ENERGY_FULL, ENERGY_EMPTY - same as above but for energy.
|
||||
|
||||
CAPACITY - capacity in percents.
|
||||
CAPACITY_LEVEL - capacity level. This corresponds to
|
||||
POWER_SUPPLY_CAPACITY_LEVEL_*.
|
||||
|
||||
TEMP - temperature of the power supply.
|
||||
TEMP_AMBIENT - ambient temperature.
|
||||
|
|
|
@ -1,18 +1,19 @@
|
|||
CFI or JEDEC memory-mapped NOR flash
|
||||
CFI or JEDEC memory-mapped NOR flash, MTD-RAM (NVRAM...)
|
||||
|
||||
Flash chips (Memory Technology Devices) are often used for solid state
|
||||
file systems on embedded devices.
|
||||
|
||||
- compatible : should contain the specific model of flash chip(s)
|
||||
used, if known, followed by either "cfi-flash" or "jedec-flash"
|
||||
- reg : Address range(s) of the flash chip(s)
|
||||
- compatible : should contain the specific model of mtd chip(s)
|
||||
used, if known, followed by either "cfi-flash", "jedec-flash"
|
||||
or "mtd-ram".
|
||||
- reg : Address range(s) of the mtd chip(s)
|
||||
It's possible to (optionally) define multiple "reg" tuples so that
|
||||
non-identical NOR chips can be described in one flash node.
|
||||
- bank-width : Width (in bytes) of the flash bank. Equal to the
|
||||
non-identical chips can be described in one node.
|
||||
- bank-width : Width (in bytes) of the bank. Equal to the
|
||||
device width times the number of interleaved chips.
|
||||
- device-width : (optional) Width of a single flash chip. If
|
||||
- device-width : (optional) Width of a single mtd chip. If
|
||||
omitted, assumed to be equal to 'bank-width'.
|
||||
- #address-cells, #size-cells : Must be present if the flash has
|
||||
- #address-cells, #size-cells : Must be present if the device has
|
||||
sub-nodes representing partitions (see below). In this case
|
||||
both #address-cells and #size-cells must be equal to 1.
|
||||
|
||||
|
@ -22,24 +23,24 @@ are defined:
|
|||
- vendor-id : Contains the flash chip's vendor id (1 byte).
|
||||
- device-id : Contains the flash chip's device id (1 byte).
|
||||
|
||||
In addition to the information on the flash bank itself, the
|
||||
In addition to the information on the mtd bank itself, the
|
||||
device tree may optionally contain additional information
|
||||
describing partitions of the flash address space. This can be
|
||||
describing partitions of the address space. This can be
|
||||
used on platforms which have strong conventions about which
|
||||
portions of the flash are used for what purposes, but which don't
|
||||
portions of a flash are used for what purposes, but which don't
|
||||
use an on-flash partition table such as RedBoot.
|
||||
|
||||
Each partition is represented as a sub-node of the flash device.
|
||||
Each partition is represented as a sub-node of the mtd device.
|
||||
Each node's name represents the name of the corresponding
|
||||
partition of the flash device.
|
||||
partition of the mtd device.
|
||||
|
||||
Flash partitions
|
||||
- reg : The partition's offset and size within the flash bank.
|
||||
- label : (optional) The label / name for this flash partition.
|
||||
- reg : The partition's offset and size within the mtd bank.
|
||||
- label : (optional) The label / name for this partition.
|
||||
If omitted, the label is taken from the node name (excluding
|
||||
the unit address).
|
||||
- read-only : (optional) This parameter, if present, is a hint to
|
||||
Linux that this flash partition should only be mounted
|
||||
Linux that this partition should only be mounted
|
||||
read-only. This is usually used for flash partitions
|
||||
containing early-boot firmware images or data which should not
|
||||
be clobbered.
|
||||
|
@ -78,3 +79,12 @@ Here an example with multiple "reg" tuples:
|
|||
reg = <0 0x04000000>;
|
||||
};
|
||||
};
|
||||
|
||||
An example using SRAM:
|
||||
|
||||
sram@2,0 {
|
||||
compatible = "samsung,k6f1616u6a", "mtd-ram";
|
||||
reg = <2 0 0x00200000>;
|
||||
bank-width = <2>;
|
||||
};
|
||||
|
||||
|
|
|
@ -3,6 +3,25 @@ HIGHPOINT ROCKETRAID 3xxx/4xxx ADAPTER DRIVER (hptiop)
|
|||
Controller Register Map
|
||||
-------------------------
|
||||
|
||||
For RR44xx Intel IOP based adapters, the controller IOP is accessed via PCI BAR0 and BAR2:
|
||||
|
||||
BAR0 offset Register
|
||||
0x11C5C Link Interface IRQ Set
|
||||
0x11C60 Link Interface IRQ Clear
|
||||
|
||||
BAR2 offset Register
|
||||
0x10 Inbound Message Register 0
|
||||
0x14 Inbound Message Register 1
|
||||
0x18 Outbound Message Register 0
|
||||
0x1C Outbound Message Register 1
|
||||
0x20 Inbound Doorbell Register
|
||||
0x24 Inbound Interrupt Status Register
|
||||
0x28 Inbound Interrupt Mask Register
|
||||
0x30 Outbound Interrupt Status Register
|
||||
0x34 Outbound Interrupt Mask Register
|
||||
0x40 Inbound Queue Port
|
||||
0x44 Outbound Queue Port
|
||||
|
||||
For Intel IOP based adapters, the controller IOP is accessed via PCI BAR0:
|
||||
|
||||
BAR0 offset Register
|
||||
|
@ -93,7 +112,7 @@ The driver exposes following sysfs attributes:
|
|||
|
||||
|
||||
-----------------------------------------------------------------------------
|
||||
Copyright (C) 2006-2007 HighPoint Technologies, Inc. All Rights Reserved.
|
||||
Copyright (C) 2006-2009 HighPoint Technologies, Inc. All Rights Reserved.
|
||||
|
||||
This file is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
|
|
|
@ -41,6 +41,13 @@ expand files, provided the time taken to do so isn't too long.
|
|||
Operations of both types may sleep during execution, thus tying up the thread
|
||||
loaned to it.
|
||||
|
||||
A further class of work item is available, based on the slow work item class:
|
||||
|
||||
(*) Delayed slow work items.
|
||||
|
||||
These are slow work items that have a timer to defer queueing of the item for
|
||||
a while.
|
||||
|
||||
|
||||
THREAD-TO-CLASS ALLOCATION
|
||||
--------------------------
|
||||
|
@ -64,9 +71,11 @@ USING SLOW WORK ITEMS
|
|||
Firstly, a module or subsystem wanting to make use of slow work items must
|
||||
register its interest:
|
||||
|
||||
int ret = slow_work_register_user();
|
||||
int ret = slow_work_register_user(struct module *module);
|
||||
|
||||
This will return 0 if successful, or a -ve error upon failure.
|
||||
This will return 0 if successful, or a -ve error upon failure. The module
|
||||
pointer should be the module interested in using this facility (almost
|
||||
certainly THIS_MODULE).
|
||||
|
||||
|
||||
Slow work items may then be set up by:
|
||||
|
@ -91,6 +100,10 @@ Slow work items may then be set up by:
|
|||
|
||||
slow_work_init(&myitem, &myitem_ops);
|
||||
|
||||
or:
|
||||
|
||||
delayed_slow_work_init(&myitem, &myitem_ops);
|
||||
|
||||
or:
|
||||
|
||||
vslow_work_init(&myitem, &myitem_ops);
|
||||
|
@ -102,15 +115,92 @@ A suitably set up work item can then be enqueued for processing:
|
|||
int ret = slow_work_enqueue(&myitem);
|
||||
|
||||
This will return a -ve error if the thread pool is unable to gain a reference
|
||||
on the item, 0 otherwise.
|
||||
on the item, 0 otherwise, or (for delayed work):
|
||||
|
||||
int ret = delayed_slow_work_enqueue(&myitem, my_jiffy_delay);
|
||||
|
||||
|
||||
The items are reference counted, so there ought to be no need for a flush
|
||||
operation. When all a module's slow work items have been processed, and the
|
||||
operation. But as the reference counting is optional, means to cancel
|
||||
existing work items are also included:
|
||||
|
||||
cancel_slow_work(&myitem);
|
||||
cancel_delayed_slow_work(&myitem);
|
||||
|
||||
can be used to cancel pending work. The above cancel function waits for
|
||||
existing work to have been executed (or prevent execution of them, depending
|
||||
on timing).
|
||||
|
||||
|
||||
When all a module's slow work items have been processed, and the
|
||||
module has no further interest in the facility, it should unregister its
|
||||
interest:
|
||||
|
||||
slow_work_unregister_user();
|
||||
slow_work_unregister_user(struct module *module);
|
||||
|
||||
The module pointer is used to wait for all outstanding work items for that
|
||||
module before completing the unregistration. This prevents the put_ref() code
|
||||
from being taken away before it completes. module should almost certainly be
|
||||
THIS_MODULE.
|
||||
|
||||
|
||||
================
|
||||
HELPER FUNCTIONS
|
||||
================
|
||||
|
||||
The slow-work facility provides a function by which it can be determined
|
||||
whether or not an item is queued for later execution:
|
||||
|
||||
bool queued = slow_work_is_queued(struct slow_work *work);
|
||||
|
||||
If it returns false, then the item is not on the queue (it may be executing
|
||||
with a requeue pending). This can be used to work out whether an item on which
|
||||
another depends is on the queue, thus allowing a dependent item to be queued
|
||||
after it.
|
||||
|
||||
If the above shows an item on which another depends not to be queued, then the
|
||||
owner of the dependent item might need to wait. However, to avoid locking up
|
||||
the threads unnecessarily be sleeping in them, it can make sense under some
|
||||
circumstances to return the work item to the queue, thus deferring it until
|
||||
some other items have had a chance to make use of the yielded thread.
|
||||
|
||||
To yield a thread and defer an item, the work function should simply enqueue
|
||||
the work item again and return. However, this doesn't work if there's nothing
|
||||
actually on the queue, as the thread just vacated will jump straight back into
|
||||
the item's work function, thus busy waiting on a CPU.
|
||||
|
||||
Instead, the item should use the thread to wait for the dependency to go away,
|
||||
but rather than using schedule() or schedule_timeout() to sleep, it should use
|
||||
the following function:
|
||||
|
||||
bool requeue = slow_work_sleep_till_thread_needed(
|
||||
struct slow_work *work,
|
||||
signed long *_timeout);
|
||||
|
||||
This will add a second wait and then sleep, such that it will be woken up if
|
||||
either something appears on the queue that could usefully make use of the
|
||||
thread - and behind which this item can be queued, or if the event the caller
|
||||
set up to wait for happens. True will be returned if something else appeared
|
||||
on the queue and this work function should perhaps return, of false if
|
||||
something else woke it up. The timeout is as for schedule_timeout().
|
||||
|
||||
For example:
|
||||
|
||||
wq = bit_waitqueue(&my_flags, MY_BIT);
|
||||
init_wait(&wait);
|
||||
requeue = false;
|
||||
do {
|
||||
prepare_to_wait(wq, &wait, TASK_UNINTERRUPTIBLE);
|
||||
if (!test_bit(MY_BIT, &my_flags))
|
||||
break;
|
||||
requeue = slow_work_sleep_till_thread_needed(&my_work,
|
||||
&timeout);
|
||||
} while (timeout > 0 && !requeue);
|
||||
finish_wait(wq, &wait);
|
||||
if (!test_bit(MY_BIT, &my_flags)
|
||||
goto do_my_thing;
|
||||
if (requeue)
|
||||
return; // to slow_work
|
||||
|
||||
|
||||
===============
|
||||
|
@ -118,7 +208,8 @@ ITEM OPERATIONS
|
|||
===============
|
||||
|
||||
Each work item requires a table of operations of type struct slow_work_ops.
|
||||
All members are required:
|
||||
Only ->execute() is required; the getting and putting of a reference and the
|
||||
describing of an item are all optional.
|
||||
|
||||
(*) Get a reference on an item:
|
||||
|
||||
|
@ -148,6 +239,16 @@ All members are required:
|
|||
This should perform the work required of the item. It may sleep, it may
|
||||
perform disk I/O and it may wait for locks.
|
||||
|
||||
(*) View an item through /proc:
|
||||
|
||||
void (*desc)(struct slow_work *work, struct seq_file *m);
|
||||
|
||||
If supplied, this should print to 'm' a small string describing the work
|
||||
the item is to do. This should be no more than about 40 characters, and
|
||||
shouldn't include a newline character.
|
||||
|
||||
See the 'Viewing executing and queued items' section below.
|
||||
|
||||
|
||||
==================
|
||||
POOL CONFIGURATION
|
||||
|
@ -172,3 +273,50 @@ The slow-work thread pool has a number of configurables:
|
|||
is bounded to between 1 and one fewer than the number of active threads.
|
||||
This ensures there is always at least one thread that can process very
|
||||
slow work items, and always at least one thread that won't.
|
||||
|
||||
|
||||
==================================
|
||||
VIEWING EXECUTING AND QUEUED ITEMS
|
||||
==================================
|
||||
|
||||
If CONFIG_SLOW_WORK_DEBUG is enabled, a debugfs file is made available:
|
||||
|
||||
/sys/kernel/debug/slow_work/runqueue
|
||||
|
||||
through which the list of work items being executed and the queues of items to
|
||||
be executed may be viewed. The owner of a work item is given the chance to
|
||||
add some information of its own.
|
||||
|
||||
The contents look something like the following:
|
||||
|
||||
THR PID ITEM ADDR FL MARK DESC
|
||||
=== ===== ================ == ===== ==========
|
||||
0 3005 ffff880023f52348 a 952ms FSC: OBJ17d3: LOOK
|
||||
1 3006 ffff880024e33668 2 160ms FSC: OBJ17e5 OP60d3b: Write1/Store fl=2
|
||||
2 3165 ffff8800296dd180 a 424ms FSC: OBJ17e4: LOOK
|
||||
3 4089 ffff8800262c8d78 a 212ms FSC: OBJ17ea: CRTN
|
||||
4 4090 ffff88002792bed8 2 388ms FSC: OBJ17e8 OP60d36: Write1/Store fl=2
|
||||
5 4092 ffff88002a0ef308 2 388ms FSC: OBJ17e7 OP60d2e: Write1/Store fl=2
|
||||
6 4094 ffff88002abaf4b8 2 132ms FSC: OBJ17e2 OP60d4e: Write1/Store fl=2
|
||||
7 4095 ffff88002bb188e0 a 388ms FSC: OBJ17e9: CRTN
|
||||
vsq - ffff880023d99668 1 308ms FSC: OBJ17e0 OP60f91: Write1/EnQ fl=2
|
||||
vsq - ffff8800295d1740 1 212ms FSC: OBJ16be OP4d4b6: Write1/EnQ fl=2
|
||||
vsq - ffff880025ba3308 1 160ms FSC: OBJ179a OP58dec: Write1/EnQ fl=2
|
||||
vsq - ffff880024ec83e0 1 160ms FSC: OBJ17ae OP599f2: Write1/EnQ fl=2
|
||||
vsq - ffff880026618e00 1 160ms FSC: OBJ17e6 OP60d33: Write1/EnQ fl=2
|
||||
vsq - ffff880025a2a4b8 1 132ms FSC: OBJ16a2 OP4d583: Write1/EnQ fl=2
|
||||
vsq - ffff880023cbe6d8 9 212ms FSC: OBJ17eb: LOOK
|
||||
vsq - ffff880024d37590 9 212ms FSC: OBJ17ec: LOOK
|
||||
vsq - ffff880027746cb0 9 212ms FSC: OBJ17ed: LOOK
|
||||
vsq - ffff880024d37ae8 9 212ms FSC: OBJ17ee: LOOK
|
||||
vsq - ffff880024d37cb0 9 212ms FSC: OBJ17ef: LOOK
|
||||
vsq - ffff880025036550 9 212ms FSC: OBJ17f0: LOOK
|
||||
vsq - ffff8800250368e0 9 212ms FSC: OBJ17f1: LOOK
|
||||
vsq - ffff880025036aa8 9 212ms FSC: OBJ17f2: LOOK
|
||||
|
||||
In the 'THR' column, executing items show the thread they're occupying and
|
||||
queued threads indicate which queue they're on. 'PID' shows the process ID of
|
||||
a slow-work thread that's executing something. 'FL' shows the work item flags.
|
||||
'MARK' indicates how long since an item was queued or began executing. Lastly,
|
||||
the 'DESC' column permits the owner of an item to give some information.
|
||||
|
||||
|
|
|
@ -522,7 +522,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
|
|||
pcm_devs - Number of PCM devices assigned to each card
|
||||
(default = 1, up to 4)
|
||||
pcm_substreams - Number of PCM substreams assigned to each PCM
|
||||
(default = 8, up to 16)
|
||||
(default = 8, up to 128)
|
||||
hrtimer - Use hrtimer (=1, default) or system timer (=0)
|
||||
fake_buffer - Fake buffer allocations (default = 1)
|
||||
|
||||
|
|
|
@ -209,6 +209,7 @@ AD1884A / AD1883 / AD1984A / AD1984B
|
|||
laptop laptop with HP jack sensing
|
||||
mobile mobile devices with HP jack sensing
|
||||
thinkpad Lenovo Thinkpad X300
|
||||
touchsmart HP Touchsmart
|
||||
|
||||
AD1884
|
||||
======
|
||||
|
@ -358,6 +359,7 @@ STAC9227/9228/9229/927x
|
|||
5stack-no-fp D965 5stack without front panel
|
||||
dell-3stack Dell Dimension E520
|
||||
dell-bios Fixes with Dell BIOS setup
|
||||
volknob Fixes with volume-knob widget 0x24
|
||||
auto BIOS setup (default)
|
||||
|
||||
STAC92HD71B*
|
||||
|
|
|
@ -96,13 +96,16 @@ handles that the Linux kernel will allocate. When you get lots
|
|||
of error messages about running out of file handles, you might
|
||||
want to increase this limit.
|
||||
|
||||
The three values in file-nr denote the number of allocated
|
||||
file handles, the number of unused file handles and the maximum
|
||||
number of file handles. When the allocated file handles come
|
||||
close to the maximum, but the number of unused file handles is
|
||||
significantly greater than 0, you've encountered a peak in your
|
||||
usage of file handles and you don't need to increase the maximum.
|
||||
Historically, the three values in file-nr denoted the number of
|
||||
allocated file handles, the number of allocated but unused file
|
||||
handles, and the maximum number of file handles. Linux 2.6 always
|
||||
reports 0 as the number of free file handles -- this is not an
|
||||
error, it just means that the number of allocated file handles
|
||||
exactly matches the number of used file handles.
|
||||
|
||||
Attempts to allocate more file descriptors than file-max are
|
||||
reported with printk, look for "VFS: file-max limit <number>
|
||||
reached".
|
||||
==============================================================
|
||||
|
||||
nr_open:
|
||||
|
|
|
@ -22,6 +22,7 @@ show up in /proc/sys/kernel:
|
|||
- callhome [ S390 only ]
|
||||
- auto_msgmni
|
||||
- core_pattern
|
||||
- core_pipe_limit
|
||||
- core_uses_pid
|
||||
- ctrl-alt-del
|
||||
- dentry-state
|
||||
|
@ -135,6 +136,27 @@ core_pattern is used to specify a core dumpfile pattern name.
|
|||
|
||||
==============================================================
|
||||
|
||||
core_pipe_limit:
|
||||
|
||||
This sysctl is only applicable when core_pattern is configured to pipe core
|
||||
files to user space helper a (when the first character of core_pattern is a '|',
|
||||
see above). When collecting cores via a pipe to an application, it is
|
||||
occasionally usefull for the collecting application to gather data about the
|
||||
crashing process from its /proc/pid directory. In order to do this safely, the
|
||||
kernel must wait for the collecting process to exit, so as not to remove the
|
||||
crashing processes proc files prematurely. This in turn creates the possibility
|
||||
that a misbehaving userspace collecting process can block the reaping of a
|
||||
crashed process simply by never exiting. This sysctl defends against that. It
|
||||
defines how many concurrent crashing processes may be piped to user space
|
||||
applications in parallel. If this value is exceeded, then those crashing
|
||||
processes above that value are noted via the kernel log and their cores are
|
||||
skipped. 0 is a special value, indicating that unlimited processes may be
|
||||
captured in parallel, but that no waiting will take place (i.e. the collecting
|
||||
process is not guaranteed access to /proc/<crahing pid>/). This value defaults
|
||||
to 0.
|
||||
|
||||
==============================================================
|
||||
|
||||
core_uses_pid:
|
||||
|
||||
The default coredump filename is "core". By setting
|
||||
|
|
|
@ -32,6 +32,8 @@ Currently, these files are in /proc/sys/vm:
|
|||
- legacy_va_layout
|
||||
- lowmem_reserve_ratio
|
||||
- max_map_count
|
||||
- memory_failure_early_kill
|
||||
- memory_failure_recovery
|
||||
- min_free_kbytes
|
||||
- min_slab_ratio
|
||||
- min_unmapped_ratio
|
||||
|
@ -53,7 +55,6 @@ Currently, these files are in /proc/sys/vm:
|
|||
- vfs_cache_pressure
|
||||
- zone_reclaim_mode
|
||||
|
||||
|
||||
==============================================================
|
||||
|
||||
block_dump
|
||||
|
@ -275,6 +276,44 @@ e.g., up to one or two maps per allocation.
|
|||
|
||||
The default value is 65536.
|
||||
|
||||
=============================================================
|
||||
|
||||
memory_failure_early_kill:
|
||||
|
||||
Control how to kill processes when uncorrected memory error (typically
|
||||
a 2bit error in a memory module) is detected in the background by hardware
|
||||
that cannot be handled by the kernel. In some cases (like the page
|
||||
still having a valid copy on disk) the kernel will handle the failure
|
||||
transparently without affecting any applications. But if there is
|
||||
no other uptodate copy of the data it will kill to prevent any data
|
||||
corruptions from propagating.
|
||||
|
||||
1: Kill all processes that have the corrupted and not reloadable page mapped
|
||||
as soon as the corruption is detected. Note this is not supported
|
||||
for a few types of pages, like kernel internally allocated data or
|
||||
the swap cache, but works for the majority of user pages.
|
||||
|
||||
0: Only unmap the corrupted page from all processes and only kill a process
|
||||
who tries to access it.
|
||||
|
||||
The kill is done using a catchable SIGBUS with BUS_MCEERR_AO, so processes can
|
||||
handle this if they want to.
|
||||
|
||||
This is only active on architectures/platforms with advanced machine
|
||||
check handling and depends on the hardware capabilities.
|
||||
|
||||
Applications can override this setting individually with the PR_MCE_KILL prctl
|
||||
|
||||
==============================================================
|
||||
|
||||
memory_failure_recovery
|
||||
|
||||
Enable memory failure recovery (when supported by the platform)
|
||||
|
||||
1: Attempt recovery.
|
||||
|
||||
0: Always panic on a memory failure.
|
||||
|
||||
==============================================================
|
||||
|
||||
min_free_kbytes:
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
Generic Thermal Sysfs driver How To
|
||||
=========================
|
||||
===================================
|
||||
|
||||
Written by Sujith Thomas <sujith.thomas@intel.com>, Zhang Rui <rui.zhang@intel.com>
|
||||
|
||||
|
@ -10,20 +10,20 @@ Copyright (c) 2008 Intel Corporation
|
|||
|
||||
0. Introduction
|
||||
|
||||
The generic thermal sysfs provides a set of interfaces for thermal zone devices (sensors)
|
||||
and thermal cooling devices (fan, processor...) to register with the thermal management
|
||||
solution and to be a part of it.
|
||||
The generic thermal sysfs provides a set of interfaces for thermal zone
|
||||
devices (sensors) and thermal cooling devices (fan, processor...) to register
|
||||
with the thermal management solution and to be a part of it.
|
||||
|
||||
This how-to focuses on enabling new thermal zone and cooling devices to participate
|
||||
in thermal management.
|
||||
This solution is platform independent and any type of thermal zone devices and
|
||||
cooling devices should be able to make use of the infrastructure.
|
||||
This how-to focuses on enabling new thermal zone and cooling devices to
|
||||
participate in thermal management.
|
||||
This solution is platform independent and any type of thermal zone devices
|
||||
and cooling devices should be able to make use of the infrastructure.
|
||||
|
||||
The main task of the thermal sysfs driver is to expose thermal zone attributes as well
|
||||
as cooling device attributes to the user space.
|
||||
An intelligent thermal management application can make decisions based on inputs
|
||||
from thermal zone attributes (the current temperature and trip point temperature)
|
||||
and throttle appropriate devices.
|
||||
The main task of the thermal sysfs driver is to expose thermal zone attributes
|
||||
as well as cooling device attributes to the user space.
|
||||
An intelligent thermal management application can make decisions based on
|
||||
inputs from thermal zone attributes (the current temperature and trip point
|
||||
temperature) and throttle appropriate devices.
|
||||
|
||||
[0-*] denotes any positive number starting from 0
|
||||
[1-*] denotes any positive number starting from 1
|
||||
|
@ -31,77 +31,77 @@ and throttle appropriate devices.
|
|||
1. thermal sysfs driver interface functions
|
||||
|
||||
1.1 thermal zone device interface
|
||||
1.1.1 struct thermal_zone_device *thermal_zone_device_register(char *name, int trips,
|
||||
void *devdata, struct thermal_zone_device_ops *ops)
|
||||
1.1.1 struct thermal_zone_device *thermal_zone_device_register(char *name,
|
||||
int trips, void *devdata, struct thermal_zone_device_ops *ops)
|
||||
|
||||
This interface function adds a new thermal zone device (sensor) to
|
||||
/sys/class/thermal folder as thermal_zone[0-*].
|
||||
It tries to bind all the thermal cooling devices registered at the same time.
|
||||
This interface function adds a new thermal zone device (sensor) to
|
||||
/sys/class/thermal folder as thermal_zone[0-*]. It tries to bind all the
|
||||
thermal cooling devices registered at the same time.
|
||||
|
||||
name: the thermal zone name.
|
||||
trips: the total number of trip points this thermal zone supports.
|
||||
devdata: device private data
|
||||
ops: thermal zone device call-backs.
|
||||
.bind: bind the thermal zone device with a thermal cooling device.
|
||||
.unbind: unbind the thermal zone device with a thermal cooling device.
|
||||
.get_temp: get the current temperature of the thermal zone.
|
||||
.get_mode: get the current mode (user/kernel) of the thermal zone.
|
||||
"kernel" means thermal management is done in kernel.
|
||||
"user" will prevent kernel thermal driver actions upon trip points
|
||||
so that user applications can take charge of thermal management.
|
||||
.set_mode: set the mode (user/kernel) of the thermal zone.
|
||||
.get_trip_type: get the type of certain trip point.
|
||||
.get_trip_temp: get the temperature above which the certain trip point
|
||||
will be fired.
|
||||
name: the thermal zone name.
|
||||
trips: the total number of trip points this thermal zone supports.
|
||||
devdata: device private data
|
||||
ops: thermal zone device call-backs.
|
||||
.bind: bind the thermal zone device with a thermal cooling device.
|
||||
.unbind: unbind the thermal zone device with a thermal cooling device.
|
||||
.get_temp: get the current temperature of the thermal zone.
|
||||
.get_mode: get the current mode (user/kernel) of the thermal zone.
|
||||
- "kernel" means thermal management is done in kernel.
|
||||
- "user" will prevent kernel thermal driver actions upon trip points
|
||||
so that user applications can take charge of thermal management.
|
||||
.set_mode: set the mode (user/kernel) of the thermal zone.
|
||||
.get_trip_type: get the type of certain trip point.
|
||||
.get_trip_temp: get the temperature above which the certain trip point
|
||||
will be fired.
|
||||
|
||||
1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz)
|
||||
|
||||
This interface function removes the thermal zone device.
|
||||
It deletes the corresponding entry form /sys/class/thermal folder and unbind all
|
||||
the thermal cooling devices it uses.
|
||||
This interface function removes the thermal zone device.
|
||||
It deletes the corresponding entry form /sys/class/thermal folder and
|
||||
unbind all the thermal cooling devices it uses.
|
||||
|
||||
1.2 thermal cooling device interface
|
||||
1.2.1 struct thermal_cooling_device *thermal_cooling_device_register(char *name,
|
||||
void *devdata, struct thermal_cooling_device_ops *)
|
||||
void *devdata, struct thermal_cooling_device_ops *)
|
||||
|
||||
This interface function adds a new thermal cooling device (fan/processor/...) to
|
||||
/sys/class/thermal/ folder as cooling_device[0-*].
|
||||
It tries to bind itself to all the thermal zone devices register at the same time.
|
||||
name: the cooling device name.
|
||||
devdata: device private data.
|
||||
ops: thermal cooling devices call-backs.
|
||||
.get_max_state: get the Maximum throttle state of the cooling device.
|
||||
.get_cur_state: get the Current throttle state of the cooling device.
|
||||
.set_cur_state: set the Current throttle state of the cooling device.
|
||||
This interface function adds a new thermal cooling device (fan/processor/...)
|
||||
to /sys/class/thermal/ folder as cooling_device[0-*]. It tries to bind itself
|
||||
to all the thermal zone devices register at the same time.
|
||||
name: the cooling device name.
|
||||
devdata: device private data.
|
||||
ops: thermal cooling devices call-backs.
|
||||
.get_max_state: get the Maximum throttle state of the cooling device.
|
||||
.get_cur_state: get the Current throttle state of the cooling device.
|
||||
.set_cur_state: set the Current throttle state of the cooling device.
|
||||
|
||||
1.2.2 void thermal_cooling_device_unregister(struct thermal_cooling_device *cdev)
|
||||
|
||||
This interface function remove the thermal cooling device.
|
||||
It deletes the corresponding entry form /sys/class/thermal folder and unbind
|
||||
itself from all the thermal zone devices using it.
|
||||
This interface function remove the thermal cooling device.
|
||||
It deletes the corresponding entry form /sys/class/thermal folder and
|
||||
unbind itself from all the thermal zone devices using it.
|
||||
|
||||
1.3 interface for binding a thermal zone device with a thermal cooling device
|
||||
1.3.1 int thermal_zone_bind_cooling_device(struct thermal_zone_device *tz,
|
||||
int trip, struct thermal_cooling_device *cdev);
|
||||
int trip, struct thermal_cooling_device *cdev);
|
||||
|
||||
This interface function bind a thermal cooling device to the certain trip point
|
||||
of a thermal zone device.
|
||||
This function is usually called in the thermal zone device .bind callback.
|
||||
tz: the thermal zone device
|
||||
cdev: thermal cooling device
|
||||
trip: indicates which trip point the cooling devices is associated with
|
||||
in this thermal zone.
|
||||
This interface function bind a thermal cooling device to the certain trip
|
||||
point of a thermal zone device.
|
||||
This function is usually called in the thermal zone device .bind callback.
|
||||
tz: the thermal zone device
|
||||
cdev: thermal cooling device
|
||||
trip: indicates which trip point the cooling devices is associated with
|
||||
in this thermal zone.
|
||||
|
||||
1.3.2 int thermal_zone_unbind_cooling_device(struct thermal_zone_device *tz,
|
||||
int trip, struct thermal_cooling_device *cdev);
|
||||
int trip, struct thermal_cooling_device *cdev);
|
||||
|
||||
This interface function unbind a thermal cooling device from the certain trip point
|
||||
of a thermal zone device.
|
||||
This function is usually called in the thermal zone device .unbind callback.
|
||||
tz: the thermal zone device
|
||||
cdev: thermal cooling device
|
||||
trip: indicates which trip point the cooling devices is associated with
|
||||
in this thermal zone.
|
||||
This interface function unbind a thermal cooling device from the certain
|
||||
trip point of a thermal zone device. This function is usually called in
|
||||
the thermal zone device .unbind callback.
|
||||
tz: the thermal zone device
|
||||
cdev: thermal cooling device
|
||||
trip: indicates which trip point the cooling devices is associated with
|
||||
in this thermal zone.
|
||||
|
||||
2. sysfs attributes structure
|
||||
|
||||
|
@ -114,153 +114,166 @@ if hwmon is compiled in or built as a module.
|
|||
|
||||
Thermal zone device sys I/F, created once it's registered:
|
||||
/sys/class/thermal/thermal_zone[0-*]:
|
||||
|-----type: Type of the thermal zone
|
||||
|-----temp: Current temperature
|
||||
|-----mode: Working mode of the thermal zone
|
||||
|-----trip_point_[0-*]_temp: Trip point temperature
|
||||
|-----trip_point_[0-*]_type: Trip point type
|
||||
|---type: Type of the thermal zone
|
||||
|---temp: Current temperature
|
||||
|---mode: Working mode of the thermal zone
|
||||
|---trip_point_[0-*]_temp: Trip point temperature
|
||||
|---trip_point_[0-*]_type: Trip point type
|
||||
|
||||
Thermal cooling device sys I/F, created once it's registered:
|
||||
/sys/class/thermal/cooling_device[0-*]:
|
||||
|-----type : Type of the cooling device(processor/fan/...)
|
||||
|-----max_state: Maximum cooling state of the cooling device
|
||||
|-----cur_state: Current cooling state of the cooling device
|
||||
|---type: Type of the cooling device(processor/fan/...)
|
||||
|---max_state: Maximum cooling state of the cooling device
|
||||
|---cur_state: Current cooling state of the cooling device
|
||||
|
||||
|
||||
These two dynamic attributes are created/removed in pairs.
|
||||
They represent the relationship between a thermal zone and its associated cooling device.
|
||||
They are created/removed for each
|
||||
thermal_zone_bind_cooling_device/thermal_zone_unbind_cooling_device successful execution.
|
||||
Then next two dynamic attributes are created/removed in pairs. They represent
|
||||
the relationship between a thermal zone and its associated cooling device.
|
||||
They are created/removed for each successful execution of
|
||||
thermal_zone_bind_cooling_device/thermal_zone_unbind_cooling_device.
|
||||
|
||||
/sys/class/thermal/thermal_zone[0-*]
|
||||
|-----cdev[0-*]: The [0-*]th cooling device in the current thermal zone
|
||||
|-----cdev[0-*]_trip_point: Trip point that cdev[0-*] is associated with
|
||||
/sys/class/thermal/thermal_zone[0-*]:
|
||||
|---cdev[0-*]: [0-*]th cooling device in current thermal zone
|
||||
|---cdev[0-*]_trip_point: Trip point that cdev[0-*] is associated with
|
||||
|
||||
Besides the thermal zone device sysfs I/F and cooling device sysfs I/F,
|
||||
the generic thermal driver also creates a hwmon sysfs I/F for each _type_ of
|
||||
thermal zone device. E.g. the generic thermal driver registers one hwmon class device
|
||||
and build the associated hwmon sysfs I/F for all the registered ACPI thermal zones.
|
||||
the generic thermal driver also creates a hwmon sysfs I/F for each _type_
|
||||
of thermal zone device. E.g. the generic thermal driver registers one hwmon
|
||||
class device and build the associated hwmon sysfs I/F for all the registered
|
||||
ACPI thermal zones.
|
||||
|
||||
/sys/class/hwmon/hwmon[0-*]:
|
||||
|-----name: The type of the thermal zone devices.
|
||||
|-----temp[1-*]_input: The current temperature of thermal zone [1-*].
|
||||
|-----temp[1-*]_critical: The critical trip point of thermal zone [1-*].
|
||||
|---name: The type of the thermal zone devices
|
||||
|---temp[1-*]_input: The current temperature of thermal zone [1-*]
|
||||
|---temp[1-*]_critical: The critical trip point of thermal zone [1-*]
|
||||
|
||||
Please read Documentation/hwmon/sysfs-interface for additional information.
|
||||
|
||||
***************************
|
||||
* Thermal zone attributes *
|
||||
***************************
|
||||
|
||||
type Strings which represent the thermal zone type.
|
||||
This is given by thermal zone driver as part of registration.
|
||||
Eg: "acpitz" indicates it's an ACPI thermal device.
|
||||
In order to keep it consistent with hwmon sys attribute,
|
||||
this should be a short, lowercase string,
|
||||
not containing spaces nor dashes.
|
||||
RO
|
||||
Required
|
||||
type
|
||||
Strings which represent the thermal zone type.
|
||||
This is given by thermal zone driver as part of registration.
|
||||
E.g: "acpitz" indicates it's an ACPI thermal device.
|
||||
In order to keep it consistent with hwmon sys attribute; this should
|
||||
be a short, lowercase string, not containing spaces nor dashes.
|
||||
RO, Required
|
||||
|
||||
temp Current temperature as reported by thermal zone (sensor)
|
||||
Unit: millidegree Celsius
|
||||
RO
|
||||
Required
|
||||
temp
|
||||
Current temperature as reported by thermal zone (sensor).
|
||||
Unit: millidegree Celsius
|
||||
RO, Required
|
||||
|
||||
mode One of the predefined values in [kernel, user]
|
||||
This file gives information about the algorithm
|
||||
that is currently managing the thermal zone.
|
||||
It can be either default kernel based algorithm
|
||||
or user space application.
|
||||
RW
|
||||
Optional
|
||||
kernel = Thermal management in kernel thermal zone driver.
|
||||
user = Preventing kernel thermal zone driver actions upon
|
||||
trip points so that user application can take full
|
||||
charge of the thermal management.
|
||||
mode
|
||||
One of the predefined values in [kernel, user].
|
||||
This file gives information about the algorithm that is currently
|
||||
managing the thermal zone. It can be either default kernel based
|
||||
algorithm or user space application.
|
||||
kernel = Thermal management in kernel thermal zone driver.
|
||||
user = Preventing kernel thermal zone driver actions upon
|
||||
trip points so that user application can take full
|
||||
charge of the thermal management.
|
||||
RW, Optional
|
||||
|
||||
trip_point_[0-*]_temp The temperature above which trip point will be fired
|
||||
Unit: millidegree Celsius
|
||||
RO
|
||||
Optional
|
||||
trip_point_[0-*]_temp
|
||||
The temperature above which trip point will be fired.
|
||||
Unit: millidegree Celsius
|
||||
RO, Optional
|
||||
|
||||
trip_point_[0-*]_type Strings which indicate the type of the trip point
|
||||
E.g. it can be one of critical, hot, passive,
|
||||
active[0-*] for ACPI thermal zone.
|
||||
RO
|
||||
Optional
|
||||
trip_point_[0-*]_type
|
||||
Strings which indicate the type of the trip point.
|
||||
E.g. it can be one of critical, hot, passive, active[0-*] for ACPI
|
||||
thermal zone.
|
||||
RO, Optional
|
||||
|
||||
cdev[0-*] Sysfs link to the thermal cooling device node where the sys I/F
|
||||
for cooling device throttling control represents.
|
||||
RO
|
||||
Optional
|
||||
cdev[0-*]
|
||||
Sysfs link to the thermal cooling device node where the sys I/F
|
||||
for cooling device throttling control represents.
|
||||
RO, Optional
|
||||
|
||||
cdev[0-*]_trip_point The trip point with which cdev[0-*] is associated in this thermal zone
|
||||
-1 means the cooling device is not associated with any trip point.
|
||||
RO
|
||||
Optional
|
||||
cdev[0-*]_trip_point
|
||||
The trip point with which cdev[0-*] is associated in this thermal
|
||||
zone; -1 means the cooling device is not associated with any trip
|
||||
point.
|
||||
RO, Optional
|
||||
|
||||
******************************
|
||||
* Cooling device attributes *
|
||||
******************************
|
||||
passive
|
||||
Attribute is only present for zones in which the passive cooling
|
||||
policy is not supported by native thermal driver. Default is zero
|
||||
and can be set to a temperature (in millidegrees) to enable a
|
||||
passive trip point for the zone. Activation is done by polling with
|
||||
an interval of 1 second.
|
||||
Unit: millidegrees Celsius
|
||||
RW, Optional
|
||||
|
||||
type String which represents the type of device
|
||||
eg: For generic ACPI: this should be "Fan",
|
||||
"Processor" or "LCD"
|
||||
eg. For memory controller device on intel_menlow platform:
|
||||
this should be "Memory controller"
|
||||
RO
|
||||
Required
|
||||
*****************************
|
||||
* Cooling device attributes *
|
||||
*****************************
|
||||
|
||||
max_state The maximum permissible cooling state of this cooling device.
|
||||
RO
|
||||
Required
|
||||
type
|
||||
String which represents the type of device, e.g:
|
||||
- for generic ACPI: should be "Fan", "Processor" or "LCD"
|
||||
- for memory controller device on intel_menlow platform:
|
||||
should be "Memory controller".
|
||||
RO, Required
|
||||
|
||||
cur_state The current cooling state of this cooling device.
|
||||
the value can any integer numbers between 0 and max_state,
|
||||
cur_state == 0 means no cooling
|
||||
cur_state == max_state means the maximum cooling.
|
||||
RW
|
||||
Required
|
||||
max_state
|
||||
The maximum permissible cooling state of this cooling device.
|
||||
RO, Required
|
||||
|
||||
cur_state
|
||||
The current cooling state of this cooling device.
|
||||
The value can any integer numbers between 0 and max_state:
|
||||
- cur_state == 0 means no cooling
|
||||
- cur_state == max_state means the maximum cooling.
|
||||
RW, Required
|
||||
|
||||
3. A simple implementation
|
||||
|
||||
ACPI thermal zone may support multiple trip points like critical/hot/passive/active.
|
||||
If an ACPI thermal zone supports critical, passive, active[0] and active[1] at the same time,
|
||||
it may register itself as a thermal_zone_device (thermal_zone1) with 4 trip points in all.
|
||||
It has one processor and one fan, which are both registered as thermal_cooling_device.
|
||||
If the processor is listed in _PSL method, and the fan is listed in _AL0 method,
|
||||
the sys I/F structure will be built like this:
|
||||
ACPI thermal zone may support multiple trip points like critical, hot,
|
||||
passive, active. If an ACPI thermal zone supports critical, passive,
|
||||
active[0] and active[1] at the same time, it may register itself as a
|
||||
thermal_zone_device (thermal_zone1) with 4 trip points in all.
|
||||
It has one processor and one fan, which are both registered as
|
||||
thermal_cooling_device.
|
||||
|
||||
If the processor is listed in _PSL method, and the fan is listed in _AL0
|
||||
method, the sys I/F structure will be built like this:
|
||||
|
||||
/sys/class/thermal:
|
||||
|
||||
|thermal_zone1:
|
||||
|-----type: acpitz
|
||||
|-----temp: 37000
|
||||
|-----mode: kernel
|
||||
|-----trip_point_0_temp: 100000
|
||||
|-----trip_point_0_type: critical
|
||||
|-----trip_point_1_temp: 80000
|
||||
|-----trip_point_1_type: passive
|
||||
|-----trip_point_2_temp: 70000
|
||||
|-----trip_point_2_type: active0
|
||||
|-----trip_point_3_temp: 60000
|
||||
|-----trip_point_3_type: active1
|
||||
|-----cdev0: --->/sys/class/thermal/cooling_device0
|
||||
|-----cdev0_trip_point: 1 /* cdev0 can be used for passive */
|
||||
|-----cdev1: --->/sys/class/thermal/cooling_device3
|
||||
|-----cdev1_trip_point: 2 /* cdev1 can be used for active[0]*/
|
||||
|---type: acpitz
|
||||
|---temp: 37000
|
||||
|---mode: kernel
|
||||
|---trip_point_0_temp: 100000
|
||||
|---trip_point_0_type: critical
|
||||
|---trip_point_1_temp: 80000
|
||||
|---trip_point_1_type: passive
|
||||
|---trip_point_2_temp: 70000
|
||||
|---trip_point_2_type: active0
|
||||
|---trip_point_3_temp: 60000
|
||||
|---trip_point_3_type: active1
|
||||
|---cdev0: --->/sys/class/thermal/cooling_device0
|
||||
|---cdev0_trip_point: 1 /* cdev0 can be used for passive */
|
||||
|---cdev1: --->/sys/class/thermal/cooling_device3
|
||||
|---cdev1_trip_point: 2 /* cdev1 can be used for active[0]*/
|
||||
|
||||
|cooling_device0:
|
||||
|-----type: Processor
|
||||
|-----max_state: 8
|
||||
|-----cur_state: 0
|
||||
|---type: Processor
|
||||
|---max_state: 8
|
||||
|---cur_state: 0
|
||||
|
||||
|cooling_device3:
|
||||
|-----type: Fan
|
||||
|-----max_state: 2
|
||||
|-----cur_state: 0
|
||||
|---type: Fan
|
||||
|---max_state: 2
|
||||
|---cur_state: 0
|
||||
|
||||
/sys/class/hwmon:
|
||||
|
||||
|hwmon0:
|
||||
|-----name: acpitz
|
||||
|-----temp1_input: 37000
|
||||
|-----temp1_crit: 100000
|
||||
|---name: acpitz
|
||||
|---temp1_input: 37000
|
||||
|---temp1_crit: 100000
|
||||
|
|
|
@ -1231,6 +1231,7 @@ something like this simple program:
|
|||
#include <sys/stat.h>
|
||||
#include <fcntl.h>
|
||||
#include <unistd.h>
|
||||
#include <string.h>
|
||||
|
||||
#define _STR(x) #x
|
||||
#define STR(x) _STR(x)
|
||||
|
@ -1265,6 +1266,7 @@ const char *find_debugfs(void)
|
|||
return NULL;
|
||||
}
|
||||
|
||||
strcat(debugfs, "/tracing/");
|
||||
debugfs_found = 1;
|
||||
|
||||
return debugfs;
|
||||
|
|
1
Documentation/vm/.gitignore
vendored
1
Documentation/vm/.gitignore
vendored
|
@ -1 +1,2 @@
|
|||
page-types
|
||||
slabinfo
|
||||
|
|
136
Documentation/vm/hwpoison.txt
Normal file
136
Documentation/vm/hwpoison.txt
Normal file
|
@ -0,0 +1,136 @@
|
|||
What is hwpoison?
|
||||
|
||||
Upcoming Intel CPUs have support for recovering from some memory errors
|
||||
(``MCA recovery''). This requires the OS to declare a page "poisoned",
|
||||
kill the processes associated with it and avoid using it in the future.
|
||||
|
||||
This patchkit implements the necessary infrastructure in the VM.
|
||||
|
||||
To quote the overview comment:
|
||||
|
||||
* High level machine check handler. Handles pages reported by the
|
||||
* hardware as being corrupted usually due to a 2bit ECC memory or cache
|
||||
* failure.
|
||||
*
|
||||
* This focusses on pages detected as corrupted in the background.
|
||||
* When the current CPU tries to consume corruption the currently
|
||||
* running process can just be killed directly instead. This implies
|
||||
* that if the error cannot be handled for some reason it's safe to
|
||||
* just ignore it because no corruption has been consumed yet. Instead
|
||||
* when that happens another machine check will happen.
|
||||
*
|
||||
* Handles page cache pages in various states. The tricky part
|
||||
* here is that we can access any page asynchronous to other VM
|
||||
* users, because memory failures could happen anytime and anywhere,
|
||||
* possibly violating some of their assumptions. This is why this code
|
||||
* has to be extremely careful. Generally it tries to use normal locking
|
||||
* rules, as in get the standard locks, even if that means the
|
||||
* error handling takes potentially a long time.
|
||||
*
|
||||
* Some of the operations here are somewhat inefficient and have non
|
||||
* linear algorithmic complexity, because the data structures have not
|
||||
* been optimized for this case. This is in particular the case
|
||||
* for the mapping from a vma to a process. Since this case is expected
|
||||
* to be rare we hope we can get away with this.
|
||||
|
||||
The code consists of a the high level handler in mm/memory-failure.c,
|
||||
a new page poison bit and various checks in the VM to handle poisoned
|
||||
pages.
|
||||
|
||||
The main target right now is KVM guests, but it works for all kinds
|
||||
of applications. KVM support requires a recent qemu-kvm release.
|
||||
|
||||
For the KVM use there was need for a new signal type so that
|
||||
KVM can inject the machine check into the guest with the proper
|
||||
address. This in theory allows other applications to handle
|
||||
memory failures too. The expection is that near all applications
|
||||
won't do that, but some very specialized ones might.
|
||||
|
||||
---
|
||||
|
||||
There are two (actually three) modi memory failure recovery can be in:
|
||||
|
||||
vm.memory_failure_recovery sysctl set to zero:
|
||||
All memory failures cause a panic. Do not attempt recovery.
|
||||
(on x86 this can be also affected by the tolerant level of the
|
||||
MCE subsystem)
|
||||
|
||||
early kill
|
||||
(can be controlled globally and per process)
|
||||
Send SIGBUS to the application as soon as the error is detected
|
||||
This allows applications who can process memory errors in a gentle
|
||||
way (e.g. drop affected object)
|
||||
This is the mode used by KVM qemu.
|
||||
|
||||
late kill
|
||||
Send SIGBUS when the application runs into the corrupted page.
|
||||
This is best for memory error unaware applications and default
|
||||
Note some pages are always handled as late kill.
|
||||
|
||||
---
|
||||
|
||||
User control:
|
||||
|
||||
vm.memory_failure_recovery
|
||||
See sysctl.txt
|
||||
|
||||
vm.memory_failure_early_kill
|
||||
Enable early kill mode globally
|
||||
|
||||
PR_MCE_KILL
|
||||
Set early/late kill mode/revert to system default
|
||||
arg1: PR_MCE_KILL_CLEAR: Revert to system default
|
||||
arg1: PR_MCE_KILL_SET: arg2 defines thread specific mode
|
||||
PR_MCE_KILL_EARLY: Early kill
|
||||
PR_MCE_KILL_LATE: Late kill
|
||||
PR_MCE_KILL_DEFAULT: Use system global default
|
||||
PR_MCE_KILL_GET
|
||||
return current mode
|
||||
|
||||
|
||||
---
|
||||
|
||||
Testing:
|
||||
|
||||
madvise(MADV_POISON, ....)
|
||||
(as root)
|
||||
Poison a page in the process for testing
|
||||
|
||||
|
||||
hwpoison-inject module through debugfs
|
||||
/sys/debug/hwpoison/corrupt-pfn
|
||||
|
||||
Inject hwpoison fault at PFN echoed into this file
|
||||
|
||||
|
||||
Architecture specific MCE injector
|
||||
|
||||
x86 has mce-inject, mce-test
|
||||
|
||||
Some portable hwpoison test programs in mce-test, see blow.
|
||||
|
||||
---
|
||||
|
||||
References:
|
||||
|
||||
http://halobates.de/mce-lc09-2.pdf
|
||||
Overview presentation from LinuxCon 09
|
||||
|
||||
git://git.kernel.org/pub/scm/utils/cpu/mce/mce-test.git
|
||||
Test suite (hwpoison specific portable tests in tsrc)
|
||||
|
||||
git://git.kernel.org/pub/scm/utils/cpu/mce/mce-inject.git
|
||||
x86 specific injector
|
||||
|
||||
|
||||
---
|
||||
|
||||
Limitations:
|
||||
|
||||
- Not all page types are supported and never will. Most kernel internal
|
||||
objects cannot be recovered, only LRU pages for now.
|
||||
- Right now hugepage support is missing.
|
||||
|
||||
---
|
||||
Andi Kleen, Oct 2009
|
||||
|
|
@ -52,15 +52,15 @@ The KSM daemon is controlled by sysfs files in /sys/kernel/mm/ksm/,
|
|||
readable by all but writable only by root:
|
||||
|
||||
max_kernel_pages - set to maximum number of kernel pages that KSM may use
|
||||
e.g. "echo 2000 > /sys/kernel/mm/ksm/max_kernel_pages"
|
||||
e.g. "echo 100000 > /sys/kernel/mm/ksm/max_kernel_pages"
|
||||
Value 0 imposes no limit on the kernel pages KSM may use;
|
||||
but note that any process using MADV_MERGEABLE can cause
|
||||
KSM to allocate these pages, unswappable until it exits.
|
||||
Default: 2000 (chosen for demonstration purposes)
|
||||
Default: quarter of memory (chosen to not pin too much)
|
||||
|
||||
pages_to_scan - how many present pages to scan before ksmd goes to sleep
|
||||
e.g. "echo 200 > /sys/kernel/mm/ksm/pages_to_scan"
|
||||
Default: 200 (chosen for demonstration purposes)
|
||||
e.g. "echo 100 > /sys/kernel/mm/ksm/pages_to_scan"
|
||||
Default: 100 (chosen for demonstration purposes)
|
||||
|
||||
sleep_millisecs - how many milliseconds ksmd should sleep before next scan
|
||||
e.g. "echo 20 > /sys/kernel/mm/ksm/sleep_millisecs"
|
||||
|
@ -70,7 +70,8 @@ run - set 0 to stop ksmd from running but keep merged pages,
|
|||
set 1 to run ksmd e.g. "echo 1 > /sys/kernel/mm/ksm/run",
|
||||
set 2 to stop ksmd and unmerge all pages currently merged,
|
||||
but leave mergeable areas registered for next run
|
||||
Default: 1 (for immediate use by apps which register)
|
||||
Default: 0 (must be changed to 1 to activate KSM,
|
||||
except if CONFIG_SYSFS is disabled)
|
||||
|
||||
The effectiveness of KSM and MADV_MERGEABLE is shown in /sys/kernel/mm/ksm/:
|
||||
|
||||
|
@ -86,4 +87,4 @@ pages_volatile embraces several different kinds of activity, but a high
|
|||
proportion there would also indicate poor use of madvise MADV_MERGEABLE.
|
||||
|
||||
Izik Eidus,
|
||||
Hugh Dickins, 30 July 2009
|
||||
Hugh Dickins, 24 Sept 2009
|
||||
|
|
|
@ -80,7 +80,7 @@ Note: PTL can also be used to guarantee that no new clones using the
|
|||
mm start up ... this is a loose form of stability on mm_users. For
|
||||
example, it is used in copy_mm to protect against a racing tlb_gather_mmu
|
||||
single address space optimization, so that the zap_page_range (from
|
||||
vmtruncate) does not lose sending ipi's to cloned threads that might
|
||||
truncate) does not lose sending ipi's to cloned threads that might
|
||||
be spawned underneath it and go to user mode to drag in pte's into tlbs.
|
||||
|
||||
swap_lock
|
||||
|
|
|
@ -2,9 +2,13 @@
|
|||
* page-types: Tool for querying page flags
|
||||
*
|
||||
* Copyright (C) 2009 Intel corporation
|
||||
* Copyright (C) 2009 Wu Fengguang <fengguang.wu@intel.com>
|
||||
*
|
||||
* Authors: Wu Fengguang <fengguang.wu@intel.com>
|
||||
*
|
||||
* Released under the General Public License (GPL).
|
||||
*/
|
||||
|
||||
#define _LARGEFILE64_SOURCE
|
||||
#include <stdio.h>
|
||||
#include <stdlib.h>
|
||||
#include <unistd.h>
|
||||
|
@ -13,11 +17,32 @@
|
|||
#include <string.h>
|
||||
#include <getopt.h>
|
||||
#include <limits.h>
|
||||
#include <assert.h>
|
||||
#include <sys/types.h>
|
||||
#include <sys/errno.h>
|
||||
#include <sys/fcntl.h>
|
||||
|
||||
|
||||
/*
|
||||
* pagemap kernel ABI bits
|
||||
*/
|
||||
|
||||
#define PM_ENTRY_BYTES sizeof(uint64_t)
|
||||
#define PM_STATUS_BITS 3
|
||||
#define PM_STATUS_OFFSET (64 - PM_STATUS_BITS)
|
||||
#define PM_STATUS_MASK (((1LL << PM_STATUS_BITS) - 1) << PM_STATUS_OFFSET)
|
||||
#define PM_STATUS(nr) (((nr) << PM_STATUS_OFFSET) & PM_STATUS_MASK)
|
||||
#define PM_PSHIFT_BITS 6
|
||||
#define PM_PSHIFT_OFFSET (PM_STATUS_OFFSET - PM_PSHIFT_BITS)
|
||||
#define PM_PSHIFT_MASK (((1LL << PM_PSHIFT_BITS) - 1) << PM_PSHIFT_OFFSET)
|
||||
#define PM_PSHIFT(x) (((u64) (x) << PM_PSHIFT_OFFSET) & PM_PSHIFT_MASK)
|
||||
#define PM_PFRAME_MASK ((1LL << PM_PSHIFT_OFFSET) - 1)
|
||||
#define PM_PFRAME(x) ((x) & PM_PFRAME_MASK)
|
||||
|
||||
#define PM_PRESENT PM_STATUS(4LL)
|
||||
#define PM_SWAP PM_STATUS(2LL)
|
||||
|
||||
|
||||
/*
|
||||
* kernel page flags
|
||||
*/
|
||||
|
@ -47,7 +72,9 @@
|
|||
#define KPF_COMPOUND_TAIL 16
|
||||
#define KPF_HUGE 17
|
||||
#define KPF_UNEVICTABLE 18
|
||||
#define KPF_HWPOISON 19
|
||||
#define KPF_NOPAGE 20
|
||||
#define KPF_KSM 21
|
||||
|
||||
/* [32-] kernel hacking assistances */
|
||||
#define KPF_RESERVED 32
|
||||
|
@ -94,7 +121,9 @@ static char *page_flag_names[] = {
|
|||
[KPF_COMPOUND_TAIL] = "T:compound_tail",
|
||||
[KPF_HUGE] = "G:huge",
|
||||
[KPF_UNEVICTABLE] = "u:unevictable",
|
||||
[KPF_HWPOISON] = "X:hwpoison",
|
||||
[KPF_NOPAGE] = "n:nopage",
|
||||
[KPF_KSM] = "x:ksm",
|
||||
|
||||
[KPF_RESERVED] = "r:reserved",
|
||||
[KPF_MLOCKED] = "m:mlocked",
|
||||
|
@ -126,6 +155,11 @@ static int nr_addr_ranges;
|
|||
static unsigned long opt_offset[MAX_ADDR_RANGES];
|
||||
static unsigned long opt_size[MAX_ADDR_RANGES];
|
||||
|
||||
#define MAX_VMAS 10240
|
||||
static int nr_vmas;
|
||||
static unsigned long pg_start[MAX_VMAS];
|
||||
static unsigned long pg_end[MAX_VMAS];
|
||||
|
||||
#define MAX_BIT_FILTERS 64
|
||||
static int nr_bit_filters;
|
||||
static uint64_t opt_mask[MAX_BIT_FILTERS];
|
||||
|
@ -133,9 +167,15 @@ static uint64_t opt_bits[MAX_BIT_FILTERS];
|
|||
|
||||
static int page_size;
|
||||
|
||||
#define PAGES_BATCH (64 << 10) /* 64k pages */
|
||||
static int pagemap_fd;
|
||||
static int kpageflags_fd;
|
||||
static uint64_t kpageflags_buf[KPF_BYTES * PAGES_BATCH];
|
||||
|
||||
static int opt_hwpoison;
|
||||
static int opt_unpoison;
|
||||
|
||||
static char *hwpoison_debug_fs = "/debug/hwpoison";
|
||||
static int hwpoison_inject_fd;
|
||||
static int hwpoison_forget_fd;
|
||||
|
||||
#define HASH_SHIFT 13
|
||||
#define HASH_SIZE (1 << HASH_SHIFT)
|
||||
|
@ -158,6 +198,11 @@ static uint64_t page_flags[HASH_SIZE];
|
|||
type __min2 = (y); \
|
||||
__min1 < __min2 ? __min1 : __min2; })
|
||||
|
||||
#define max_t(type, x, y) ({ \
|
||||
type __max1 = (x); \
|
||||
type __max2 = (y); \
|
||||
__max1 > __max2 ? __max1 : __max2; })
|
||||
|
||||
static unsigned long pages2mb(unsigned long pages)
|
||||
{
|
||||
return (pages * page_size) >> 20;
|
||||
|
@ -173,6 +218,74 @@ static void fatal(const char *x, ...)
|
|||
exit(EXIT_FAILURE);
|
||||
}
|
||||
|
||||
static int checked_open(const char *pathname, int flags)
|
||||
{
|
||||
int fd = open(pathname, flags);
|
||||
|
||||
if (fd < 0) {
|
||||
perror(pathname);
|
||||
exit(EXIT_FAILURE);
|
||||
}
|
||||
|
||||
return fd;
|
||||
}
|
||||
|
||||
/*
|
||||
* pagemap/kpageflags routines
|
||||
*/
|
||||
|
||||
static unsigned long do_u64_read(int fd, char *name,
|
||||
uint64_t *buf,
|
||||
unsigned long index,
|
||||
unsigned long count)
|
||||
{
|
||||
long bytes;
|
||||
|
||||
if (index > ULONG_MAX / 8)
|
||||
fatal("index overflow: %lu\n", index);
|
||||
|
||||
if (lseek(fd, index * 8, SEEK_SET) < 0) {
|
||||
perror(name);
|
||||
exit(EXIT_FAILURE);
|
||||
}
|
||||
|
||||
bytes = read(fd, buf, count * 8);
|
||||
if (bytes < 0) {
|
||||
perror(name);
|
||||
exit(EXIT_FAILURE);
|
||||
}
|
||||
if (bytes % 8)
|
||||
fatal("partial read: %lu bytes\n", bytes);
|
||||
|
||||
return bytes / 8;
|
||||
}
|
||||
|
||||
static unsigned long kpageflags_read(uint64_t *buf,
|
||||
unsigned long index,
|
||||
unsigned long pages)
|
||||
{
|
||||
return do_u64_read(kpageflags_fd, PROC_KPAGEFLAGS, buf, index, pages);
|
||||
}
|
||||
|
||||
static unsigned long pagemap_read(uint64_t *buf,
|
||||
unsigned long index,
|
||||
unsigned long pages)
|
||||
{
|
||||
return do_u64_read(pagemap_fd, "/proc/pid/pagemap", buf, index, pages);
|
||||
}
|
||||
|
||||
static unsigned long pagemap_pfn(uint64_t val)
|
||||
{
|
||||
unsigned long pfn;
|
||||
|
||||
if (val & PM_PRESENT)
|
||||
pfn = PM_PFRAME(val);
|
||||
else
|
||||
pfn = 0;
|
||||
|
||||
return pfn;
|
||||
}
|
||||
|
||||
|
||||
/*
|
||||
* page flag names
|
||||
|
@ -221,29 +334,39 @@ static char *page_flag_longname(uint64_t flags)
|
|||
* page list and summary
|
||||
*/
|
||||
|
||||
static void show_page_range(unsigned long offset, uint64_t flags)
|
||||
static void show_page_range(unsigned long voffset,
|
||||
unsigned long offset, uint64_t flags)
|
||||
{
|
||||
static uint64_t flags0;
|
||||
static unsigned long voff;
|
||||
static unsigned long index;
|
||||
static unsigned long count;
|
||||
|
||||
if (flags == flags0 && offset == index + count) {
|
||||
if (flags == flags0 && offset == index + count &&
|
||||
(!opt_pid || voffset == voff + count)) {
|
||||
count++;
|
||||
return;
|
||||
}
|
||||
|
||||
if (count)
|
||||
printf("%lu\t%lu\t%s\n",
|
||||
if (count) {
|
||||
if (opt_pid)
|
||||
printf("%lx\t", voff);
|
||||
printf("%lx\t%lx\t%s\n",
|
||||
index, count, page_flag_name(flags0));
|
||||
}
|
||||
|
||||
flags0 = flags;
|
||||
index = offset;
|
||||
voff = voffset;
|
||||
count = 1;
|
||||
}
|
||||
|
||||
static void show_page(unsigned long offset, uint64_t flags)
|
||||
static void show_page(unsigned long voffset,
|
||||
unsigned long offset, uint64_t flags)
|
||||
{
|
||||
printf("%lu\t%s\n", offset, page_flag_name(flags));
|
||||
if (opt_pid)
|
||||
printf("%lx\t", voffset);
|
||||
printf("%lx\t%s\n", offset, page_flag_name(flags));
|
||||
}
|
||||
|
||||
static void show_summary(void)
|
||||
|
@ -320,6 +443,62 @@ static uint64_t well_known_flags(uint64_t flags)
|
|||
return flags;
|
||||
}
|
||||
|
||||
static uint64_t kpageflags_flags(uint64_t flags)
|
||||
{
|
||||
flags = expand_overloaded_flags(flags);
|
||||
|
||||
if (!opt_raw)
|
||||
flags = well_known_flags(flags);
|
||||
|
||||
return flags;
|
||||
}
|
||||
|
||||
/*
|
||||
* page actions
|
||||
*/
|
||||
|
||||
static void prepare_hwpoison_fd(void)
|
||||
{
|
||||
char buf[100];
|
||||
|
||||
if (opt_hwpoison && !hwpoison_inject_fd) {
|
||||
sprintf(buf, "%s/corrupt-pfn", hwpoison_debug_fs);
|
||||
hwpoison_inject_fd = checked_open(buf, O_WRONLY);
|
||||
}
|
||||
|
||||
if (opt_unpoison && !hwpoison_forget_fd) {
|
||||
sprintf(buf, "%s/renew-pfn", hwpoison_debug_fs);
|
||||
hwpoison_forget_fd = checked_open(buf, O_WRONLY);
|
||||
}
|
||||
}
|
||||
|
||||
static int hwpoison_page(unsigned long offset)
|
||||
{
|
||||
char buf[100];
|
||||
int len;
|
||||
|
||||
len = sprintf(buf, "0x%lx\n", offset);
|
||||
len = write(hwpoison_inject_fd, buf, len);
|
||||
if (len < 0) {
|
||||
perror("hwpoison inject");
|
||||
return len;
|
||||
}
|
||||
return 0;
|
||||
}
|
||||
|
||||
static int unpoison_page(unsigned long offset)
|
||||
{
|
||||
char buf[100];
|
||||
int len;
|
||||
|
||||
len = sprintf(buf, "0x%lx\n", offset);
|
||||
len = write(hwpoison_forget_fd, buf, len);
|
||||
if (len < 0) {
|
||||
perror("hwpoison forget");
|
||||
return len;
|
||||
}
|
||||
return 0;
|
||||
}
|
||||
|
||||
/*
|
||||
* page frame walker
|
||||
|
@ -352,73 +531,124 @@ static int hash_slot(uint64_t flags)
|
|||
exit(EXIT_FAILURE);
|
||||
}
|
||||
|
||||
static void add_page(unsigned long offset, uint64_t flags)
|
||||
static void add_page(unsigned long voffset,
|
||||
unsigned long offset, uint64_t flags)
|
||||
{
|
||||
flags = expand_overloaded_flags(flags);
|
||||
|
||||
if (!opt_raw)
|
||||
flags = well_known_flags(flags);
|
||||
flags = kpageflags_flags(flags);
|
||||
|
||||
if (!bit_mask_ok(flags))
|
||||
return;
|
||||
|
||||
if (opt_hwpoison)
|
||||
hwpoison_page(offset);
|
||||
if (opt_unpoison)
|
||||
unpoison_page(offset);
|
||||
|
||||
if (opt_list == 1)
|
||||
show_page_range(offset, flags);
|
||||
show_page_range(voffset, offset, flags);
|
||||
else if (opt_list == 2)
|
||||
show_page(offset, flags);
|
||||
show_page(voffset, offset, flags);
|
||||
|
||||
nr_pages[hash_slot(flags)]++;
|
||||
total_pages++;
|
||||
}
|
||||
|
||||
static void walk_pfn(unsigned long index, unsigned long count)
|
||||
#define KPAGEFLAGS_BATCH (64 << 10) /* 64k pages */
|
||||
static void walk_pfn(unsigned long voffset,
|
||||
unsigned long index,
|
||||
unsigned long count)
|
||||
{
|
||||
uint64_t buf[KPAGEFLAGS_BATCH];
|
||||
unsigned long batch;
|
||||
unsigned long n;
|
||||
unsigned long pages;
|
||||
unsigned long i;
|
||||
|
||||
if (index > ULONG_MAX / KPF_BYTES)
|
||||
fatal("index overflow: %lu\n", index);
|
||||
while (count) {
|
||||
batch = min_t(unsigned long, count, KPAGEFLAGS_BATCH);
|
||||
pages = kpageflags_read(buf, index, batch);
|
||||
if (pages == 0)
|
||||
break;
|
||||
|
||||
lseek(kpageflags_fd, index * KPF_BYTES, SEEK_SET);
|
||||
for (i = 0; i < pages; i++)
|
||||
add_page(voffset + i, index + i, buf[i]);
|
||||
|
||||
index += pages;
|
||||
count -= pages;
|
||||
}
|
||||
}
|
||||
|
||||
#define PAGEMAP_BATCH (64 << 10)
|
||||
static void walk_vma(unsigned long index, unsigned long count)
|
||||
{
|
||||
uint64_t buf[PAGEMAP_BATCH];
|
||||
unsigned long batch;
|
||||
unsigned long pages;
|
||||
unsigned long pfn;
|
||||
unsigned long i;
|
||||
|
||||
while (count) {
|
||||
batch = min_t(unsigned long, count, PAGES_BATCH);
|
||||
n = read(kpageflags_fd, kpageflags_buf, batch * KPF_BYTES);
|
||||
if (n == 0)
|
||||
batch = min_t(unsigned long, count, PAGEMAP_BATCH);
|
||||
pages = pagemap_read(buf, index, batch);
|
||||
if (pages == 0)
|
||||
break;
|
||||
if (n < 0) {
|
||||
perror(PROC_KPAGEFLAGS);
|
||||
exit(EXIT_FAILURE);
|
||||
|
||||
for (i = 0; i < pages; i++) {
|
||||
pfn = pagemap_pfn(buf[i]);
|
||||
if (pfn)
|
||||
walk_pfn(index + i, pfn, 1);
|
||||
}
|
||||
|
||||
if (n % KPF_BYTES != 0)
|
||||
fatal("partial read: %lu bytes\n", n);
|
||||
n = n / KPF_BYTES;
|
||||
|
||||
for (i = 0; i < n; i++)
|
||||
add_page(index + i, kpageflags_buf[i]);
|
||||
|
||||
index += batch;
|
||||
count -= batch;
|
||||
index += pages;
|
||||
count -= pages;
|
||||
}
|
||||
}
|
||||
|
||||
static void walk_task(unsigned long index, unsigned long count)
|
||||
{
|
||||
const unsigned long end = index + count;
|
||||
unsigned long start;
|
||||
int i = 0;
|
||||
|
||||
while (index < end) {
|
||||
|
||||
while (pg_end[i] <= index)
|
||||
if (++i >= nr_vmas)
|
||||
return;
|
||||
if (pg_start[i] >= end)
|
||||
return;
|
||||
|
||||
start = max_t(unsigned long, pg_start[i], index);
|
||||
index = min_t(unsigned long, pg_end[i], end);
|
||||
|
||||
assert(start < index);
|
||||
walk_vma(start, index - start);
|
||||
}
|
||||
}
|
||||
|
||||
static void add_addr_range(unsigned long offset, unsigned long size)
|
||||
{
|
||||
if (nr_addr_ranges >= MAX_ADDR_RANGES)
|
||||
fatal("too many addr ranges\n");
|
||||
|
||||
opt_offset[nr_addr_ranges] = offset;
|
||||
opt_size[nr_addr_ranges] = min_t(unsigned long, size, ULONG_MAX-offset);
|
||||
nr_addr_ranges++;
|
||||
}
|
||||
|
||||
static void walk_addr_ranges(void)
|
||||
{
|
||||
int i;
|
||||
|
||||
kpageflags_fd = open(PROC_KPAGEFLAGS, O_RDONLY);
|
||||
if (kpageflags_fd < 0) {
|
||||
perror(PROC_KPAGEFLAGS);
|
||||
exit(EXIT_FAILURE);
|
||||
}
|
||||
kpageflags_fd = checked_open(PROC_KPAGEFLAGS, O_RDONLY);
|
||||
|
||||
if (!nr_addr_ranges)
|
||||
walk_pfn(0, ULONG_MAX);
|
||||
add_addr_range(0, ULONG_MAX);
|
||||
|
||||
for (i = 0; i < nr_addr_ranges; i++)
|
||||
walk_pfn(opt_offset[i], opt_size[i]);
|
||||
if (!opt_pid)
|
||||
walk_pfn(0, opt_offset[i], opt_size[i]);
|
||||
else
|
||||
walk_task(opt_offset[i], opt_size[i]);
|
||||
|
||||
close(kpageflags_fd);
|
||||
}
|
||||
|
@ -446,20 +676,22 @@ static void usage(void)
|
|||
" -r|--raw Raw mode, for kernel developers\n"
|
||||
" -a|--addr addr-spec Walk a range of pages\n"
|
||||
" -b|--bits bits-spec Walk pages with specified bits\n"
|
||||
#if 0 /* planned features */
|
||||
" -p|--pid pid Walk process address space\n"
|
||||
#if 0 /* planned features */
|
||||
" -f|--file filename Walk file address space\n"
|
||||
#endif
|
||||
" -l|--list Show page details in ranges\n"
|
||||
" -L|--list-each Show page details one by one\n"
|
||||
" -N|--no-summary Don't show summay info\n"
|
||||
" -X|--hwpoison hwpoison pages\n"
|
||||
" -x|--unpoison unpoison pages\n"
|
||||
" -h|--help Show this usage message\n"
|
||||
"addr-spec:\n"
|
||||
" N one page at offset N (unit: pages)\n"
|
||||
" N+M pages range from N to N+M-1\n"
|
||||
" N,M pages range from N to M-1\n"
|
||||
" N, pages range from N to end\n"
|
||||
" ,M pages range from 0 to M\n"
|
||||
" ,M pages range from 0 to M-1\n"
|
||||
"bits-spec:\n"
|
||||
" bit1,bit2 (flags & (bit1|bit2)) != 0\n"
|
||||
" bit1,bit2=bit1 (flags & (bit1|bit2)) == bit1\n"
|
||||
|
@ -496,23 +728,55 @@ static unsigned long long parse_number(const char *str)
|
|||
|
||||
static void parse_pid(const char *str)
|
||||
{
|
||||
FILE *file;
|
||||
char buf[5000];
|
||||
|
||||
opt_pid = parse_number(str);
|
||||
|
||||
sprintf(buf, "/proc/%d/pagemap", opt_pid);
|
||||
pagemap_fd = checked_open(buf, O_RDONLY);
|
||||
|
||||
sprintf(buf, "/proc/%d/maps", opt_pid);
|
||||
file = fopen(buf, "r");
|
||||
if (!file) {
|
||||
perror(buf);
|
||||
exit(EXIT_FAILURE);
|
||||
}
|
||||
|
||||
while (fgets(buf, sizeof(buf), file) != NULL) {
|
||||
unsigned long vm_start;
|
||||
unsigned long vm_end;
|
||||
unsigned long long pgoff;
|
||||
int major, minor;
|
||||
char r, w, x, s;
|
||||
unsigned long ino;
|
||||
int n;
|
||||
|
||||
n = sscanf(buf, "%lx-%lx %c%c%c%c %llx %x:%x %lu",
|
||||
&vm_start,
|
||||
&vm_end,
|
||||
&r, &w, &x, &s,
|
||||
&pgoff,
|
||||
&major, &minor,
|
||||
&ino);
|
||||
if (n < 10) {
|
||||
fprintf(stderr, "unexpected line: %s\n", buf);
|
||||
continue;
|
||||
}
|
||||
pg_start[nr_vmas] = vm_start / page_size;
|
||||
pg_end[nr_vmas] = vm_end / page_size;
|
||||
if (++nr_vmas >= MAX_VMAS) {
|
||||
fprintf(stderr, "too many VMAs\n");
|
||||
break;
|
||||
}
|
||||
}
|
||||
fclose(file);
|
||||
}
|
||||
|
||||
static void parse_file(const char *name)
|
||||
{
|
||||
}
|
||||
|
||||
static void add_addr_range(unsigned long offset, unsigned long size)
|
||||
{
|
||||
if (nr_addr_ranges >= MAX_ADDR_RANGES)
|
||||
fatal("too much addr ranges\n");
|
||||
|
||||
opt_offset[nr_addr_ranges] = offset;
|
||||
opt_size[nr_addr_ranges] = size;
|
||||
nr_addr_ranges++;
|
||||
}
|
||||
|
||||
static void parse_addr_range(const char *optarg)
|
||||
{
|
||||
unsigned long offset;
|
||||
|
@ -630,6 +894,8 @@ static struct option opts[] = {
|
|||
{ "list" , 0, NULL, 'l' },
|
||||
{ "list-each" , 0, NULL, 'L' },
|
||||
{ "no-summary", 0, NULL, 'N' },
|
||||
{ "hwpoison" , 0, NULL, 'X' },
|
||||
{ "unpoison" , 0, NULL, 'x' },
|
||||
{ "help" , 0, NULL, 'h' },
|
||||
{ NULL , 0, NULL, 0 }
|
||||
};
|
||||
|
@ -641,7 +907,7 @@ int main(int argc, char *argv[])
|
|||
page_size = getpagesize();
|
||||
|
||||
while ((c = getopt_long(argc, argv,
|
||||
"rp:f:a:b:lLNh", opts, NULL)) != -1) {
|
||||
"rp:f:a:b:lLNXxh", opts, NULL)) != -1) {
|
||||
switch (c) {
|
||||
case 'r':
|
||||
opt_raw = 1;
|
||||
|
@ -667,6 +933,14 @@ int main(int argc, char *argv[])
|
|||
case 'N':
|
||||
opt_no_summary = 1;
|
||||
break;
|
||||
case 'X':
|
||||
opt_hwpoison = 1;
|
||||
prepare_hwpoison_fd();
|
||||
break;
|
||||
case 'x':
|
||||
opt_unpoison = 1;
|
||||
prepare_hwpoison_fd();
|
||||
break;
|
||||
case 'h':
|
||||
usage();
|
||||
exit(0);
|
||||
|
@ -676,15 +950,17 @@ int main(int argc, char *argv[])
|
|||
}
|
||||
}
|
||||
|
||||
if (opt_list && opt_pid)
|
||||
printf("voffset\t");
|
||||
if (opt_list == 1)
|
||||
printf("offset\tcount\tflags\n");
|
||||
printf("offset\tlen\tflags\n");
|
||||
if (opt_list == 2)
|
||||
printf("offset\tflags\n");
|
||||
|
||||
walk_addr_ranges();
|
||||
|
||||
if (opt_list == 1)
|
||||
show_page_range(0, 0); /* drain the buffer */
|
||||
show_page_range(0, 0, 0); /* drain the buffer */
|
||||
|
||||
if (opt_no_summary)
|
||||
return 0;
|
||||
|
|
|
@ -57,7 +57,9 @@ There are three components to pagemap:
|
|||
16. COMPOUND_TAIL
|
||||
16. HUGE
|
||||
18. UNEVICTABLE
|
||||
19. HWPOISON
|
||||
20. NOPAGE
|
||||
21. KSM
|
||||
|
||||
Short descriptions to the page flags:
|
||||
|
||||
|
@ -86,9 +88,15 @@ Short descriptions to the page flags:
|
|||
17. HUGE
|
||||
this is an integral part of a HugeTLB page
|
||||
|
||||
19. HWPOISON
|
||||
hardware detected memory corruption on this page: don't touch the data!
|
||||
|
||||
20. NOPAGE
|
||||
no page frame exists at the requested address
|
||||
|
||||
21. KSM
|
||||
identical memory pages dynamically shared between one or more processes
|
||||
|
||||
[IO related page flags]
|
||||
1. ERROR IO error occurred
|
||||
3. UPTODATE page has up-to-date data
|
||||
|
|
|
@ -24,8 +24,8 @@ General Remarks
|
|||
|
||||
Valid addresses are 0x18, 0x19, 0x1a, and 0x1b.
|
||||
However, the device cannot be detected without writing to the i2c bus, so no
|
||||
detection is done.
|
||||
You should force the device address.
|
||||
detection is done. You should instantiate the device explicitly.
|
||||
|
||||
$ modprobe ds2482 force=0,0x18
|
||||
$ modprobe ds2482
|
||||
$ echo ds2482 0x18 > /sys/bus/i2c/devices/i2c-0/new_device
|
||||
|
||||
|
|
343
MAINTAINERS
343
MAINTAINERS
|
@ -65,43 +65,51 @@ trivial patch so apply some common sense.
|
|||
|
||||
8. Happy hacking.
|
||||
|
||||
-----------------------------------
|
||||
Descriptions of section entries:
|
||||
|
||||
Maintainers List (try to look for most precise areas first)
|
||||
P: Person (obsolete)
|
||||
M: Mail patches to: FullName <address@domain>
|
||||
L: Mailing list that is relevant to this area
|
||||
W: Web-page with status/info
|
||||
T: SCM tree type and location. Type is one of: git, hg, quilt, stgit.
|
||||
S: Status, one of the following:
|
||||
Supported: Someone is actually paid to look after this.
|
||||
Maintained: Someone actually looks after it.
|
||||
Odd Fixes: It has a maintainer but they don't have time to do
|
||||
much other than throw the odd patch in. See below..
|
||||
Orphan: No current maintainer [but maybe you could take the
|
||||
role as you write your new code].
|
||||
Obsolete: Old code. Something tagged obsolete generally means
|
||||
it has been replaced by a better system and you
|
||||
should be using that.
|
||||
F: Files and directories with wildcard patterns.
|
||||
A trailing slash includes all files and subdirectory files.
|
||||
F: drivers/net/ all files in and below drivers/net
|
||||
F: drivers/net/* all files in drivers/net, but not below
|
||||
F: */net/* all files in "any top level directory"/net
|
||||
One pattern per line. Multiple F: lines acceptable.
|
||||
X: Files and directories that are NOT maintained, same rules as F:
|
||||
Files exclusions are tested before file matches.
|
||||
Can be useful for excluding a specific subdirectory, for instance:
|
||||
F: net/
|
||||
X: net/ipv6/
|
||||
matches all files in and below net excluding net/ipv6/
|
||||
K: Keyword perl extended regex pattern to match content in a
|
||||
patch or file. For instance:
|
||||
K: of_get_profile
|
||||
matches patches or files that contain "of_get_profile"
|
||||
K: \b(printk|pr_(info|err))\b
|
||||
matches patches or files that contain one or more of the words
|
||||
printk, pr_info or pr_err
|
||||
One regex pattern per line. Multiple K: lines acceptable.
|
||||
|
||||
Note: For the hard of thinking, this list is meant to remain in alphabetical
|
||||
order. If you could add yourselves to it in alphabetical order that would be
|
||||
so much easier [Ed]
|
||||
|
||||
P: Person (obsolete)
|
||||
M: Mail patches to: FullName <address@domain>
|
||||
L: Mailing list that is relevant to this area
|
||||
W: Web-page with status/info
|
||||
T: SCM tree type and location. Type is one of: git, hg, quilt, stgit.
|
||||
S: Status, one of the following:
|
||||
Maintainers List (try to look for most precise areas first)
|
||||
|
||||
Supported: Someone is actually paid to look after this.
|
||||
Maintained: Someone actually looks after it.
|
||||
Odd Fixes: It has a maintainer but they don't have time to do
|
||||
much other than throw the odd patch in. See below..
|
||||
Orphan: No current maintainer [but maybe you could take the
|
||||
role as you write your new code].
|
||||
Obsolete: Old code. Something tagged obsolete generally means
|
||||
it has been replaced by a better system and you
|
||||
should be using that.
|
||||
|
||||
F: Files and directories with wildcard patterns.
|
||||
A trailing slash includes all files and subdirectory files.
|
||||
F: drivers/net/ all files in and below drivers/net
|
||||
F: drivers/net/* all files in drivers/net, but not below
|
||||
F: */net/* all files in "any top level directory"/net
|
||||
One pattern per line. Multiple F: lines acceptable.
|
||||
X: Files and directories that are NOT maintained, same rules as F:
|
||||
Files exclusions are tested before file matches.
|
||||
Can be useful for excluding a specific subdirectory, for instance:
|
||||
F: net/
|
||||
X: net/ipv6/
|
||||
matches all files in and below net excluding net/ipv6/
|
||||
-----------------------------------
|
||||
|
||||
3C505 NETWORK DRIVER
|
||||
M: Philip Blundell <philb@gnu.org>
|
||||
|
@ -174,7 +182,7 @@ M: Ron Minnich <rminnich@sandia.gov>
|
|||
M: Latchesar Ionkov <lucho@ionkov.net>
|
||||
L: v9fs-developer@lists.sourceforge.net
|
||||
W: http://swik.net/v9fs
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/ericvh/v9fs.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs.git
|
||||
S: Maintained
|
||||
F: Documentation/filesystems/9p.txt
|
||||
F: fs/9p/
|
||||
|
@ -257,11 +265,12 @@ W: http://www.lesswatts.org/projects/acpi/
|
|||
S: Supported
|
||||
F: drivers/acpi/fan.c
|
||||
|
||||
ACPI PCI HOTPLUG DRIVER
|
||||
M: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
|
||||
L: linux-pci@vger.kernel.org
|
||||
ACPI PROCESSOR AGGREGATOR DRIVER
|
||||
M: Shaohua Li <shaohua.li@intel.com>
|
||||
L: linux-acpi@vger.kernel.org
|
||||
W: http://www.lesswatts.org/projects/acpi/
|
||||
S: Supported
|
||||
F: drivers/pci/hotplug/acpi*
|
||||
F: drivers/acpi/acpi_pad.c
|
||||
|
||||
ACPI THERMAL DRIVER
|
||||
M: Zhang Rui <rui.zhang@intel.com>
|
||||
|
@ -503,10 +512,32 @@ W: http://www.arm.linux.org.uk/
|
|||
S: Maintained
|
||||
F: arch/arm/
|
||||
|
||||
ARM PRIMECELL AACI PL041 DRIVER
|
||||
M: Russell King <linux@arm.linux.org.uk>
|
||||
S: Maintained
|
||||
F: sound/arm/aaci.*
|
||||
|
||||
ARM PRIMECELL CLCD PL110 DRIVER
|
||||
M: Russell King <linux@arm.linux.org.uk>
|
||||
S: Maintained
|
||||
F: drivers/video/amba-clcd.*
|
||||
|
||||
ARM PRIMECELL KMI PL050 DRIVER
|
||||
M: Russell King <linux@arm.linux.org.uk>
|
||||
S: Maintained
|
||||
F: drivers/input/serio/ambakmi.*
|
||||
F: include/linux/amba/kmi.h
|
||||
|
||||
ARM PRIMECELL MMCI PL180/1 DRIVER
|
||||
S: Orphan
|
||||
F: drivers/mmc/host/mmci.*
|
||||
|
||||
ARM PRIMECELL BUS SUPPORT
|
||||
M: Russell King <linux@arm.linux.org.uk>
|
||||
S: Maintained
|
||||
F: drivers/amba/
|
||||
F: include/linux/amba/bus.h
|
||||
|
||||
ARM/ADI ROADRUNNER MACHINE SUPPORT
|
||||
M: Lennert Buytenhek <kernel@wantstofly.org>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
|
@ -576,6 +607,11 @@ M: Mike Rapoport <mike@compulab.co.il>
|
|||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
|
||||
ARM/CONTEC MICRO9 MACHINE SUPPORT
|
||||
M: Hubert Feurstein <hubert.feurstein@contec.at>
|
||||
S: Maintained
|
||||
F: arch/arm/mach-ep93xx/micro9.c
|
||||
|
||||
ARM/CORGI MACHINE SUPPORT
|
||||
M: Richard Purdie <rpurdie@rpsys.net>
|
||||
S: Maintained
|
||||
|
@ -652,24 +688,24 @@ ARM/INTEL IOP32X ARM ARCHITECTURE
|
|||
M: Lennert Buytenhek <kernel@wantstofly.org>
|
||||
M: Dan Williams <dan.j.williams@intel.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Supported
|
||||
S: Maintained
|
||||
|
||||
ARM/INTEL IOP33X ARM ARCHITECTURE
|
||||
M: Dan Williams <dan.j.williams@intel.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Supported
|
||||
S: Maintained
|
||||
|
||||
ARM/INTEL IOP13XX ARM ARCHITECTURE
|
||||
M: Lennert Buytenhek <kernel@wantstofly.org>
|
||||
M: Dan Williams <dan.j.williams@intel.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Supported
|
||||
S: Maintained
|
||||
|
||||
ARM/INTEL IQ81342EX MACHINE SUPPORT
|
||||
M: Lennert Buytenhek <kernel@wantstofly.org>
|
||||
M: Dan Williams <dan.j.williams@intel.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Supported
|
||||
S: Maintained
|
||||
|
||||
ARM/INTEL IXP2000 ARM ARCHITECTURE
|
||||
M: Lennert Buytenhek <kernel@wantstofly.org>
|
||||
|
@ -686,11 +722,18 @@ M: Lennert Buytenhek <kernel@wantstofly.org>
|
|||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
|
||||
ARM/INTEL IXP4XX ARM ARCHITECTURE
|
||||
M: Imre Kaloz <kaloz@openwrt.org>
|
||||
M: Krzysztof Halasa <khc@pm.waw.pl>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: arch/arm/mach-ixp4xx/
|
||||
|
||||
ARM/INTEL XSC3 (MANZANO) ARM CORE
|
||||
M: Lennert Buytenhek <kernel@wantstofly.org>
|
||||
M: Dan Williams <dan.j.williams@intel.com>
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Supported
|
||||
S: Maintained
|
||||
|
||||
ARM/IP FABRICS DOUBLE ESPRESSO MACHINE SUPPORT
|
||||
M: Lennert Buytenhek <kernel@wantstofly.org>
|
||||
|
@ -739,20 +782,37 @@ M: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
|
|||
M: Dirk Opfer <dirk@opfer-online.de>
|
||||
S: Maintained
|
||||
|
||||
ARM/PALMTX,PALMT5,PALMLD,PALMTE2 SUPPORT
|
||||
ARM/PALMTX,PALMT5,PALMLD,PALMTE2,PALMTC SUPPORT
|
||||
M: Marek Vasut <marek.vasut@gmail.com>
|
||||
L: linux-arm-kernel@lists.infradead.org
|
||||
W: http://hackndev.com
|
||||
S: Maintained
|
||||
F: arch/arm/mach-pxa/include/mach/palmtx.h
|
||||
F: arch/arm/mach-pxa/palmtx.c
|
||||
F: arch/arm/mach-pxa/include/mach/palmt5.h
|
||||
F: arch/arm/mach-pxa/palmt5.c
|
||||
F: arch/arm/mach-pxa/include/mach/palmld.h
|
||||
F: arch/arm/mach-pxa/palmld.c
|
||||
F: arch/arm/mach-pxa/include/mach/palmte2.h
|
||||
F: arch/arm/mach-pxa/palmte2.c
|
||||
F: arch/arm/mach-pxa/include/mach/palmtc.h
|
||||
F: arch/arm/mach-pxa/palmtc.c
|
||||
|
||||
ARM/PALM TREO 680 SUPPORT
|
||||
M: Tomas Cech <sleep_walker@suse.cz>
|
||||
L: linux-arm-kernel@lists.infradead.org
|
||||
W: http://hackndev.com
|
||||
S: Maintained
|
||||
F: arch/arm/mach-pxa/include/mach/treo680.h
|
||||
F: arch/arm/mach-pxa/treo680.c
|
||||
|
||||
ARM/PALMZ72 SUPPORT
|
||||
M: Sergey Lapin <slapin@ossfans.org>
|
||||
L: linux-arm-kernel@lists.infradead.org
|
||||
W: http://hackndev.com
|
||||
S: Maintained
|
||||
F: arch/arm/mach-pxa/include/mach/palmz72.h
|
||||
F: arch/arm/mach-pxa/palmz72.c
|
||||
|
||||
ARM/PLEB SUPPORT
|
||||
M: Peter Chubb <pleb@gelato.unsw.edu.au>
|
||||
|
@ -868,7 +928,6 @@ M: Karol Kozimor <sziwan@users.sourceforge.net>
|
|||
L: acpi4asus-user@lists.sourceforge.net
|
||||
W: http://acpi4asus.sf.net
|
||||
S: Maintained
|
||||
F: arch/x86/kernel/acpi/boot.c
|
||||
F: drivers/platform/x86/asus_acpi.c
|
||||
|
||||
ASUS ASB100 HARDWARE MONITOR DRIVER
|
||||
|
@ -962,7 +1021,7 @@ F: drivers/net/atlx/
|
|||
|
||||
ATM
|
||||
M: Chas Williams <chas@cmf.nrl.navy.mil>
|
||||
L: linux-atm-general@lists.sourceforge.net (subscribers-only)
|
||||
L: linux-atm-general@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: netdev@vger.kernel.org
|
||||
W: http://linux-atm.sourceforge.net
|
||||
S: Maintained
|
||||
|
@ -990,7 +1049,7 @@ F: drivers/serial/atmel_serial.c
|
|||
|
||||
ATMEL LCDFB DRIVER
|
||||
M: Nicolas Ferre <nicolas.ferre@atmel.com>
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/video/atmel_lcdfb.c
|
||||
F: include/video/atmel_lcdc.h
|
||||
|
@ -1206,6 +1265,12 @@ L: netdev@vger.kernel.org
|
|||
S: Supported
|
||||
F: drivers/net/tg3.*
|
||||
|
||||
BROCADE BFA FC SCSI DRIVER
|
||||
M: Jing Huang <huangj@brocade.com>
|
||||
L: linux-scsi@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/scsi/bfa/
|
||||
|
||||
BSG (block layer generic sg v4 driver)
|
||||
M: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
||||
L: linux-scsi@vger.kernel.org
|
||||
|
@ -1443,6 +1508,7 @@ F: mm/*cgroup*
|
|||
|
||||
CORETEMP HARDWARE MONITORING DRIVER
|
||||
M: Rudolf Marek <r.marek@assembler.cz>
|
||||
M: Huaxu Wan <huaxu.wan@intel.com>
|
||||
L: lm-sensors@lm-sensors.org
|
||||
S: Maintained
|
||||
F: Documentation/hwmon/coretemp
|
||||
|
@ -2033,7 +2099,7 @@ S: Maintained
|
|||
F: fs/*
|
||||
|
||||
FINTEK F75375S HARDWARE MONITOR AND FAN CONTROLLER DRIVER
|
||||
M: Riku Voipio <riku.vipio@iki.fi>
|
||||
M: Riku Voipio <riku.voipio@iki.fi>
|
||||
L: lm-sensors@lm-sensors.org
|
||||
S: Maintained
|
||||
F: drivers/hwmon/f75375s.c
|
||||
|
@ -2069,7 +2135,7 @@ F: drivers/net/wan/dlci.c
|
|||
F: drivers/net/wan/sdla.c
|
||||
|
||||
FRAMEBUFFER LAYER
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
W: http://linux-fbdev.sourceforge.net/
|
||||
S: Orphan
|
||||
F: Documentation/fb/
|
||||
|
@ -2092,7 +2158,7 @@ F: drivers/i2c/busses/i2c-cpm.c
|
|||
|
||||
FREESCALE IMX / MXC FRAMEBUFFER DRIVER
|
||||
M: Sascha Hauer <kernel@pengutronix.de>
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
|
||||
S: Maintained
|
||||
F: arch/arm/plat-mxc/include/mach/imxfb.h
|
||||
|
@ -2114,7 +2180,7 @@ S: Supported
|
|||
F: arch/powerpc/sysdev/qe_lib/
|
||||
F: arch/powerpc/include/asm/*qe.h
|
||||
|
||||
FREESCALE USB PERIPHERIAL DRIVERS
|
||||
FREESCALE USB PERIPHERAL DRIVERS
|
||||
M: Li Yang <leoli@freescale.com>
|
||||
L: linux-usb@vger.kernel.org
|
||||
L: linuxppc-dev@ozlabs.org
|
||||
|
@ -2165,18 +2231,6 @@ F: Documentation/filesystems/caching/
|
|||
F: fs/fscache/
|
||||
F: include/linux/fscache*.h
|
||||
|
||||
TRACING
|
||||
M: Steven Rostedt <rostedt@goodmis.org>
|
||||
M: Frederic Weisbecker <fweisbec@gmail.com>
|
||||
M: Ingo Molnar <mingo@redhat.com>
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git tracing/core
|
||||
S: Maintained
|
||||
F: Documentation/trace/ftrace.txt
|
||||
F: arch/*/*/*/ftrace.h
|
||||
F: arch/*/kernel/ftrace.c
|
||||
F: include/*/ftrace.h include/trace/ include/linux/trace*.h
|
||||
F: kernel/trace/
|
||||
|
||||
FUJITSU FR-V (FRV) PORT
|
||||
M: David Howells <dhowells@redhat.com>
|
||||
S: Maintained
|
||||
|
@ -2235,9 +2289,8 @@ S: Maintained
|
|||
F: include/asm-generic
|
||||
|
||||
GENERIC UIO DRIVER FOR PCI DEVICES
|
||||
M: Michael S. Tsirkin <mst@redhat.com>
|
||||
M: "Michael S. Tsirkin" <mst@redhat.com>
|
||||
L: kvm@vger.kernel.org
|
||||
L: linux-kernel@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/uio/uio_pci_generic.c
|
||||
|
||||
|
@ -2281,6 +2334,13 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
|||
S: Maintained
|
||||
F: drivers/media/video/gspca/finepix.c
|
||||
|
||||
GSPCA GL860 SUBDRIVER
|
||||
M: Olivier Lorin <o.lorin@laposte.net>
|
||||
L: linux-media@vger.kernel.org
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
|
||||
S: Maintained
|
||||
F: drivers/media/video/gspca/gl860/
|
||||
|
||||
GSPCA M5602 SUBDRIVER
|
||||
M: Erik Andren <erik.andren@gmail.com>
|
||||
L: linux-media@vger.kernel.org
|
||||
|
@ -2324,7 +2384,9 @@ S: Orphan
|
|||
F: drivers/hwmon/
|
||||
|
||||
HARDWARE RANDOM NUMBER GENERATOR CORE
|
||||
S: Orphan
|
||||
M: Matt Mackall <mpm@selenic.com>
|
||||
M: Herbert Xu <herbert@gondor.apana.org.au>
|
||||
S: Odd fixes
|
||||
F: Documentation/hw_random.txt
|
||||
F: drivers/char/hw_random/
|
||||
F: include/linux/hw_random.h
|
||||
|
@ -2500,8 +2562,7 @@ S: Maintained
|
|||
F: Documentation/i2c/
|
||||
F: drivers/i2c/
|
||||
F: include/linux/i2c.h
|
||||
F: include/linux/i2c-dev.h
|
||||
F: include/linux/i2c-id.h
|
||||
F: include/linux/i2c-*.h
|
||||
|
||||
I2C-TINY-USB DRIVER
|
||||
M: Till Harbaum <till@harbaum.org>
|
||||
|
@ -2576,6 +2637,7 @@ L: linux1394-devel@lists.sourceforge.net
|
|||
W: http://www.linux1394.org/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git
|
||||
S: Maintained
|
||||
F: Documentation/debugging-via-ohci1394.txt
|
||||
F: drivers/ieee1394/
|
||||
|
||||
IEEE 1394 RAW I/O DRIVER
|
||||
|
@ -2601,7 +2663,7 @@ S: Supported
|
|||
F: security/integrity/ima/
|
||||
|
||||
IMS TWINTURBO FRAMEBUFFER DRIVER
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
S: Orphan
|
||||
F: drivers/video/imsttfb.c
|
||||
|
||||
|
@ -2636,14 +2698,14 @@ F: drivers/input/
|
|||
|
||||
INTEL FRAMEBUFFER DRIVER (excluding 810 and 815)
|
||||
M: Sylvain Meyer <sylvain.meyer@worldonline.fr>
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/fb/intelfb.txt
|
||||
F: drivers/video/intelfb/
|
||||
|
||||
INTEL 810/815 FRAMEBUFFER DRIVER
|
||||
M: Antonino Daplas <adaplas@gmail.com>
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/video/i810/
|
||||
|
||||
|
@ -2675,7 +2737,7 @@ F: include/linux/intel-iommu.h
|
|||
|
||||
INTEL IOP-ADMA DMA DRIVER
|
||||
M: Dan Williams <dan.j.williams@intel.com>
|
||||
S: Supported
|
||||
S: Maintained
|
||||
F: drivers/dma/iop-adma.c
|
||||
|
||||
INTEL IXP4XX QMGR, NPE, ETHERNET and HSS SUPPORT
|
||||
|
@ -2789,7 +2851,7 @@ F: drivers/infiniband/hw/ipath/
|
|||
|
||||
IPMI SUBSYSTEM
|
||||
M: Corey Minyard <minyard@acm.org>
|
||||
L: openipmi-developer@lists.sourceforge.net
|
||||
L: openipmi-developer@lists.sourceforge.net (moderated for non-subscribers)
|
||||
W: http://openipmi.sourceforge.net/
|
||||
S: Supported
|
||||
F: Documentation/IPMI.txt
|
||||
|
@ -2953,19 +3015,16 @@ S: Maintained
|
|||
F: fs/autofs4/
|
||||
|
||||
KERNEL BUILD
|
||||
M: Sam Ravnborg <sam@ravnborg.org>
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild-next.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/sam/kbuild-fixes.git
|
||||
L: linux-kbuild@vger.kernel.org
|
||||
S: Maintained
|
||||
S: Orphan
|
||||
F: Documentation/kbuild/
|
||||
F: Makefile
|
||||
F: scripts/Makefile.*
|
||||
|
||||
KERNEL JANITORS
|
||||
L: kernel-janitors@vger.kernel.org
|
||||
W: http://www.kerneljanitors.org/
|
||||
S: Maintained
|
||||
W: http://janitor.kernelnewbies.org/
|
||||
S: Odd Fixes
|
||||
|
||||
KERNEL NFSD, SUNRPC, AND LOCKD SERVERS
|
||||
M: "J. Bruce Fields" <bfields@fieldses.org>
|
||||
|
@ -3050,9 +3109,13 @@ F: kernel/kgdb.c
|
|||
|
||||
KMEMCHECK
|
||||
M: Vegard Nossum <vegardno@ifi.uio.no>
|
||||
P Pekka Enberg
|
||||
M: penberg@cs.helsinki.fi
|
||||
M: Pekka Enberg <penberg@cs.helsinki.fi>
|
||||
S: Maintained
|
||||
F: Documentation/kmemcheck.txt
|
||||
F: arch/x86/include/asm/kmemcheck.h
|
||||
F: arch/x86/mm/kmemcheck/
|
||||
F: include/linux/kmemcheck.h
|
||||
F: mm/kmemcheck.c
|
||||
|
||||
KMEMLEAK
|
||||
M: Catalin Marinas <catalin.marinas@arm.com>
|
||||
|
@ -3353,7 +3416,7 @@ S: Supported
|
|||
|
||||
MATROX FRAMEBUFFER DRIVER
|
||||
M: Petr Vandrovec <vandrove@vc.cvut.cz>
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/video/matrox/matroxfb_*
|
||||
F: include/linux/matroxfb.h
|
||||
|
@ -3582,7 +3645,7 @@ L: netfilter@vger.kernel.org
|
|||
L: coreteam@netfilter.org
|
||||
W: http://www.netfilter.org/
|
||||
W: http://www.iptables.org/
|
||||
T: git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git
|
||||
S: Supported
|
||||
F: include/linux/netfilter*
|
||||
F: include/linux/netfilter/
|
||||
|
@ -3616,11 +3679,20 @@ F: Documentation/blockdev/nbd.txt
|
|||
F: drivers/block/nbd.c
|
||||
F: include/linux/nbd.h
|
||||
|
||||
NETWORK DROP MONITOR
|
||||
M: Neil Horman <nhorman@tuxdriver.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
W: https://fedorahosted.org/dropwatch/
|
||||
F: net/core/drop_monitor.c
|
||||
|
||||
NETWORKING [GENERAL]
|
||||
M: "David S. Miller" <davem@davemloft.net>
|
||||
L: netdev@vger.kernel.org
|
||||
W: http://www.linuxfoundation.org/en/Net
|
||||
W: http://patchwork.ozlabs.org/project/netdev/list/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git
|
||||
S: Maintained
|
||||
F: net/
|
||||
F: include/net/
|
||||
|
@ -3731,13 +3803,13 @@ F: fs/ntfs/
|
|||
|
||||
NVIDIA (rivafb and nvidiafb) FRAMEBUFFER DRIVER
|
||||
M: Antonino Daplas <adaplas@gmail.com>
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/video/riva/
|
||||
F: drivers/video/nvidia/
|
||||
|
||||
OMAP SUPPORT
|
||||
M: "Tony Lindgren <tony@atomide.com>" <tony@atomide.com>
|
||||
M: Tony Lindgren <tony@atomide.com>
|
||||
L: linux-omap@vger.kernel.org
|
||||
W: http://www.muru.com/linux/omap/
|
||||
W: http://linux.omap.com/
|
||||
|
@ -3766,7 +3838,7 @@ F: sound/soc/omap/
|
|||
|
||||
OMAP FRAMEBUFFER SUPPORT
|
||||
M: Imre Deak <imre.deak@nokia.com>
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
L: linux-omap@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/video/omap/
|
||||
|
@ -3842,6 +3914,15 @@ S: Maintained
|
|||
F: Documentation/i2c/busses/i2c-ocores
|
||||
F: drivers/i2c/busses/i2c-ocores.c
|
||||
|
||||
OPEN FIRMWARE AND FLATTENED DEVICE TREE
|
||||
M: Grant Likely <grant.likely@secretlab.ca>
|
||||
L: devicetree-discuss@lists.ozlabs.org
|
||||
W: http://fdt.secretlab.ca
|
||||
S: Maintained
|
||||
F: drivers/of
|
||||
F: include/linux/of*.h
|
||||
K: of_get_property
|
||||
|
||||
OPROFILE
|
||||
M: Robert Richter <robert.richter@amd.com>
|
||||
L: oprofile-list@lists.sf.net
|
||||
|
@ -3946,6 +4027,7 @@ F: drivers/block/paride/
|
|||
PARISC ARCHITECTURE
|
||||
M: Kyle McMartin <kyle@mcmartin.ca>
|
||||
M: Helge Deller <deller@gmx.de>
|
||||
M: "James E.J. Bottomley" <jejb@parisc-linux.org>
|
||||
L: linux-parisc@vger.kernel.org
|
||||
W: http://www.parisc-linux.org/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/kyle/parisc-2.6.git
|
||||
|
@ -3996,11 +4078,11 @@ F: Documentation/PCI/
|
|||
F: drivers/pci/
|
||||
F: include/linux/pci*
|
||||
|
||||
PCIE HOTPLUG DRIVER
|
||||
M: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
|
||||
PCI HOTPLUG
|
||||
M: Jesse Barnes <jbarnes@virtuousgeek.org>
|
||||
L: linux-pci@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/pci/pcie/
|
||||
F: drivers/pci/hotplug
|
||||
|
||||
PCMCIA SUBSYSTEM
|
||||
P: Linux PCMCIA Team
|
||||
|
@ -4029,6 +4111,13 @@ M: Peter Zijlstra <a.p.zijlstra@chello.nl>
|
|||
M: Paul Mackerras <paulus@samba.org>
|
||||
M: Ingo Molnar <mingo@elte.hu>
|
||||
S: Supported
|
||||
F: kernel/perf_event.c
|
||||
F: include/linux/perf_event.h
|
||||
F: arch/*/*/kernel/perf_event.c
|
||||
F: arch/*/include/asm/perf_event.h
|
||||
F: arch/*/lib/perf_event.c
|
||||
F: arch/*/kernel/perf_callchain.c
|
||||
F: tools/perf/
|
||||
|
||||
PERSONALITY HANDLING
|
||||
M: Christoph Hellwig <hch@infradead.org>
|
||||
|
@ -4255,21 +4344,23 @@ F: include/linux/qnxtypes.h
|
|||
|
||||
RADEON FRAMEBUFFER DISPLAY DRIVER
|
||||
M: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/video/aty/radeon*
|
||||
F: include/linux/radeonfb.h
|
||||
|
||||
RAGE128 FRAMEBUFFER DISPLAY DRIVER
|
||||
M: Paul Mackerras <paulus@samba.org>
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/video/aty/aty128fb.c
|
||||
|
||||
RALINK RT2X00 WIRELESS LAN DRIVER
|
||||
P: rt2x00 project
|
||||
M: Ivo van Doorn <IvDoorn@gmail.com>
|
||||
M: Gertjan van Wingerde <gwingerde@gmail.com>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
L: users@rt2x00.serialmonkey.com
|
||||
L: users@rt2x00.serialmonkey.com (moderated for non-subscribers)
|
||||
W: http://rt2x00.serialmonkey.com/
|
||||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/ivd/rt2x00.git
|
||||
|
@ -4355,7 +4446,7 @@ RFKILL
|
|||
M: Johannes Berg <johannes@sipsolutions.net>
|
||||
L: linux-wireless@vger.kernel.org
|
||||
S: Maintained
|
||||
F Documentation/rfkill.txt
|
||||
F: Documentation/rfkill.txt
|
||||
F: net/rfkill/
|
||||
|
||||
RISCOM8 DRIVER
|
||||
|
@ -4399,7 +4490,7 @@ F: drivers/net/wireless/rtl818x/rtl8187*
|
|||
|
||||
S3 SAVAGE FRAMEBUFFER DRIVER
|
||||
M: Antonino Daplas <adaplas@gmail.com>
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/video/savage/
|
||||
|
||||
|
@ -4478,12 +4569,11 @@ F: kernel/sched*
|
|||
F: include/linux/sched.h
|
||||
|
||||
SCORE ARCHITECTURE
|
||||
P: Chen Liqin
|
||||
M: liqin.chen@sunplusct.com
|
||||
P: Lennox Wu
|
||||
M: lennox.wu@gmail.com
|
||||
M: Chen Liqin <liqin.chen@sunplusct.com>
|
||||
M: Lennox Wu <lennox.wu@gmail.com>
|
||||
W: http://www.sunplusct.com
|
||||
S: Supported
|
||||
F: arch/score/
|
||||
|
||||
SCSI CDROM DRIVER
|
||||
M: Jens Axboe <axboe@kernel.dk>
|
||||
|
@ -4556,27 +4646,27 @@ S: Maintained
|
|||
F: drivers/mmc/host/sdricoh_cs.c
|
||||
|
||||
SECURE DIGITAL HOST CONTROLLER INTERFACE (SDHCI) DRIVER
|
||||
S: Orphan
|
||||
L: linux-mmc@vger.kernel.org
|
||||
F: drivers/mmc/host/sdhci.*
|
||||
S: Orphan
|
||||
L: linux-mmc@vger.kernel.org
|
||||
F: drivers/mmc/host/sdhci.*
|
||||
|
||||
SECURE DIGITAL HOST CONTROLLER INTERFACE, OPEN FIRMWARE BINDINGS (SDHCI-OF)
|
||||
M: Anton Vorontsov <avorontsov@ru.mvista.com>
|
||||
L: linuxppc-dev@ozlabs.org
|
||||
L: linux-mmc@vger.kernel.org
|
||||
L: linux-mmc@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/mmc/host/sdhci-of.*
|
||||
F: drivers/mmc/host/sdhci-of.*
|
||||
|
||||
SECURE DIGITAL HOST CONTROLLER INTERFACE (SDHCI) SAMSUNG DRIVER
|
||||
M: Ben Dooks <ben-linux@fluff.org>
|
||||
L: linux-mmc@vger.kernel.org
|
||||
L: linux-mmc@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/mmc/host/sdhci-s3c.c
|
||||
|
||||
SECURITY SUBSYSTEM
|
||||
M: James Morris <jmorris@namei.org>
|
||||
L: linux-security-module@vger.kernel.org (suggested Cc:)
|
||||
T: git git://www.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6.git
|
||||
W: http://security.wiki.kernel.org/
|
||||
S: Supported
|
||||
F: security/
|
||||
|
@ -4611,6 +4701,13 @@ F: drivers/ata/
|
|||
F: include/linux/ata.h
|
||||
F: include/linux/libata.h
|
||||
|
||||
SERVER ENGINES 10Gbps iSCSI - BladeEngine 2 DRIVER
|
||||
M: Jayamohan Kallickal <jayamohank@serverengines.com>
|
||||
L: linux-scsi@vger.kernel.org
|
||||
W: http://www.serverengines.com
|
||||
S: Supported
|
||||
F: drivers/scsi/be2iscsi/
|
||||
|
||||
SERVER ENGINES 10Gbps NIC - BladeEngine 2 DRIVER
|
||||
M: Sathya Perla <sathyap@serverengines.com>
|
||||
M: Subbu Seetharaman <subbus@serverengines.com>
|
||||
|
@ -4663,15 +4760,8 @@ F: drivers/serial/serial_lh7a40x.c
|
|||
F: drivers/usb/gadget/lh7a40*
|
||||
F: drivers/usb/host/ohci-lh7a40*
|
||||
|
||||
SHPC HOTPLUG DRIVER
|
||||
M: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
|
||||
L: linux-pci@vger.kernel.org
|
||||
S: Supported
|
||||
F: drivers/pci/hotplug/shpchp*
|
||||
|
||||
SIMPLE FIRMWARE INTERFACE (SFI)
|
||||
P: Len Brown
|
||||
M: lenb@kernel.org
|
||||
M: Len Brown <lenb@kernel.org>
|
||||
L: sfi-devel@simplefirmware.org
|
||||
W: http://simplefirmware.org/
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-sfi-2.6.git
|
||||
|
@ -4680,7 +4770,6 @@ F: arch/x86/kernel/*sfi*
|
|||
F: drivers/sfi/
|
||||
F: include/linux/sfi*.h
|
||||
|
||||
|
||||
SIMTEC EB110ATX (Chalice CATS)
|
||||
P: Ben Dooks
|
||||
M: Vincent Sanders <support@simtec.co.uk>
|
||||
|
@ -5120,6 +5209,20 @@ L: tpmdd-devel@lists.sourceforge.net (moderated for non-subscribers)
|
|||
S: Maintained
|
||||
F: drivers/char/tpm/
|
||||
|
||||
TRACING
|
||||
M: Steven Rostedt <rostedt@goodmis.org>
|
||||
M: Frederic Weisbecker <fweisbec@gmail.com>
|
||||
M: Ingo Molnar <mingo@redhat.com>
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git tracing/core
|
||||
S: Maintained
|
||||
F: Documentation/trace/ftrace.txt
|
||||
F: arch/*/*/*/ftrace.h
|
||||
F: arch/*/kernel/ftrace.c
|
||||
F: include/*/ftrace.h
|
||||
F: include/linux/trace*.h
|
||||
F: include/trace/
|
||||
F: kernel/trace/
|
||||
|
||||
TRIVIAL PATCHES
|
||||
M: Jiri Kosina <trivial@kernel.org>
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial.git
|
||||
|
@ -5550,7 +5653,7 @@ S: Maintained
|
|||
|
||||
UVESAFB DRIVER
|
||||
M: Michal Januszewski <spock@gentoo.org>
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
W: http://dev.gentoo.org/~spock/projects/uvesafb/
|
||||
S: Maintained
|
||||
F: Documentation/fb/uvesafb.txt
|
||||
|
@ -5583,7 +5686,7 @@ F: drivers/mmc/host/via-sdmmc.c
|
|||
VIA UNICHROME(PRO)/CHROME9 FRAMEBUFFER DRIVER
|
||||
M: Joseph Chan <JosephChan@via.com.tw>
|
||||
M: Scott Fang <ScottFang@viatech.com.cn>
|
||||
L: linux-fbdev-devel@lists.sourceforge.net (moderated for non-subscribers)
|
||||
L: linux-fbdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/video/via/
|
||||
|
||||
|
@ -5608,6 +5711,13 @@ S: Maintained
|
|||
F: drivers/vlynq/vlynq.c
|
||||
F: include/linux/vlynq.h
|
||||
|
||||
VMWARE VMXNET3 ETHERNET DRIVER
|
||||
M: Shreyas Bhatewara <sbhatewara@vmware.com>
|
||||
M: "VMware, Inc." <pv-drivers@vmware.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Maintained
|
||||
F: drivers/net/vmxnet3/
|
||||
|
||||
VOLTAGE AND CURRENT REGULATOR FRAMEWORK
|
||||
M: Liam Girdwood <lrg@slimlogic.co.uk>
|
||||
M: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
||||
|
@ -5679,8 +5789,7 @@ S: Maintained
|
|||
F: drivers/scsi/wd7000.c
|
||||
|
||||
WINBOND CIR DRIVER
|
||||
P: David Härdeman
|
||||
M: david@hardeman.nu
|
||||
M: David Härdeman <david@hardeman.nu>
|
||||
S: Maintained
|
||||
F: drivers/input/misc/winbond-cir.c
|
||||
|
||||
|
@ -5737,9 +5846,7 @@ F: drivers/input/touchscreen/*wm97*
|
|||
F: include/linux/wm97xx.h
|
||||
|
||||
WOLFSON MICROELECTRONICS PMIC DRIVERS
|
||||
P: Mark Brown
|
||||
M: broonie@opensource.wolfsonmicro.com
|
||||
L: linux-kernel@vger.kernel.org
|
||||
M: Mark Brown <broonie@opensource.wolfsonmicro.com>
|
||||
T: git git://opensource.wolfsonmicro.com/linux-2.6-audioplus
|
||||
W: http://opensource.wolfsonmicro.com/node/8
|
||||
S: Supported
|
||||
|
|
20
Makefile
20
Makefile
|
@ -1,6 +1,6 @@
|
|||
VERSION = 2
|
||||
PATCHLEVEL = 6
|
||||
SUBLEVEL = 31
|
||||
SUBLEVEL = 32
|
||||
EXTRAVERSION =
|
||||
NAME = Man-Eating Seals of Antiquity
|
||||
|
||||
|
@ -221,7 +221,7 @@ CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
|
|||
|
||||
HOSTCC = gcc
|
||||
HOSTCXX = g++
|
||||
HOSTCFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
|
||||
HOSTCFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer
|
||||
HOSTCXXFLAGS = -O2
|
||||
|
||||
# Decide whether to build built-in, modular, or both.
|
||||
|
@ -315,6 +315,7 @@ OBJCOPY = $(CROSS_COMPILE)objcopy
|
|||
OBJDUMP = $(CROSS_COMPILE)objdump
|
||||
AWK = awk
|
||||
GENKSYMS = scripts/genksyms/genksyms
|
||||
INSTALLKERNEL := installkernel
|
||||
DEPMOD = /sbin/depmod
|
||||
KALLSYMS = scripts/kallsyms
|
||||
PERL = perl
|
||||
|
@ -353,7 +354,8 @@ KERNELVERSION = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
|
|||
|
||||
export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION
|
||||
export ARCH SRCARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC
|
||||
export CPP AR NM STRIP OBJCOPY OBJDUMP MAKE AWK GENKSYMS PERL UTS_MACHINE
|
||||
export CPP AR NM STRIP OBJCOPY OBJDUMP
|
||||
export MAKE AWK GENKSYMS INSTALLKERNEL PERL UTS_MACHINE
|
||||
export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
|
||||
|
||||
export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS LDFLAGS
|
||||
|
@ -571,6 +573,9 @@ KBUILD_CFLAGS += $(call cc-option,-fno-strict-overflow)
|
|||
# revert to pre-gcc-4.4 behaviour of .eh_frame
|
||||
KBUILD_CFLAGS += $(call cc-option,-fno-dwarf2-cfi-asm)
|
||||
|
||||
# conserve stack if available
|
||||
KBUILD_CFLAGS += $(call cc-option,-fconserve-stack)
|
||||
|
||||
# Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments
|
||||
# But warn user when we do so
|
||||
warn-assign = \
|
||||
|
@ -591,12 +596,12 @@ endif
|
|||
|
||||
# Use --build-id when available.
|
||||
LDFLAGS_BUILD_ID = $(patsubst -Wl$(comma)%,%,\
|
||||
$(call ld-option, -Wl$(comma)--build-id,))
|
||||
$(call cc-ldoption, -Wl$(comma)--build-id,))
|
||||
LDFLAGS_MODULE += $(LDFLAGS_BUILD_ID)
|
||||
LDFLAGS_vmlinux += $(LDFLAGS_BUILD_ID)
|
||||
|
||||
ifeq ($(CONFIG_STRIP_ASM_SYMS),y)
|
||||
LDFLAGS_vmlinux += -X
|
||||
LDFLAGS_vmlinux += $(call ld-option, -X,)
|
||||
endif
|
||||
|
||||
# Default kernel image to build when no specific target is given.
|
||||
|
@ -980,11 +985,6 @@ prepare0: archprepare FORCE
|
|||
# All the preparing..
|
||||
prepare: prepare0
|
||||
|
||||
# Leave this as default for preprocessing vmlinux.lds.S, which is now
|
||||
# done in arch/$(ARCH)/kernel/Makefile
|
||||
|
||||
export CPPFLAGS_vmlinux.lds += -P -C -U$(ARCH)
|
||||
|
||||
# The asm symlink changes when $(ARCH) changes.
|
||||
# Detect this and ask user to run make mrproper
|
||||
# If asm is a stale symlink (point to dir that does not exist) remove it
|
||||
|
|
|
@ -35,7 +35,7 @@
|
|||
const char * prog_name;
|
||||
|
||||
|
||||
void
|
||||
static void
|
||||
usage (void)
|
||||
{
|
||||
fprintf(stderr,
|
||||
|
|
|
@ -47,7 +47,7 @@ extern struct cpuinfo_alpha cpu_data[NR_CPUS];
|
|||
extern int smp_num_cpus;
|
||||
|
||||
extern void arch_send_call_function_single_ipi(int cpu);
|
||||
extern void arch_send_call_function_ipi(cpumask_t mask);
|
||||
extern void arch_send_call_function_ipi_mask(const struct cpumask *mask);
|
||||
|
||||
#else /* CONFIG_SMP */
|
||||
|
||||
|
|
|
@ -50,32 +50,35 @@ struct thread_info {
|
|||
register struct thread_info *__current_thread_info __asm__("$8");
|
||||
#define current_thread_info() __current_thread_info
|
||||
|
||||
#endif /* __ASSEMBLY__ */
|
||||
|
||||
/* Thread information allocation. */
|
||||
#define THREAD_SIZE_ORDER 1
|
||||
#define THREAD_SIZE (2*PAGE_SIZE)
|
||||
|
||||
#endif /* __ASSEMBLY__ */
|
||||
|
||||
#define PREEMPT_ACTIVE 0x40000000
|
||||
|
||||
/*
|
||||
* Thread information flags:
|
||||
* - these are process state flags and used from assembly
|
||||
* - pending work-to-be-done flags come first to fit in and immediate operand.
|
||||
* - pending work-to-be-done flags come first and must be assigned to be
|
||||
* within bits 0 to 7 to fit in and immediate operand.
|
||||
* - ALPHA_UAC_SHIFT below must be kept consistent with the unaligned
|
||||
* control flags.
|
||||
*
|
||||
* TIF_SYSCALL_TRACE is known to be 0 via blbs.
|
||||
*/
|
||||
#define TIF_SYSCALL_TRACE 0 /* syscall trace active */
|
||||
#define TIF_SIGPENDING 1 /* signal pending */
|
||||
#define TIF_NEED_RESCHED 2 /* rescheduling necessary */
|
||||
#define TIF_POLLING_NRFLAG 3 /* poll_idle is polling NEED_RESCHED */
|
||||
#define TIF_DIE_IF_KERNEL 4 /* dik recursion lock */
|
||||
#define TIF_UAC_NOPRINT 5 /* see sysinfo.h */
|
||||
#define TIF_UAC_NOFIX 6
|
||||
#define TIF_UAC_SIGBUS 7
|
||||
#define TIF_MEMDIE 8
|
||||
#define TIF_RESTORE_SIGMASK 9 /* restore signal mask in do_signal */
|
||||
#define TIF_NOTIFY_RESUME 10 /* callback before returning to user */
|
||||
#define TIF_NOTIFY_RESUME 1 /* callback before returning to user */
|
||||
#define TIF_SIGPENDING 2 /* signal pending */
|
||||
#define TIF_NEED_RESCHED 3 /* rescheduling necessary */
|
||||
#define TIF_POLLING_NRFLAG 8 /* poll_idle is polling NEED_RESCHED */
|
||||
#define TIF_DIE_IF_KERNEL 9 /* dik recursion lock */
|
||||
#define TIF_UAC_NOPRINT 10 /* see sysinfo.h */
|
||||
#define TIF_UAC_NOFIX 11
|
||||
#define TIF_UAC_SIGBUS 12
|
||||
#define TIF_MEMDIE 13
|
||||
#define TIF_RESTORE_SIGMASK 14 /* restore signal mask in do_signal */
|
||||
#define TIF_FREEZE 16 /* is freezing for suspend */
|
||||
|
||||
#define _TIF_SYSCALL_TRACE (1<<TIF_SYSCALL_TRACE)
|
||||
|
@ -94,7 +97,7 @@ register struct thread_info *__current_thread_info __asm__("$8");
|
|||
#define _TIF_ALLWORK_MASK (_TIF_WORK_MASK \
|
||||
| _TIF_SYSCALL_TRACE)
|
||||
|
||||
#define ALPHA_UAC_SHIFT 6
|
||||
#define ALPHA_UAC_SHIFT 10
|
||||
#define ALPHA_UAC_MASK (1 << TIF_UAC_NOPRINT | 1 << TIF_UAC_NOFIX | \
|
||||
1 << TIF_UAC_SIGBUS)
|
||||
|
||||
|
|
|
@ -22,23 +22,6 @@ static inline int cpu_to_node(int cpu)
|
|||
return node;
|
||||
}
|
||||
|
||||
static inline cpumask_t node_to_cpumask(int node)
|
||||
{
|
||||
cpumask_t node_cpu_mask = CPU_MASK_NONE;
|
||||
int cpu;
|
||||
|
||||
for_each_online_cpu(cpu) {
|
||||
if (cpu_to_node(cpu) == node)
|
||||
cpu_set(cpu, node_cpu_mask);
|
||||
}
|
||||
|
||||
#ifdef DEBUG_NUMA
|
||||
printk("node %d: cpu_mask: %016lx\n", node, node_cpu_mask);
|
||||
#endif
|
||||
|
||||
return node_cpu_mask;
|
||||
}
|
||||
|
||||
extern struct cpumask node_to_cpumask_map[];
|
||||
/* FIXME: This is dumb, recalculating every time. But simple. */
|
||||
static const struct cpumask *cpumask_of_node(int node)
|
||||
|
@ -55,7 +38,6 @@ static const struct cpumask *cpumask_of_node(int node)
|
|||
return &node_to_cpumask_map[node];
|
||||
}
|
||||
|
||||
#define pcibus_to_cpumask(bus) (cpu_online_map)
|
||||
#define cpumask_of_pcibus(bus) (cpu_online_mask)
|
||||
|
||||
#endif /* !CONFIG_NUMA */
|
||||
|
|
|
@ -1016,7 +1016,7 @@ marvel_agp_bind_memory(alpha_agp_info *agp, off_t pg_start, struct agp_memory *m
|
|||
{
|
||||
struct marvel_agp_aperture *aper = agp->aperture.sysdata;
|
||||
return iommu_bind(aper->arena, aper->pg_start + pg_start,
|
||||
mem->page_count, mem->memory);
|
||||
mem->page_count, mem->pages);
|
||||
}
|
||||
|
||||
static int
|
||||
|
@ -1103,6 +1103,8 @@ marvel_agp_info(void)
|
|||
* Allocate the info structure.
|
||||
*/
|
||||
agp = kmalloc(sizeof(*agp), GFP_KERNEL);
|
||||
if (!agp)
|
||||
return NULL;
|
||||
|
||||
/*
|
||||
* Fill it in.
|
||||
|
|
|
@ -680,7 +680,7 @@ titan_agp_bind_memory(alpha_agp_info *agp, off_t pg_start, struct agp_memory *me
|
|||
{
|
||||
struct titan_agp_aperture *aper = agp->aperture.sysdata;
|
||||
return iommu_bind(aper->arena, aper->pg_start + pg_start,
|
||||
mem->page_count, mem->memory);
|
||||
mem->page_count, mem->pages);
|
||||
}
|
||||
|
||||
static int
|
||||
|
@ -757,6 +757,8 @@ titan_agp_info(void)
|
|||
* Allocate the info structure.
|
||||
*/
|
||||
agp = kmalloc(sizeof(*agp), GFP_KERNEL);
|
||||
if (!agp)
|
||||
return NULL;
|
||||
|
||||
/*
|
||||
* Fill it in.
|
||||
|
|
|
@ -13,6 +13,5 @@ static struct sighand_struct init_sighand = INIT_SIGHAND(init_sighand);
|
|||
struct task_struct init_task = INIT_TASK(init_task);
|
||||
EXPORT_SYMBOL(init_task);
|
||||
|
||||
union thread_union init_thread_union
|
||||
__attribute__((section(".data.init_thread")))
|
||||
= { INIT_THREAD_INFO(init_task) };
|
||||
union thread_union init_thread_union __init_task_data =
|
||||
{ INIT_THREAD_INFO(init_task) };
|
||||
|
|
|
@ -92,7 +92,7 @@ show_interrupts(struct seq_file *p, void *v)
|
|||
for_each_online_cpu(j)
|
||||
seq_printf(p, "%10u ", kstat_irqs_cpu(irq, j));
|
||||
#endif
|
||||
seq_printf(p, " %14s", irq_desc[irq].chip->typename);
|
||||
seq_printf(p, " %14s", irq_desc[irq].chip->name);
|
||||
seq_printf(p, " %c%s",
|
||||
(action->flags & IRQF_DISABLED)?'+':' ',
|
||||
action->name);
|
||||
|
|
|
@ -228,7 +228,7 @@ struct irqaction timer_irqaction = {
|
|||
};
|
||||
|
||||
static struct irq_chip rtc_irq_type = {
|
||||
.typename = "RTC",
|
||||
.name = "RTC",
|
||||
.startup = rtc_startup,
|
||||
.shutdown = rtc_enable_disable,
|
||||
.enable = rtc_enable_disable,
|
||||
|
|
|
@ -84,7 +84,7 @@ i8259a_end_irq(unsigned int irq)
|
|||
}
|
||||
|
||||
struct irq_chip i8259a_irq_type = {
|
||||
.typename = "XT-PIC",
|
||||
.name = "XT-PIC",
|
||||
.startup = i8259a_startup_irq,
|
||||
.shutdown = i8259a_disable_irq,
|
||||
.enable = i8259a_enable_irq,
|
||||
|
|
|
@ -71,7 +71,7 @@ pyxis_mask_and_ack_irq(unsigned int irq)
|
|||
}
|
||||
|
||||
static struct irq_chip pyxis_irq_type = {
|
||||
.typename = "PYXIS",
|
||||
.name = "PYXIS",
|
||||
.startup = pyxis_startup_irq,
|
||||
.shutdown = pyxis_disable_irq,
|
||||
.enable = pyxis_enable_irq,
|
||||
|
|
|
@ -49,7 +49,7 @@ srm_end_irq(unsigned int irq)
|
|||
|
||||
/* Handle interrupts from the SRM, assuming no additional weirdness. */
|
||||
static struct irq_chip srm_irq_type = {
|
||||
.typename = "SRM",
|
||||
.name = "SRM",
|
||||
.startup = srm_startup_irq,
|
||||
.shutdown = srm_disable_irq,
|
||||
.enable = srm_enable_irq,
|
||||
|
|
|
@ -198,7 +198,7 @@ extern unsigned long size_for_memory(unsigned long max);
|
|||
|
||||
extern int iommu_reserve(struct pci_iommu_arena *, long, long);
|
||||
extern int iommu_release(struct pci_iommu_arena *, long, long);
|
||||
extern int iommu_bind(struct pci_iommu_arena *, long, long, unsigned long *);
|
||||
extern int iommu_bind(struct pci_iommu_arena *, long, long, struct page **);
|
||||
extern int iommu_unbind(struct pci_iommu_arena *, long, long);
|
||||
|
||||
|
||||
|
|
|
@ -876,7 +876,7 @@ iommu_release(struct pci_iommu_arena *arena, long pg_start, long pg_count)
|
|||
|
||||
int
|
||||
iommu_bind(struct pci_iommu_arena *arena, long pg_start, long pg_count,
|
||||
unsigned long *physaddrs)
|
||||
struct page **pages)
|
||||
{
|
||||
unsigned long flags;
|
||||
unsigned long *ptes;
|
||||
|
@ -896,7 +896,7 @@ iommu_bind(struct pci_iommu_arena *arena, long pg_start, long pg_count,
|
|||
}
|
||||
|
||||
for(i = 0, j = pg_start; i < pg_count; i++, j++)
|
||||
ptes[j] = mk_iommu_pte(physaddrs[i]);
|
||||
ptes[j] = mk_iommu_pte(page_to_phys(pages[i]));
|
||||
|
||||
spin_unlock_irqrestore(&arena->lock, flags);
|
||||
|
||||
|
|
|
@ -19,7 +19,6 @@
|
|||
#include <linux/ptrace.h>
|
||||
#include <linux/slab.h>
|
||||
#include <linux/user.h>
|
||||
#include <linux/utsname.h>
|
||||
#include <linux/time.h>
|
||||
#include <linux/major.h>
|
||||
#include <linux/stat.h>
|
||||
|
|
|
@ -548,16 +548,16 @@ setup_profiling_timer(unsigned int multiplier)
|
|||
|
||||
|
||||
static void
|
||||
send_ipi_message(cpumask_t to_whom, enum ipi_message_type operation)
|
||||
send_ipi_message(const struct cpumask *to_whom, enum ipi_message_type operation)
|
||||
{
|
||||
int i;
|
||||
|
||||
mb();
|
||||
for_each_cpu_mask(i, to_whom)
|
||||
for_each_cpu(i, to_whom)
|
||||
set_bit(operation, &ipi_data[i].bits);
|
||||
|
||||
mb();
|
||||
for_each_cpu_mask(i, to_whom)
|
||||
for_each_cpu(i, to_whom)
|
||||
wripir(i);
|
||||
}
|
||||
|
||||
|
@ -624,7 +624,7 @@ smp_send_reschedule(int cpu)
|
|||
printk(KERN_WARNING
|
||||
"smp_send_reschedule: Sending IPI to self.\n");
|
||||
#endif
|
||||
send_ipi_message(cpumask_of_cpu(cpu), IPI_RESCHEDULE);
|
||||
send_ipi_message(cpumask_of(cpu), IPI_RESCHEDULE);
|
||||
}
|
||||
|
||||
void
|
||||
|
@ -636,17 +636,17 @@ smp_send_stop(void)
|
|||
if (hard_smp_processor_id() != boot_cpu_id)
|
||||
printk(KERN_WARNING "smp_send_stop: Not on boot cpu.\n");
|
||||
#endif
|
||||
send_ipi_message(to_whom, IPI_CPU_STOP);
|
||||
send_ipi_message(&to_whom, IPI_CPU_STOP);
|
||||
}
|
||||
|
||||
void arch_send_call_function_ipi(cpumask_t mask)
|
||||
void arch_send_call_function_ipi_mask(const struct cpumask *mask)
|
||||
{
|
||||
send_ipi_message(mask, IPI_CALL_FUNC);
|
||||
}
|
||||
|
||||
void arch_send_call_function_single_ipi(int cpu)
|
||||
{
|
||||
send_ipi_message(cpumask_of_cpu(cpu), IPI_CALL_FUNC_SINGLE);
|
||||
send_ipi_message(cpumask_of(cpu), IPI_CALL_FUNC_SINGLE);
|
||||
}
|
||||
|
||||
static void
|
||||
|
|
|
@ -90,7 +90,7 @@ alcor_end_irq(unsigned int irq)
|
|||
}
|
||||
|
||||
static struct irq_chip alcor_irq_type = {
|
||||
.typename = "ALCOR",
|
||||
.name = "ALCOR",
|
||||
.startup = alcor_startup_irq,
|
||||
.shutdown = alcor_disable_irq,
|
||||
.enable = alcor_enable_irq,
|
||||
|
|
|
@ -72,7 +72,7 @@ cabriolet_end_irq(unsigned int irq)
|
|||
}
|
||||
|
||||
static struct irq_chip cabriolet_irq_type = {
|
||||
.typename = "CABRIOLET",
|
||||
.name = "CABRIOLET",
|
||||
.startup = cabriolet_startup_irq,
|
||||
.shutdown = cabriolet_disable_irq,
|
||||
.enable = cabriolet_enable_irq,
|
||||
|
|
|
@ -199,7 +199,7 @@ clipper_set_affinity(unsigned int irq, const struct cpumask *affinity)
|
|||
}
|
||||
|
||||
static struct irq_chip dp264_irq_type = {
|
||||
.typename = "DP264",
|
||||
.name = "DP264",
|
||||
.startup = dp264_startup_irq,
|
||||
.shutdown = dp264_disable_irq,
|
||||
.enable = dp264_enable_irq,
|
||||
|
@ -210,7 +210,7 @@ static struct irq_chip dp264_irq_type = {
|
|||
};
|
||||
|
||||
static struct irq_chip clipper_irq_type = {
|
||||
.typename = "CLIPPER",
|
||||
.name = "CLIPPER",
|
||||
.startup = clipper_startup_irq,
|
||||
.shutdown = clipper_disable_irq,
|
||||
.enable = clipper_enable_irq,
|
||||
|
|
|
@ -70,7 +70,7 @@ eb64p_end_irq(unsigned int irq)
|
|||
}
|
||||
|
||||
static struct irq_chip eb64p_irq_type = {
|
||||
.typename = "EB64P",
|
||||
.name = "EB64P",
|
||||
.startup = eb64p_startup_irq,
|
||||
.shutdown = eb64p_disable_irq,
|
||||
.enable = eb64p_enable_irq,
|
||||
|
|
|
@ -81,7 +81,7 @@ eiger_end_irq(unsigned int irq)
|
|||
}
|
||||
|
||||
static struct irq_chip eiger_irq_type = {
|
||||
.typename = "EIGER",
|
||||
.name = "EIGER",
|
||||
.startup = eiger_startup_irq,
|
||||
.shutdown = eiger_disable_irq,
|
||||
.enable = eiger_enable_irq,
|
||||
|
|
|
@ -119,7 +119,7 @@ jensen_local_end(unsigned int irq)
|
|||
}
|
||||
|
||||
static struct irq_chip jensen_local_irq_type = {
|
||||
.typename = "LOCAL",
|
||||
.name = "LOCAL",
|
||||
.startup = jensen_local_startup,
|
||||
.shutdown = jensen_local_shutdown,
|
||||
.enable = jensen_local_enable,
|
||||
|
|
|
@ -170,7 +170,7 @@ marvel_irq_noop_return(unsigned int irq)
|
|||
}
|
||||
|
||||
static struct irq_chip marvel_legacy_irq_type = {
|
||||
.typename = "LEGACY",
|
||||
.name = "LEGACY",
|
||||
.startup = marvel_irq_noop_return,
|
||||
.shutdown = marvel_irq_noop,
|
||||
.enable = marvel_irq_noop,
|
||||
|
@ -180,7 +180,7 @@ static struct irq_chip marvel_legacy_irq_type = {
|
|||
};
|
||||
|
||||
static struct irq_chip io7_lsi_irq_type = {
|
||||
.typename = "LSI",
|
||||
.name = "LSI",
|
||||
.startup = io7_startup_irq,
|
||||
.shutdown = io7_disable_irq,
|
||||
.enable = io7_enable_irq,
|
||||
|
@ -190,7 +190,7 @@ static struct irq_chip io7_lsi_irq_type = {
|
|||
};
|
||||
|
||||
static struct irq_chip io7_msi_irq_type = {
|
||||
.typename = "MSI",
|
||||
.name = "MSI",
|
||||
.startup = io7_startup_irq,
|
||||
.shutdown = io7_disable_irq,
|
||||
.enable = io7_enable_irq,
|
||||
|
|
|
@ -69,7 +69,7 @@ mikasa_end_irq(unsigned int irq)
|
|||
}
|
||||
|
||||
static struct irq_chip mikasa_irq_type = {
|
||||
.typename = "MIKASA",
|
||||
.name = "MIKASA",
|
||||
.startup = mikasa_startup_irq,
|
||||
.shutdown = mikasa_disable_irq,
|
||||
.enable = mikasa_enable_irq,
|
||||
|
|
|
@ -74,7 +74,7 @@ noritake_end_irq(unsigned int irq)
|
|||
}
|
||||
|
||||
static struct irq_chip noritake_irq_type = {
|
||||
.typename = "NORITAKE",
|
||||
.name = "NORITAKE",
|
||||
.startup = noritake_startup_irq,
|
||||
.shutdown = noritake_disable_irq,
|
||||
.enable = noritake_enable_irq,
|
||||
|
|
|
@ -136,7 +136,7 @@ rawhide_end_irq(unsigned int irq)
|
|||
}
|
||||
|
||||
static struct irq_chip rawhide_irq_type = {
|
||||
.typename = "RAWHIDE",
|
||||
.name = "RAWHIDE",
|
||||
.startup = rawhide_startup_irq,
|
||||
.shutdown = rawhide_disable_irq,
|
||||
.enable = rawhide_enable_irq,
|
||||
|
|
|
@ -66,7 +66,7 @@ ruffian_init_irq(void)
|
|||
common_init_isa_dma();
|
||||
}
|
||||
|
||||
#define RUFFIAN_LATCH ((PIT_TICK_RATE + HZ / 2) / HZ)
|
||||
#define RUFFIAN_LATCH DIV_ROUND_CLOSEST(PIT_TICK_RATE, HZ)
|
||||
|
||||
static void __init
|
||||
ruffian_init_rtc(void)
|
||||
|
|
|
@ -73,7 +73,7 @@ rx164_end_irq(unsigned int irq)
|
|||
}
|
||||
|
||||
static struct irq_chip rx164_irq_type = {
|
||||
.typename = "RX164",
|
||||
.name = "RX164",
|
||||
.startup = rx164_startup_irq,
|
||||
.shutdown = rx164_disable_irq,
|
||||
.enable = rx164_enable_irq,
|
||||
|
|
|
@ -502,7 +502,7 @@ sable_lynx_mask_and_ack_irq(unsigned int irq)
|
|||
}
|
||||
|
||||
static struct irq_chip sable_lynx_irq_type = {
|
||||
.typename = "SABLE/LYNX",
|
||||
.name = "SABLE/LYNX",
|
||||
.startup = sable_lynx_startup_irq,
|
||||
.shutdown = sable_lynx_disable_irq,
|
||||
.enable = sable_lynx_enable_irq,
|
||||
|
|
|
@ -75,7 +75,7 @@ takara_end_irq(unsigned int irq)
|
|||
}
|
||||
|
||||
static struct irq_chip takara_irq_type = {
|
||||
.typename = "TAKARA",
|
||||
.name = "TAKARA",
|
||||
.startup = takara_startup_irq,
|
||||
.shutdown = takara_disable_irq,
|
||||
.enable = takara_enable_irq,
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue