diff options
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/00-INDEX | 6 | ||||
-rw-r--r-- | Documentation/ABI/obsolete/o2cb | 11 | ||||
-rw-r--r-- | Documentation/ABI/stable/o2cb | 10 | ||||
-rw-r--r-- | Documentation/ABI/testing/sysfs-ocfs2 | 89 | ||||
-rw-r--r-- | Documentation/DocBook/Makefile | 2 | ||||
-rw-r--r-- | Documentation/DocBook/kgdb.tmpl | 447 | ||||
-rw-r--r-- | Documentation/feature-removal-schedule.txt | 12 | ||||
-rw-r--r-- | Documentation/filesystems/xfs.txt | 15 | ||||
-rw-r--r-- | Documentation/i386/boot.txt | 28 | ||||
-rw-r--r-- | Documentation/ide/ide.txt | 47 | ||||
-rw-r--r-- | Documentation/ide/warm-plug-howto.txt | 13 | ||||
-rw-r--r-- | Documentation/kernel-parameters.txt | 31 | ||||
-rw-r--r-- | Documentation/s390/s390dbf.txt | 21 | ||||
-rw-r--r-- | Documentation/timers/highres.txt (renamed from Documentation/hrtimers/highres.txt) | 0 | ||||
-rw-r--r-- | Documentation/timers/hrtimers.txt (renamed from Documentation/hrtimers/hrtimers.txt) | 0 | ||||
-rw-r--r-- | Documentation/timers/timer_stats.txt (renamed from Documentation/hrtimer/timer_stats.txt) | 0 | ||||
-rw-r--r-- | Documentation/x86/pat.txt | 100 | ||||
-rw-r--r-- | Documentation/x86_64/boot-options.txt | 5 |
18 files changed, 778 insertions, 59 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index e8fb24671967..f7923a42e769 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX | |||
@@ -167,10 +167,8 @@ highuid.txt | |||
167 | - notes on the change from 16 bit to 32 bit user/group IDs. | 167 | - notes on the change from 16 bit to 32 bit user/group IDs. |
168 | hpet.txt | 168 | hpet.txt |
169 | - High Precision Event Timer Driver for Linux. | 169 | - High Precision Event Timer Driver for Linux. |
170 | hrtimer/ | 170 | timers/ |
171 | - info on the timer_stats debugging facility for timer (ab)use. | 171 | - info on the timer related topics |
172 | hrtimers/ | ||
173 | - info on the hrtimers subsystem for high-resolution kernel timers. | ||
174 | hw_random.txt | 172 | hw_random.txt |
175 | - info on Linux support for random number generator in i8xx chipsets. | 173 | - info on Linux support for random number generator in i8xx chipsets. |
176 | hwmon/ | 174 | hwmon/ |
diff --git a/Documentation/ABI/obsolete/o2cb b/Documentation/ABI/obsolete/o2cb new file mode 100644 index 000000000000..9c49d8e6c0cc --- /dev/null +++ b/Documentation/ABI/obsolete/o2cb | |||
@@ -0,0 +1,11 @@ | |||
1 | What: /sys/o2cb symlink | ||
2 | Date: Dec 2005 | ||
3 | KernelVersion: 2.6.16 | ||
4 | Contact: ocfs2-devel@oss.oracle.com | ||
5 | Description: This is a symlink: /sys/o2cb to /sys/fs/o2cb. The symlink will | ||
6 | be removed when new versions of ocfs2-tools which know to look | ||
7 | in /sys/fs/o2cb are sufficiently prevalent. Don't code new | ||
8 | software to look here, it should try /sys/fs/o2cb instead. | ||
9 | See Documentation/ABI/stable/o2cb for more information on usage. | ||
10 | Users: ocfs2-tools. It's sufficient to mail proposed changes to | ||
11 | ocfs2-devel@oss.oracle.com. | ||
diff --git a/Documentation/ABI/stable/o2cb b/Documentation/ABI/stable/o2cb new file mode 100644 index 000000000000..5eb1545e0b8d --- /dev/null +++ b/Documentation/ABI/stable/o2cb | |||
@@ -0,0 +1,10 @@ | |||
1 | What: /sys/fs/o2cb/ (was /sys/o2cb) | ||
2 | Date: Dec 2005 | ||
3 | KernelVersion: 2.6.16 | ||
4 | Contact: ocfs2-devel@oss.oracle.com | ||
5 | Description: Ocfs2-tools looks at 'interface-revision' for versioning | ||
6 | information. Each logmask/ file controls a set of debug prints | ||
7 | and can be written into with the strings "allow", "deny", or | ||
8 | "off". Reading the file returns the current state. | ||
9 | Users: ocfs2-tools. It's sufficient to mail proposed changes to | ||
10 | ocfs2-devel@oss.oracle.com. | ||
diff --git a/Documentation/ABI/testing/sysfs-ocfs2 b/Documentation/ABI/testing/sysfs-ocfs2 new file mode 100644 index 000000000000..b7cc516a8a8a --- /dev/null +++ b/Documentation/ABI/testing/sysfs-ocfs2 | |||
@@ -0,0 +1,89 @@ | |||
1 | What: /sys/fs/ocfs2/ | ||
2 | Date: April 2008 | ||
3 | Contact: ocfs2-devel@oss.oracle.com | ||
4 | Description: | ||
5 | The /sys/fs/ocfs2 directory contains knobs used by the | ||
6 | ocfs2-tools to interact with the filesystem. | ||
7 | |||
8 | What: /sys/fs/ocfs2/max_locking_protocol | ||
9 | Date: April 2008 | ||
10 | Contact: ocfs2-devel@oss.oracle.com | ||
11 | Description: | ||
12 | The /sys/fs/ocfs2/max_locking_protocol file displays version | ||
13 | of ocfs2 locking supported by the filesystem. This version | ||
14 | covers how ocfs2 uses distributed locking between cluster | ||
15 | nodes. | ||
16 | |||
17 | The protocol version has a major and minor number. Two | ||
18 | cluster nodes can interoperate if they have an identical | ||
19 | major number and an overlapping minor number - thus, | ||
20 | a node with version 1.10 can interoperate with a node | ||
21 | sporting version 1.8, as long as both use the 1.8 protocol. | ||
22 | |||
23 | Reading from this file returns a single line, the major | ||
24 | number and minor number joined by a period, eg "1.10". | ||
25 | |||
26 | This file is read-only. The value is compiled into the | ||
27 | driver. | ||
28 | |||
29 | What: /sys/fs/ocfs2/loaded_cluster_plugins | ||
30 | Date: April 2008 | ||
31 | Contact: ocfs2-devel@oss.oracle.com | ||
32 | Description: | ||
33 | The /sys/fs/ocfs2/loaded_cluster_plugins file describes | ||
34 | the available plugins to support ocfs2 cluster operation. | ||
35 | A cluster plugin is required to use ocfs2 in a cluster. | ||
36 | There are currently two available plugins: | ||
37 | |||
38 | * 'o2cb' - The classic o2cb cluster stack that ocfs2 has | ||
39 | used since its inception. | ||
40 | * 'user' - A plugin supporting userspace cluster software | ||
41 | in conjunction with fs/dlm. | ||
42 | |||
43 | Reading from this file returns the names of all loaded | ||
44 | plugins, one per line. | ||
45 | |||
46 | This file is read-only. Its contents may change as | ||
47 | plugins are loaded or removed. | ||
48 | |||
49 | What: /sys/fs/ocfs2/active_cluster_plugin | ||
50 | Date: April 2008 | ||
51 | Contact: ocfs2-devel@oss.oracle.com | ||
52 | Description: | ||
53 | The /sys/fs/ocfs2/active_cluster_plugin displays which | ||
54 | cluster plugin is currently in use by the filesystem. | ||
55 | The active plugin will appear in the loaded_cluster_plugins | ||
56 | file as well. Only one plugin can be used at a time. | ||
57 | |||
58 | Reading from this file returns the name of the active plugin | ||
59 | on a single line. | ||
60 | |||
61 | This file is read-only. Which plugin is active depends on | ||
62 | the cluster stack in use. The contents may change | ||
63 | when all filesystems are unmounted and the cluster stack | ||
64 | is changed. | ||
65 | |||
66 | What: /sys/fs/ocfs2/cluster_stack | ||
67 | Date: April 2008 | ||
68 | Contact: ocfs2-devel@oss.oracle.com | ||
69 | Description: | ||
70 | The /sys/fs/ocfs2/cluster_stack file contains the name | ||
71 | of current ocfs2 cluster stack. This value is set by | ||
72 | userspace tools when bringing the cluster stack online. | ||
73 | |||
74 | Cluster stack names are 4 characters in length. | ||
75 | |||
76 | When the 'o2cb' cluster stack is used, the 'o2cb' cluster | ||
77 | plugin is active. All other cluster stacks use the 'user' | ||
78 | cluster plugin. | ||
79 | |||
80 | Reading from this file returns the name of the current | ||
81 | cluster stack on a single line. | ||
82 | |||
83 | Writing a new stack name to this file changes the current | ||
84 | cluster stack unless there are mounted ocfs2 filesystems. | ||
85 | If there are mounted filesystems, attempts to change the | ||
86 | stack return an error. | ||
87 | |||
88 | Users: | ||
89 | ocfs2-tools <ocfs2-tools-devel@oss.oracle.com> | ||
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index 300e1707893f..e471bc466a7e 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile | |||
@@ -9,7 +9,7 @@ | |||
9 | DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \ | 9 | DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \ |
10 | kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ | 10 | kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ |
11 | procfs-guide.xml writing_usb_driver.xml networking.xml \ | 11 | procfs-guide.xml writing_usb_driver.xml networking.xml \ |
12 | kernel-api.xml filesystems.xml lsm.xml usb.xml \ | 12 | kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \ |
13 | gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ | 13 | gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ |
14 | genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml | 14 | genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml |
15 | 15 | ||
diff --git a/Documentation/DocBook/kgdb.tmpl b/Documentation/DocBook/kgdb.tmpl new file mode 100644 index 000000000000..97618bed4d65 --- /dev/null +++ b/Documentation/DocBook/kgdb.tmpl | |||
@@ -0,0 +1,447 @@ | |||
1 | <?xml version="1.0" encoding="UTF-8"?> | ||
2 | <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" | ||
3 | "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> | ||
4 | |||
5 | <book id="kgdbOnLinux"> | ||
6 | <bookinfo> | ||
7 | <title>Using kgdb and the kgdb Internals</title> | ||
8 | |||
9 | <authorgroup> | ||
10 | <author> | ||
11 | <firstname>Jason</firstname> | ||
12 | <surname>Wessel</surname> | ||
13 | <affiliation> | ||
14 | <address> | ||
15 | <email>jason.wessel@windriver.com</email> | ||
16 | </address> | ||
17 | </affiliation> | ||
18 | </author> | ||
19 | </authorgroup> | ||
20 | |||
21 | <authorgroup> | ||
22 | <author> | ||
23 | <firstname>Tom</firstname> | ||
24 | <surname>Rini</surname> | ||
25 | <affiliation> | ||
26 | <address> | ||
27 | <email>trini@kernel.crashing.org</email> | ||
28 | </address> | ||
29 | </affiliation> | ||
30 | </author> | ||
31 | </authorgroup> | ||
32 | |||
33 | <authorgroup> | ||
34 | <author> | ||
35 | <firstname>Amit S.</firstname> | ||
36 | <surname>Kale</surname> | ||
37 | <affiliation> | ||
38 | <address> | ||
39 | <email>amitkale@linsyssoft.com</email> | ||
40 | </address> | ||
41 | </affiliation> | ||
42 | </author> | ||
43 | </authorgroup> | ||
44 | |||
45 | <copyright> | ||
46 | <year>2008</year> | ||
47 | <holder>Wind River Systems, Inc.</holder> | ||
48 | </copyright> | ||
49 | <copyright> | ||
50 | <year>2004-2005</year> | ||
51 | <holder>MontaVista Software, Inc.</holder> | ||
52 | </copyright> | ||
53 | <copyright> | ||
54 | <year>2004</year> | ||
55 | <holder>Amit S. Kale</holder> | ||
56 | </copyright> | ||
57 | |||
58 | <legalnotice> | ||
59 | <para> | ||
60 | This file is licensed under the terms of the GNU General Public License | ||
61 | version 2. This program is licensed "as is" without any warranty of any | ||
62 | kind, whether express or implied. | ||
63 | </para> | ||
64 | |||
65 | </legalnotice> | ||
66 | </bookinfo> | ||
67 | |||
68 | <toc></toc> | ||
69 | <chapter id="Introduction"> | ||
70 | <title>Introduction</title> | ||
71 | <para> | ||
72 | kgdb is a source level debugger for linux kernel. It is used along | ||
73 | with gdb to debug a linux kernel. The expectation is that gdb can | ||
74 | be used to "break in" to the kernel to inspect memory, variables | ||
75 | and look through a cal stack information similar to what an | ||
76 | application developer would use gdb for. It is possible to place | ||
77 | breakpoints in kernel code and perform some limited execution | ||
78 | stepping. | ||
79 | </para> | ||
80 | <para> | ||
81 | Two machines are required for using kgdb. One of these machines is a | ||
82 | development machine and the other is a test machine. The kernel | ||
83 | to be debugged runs on the test machine. The development machine | ||
84 | runs an instance of gdb against the vmlinux file which contains | ||
85 | the symbols (not boot image such as bzImage, zImage, uImage...). | ||
86 | In gdb the developer specifies the connection parameters and | ||
87 | connects to kgdb. Depending on which kgdb I/O modules exist in | ||
88 | the kernel for a given architecture, it may be possible to debug | ||
89 | the test machine's kernel with the development machine using a | ||
90 | rs232 or ethernet connection. | ||
91 | </para> | ||
92 | </chapter> | ||
93 | <chapter id="CompilingAKernel"> | ||
94 | <title>Compiling a kernel</title> | ||
95 | <para> | ||
96 | To enable <symbol>CONFIG_KGDB</symbol>, look under the "Kernel debugging" | ||
97 | and then select "KGDB: kernel debugging with remote gdb". | ||
98 | </para> | ||
99 | <para> | ||
100 | Next you should choose one of more I/O drivers to interconnect debugging | ||
101 | host and debugged target. Early boot debugging requires a KGDB | ||
102 | I/O driver that supports early debugging and the driver must be | ||
103 | built into the kernel directly. Kgdb I/O driver configuration | ||
104 | takes place via kernel or module parameters, see following | ||
105 | chapter. | ||
106 | </para> | ||
107 | <para> | ||
108 | The kgdb test compile options are described in the kgdb test suite chapter. | ||
109 | </para> | ||
110 | |||
111 | </chapter> | ||
112 | <chapter id="EnableKGDB"> | ||
113 | <title>Enable kgdb for debugging</title> | ||
114 | <para> | ||
115 | In order to use kgdb you must activate it by passing configuration | ||
116 | information to one of the kgdb I/O drivers. If you do not pass any | ||
117 | configuration information kgdb will not do anything at all. Kgdb | ||
118 | will only actively hook up to the kernel trap hooks if a kgdb I/O | ||
119 | driver is loaded and configured. If you unconfigure a kgdb I/O | ||
120 | driver, kgdb will unregister all the kernel hook points. | ||
121 | </para> | ||
122 | <para> | ||
123 | All drivers can be reconfigured at run time, if | ||
124 | <symbol>CONFIG_SYSFS</symbol> and <symbol>CONFIG_MODULES</symbol> | ||
125 | are enabled, by echo'ing a new config string to | ||
126 | <constant>/sys/module/<driver>/parameter/<option></constant>. | ||
127 | The driver can be unconfigured by passing an empty string. You cannot | ||
128 | change the configuration while the debugger is attached. Make sure | ||
129 | to detach the debugger with the <constant>detach</constant> command | ||
130 | prior to trying unconfigure a kgdb I/O driver. | ||
131 | </para> | ||
132 | <sect1 id="kgdbwait"> | ||
133 | <title>Kernel parameter: kgdbwait</title> | ||
134 | <para> | ||
135 | The Kernel command line option <constant>kgdbwait</constant> makes | ||
136 | kgdb wait for a debugger connection during booting of a kernel. You | ||
137 | can only use this option you compiled a kgdb I/O driver into the | ||
138 | kernel and you specified the I/O driver configuration as a kernel | ||
139 | command line option. The kgdbwait parameter should always follow the | ||
140 | configuration parameter for the kgdb I/O driver in the kernel | ||
141 | command line else the I/O driver will not be configured prior to | ||
142 | asking the kernel to use it to wait. | ||
143 | </para> | ||
144 | <para> | ||
145 | The kernel will stop and wait as early as the I/O driver and | ||
146 | architecture will allow when you use this option. If you build the | ||
147 | kgdb I/O driver as a kernel module kgdbwait will not do anything. | ||
148 | </para> | ||
149 | </sect1> | ||
150 | <sect1 id="kgdboc"> | ||
151 | <title>Kernel parameter: kgdboc</title> | ||
152 | <para> | ||
153 | The kgdboc driver was originally an abbreviation meant to stand for | ||
154 | "kgdb over console". Kgdboc is designed to work with a single | ||
155 | serial port. It was meant to cover the circumstance | ||
156 | where you wanted to use a serial console as your primary console as | ||
157 | well as using it to perform kernel debugging. Of course you can | ||
158 | also use kgdboc without assigning a console to the same port. | ||
159 | </para> | ||
160 | <sect2 id="UsingKgdboc"> | ||
161 | <title>Using kgdboc</title> | ||
162 | <para> | ||
163 | You can configure kgdboc via sysfs or a module or kernel boot line | ||
164 | parameter depending on if you build with CONFIG_KGDBOC as a module | ||
165 | or built-in. | ||
166 | <orderedlist> | ||
167 | <listitem><para>From the module load or build-in</para> | ||
168 | <para><constant>kgdboc=<tty-device>,[baud]</constant></para> | ||
169 | <para> | ||
170 | The example here would be if your console port was typically ttyS0, you would use something like <constant>kgdboc=ttyS0,115200</constant> or on the ARM Versatile AB you would likely use <constant>kgdboc=ttyAMA0,115200</constant> | ||
171 | </para> | ||
172 | </listitem> | ||
173 | <listitem><para>From sysfs</para> | ||
174 | <para><constant>echo ttyS0 > /sys/module/kgdboc/parameters/kgdboc</constant></para> | ||
175 | </listitem> | ||
176 | </orderedlist> | ||
177 | </para> | ||
178 | <para> | ||
179 | NOTE: Kgdboc does not support interrupting the target via the | ||
180 | gdb remote protocol. You must manually send a sysrq-g unless you | ||
181 | have a proxy that splits console output to a terminal problem and | ||
182 | has a separate port for the debugger to connect to that sends the | ||
183 | sysrq-g for you. | ||
184 | </para> | ||
185 | <para>When using kgdboc with no debugger proxy, you can end up | ||
186 | connecting the debugger for one of two entry points. If an | ||
187 | exception occurs after you have loaded kgdboc a message should print | ||
188 | on the console stating it is waiting for the debugger. In case you | ||
189 | disconnect your terminal program and then connect the debugger in | ||
190 | its place. If you want to interrupt the target system and forcibly | ||
191 | enter a debug session you have to issue a Sysrq sequence and then | ||
192 | type the letter <constant>g</constant>. Then you disconnect the | ||
193 | terminal session and connect gdb. Your options if you don't like | ||
194 | this are to hack gdb to send the sysrq-g for you as well as on the | ||
195 | initial connect, or to use a debugger proxy that allows an | ||
196 | unmodified gdb to do the debugging. | ||
197 | </para> | ||
198 | </sect2> | ||
199 | </sect1> | ||
200 | <sect1 id="kgdbcon"> | ||
201 | <title>Kernel parameter: kgdbcon</title> | ||
202 | <para> | ||
203 | Kgdb supports using the gdb serial protocol to send console messages | ||
204 | to the debugger when the debugger is connected and running. There | ||
205 | are two ways to activate this feature. | ||
206 | <orderedlist> | ||
207 | <listitem><para>Activate with the kernel command line option:</para> | ||
208 | <para><constant>kgdbcon</constant></para> | ||
209 | </listitem> | ||
210 | <listitem><para>Use sysfs before configuring an io driver</para> | ||
211 | <para> | ||
212 | <constant>echo 1 > /sys/module/kgdb/parameters/kgdb_use_con</constant> | ||
213 | </para> | ||
214 | <para> | ||
215 | NOTE: If you do this after you configure the kgdb I/O driver, the | ||
216 | setting will not take effect until the next point the I/O is | ||
217 | reconfigured. | ||
218 | </para> | ||
219 | </listitem> | ||
220 | </orderedlist> | ||
221 | </para> | ||
222 | <para> | ||
223 | IMPORTANT NOTE: Using this option with kgdb over the console | ||
224 | (kgdboc) or kgdb over ethernet (kgdboe) is not supported. | ||
225 | </para> | ||
226 | </sect1> | ||
227 | </chapter> | ||
228 | <chapter id="ConnectingGDB"> | ||
229 | <title>Connecting gdb</title> | ||
230 | <para> | ||
231 | If you are using kgdboc, you need to have used kgdbwait as a boot | ||
232 | argument, issued a sysrq-g, or the system you are going to debug | ||
233 | has already taken an exception and is waiting for the debugger to | ||
234 | attach before you can connect gdb. | ||
235 | </para> | ||
236 | <para> | ||
237 | If you are not using different kgdb I/O driver other than kgdboc, | ||
238 | you should be able to connect and the target will automatically | ||
239 | respond. | ||
240 | </para> | ||
241 | <para> | ||
242 | Example (using a serial port): | ||
243 | </para> | ||
244 | <programlisting> | ||
245 | % gdb ./vmlinux | ||
246 | (gdb) set remotebaud 115200 | ||
247 | (gdb) target remote /dev/ttyS0 | ||
248 | </programlisting> | ||
249 | <para> | ||
250 | Example (kgdb to a terminal server): | ||
251 | </para> | ||
252 | <programlisting> | ||
253 | % gdb ./vmlinux | ||
254 | (gdb) target remote udp:192.168.2.2:6443 | ||
255 | </programlisting> | ||
256 | <para> | ||
257 | Example (kgdb over ethernet): | ||
258 | </para> | ||
259 | <programlisting> | ||
260 | % gdb ./vmlinux | ||
261 | (gdb) target remote udp:192.168.2.2:6443 | ||
262 | </programlisting> | ||
263 | <para> | ||
264 | Once connected, you can debug a kernel the way you would debug an | ||
265 | application program. | ||
266 | </para> | ||
267 | <para> | ||
268 | If you are having problems connecting or something is going | ||
269 | seriously wrong while debugging, it will most often be the case | ||
270 | that you want to enable gdb to be verbose about its target | ||
271 | communications. You do this prior to issuing the <constant>target | ||
272 | remote</constant> command by typing in: <constant>set remote debug 1</constant> | ||
273 | </para> | ||
274 | </chapter> | ||
275 | <chapter id="KGDBTestSuite"> | ||
276 | <title>kgdb Test Suite</title> | ||
277 | <para> | ||
278 | When kgdb is enabled in the kernel config you can also elect to | ||
279 | enable the config parameter KGDB_TESTS. Turning this on will | ||
280 | enable a special kgdb I/O module which is designed to test the | ||
281 | kgdb internal functions. | ||
282 | </para> | ||
283 | <para> | ||
284 | The kgdb tests are mainly intended for developers to test the kgdb | ||
285 | internals as well as a tool for developing a new kgdb architecture | ||
286 | specific implementation. These tests are not really for end users | ||
287 | of the Linux kernel. The primary source of documentation would be | ||
288 | to look in the drivers/misc/kgdbts.c file. | ||
289 | </para> | ||
290 | <para> | ||
291 | The kgdb test suite can also be configured at compile time to run | ||
292 | the core set of tests by setting the kernel config parameter | ||
293 | KGDB_TESTS_ON_BOOT. This particular option is aimed at automated | ||
294 | regression testing and does not require modifying the kernel boot | ||
295 | config arguments. If this is turned on, the kgdb test suite can | ||
296 | be disabled by specifying "kgdbts=" as a kernel boot argument. | ||
297 | </para> | ||
298 | </chapter> | ||
299 | <chapter id="CommonBackEndReq"> | ||
300 | <title>KGDB Internals</title> | ||
301 | <sect1 id="kgdbArchitecture"> | ||
302 | <title>Architecture Specifics</title> | ||
303 | <para> | ||
304 | Kgdb is organized into three basic components: | ||
305 | <orderedlist> | ||
306 | <listitem><para>kgdb core</para> | ||
307 | <para> | ||
308 | The kgdb core is found in kernel/kgdb.c. It contains: | ||
309 | <itemizedlist> | ||
310 | <listitem><para>All the logic to implement the gdb serial protocol</para></listitem> | ||
311 | <listitem><para>A generic OS exception handler which includes sync'ing the processors into a stopped state on an multi cpu system.</para></listitem> | ||
312 | <listitem><para>The API to talk to the kgdb I/O drivers</para></listitem> | ||
313 | <listitem><para>The API to make calls to the arch specific kgdb implementation</para></listitem> | ||
314 | <listitem><para>The logic to perform safe memory reads and writes to memory while using the debugger</para></listitem> | ||
315 | <listitem><para>A full implementation for software breakpoints unless overridden by the arch</para></listitem> | ||
316 | </itemizedlist> | ||
317 | </para> | ||
318 | </listitem> | ||
319 | <listitem><para>kgdb arch specific implementation</para> | ||
320 | <para> | ||
321 | This implementation is generally found in arch/*/kernel/kgdb.c. | ||
322 | As an example, arch/x86/kernel/kgdb.c contains the specifics to | ||
323 | implement HW breakpoint as well as the initialization to | ||
324 | dynamically register and unregister for the trap handlers on | ||
325 | this architecture. The arch specific portion implements: | ||
326 | <itemizedlist> | ||
327 | <listitem><para>contains an arch specific trap catcher which | ||
328 | invokes kgdb_handle_exception() to start kgdb about doing its | ||
329 | work</para></listitem> | ||
330 | <listitem><para>translation to and from gdb specific packet format to pt_regs</para></listitem> | ||
331 | <listitem><para>Registration and unregistration of architecture specific trap hooks</para></listitem> | ||
332 | <listitem><para>Any special exception handling and cleanup</para></listitem> | ||
333 | <listitem><para>NMI exception handling and cleanup</para></listitem> | ||
334 | <listitem><para>(optional)HW breakpoints</para></listitem> | ||
335 | </itemizedlist> | ||
336 | </para> | ||
337 | </listitem> | ||
338 | <listitem><para>kgdb I/O driver</para> | ||
339 | <para> | ||
340 | Each kgdb I/O driver has to provide an implemenation for the following: | ||
341 | <itemizedlist> | ||
342 | <listitem><para>configuration via builtin or module</para></listitem> | ||
343 | <listitem><para>dynamic configuration and kgdb hook registration calls</para></listitem> | ||
344 | <listitem><para>read and write character interface</para></listitem> | ||
345 | <listitem><para>A cleanup handler for unconfiguring from the kgdb core</para></listitem> | ||
346 | <listitem><para>(optional) Early debug methodology</para></listitem> | ||
347 | </itemizedlist> | ||
348 | Any given kgdb I/O driver has to operate very closely with the | ||
349 | hardware and must do it in such a way that does not enable | ||
350 | interrupts or change other parts of the system context without | ||
351 | completely restoring them. The kgdb core will repeatedly "poll" | ||
352 | a kgdb I/O driver for characters when it needs input. The I/O | ||
353 | driver is expected to return immediately if there is no data | ||
354 | available. Doing so allows for the future possibility to touch | ||
355 | watch dog hardware in such a way as to have a target system not | ||
356 | reset when these are enabled. | ||
357 | </para> | ||
358 | </listitem> | ||
359 | </orderedlist> | ||
360 | </para> | ||
361 | <para> | ||
362 | If you are intent on adding kgdb architecture specific support | ||
363 | for a new architecture, the architecture should define | ||
364 | <constant>HAVE_ARCH_KGDB</constant> in the architecture specific | ||
365 | Kconfig file. This will enable kgdb for the architecture, and | ||
366 | at that point you must create an architecture specific kgdb | ||
367 | implementation. | ||
368 | </para> | ||
369 | <para> | ||
370 | There are a few flags which must be set on every architecture in | ||
371 | their <asm/kgdb.h> file. These are: | ||
372 | <itemizedlist> | ||
373 | <listitem> | ||
374 | <para> | ||
375 | NUMREGBYTES: The size in bytes of all of the registers, so | ||
376 | that we can ensure they will all fit into a packet. | ||
377 | </para> | ||
378 | <para> | ||
379 | BUFMAX: The size in bytes of the buffer GDB will read into. | ||
380 | This must be larger than NUMREGBYTES. | ||
381 | </para> | ||
382 | <para> | ||
383 | CACHE_FLUSH_IS_SAFE: Set to 1 if it is always safe to call | ||
384 | flush_cache_range or flush_icache_range. On some architectures, | ||
385 | these functions may not be safe to call on SMP since we keep other | ||
386 | CPUs in a holding pattern. | ||
387 | </para> | ||
388 | </listitem> | ||
389 | </itemizedlist> | ||
390 | </para> | ||
391 | <para> | ||
392 | There are also the following functions for the common backend, | ||
393 | found in kernel/kgdb.c, that must be supplied by the | ||
394 | architecture-specific backend unless marked as (optional), in | ||
395 | which case a default function maybe used if the architecture | ||
396 | does not need to provide a specific implementation. | ||
397 | </para> | ||
398 | !Iinclude/linux/kgdb.h | ||
399 | </sect1> | ||
400 | <sect1 id="kgdbocDesign"> | ||
401 | <title>kgdboc internals</title> | ||
402 | <para> | ||
403 | The kgdboc driver is actually a very thin driver that relies on the | ||
404 | underlying low level to the hardware driver having "polling hooks" | ||
405 | which the to which the tty driver is attached. In the initial | ||
406 | implementation of kgdboc it the serial_core was changed to expose a | ||
407 | low level uart hook for doing polled mode reading and writing of a | ||
408 | single character while in an atomic context. When kgdb makes an I/O | ||
409 | request to the debugger, kgdboc invokes a call back in the serial | ||
410 | core which in turn uses the call back in the uart driver. It is | ||
411 | certainly possible to extend kgdboc to work with non-uart based | ||
412 | consoles in the future. | ||
413 | </para> | ||
414 | <para> | ||
415 | When using kgdboc with a uart, the uart driver must implement two callbacks in the <constant>struct uart_ops</constant>. Example from drivers/8250.c:<programlisting> | ||
416 | #ifdef CONFIG_CONSOLE_POLL | ||
417 | .poll_get_char = serial8250_get_poll_char, | ||
418 | .poll_put_char = serial8250_put_poll_char, | ||
419 | #endif | ||
420 | </programlisting> | ||
421 | Any implementation specifics around creating a polling driver use the | ||
422 | <constant>#ifdef CONFIG_CONSOLE_POLL</constant>, as shown above. | ||
423 | Keep in mind that polling hooks have to be implemented in such a way | ||
424 | that they can be called from an atomic context and have to restore | ||
425 | the state of the uart chip on return such that the system can return | ||
426 | to normal when the debugger detaches. You need to be very careful | ||
427 | with any kind of lock you consider, because failing here is most | ||
428 | going to mean pressing the reset button. | ||
429 | </para> | ||
430 | </sect1> | ||
431 | </chapter> | ||
432 | <chapter id="credits"> | ||
433 | <title>Credits</title> | ||
434 | <para> | ||
435 | The following people have contributed to this document: | ||
436 | <orderedlist> | ||
437 | <listitem><para>Amit Kale<email>amitkale@linsyssoft.com</email></para></listitem> | ||
438 | <listitem><para>Tom Rini<email>trini@kernel.crashing.org</email></para></listitem> | ||
439 | </orderedlist> | ||
440 | In March 2008 this document was completely rewritten by: | ||
441 | <itemizedlist> | ||
442 | <listitem><para>Jason Wessel<email>jason.wessel@windriver.com</email></para></listitem> | ||
443 | </itemizedlist> | ||
444 | </para> | ||
445 | </chapter> | ||
446 | </book> | ||
447 | |||
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index bf0e3df8e7a1..4b70622a8a91 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt | |||
@@ -212,7 +212,7 @@ Who: Stephen Hemminger <shemminger@linux-foundation.org> | |||
212 | --------------------------- | 212 | --------------------------- |
213 | 213 | ||
214 | What: i386/x86_64 bzImage symlinks | 214 | What: i386/x86_64 bzImage symlinks |
215 | When: April 2008 | 215 | When: April 2010 |
216 | 216 | ||
217 | Why: The i386/x86_64 merge provides a symlink to the old bzImage | 217 | Why: The i386/x86_64 merge provides a symlink to the old bzImage |
218 | location so not yet updated user space tools, e.g. package | 218 | location so not yet updated user space tools, e.g. package |
@@ -318,3 +318,13 @@ Why: Not used in-tree. The current out-of-tree users used it to | |||
318 | code / infrastructure should be in the kernel and not in some | 318 | code / infrastructure should be in the kernel and not in some |
319 | out-of-tree driver. | 319 | out-of-tree driver. |
320 | Who: Thomas Gleixner <tglx@linutronix.de> | 320 | Who: Thomas Gleixner <tglx@linutronix.de> |
321 | |||
322 | --------------------------- | ||
323 | |||
324 | What: /sys/o2cb symlink | ||
325 | When: January 2010 | ||
326 | Why: /sys/fs/o2cb is the proper location for this information - /sys/o2cb | ||
327 | exists as a symlink for backwards compatibility for old versions of | ||
328 | ocfs2-tools. 2 years should be sufficient time to phase in new versions | ||
329 | which know to look in /sys/fs/o2cb. | ||
330 | Who: ocfs2-devel@oss.oracle.com | ||
diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt index 74aeb142ae5f..0a1668ba2600 100644 --- a/Documentation/filesystems/xfs.txt +++ b/Documentation/filesystems/xfs.txt | |||
@@ -52,16 +52,15 @@ When mounting an XFS filesystem, the following options are accepted. | |||
52 | and also gets the setgid bit set if it is a directory itself. | 52 | and also gets the setgid bit set if it is a directory itself. |
53 | 53 | ||
54 | ihashsize=value | 54 | ihashsize=value |
55 | Sets the number of hash buckets available for hashing the | 55 | In memory inode hashes have been removed, so this option has |
56 | in-memory inodes of the specified mount point. If a value | 56 | no function as of August 2007. Option is deprecated. |
57 | of zero is used, the value selected by the default algorithm | ||
58 | will be displayed in /proc/mounts. | ||
59 | 57 | ||
60 | ikeep/noikeep | 58 | ikeep/noikeep |
61 | When inode clusters are emptied of inodes, keep them around | 59 | When ikeep is specified, XFS does not delete empty inode clusters |
62 | on the disk (ikeep) - this is the traditional XFS behaviour | 60 | and keeps them around on disk. ikeep is the traditional XFS |
63 | and is still the default for now. Using the noikeep option, | 61 | behaviour. When noikeep is specified, empty inode clusters |
64 | inode clusters are returned to the free space pool. | 62 | are returned to the free space pool. The default is noikeep for |
63 | non-DMAPI mounts, while ikeep is the default when DMAPI is in use. | ||
65 | 64 | ||
66 | inode64 | 65 | inode64 |
67 | Indicates that XFS is allowed to create inodes at any location | 66 | Indicates that XFS is allowed to create inodes at any location |
diff --git a/Documentation/i386/boot.txt b/Documentation/i386/boot.txt index fc49b79bc1ab..2eb16100bb3f 100644 --- a/Documentation/i386/boot.txt +++ b/Documentation/i386/boot.txt | |||
@@ -170,6 +170,8 @@ Offset Proto Name Meaning | |||
170 | 0238/4 2.06+ cmdline_size Maximum size of the kernel command line | 170 | 0238/4 2.06+ cmdline_size Maximum size of the kernel command line |
171 | 023C/4 2.07+ hardware_subarch Hardware subarchitecture | 171 | 023C/4 2.07+ hardware_subarch Hardware subarchitecture |
172 | 0240/8 2.07+ hardware_subarch_data Subarchitecture-specific data | 172 | 0240/8 2.07+ hardware_subarch_data Subarchitecture-specific data |
173 | 0248/4 2.08+ payload_offset Offset of kernel payload | ||
174 | 024C/4 2.08+ payload_length Length of kernel payload | ||
173 | 175 | ||
174 | (1) For backwards compatibility, if the setup_sects field contains 0, the | 176 | (1) For backwards compatibility, if the setup_sects field contains 0, the |
175 | real value is 4. | 177 | real value is 4. |
@@ -512,6 +514,32 @@ Protocol: 2.07+ | |||
512 | 514 | ||
513 | A pointer to data that is specific to hardware subarch | 515 | A pointer to data that is specific to hardware subarch |
514 | 516 | ||
517 | Field name: payload_offset | ||
518 | Type: read | ||
519 | Offset/size: 0x248/4 | ||
520 | Protocol: 2.08+ | ||
521 | |||
522 | If non-zero then this field contains the offset from the end of the | ||
523 | real-mode code to the payload. | ||
524 | |||
525 | The payload may be compressed. The format of both the compressed and | ||
526 | uncompressed data should be determined using the standard magic | ||
527 | numbers. Currently only gzip compressed ELF is used. | ||
528 | |||
529 | Field name: payload_length | ||
530 | Type: read | ||
531 | Offset/size: 0x24c/4 | ||
532 | Protocol: 2.08+ | ||
533 | |||
534 | The length of the payload. | ||
535 | |||
536 | **** THE IMAGE CHECKSUM | ||
537 | |||
538 | From boot protocol version 2.08 onwards the CRC-32 is calculated over | ||
539 | the entire file using the characteristic polynomial 0x04C11DB7 and an | ||
540 | initial remainder of 0xffffffff. The checksum is appended to the | ||
541 | file; therefore the CRC of the file up to the limit specified in the | ||
542 | syssize field of the header is always 0. | ||
515 | 543 | ||
516 | **** THE KERNEL COMMAND LINE | 544 | **** THE KERNEL COMMAND LINE |
517 | 545 | ||
diff --git a/Documentation/ide/ide.txt b/Documentation/ide/ide.txt index 818676aad45a..486c699f4aea 100644 --- a/Documentation/ide/ide.txt +++ b/Documentation/ide/ide.txt | |||
@@ -71,29 +71,6 @@ This driver automatically probes for most IDE interfaces (including all PCI | |||
71 | ones), for the drives/geometries attached to those interfaces, and for the IRQ | 71 | ones), for the drives/geometries attached to those interfaces, and for the IRQ |
72 | lines being used by the interfaces (normally 14, 15 for ide0/ide1). | 72 | lines being used by the interfaces (normally 14, 15 for ide0/ide1). |
73 | 73 | ||
74 | For special cases, interfaces may be specified using kernel "command line" | ||
75 | options. For example, | ||
76 | |||
77 | ide3=0x168,0x36e,10 /* ioports 0x168-0x16f,0x36e, irq 10 */ | ||
78 | |||
79 | Normally the irq number need not be specified, as ide.c will probe for it: | ||
80 | |||
81 | ide3=0x168,0x36e /* ioports 0x168-0x16f,0x36e */ | ||
82 | |||
83 | The standard port, and irq values are these: | ||
84 | |||
85 | ide0=0x1f0,0x3f6,14 | ||
86 | ide1=0x170,0x376,15 | ||
87 | ide2=0x1e8,0x3ee,11 | ||
88 | ide3=0x168,0x36e,10 | ||
89 | |||
90 | Note that the first parameter reserves 8 contiguous ioports, whereas the | ||
91 | second value denotes a single ioport. If in doubt, do a 'cat /proc/ioports'. | ||
92 | |||
93 | In all probability the device uses these ports and IRQs if it is attached | ||
94 | to the appropriate ide channel. Pass the parameter for the correct ide | ||
95 | channel to the kernel, as explained above. | ||
96 | |||
97 | Any number of interfaces may share a single IRQ if necessary, at a slight | 74 | Any number of interfaces may share a single IRQ if necessary, at a slight |
98 | performance penalty, whether on separate cards or a single VLB card. | 75 | performance penalty, whether on separate cards or a single VLB card. |
99 | The IDE driver automatically detects and handles this. However, this may | 76 | The IDE driver automatically detects and handles this. However, this may |
@@ -184,13 +161,6 @@ provided it is mounted with the default block size of 1024 (as above). | |||
184 | Please pass on any feedback on any of this stuff to the maintainer, | 161 | Please pass on any feedback on any of this stuff to the maintainer, |
185 | whose address can be found in linux/MAINTAINERS. | 162 | whose address can be found in linux/MAINTAINERS. |
186 | 163 | ||
187 | Note that if BOTH hd.c and ide.c are configured into the kernel, | ||
188 | hd.c will normally be allowed to control the primary IDE interface. | ||
189 | This is useful for older hardware that may be incompatible with ide.c, | ||
190 | and still allows newer hardware to run on the 2nd/3rd/4th IDE ports | ||
191 | under control of ide.c. To have ide.c also "take over" the primary | ||
192 | IDE port in this situation, use the "command line" parameter: ide0=0x1f0 | ||
193 | |||
194 | The IDE driver is modularized. The high level disk/CD-ROM/tape/floppy | 164 | The IDE driver is modularized. The high level disk/CD-ROM/tape/floppy |
195 | drivers can always be compiled as loadable modules, the chipset drivers | 165 | drivers can always be compiled as loadable modules, the chipset drivers |
196 | can only be compiled into the kernel, and the core code (ide.c) can be | 166 | can only be compiled into the kernel, and the core code (ide.c) can be |
@@ -206,7 +176,7 @@ When ide.c is used as a module, you can pass command line parameters to the | |||
206 | driver using the "options=" keyword to insmod, while replacing any ',' with | 176 | driver using the "options=" keyword to insmod, while replacing any ',' with |
207 | ';'. For example: | 177 | ';'. For example: |
208 | 178 | ||
209 | insmod ide.o options="ide0=serialize ide1=serialize ide2=0x1e8;0x3ee;11" | 179 | insmod ide.o options="hda=nodma hdb=nodma" |
210 | 180 | ||
211 | 181 | ||
212 | ================================================================================ | 182 | ================================================================================ |
@@ -247,21 +217,11 @@ Summary of ide driver parameters for kernel command line | |||
247 | As for VLB, it is safest to not specify it. | 217 | As for VLB, it is safest to not specify it. |
248 | Bigger values are safer than smaller ones. | 218 | Bigger values are safer than smaller ones. |
249 | 219 | ||
250 | "idex=base" : probe for an interface at the addr specified, | ||
251 | where "base" is usually 0x1f0 or 0x170 | ||
252 | and "ctl" is assumed to be "base"+0x206 | ||
253 | |||
254 | "idex=base,ctl" : specify both base and ctl | ||
255 | |||
256 | "idex=base,ctl,irq" : specify base, ctl, and irq number | ||
257 | |||
258 | "idex=serialize" : do not overlap operations on idex. Please note | 220 | "idex=serialize" : do not overlap operations on idex. Please note |
259 | that you will have to specify this option for | 221 | that you will have to specify this option for |
260 | both the respective primary and secondary channel | 222 | both the respective primary and secondary channel |
261 | to take effect. | 223 | to take effect. |
262 | 224 | ||
263 | "idex=four" : four drives on idex and ide(x^1) share same ports | ||
264 | |||
265 | "idex=reset" : reset interface after probe | 225 | "idex=reset" : reset interface after probe |
266 | 226 | ||
267 | "idex=ata66" : informs the interface that it has an 80c cable | 227 | "idex=ata66" : informs the interface that it has an 80c cable |
@@ -269,8 +229,6 @@ Summary of ide driver parameters for kernel command line | |||
269 | ability to bit test for detection is currently | 229 | ability to bit test for detection is currently |
270 | unknown. | 230 | unknown. |
271 | 231 | ||
272 | "ide=reverse" : formerly called to pci sub-system, but now local. | ||
273 | |||
274 | "ide=doubler" : probe/support IDE doublers on Amiga | 232 | "ide=doubler" : probe/support IDE doublers on Amiga |
275 | 233 | ||
276 | There may be more options than shown -- use the source, Luke! | 234 | There may be more options than shown -- use the source, Luke! |
@@ -290,6 +248,9 @@ Also for legacy CMD640 host driver (cmd640) you need to use "probe_vlb" | |||
290 | kernel paremeter to enable probing for VLB version of the chipset (PCI ones | 248 | kernel paremeter to enable probing for VLB version of the chipset (PCI ones |
291 | are detected automatically). | 249 | are detected automatically). |
292 | 250 | ||
251 | You also need to use "probe" kernel parameter for ide-4drives driver | ||
252 | (support for IDE generic chipset with four drives on one port). | ||
253 | |||
293 | ================================================================================ | 254 | ================================================================================ |
294 | 255 | ||
295 | Some Terminology | 256 | Some Terminology |
diff --git a/Documentation/ide/warm-plug-howto.txt b/Documentation/ide/warm-plug-howto.txt new file mode 100644 index 000000000000..d5885468b072 --- /dev/null +++ b/Documentation/ide/warm-plug-howto.txt | |||
@@ -0,0 +1,13 @@ | |||
1 | |||
2 | IDE warm-plug HOWTO | ||
3 | =================== | ||
4 | |||
5 | To warm-plug devices on a port 'idex': | ||
6 | |||
7 | # echo -n "1" > /sys/class/ide_port/idex/delete_devices | ||
8 | |||
9 | unplug old device(s) and plug new device(s) | ||
10 | |||
11 | # echo -n "1" > /sys/class/ide_port/idex/scan | ||
12 | |||
13 | done | ||
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index dafd001bf833..256a2162503c 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt | |||
@@ -763,11 +763,11 @@ and is between 256 and 4096 characters. It is defined in the file | |||
763 | Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]] | 763 | Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]] |
764 | 764 | ||
765 | ide= [HW] (E)IDE subsystem | 765 | ide= [HW] (E)IDE subsystem |
766 | Format: ide=nodma or ide=doubler or ide=reverse | 766 | Format: ide=nodma or ide=doubler |
767 | See Documentation/ide/ide.txt. | 767 | See Documentation/ide/ide.txt. |
768 | 768 | ||
769 | ide?= [HW] (E)IDE subsystem | 769 | ide?= [HW] (E)IDE subsystem |
770 | Format: ide?=noprobe or chipset specific parameters. | 770 | Format: ide?=ata66 or chipset specific parameters. |
771 | See Documentation/ide/ide.txt. | 771 | See Documentation/ide/ide.txt. |
772 | 772 | ||
773 | idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed | 773 | idebus= [HW] (E)IDE subsystem - VLB/PCI bus speed |
@@ -812,6 +812,19 @@ and is between 256 and 4096 characters. It is defined in the file | |||
812 | 812 | ||
813 | inttest= [IA64] | 813 | inttest= [IA64] |
814 | 814 | ||
815 | iommu= [x86] | ||
816 | off | ||
817 | force | ||
818 | noforce | ||
819 | biomerge | ||
820 | panic | ||
821 | nopanic | ||
822 | merge | ||
823 | nomerge | ||
824 | forcesac | ||
825 | soft | ||
826 | |||
827 | |||
815 | intel_iommu= [DMAR] Intel IOMMU driver (DMAR) option | 828 | intel_iommu= [DMAR] Intel IOMMU driver (DMAR) option |
816 | off | 829 | off |
817 | Disable intel iommu driver. | 830 | Disable intel iommu driver. |
@@ -928,6 +941,11 @@ and is between 256 and 4096 characters. It is defined in the file | |||
928 | kstack=N [X86-32,X86-64] Print N words from the kernel stack | 941 | kstack=N [X86-32,X86-64] Print N words from the kernel stack |
929 | in oops dumps. | 942 | in oops dumps. |
930 | 943 | ||
944 | kgdboc= [HW] kgdb over consoles. | ||
945 | Requires a tty driver that supports console polling. | ||
946 | (only serial suported for now) | ||
947 | Format: <serial_device>[,baud] | ||
948 | |||
931 | l2cr= [PPC] | 949 | l2cr= [PPC] |
932 | 950 | ||
933 | lapic [X86-32,APIC] Enable the local APIC even if BIOS | 951 | lapic [X86-32,APIC] Enable the local APIC even if BIOS |
@@ -1134,6 +1152,11 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1134 | or | 1152 | or |
1135 | memmap=0x10000$0x18690000 | 1153 | memmap=0x10000$0x18690000 |
1136 | 1154 | ||
1155 | memtest= [KNL,X86_64] Enable memtest | ||
1156 | Format: <integer> | ||
1157 | range: 0,4 : pattern number | ||
1158 | default : 0 <disable> | ||
1159 | |||
1137 | meye.*= [HW] Set MotionEye Camera parameters | 1160 | meye.*= [HW] Set MotionEye Camera parameters |
1138 | See Documentation/video4linux/meye.txt. | 1161 | See Documentation/video4linux/meye.txt. |
1139 | 1162 | ||
@@ -1339,6 +1362,10 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1339 | 1362 | ||
1340 | nowb [ARM] | 1363 | nowb [ARM] |
1341 | 1364 | ||
1365 | nptcg= [IA64] Override max number of concurrent global TLB | ||
1366 | purges which is reported from either PAL_VM_SUMMARY or | ||
1367 | SAL PALO. | ||
1368 | |||
1342 | numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA. | 1369 | numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA. |
1343 | one of ['zone', 'node', 'default'] can be specified | 1370 | one of ['zone', 'node', 'default'] can be specified |
1344 | This can be set from sysctl after boot. | 1371 | This can be set from sysctl after boot. |
diff --git a/Documentation/s390/s390dbf.txt b/Documentation/s390/s390dbf.txt index 0eb7c58916de..e05420973698 100644 --- a/Documentation/s390/s390dbf.txt +++ b/Documentation/s390/s390dbf.txt | |||
@@ -115,6 +115,27 @@ Return Value: Handle for generated debug area | |||
115 | Description: Allocates memory for a debug log | 115 | Description: Allocates memory for a debug log |
116 | Must not be called within an interrupt handler | 116 | Must not be called within an interrupt handler |
117 | 117 | ||
118 | ---------------------------------------------------------------------------- | ||
119 | debug_info_t *debug_register_mode(char *name, int pages, int nr_areas, | ||
120 | int buf_size, mode_t mode, uid_t uid, | ||
121 | gid_t gid); | ||
122 | |||
123 | Parameter: name: Name of debug log (e.g. used for debugfs entry) | ||
124 | pages: Number of pages, which will be allocated per area | ||
125 | nr_areas: Number of debug areas | ||
126 | buf_size: Size of data area in each debug entry | ||
127 | mode: File mode for debugfs files. E.g. S_IRWXUGO | ||
128 | uid: User ID for debugfs files. Currently only 0 is | ||
129 | supported. | ||
130 | gid: Group ID for debugfs files. Currently only 0 is | ||
131 | supported. | ||
132 | |||
133 | Return Value: Handle for generated debug area | ||
134 | NULL if register failed | ||
135 | |||
136 | Description: Allocates memory for a debug log | ||
137 | Must not be called within an interrupt handler | ||
138 | |||
118 | --------------------------------------------------------------------------- | 139 | --------------------------------------------------------------------------- |
119 | void debug_unregister (debug_info_t * id); | 140 | void debug_unregister (debug_info_t * id); |
120 | 141 | ||
diff --git a/Documentation/hrtimers/highres.txt b/Documentation/timers/highres.txt index a73ecf5b4bdb..a73ecf5b4bdb 100644 --- a/Documentation/hrtimers/highres.txt +++ b/Documentation/timers/highres.txt | |||
diff --git a/Documentation/hrtimers/hrtimers.txt b/Documentation/timers/hrtimers.txt index ce31f65e12e7..ce31f65e12e7 100644 --- a/Documentation/hrtimers/hrtimers.txt +++ b/Documentation/timers/hrtimers.txt | |||
diff --git a/Documentation/hrtimer/timer_stats.txt b/Documentation/timers/timer_stats.txt index 20d368c59814..20d368c59814 100644 --- a/Documentation/hrtimer/timer_stats.txt +++ b/Documentation/timers/timer_stats.txt | |||
diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt new file mode 100644 index 000000000000..17965f927c15 --- /dev/null +++ b/Documentation/x86/pat.txt | |||
@@ -0,0 +1,100 @@ | |||
1 | |||
2 | PAT (Page Attribute Table) | ||
3 | |||
4 | x86 Page Attribute Table (PAT) allows for setting the memory attribute at the | ||
5 | page level granularity. PAT is complementary to the MTRR settings which allows | ||
6 | for setting of memory types over physical address ranges. However, PAT is | ||
7 | more flexible than MTRR due to its capability to set attributes at page level | ||
8 | and also due to the fact that there are no hardware limitations on number of | ||
9 | such attribute settings allowed. Added flexibility comes with guidelines for | ||
10 | not having memory type aliasing for the same physical memory with multiple | ||
11 | virtual addresses. | ||
12 | |||
13 | PAT allows for different types of memory attributes. The most commonly used | ||
14 | ones that will be supported at this time are Write-back, Uncached, | ||
15 | Write-combined and Uncached Minus. | ||
16 | |||
17 | There are many different APIs in the kernel that allows setting of memory | ||
18 | attributes at the page level. In order to avoid aliasing, these interfaces | ||
19 | should be used thoughtfully. Below is a table of interfaces available, | ||
20 | their intended usage and their memory attribute relationships. Internally, | ||
21 | these APIs use a reserve_memtype()/free_memtype() interface on the physical | ||
22 | address range to avoid any aliasing. | ||
23 | |||
24 | |||
25 | ------------------------------------------------------------------- | ||
26 | API | RAM | ACPI,... | Reserved/Holes | | ||
27 | -----------------------|----------|------------|------------------| | ||
28 | | | | | | ||
29 | ioremap | -- | UC | UC | | ||
30 | | | | | | ||
31 | ioremap_cache | -- | WB | WB | | ||
32 | | | | | | ||
33 | ioremap_nocache | -- | UC | UC | | ||
34 | | | | | | ||
35 | ioremap_wc | -- | -- | WC | | ||
36 | | | | | | ||
37 | set_memory_uc | UC | -- | -- | | ||
38 | set_memory_wb | | | | | ||
39 | | | | | | ||
40 | set_memory_wc | WC | -- | -- | | ||
41 | set_memory_wb | | | | | ||
42 | | | | | | ||
43 | pci sysfs resource | -- | -- | UC | | ||
44 | | | | | | ||
45 | pci sysfs resource_wc | -- | -- | WC | | ||
46 | is IORESOURCE_PREFETCH| | | | | ||
47 | | | | | | ||
48 | pci proc | -- | -- | UC | | ||
49 | !PCIIOC_WRITE_COMBINE | | | | | ||
50 | | | | | | ||
51 | pci proc | -- | -- | WC | | ||
52 | PCIIOC_WRITE_COMBINE | | | | | ||
53 | | | | | | ||
54 | /dev/mem | -- | UC | UC | | ||
55 | read-write | | | | | ||
56 | | | | | | ||
57 | /dev/mem | -- | UC | UC | | ||
58 | mmap SYNC flag | | | | | ||
59 | | | | | | ||
60 | /dev/mem | -- | WB/WC/UC | WB/WC/UC | | ||
61 | mmap !SYNC flag | |(from exist-| (from exist- | | ||
62 | and | | ing alias)| ing alias) | | ||
63 | any alias to this area| | | | | ||
64 | | | | | | ||
65 | /dev/mem | -- | WB | WB | | ||
66 | mmap !SYNC flag | | | | | ||
67 | no alias to this area | | | | | ||
68 | and | | | | | ||
69 | MTRR says WB | | | | | ||
70 | | | | | | ||
71 | /dev/mem | -- | -- | UC_MINUS | | ||
72 | mmap !SYNC flag | | | | | ||
73 | no alias to this area | | | | | ||
74 | and | | | | | ||
75 | MTRR says !WB | | | | | ||
76 | | | | | | ||
77 | ------------------------------------------------------------------- | ||
78 | |||
79 | Notes: | ||
80 | |||
81 | -- in the above table mean "Not suggested usage for the API". Some of the --'s | ||
82 | are strictly enforced by the kernel. Some others are not really enforced | ||
83 | today, but may be enforced in future. | ||
84 | |||
85 | For ioremap and pci access through /sys or /proc - The actual type returned | ||
86 | can be more restrictive, in case of any existing aliasing for that address. | ||
87 | For example: If there is an existing uncached mapping, a new ioremap_wc can | ||
88 | return uncached mapping in place of write-combine requested. | ||
89 | |||
90 | set_memory_[uc|wc] and set_memory_wb should be used in pairs, where driver will | ||
91 | first make a region uc or wc and switch it back to wb after use. | ||
92 | |||
93 | Over time writes to /proc/mtrr will be deprecated in favor of using PAT based | ||
94 | interfaces. Users writing to /proc/mtrr are suggested to use above interfaces. | ||
95 | |||
96 | Drivers should use ioremap_[uc|wc] to access PCI BARs with [uc|wc] access | ||
97 | types. | ||
98 | |||
99 | Drivers should use set_memory_[uc|wc] to set access type for RAM ranges. | ||
100 | |||
diff --git a/Documentation/x86_64/boot-options.txt b/Documentation/x86_64/boot-options.txt index 34abae4e9442..b0c7b6c4abda 100644 --- a/Documentation/x86_64/boot-options.txt +++ b/Documentation/x86_64/boot-options.txt | |||
@@ -307,3 +307,8 @@ Debugging | |||
307 | stuck (default) | 307 | stuck (default) |
308 | 308 | ||
309 | Miscellaneous | 309 | Miscellaneous |
310 | |||
311 | nogbpages | ||
312 | Do not use GB pages for kernel direct mappings. | ||
313 | gbpages | ||
314 | Use GB pages for kernel direct mappings. | ||