Merge branch 'merge' of git://git.secretlab.ca/git/linux-2.6 into merge
This commit is contained in:
@@ -1,4 +1,4 @@
|
||||
What: /debug/pktcdvd/pktcdvd[0-7]
|
||||
What: /sys/kernel/debug/pktcdvd/pktcdvd[0-7]
|
||||
Date: Oct. 2006
|
||||
KernelVersion: 2.6.20
|
||||
Contact: Thomas Maier <balagi@justmail.de>
|
||||
@@ -10,10 +10,10 @@ debugfs interface
|
||||
The pktcdvd module (packet writing driver) creates
|
||||
these files in debugfs:
|
||||
|
||||
/debug/pktcdvd/pktcdvd[0-7]/
|
||||
/sys/kernel/debug/pktcdvd/pktcdvd[0-7]/
|
||||
info (0444) Lots of driver statistics and infos.
|
||||
|
||||
Example:
|
||||
-------
|
||||
|
||||
cat /debug/pktcdvd/pktcdvd0/info
|
||||
cat /sys/kernel/debug/pktcdvd/pktcdvd0/info
|
||||
|
@@ -136,7 +136,7 @@ exactly why.
|
||||
The standard 32-bit addressing PCI device would do something like
|
||||
this:
|
||||
|
||||
if (pci_set_dma_mask(pdev, DMA_32BIT_MASK)) {
|
||||
if (pci_set_dma_mask(pdev, DMA_BIT_MASK(32))) {
|
||||
printk(KERN_WARNING
|
||||
"mydev: No suitable DMA available.\n");
|
||||
goto ignore_this_device;
|
||||
@@ -155,9 +155,9 @@ all 64-bits when accessing streaming DMA:
|
||||
|
||||
int using_dac;
|
||||
|
||||
if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) {
|
||||
if (!pci_set_dma_mask(pdev, DMA_BIT_MASK(64))) {
|
||||
using_dac = 1;
|
||||
} else if (!pci_set_dma_mask(pdev, DMA_32BIT_MASK)) {
|
||||
} else if (!pci_set_dma_mask(pdev, DMA_BIT_MASK(32))) {
|
||||
using_dac = 0;
|
||||
} else {
|
||||
printk(KERN_WARNING
|
||||
@@ -170,14 +170,14 @@ the case would look like this:
|
||||
|
||||
int using_dac, consistent_using_dac;
|
||||
|
||||
if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) {
|
||||
if (!pci_set_dma_mask(pdev, DMA_BIT_MASK(64))) {
|
||||
using_dac = 1;
|
||||
consistent_using_dac = 1;
|
||||
pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
|
||||
} else if (!pci_set_dma_mask(pdev, DMA_32BIT_MASK)) {
|
||||
pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64));
|
||||
} else if (!pci_set_dma_mask(pdev, DMA_BIT_MASK(32))) {
|
||||
using_dac = 0;
|
||||
consistent_using_dac = 0;
|
||||
pci_set_consistent_dma_mask(pdev, DMA_32BIT_MASK);
|
||||
pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(32));
|
||||
} else {
|
||||
printk(KERN_WARNING
|
||||
"mydev: No suitable DMA available.\n");
|
||||
@@ -192,7 +192,7 @@ check the return value from pci_set_consistent_dma_mask().
|
||||
Finally, if your device can only drive the low 24-bits of
|
||||
address during PCI bus mastering you might do something like:
|
||||
|
||||
if (pci_set_dma_mask(pdev, DMA_24BIT_MASK)) {
|
||||
if (pci_set_dma_mask(pdev, DMA_BIT_MASK(24))) {
|
||||
printk(KERN_WARNING
|
||||
"mydev: 24-bit DMA addressing not available.\n");
|
||||
goto ignore_this_device;
|
||||
@@ -213,7 +213,7 @@ most specific mask.
|
||||
|
||||
Here is pseudo-code showing how this might be done:
|
||||
|
||||
#define PLAYBACK_ADDRESS_BITS DMA_32BIT_MASK
|
||||
#define PLAYBACK_ADDRESS_BITS DMA_BIT_MASK(32)
|
||||
#define RECORD_ADDRESS_BITS 0x00ffffff
|
||||
|
||||
struct my_sound_card *card;
|
||||
|
@@ -31,7 +31,7 @@ PS_METHOD = $(prefer-db2x)
|
||||
|
||||
###
|
||||
# The targets that may be used.
|
||||
PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs
|
||||
PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs
|
||||
|
||||
BOOKS := $(addprefix $(obj)/,$(DOCBOOKS))
|
||||
xmldocs: $(BOOKS)
|
||||
@@ -213,11 +213,12 @@ silent_gen_xml = :
|
||||
dochelp:
|
||||
@echo ' Linux kernel internal documentation in different formats:'
|
||||
@echo ' htmldocs - HTML'
|
||||
@echo ' installmandocs - install man pages generated by mandocs'
|
||||
@echo ' mandocs - man pages'
|
||||
@echo ' pdfdocs - PDF'
|
||||
@echo ' psdocs - Postscript'
|
||||
@echo ' xmldocs - XML DocBook'
|
||||
@echo ' mandocs - man pages'
|
||||
@echo ' installmandocs - install man pages generated by mandocs'
|
||||
@echo ' cleandocs - clean all generated DocBook files'
|
||||
|
||||
###
|
||||
# Temporary files left by various tools
|
||||
@@ -235,6 +236,10 @@ clean-files := $(DOCBOOKS) \
|
||||
|
||||
clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man
|
||||
|
||||
cleandocs:
|
||||
$(Q)rm -f $(call objectify, $(clean-files))
|
||||
$(Q)rm -rf $(call objectify, $(clean-dirs))
|
||||
|
||||
# Declare the contents of the .PHONY variable as phony. We keep that
|
||||
# information in a variable se we can use it in if_changed and friends.
|
||||
|
||||
|
@@ -259,7 +259,7 @@ X!Earch/x86/kernel/mca_32.c
|
||||
!Eblock/blk-tag.c
|
||||
!Iblock/blk-tag.c
|
||||
!Eblock/blk-integrity.c
|
||||
!Iblock/blktrace.c
|
||||
!Ikernel/trace/blktrace.c
|
||||
!Iblock/genhd.c
|
||||
!Eblock/genhd.c
|
||||
</chapter>
|
||||
|
@@ -1137,8 +1137,8 @@
|
||||
if (err < 0)
|
||||
return err;
|
||||
/* check PCI availability (28bit DMA) */
|
||||
if (pci_set_dma_mask(pci, DMA_28BIT_MASK) < 0 ||
|
||||
pci_set_consistent_dma_mask(pci, DMA_28BIT_MASK) < 0) {
|
||||
if (pci_set_dma_mask(pci, DMA_BIT_MASK(28)) < 0 ||
|
||||
pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(28)) < 0) {
|
||||
printk(KERN_ERR "error to set 28bit mask DMA\n");
|
||||
pci_disable_device(pci);
|
||||
return -ENXIO;
|
||||
@@ -1252,8 +1252,8 @@
|
||||
err = pci_enable_device(pci);
|
||||
if (err < 0)
|
||||
return err;
|
||||
if (pci_set_dma_mask(pci, DMA_28BIT_MASK) < 0 ||
|
||||
pci_set_consistent_dma_mask(pci, DMA_28BIT_MASK) < 0) {
|
||||
if (pci_set_dma_mask(pci, DMA_BIT_MASK(28)) < 0 ||
|
||||
pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(28)) < 0) {
|
||||
printk(KERN_ERR "error to set 28bit mask DMA\n");
|
||||
pci_disable_device(pci);
|
||||
return -ENXIO;
|
||||
|
@@ -8,6 +8,8 @@ cpqarray.txt
|
||||
- info on using Compaq's SMART2 Intelligent Disk Array Controllers.
|
||||
floppy.txt
|
||||
- notes and driver options for the floppy disk driver.
|
||||
mflash.txt
|
||||
- info on mGine m(g)flash driver for linux.
|
||||
nbd.txt
|
||||
- info on a TCP implementation of a network block device.
|
||||
paride.txt
|
||||
|
84
Documentation/blockdev/mflash.txt
Normal file
84
Documentation/blockdev/mflash.txt
Normal file
@@ -0,0 +1,84 @@
|
||||
This document describes m[g]flash support in linux.
|
||||
|
||||
Contents
|
||||
1. Overview
|
||||
2. Reserved area configuration
|
||||
3. Example of mflash platform driver registration
|
||||
|
||||
1. Overview
|
||||
|
||||
Mflash and gflash are embedded flash drive. The only difference is mflash is
|
||||
MCP(Multi Chip Package) device. These two device operate exactly same way.
|
||||
So the rest mflash repersents mflash and gflash altogether.
|
||||
|
||||
Internally, mflash has nand flash and other hardware logics and supports
|
||||
2 different operation (ATA, IO) modes. ATA mode doesn't need any new
|
||||
driver and currently works well under standard IDE subsystem. Actually it's
|
||||
one chip SSD. IO mode is ATA-like custom mode for the host that doesn't have
|
||||
IDE interface.
|
||||
|
||||
Followings are brief descriptions about IO mode.
|
||||
A. IO mode based on ATA protocol and uses some custom command. (read confirm,
|
||||
write confirm)
|
||||
B. IO mode uses SRAM bus interface.
|
||||
C. IO mode supports 4kB boot area, so host can boot from mflash.
|
||||
|
||||
2. Reserved area configuration
|
||||
If host boot from mflash, usually needs raw area for boot loader image. All of
|
||||
the mflash's block device operation will be taken this value as start offset.
|
||||
Note that boot loader's size of reserved area and kernel configuration value
|
||||
must be same.
|
||||
|
||||
3. Example of mflash platform driver registration
|
||||
Working mflash is very straight forward. Adding platform device stuff to board
|
||||
configuration file is all. Here is some pseudo example.
|
||||
|
||||
static struct mg_drv_data mflash_drv_data = {
|
||||
/* If you want to polling driver set to 1 */
|
||||
.use_polling = 0,
|
||||
/* device attribution */
|
||||
.dev_attr = MG_BOOT_DEV
|
||||
};
|
||||
|
||||
static struct resource mg_mflash_rsc[] = {
|
||||
/* Base address of mflash */
|
||||
[0] = {
|
||||
.start = 0x08000000,
|
||||
.end = 0x08000000 + SZ_64K - 1,
|
||||
.flags = IORESOURCE_MEM
|
||||
},
|
||||
/* mflash interrupt pin */
|
||||
[1] = {
|
||||
.start = IRQ_GPIO(84),
|
||||
.end = IRQ_GPIO(84),
|
||||
.flags = IORESOURCE_IRQ
|
||||
},
|
||||
/* mflash reset pin */
|
||||
[2] = {
|
||||
.start = 43,
|
||||
.end = 43,
|
||||
.name = MG_RST_PIN,
|
||||
.flags = IORESOURCE_IO
|
||||
},
|
||||
/* mflash reset-out pin
|
||||
* If you use mflash as storage device (i.e. other than MG_BOOT_DEV),
|
||||
* should assign this */
|
||||
[3] = {
|
||||
.start = 51,
|
||||
.end = 51,
|
||||
.name = MG_RSTOUT_PIN,
|
||||
.flags = IORESOURCE_IO
|
||||
}
|
||||
};
|
||||
|
||||
static struct platform_device mflash_dev = {
|
||||
.name = MG_DEV_NAME,
|
||||
.id = -1,
|
||||
.dev = {
|
||||
.platform_data = &mflash_drv_data,
|
||||
},
|
||||
.num_resources = ARRAY_SIZE(mg_mflash_rsc),
|
||||
.resource = mg_mflash_rsc
|
||||
};
|
||||
|
||||
platform_device_register(&mflash_dev);
|
@@ -30,3 +30,21 @@ The above steps create a new group g1 and move the current shell
|
||||
process (bash) into it. CPU time consumed by this bash and its children
|
||||
can be obtained from g1/cpuacct.usage and the same is accumulated in
|
||||
/cgroups/cpuacct.usage also.
|
||||
|
||||
cpuacct.stat file lists a few statistics which further divide the
|
||||
CPU time obtained by the cgroup into user and system times. Currently
|
||||
the following statistics are supported:
|
||||
|
||||
user: Time spent by tasks of the cgroup in user mode.
|
||||
system: Time spent by tasks of the cgroup in kernel mode.
|
||||
|
||||
user and system are in USER_HZ unit.
|
||||
|
||||
cpuacct controller uses percpu_counter interface to collect user and
|
||||
system times. This has two side effects:
|
||||
|
||||
- It is theoretically possible to see wrong values for user and system times.
|
||||
This is because percpu_counter_read() on 32bit systems isn't safe
|
||||
against concurrent writes.
|
||||
- It is possible to see slightly outdated values for user and system times
|
||||
due to the batch processing nature of percpu_counter.
|
||||
|
@@ -6,15 +6,14 @@ used here with the memory controller that is used in hardware.
|
||||
|
||||
Salient features
|
||||
|
||||
a. Enable control of both RSS (mapped) and Page Cache (unmapped) pages
|
||||
a. Enable control of Anonymous, Page Cache (mapped and unmapped) and
|
||||
Swap Cache memory pages.
|
||||
b. The infrastructure allows easy addition of other types of memory to control
|
||||
c. Provides *zero overhead* for non memory controller users
|
||||
d. Provides a double LRU: global memory pressure causes reclaim from the
|
||||
global LRU; a cgroup on hitting a limit, reclaims from the per
|
||||
cgroup LRU
|
||||
|
||||
NOTE: Swap Cache (unmapped) is not accounted now.
|
||||
|
||||
Benefits and Purpose of the memory controller
|
||||
|
||||
The memory controller isolates the memory behaviour of a group of tasks
|
||||
@@ -290,34 +289,44 @@ will be charged as a new owner of it.
|
||||
moved to the parent. If you want to avoid that, force_empty will be useful.
|
||||
|
||||
5.2 stat file
|
||||
memory.stat file includes following statistics (now)
|
||||
cache - # of pages from page-cache and shmem.
|
||||
rss - # of pages from anonymous memory.
|
||||
pgpgin - # of event of charging
|
||||
pgpgout - # of event of uncharging
|
||||
active_anon - # of pages on active lru of anon, shmem.
|
||||
inactive_anon - # of pages on active lru of anon, shmem
|
||||
active_file - # of pages on active lru of file-cache
|
||||
inactive_file - # of pages on inactive lru of file cache
|
||||
unevictable - # of pages cannot be reclaimed.(mlocked etc)
|
||||
|
||||
Below is depend on CONFIG_DEBUG_VM.
|
||||
inactive_ratio - VM internal parameter. (see mm/page_alloc.c)
|
||||
recent_rotated_anon - VM internal parameter. (see mm/vmscan.c)
|
||||
recent_rotated_file - VM internal parameter. (see mm/vmscan.c)
|
||||
recent_scanned_anon - VM internal parameter. (see mm/vmscan.c)
|
||||
recent_scanned_file - VM internal parameter. (see mm/vmscan.c)
|
||||
memory.stat file includes following statistics
|
||||
|
||||
Memo:
|
||||
cache - # of bytes of page cache memory.
|
||||
rss - # of bytes of anonymous and swap cache memory.
|
||||
pgpgin - # of pages paged in (equivalent to # of charging events).
|
||||
pgpgout - # of pages paged out (equivalent to # of uncharging events).
|
||||
active_anon - # of bytes of anonymous and swap cache memory on active
|
||||
lru list.
|
||||
inactive_anon - # of bytes of anonymous memory and swap cache memory on
|
||||
inactive lru list.
|
||||
active_file - # of bytes of file-backed memory on active lru list.
|
||||
inactive_file - # of bytes of file-backed memory on inactive lru list.
|
||||
unevictable - # of bytes of memory that cannot be reclaimed (mlocked etc).
|
||||
|
||||
The following additional stats are dependent on CONFIG_DEBUG_VM.
|
||||
|
||||
inactive_ratio - VM internal parameter. (see mm/page_alloc.c)
|
||||
recent_rotated_anon - VM internal parameter. (see mm/vmscan.c)
|
||||
recent_rotated_file - VM internal parameter. (see mm/vmscan.c)
|
||||
recent_scanned_anon - VM internal parameter. (see mm/vmscan.c)
|
||||
recent_scanned_file - VM internal parameter. (see mm/vmscan.c)
|
||||
|
||||
Memo:
|
||||
recent_rotated means recent frequency of lru rotation.
|
||||
recent_scanned means recent # of scans to lru.
|
||||
showing for better debug please see the code for meanings.
|
||||
|
||||
Note:
|
||||
Only anonymous and swap cache memory is listed as part of 'rss' stat.
|
||||
This should not be confused with the true 'resident set size' or the
|
||||
amount of physical memory used by the cgroup. Per-cgroup rss
|
||||
accounting is not done yet.
|
||||
|
||||
5.3 swappiness
|
||||
Similar to /proc/sys/vm/swappiness, but affecting a hierarchy of groups only.
|
||||
|
||||
Following cgroup's swapiness can't be changed.
|
||||
Following cgroups' swapiness can't be changed.
|
||||
- root cgroup (uses /proc/sys/vm/swappiness).
|
||||
- a cgroup which uses hierarchy and it has child cgroup.
|
||||
- a cgroup which uses hierarchy and not the root of hierarchy.
|
||||
|
@@ -47,13 +47,18 @@ to work with it.
|
||||
|
||||
2. Basic accounting routines
|
||||
|
||||
a. void res_counter_init(struct res_counter *rc)
|
||||
a. void res_counter_init(struct res_counter *rc,
|
||||
struct res_counter *rc_parent)
|
||||
|
||||
Initializes the resource counter. As usual, should be the first
|
||||
routine called for a new counter.
|
||||
|
||||
b. int res_counter_charge[_locked]
|
||||
(struct res_counter *rc, unsigned long val)
|
||||
The struct res_counter *parent can be used to define a hierarchical
|
||||
child -> parent relationship directly in the res_counter structure,
|
||||
NULL can be used to define no relationship.
|
||||
|
||||
c. int res_counter_charge(struct res_counter *rc, unsigned long val,
|
||||
struct res_counter **limit_fail_at)
|
||||
|
||||
When a resource is about to be allocated it has to be accounted
|
||||
with the appropriate resource counter (controller should determine
|
||||
@@ -67,15 +72,25 @@ to work with it.
|
||||
* if the charging is performed first, then it should be uncharged
|
||||
on error path (if the one is called).
|
||||
|
||||
c. void res_counter_uncharge[_locked]
|
||||
If the charging fails and a hierarchical dependency exists, the
|
||||
limit_fail_at parameter is set to the particular res_counter element
|
||||
where the charging failed.
|
||||
|
||||
d. int res_counter_charge_locked
|
||||
(struct res_counter *rc, unsigned long val)
|
||||
|
||||
The same as res_counter_charge(), but it must not acquire/release the
|
||||
res_counter->lock internally (it must be called with res_counter->lock
|
||||
held).
|
||||
|
||||
e. void res_counter_uncharge[_locked]
|
||||
(struct res_counter *rc, unsigned long val)
|
||||
|
||||
When a resource is released (freed) it should be de-accounted
|
||||
from the resource counter it was accounted to. This is called
|
||||
"uncharging".
|
||||
|
||||
The _locked routines imply that the res_counter->lock is taken.
|
||||
|
||||
The _locked routines imply that the res_counter->lock is taken.
|
||||
|
||||
2.1 Other accounting routines
|
||||
|
||||
|
@@ -3,7 +3,7 @@
|
||||
|
||||
Maintained by Alan Cox <device@lanana.org>
|
||||
|
||||
Last revised: 29 November 2006
|
||||
Last revised: 6th April 2009
|
||||
|
||||
This list is the Linux Device List, the official registry of allocated
|
||||
device numbers and /dev directory nodes for the Linux operating
|
||||
@@ -2797,6 +2797,10 @@ Your cooperation is appreciated.
|
||||
206 = /dev/ttySC1 SC26xx serial port 1
|
||||
207 = /dev/ttySC2 SC26xx serial port 2
|
||||
208 = /dev/ttySC3 SC26xx serial port 3
|
||||
209 = /dev/ttyMAX0 MAX3100 serial port 0
|
||||
210 = /dev/ttyMAX1 MAX3100 serial port 1
|
||||
211 = /dev/ttyMAX2 MAX3100 serial port 2
|
||||
212 = /dev/ttyMAX3 MAX3100 serial port 3
|
||||
|
||||
205 char Low-density serial ports (alternate device)
|
||||
0 = /dev/culu0 Callout device for ttyLU0
|
||||
|
@@ -59,7 +59,8 @@ Accepted options:
|
||||
ypan Enable display panning using the VESA protected mode
|
||||
interface. The visible screen is just a window of the
|
||||
video memory, console scrolling is done by changing the
|
||||
start of the window. Available on x86 only.
|
||||
start of the window. This option is available on x86
|
||||
only and is the default option on that architecture.
|
||||
|
||||
ywrap Same as ypan, but assumes your gfx board can wrap-around
|
||||
the video memory (i.e. starts reading from top if it
|
||||
@@ -67,7 +68,7 @@ ywrap Same as ypan, but assumes your gfx board can wrap-around
|
||||
Available on x86 only.
|
||||
|
||||
redraw Scroll by redrawing the affected part of the screen, this
|
||||
is the safe (and slow) default.
|
||||
is the default on non-x86.
|
||||
|
||||
(If you're using uvesafb as a module, the above three options are
|
||||
used a parameter of the scroll option, e.g. scroll=ypan.)
|
||||
@@ -182,7 +183,7 @@ from the Video BIOS if you set pixclock to 0 in fb_var_screeninfo.
|
||||
|
||||
--
|
||||
Michal Januszewski <spock@gentoo.org>
|
||||
Last updated: 2007-06-16
|
||||
Last updated: 2009-03-30
|
||||
|
||||
Documentation of the uvesafb options is loosely based on vesafb.txt.
|
||||
|
||||
|
@@ -354,7 +354,8 @@ Who: Krzysztof Piotr Oledzki <ole@ans.pl>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: i2c_attach_client(), i2c_detach_client(), i2c_driver->detach_client()
|
||||
What: i2c_attach_client(), i2c_detach_client(), i2c_driver->detach_client(),
|
||||
i2c_adapter->client_register(), i2c_adapter->client_unregister
|
||||
When: 2.6.30
|
||||
Check: i2c_attach_client i2c_detach_client
|
||||
Why: Deprecated by the new (standard) device driver binding model. Use
|
||||
@@ -427,3 +428,12 @@ Why: In 2.6.27, the semantics of /sys/bus/pci/slots was redefined to
|
||||
After a reasonable transition period, we will remove the legacy
|
||||
fakephp interface.
|
||||
Who: Alex Chiang <achiang@hp.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: i2c-voodoo3 driver
|
||||
When: October 2009
|
||||
Why: Superseded by tdfxfb. I2C/DDC support used to live in a separate
|
||||
driver but this caused driver conflicts.
|
||||
Who: Jean Delvare <khali@linux-fr.org>
|
||||
Krzysztof Helt <krzysztof.h1@wp.pl>
|
||||
|
@@ -68,6 +68,8 @@ ncpfs.txt
|
||||
- info on Novell Netware(tm) filesystem using NCP protocol.
|
||||
nfsroot.txt
|
||||
- short guide on setting up a diskless box with NFS root filesystem.
|
||||
nilfs2.txt
|
||||
- info and mount options for the NILFS2 filesystem.
|
||||
ntfs.txt
|
||||
- info and mount options for the NTFS filesystem (Windows NT).
|
||||
ocfs2.txt
|
||||
|
159
Documentation/filesystems/knfsd-stats.txt
Normal file
159
Documentation/filesystems/knfsd-stats.txt
Normal file
@@ -0,0 +1,159 @@
|
||||
|
||||
Kernel NFS Server Statistics
|
||||
============================
|
||||
|
||||
This document describes the format and semantics of the statistics
|
||||
which the kernel NFS server makes available to userspace. These
|
||||
statistics are available in several text form pseudo files, each of
|
||||
which is described separately below.
|
||||
|
||||
In most cases you don't need to know these formats, as the nfsstat(8)
|
||||
program from the nfs-utils distribution provides a helpful command-line
|
||||
interface for extracting and printing them.
|
||||
|
||||
All the files described here are formatted as a sequence of text lines,
|
||||
separated by newline '\n' characters. Lines beginning with a hash
|
||||
'#' character are comments intended for humans and should be ignored
|
||||
by parsing routines. All other lines contain a sequence of fields
|
||||
separated by whitespace.
|
||||
|
||||
/proc/fs/nfsd/pool_stats
|
||||
------------------------
|
||||
|
||||
This file is available in kernels from 2.6.30 onwards, if the
|
||||
/proc/fs/nfsd filesystem is mounted (it almost always should be).
|
||||
|
||||
The first line is a comment which describes the fields present in
|
||||
all the other lines. The other lines present the following data as
|
||||
a sequence of unsigned decimal numeric fields. One line is shown
|
||||
for each NFS thread pool.
|
||||
|
||||
All counters are 64 bits wide and wrap naturally. There is no way
|
||||
to zero these counters, instead applications should do their own
|
||||
rate conversion.
|
||||
|
||||
pool
|
||||
The id number of the NFS thread pool to which this line applies.
|
||||
This number does not change.
|
||||
|
||||
Thread pool ids are a contiguous set of small integers starting
|
||||
at zero. The maximum value depends on the thread pool mode, but
|
||||
currently cannot be larger than the number of CPUs in the system.
|
||||
Note that in the default case there will be a single thread pool
|
||||
which contains all the nfsd threads and all the CPUs in the system,
|
||||
and thus this file will have a single line with a pool id of "0".
|
||||
|
||||
packets-arrived
|
||||
Counts how many NFS packets have arrived. More precisely, this
|
||||
is the number of times that the network stack has notified the
|
||||
sunrpc server layer that new data may be available on a transport
|
||||
(e.g. an NFS or UDP socket or an NFS/RDMA endpoint).
|
||||
|
||||
Depending on the NFS workload patterns and various network stack
|
||||
effects (such as Large Receive Offload) which can combine packets
|
||||
on the wire, this may be either more or less than the number
|
||||
of NFS calls received (which statistic is available elsewhere).
|
||||
However this is a more accurate and less workload-dependent measure
|
||||
of how much CPU load is being placed on the sunrpc server layer
|
||||
due to NFS network traffic.
|
||||
|
||||
sockets-enqueued
|
||||
Counts how many times an NFS transport is enqueued to wait for
|
||||
an nfsd thread to service it, i.e. no nfsd thread was considered
|
||||
available.
|
||||
|
||||
The circumstance this statistic tracks indicates that there was NFS
|
||||
network-facing work to be done but it couldn't be done immediately,
|
||||
thus introducing a small delay in servicing NFS calls. The ideal
|
||||
rate of change for this counter is zero; significantly non-zero
|
||||
values may indicate a performance limitation.
|
||||
|
||||
This can happen either because there are too few nfsd threads in the
|
||||
thread pool for the NFS workload (the workload is thread-limited),
|
||||
or because the NFS workload needs more CPU time than is available in
|
||||
the thread pool (the workload is CPU-limited). In the former case,
|
||||
configuring more nfsd threads will probably improve the performance
|
||||
of the NFS workload. In the latter case, the sunrpc server layer is
|
||||
already choosing not to wake idle nfsd threads because there are too
|
||||
many nfsd threads which want to run but cannot, so configuring more
|
||||
nfsd threads will make no difference whatsoever. The overloads-avoided
|
||||
statistic (see below) can be used to distinguish these cases.
|
||||
|
||||
threads-woken
|
||||
Counts how many times an idle nfsd thread is woken to try to
|
||||
receive some data from an NFS transport.
|
||||
|
||||
This statistic tracks the circumstance where incoming
|
||||
network-facing NFS work is being handled quickly, which is a good
|
||||
thing. The ideal rate of change for this counter will be close
|
||||
to but less than the rate of change of the packets-arrived counter.
|
||||
|
||||
overloads-avoided
|
||||
Counts how many times the sunrpc server layer chose not to wake an
|
||||
nfsd thread, despite the presence of idle nfsd threads, because
|
||||
too many nfsd threads had been recently woken but could not get
|
||||
enough CPU time to actually run.
|
||||
|
||||
This statistic counts a circumstance where the sunrpc layer
|
||||
heuristically avoids overloading the CPU scheduler with too many
|
||||
runnable nfsd threads. The ideal rate of change for this counter
|
||||
is zero. Significant non-zero values indicate that the workload
|
||||
is CPU limited. Usually this is associated with heavy CPU usage
|
||||
on all the CPUs in the nfsd thread pool.
|
||||
|
||||
If a sustained large overloads-avoided rate is detected on a pool,
|
||||
the top(1) utility should be used to check for the following
|
||||
pattern of CPU usage on all the CPUs associated with the given
|
||||
nfsd thread pool.
|
||||
|
||||
- %us ~= 0 (as you're *NOT* running applications on your NFS server)
|
||||
|
||||
- %wa ~= 0
|
||||
|
||||
- %id ~= 0
|
||||
|
||||
- %sy + %hi + %si ~= 100
|
||||
|
||||
If this pattern is seen, configuring more nfsd threads will *not*
|
||||
improve the performance of the workload. If this patten is not
|
||||
seen, then something more subtle is wrong.
|
||||
|
||||
threads-timedout
|
||||
Counts how many times an nfsd thread triggered an idle timeout,
|
||||
i.e. was not woken to handle any incoming network packets for
|
||||
some time.
|
||||
|
||||
This statistic counts a circumstance where there are more nfsd
|
||||
threads configured than can be used by the NFS workload. This is
|
||||
a clue that the number of nfsd threads can be reduced without
|
||||
affecting performance. Unfortunately, it's only a clue and not
|
||||
a strong indication, for a couple of reasons:
|
||||
|
||||
- Currently the rate at which the counter is incremented is quite
|
||||
slow; the idle timeout is 60 minutes. Unless the NFS workload
|
||||
remains constant for hours at a time, this counter is unlikely
|
||||
to be providing information that is still useful.
|
||||
|
||||
- It is usually a wise policy to provide some slack,
|
||||
i.e. configure a few more nfsds than are currently needed,
|
||||
to allow for future spikes in load.
|
||||
|
||||
|
||||
Note that incoming packets on NFS transports will be dealt with in
|
||||
one of three ways. An nfsd thread can be woken (threads-woken counts
|
||||
this case), or the transport can be enqueued for later attention
|
||||
(sockets-enqueued counts this case), or the packet can be temporarily
|
||||
deferred because the transport is currently being used by an nfsd
|
||||
thread. This last case is not very interesting and is not explicitly
|
||||
counted, but can be inferred from the other counters thus:
|
||||
|
||||
packets-deferred = packets-arrived - ( sockets-enqueued + threads-woken )
|
||||
|
||||
|
||||
More
|
||||
----
|
||||
Descriptions of the other statistics file should go here.
|
||||
|
||||
|
||||
Greg Banks <gnb@sgi.com>
|
||||
26 Mar 2009
|
161
Documentation/filesystems/nfs41-server.txt
Normal file
161
Documentation/filesystems/nfs41-server.txt
Normal file
@@ -0,0 +1,161 @@
|
||||
NFSv4.1 Server Implementation
|
||||
|
||||
Server support for minorversion 1 can be controlled using the
|
||||
/proc/fs/nfsd/versions control file. The string output returned
|
||||
by reading this file will contain either "+4.1" or "-4.1"
|
||||
correspondingly.
|
||||
|
||||
Currently, server support for minorversion 1 is disabled by default.
|
||||
It can be enabled at run time by writing the string "+4.1" to
|
||||
the /proc/fs/nfsd/versions control file. Note that to write this
|
||||
control file, the nfsd service must be taken down. Use your user-mode
|
||||
nfs-utils to set this up; see rpc.nfsd(8)
|
||||
|
||||
The NFSv4 minorversion 1 (NFSv4.1) implementation in nfsd is based
|
||||
on the latest NFSv4.1 Internet Draft:
|
||||
http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion1-29
|
||||
|
||||
From the many new features in NFSv4.1 the current implementation
|
||||
focuses on the mandatory-to-implement NFSv4.1 Sessions, providing
|
||||
"exactly once" semantics and better control and throttling of the
|
||||
resources allocated for each client.
|
||||
|
||||
Other NFSv4.1 features, Parallel NFS operations in particular,
|
||||
are still under development out of tree.
|
||||
See http://wiki.linux-nfs.org/wiki/index.php/PNFS_prototype_design
|
||||
for more information.
|
||||
|
||||
The table below, taken from the NFSv4.1 document, lists
|
||||
the operations that are mandatory to implement (REQ), optional
|
||||
(OPT), and NFSv4.0 operations that are required not to implement (MNI)
|
||||
in minor version 1. The first column indicates the operations that
|
||||
are not supported yet by the linux server implementation.
|
||||
|
||||
The OPTIONAL features identified and their abbreviations are as follows:
|
||||
pNFS Parallel NFS
|
||||
FDELG File Delegations
|
||||
DDELG Directory Delegations
|
||||
|
||||
The following abbreviations indicate the linux server implementation status.
|
||||
I Implemented NFSv4.1 operations.
|
||||
NS Not Supported.
|
||||
NS* unimplemented optional feature.
|
||||
P pNFS features implemented out of tree.
|
||||
PNS pNFS features that are not supported yet (out of tree).
|
||||
|
||||
Operations
|
||||
|
||||
+----------------------+------------+--------------+----------------+
|
||||
| Operation | REQ, REC, | Feature | Definition |
|
||||
| | OPT, or | (REQ, REC, | |
|
||||
| | MNI | or OPT) | |
|
||||
+----------------------+------------+--------------+----------------+
|
||||
| ACCESS | REQ | | Section 18.1 |
|
||||
NS | BACKCHANNEL_CTL | REQ | | Section 18.33 |
|
||||
NS | BIND_CONN_TO_SESSION | REQ | | Section 18.34 |
|
||||
| CLOSE | REQ | | Section 18.2 |
|
||||
| COMMIT | REQ | | Section 18.3 |
|
||||
| CREATE | REQ | | Section 18.4 |
|
||||
I | CREATE_SESSION | REQ | | Section 18.36 |
|
||||
NS*| DELEGPURGE | OPT | FDELG (REQ) | Section 18.5 |
|
||||
| DELEGRETURN | OPT | FDELG, | Section 18.6 |
|
||||
| | | DDELG, pNFS | |
|
||||
| | | (REQ) | |
|
||||
NS | DESTROY_CLIENTID | REQ | | Section 18.50 |
|
||||
I | DESTROY_SESSION | REQ | | Section 18.37 |
|
||||
I | EXCHANGE_ID | REQ | | Section 18.35 |
|
||||
NS | FREE_STATEID | REQ | | Section 18.38 |
|
||||
| GETATTR | REQ | | Section 18.7 |
|
||||
P | GETDEVICEINFO | OPT | pNFS (REQ) | Section 18.40 |
|
||||
P | GETDEVICELIST | OPT | pNFS (OPT) | Section 18.41 |
|
||||
| GETFH | REQ | | Section 18.8 |
|
||||
NS*| GET_DIR_DELEGATION | OPT | DDELG (REQ) | Section 18.39 |
|
||||
P | LAYOUTCOMMIT | OPT | pNFS (REQ) | Section 18.42 |
|
||||
P | LAYOUTGET | OPT | pNFS (REQ) | Section 18.43 |
|
||||
P | LAYOUTRETURN | OPT | pNFS (REQ) | Section 18.44 |
|
||||
| LINK | OPT | | Section 18.9 |
|
||||
| LOCK | REQ | | Section 18.10 |
|
||||
| LOCKT | REQ | | Section 18.11 |
|
||||
| LOCKU | REQ | | Section 18.12 |
|
||||
| LOOKUP | REQ | | Section 18.13 |
|
||||
| LOOKUPP | REQ | | Section 18.14 |
|
||||
| NVERIFY | REQ | | Section 18.15 |
|
||||
| OPEN | REQ | | Section 18.16 |
|
||||
NS*| OPENATTR | OPT | | Section 18.17 |
|
||||
| OPEN_CONFIRM | MNI | | N/A |
|
||||
| OPEN_DOWNGRADE | REQ | | Section 18.18 |
|
||||
| PUTFH | REQ | | Section 18.19 |
|
||||
| PUTPUBFH | REQ | | Section 18.20 |
|
||||
| PUTROOTFH | REQ | | Section 18.21 |
|
||||
| READ | REQ | | Section 18.22 |
|
||||
| READDIR | REQ | | Section 18.23 |
|
||||
| READLINK | OPT | | Section 18.24 |
|
||||
NS | RECLAIM_COMPLETE | REQ | | Section 18.51 |
|
||||
| RELEASE_LOCKOWNER | MNI | | N/A |
|
||||
| REMOVE | REQ | | Section 18.25 |
|
||||
| RENAME | REQ | | Section 18.26 |
|
||||
| RENEW | MNI | | N/A |
|
||||
| RESTOREFH | REQ | | Section 18.27 |
|
||||
| SAVEFH | REQ | | Section 18.28 |
|
||||
| SECINFO | REQ | | Section 18.29 |
|
||||
NS | SECINFO_NO_NAME | REC | pNFS files | Section 18.45, |
|
||||
| | | layout (REQ) | Section 13.12 |
|
||||
I | SEQUENCE | REQ | | Section 18.46 |
|
||||
| SETATTR | REQ | | Section 18.30 |
|
||||
| SETCLIENTID | MNI | | N/A |
|
||||
| SETCLIENTID_CONFIRM | MNI | | N/A |
|
||||
NS | SET_SSV | REQ | | Section 18.47 |
|
||||
NS | TEST_STATEID | REQ | | Section 18.48 |
|
||||
| VERIFY | REQ | | Section 18.31 |
|
||||
NS*| WANT_DELEGATION | OPT | FDELG (OPT) | Section 18.49 |
|
||||
| WRITE | REQ | | Section 18.32 |
|
||||
|
||||
Callback Operations
|
||||
|
||||
+-------------------------+-----------+-------------+---------------+
|
||||
| Operation | REQ, REC, | Feature | Definition |
|
||||
| | OPT, or | (REQ, REC, | |
|
||||
| | MNI | or OPT) | |
|
||||
+-------------------------+-----------+-------------+---------------+
|
||||
| CB_GETATTR | OPT | FDELG (REQ) | Section 20.1 |
|
||||
P | CB_LAYOUTRECALL | OPT | pNFS (REQ) | Section 20.3 |
|
||||
NS*| CB_NOTIFY | OPT | DDELG (REQ) | Section 20.4 |
|
||||
P | CB_NOTIFY_DEVICEID | OPT | pNFS (OPT) | Section 20.12 |
|
||||
NS*| CB_NOTIFY_LOCK | OPT | | Section 20.11 |
|
||||
NS*| CB_PUSH_DELEG | OPT | FDELG (OPT) | Section 20.5 |
|
||||
| CB_RECALL | OPT | FDELG, | Section 20.2 |
|
||||
| | | DDELG, pNFS | |
|
||||
| | | (REQ) | |
|
||||
NS*| CB_RECALL_ANY | OPT | FDELG, | Section 20.6 |
|
||||
| | | DDELG, pNFS | |
|
||||
| | | (REQ) | |
|
||||
NS | CB_RECALL_SLOT | REQ | | Section 20.8 |
|
||||
NS*| CB_RECALLABLE_OBJ_AVAIL | OPT | DDELG, pNFS | Section 20.7 |
|
||||
| | | (REQ) | |
|
||||
I | CB_SEQUENCE | OPT | FDELG, | Section 20.9 |
|
||||
| | | DDELG, pNFS | |
|
||||
| | | (REQ) | |
|
||||
NS*| CB_WANTS_CANCELLED | OPT | FDELG, | Section 20.10 |
|
||||
| | | DDELG, pNFS | |
|
||||
| | | (REQ) | |
|
||||
+-------------------------+-----------+-------------+---------------+
|
||||
|
||||
Implementation notes:
|
||||
|
||||
EXCHANGE_ID:
|
||||
* only SP4_NONE state protection supported
|
||||
* implementation ids are ignored
|
||||
|
||||
CREATE_SESSION:
|
||||
* backchannel attributes are ignored
|
||||
* backchannel security parameters are ignored
|
||||
|
||||
SEQUENCE:
|
||||
* no support for dynamic slot table renegotiation (optional)
|
||||
|
||||
nfsv4.1 COMPOUND rules:
|
||||
The following cases aren't supported yet:
|
||||
* Enforcing of NFS4ERR_NOT_ONLY_OP for: BIND_CONN_TO_SESSION, CREATE_SESSION,
|
||||
DESTROY_CLIENTID, DESTROY_SESSION, EXCHANGE_ID.
|
||||
* DESTROY_SESSION MUST be the final operation in the COMPOUND request.
|
||||
|
200
Documentation/filesystems/nilfs2.txt
Normal file
200
Documentation/filesystems/nilfs2.txt
Normal file
@@ -0,0 +1,200 @@
|
||||
NILFS2
|
||||
------
|
||||
|
||||
NILFS2 is a log-structured file system (LFS) supporting continuous
|
||||
snapshotting. In addition to versioning capability of the entire file
|
||||
system, users can even restore files mistakenly overwritten or
|
||||
destroyed just a few seconds ago. Since NILFS2 can keep consistency
|
||||
like conventional LFS, it achieves quick recovery after system
|
||||
crashes.
|
||||
|
||||
NILFS2 creates a number of checkpoints every few seconds or per
|
||||
synchronous write basis (unless there is no change). Users can select
|
||||
significant versions among continuously created checkpoints, and can
|
||||
change them into snapshots which will be preserved until they are
|
||||
changed back to checkpoints.
|
||||
|
||||
There is no limit on the number of snapshots until the volume gets
|
||||
full. Each snapshot is mountable as a read-only file system
|
||||
concurrently with its writable mount, and this feature is convenient
|
||||
for online backup.
|
||||
|
||||
The userland tools are included in nilfs-utils package, which is
|
||||
available from the following download page. At least "mkfs.nilfs2",
|
||||
"mount.nilfs2", "umount.nilfs2", and "nilfs_cleanerd" (so called
|
||||
cleaner or garbage collector) are required. Details on the tools are
|
||||
described in the man pages included in the package.
|
||||
|
||||
Project web page: http://www.nilfs.org/en/
|
||||
Download page: http://www.nilfs.org/en/download.html
|
||||
Git tree web page: http://www.nilfs.org/git/
|
||||
NILFS mailing lists: http://www.nilfs.org/mailman/listinfo/users
|
||||
|
||||
Caveats
|
||||
=======
|
||||
|
||||
Features which NILFS2 does not support yet:
|
||||
|
||||
- atime
|
||||
- extended attributes
|
||||
- POSIX ACLs
|
||||
- quotas
|
||||
- writable snapshots
|
||||
- remote backup (CDP)
|
||||
- data integrity
|
||||
- defragmentation
|
||||
|
||||
Mount options
|
||||
=============
|
||||
|
||||
NILFS2 supports the following mount options:
|
||||
(*) == default
|
||||
|
||||
barrier=on(*) This enables/disables barriers. barrier=off disables
|
||||
it, barrier=on enables it.
|
||||
errors=continue(*) Keep going on a filesystem error.
|
||||
errors=remount-ro Remount the filesystem read-only on an error.
|
||||
errors=panic Panic and halt the machine if an error occurs.
|
||||
cp=n Specify the checkpoint-number of the snapshot to be
|
||||
mounted. Checkpoints and snapshots are listed by lscp
|
||||
user command. Only the checkpoints marked as snapshot
|
||||
are mountable with this option. Snapshot is read-only,
|
||||
so a read-only mount option must be specified together.
|
||||
order=relaxed(*) Apply relaxed order semantics that allows modified data
|
||||
blocks to be written to disk without making a
|
||||
checkpoint if no metadata update is going. This mode
|
||||
is equivalent to the ordered data mode of the ext3
|
||||
filesystem except for the updates on data blocks still
|
||||
conserve atomicity. This will improve synchronous
|
||||
write performance for overwriting.
|
||||
order=strict Apply strict in-order semantics that preserves sequence
|
||||
of all file operations including overwriting of data
|
||||
blocks. That means, it is guaranteed that no
|
||||
overtaking of events occurs in the recovered file
|
||||
system after a crash.
|
||||
|
||||
NILFS2 usage
|
||||
============
|
||||
|
||||
To use nilfs2 as a local file system, simply:
|
||||
|
||||
# mkfs -t nilfs2 /dev/block_device
|
||||
# mount -t nilfs2 /dev/block_device /dir
|
||||
|
||||
This will also invoke the cleaner through the mount helper program
|
||||
(mount.nilfs2).
|
||||
|
||||
Checkpoints and snapshots are managed by the following commands.
|
||||
Their manpages are included in the nilfs-utils package above.
|
||||
|
||||
lscp list checkpoints or snapshots.
|
||||
mkcp make a checkpoint or a snapshot.
|
||||
chcp change an existing checkpoint to a snapshot or vice versa.
|
||||
rmcp invalidate specified checkpoint(s).
|
||||
|
||||
To mount a snapshot,
|
||||
|
||||
# mount -t nilfs2 -r -o cp=<cno> /dev/block_device /snap_dir
|
||||
|
||||
where <cno> is the checkpoint number of the snapshot.
|
||||
|
||||
To unmount the NILFS2 mount point or snapshot, simply:
|
||||
|
||||
# umount /dir
|
||||
|
||||
Then, the cleaner daemon is automatically shut down by the umount
|
||||
helper program (umount.nilfs2).
|
||||
|
||||
Disk format
|
||||
===========
|
||||
|
||||
A nilfs2 volume is equally divided into a number of segments except
|
||||
for the super block (SB) and segment #0. A segment is the container
|
||||
of logs. Each log is composed of summary information blocks, payload
|
||||
blocks, and an optional super root block (SR):
|
||||
|
||||
______________________________________________________
|
||||
| |SB| | Segment | Segment | Segment | ... | Segment | |
|
||||
|_|__|_|____0____|____1____|____2____|_____|____N____|_|
|
||||
0 +1K +4K +8M +16M +24M +(8MB x N)
|
||||
. . (Typical offsets for 4KB-block)
|
||||
. .
|
||||
.______________________.
|
||||
| log | log |... | log |
|
||||
|__1__|__2__|____|__m__|
|
||||
. .
|
||||
. .
|
||||
. .
|
||||
.______________________________.
|
||||
| Summary | Payload blocks |SR|
|
||||
|_blocks__|_________________|__|
|
||||
|
||||
The payload blocks are organized per file, and each file consists of
|
||||
data blocks and B-tree node blocks:
|
||||
|
||||
|<--- File-A --->|<--- File-B --->|
|
||||
_______________________________________________________________
|
||||
| Data blocks | B-tree blocks | Data blocks | B-tree blocks | ...
|
||||
_|_____________|_______________|_____________|_______________|_
|
||||
|
||||
|
||||
Since only the modified blocks are written in the log, it may have
|
||||
files without data blocks or B-tree node blocks.
|
||||
|
||||
The organization of the blocks is recorded in the summary information
|
||||
blocks, which contains a header structure (nilfs_segment_summary), per
|
||||
file structures (nilfs_finfo), and per block structures (nilfs_binfo):
|
||||
|
||||
_________________________________________________________________________
|
||||
| Summary | finfo | binfo | ... | binfo | finfo | binfo | ... | binfo |...
|
||||
|_blocks__|___A___|_(A,1)_|_____|(A,Na)_|___B___|_(B,1)_|_____|(B,Nb)_|___
|
||||
|
||||
|
||||
The logs include regular files, directory files, symbolic link files
|
||||
and several meta data files. The mata data files are the files used
|
||||
to maintain file system meta data. The current version of NILFS2 uses
|
||||
the following meta data files:
|
||||
|
||||
1) Inode file (ifile) -- Stores on-disk inodes
|
||||
2) Checkpoint file (cpfile) -- Stores checkpoints
|
||||
3) Segment usage file (sufile) -- Stores allocation state of segments
|
||||
4) Data address translation file -- Maps virtual block numbers to usual
|
||||
(DAT) block numbers. This file serves to
|
||||
make on-disk blocks relocatable.
|
||||
|
||||
The following figure shows a typical organization of the logs:
|
||||
|
||||
_________________________________________________________________________
|
||||
| Summary | regular file | file | ... | ifile | cpfile | sufile | DAT |SR|
|
||||
|_blocks__|_or_directory_|_______|_____|_______|________|________|_____|__|
|
||||
|
||||
|
||||
To stride over segment boundaries, this sequence of files may be split
|
||||
into multiple logs. The sequence of logs that should be treated as
|
||||
logically one log, is delimited with flags marked in the segment
|
||||
summary. The recovery code of nilfs2 looks this boundary information
|
||||
to ensure atomicity of updates.
|
||||
|
||||
The super root block is inserted for every checkpoints. It includes
|
||||
three special inodes, inodes for the DAT, cpfile, and sufile. Inodes
|
||||
of regular files, directories, symlinks and other special files, are
|
||||
included in the ifile. The inode of ifile itself is included in the
|
||||
corresponding checkpoint entry in the cpfile. Thus, the hierarchy
|
||||
among NILFS2 files can be depicted as follows:
|
||||
|
||||
Super block (SB)
|
||||
|
|
||||
v
|
||||
Super root block (the latest cno=xx)
|
||||
|-- DAT
|
||||
|-- sufile
|
||||
`-- cpfile
|
||||
|-- ifile (cno=c1)
|
||||
|-- ifile (cno=c2) ---- file (ino=i1)
|
||||
: : |-- file (ino=i2)
|
||||
`-- ifile (cno=xx) |-- file (ino=i3)
|
||||
: :
|
||||
`-- file (ino=yy)
|
||||
( regular file, directory, or symlink )
|
||||
|
||||
For detail on the format of each file, please see include/linux/nilfs2_fs.h.
|
36
Documentation/hwmon/g760a
Normal file
36
Documentation/hwmon/g760a
Normal file
@@ -0,0 +1,36 @@
|
||||
Kernel driver g760a
|
||||
===================
|
||||
|
||||
Supported chips:
|
||||
* Global Mixed-mode Technology Inc. G760A
|
||||
Prefix: 'g760a'
|
||||
Datasheet: Publicly available at the GMT website
|
||||
http://www.gmt.com.tw/datasheet/g760a.pdf
|
||||
|
||||
Author: Herbert Valerio Riedel <hvr@gnu.org>
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
The GMT G760A Fan Speed PWM Controller is connected directly to a fan
|
||||
and performs closed-loop control of the fan speed.
|
||||
|
||||
The fan speed is programmed by setting the period via 'pwm1' of two
|
||||
consecutive speed pulses. The period is defined in terms of clock
|
||||
cycle counts of an assumed 32kHz clock source.
|
||||
|
||||
Setting a period of 0 stops the fan; setting the period to 255 sets
|
||||
fan to maximum speed.
|
||||
|
||||
The measured fan rotation speed returned via 'fan1_input' is derived
|
||||
from the measured speed pulse period by assuming again a 32kHz clock
|
||||
source and a 2 pulse-per-revolution fan.
|
||||
|
||||
The 'alarms' file provides access to the two alarm bits provided by
|
||||
the G760A chip's status register: Bit 0 is set when the actual fan
|
||||
speed differs more than 20% with respect to the programmed fan speed;
|
||||
bit 1 is set when fan speed is below 1920 RPM.
|
||||
|
||||
The g760a driver will not update its values more frequently than every
|
||||
other second; reading them more often will do no harm, but will return
|
||||
'old' values.
|
@@ -24,6 +24,49 @@ Partitions and P_Keys
|
||||
The P_Key for any interface is given by the "pkey" file, and the
|
||||
main interface for a subinterface is in "parent."
|
||||
|
||||
Datagram vs Connected modes
|
||||
|
||||
The IPoIB driver supports two modes of operation: datagram and
|
||||
connected. The mode is set and read through an interface's
|
||||
/sys/class/net/<intf name>/mode file.
|
||||
|
||||
In datagram mode, the IB UD (Unreliable Datagram) transport is used
|
||||
and so the interface MTU has is equal to the IB L2 MTU minus the
|
||||
IPoIB encapsulation header (4 bytes). For example, in a typical IB
|
||||
fabric with a 2K MTU, the IPoIB MTU will be 2048 - 4 = 2044 bytes.
|
||||
|
||||
In connected mode, the IB RC (Reliable Connected) transport is used.
|
||||
Connected mode is to takes advantage of the connected nature of the
|
||||
IB transport and allows an MTU up to the maximal IP packet size of
|
||||
64K, which reduces the number of IP packets needed for handling
|
||||
large UDP datagrams, TCP segments, etc and increases the performance
|
||||
for large messages.
|
||||
|
||||
In connected mode, the interface's UD QP is still used for multicast
|
||||
and communication with peers that don't support connected mode. In
|
||||
this case, RX emulation of ICMP PMTU packets is used to cause the
|
||||
networking stack to use the smaller UD MTU for these neighbours.
|
||||
|
||||
Stateless offloads
|
||||
|
||||
If the IB HW supports IPoIB stateless offloads, IPoIB advertises
|
||||
TCP/IP checksum and/or Large Send (LSO) offloading capability to the
|
||||
network stack.
|
||||
|
||||
Large Receive (LRO) offloading is also implemented and may be turned
|
||||
on/off using ethtool calls. Currently LRO is supported only for
|
||||
checksum offload capable devices.
|
||||
|
||||
Stateless offloads are supported only in datagram mode.
|
||||
|
||||
Interrupt moderation
|
||||
|
||||
If the underlying IB device supports CQ event moderation, one can
|
||||
use ethtool to set interrupt mitigation parameters and thus reduce
|
||||
the overhead incurred by handling interrupts. The main code path of
|
||||
IPoIB doesn't use events for TX completion signaling so only RX
|
||||
moderation is supported.
|
||||
|
||||
Debugging Information
|
||||
|
||||
By compiling the IPoIB driver with CONFIG_INFINIBAND_IPOIB_DEBUG set
|
||||
@@ -55,3 +98,5 @@ References
|
||||
http://ietf.org/rfc/rfc4391.txt
|
||||
IP over InfiniBand (IPoIB) Architecture (RFC 4392)
|
||||
http://ietf.org/rfc/rfc4392.txt
|
||||
IP over InfiniBand: Connected Mode (RFC 4755)
|
||||
http://ietf.org/rfc/rfc4755.txt
|
||||
|
101
Documentation/input/rotary-encoder.txt
Normal file
101
Documentation/input/rotary-encoder.txt
Normal file
@@ -0,0 +1,101 @@
|
||||
rotary-encoder - a generic driver for GPIO connected devices
|
||||
Daniel Mack <daniel@caiaq.de>, Feb 2009
|
||||
|
||||
0. Function
|
||||
-----------
|
||||
|
||||
Rotary encoders are devices which are connected to the CPU or other
|
||||
peripherals with two wires. The outputs are phase-shifted by 90 degrees
|
||||
and by triggering on falling and rising edges, the turn direction can
|
||||
be determined.
|
||||
|
||||
The phase diagram of these two outputs look like this:
|
||||
|
||||
_____ _____ _____
|
||||
| | | | | |
|
||||
Channel A ____| |_____| |_____| |____
|
||||
|
||||
: : : : : : : : : : : :
|
||||
__ _____ _____ _____
|
||||
| | | | | | |
|
||||
Channel B |_____| |_____| |_____| |__
|
||||
|
||||
: : : : : : : : : : : :
|
||||
Event a b c d a b c d a b c d
|
||||
|
||||
|<-------->|
|
||||
one step
|
||||
|
||||
|
||||
For more information, please see
|
||||
http://en.wikipedia.org/wiki/Rotary_encoder
|
||||
|
||||
|
||||
1. Events / state machine
|
||||
-------------------------
|
||||
|
||||
a) Rising edge on channel A, channel B in low state
|
||||
This state is used to recognize a clockwise turn
|
||||
|
||||
b) Rising edge on channel B, channel A in high state
|
||||
When entering this state, the encoder is put into 'armed' state,
|
||||
meaning that there it has seen half the way of a one-step transition.
|
||||
|
||||
c) Falling edge on channel A, channel B in high state
|
||||
This state is used to recognize a counter-clockwise turn
|
||||
|
||||
d) Falling edge on channel B, channel A in low state
|
||||
Parking position. If the encoder enters this state, a full transition
|
||||
should have happend, unless it flipped back on half the way. The
|
||||
'armed' state tells us about that.
|
||||
|
||||
2. Platform requirements
|
||||
------------------------
|
||||
|
||||
As there is no hardware dependent call in this driver, the platform it is
|
||||
used with must support gpiolib. Another requirement is that IRQs must be
|
||||
able to fire on both edges.
|
||||
|
||||
|
||||
3. Board integration
|
||||
--------------------
|
||||
|
||||
To use this driver in your system, register a platform_device with the
|
||||
name 'rotary-encoder' and associate the IRQs and some specific platform
|
||||
data with it.
|
||||
|
||||
struct rotary_encoder_platform_data is declared in
|
||||
include/linux/rotary-encoder.h and needs to be filled with the number of
|
||||
steps the encoder has and can carry information about externally inverted
|
||||
signals (because of used invertig buffer or other reasons).
|
||||
|
||||
Because GPIO to IRQ mapping is platform specific, this information must
|
||||
be given in seperately to the driver. See the example below.
|
||||
|
||||
---------<snip>---------
|
||||
|
||||
/* board support file example */
|
||||
|
||||
#include <linux/input.h>
|
||||
#include <linux/rotary_encoder.h>
|
||||
|
||||
#define GPIO_ROTARY_A 1
|
||||
#define GPIO_ROTARY_B 2
|
||||
|
||||
static struct rotary_encoder_platform_data my_rotary_encoder_info = {
|
||||
.steps = 24,
|
||||
.axis = ABS_X,
|
||||
.gpio_a = GPIO_ROTARY_A,
|
||||
.gpio_b = GPIO_ROTARY_B,
|
||||
.inverted_a = 0,
|
||||
.inverted_b = 0,
|
||||
};
|
||||
|
||||
static struct platform_device rotary_encoder_device = {
|
||||
.name = "rotary-encoder",
|
||||
.id = 0,
|
||||
.dev = {
|
||||
.platform_data = &my_rotary_encoder_info,
|
||||
}
|
||||
};
|
||||
|
@@ -61,24 +61,28 @@ GigaSet 307x Device Driver
|
||||
---------------------
|
||||
2.1. Modules
|
||||
-------
|
||||
To get the device working, you have to load the proper kernel module. You
|
||||
can do this using
|
||||
modprobe modulename
|
||||
where modulename is ser_gigaset (M101), usb_gigaset (M105), or
|
||||
bas_gigaset (direct USB connection to the base).
|
||||
For the devices to work, the proper kernel modules have to be loaded.
|
||||
This normally happens automatically when the system detects the USB
|
||||
device (base, M105) or when the line discipline is attached (M101). It
|
||||
can also be triggered manually using the modprobe(8) command, for example
|
||||
for troubleshooting or to pass module parameters.
|
||||
|
||||
The module ser_gigaset provides a serial line discipline N_GIGASET_M101
|
||||
which drives the device through the regular serial line driver. To use it,
|
||||
run the Gigaset M101 daemon "gigasetm101d" (also available from
|
||||
http://sourceforge.net/projects/gigaset307x/) with the device file of the
|
||||
RS232 port to the M101 as an argument, for example:
|
||||
gigasetm101d /dev/ttyS1
|
||||
This will open the device file, set its line discipline to N_GIGASET_M101,
|
||||
and then sleep in the background, keeping the device open so that the
|
||||
line discipline remains active. To deactivate it, kill the daemon, for
|
||||
example with
|
||||
killall gigasetm101d
|
||||
before disconnecting the device.
|
||||
which drives the device through the regular serial line driver. It must
|
||||
be attached to the serial line to which the M101 is connected with the
|
||||
ldattach(8) command (requires util-linux-ng release 2.14 or later), for
|
||||
example:
|
||||
ldattach GIGASET_M101 /dev/ttyS1
|
||||
This will open the device file, attach the line discipline to it, and
|
||||
then sleep in the background, keeping the device open so that the line
|
||||
discipline remains active. To deactivate it, kill the daemon, for example
|
||||
with
|
||||
killall ldattach
|
||||
before disconnecting the device. To have this happen automatically at
|
||||
system startup/shutdown on an LSB compatible system, create and activate
|
||||
an appropriate LSB startup script /etc/init.d/gigaset. (The init name
|
||||
'gigaset' is officially assigned to this project by LANANA.)
|
||||
Alternatively, just add the 'ldattach' command line to /etc/rc.local.
|
||||
|
||||
2.2. Device nodes for user space programs
|
||||
------------------------------------
|
||||
@@ -194,10 +198,11 @@ GigaSet 307x Device Driver
|
||||
operation (for wireless access to the base), but are needed for access
|
||||
to the M105's own configuration mode (registration to the base, baudrate
|
||||
and line format settings, device status queries) via the gigacontr
|
||||
utility. Their use is disabled in the driver by default for safety
|
||||
reasons but can be enabled by setting the kernel configuration option
|
||||
"Support for undocumented USB requests" (GIGASET_UNDOCREQ) to "Y" and
|
||||
recompiling.
|
||||
utility. Their use is controlled by the kernel configuration option
|
||||
"Support for undocumented USB requests" (CONFIG_GIGASET_UNDOCREQ). If you
|
||||
encounter error code -ENOTTY when trying to use some features of the
|
||||
M105, try setting that option to "y" via 'make {x,menu}config' and
|
||||
recompiling the driver.
|
||||
|
||||
|
||||
3. Troubleshooting
|
||||
@@ -228,6 +233,13 @@ GigaSet 307x Device Driver
|
||||
Solution:
|
||||
Select Unimodem mode for all DECT data adapters. (see section 2.4.)
|
||||
|
||||
Problem:
|
||||
You want to configure your USB DECT data adapter (M105) but gigacontr
|
||||
reports an error: "/dev/ttyGU0: Inappropriate ioctl for device".
|
||||
Solution:
|
||||
Recompile the usb_gigaset driver with the kernel configuration option
|
||||
CONFIG_GIGASET_UNDOCREQ set to 'y'. (see section 2.6.)
|
||||
|
||||
3.2. Telling the driver to provide more information
|
||||
----------------------------------------------
|
||||
Building the driver with the "Gigaset debugging" kernel configuration
|
||||
|
@@ -40,10 +40,16 @@ This document describes the Linux kernel Makefiles.
|
||||
--- 6.7 Custom kbuild commands
|
||||
--- 6.8 Preprocessing linker scripts
|
||||
|
||||
=== 7 Kbuild Variables
|
||||
=== 8 Makefile language
|
||||
=== 9 Credits
|
||||
=== 10 TODO
|
||||
=== 7 Kbuild syntax for exported headers
|
||||
--- 7.1 header-y
|
||||
--- 7.2 objhdr-y
|
||||
--- 7.3 destination-y
|
||||
--- 7.4 unifdef-y (deprecated)
|
||||
|
||||
=== 8 Kbuild Variables
|
||||
=== 9 Makefile language
|
||||
=== 10 Credits
|
||||
=== 11 TODO
|
||||
|
||||
=== 1 Overview
|
||||
|
||||
@@ -1143,8 +1149,69 @@ When kbuild executes, the following steps are followed (roughly):
|
||||
The kbuild infrastructure for *lds file are used in several
|
||||
architecture-specific files.
|
||||
|
||||
=== 7 Kbuild syntax for exported headers
|
||||
|
||||
=== 7 Kbuild Variables
|
||||
The kernel include a set of headers that is exported to userspace.
|
||||
Many headers can be exported as-is but other headers requires a
|
||||
minimal pre-processing before they are ready for user-space.
|
||||
The pre-processing does:
|
||||
- drop kernel specific annotations
|
||||
- drop include of compiler.h
|
||||
- drop all sections that is kernel internat (guarded by ifdef __KERNEL__)
|
||||
|
||||
Each relevant directory contain a file name "Kbuild" which specify the
|
||||
headers to be exported.
|
||||
See subsequent chapter for the syntax of the Kbuild file.
|
||||
|
||||
--- 7.1 header-y
|
||||
|
||||
header-y specify header files to be exported.
|
||||
|
||||
Example:
|
||||
#include/linux/Kbuild
|
||||
header-y += usb/
|
||||
header-y += aio_abi.h
|
||||
|
||||
The convention is to list one file per line and
|
||||
preferably in alphabetic order.
|
||||
|
||||
header-y also specify which subdirectories to visit.
|
||||
A subdirectory is identified by a trailing '/' which
|
||||
can be seen in the example above for the usb subdirectory.
|
||||
|
||||
Subdirectories are visited before their parent directories.
|
||||
|
||||
--- 7.2 objhdr-y
|
||||
|
||||
objhdr-y specifies generated files to be exported.
|
||||
Generated files are special as they need to be looked
|
||||
up in another directory when doing 'make O=...' builds.
|
||||
|
||||
Example:
|
||||
#include/linux/Kbuild
|
||||
objhdr-y += version.h
|
||||
|
||||
--- 7.3 destination-y
|
||||
|
||||
When an architecture have a set of exported headers that needs to be
|
||||
exported to a different directory destination-y is used.
|
||||
destination-y specify the destination directory for all exported
|
||||
headers in the file where it is present.
|
||||
|
||||
Example:
|
||||
#arch/xtensa/platforms/s6105/include/platform/Kbuild
|
||||
destination-y := include/linux
|
||||
|
||||
In the example above all exported headers in the Kbuild file
|
||||
will be located in the directory "include/linux" when exported.
|
||||
|
||||
|
||||
--- 7.4 unifdef-y (deprecated)
|
||||
|
||||
unifdef-y is deprecated. A direct replacement is header-y.
|
||||
|
||||
|
||||
=== 8 Kbuild Variables
|
||||
|
||||
The top Makefile exports the following variables:
|
||||
|
||||
@@ -1206,7 +1273,7 @@ The top Makefile exports the following variables:
|
||||
INSTALL_MOD_STRIP will used as the option(s) to the strip command.
|
||||
|
||||
|
||||
=== 8 Makefile language
|
||||
=== 9 Makefile language
|
||||
|
||||
The kernel Makefiles are designed to be run with GNU Make. The Makefiles
|
||||
use only the documented features of GNU Make, but they do use many
|
||||
@@ -1225,14 +1292,14 @@ time the left-hand side is used.
|
||||
There are some cases where "=" is appropriate. Usually, though, ":="
|
||||
is the right choice.
|
||||
|
||||
=== 9 Credits
|
||||
=== 10 Credits
|
||||
|
||||
Original version made by Michael Elizabeth Chastain, <mailto:mec@shout.net>
|
||||
Updates by Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de>
|
||||
Updates by Sam Ravnborg <sam@ravnborg.org>
|
||||
Language QA by Jan Engelhardt <jengelh@gmx.de>
|
||||
|
||||
=== 10 TODO
|
||||
=== 11 TODO
|
||||
|
||||
- Describe how kbuild supports shipped files with _shipped.
|
||||
- Generating offset header files.
|
||||
|
@@ -153,60 +153,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
1,0: use 1st APIC table
|
||||
default: 0
|
||||
|
||||
acpi_sleep= [HW,ACPI] Sleep options
|
||||
Format: { s3_bios, s3_mode, s3_beep, s4_nohwsig,
|
||||
old_ordering, s4_nonvs }
|
||||
See Documentation/power/video.txt for information on
|
||||
s3_bios and s3_mode.
|
||||
s3_beep is for debugging; it makes the PC's speaker beep
|
||||
as soon as the kernel's real-mode entry point is called.
|
||||
s4_nohwsig prevents ACPI hardware signature from being
|
||||
used during resume from hibernation.
|
||||
old_ordering causes the ACPI 1.0 ordering of the _PTS
|
||||
control method, with respect to putting devices into
|
||||
low power states, to be enforced (the ACPI 2.0 ordering
|
||||
of _PTS is used by default).
|
||||
s4_nonvs prevents the kernel from saving/restoring the
|
||||
ACPI NVS memory during hibernation.
|
||||
|
||||
acpi_sci= [HW,ACPI] ACPI System Control Interrupt trigger mode
|
||||
Format: { level | edge | high | low }
|
||||
|
||||
acpi_irq_balance [HW,ACPI]
|
||||
ACPI will balance active IRQs
|
||||
default in APIC mode
|
||||
|
||||
acpi_irq_nobalance [HW,ACPI]
|
||||
ACPI will not move active IRQs (default)
|
||||
default in PIC mode
|
||||
|
||||
acpi_irq_pci= [HW,ACPI] If irq_balance, clear listed IRQs for
|
||||
use by PCI
|
||||
Format: <irq>,<irq>...
|
||||
|
||||
acpi_irq_isa= [HW,ACPI] If irq_balance, mark listed IRQs used by ISA
|
||||
Format: <irq>,<irq>...
|
||||
|
||||
acpi_no_auto_ssdt [HW,ACPI] Disable automatic loading of SSDT
|
||||
|
||||
acpi_os_name= [HW,ACPI] Tell ACPI BIOS the name of the OS
|
||||
Format: To spoof as Windows 98: ="Microsoft Windows"
|
||||
|
||||
acpi_osi= [HW,ACPI] Modify list of supported OS interface strings
|
||||
acpi_osi="string1" # add string1 -- only one string
|
||||
acpi_osi="!string2" # remove built-in string2
|
||||
acpi_osi= # disable all strings
|
||||
|
||||
acpi_serialize [HW,ACPI] force serialization of AML methods
|
||||
|
||||
acpi_skip_timer_override [HW,ACPI]
|
||||
Recognize and ignore IRQ0/pin2 Interrupt Override.
|
||||
For broken nForce2 BIOS resulting in XT-PIC timer.
|
||||
acpi_use_timer_override [HW,ACPI]
|
||||
Use timer override. For some broken Nvidia NF5 boards
|
||||
that require a timer override, but don't have
|
||||
HPET
|
||||
|
||||
acpi_backlight= [HW,ACPI]
|
||||
acpi_backlight=vendor
|
||||
acpi_backlight=video
|
||||
@@ -214,11 +160,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
(e.g. thinkpad_acpi, sony_acpi, etc.) instead
|
||||
of the ACPI video.ko driver.
|
||||
|
||||
acpi_display_output= [HW,ACPI]
|
||||
acpi_display_output=vendor
|
||||
acpi_display_output=video
|
||||
See above.
|
||||
|
||||
acpi.debug_layer= [HW,ACPI,ACPI_DEBUG]
|
||||
acpi.debug_level= [HW,ACPI,ACPI_DEBUG]
|
||||
Format: <int>
|
||||
@@ -247,6 +188,41 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
unusable. The "log_buf_len" parameter may be useful
|
||||
if you need to capture more output.
|
||||
|
||||
acpi_display_output= [HW,ACPI]
|
||||
acpi_display_output=vendor
|
||||
acpi_display_output=video
|
||||
See above.
|
||||
|
||||
acpi_irq_balance [HW,ACPI]
|
||||
ACPI will balance active IRQs
|
||||
default in APIC mode
|
||||
|
||||
acpi_irq_nobalance [HW,ACPI]
|
||||
ACPI will not move active IRQs (default)
|
||||
default in PIC mode
|
||||
|
||||
acpi_irq_isa= [HW,ACPI] If irq_balance, mark listed IRQs used by ISA
|
||||
Format: <irq>,<irq>...
|
||||
|
||||
acpi_irq_pci= [HW,ACPI] If irq_balance, clear listed IRQs for
|
||||
use by PCI
|
||||
Format: <irq>,<irq>...
|
||||
|
||||
acpi_no_auto_ssdt [HW,ACPI] Disable automatic loading of SSDT
|
||||
|
||||
acpi_os_name= [HW,ACPI] Tell ACPI BIOS the name of the OS
|
||||
Format: To spoof as Windows 98: ="Microsoft Windows"
|
||||
|
||||
acpi_osi= [HW,ACPI] Modify list of supported OS interface strings
|
||||
acpi_osi="string1" # add string1 -- only one string
|
||||
acpi_osi="!string2" # remove built-in string2
|
||||
acpi_osi= # disable all strings
|
||||
|
||||
acpi_pm_good [X86-32,X86-64]
|
||||
Override the pmtimer bug detection: force the kernel
|
||||
to assume that this machine's pmtimer latches its value
|
||||
and always returns good values.
|
||||
|
||||
acpi.power_nocheck= [HW,ACPI]
|
||||
Format: 1/0 enable/disable the check of power state.
|
||||
On some bogus BIOS the _PSC object/_STA object of
|
||||
@@ -255,11 +231,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
power state again in power transition.
|
||||
1 : disable the power state check
|
||||
|
||||
acpi_pm_good [X86-32,X86-64]
|
||||
Override the pmtimer bug detection: force the kernel
|
||||
to assume that this machine's pmtimer latches its value
|
||||
and always returns good values.
|
||||
|
||||
acpi_enforce_resources= [ACPI]
|
||||
{ strict | lax | no }
|
||||
Check for resource conflicts between native drivers
|
||||
@@ -276,22 +247,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
no: ACPI OperationRegions are not marked as reserved,
|
||||
no further checks are performed.
|
||||
|
||||
agp= [AGP]
|
||||
{ off | try_unsupported }
|
||||
off: disable AGP support
|
||||
try_unsupported: try to drive unsupported chipsets
|
||||
(may crash computer or cause data corruption)
|
||||
|
||||
enable_timer_pin_1 [i386,x86-64]
|
||||
Enable PIN 1 of APIC timer
|
||||
Can be useful to work around chipset bugs
|
||||
(in particular on some ATI chipsets).
|
||||
The kernel tries to set a reasonable default.
|
||||
|
||||
disable_timer_pin_1 [i386,x86-64]
|
||||
Disable PIN 1 of APIC timer
|
||||
Can be useful to work around chipset bugs.
|
||||
|
||||
ad1848= [HW,OSS]
|
||||
Format: <io>,<irq>,<dma>,<dma2>,<type>
|
||||
|
||||
@@ -305,6 +260,12 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
Format: <io>,<irq>,<dma>,<mss_io>,<mpu_io>,<mpu_irq>
|
||||
See also header of sound/oss/aedsp16.c.
|
||||
|
||||
agp= [AGP]
|
||||
{ off | try_unsupported }
|
||||
off: disable AGP support
|
||||
try_unsupported: try to drive unsupported chipsets
|
||||
(may crash computer or cause data corruption)
|
||||
|
||||
aha152x= [HW,SCSI]
|
||||
See Documentation/scsi/aha152x.txt.
|
||||
|
||||
@@ -432,12 +393,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
possible to determine what the correct size should be.
|
||||
This option provides an override for these situations.
|
||||
|
||||
security= [SECURITY] Choose a security module to enable at boot.
|
||||
If this boot parameter is not specified, only the first
|
||||
security module asking for security registration will be
|
||||
loaded. An invalid security module name will be treated
|
||||
as if no module has been chosen.
|
||||
|
||||
capability.disable=
|
||||
[SECURITY] Disable capabilities. This would normally
|
||||
be used only if an alternative security model is to be
|
||||
@@ -509,24 +464,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
Range: 0 - 8192
|
||||
Default: 64
|
||||
|
||||
dma_debug=off If the kernel is compiled with DMA_API_DEBUG support
|
||||
this option disables the debugging code at boot.
|
||||
|
||||
dma_debug_entries=<number>
|
||||
This option allows to tune the number of preallocated
|
||||
entries for DMA-API debugging code. One entry is
|
||||
required per DMA-API allocation. Use this if the
|
||||
DMA-API debugging code disables itself because the
|
||||
architectural default is too low.
|
||||
|
||||
hpet= [X86-32,HPET] option to control HPET usage
|
||||
Format: { enable (default) | disable | force |
|
||||
verbose }
|
||||
disable: disable HPET and use PIT instead
|
||||
force: allow force enabled of undocumented chips (ICH4,
|
||||
VIA, nVidia)
|
||||
verbose: show contents of HPET registers during setup
|
||||
|
||||
com20020= [HW,NET] ARCnet - COM20020 chipset
|
||||
Format:
|
||||
<io>[,<irq>[,<nodeID>[,<backplane>[,<ckp>[,<timeout>]]]]]
|
||||
@@ -570,23 +507,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
console=brl,ttyS0
|
||||
For now, only VisioBraille is supported.
|
||||
|
||||
earlycon= [KNL] Output early console device and options.
|
||||
uart[8250],io,<addr>[,options]
|
||||
uart[8250],mmio,<addr>[,options]
|
||||
Start an early, polled-mode console on the 8250/16550
|
||||
UART at the specified I/O port or MMIO address.
|
||||
The options are the same as for ttyS, above.
|
||||
|
||||
no_console_suspend
|
||||
[HW] Never suspend the console
|
||||
Disable suspending of consoles during suspend and
|
||||
hibernate operations. Once disabled, debugging
|
||||
messages can reach various consoles while the rest
|
||||
of the system is being put to sleep (ie, while
|
||||
debugging driver suspend/resume hooks). This may
|
||||
not work reliably with all consoles, but is known
|
||||
to work with serial and VGA consoles.
|
||||
|
||||
coredump_filter=
|
||||
[KNL] Change the default value for
|
||||
/proc/<pid>/coredump_filter.
|
||||
@@ -643,30 +563,13 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
Format: <area>[,<node>]
|
||||
See also Documentation/networking/decnet.txt.
|
||||
|
||||
vt.default_blu= [VT]
|
||||
Format: <blue0>,<blue1>,<blue2>,...,<blue15>
|
||||
Change the default blue palette of the console.
|
||||
This is a 16-member array composed of values
|
||||
ranging from 0-255.
|
||||
|
||||
vt.default_grn= [VT]
|
||||
Format: <green0>,<green1>,<green2>,...,<green15>
|
||||
Change the default green palette of the console.
|
||||
This is a 16-member array composed of values
|
||||
ranging from 0-255.
|
||||
|
||||
vt.default_red= [VT]
|
||||
Format: <red0>,<red1>,<red2>,...,<red15>
|
||||
Change the default red palette of the console.
|
||||
This is a 16-member array composed of values
|
||||
ranging from 0-255.
|
||||
|
||||
vt.default_utf8=
|
||||
[VT]
|
||||
Format=<0|1>
|
||||
Set system-wide default UTF-8 mode for all tty's.
|
||||
Default is 1, i.e. UTF-8 mode is enabled for all
|
||||
newly opened terminals.
|
||||
default_hugepagesz=
|
||||
[same as hugepagesz=] The size of the default
|
||||
HugeTLB page size. This is the size represented by
|
||||
the legacy /proc/ hugepages APIs, used for SHM, and
|
||||
default size when mounting hugetlbfs filesystems.
|
||||
Defaults to the default architecture's huge page size
|
||||
if not specified.
|
||||
|
||||
dhash_entries= [KNL]
|
||||
Set number of hash buckets for dentry cache.
|
||||
@@ -679,27 +582,9 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
Documentation/serial/digiepca.txt.
|
||||
|
||||
disable_mtrr_cleanup [X86]
|
||||
enable_mtrr_cleanup [X86]
|
||||
The kernel tries to adjust MTRR layout from continuous
|
||||
to discrete, to make X server driver able to add WB
|
||||
entry later. This parameter enables/disables that.
|
||||
|
||||
mtrr_chunk_size=nn[KMG] [X86]
|
||||
used for mtrr cleanup. It is largest continous chunk
|
||||
that could hold holes aka. UC entries.
|
||||
|
||||
mtrr_gran_size=nn[KMG] [X86]
|
||||
Used for mtrr cleanup. It is granularity of mtrr block.
|
||||
Default is 1.
|
||||
Large value could prevent small alignment from
|
||||
using up MTRRs.
|
||||
|
||||
mtrr_spare_reg_nr=n [X86]
|
||||
Format: <integer>
|
||||
Range: 0,7 : spare reg number
|
||||
Default : 1
|
||||
Used for mtrr cleanup. It is spare mtrr entries number.
|
||||
Set to 2 or more if your graphical card needs more.
|
||||
entry later. This parameter disables that.
|
||||
|
||||
disable_mtrr_trim [X86, Intel and AMD only]
|
||||
By default the kernel will trim any uncacheable
|
||||
@@ -707,12 +592,38 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
MTRR settings. This parameter disables that behavior,
|
||||
possibly causing your machine to run very slowly.
|
||||
|
||||
disable_timer_pin_1 [i386,x86-64]
|
||||
Disable PIN 1 of APIC timer
|
||||
Can be useful to work around chipset bugs.
|
||||
|
||||
dmasound= [HW,OSS] Sound subsystem buffers
|
||||
|
||||
dma_debug=off If the kernel is compiled with DMA_API_DEBUG support,
|
||||
this option disables the debugging code at boot.
|
||||
|
||||
dma_debug_entries=<number>
|
||||
This option allows to tune the number of preallocated
|
||||
entries for DMA-API debugging code. One entry is
|
||||
required per DMA-API allocation. Use this if the
|
||||
DMA-API debugging code disables itself because the
|
||||
architectural default is too low.
|
||||
|
||||
dscc4.setup= [NET]
|
||||
|
||||
dtc3181e= [HW,SCSI]
|
||||
|
||||
dynamic_printk Enables pr_debug()/dev_dbg() calls if
|
||||
CONFIG_DYNAMIC_PRINTK_DEBUG has been enabled.
|
||||
These can also be switched on/off via
|
||||
<debugfs>/dynamic_printk/modules
|
||||
|
||||
earlycon= [KNL] Output early console device and options.
|
||||
uart[8250],io,<addr>[,options]
|
||||
uart[8250],mmio,<addr>[,options]
|
||||
Start an early, polled-mode console on the 8250/16550
|
||||
UART at the specified I/O port or MMIO address.
|
||||
The options are the same as for ttyS, above.
|
||||
|
||||
earlyprintk= [X86-32,X86-64,SH,BLACKFIN]
|
||||
earlyprintk=vga
|
||||
earlyprintk=serial[,ttySn[,baudrate]]
|
||||
@@ -754,6 +665,17 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
pass this option to capture kernel.
|
||||
See Documentation/kdump/kdump.txt for details.
|
||||
|
||||
enable_mtrr_cleanup [X86]
|
||||
The kernel tries to adjust MTRR layout from continuous
|
||||
to discrete, to make X server driver able to add WB
|
||||
entry later. This parameter enables that.
|
||||
|
||||
enable_timer_pin_1 [i386,x86-64]
|
||||
Enable PIN 1 of APIC timer
|
||||
Can be useful to work around chipset bugs
|
||||
(in particular on some ATI chipsets).
|
||||
The kernel tries to set a reasonable default.
|
||||
|
||||
enforcing [SELINUX] Set initial enforcing status.
|
||||
Format: {"0" | "1"}
|
||||
See security/selinux/Kconfig help text.
|
||||
@@ -841,6 +763,16 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
hisax= [HW,ISDN]
|
||||
See Documentation/isdn/README.HiSax.
|
||||
|
||||
hlt [BUGS=ARM,SH]
|
||||
|
||||
hpet= [X86-32,HPET] option to control HPET usage
|
||||
Format: { enable (default) | disable | force |
|
||||
verbose }
|
||||
disable: disable HPET and use PIT instead
|
||||
force: allow force enabled of undocumented chips (ICH4,
|
||||
VIA, nVidia)
|
||||
verbose: show contents of HPET registers during setup
|
||||
|
||||
hugepages= [HW,X86-32,IA-64] HugeTLB pages to allocate at boot.
|
||||
hugepagesz= [HW,IA-64,PPC,X86-64] The size of the HugeTLB pages.
|
||||
On x86-64 and powerpc, this option can be specified
|
||||
@@ -850,15 +782,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
(when the CPU supports the "pdpe1gb" cpuinfo flag)
|
||||
Note that 1GB pages can only be allocated at boot time
|
||||
using hugepages= and not freed afterwards.
|
||||
default_hugepagesz=
|
||||
[same as hugepagesz=] The size of the default
|
||||
HugeTLB page size. This is the size represented by
|
||||
the legacy /proc/ hugepages APIs, used for SHM, and
|
||||
default size when mounting hugetlbfs filesystems.
|
||||
Defaults to the default architecture's huge page size
|
||||
if not specified.
|
||||
|
||||
hlt [BUGS=ARM,SH]
|
||||
|
||||
hvc_iucv= [S390] Number of z/VM IUCV hypervisor console (HVC)
|
||||
terminal devices. Valid values: 0..8
|
||||
@@ -919,6 +842,9 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed
|
||||
See Documentation/ide/ide.txt.
|
||||
|
||||
ide-pci-generic.all-generic-ide [HW] (E)IDE subsystem
|
||||
Claim all unknown PCI IDE storage controllers.
|
||||
|
||||
idle= [X86]
|
||||
Format: idle=poll, idle=mwait, idle=halt, idle=nomwait
|
||||
Poll forces a polling idle loop that can slightly
|
||||
@@ -934,9 +860,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
In such case C2/C3 won't be used again.
|
||||
idle=nomwait: Disable mwait for CPU C-states
|
||||
|
||||
ide-pci-generic.all-generic-ide [HW] (E)IDE subsystem
|
||||
Claim all unknown PCI IDE storage controllers.
|
||||
|
||||
ignore_loglevel [KNL]
|
||||
Ignore loglevel setting - this will print /all/
|
||||
kernel messages to the console. Useful for debugging.
|
||||
@@ -970,25 +893,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
inport.irq= [HW] Inport (ATI XL and Microsoft) busmouse driver
|
||||
Format: <irq>
|
||||
|
||||
inttest= [IA64]
|
||||
|
||||
iomem= Disable strict checking of access to MMIO memory
|
||||
strict regions from userspace.
|
||||
relaxed
|
||||
|
||||
iommu= [x86]
|
||||
off
|
||||
force
|
||||
noforce
|
||||
biomerge
|
||||
panic
|
||||
nopanic
|
||||
merge
|
||||
nomerge
|
||||
forcesac
|
||||
soft
|
||||
|
||||
|
||||
intel_iommu= [DMAR] Intel IOMMU driver (DMAR) option
|
||||
on
|
||||
Enable intel iommu driver.
|
||||
@@ -1012,6 +916,28 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
result in a hardware IOTLB flush operation as opposed
|
||||
to batching them for performance.
|
||||
|
||||
inttest= [IA64]
|
||||
|
||||
iomem= Disable strict checking of access to MMIO memory
|
||||
strict regions from userspace.
|
||||
relaxed
|
||||
|
||||
iommu= [x86]
|
||||
off
|
||||
force
|
||||
noforce
|
||||
biomerge
|
||||
panic
|
||||
nopanic
|
||||
merge
|
||||
nomerge
|
||||
forcesac
|
||||
soft
|
||||
|
||||
io7= [HW] IO7 for Marvel based alpha systems
|
||||
See comment before marvel_specify_io7 in
|
||||
arch/alpha/kernel/core_marvel.c.
|
||||
|
||||
io_delay= [X86-32,X86-64] I/O delay method
|
||||
0x80
|
||||
Standard port 0x80 based delay
|
||||
@@ -1022,10 +948,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
none
|
||||
No delay
|
||||
|
||||
io7= [HW] IO7 for Marvel based alpha systems
|
||||
See comment before marvel_specify_io7 in
|
||||
arch/alpha/kernel/core_marvel.c.
|
||||
|
||||
ip= [IP_PNP]
|
||||
See Documentation/filesystems/nfsroot.txt.
|
||||
|
||||
@@ -1036,12 +958,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
ips= [HW,SCSI] Adaptec / IBM ServeRAID controller
|
||||
See header of drivers/scsi/ips.c.
|
||||
|
||||
ports= [IP_VS_FTP] IPVS ftp helper module
|
||||
Default is 21.
|
||||
Up to 8 (IP_VS_APP_MAX_PORTS) ports
|
||||
may be specified.
|
||||
Format: <port>,<port>....
|
||||
|
||||
irqfixup [HW]
|
||||
When an interrupt is not handled search all handlers
|
||||
for it. Intended to get systems with badly broken
|
||||
@@ -1082,6 +998,8 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
js= [HW,JOY] Analog joystick
|
||||
See Documentation/input/joystick.txt.
|
||||
|
||||
keepinitrd [HW,ARM]
|
||||
|
||||
kernelcore=nn[KMG] [KNL,X86-32,IA-64,PPC,X86-64] This parameter
|
||||
specifies the amount of memory usable by the kernel
|
||||
for non-movable allocations. The requested amount is
|
||||
@@ -1107,21 +1025,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
higher than default (KMEMTRACE_N_SUBBUFS in code) if
|
||||
you experience buffer overruns.
|
||||
|
||||
movablecore=nn[KMG] [KNL,X86-32,IA-64,PPC,X86-64] This parameter
|
||||
is similar to kernelcore except it specifies the
|
||||
amount of memory used for migratable allocations.
|
||||
If both kernelcore and movablecore is specified,
|
||||
then kernelcore will be at *least* the specified
|
||||
value but may be more. If movablecore on its own
|
||||
is specified, the administrator must be careful
|
||||
that the amount of memory usable for all allocations
|
||||
is not too small.
|
||||
|
||||
keepinitrd [HW,ARM]
|
||||
|
||||
kstack=N [X86-32,X86-64] Print N words from the kernel stack
|
||||
in oops dumps.
|
||||
|
||||
kgdboc= [HW] kgdb over consoles.
|
||||
Requires a tty driver that supports console polling.
|
||||
(only serial suported for now)
|
||||
@@ -1131,6 +1034,9 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
Configure the RouterBoard 532 series on-chip
|
||||
Ethernet adapter MAC address.
|
||||
|
||||
kstack=N [X86-32,X86-64] Print N words from the kernel stack
|
||||
in oops dumps.
|
||||
|
||||
l2cr= [PPC]
|
||||
|
||||
l3cr= [PPC]
|
||||
@@ -1276,9 +1182,8 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
(machvec) in a generic kernel.
|
||||
Example: machvec=hpzx1_swiotlb
|
||||
|
||||
max_loop= [LOOP] Maximum number of loopback devices that can
|
||||
be mounted
|
||||
Format: <1-256>
|
||||
max_addr=nn[KMG] [KNL,BOOT,ia64] All physical memory greater
|
||||
than or equal to this physical address is ignored.
|
||||
|
||||
maxcpus= [SMP] Maximum number of processors that an SMP kernel
|
||||
should make use of. maxcpus=n : n >= 0 limits the
|
||||
@@ -1286,8 +1191,9 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
it is equivalent to "nosmp", which also disables
|
||||
the IO APIC.
|
||||
|
||||
max_addr=nn[KMG] [KNL,BOOT,ia64] All physical memory greater than
|
||||
or equal to this physical address is ignored.
|
||||
max_loop= [LOOP] Maximum number of loopback devices that can
|
||||
be mounted
|
||||
Format: <1-256>
|
||||
|
||||
max_luns= [SCSI] Maximum number of LUNs to probe.
|
||||
Should be between 1 and 2^32-1.
|
||||
@@ -1414,6 +1320,16 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
mousedev.yres= [MOUSE] Vertical screen resolution, used for devices
|
||||
reporting absolute coordinates, such as tablets
|
||||
|
||||
movablecore=nn[KMG] [KNL,X86-32,IA-64,PPC,X86-64] This parameter
|
||||
is similar to kernelcore except it specifies the
|
||||
amount of memory used for migratable allocations.
|
||||
If both kernelcore and movablecore is specified,
|
||||
then kernelcore will be at *least* the specified
|
||||
value but may be more. If movablecore on its own
|
||||
is specified, the administrator must be careful
|
||||
that the amount of memory usable for all allocations
|
||||
is not too small.
|
||||
|
||||
mpu401= [HW,OSS]
|
||||
Format: <io>,<irq>
|
||||
|
||||
@@ -1435,6 +1351,23 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
[HW] Make the MicroTouch USB driver use raw coordinates
|
||||
('y', default) or cooked coordinates ('n')
|
||||
|
||||
mtrr_chunk_size=nn[KMG] [X86]
|
||||
used for mtrr cleanup. It is largest continous chunk
|
||||
that could hold holes aka. UC entries.
|
||||
|
||||
mtrr_gran_size=nn[KMG] [X86]
|
||||
Used for mtrr cleanup. It is granularity of mtrr block.
|
||||
Default is 1.
|
||||
Large value could prevent small alignment from
|
||||
using up MTRRs.
|
||||
|
||||
mtrr_spare_reg_nr=n [X86]
|
||||
Format: <integer>
|
||||
Range: 0,7 : spare reg number
|
||||
Default : 1
|
||||
Used for mtrr cleanup. It is spare mtrr entries number.
|
||||
Set to 2 or more if your graphical card needs more.
|
||||
|
||||
n2= [NET] SDL Inc. RISCom/N2 synchronous serial card
|
||||
|
||||
NCR_D700= [HW,SCSI]
|
||||
@@ -1495,11 +1428,13 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
0 - turn nmi_watchdog off
|
||||
1 - use the IO-APIC timer for the NMI watchdog
|
||||
2 - use the local APIC for the NMI watchdog using
|
||||
a performance counter. Note: This will use one performance
|
||||
counter and the local APIC's performance vector.
|
||||
When panic is specified panic when an NMI watchdog timeout occurs.
|
||||
This is useful when you use a panic=... timeout and need the box
|
||||
quickly up again.
|
||||
a performance counter. Note: This will use one
|
||||
performance counter and the local APIC's performance
|
||||
vector.
|
||||
When panic is specified, panic when an NMI watchdog
|
||||
timeout occurs.
|
||||
This is useful when you use a panic=... timeout and
|
||||
need the box quickly up again.
|
||||
Instead of 1 and 2 it is possible to use the following
|
||||
symbolic names: lapic and ioapic
|
||||
Example: nmi_watchdog=2 or nmi_watchdog=panic,lapic
|
||||
@@ -1508,6 +1443,16 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
emulation library even if a 387 maths coprocessor
|
||||
is present.
|
||||
|
||||
no_console_suspend
|
||||
[HW] Never suspend the console
|
||||
Disable suspending of consoles during suspend and
|
||||
hibernate operations. Once disabled, debugging
|
||||
messages can reach various consoles while the rest
|
||||
of the system is being put to sleep (ie, while
|
||||
debugging driver suspend/resume hooks). This may
|
||||
not work reliably with all consoles, but is known
|
||||
to work with serial and VGA consoles.
|
||||
|
||||
noaliencache [MM, NUMA, SLAB] Disables the allocation of alien
|
||||
caches in the slab allocator. Saves per-node memory,
|
||||
but will impact performance.
|
||||
@@ -1522,6 +1467,8 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
|
||||
nocache [ARM]
|
||||
|
||||
noclflush [BUGS=X86] Don't use the CLFLUSH instruction
|
||||
|
||||
nodelayacct [KNL] Disable per-task delay accounting
|
||||
|
||||
nodisconnect [HW,SCSI,M68K] Disables SCSI disconnects.
|
||||
@@ -1550,8 +1497,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
register save and restore. The kernel will only save
|
||||
legacy floating-point registers on task switch.
|
||||
|
||||
noclflush [BUGS=X86] Don't use the CLFLUSH instruction
|
||||
|
||||
nohlt [BUGS=ARM,SH] Tells the kernel that the sleep(SH) or
|
||||
wfi(ARM) instruction doesn't work correctly and not to
|
||||
use it. This is also useful when using JTAG debugger.
|
||||
@@ -1596,12 +1541,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
|
||||
nolapic_timer [X86-32,APIC] Do not use the local APIC timer.
|
||||
|
||||
nox2apic [X86-64,APIC] Do not enable x2APIC mode.
|
||||
|
||||
x2apic_phys [X86-64,APIC] Use x2apic physical mode instead of
|
||||
default x2apic cluster mode on platforms
|
||||
supporting x2apic.
|
||||
|
||||
noltlbs [PPC] Do not use large page/tlb entries for kernel
|
||||
lowmem mapping on PPC40x.
|
||||
|
||||
@@ -1612,6 +1551,9 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
nomfgpt [X86-32] Disable Multi-Function General Purpose
|
||||
Timer usage (for AMD Geode machines).
|
||||
|
||||
norandmaps Don't use address space randomization. Equivalent to
|
||||
echo 0 > /proc/sys/kernel/randomize_va_space
|
||||
|
||||
noreplace-paravirt [X86-32,PV_OPS] Don't patch paravirt_ops
|
||||
|
||||
noreplace-smp [X86-32,SMP] Don't replace SMP instructions
|
||||
@@ -1650,13 +1592,13 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
purges which is reported from either PAL_VM_SUMMARY or
|
||||
SAL PALO.
|
||||
|
||||
nr_uarts= [SERIAL] maximum number of UARTs to be registered.
|
||||
|
||||
numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA.
|
||||
one of ['zone', 'node', 'default'] can be specified
|
||||
This can be set from sysctl after boot.
|
||||
See Documentation/sysctl/vm.txt for details.
|
||||
|
||||
nr_uarts= [SERIAL] maximum number of UARTs to be registered.
|
||||
|
||||
ohci1394_dma=early [HW] enable debugging via the ohci1394 driver.
|
||||
See Documentation/debugging-via-ohci1394.txt for more
|
||||
info.
|
||||
@@ -1905,6 +1847,14 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
printk.time= Show timing data prefixed to each printk message line
|
||||
Format: <bool> (1/Y/y=enable, 0/N/n=disable)
|
||||
|
||||
processor.max_cstate= [HW,ACPI]
|
||||
Limit processor to maximum C-state
|
||||
max_cstate=9 overrides any DMI blacklist limit.
|
||||
|
||||
processor.nocst [HW,ACPI]
|
||||
Ignore the _CST method to determine C-states,
|
||||
instead using the legacy FADT method
|
||||
|
||||
profile= [KNL] Enable kernel profiling via /proc/profile
|
||||
Format: [schedule,]<number>
|
||||
Param: "schedule" - profile schedule points.
|
||||
@@ -1914,14 +1864,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
Requires CONFIG_SCHEDSTATS
|
||||
Param: "kvm" - profile VM exits.
|
||||
|
||||
processor.max_cstate= [HW,ACPI]
|
||||
Limit processor to maximum C-state
|
||||
max_cstate=9 overrides any DMI blacklist limit.
|
||||
|
||||
processor.nocst [HW,ACPI]
|
||||
Ignore the _CST method to determine C-states,
|
||||
instead using the legacy FADT method
|
||||
|
||||
prompt_ramdisk= [RAM] List of RAM disks to prompt for floppy disk
|
||||
before loading.
|
||||
See Documentation/blockdev/ramdisk.txt.
|
||||
@@ -2075,7 +2017,13 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
allowing boot to proceed. none ignores them, expecting
|
||||
user space to do the scan.
|
||||
|
||||
selinux [SELINUX] Disable or enable SELinux at boot time.
|
||||
security= [SECURITY] Choose a security module to enable at boot.
|
||||
If this boot parameter is not specified, only the first
|
||||
security module asking for security registration will be
|
||||
loaded. An invalid security module name will be treated
|
||||
as if no module has been chosen.
|
||||
|
||||
selinux= [SELINUX] Disable or enable SELinux at boot time.
|
||||
Format: { "0" | "1" }
|
||||
See security/selinux/Kconfig help text.
|
||||
0 -- disable.
|
||||
@@ -2499,9 +2447,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
medium is write-protected).
|
||||
Example: quirks=0419:aaf5:rl,0421:0433:rc
|
||||
|
||||
add_efi_memmap [EFI; x86-32,X86-64] Include EFI memory map in
|
||||
kernel's map of available physical RAM.
|
||||
|
||||
vdso= [X86-32,SH,x86-64]
|
||||
vdso=2: enable compat VDSO (default with COMPAT_VDSO)
|
||||
vdso=1: enable VDSO (default)
|
||||
@@ -2540,6 +2485,31 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
vmpoff= [KNL,S390] Perform z/VM CP command after power off.
|
||||
Format: <command>
|
||||
|
||||
vt.default_blu= [VT]
|
||||
Format: <blue0>,<blue1>,<blue2>,...,<blue15>
|
||||
Change the default blue palette of the console.
|
||||
This is a 16-member array composed of values
|
||||
ranging from 0-255.
|
||||
|
||||
vt.default_grn= [VT]
|
||||
Format: <green0>,<green1>,<green2>,...,<green15>
|
||||
Change the default green palette of the console.
|
||||
This is a 16-member array composed of values
|
||||
ranging from 0-255.
|
||||
|
||||
vt.default_red= [VT]
|
||||
Format: <red0>,<red1>,<red2>,...,<red15>
|
||||
Change the default red palette of the console.
|
||||
This is a 16-member array composed of values
|
||||
ranging from 0-255.
|
||||
|
||||
vt.default_utf8=
|
||||
[VT]
|
||||
Format=<0|1>
|
||||
Set system-wide default UTF-8 mode for all tty's.
|
||||
Default is 1, i.e. UTF-8 mode is enabled for all
|
||||
newly opened terminals.
|
||||
|
||||
waveartist= [HW,OSS]
|
||||
Format: <io>,<irq>,<dma>,<dma2>
|
||||
|
||||
@@ -2552,6 +2522,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
wdt= [WDT] Watchdog
|
||||
See Documentation/watchdog/wdt.txt.
|
||||
|
||||
x2apic_phys [X86-64,APIC] Use x2apic physical mode instead of
|
||||
default x2apic cluster mode on platforms
|
||||
supporting x2apic.
|
||||
|
||||
xd= [HW,XT] Original XT pre-IDE (RLL encoded) disks.
|
||||
xd_geo= See header of drivers/block/xd.c.
|
||||
|
||||
@@ -2559,9 +2533,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
Format:
|
||||
<irq>,<irq_mask>,<io>,<full_duplex>,<do_sound>,<lockup_hack>[,<irq2>[,<irq3>[,<irq4>]]]
|
||||
|
||||
norandmaps Don't use address space randomization. Equivalent to
|
||||
echo 0 > /proc/sys/kernel/randomize_va_space
|
||||
|
||||
______________________________________________________________________
|
||||
|
||||
TODO:
|
||||
|
@@ -212,7 +212,9 @@ hit, Kprobes calls kp->pre_handler. After the probed instruction
|
||||
is single-stepped, Kprobe calls kp->post_handler. If a fault
|
||||
occurs during execution of kp->pre_handler or kp->post_handler,
|
||||
or during single-stepping of the probed instruction, Kprobes calls
|
||||
kp->fault_handler. Any or all handlers can be NULL.
|
||||
kp->fault_handler. Any or all handlers can be NULL. If kp->flags
|
||||
is set KPROBE_FLAG_DISABLED, that kp will be registered but disabled,
|
||||
so, it's handlers aren't hit until calling enable_kprobe(kp).
|
||||
|
||||
NOTE:
|
||||
1. With the introduction of the "symbol_name" field to struct kprobe,
|
||||
@@ -363,6 +365,26 @@ probes) in the specified array, they clear the addr field of those
|
||||
incorrect probes. However, other probes in the array are
|
||||
unregistered correctly.
|
||||
|
||||
4.7 disable_*probe
|
||||
|
||||
#include <linux/kprobes.h>
|
||||
int disable_kprobe(struct kprobe *kp);
|
||||
int disable_kretprobe(struct kretprobe *rp);
|
||||
int disable_jprobe(struct jprobe *jp);
|
||||
|
||||
Temporarily disables the specified *probe. You can enable it again by using
|
||||
enable_*probe(). You must specify the probe which has been registered.
|
||||
|
||||
4.8 enable_*probe
|
||||
|
||||
#include <linux/kprobes.h>
|
||||
int enable_kprobe(struct kprobe *kp);
|
||||
int enable_kretprobe(struct kretprobe *rp);
|
||||
int enable_jprobe(struct jprobe *jp);
|
||||
|
||||
Enables *probe which has been disabled by disable_*probe(). You must specify
|
||||
the probe which has been registered.
|
||||
|
||||
5. Kprobes Features and Limitations
|
||||
|
||||
Kprobes allows multiple probes at the same address. Currently,
|
||||
@@ -500,10 +522,14 @@ the probe. If the probed function belongs to a module, the module name
|
||||
is also specified. Following columns show probe status. If the probe is on
|
||||
a virtual address that is no longer valid (module init sections, module
|
||||
virtual addresses that correspond to modules that've been unloaded),
|
||||
such probes are marked with [GONE].
|
||||
such probes are marked with [GONE]. If the probe is temporarily disabled,
|
||||
such probes are marked with [DISABLED].
|
||||
|
||||
/debug/kprobes/enabled: Turn kprobes ON/OFF
|
||||
/debug/kprobes/enabled: Turn kprobes ON/OFF forcibly.
|
||||
|
||||
Provides a knob to globally turn registered kprobes ON or OFF. By default,
|
||||
all kprobes are enabled. By echoing "0" to this file, all registered probes
|
||||
will be disarmed, till such time a "1" is echoed to this file.
|
||||
Provides a knob to globally and forcibly turn registered kprobes ON or OFF.
|
||||
By default, all kprobes are enabled. By echoing "0" to this file, all
|
||||
registered probes will be disarmed, till such time a "1" is echoed to this
|
||||
file. Note that this knob just disarms and arms all kprobes and doesn't
|
||||
change each probe's disabling state. This means that disabled kprobes (marked
|
||||
[DISABLED]) will be not enabled if you turn ON all kprobes by this knob.
|
||||
|
@@ -43,12 +43,11 @@ Table of Contents
|
||||
2) Representing devices without a current OF specification
|
||||
a) PHY nodes
|
||||
b) Interrupt controllers
|
||||
c) CFI or JEDEC memory-mapped NOR flash
|
||||
d) 4xx/Axon EMAC ethernet nodes
|
||||
e) Xilinx IP cores
|
||||
f) USB EHCI controllers
|
||||
g) MDIO on GPIOs
|
||||
h) SPI busses
|
||||
c) 4xx/Axon EMAC ethernet nodes
|
||||
d) Xilinx IP cores
|
||||
e) USB EHCI controllers
|
||||
f) MDIO on GPIOs
|
||||
g) SPI busses
|
||||
|
||||
VII - Marvell Discovery mv64[345]6x System Controller chips
|
||||
1) The /system-controller node
|
||||
@@ -999,7 +998,7 @@ compatibility.
|
||||
translation of SOC addresses for memory mapped SOC registers.
|
||||
- bus-frequency: Contains the bus frequency for the SOC node.
|
||||
Typically, the value of this field is filled in by the boot
|
||||
loader.
|
||||
loader.
|
||||
|
||||
|
||||
Recommended properties:
|
||||
@@ -1287,71 +1286,7 @@ platforms are moved over to use the flattened-device-tree model.
|
||||
device_type = "open-pic";
|
||||
};
|
||||
|
||||
c) CFI or JEDEC memory-mapped NOR flash
|
||||
|
||||
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 of the flash chip
|
||||
- bank-width : Width (in bytes) of the flash bank. Equal to the
|
||||
device width times the number of interleaved chips.
|
||||
- device-width : (optional) Width of a single flash chip. If
|
||||
omitted, assumed to be equal to 'bank-width'.
|
||||
- #address-cells, #size-cells : Must be present if the flash has
|
||||
sub-nodes representing partitions (see below). In this case
|
||||
both #address-cells and #size-cells must be equal to 1.
|
||||
|
||||
For JEDEC compatible devices, the following additional properties
|
||||
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
|
||||
device tree may optionally contain additional information
|
||||
describing partitions of the flash 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
|
||||
use an on-flash partition table such as RedBoot.
|
||||
|
||||
Each partition is represented as a sub-node of the flash device.
|
||||
Each node's name represents the name of the corresponding
|
||||
partition of the flash device.
|
||||
|
||||
Flash partitions
|
||||
- reg : The partition's offset and size within the flash bank.
|
||||
- label : (optional) The label / name for this flash 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
|
||||
read-only. This is usually used for flash partitions
|
||||
containing early-boot firmware images or data which should not
|
||||
be clobbered.
|
||||
|
||||
Example:
|
||||
|
||||
flash@ff000000 {
|
||||
compatible = "amd,am29lv128ml", "cfi-flash";
|
||||
reg = <ff000000 01000000>;
|
||||
bank-width = <4>;
|
||||
device-width = <1>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
fs@0 {
|
||||
label = "fs";
|
||||
reg = <0 f80000>;
|
||||
};
|
||||
firmware@f80000 {
|
||||
label ="firmware";
|
||||
reg = <f80000 80000>;
|
||||
read-only;
|
||||
};
|
||||
};
|
||||
|
||||
d) 4xx/Axon EMAC ethernet nodes
|
||||
c) 4xx/Axon EMAC ethernet nodes
|
||||
|
||||
The EMAC ethernet controller in IBM and AMCC 4xx chips, and also
|
||||
the Axon bridge. To operate this needs to interact with a ths
|
||||
@@ -1499,7 +1434,7 @@ platforms are moved over to use the flattened-device-tree model.
|
||||
available.
|
||||
For Axon: 0x0000012a
|
||||
|
||||
e) Xilinx IP cores
|
||||
d) Xilinx IP cores
|
||||
|
||||
The Xilinx EDK toolchain ships with a set of IP cores (devices) for use
|
||||
in Xilinx Spartan and Virtex FPGAs. The devices cover the whole range
|
||||
@@ -1761,7 +1696,7 @@ platforms are moved over to use the flattened-device-tree model.
|
||||
listed above, nodes for these devices should include a phy-handle
|
||||
property, and may include other common network device properties
|
||||
like local-mac-address.
|
||||
|
||||
|
||||
iv) Xilinx Uartlite
|
||||
|
||||
Xilinx uartlite devices are simple fixed speed serial ports.
|
||||
@@ -1793,7 +1728,7 @@ platforms are moved over to use the flattened-device-tree model.
|
||||
- reg-offset : A value of 3 is required
|
||||
- reg-shift : A value of 2 is required
|
||||
|
||||
f) USB EHCI controllers
|
||||
e) USB EHCI controllers
|
||||
|
||||
Required properties:
|
||||
- compatible : should be "usb-ehci".
|
||||
@@ -1819,7 +1754,7 @@ platforms are moved over to use the flattened-device-tree model.
|
||||
big-endian;
|
||||
};
|
||||
|
||||
g) MDIO on GPIOs
|
||||
f) MDIO on GPIOs
|
||||
|
||||
Currently defined compatibles:
|
||||
- virtual,gpio-mdio
|
||||
@@ -1839,7 +1774,7 @@ platforms are moved over to use the flattened-device-tree model.
|
||||
&qe_pio_c 6>;
|
||||
};
|
||||
|
||||
h) SPI (Serial Peripheral Interface) busses
|
||||
g) SPI (Serial Peripheral Interface) busses
|
||||
|
||||
SPI busses can be described with a node for the SPI master device
|
||||
and a set of child nodes for each SPI slave on the bus. For this
|
||||
|
@@ -5,9 +5,21 @@ Required properties:
|
||||
- reg : should specify localbus chip select and size used for the chip.
|
||||
- fsl,upm-addr-offset : UPM pattern offset for the address latch.
|
||||
- fsl,upm-cmd-offset : UPM pattern offset for the command latch.
|
||||
- gpios : may specify optional GPIO connected to the Ready-Not-Busy pin.
|
||||
|
||||
Example:
|
||||
Optional properties:
|
||||
- fsl,upm-wait-flags : add chip-dependent short delays after running the
|
||||
UPM pattern (0x1), after writing a data byte (0x2) or after
|
||||
writing out a buffer (0x4).
|
||||
- fsl,upm-addr-line-cs-offsets : address offsets for multi-chip support.
|
||||
The corresponding address lines are used to select the chip.
|
||||
- gpios : may specify optional GPIOs connected to the Ready-Not-Busy pins
|
||||
(R/B#). For multi-chip devices, "n" GPIO definitions are required
|
||||
according to the number of chips.
|
||||
- chip-delay : chip dependent delay for transfering data from array to
|
||||
read registers (tR). Required if property "gpios" is not used
|
||||
(R/B# pins not connected).
|
||||
|
||||
Examples:
|
||||
|
||||
upm@1,0 {
|
||||
compatible = "fsl,upm-nand";
|
||||
@@ -26,3 +38,26 @@ upm@1,0 {
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
upm@3,0 {
|
||||
#address-cells = <0>;
|
||||
#size-cells = <0>;
|
||||
compatible = "tqc,tqm8548-upm-nand", "fsl,upm-nand";
|
||||
reg = <3 0x0 0x800>;
|
||||
fsl,upm-addr-offset = <0x10>;
|
||||
fsl,upm-cmd-offset = <0x08>;
|
||||
/* Multi-chip NAND device */
|
||||
fsl,upm-addr-line-cs-offsets = <0x0 0x200>;
|
||||
fsl,upm-wait-flags = <0x5>;
|
||||
chip-delay = <25>; // in micro-seconds
|
||||
|
||||
nand@0 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
partition@0 {
|
||||
label = "fs";
|
||||
reg = <0x00000000 0x10000000>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
@@ -1,15 +1,43 @@
|
||||
LED connected to GPIO
|
||||
LEDs connected to GPIO lines
|
||||
|
||||
Required properties:
|
||||
- compatible : should be "gpio-led".
|
||||
- label : (optional) the label for this LED. If omitted, the label is
|
||||
- compatible : should be "gpio-leds".
|
||||
|
||||
Each LED is represented as a sub-node of the gpio-leds device. Each
|
||||
node's name represents the name of the corresponding LED.
|
||||
|
||||
LED sub-node properties:
|
||||
- gpios : Should specify the LED's GPIO, see "Specifying GPIO information
|
||||
for devices" in Documentation/powerpc/booting-without-of.txt. Active
|
||||
low LEDs should be indicated using flags in the GPIO specifier.
|
||||
- label : (optional) The label for this LED. If omitted, the label is
|
||||
taken from the node name (excluding the unit address).
|
||||
- gpios : should specify LED GPIO.
|
||||
- linux,default-trigger : (optional) This parameter, if present, is a
|
||||
string defining the trigger assigned to the LED. Current triggers are:
|
||||
"backlight" - LED will act as a back-light, controlled by the framebuffer
|
||||
system
|
||||
"default-on" - LED will turn on
|
||||
"heartbeat" - LED "double" flashes at a load average based rate
|
||||
"ide-disk" - LED indicates disk activity
|
||||
"timer" - LED flashes at a fixed, configurable rate
|
||||
|
||||
Example:
|
||||
Examples:
|
||||
|
||||
led@0 {
|
||||
compatible = "gpio-led";
|
||||
label = "hdd";
|
||||
gpios = <&mcu_pio 0 1>;
|
||||
leds {
|
||||
compatible = "gpio-leds";
|
||||
hdd {
|
||||
label = "IDE Activity";
|
||||
gpios = <&mcu_pio 0 1>; /* Active low */
|
||||
linux,default-trigger = "ide-disk";
|
||||
};
|
||||
};
|
||||
|
||||
run-control {
|
||||
compatible = "gpio-leds";
|
||||
red {
|
||||
gpios = <&mpc8572 6 0>;
|
||||
};
|
||||
green {
|
||||
gpios = <&mpc8572 7 0>;
|
||||
};
|
||||
}
|
||||
|
80
Documentation/powerpc/dts-bindings/mtd-physmap.txt
Normal file
80
Documentation/powerpc/dts-bindings/mtd-physmap.txt
Normal file
@@ -0,0 +1,80 @@
|
||||
CFI or JEDEC memory-mapped NOR flash
|
||||
|
||||
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)
|
||||
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
|
||||
device width times the number of interleaved chips.
|
||||
- device-width : (optional) Width of a single flash chip. If
|
||||
omitted, assumed to be equal to 'bank-width'.
|
||||
- #address-cells, #size-cells : Must be present if the flash has
|
||||
sub-nodes representing partitions (see below). In this case
|
||||
both #address-cells and #size-cells must be equal to 1.
|
||||
|
||||
For JEDEC compatible devices, the following additional properties
|
||||
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
|
||||
device tree may optionally contain additional information
|
||||
describing partitions of the flash 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
|
||||
use an on-flash partition table such as RedBoot.
|
||||
|
||||
Each partition is represented as a sub-node of the flash device.
|
||||
Each node's name represents the name of the corresponding
|
||||
partition of the flash device.
|
||||
|
||||
Flash partitions
|
||||
- reg : The partition's offset and size within the flash bank.
|
||||
- label : (optional) The label / name for this flash 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
|
||||
read-only. This is usually used for flash partitions
|
||||
containing early-boot firmware images or data which should not
|
||||
be clobbered.
|
||||
|
||||
Example:
|
||||
|
||||
flash@ff000000 {
|
||||
compatible = "amd,am29lv128ml", "cfi-flash";
|
||||
reg = <ff000000 01000000>;
|
||||
bank-width = <4>;
|
||||
device-width = <1>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
fs@0 {
|
||||
label = "fs";
|
||||
reg = <0 f80000>;
|
||||
};
|
||||
firmware@f80000 {
|
||||
label ="firmware";
|
||||
reg = <f80000 80000>;
|
||||
read-only;
|
||||
};
|
||||
};
|
||||
|
||||
Here an example with multiple "reg" tuples:
|
||||
|
||||
flash@f0000000,0 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
compatible = "intel,PC48F4400P0VB", "cfi-flash";
|
||||
reg = <0 0x00000000 0x02000000
|
||||
0 0x02000000 0x02000000>;
|
||||
bank-width = <2>;
|
||||
partition@0 {
|
||||
label = "test-part1";
|
||||
reg = <0 0x04000000>;
|
||||
};
|
||||
};
|
@@ -60,17 +60,9 @@ Supported Cards/Chipsets
|
||||
9005:0285:9005:02d5 Adaptec ASR-2405 (Voodoo40 Lite)
|
||||
9005:0285:9005:02d6 Adaptec ASR-2445 (Voodoo44 Lite)
|
||||
9005:0285:9005:02d7 Adaptec ASR-2805 (Voodoo80 Lite)
|
||||
9005:0285:9005:02d8 Adaptec 5405G (Voodoo40 PM)
|
||||
9005:0285:9005:02d9 Adaptec 5445G (Voodoo44 PM)
|
||||
9005:0285:9005:02da Adaptec 5805G (Voodoo80 PM)
|
||||
9005:0285:9005:02db Adaptec 5085G (Voodoo08 PM)
|
||||
9005:0285:9005:02dc Adaptec 51245G (Voodoo124 PM)
|
||||
9005:0285:9005:02dd Adaptec 51645G (Voodoo164 PM)
|
||||
9005:0285:9005:02de Adaptec 52445G (Voodoo244 PM)
|
||||
9005:0285:9005:02df Adaptec ASR-2045G (Voodoo04 Lite PM)
|
||||
9005:0285:9005:02e0 Adaptec ASR-2405G (Voodoo40 Lite PM)
|
||||
9005:0285:9005:02e1 Adaptec ASR-2445G (Voodoo44 Lite PM)
|
||||
9005:0285:9005:02e2 Adaptec ASR-2805G (Voodoo80 Lite PM)
|
||||
9005:0285:9005:02d8 Adaptec 5405Z (Voodoo40 BLBU)
|
||||
9005:0285:9005:02d9 Adaptec 5445Z (Voodoo44 BLBU)
|
||||
9005:0285:9005:02da Adaptec 5805Z (Voodoo80 BLBU)
|
||||
1011:0046:9005:0364 Adaptec 5400S (Mustang)
|
||||
1011:0046:9005:0365 Adaptec 5400S (Mustang)
|
||||
9005:0287:9005:0800 Adaptec Themisto (Jupiter)
|
||||
@@ -140,6 +132,7 @@ Deanna Bonds (non-DASD support, PAE fibs and 64 bit,
|
||||
where fibs that go to the hardware are consistently called hw_fibs and
|
||||
not just fibs like the name of the driver tracking structure)
|
||||
Mark Salyzyn <Mark_Salyzyn@adaptec.com> Fixed panic issues and added some new product ids for upcoming hbas. Performance tuning, card failover and bug mitigations.
|
||||
Achim Leubner <Achim_Leubner@adaptec.com>
|
||||
|
||||
Original Driver
|
||||
-------------------------
|
||||
|
71
Documentation/sound/alsa/soc/jack.txt
Normal file
71
Documentation/sound/alsa/soc/jack.txt
Normal file
@@ -0,0 +1,71 @@
|
||||
ASoC jack detection
|
||||
===================
|
||||
|
||||
ALSA has a standard API for representing physical jacks to user space,
|
||||
the kernel side of which can be seen in include/sound/jack.h. ASoC
|
||||
provides a version of this API adding two additional features:
|
||||
|
||||
- It allows more than one jack detection method to work together on one
|
||||
user visible jack. In embedded systems it is common for multiple
|
||||
to be present on a single jack but handled by separate bits of
|
||||
hardware.
|
||||
|
||||
- Integration with DAPM, allowing DAPM endpoints to be updated
|
||||
automatically based on the detected jack status (eg, turning off the
|
||||
headphone outputs if no headphones are present).
|
||||
|
||||
This is done by splitting the jacks up into three things working
|
||||
together: the jack itself represented by a struct snd_soc_jack, sets of
|
||||
snd_soc_jack_pins representing DAPM endpoints to update and blocks of
|
||||
code providing jack reporting mechanisms.
|
||||
|
||||
For example, a system may have a stereo headset jack with two reporting
|
||||
mechanisms, one for the headphone and one for the microphone. Some
|
||||
systems won't be able to use their speaker output while a headphone is
|
||||
connected and so will want to make sure to update both speaker and
|
||||
headphone when the headphone jack status changes.
|
||||
|
||||
The jack - struct snd_soc_jack
|
||||
==============================
|
||||
|
||||
This represents a physical jack on the system and is what is visible to
|
||||
user space. The jack itself is completely passive, it is set up by the
|
||||
machine driver and updated by jack detection methods.
|
||||
|
||||
Jacks are created by the machine driver calling snd_soc_jack_new().
|
||||
|
||||
snd_soc_jack_pin
|
||||
================
|
||||
|
||||
These represent a DAPM pin to update depending on some of the status
|
||||
bits supported by the jack. Each snd_soc_jack has zero or more of these
|
||||
which are updated automatically. They are created by the machine driver
|
||||
and associated with the jack using snd_soc_jack_add_pins(). The status
|
||||
of the endpoint may configured to be the opposite of the jack status if
|
||||
required (eg, enabling a built in microphone if a microphone is not
|
||||
connected via a jack).
|
||||
|
||||
Jack detection methods
|
||||
======================
|
||||
|
||||
Actual jack detection is done by code which is able to monitor some
|
||||
input to the system and update a jack by calling snd_soc_jack_report(),
|
||||
specifying a subset of bits to update. The jack detection code should
|
||||
be set up by the machine driver, taking configuration for the jack to
|
||||
update and the set of things to report when the jack is connected.
|
||||
|
||||
Often this is done based on the status of a GPIO - a handler for this is
|
||||
provided by the snd_soc_jack_add_gpio() function. Other methods are
|
||||
also available, for example integrated into CODECs. One example of
|
||||
CODEC integrated jack detection can be see in the WM8350 driver.
|
||||
|
||||
Each jack may have multiple reporting mechanisms, though it will need at
|
||||
least one to be useful.
|
||||
|
||||
Machine drivers
|
||||
===============
|
||||
|
||||
These are all hooked together by the machine driver depending on the
|
||||
system hardware. The machine driver will set up the snd_soc_jack and
|
||||
the list of pins to update then set up one or more jack detection
|
||||
mechanisms to update that jack based on their current status.
|
@@ -42,6 +42,14 @@ sure that bitwise types don't get mixed up (little-endian vs big-endian
|
||||
vs cpu-endian vs whatever), and there the constant "0" really _is_
|
||||
special.
|
||||
|
||||
__bitwise__ - to be used for relatively compact stuff (gfp_t, etc.) that
|
||||
is mostly warning-free and is supposed to stay that way. Warnings will
|
||||
be generated without __CHECK_ENDIAN__.
|
||||
|
||||
__bitwise - noisy stuff; in particular, __le*/__be* are that. We really
|
||||
don't want to drown in noise unless we'd explicitly asked for it.
|
||||
|
||||
|
||||
Getting sparse
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
|
@@ -95,7 +95,7 @@ of struct cmsghdr structures with appended data.
|
||||
|
||||
There is only one file in this directory.
|
||||
unix_dgram_qlen limits the max number of datagrams queued in Unix domain
|
||||
socket's buffer. It will not take effect unless PF_UNIX flag is spicified.
|
||||
socket's buffer. It will not take effect unless PF_UNIX flag is specified.
|
||||
|
||||
|
||||
3. /proc/sys/net/ipv4 - IPV4 settings
|
||||
|
@@ -39,6 +39,8 @@ Currently, these files are in /proc/sys/vm:
|
||||
- nr_hugepages
|
||||
- nr_overcommit_hugepages
|
||||
- nr_pdflush_threads
|
||||
- nr_pdflush_threads_min
|
||||
- nr_pdflush_threads_max
|
||||
- nr_trim_pages (only if CONFIG_MMU=n)
|
||||
- numa_zonelist_order
|
||||
- oom_dump_tasks
|
||||
@@ -463,6 +465,32 @@ The default value is 0.
|
||||
|
||||
==============================================================
|
||||
|
||||
nr_pdflush_threads_min
|
||||
|
||||
This value controls the minimum number of pdflush threads.
|
||||
|
||||
At boot time, the kernel will create and maintain 'nr_pdflush_threads_min'
|
||||
threads for the kernel's lifetime.
|
||||
|
||||
The default value is 2. The minimum value you can specify is 1, and
|
||||
the maximum value is the current setting of 'nr_pdflush_threads_max'.
|
||||
|
||||
See 'nr_pdflush_threads_max' below for more information.
|
||||
|
||||
==============================================================
|
||||
|
||||
nr_pdflush_threads_max
|
||||
|
||||
This value controls the maximum number of pdflush threads that can be
|
||||
created. The pdflush algorithm will create a new pdflush thread (up to
|
||||
this maximum) if no pdflush threads have been available for >= 1 second.
|
||||
|
||||
The default value is 8. The minimum value you can specify is the
|
||||
current value of 'nr_pdflush_threads_min' and the
|
||||
maximum is 1000.
|
||||
|
||||
==============================================================
|
||||
|
||||
overcommit_memory:
|
||||
|
||||
This value contains a flag that enables memory overcommitment.
|
||||
|
55
Documentation/tomoyo.txt
Normal file
55
Documentation/tomoyo.txt
Normal file
@@ -0,0 +1,55 @@
|
||||
--- What is TOMOYO? ---
|
||||
|
||||
TOMOYO is a name-based MAC extension (LSM module) for the Linux kernel.
|
||||
|
||||
LiveCD-based tutorials are available at
|
||||
http://tomoyo.sourceforge.jp/en/1.6.x/1st-step/ubuntu8.04-live/
|
||||
http://tomoyo.sourceforge.jp/en/1.6.x/1st-step/centos5-live/ .
|
||||
Though these tutorials use non-LSM version of TOMOYO, they are useful for you
|
||||
to know what TOMOYO is.
|
||||
|
||||
--- How to enable TOMOYO? ---
|
||||
|
||||
Build the kernel with CONFIG_SECURITY_TOMOYO=y and pass "security=tomoyo" on
|
||||
kernel's command line.
|
||||
|
||||
Please see http://tomoyo.sourceforge.jp/en/2.2.x/ for details.
|
||||
|
||||
--- Where is documentation? ---
|
||||
|
||||
User <-> Kernel interface documentation is available at
|
||||
http://tomoyo.sourceforge.jp/en/2.2.x/policy-reference.html .
|
||||
|
||||
Materials we prepared for seminars and symposiums are available at
|
||||
http://sourceforge.jp/projects/tomoyo/docs/?category_id=532&language_id=1 .
|
||||
Below lists are chosen from three aspects.
|
||||
|
||||
What is TOMOYO?
|
||||
TOMOYO Linux Overview
|
||||
http://sourceforge.jp/projects/tomoyo/docs/lca2009-takeda.pdf
|
||||
TOMOYO Linux: pragmatic and manageable security for Linux
|
||||
http://sourceforge.jp/projects/tomoyo/docs/freedomhectaipei-tomoyo.pdf
|
||||
TOMOYO Linux: A Practical Method to Understand and Protect Your Own Linux Box
|
||||
http://sourceforge.jp/projects/tomoyo/docs/PacSec2007-en-no-demo.pdf
|
||||
|
||||
What can TOMOYO do?
|
||||
Deep inside TOMOYO Linux
|
||||
http://sourceforge.jp/projects/tomoyo/docs/lca2009-kumaneko.pdf
|
||||
The role of "pathname based access control" in security.
|
||||
http://sourceforge.jp/projects/tomoyo/docs/lfj2008-bof.pdf
|
||||
|
||||
History of TOMOYO?
|
||||
Realities of Mainlining
|
||||
http://sourceforge.jp/projects/tomoyo/docs/lfj2008.pdf
|
||||
|
||||
--- What is future plan? ---
|
||||
|
||||
We believe that inode based security and name based security are complementary
|
||||
and both should be used together. But unfortunately, so far, we cannot enable
|
||||
multiple LSM modules at the same time. We feel sorry that you have to give up
|
||||
SELinux/SMACK/AppArmor etc. when you want to use TOMOYO.
|
||||
|
||||
We hope that LSM becomes stackable in future. Meanwhile, you can use non-LSM
|
||||
version of TOMOYO, available at http://tomoyo.sourceforge.jp/en/1.6.x/ .
|
||||
LSM version of TOMOYO is a subset of non-LSM version of TOMOYO. We are planning
|
||||
to port non-LSM version's functionalities to LSM versions.
|
125
Documentation/video4linux/pxa_camera.txt
Normal file
125
Documentation/video4linux/pxa_camera.txt
Normal file
@@ -0,0 +1,125 @@
|
||||
PXA-Camera Host Driver
|
||||
======================
|
||||
|
||||
Constraints
|
||||
-----------
|
||||
a) Image size for YUV422P format
|
||||
All YUV422P images are enforced to have width x height % 16 = 0.
|
||||
This is due to DMA constraints, which transfers only planes of 8 byte
|
||||
multiples.
|
||||
|
||||
|
||||
Global video workflow
|
||||
---------------------
|
||||
a) QCI stopped
|
||||
Initialy, the QCI interface is stopped.
|
||||
When a buffer is queued (pxa_videobuf_ops->buf_queue), the QCI starts.
|
||||
|
||||
b) QCI started
|
||||
More buffers can be queued while the QCI is started without halting the
|
||||
capture. The new buffers are "appended" at the tail of the DMA chain, and
|
||||
smoothly captured one frame after the other.
|
||||
|
||||
Once a buffer is filled in the QCI interface, it is marked as "DONE" and
|
||||
removed from the active buffers list. It can be then requeud or dequeued by
|
||||
userland application.
|
||||
|
||||
Once the last buffer is filled in, the QCI interface stops.
|
||||
|
||||
|
||||
DMA usage
|
||||
---------
|
||||
a) DMA flow
|
||||
- first buffer queued for capture
|
||||
Once a first buffer is queued for capture, the QCI is started, but data
|
||||
transfer is not started. On "End Of Frame" interrupt, the irq handler
|
||||
starts the DMA chain.
|
||||
- capture of one videobuffer
|
||||
The DMA chain starts transfering data into videobuffer RAM pages.
|
||||
When all pages are transfered, the DMA irq is raised on "ENDINTR" status
|
||||
- finishing one videobuffer
|
||||
The DMA irq handler marks the videobuffer as "done", and removes it from
|
||||
the active running queue
|
||||
Meanwhile, the next videobuffer (if there is one), is transfered by DMA
|
||||
- finishing the last videobuffer
|
||||
On the DMA irq of the last videobuffer, the QCI is stopped.
|
||||
|
||||
b) DMA prepared buffer will have this structure
|
||||
|
||||
+------------+-----+---------------+-----------------+
|
||||
| desc-sg[0] | ... | desc-sg[last] | finisher/linker |
|
||||
+------------+-----+---------------+-----------------+
|
||||
|
||||
This structure is pointed by dma->sg_cpu.
|
||||
The descriptors are used as follows :
|
||||
- desc-sg[i]: i-th descriptor, transfering the i-th sg
|
||||
element to the video buffer scatter gather
|
||||
- finisher: has ddadr=DADDR_STOP, dcmd=ENDIRQEN
|
||||
- linker: has ddadr= desc-sg[0] of next video buffer, dcmd=0
|
||||
|
||||
For the next schema, let's assume d0=desc-sg[0] .. dN=desc-sg[N],
|
||||
"f" stands for finisher and "l" for linker.
|
||||
A typical running chain is :
|
||||
|
||||
Videobuffer 1 Videobuffer 2
|
||||
+---------+----+---+ +----+----+----+---+
|
||||
| d0 | .. | dN | l | | d0 | .. | dN | f |
|
||||
+---------+----+-|-+ ^----+----+----+---+
|
||||
| |
|
||||
+----+
|
||||
|
||||
After the chaining is finished, the chain looks like :
|
||||
|
||||
Videobuffer 1 Videobuffer 2 Videobuffer 3
|
||||
+---------+----+---+ +----+----+----+---+ +----+----+----+---+
|
||||
| d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f |
|
||||
+---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+
|
||||
| | | |
|
||||
+----+ +----+
|
||||
new_link
|
||||
|
||||
c) DMA hot chaining timeslice issue
|
||||
|
||||
As DMA chaining is done while DMA _is_ running, the linking may be done
|
||||
while the DMA jumps from one Videobuffer to another. On the schema, that
|
||||
would be a problem if the following sequence is encountered :
|
||||
|
||||
- DMA chain is Videobuffer1 + Videobuffer2
|
||||
- pxa_videobuf_queue() is called to queue Videobuffer3
|
||||
- DMA controller finishes Videobuffer2, and DMA stops
|
||||
=>
|
||||
Videobuffer 1 Videobuffer 2
|
||||
+---------+----+---+ +----+----+----+---+
|
||||
| d0 | .. | dN | l | | d0 | .. | dN | f |
|
||||
+---------+----+-|-+ ^----+----+----+-^-+
|
||||
| | |
|
||||
+----+ +-- DMA DDADR loads DDADR_STOP
|
||||
|
||||
- pxa_dma_add_tail_buf() is called, the Videobuffer2 "finisher" is
|
||||
replaced by a "linker" to Videobuffer3 (creation of new_link)
|
||||
- pxa_videobuf_queue() finishes
|
||||
- the DMA irq handler is called, which terminates Videobuffer2
|
||||
- Videobuffer3 capture is not scheduled on DMA chain (as it stopped !!!)
|
||||
|
||||
Videobuffer 1 Videobuffer 2 Videobuffer 3
|
||||
+---------+----+---+ +----+----+----+---+ +----+----+----+---+
|
||||
| d0 | .. | dN | l | | d0 | .. | dN | l | | d0 | .. | dN | f |
|
||||
+---------+----+-|-+ ^----+----+----+-|-+ ^----+----+----+---+
|
||||
| | | |
|
||||
+----+ +----+
|
||||
new_link
|
||||
DMA DDADR still is DDADR_STOP
|
||||
|
||||
- pxa_camera_check_link_miss() is called
|
||||
This checks if the DMA is finished and a buffer is still on the
|
||||
pcdev->capture list. If that's the case, the capture will be restarted,
|
||||
and Videobuffer3 is scheduled on DMA chain.
|
||||
- the DMA irq handler finishes
|
||||
|
||||
Note: if DMA stops just after pxa_camera_check_link_miss() reads DDADR()
|
||||
value, we have the guarantee that the DMA irq handler will be called back
|
||||
when the DMA will finish the buffer, and pxa_camera_check_link_miss() will
|
||||
be called again, to reschedule Videobuffer3.
|
||||
|
||||
--
|
||||
Author: Robert Jarzmik <robert.jarzmik@free.fr>
|
@@ -90,7 +90,7 @@ up before calling v4l2_device_register then it will be untouched. If dev is
|
||||
NULL, then you *must* setup v4l2_dev->name before calling v4l2_device_register.
|
||||
|
||||
The first 'dev' argument is normally the struct device pointer of a pci_dev,
|
||||
usb_device or platform_device. It is rare for dev to be NULL, but it happens
|
||||
usb_interface or platform_device. It is rare for dev to be NULL, but it happens
|
||||
with ISA devices or when one device creates multiple PCI devices, thus making
|
||||
it impossible to associate v4l2_dev with a particular parent.
|
||||
|
||||
@@ -351,17 +351,6 @@ And this to go from an i2c_client to a v4l2_subdev struct:
|
||||
|
||||
struct v4l2_subdev *sd = i2c_get_clientdata(client);
|
||||
|
||||
Finally you need to make a command function to make driver->command()
|
||||
call the right subdev_ops functions:
|
||||
|
||||
static int subdev_command(struct i2c_client *client, unsigned cmd, void *arg)
|
||||
{
|
||||
return v4l2_subdev_command(i2c_get_clientdata(client), cmd, arg);
|
||||
}
|
||||
|
||||
If driver->command is never used then you can leave this out. Eventually the
|
||||
driver->command usage should be removed from v4l.
|
||||
|
||||
Make sure to call v4l2_device_unregister_subdev(sd) when the remove() callback
|
||||
is called. This will unregister the sub-device from the bridge driver. It is
|
||||
safe to call this even if the sub-device was never registered.
|
||||
@@ -375,14 +364,12 @@ from the remove() callback ensures that this is always done correctly.
|
||||
|
||||
The bridge driver also has some helper functions it can use:
|
||||
|
||||
struct v4l2_subdev *sd = v4l2_i2c_new_subdev(adapter, "module_foo", "chipid", 0x36);
|
||||
struct v4l2_subdev *sd = v4l2_i2c_new_subdev(v4l2_dev, adapter,
|
||||
"module_foo", "chipid", 0x36);
|
||||
|
||||
This loads the given module (can be NULL if no module needs to be loaded) and
|
||||
calls i2c_new_device() with the given i2c_adapter and chip/address arguments.
|
||||
If all goes well, then it registers the subdev with the v4l2_device. It gets
|
||||
the v4l2_device by calling i2c_get_adapdata(adapter), so you should make sure
|
||||
to call i2c_set_adapdata(adapter, v4l2_device) when you setup the i2c_adapter
|
||||
in your driver.
|
||||
If all goes well, then it registers the subdev with the v4l2_device.
|
||||
|
||||
You can also use v4l2_i2c_new_probed_subdev() which is very similar to
|
||||
v4l2_i2c_new_subdev(), except that it has an array of possible I2C addresses
|
||||
|
@@ -1,5 +1,7 @@
|
||||
00-INDEX
|
||||
- this file.
|
||||
active_mm.txt
|
||||
- An explanation from Linus about tsk->active_mm vs tsk->mm.
|
||||
balance
|
||||
- various information on memory balancing.
|
||||
hugetlbpage.txt
|
||||
|
83
Documentation/vm/active_mm.txt
Normal file
83
Documentation/vm/active_mm.txt
Normal file
@@ -0,0 +1,83 @@
|
||||
List: linux-kernel
|
||||
Subject: Re: active_mm
|
||||
From: Linus Torvalds <torvalds () transmeta ! com>
|
||||
Date: 1999-07-30 21:36:24
|
||||
|
||||
Cc'd to linux-kernel, because I don't write explanations all that often,
|
||||
and when I do I feel better about more people reading them.
|
||||
|
||||
On Fri, 30 Jul 1999, David Mosberger wrote:
|
||||
>
|
||||
> Is there a brief description someplace on how "mm" vs. "active_mm" in
|
||||
> the task_struct are supposed to be used? (My apologies if this was
|
||||
> discussed on the mailing lists---I just returned from vacation and
|
||||
> wasn't able to follow linux-kernel for a while).
|
||||
|
||||
Basically, the new setup is:
|
||||
|
||||
- we have "real address spaces" and "anonymous address spaces". The
|
||||
difference is that an anonymous address space doesn't care about the
|
||||
user-level page tables at all, so when we do a context switch into an
|
||||
anonymous address space we just leave the previous address space
|
||||
active.
|
||||
|
||||
The obvious use for a "anonymous address space" is any thread that
|
||||
doesn't need any user mappings - all kernel threads basically fall into
|
||||
this category, but even "real" threads can temporarily say that for
|
||||
some amount of time they are not going to be interested in user space,
|
||||
and that the scheduler might as well try to avoid wasting time on
|
||||
switching the VM state around. Currently only the old-style bdflush
|
||||
sync does that.
|
||||
|
||||
- "tsk->mm" points to the "real address space". For an anonymous process,
|
||||
tsk->mm will be NULL, for the logical reason that an anonymous process
|
||||
really doesn't _have_ a real address space at all.
|
||||
|
||||
- however, we obviously need to keep track of which address space we
|
||||
"stole" for such an anonymous user. For that, we have "tsk->active_mm",
|
||||
which shows what the currently active address space is.
|
||||
|
||||
The rule is that for a process with a real address space (ie tsk->mm is
|
||||
non-NULL) the active_mm obviously always has to be the same as the real
|
||||
one.
|
||||
|
||||
For a anonymous process, tsk->mm == NULL, and tsk->active_mm is the
|
||||
"borrowed" mm while the anonymous process is running. When the
|
||||
anonymous process gets scheduled away, the borrowed address space is
|
||||
returned and cleared.
|
||||
|
||||
To support all that, the "struct mm_struct" now has two counters: a
|
||||
"mm_users" counter that is how many "real address space users" there are,
|
||||
and a "mm_count" counter that is the number of "lazy" users (ie anonymous
|
||||
users) plus one if there are any real users.
|
||||
|
||||
Usually there is at least one real user, but it could be that the real
|
||||
user exited on another CPU while a lazy user was still active, so you do
|
||||
actually get cases where you have a address space that is _only_ used by
|
||||
lazy users. That is often a short-lived state, because once that thread
|
||||
gets scheduled away in favour of a real thread, the "zombie" mm gets
|
||||
released because "mm_users" becomes zero.
|
||||
|
||||
Also, a new rule is that _nobody_ ever has "init_mm" as a real MM any
|
||||
more. "init_mm" should be considered just a "lazy context when no other
|
||||
context is available", and in fact it is mainly used just at bootup when
|
||||
no real VM has yet been created. So code that used to check
|
||||
|
||||
if (current->mm == &init_mm)
|
||||
|
||||
should generally just do
|
||||
|
||||
if (!current->mm)
|
||||
|
||||
instead (which makes more sense anyway - the test is basically one of "do
|
||||
we have a user context", and is generally done by the page fault handler
|
||||
and things like that).
|
||||
|
||||
Anyway, I put a pre-patch-2.3.13-1 on ftp.kernel.org just a moment ago,
|
||||
because it slightly changes the interfaces to accomodate the alpha (who
|
||||
would have thought it, but the alpha actually ends up having one of the
|
||||
ugliest context switch codes - unlike the other architectures where the MM
|
||||
and register state is separate, the alpha PALcode joins the two, and you
|
||||
need to switch both together).
|
||||
|
||||
(From http://marc.info/?l=linux-kernel&m=93337278602211&w=2)
|
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user