diff options
Diffstat (limited to 'Documentation')
49 files changed, 2455 insertions, 1109 deletions
diff --git a/Documentation/ABI/testing/debugfs-kmemtrace b/Documentation/ABI/testing/debugfs-kmemtrace deleted file mode 100644 index 5e6a92a02d85..000000000000 --- a/Documentation/ABI/testing/debugfs-kmemtrace +++ /dev/null @@ -1,71 +0,0 @@ -What: /sys/kernel/debug/kmemtrace/ -Date: July 2008 -Contact: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> -Description: - -In kmemtrace-enabled kernels, the following files are created: - -/sys/kernel/debug/kmemtrace/ - cpu<n> (0400) Per-CPU tracing data, see below. (binary) - total_overruns (0400) Total number of bytes which were dropped from - cpu<n> files because of full buffer condition, - non-binary. (text) - abi_version (0400) Kernel's kmemtrace ABI version. (text) - -Each per-CPU file should be read according to the relay interface. That is, -the reader should set affinity to that specific CPU and, as currently done by -the userspace application (though there are other methods), use poll() with -an infinite timeout before every read(). Otherwise, erroneous data may be -read. The binary data has the following _core_ format: - - Event ID (1 byte) Unsigned integer, one of: - 0 - represents an allocation (KMEMTRACE_EVENT_ALLOC) - 1 - represents a freeing of previously allocated memory - (KMEMTRACE_EVENT_FREE) - Type ID (1 byte) Unsigned integer, one of: - 0 - this is a kmalloc() / kfree() - 1 - this is a kmem_cache_alloc() / kmem_cache_free() - 2 - this is a __get_free_pages() et al. - Event size (2 bytes) Unsigned integer representing the - size of this event. Used to extend - kmemtrace. Discard the bytes you - don't know about. - Sequence number (4 bytes) Signed integer used to reorder data - logged on SMP machines. Wraparound - must be taken into account, although - it is unlikely. - Caller address (8 bytes) Return address to the caller. - Pointer to mem (8 bytes) Pointer to target memory area. Can be - NULL, but not all such calls might be - recorded. - -In case of KMEMTRACE_EVENT_ALLOC events, the next fields follow: - - Requested bytes (8 bytes) Total number of requested bytes, - unsigned, must not be zero. - Allocated bytes (8 bytes) Total number of actually allocated - bytes, unsigned, must not be lower - than requested bytes. - Requested flags (4 bytes) GFP flags supplied by the caller. - Target CPU (4 bytes) Signed integer, valid for event id 1. - If equal to -1, target CPU is the same - as origin CPU, but the reverse might - not be true. - -The data is made available in the same endianness the machine has. - -Other event ids and type ids may be defined and added. Other fields may be -added by increasing event size, but see below for details. -Every modification to the ABI, including new id definitions, are followed -by bumping the ABI version by one. - -Adding new data to the packet (features) is done at the end of the mandatory -data: - Feature size (2 byte) - Feature ID (1 byte) - Feature data (Feature size - 3 bytes) - - -Users: - kmemtrace-user - git://repo.or.cz/kmemtrace-user.git - diff --git a/Documentation/ABI/testing/sysfs-bus-i2c-devices-hm6352 b/Documentation/ABI/testing/sysfs-bus-i2c-devices-hm6352 new file mode 100644 index 000000000000..feb2e4a87075 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-i2c-devices-hm6352 @@ -0,0 +1,21 @@ +Where: /sys/bus/i2c/devices/.../heading0_input +Date: April 2010 +Kernel Version: 2.6.36? +Contact: alan.cox@intel.com +Description: Reports the current heading from the compass as a floating + point value in degrees. + +Where: /sys/bus/i2c/devices/.../power_state +Date: April 2010 +Kernel Version: 2.6.36? +Contact: alan.cox@intel.com +Description: Sets the power state of the device. 0 sets the device into + sleep mode, 1 wakes it up. + +Where: /sys/bus/i2c/devices/.../calibration +Date: April 2010 +Kernel Version: 2.6.36? +Contact: alan.cox@intel.com +Description: Sets the calibration on or off (1 = on, 0 = off). See the + chip data sheet. + diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index 25be3250f7d6..f979d825d112 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci @@ -139,3 +139,30 @@ Contact: linux-pci@vger.kernel.org Description: This symbolic link points to the PCI hotplug controller driver module that manages the hotplug slot. + +What: /sys/bus/pci/devices/.../label +Date: July 2010 +Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com +Description: + Reading this attribute will provide the firmware + given name(SMBIOS type 41 string) of the PCI device. + The attribute will be created only if the firmware + has given a name to the PCI device. +Users: + Userspace applications interested in knowing the + firmware assigned name of the PCI device. + +What: /sys/bus/pci/devices/.../index +Date: July 2010 +Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com +Description: + Reading this attribute will provide the firmware + given instance(SMBIOS type 41 device type instance) + of the PCI device. The attribute will be created + only if the firmware has given a device type instance + to the PCI device. +Users: + Userspace applications interested in knowing the + firmware assigned device type instance of the PCI + device that can help in understanding the firmware + intended order of the PCI device. diff --git a/Documentation/ABI/testing/sysfs-i2c-bmp085 b/Documentation/ABI/testing/sysfs-i2c-bmp085 new file mode 100644 index 000000000000..585962ad0465 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-i2c-bmp085 @@ -0,0 +1,31 @@ +What: /sys/bus/i2c/devices/<busnum>-<devaddr>/pressure0_input +Date: June 2010 +Contact: Christoph Mair <christoph.mair@gmail.com> +Description: Start a pressure measurement and read the result. Values + represent the ambient air pressure in pascal (0.01 millibar). + + Reading: returns the current air pressure. + + +What: /sys/bus/i2c/devices/<busnum>-<devaddr>/temp0_input +Date: June 2010 +Contact: Christoph Mair <christoph.mair@gmail.com> +Description: Measure the ambient temperature. The returned value represents + the ambient temperature in units of 0.1 degree celsius. + + Reading: returns the current temperature. + + +What: /sys/bus/i2c/devices/<busnum>-<devaddr>/oversampling +Date: June 2010 +Contact: Christoph Mair <christoph.mair@gmail.com> +Description: Tell the bmp085 to use more samples to calculate a pressure + value. When writing to this file the chip will use 2^x samples + to calculate the next pressure value with x being the value + written. Using this feature will decrease RMS noise and + increase the measurement time. + + Reading: returns the current oversampling setting. + + Writing: sets a new oversampling setting. + Accepted values: 0..3. diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index 1b2dd4fc3db2..ecd35e9d4410 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -111,6 +111,7 @@ X!Edrivers/base/attribute_container.c <!-- X!Edrivers/base/interface.c --> +!Iinclude/linux/platform_device.h !Edrivers/base/platform.c !Edrivers/base/bus.c </sect1> diff --git a/Documentation/DocBook/kgdb.tmpl b/Documentation/DocBook/kgdb.tmpl index 55f12ac37acd..490d862c5f0d 100644 --- a/Documentation/DocBook/kgdb.tmpl +++ b/Documentation/DocBook/kgdb.tmpl @@ -199,10 +199,33 @@ may be configured as a kernel built-in or a kernel loadable module. You can only make use of <constant>kgdbwait</constant> and early debugging if you build kgdboc into the kernel as a built-in. + <para>Optionally you can elect to activate kms (Kernel Mode + Setting) integration. When you use kms with kgdboc and you have a + video driver that has atomic mode setting hooks, it is possible to + enter the debugger on the graphics console. When the kernel + execution is resumed, the previous graphics mode will be restored. + This integration can serve as a useful tool to aid in diagnosing + crashes or doing analysis of memory with kdb while allowing the + full graphics console applications to run. + </para> </para> <sect2 id="kgdbocArgs"> <title>kgdboc arguments</title> - <para>Usage: <constant>kgdboc=[kbd][[,]serial_device][,baud]</constant></para> + <para>Usage: <constant>kgdboc=[kms][[,]kbd][[,]serial_device][,baud]</constant></para> + <para>The order listed above must be observed if you use any of the + optional configurations together. + </para> + <para>Abbreviations: + <itemizedlist> + <listitem><para>kms = Kernel Mode Setting</para></listitem> + <listitem><para>kbd = Keyboard</para></listitem> + </itemizedlist> + </para> + <para>You can configure kgdboc to use the keyboard, and or a serial + device depending on if you are using kdb and or kgdb, in one of the + following scenarios. The order listed above must be observed if + you use any of the optional configurations together. Using kms + + only gdb is generally not a useful combination.</para> <sect3 id="kgdbocArgs1"> <title>Using loadable module or built-in</title> <para> @@ -212,7 +235,7 @@ <listitem> <para>As a kernel loadable module:</para> <para>Use the command: <constant>modprobe kgdboc kgdboc=<tty-device>,[baud]</constant></para> - <para>Here are two examples of how you might formate the kgdboc + <para>Here are two examples of how you might format the kgdboc string. The first is for an x86 target using the first serial port. The second example is for the ARM Versatile AB using the second serial port. @@ -240,6 +263,9 @@ </sect3> <sect3 id="kgdbocArgs3"> <title>More examples</title> + <para>You can configure kgdboc to use the keyboard, and or a serial + device depending on if you are using kdb and or kgdb, in one of the + following scenarios.</para> <para>You can configure kgdboc to use the keyboard, and or a serial device depending on if you are using kdb and or kgdb, in one of the following scenarios. @@ -255,6 +281,12 @@ <listitem><para>kdb with a keyboard</para> <para><constant>kgdboc=kbd</constant></para> </listitem> + <listitem><para>kdb with kernel mode setting</para> + <para><constant>kgdboc=kms,kbd</constant></para> + </listitem> + <listitem><para>kdb with kernel mode setting and kgdb over a serial port</para> + <para><constant>kgdboc=kms,kbd,ttyS0,115200</constant></para> + </listitem> </orderedlist> </para> </sect3> @@ -637,6 +669,8 @@ Task Addr Pid Parent [*] cpu State Thread Command <listitem><para>The logic to perform safe memory reads and writes to memory while using the debugger</para></listitem> <listitem><para>A full implementation for software breakpoints unless overridden by the arch</para></listitem> <listitem><para>The API to invoke either the kdb or kgdb frontend to the debug core.</para></listitem> + <listitem><para>The structures and callback API for atomic kernel mode setting.</para> + <para>NOTE: kgdboc is where the kms callbacks are invoked.</para></listitem> </itemizedlist> </para> </listitem> @@ -747,6 +781,8 @@ Task Addr Pid Parent [*] cpu State Thread Command </sect1> <sect1 id="kgdbocDesign"> <title>kgdboc internals</title> + <sect2> + <title>kgdboc and uarts</title> <para> The kgdboc driver is actually a very thin driver that relies on the underlying low level to the hardware driver having "polling hooks" @@ -754,11 +790,8 @@ Task Addr Pid Parent [*] cpu State Thread Command implementation of kgdboc it the serial_core was changed to expose a low level UART hook for doing polled mode reading and writing of a single character while in an atomic context. When kgdb makes an I/O - request to the debugger, kgdboc invokes a call back in the serial - core which in turn uses the call back in the UART driver. It is - certainly possible to extend kgdboc to work with non-UART based - consoles in the future. - </para> + request to the debugger, kgdboc invokes a callback in the serial + core which in turn uses the callback in the UART driver.</para> <para> 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> #ifdef CONFIG_CONSOLE_POLL @@ -772,9 +805,68 @@ Task Addr Pid Parent [*] cpu State Thread Command that they can be called from an atomic context and have to restore the state of the UART chip on return such that the system can return to normal when the debugger detaches. You need to be very careful - with any kind of lock you consider, because failing here is most + with any kind of lock you consider, because failing here is most likely going to mean pressing the reset button. </para> + </sect2> + <sect2 id="kgdbocKbd"> + <title>kgdboc and keyboards</title> + <para>The kgdboc driver contains logic to configure communications + with an attached keyboard. The keyboard infrastructure is only + compiled into the kernel when CONFIG_KDB_KEYBOARD=y is set in the + kernel configuration.</para> + <para>The core polled keyboard driver driver for PS/2 type keyboards + is in drivers/char/kdb_keyboard.c. This driver is hooked into the + debug core when kgdboc populates the callback in the array + called <constant>kdb_poll_funcs[]</constant>. The + kdb_get_kbd_char() is the top-level function which polls hardware + for single character input. + </para> + </sect2> + <sect2 id="kgdbocKms"> + <title>kgdboc and kms</title> + <para>The kgdboc driver contains logic to request the graphics + display to switch to a text context when you are using + "kgdboc=kms,kbd", provided that you have a video driver which has a + frame buffer console and atomic kernel mode setting support.</para> + <para> + Every time the kernel + debugger is entered it calls kgdboc_pre_exp_handler() which in turn + calls con_debug_enter() in the virtual console layer. On resuming kernel + execution, the kernel debugger calls kgdboc_post_exp_handler() which + in turn calls con_debug_leave().</para> + <para>Any video driver that wants to be compatible with the kernel + debugger and the atomic kms callbacks must implement the + mode_set_base_atomic, fb_debug_enter and fb_debug_leave operations. + For the fb_debug_enter and fb_debug_leave the option exists to use + the generic drm fb helper functions or implement something custom for + the hardware. The following example shows the initialization of the + .mode_set_base_atomic operation in + drivers/gpu/drm/i915/intel_display.c: + <informalexample> + <programlisting> +static const struct drm_crtc_helper_funcs intel_helper_funcs = { +[...] + .mode_set_base_atomic = intel_pipe_set_base_atomic, +[...] +}; + </programlisting> + </informalexample> + </para> + <para>Here is an example of how the i915 driver initializes the fb_debug_enter and fb_debug_leave functions to use the generic drm helpers in + drivers/gpu/drm/i915/intel_fb.c: + <informalexample> + <programlisting> +static struct fb_ops intelfb_ops = { +[...] + .fb_debug_enter = drm_fb_helper_debug_enter, + .fb_debug_leave = drm_fb_helper_debug_leave, +[...] +}; + </programlisting> + </informalexample> + </para> + </sect2> </sect1> </chapter> <chapter id="credits"> diff --git a/Documentation/DocBook/stylesheet.xsl b/Documentation/DocBook/stylesheet.xsl index 254c1d5d2e50..85b25275196f 100644 --- a/Documentation/DocBook/stylesheet.xsl +++ b/Documentation/DocBook/stylesheet.xsl @@ -6,4 +6,5 @@ <param name="callout.graphics">0</param> <!-- <param name="paper.type">A4</param> --> <param name="generate.section.toc.level">2</param> +<param name="use.id.as.filename">1</param> </stylesheet> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 72651f788f4e..689e2371095c 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -98,6 +98,17 @@ system, git, as a "commit log". See #15, below. If your description starts to get long, that's a sign that you probably need to split up your patch. See #3, next. +When you submit or resubmit a patch or patch series, include the +complete patch description and justification for it. Don't just +say that this is version N of the patch (series). Don't expect the +patch merger to refer back to earlier patch versions or referenced +URLs to find the patch description and put that into the patch. +I.e., the patch (series) and its description should be self-contained. +This benefits both the patch merger(s) and reviewers. Some reviewers +probably didn't even receive earlier versions of the patch. + +If the patch fixes a logged bug entry, refer to that bug entry by +number and URL. 3) Separate your changes. diff --git a/Documentation/blackfin/00-INDEX b/Documentation/blackfin/00-INDEX index c34e12440fec..2df0365f2dff 100644 --- a/Documentation/blackfin/00-INDEX +++ b/Documentation/blackfin/00-INDEX @@ -1,11 +1,8 @@ 00-INDEX - This file -cachefeatures.txt - - Supported cache features. - -Filesystems - - Requirements for mounting the root file system. - -bfin-gpio-note.txt +bfin-gpio-notes.txt - Notes in developing/using bfin-gpio driver. + +bfin-spi-notes.txt + - Notes for using bfin spi bus driver. diff --git a/Documentation/blackfin/Filesystems b/Documentation/blackfin/Filesystems deleted file mode 100644 index 51260a1b8032..000000000000 --- a/Documentation/blackfin/Filesystems +++ /dev/null @@ -1,169 +0,0 @@ -/* - * File: Documentation/blackfin/Filesystems - * Based on: - * Author: - * - * Created: - * Description: This file contains the simple DMA Implementation for Blackfin - * - * Rev: $Id: Filesystems 2384 2006-11-01 04:12:43Z magicyang $ - * - * Modified: - * Copyright 2004-2006 Analog Devices Inc. - * - * Bugs: Enter bugs at http://blackfin.uclinux.org/ - * - */ - - How to mount the root file system in uClinux/Blackfin - ----------------------------------------------------- - -1 Mounting EXT3 File system. - ------------------------ - - Creating an EXT3 File system for uClinux/Blackfin: - - -Please follow the steps to form the EXT3 File system and mount the same as root -file system. - -a Make an ext3 file system as large as you want the final root file - system. - - mkfs.ext3 /dev/ram0 <your-rootfs-size-in-1k-blocks> - -b Mount this Empty file system on a free directory as: - - mount -t ext3 /dev/ram0 ./test - where ./test is the empty directory. - -c Copy your root fs directory that you have so carefully made over. - - cp -af /tmp/my_final_rootfs_files/* ./test - - (For ex: cp -af uClinux-dist/romfs/* ./test) - -d If you have done everything right till now you should be able to see - the required "root" dir's (that's etc, root, bin, lib, sbin...) - -e Now unmount the file system - - umount ./test - -f Create the root file system image. - - dd if=/dev/ram0 bs=1k count=<your-rootfs-size-in-1k-blocks> \ - > ext3fs.img - - -Now you have to tell the kernel that will be mounting this file system as -rootfs. -So do a make menuconfig under kernel and select the Ext3 journaling file system -support under File system --> submenu. - - -2. Mounting EXT2 File system. - ------------------------- - -By default the ext2 file system image will be created if you invoke make from -the top uClinux-dist directory. - - -3. Mounting CRAMFS File System - ---------------------------- - -To create a CRAMFS file system image execute the command - - mkfs.cramfs ./test cramfs.img - - where ./test is the target directory. - - -4. Mounting ROMFS File System - -------------------------- - -To create a ROMFS file system image execute the command - - genromfs -v -V "ROMdisk" -f romfs.img -d ./test - - where ./test is the target directory - - -5. Mounting the JFFS2 Filesystem - ----------------------------- - -To create a compressed JFFS filesystem (JFFS2), please execute the command - - mkfs.jffs2 -d ./test -o jffs2.img - - where ./test is the target directory. - -However, please make sure the following is in your kernel config. - -/* - * RAM/ROM/Flash chip drivers - */ -#define CONFIG_MTD_CFI 1 -#define CONFIG_MTD_ROM 1 -/* - * Mapping drivers for chip access - */ -#define CONFIG_MTD_COMPLEX_MAPPINGS 1 -#define CONFIG_MTD_BF533 1 -#undef CONFIG_MTD_UCLINUX - -Through the u-boot boot loader, use the jffs2.img in the corresponding -partition made in linux-2.6.x/drivers/mtd/maps/bf533_flash.c. - -NOTE - Currently the Flash driver is available only for EZKIT. Watch out for a - STAMP driver soon. - - -6. Mounting the NFS File system - ----------------------------- - - For mounting the NFS please do the following in the kernel config. - - In Networking Support --> Networking options --> TCP/IP networking --> - IP: kernel level autoconfiguration - - Enable BOOTP Support. - - In Kernel hacking --> Compiled-in kernel boot parameter add the following - - root=/dev/nfs rw ip=bootp - - In File system --> Network File system, Enable - - NFS file system support --> NFSv3 client support - Root File system on NFS - - in uClibc menuconfig, do the following - In Networking Support - enable Remote Procedure Call (RPC) support - Full RPC Support - - On the Host side, ensure that /etc/dhcpd.conf looks something like this - - ddns-update-style ad-hoc; - allow bootp; - subnet 10.100.4.0 netmask 255.255.255.0 { - default-lease-time 122209600; - max-lease-time 31557600; - group { - host bf533 { - hardware ethernet 00:CF:52:49:C3:01; - fixed-address 10.100.4.50; - option root-path "/home/nfsmount"; - } - } - - ensure that /etc/exports looks something like this - /home/nfsmount *(rw,no_root_squash,no_all_squash) - - run the following commands as root (may differ depending on your - distribution) : - - service nfs start - - service portmap start - - service dhcpd start - - /usr/sbin/exportfs diff --git a/Documentation/blackfin/bfin-spi-notes.txt b/Documentation/blackfin/bfin-spi-notes.txt new file mode 100644 index 000000000000..556fa877f2e8 --- /dev/null +++ b/Documentation/blackfin/bfin-spi-notes.txt @@ -0,0 +1,14 @@ +SPI Chip Select behavior: + +With the Blackfin on-chip SPI peripheral, there is some logic tied to the CPHA +bit whether the Slave Select Line is controlled by hardware (CPHA=0) or +controlled by software (CPHA=1). However, the Linux SPI bus driver assumes that +the Slave Select is always under software control and being asserted during +the entire SPI transfer. - And not just bits_per_word duration. + +In most cases you can utilize SPI MODE_3 instead of MODE_0 to work-around this +behavior. If your SPI slave device in question requires SPI MODE_0 or MODE_2 +timing, you can utilize the GPIO controlled SPI Slave Select option instead. + +You can even use the same pin whose peripheral role is a SSEL, +but use it as a GPIO instead. diff --git a/Documentation/blackfin/cachefeatures.txt b/Documentation/blackfin/cachefeatures.txt deleted file mode 100644 index 75de51f94515..000000000000 --- a/Documentation/blackfin/cachefeatures.txt +++ /dev/null @@ -1,55 +0,0 @@ -/* - * File: Documentation/blackfin/cachefeatures.txt - * Based on: - * Author: - * - * Created: - * Description: This file contains the simple DMA Implementation for Blackfin - * - * Rev: $Id: cachefeatures.txt 2384 2006-11-01 04:12:43Z magicyang $ - * - * Modified: - * Copyright 2004-2006 Analog Devices Inc. - * - * Bugs: Enter bugs at http://blackfin.uclinux.org/ - * - */ - - - Instruction and Data cache initialization. - icache_init(); - dcache_init(); - - - Instruction and Data cache Invalidation Routines, when flushing the - same is not required. - _icache_invalidate(); - _dcache_invalidate(); - - Also, for invalidating the entire instruction and data cache, the below - routines are provided (another method for invalidation, refer page no 267 and 287 of - ADSP-BF533 Hardware Reference manual) - - invalidate_entire_dcache(); - invalidate_entire_icache(); - - -External Flushing of Instruction and data cache routines. - - flush_instruction_cache(); - flush_data_cache(); - - - Internal Flushing of Instruction and Data Cache. - - icplb_flush(); - dcplb_flush(); - - - Miscellaneous cache functions. - - flush_cache_all(); - flush_cache_mm(); - invalidate_dcache_range(); - flush_dcache_range(); - flush_dcache_page(); - flush_cache_range(); - flush_cache_page(); - invalidate_dcache_range(); - flush_page_to_ram(); - diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt index 508b5b2b0289..b9a83dd24732 100644 --- a/Documentation/block/biodoc.txt +++ b/Documentation/block/biodoc.txt @@ -7,7 +7,7 @@ Notes Written on Jan 15, 2002: Last Updated May 2, 2002 September 2003: Updated I/O Scheduler portions - Nick Piggin <piggin@cyberone.com.au> + Nick Piggin <npiggin@kernel.dk> Introduction: diff --git a/Documentation/coccinelle.txt b/Documentation/coccinelle.txt new file mode 100644 index 000000000000..cd2b02837066 --- /dev/null +++ b/Documentation/coccinelle.txt @@ -0,0 +1,258 @@ +Copyright 2010 Nicolas Palix <npalix@diku.dk> +Copyright 2010 Julia Lawall <julia@diku.dk> +Copyright 2010 Gilles Muller <Gilles.Muller@lip6.fr> + + + Getting Coccinelle +~~~~~~~~~~~~~~~~~~~~ + +The semantic patches included in the kernel use the 'virtual rule' +feature which was introduced in Coccinelle version 0.1.11. + +Coccinelle (>=0.2.0) is available through the package manager +of many distributions, e.g. : + + - Debian (>=squeeze) + - Fedora (>=13) + - Ubuntu (>=10.04 Lucid Lynx) + - OpenSUSE + - Arch Linux + - NetBSD + - FreeBSD + + +You can get the latest version released from the Coccinelle homepage at +http://coccinelle.lip6.fr/ + +Once you have it, run the following command: + + ./configure + make + +as a regular user, and install it with + + sudo make install + + + Using Coccinelle on the Linux kernel +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +A Coccinelle-specific target is defined in the top level +Makefile. This target is named 'coccicheck' and calls the 'coccicheck' +front-end in the 'scripts' directory. + +Four modes are defined: report, patch, context, and org. The mode to +use is specified by setting the MODE variable with 'MODE=<mode>'. + +'report' generates a list in the following format: + file:line:column-column: message + +'patch' proposes a fix, when possible. + +'context' highlights lines of interest and their context in a +diff-like style.Lines of interest are indicated with '-'. + +'org' generates a report in the Org mode format of Emacs. + +Note that not all semantic patches implement all modes. + +To make a report for every semantic patch, run the following command: + + make coccicheck MODE=report + +NB: The 'report' mode is the default one. + +To produce patches, run: + + make coccicheck MODE=patch + + +The coccicheck target applies every semantic patch available in the +subdirectories of 'scripts/coccinelle' to the entire Linux kernel. + +For each semantic patch, a changelog message is proposed. It gives a +description of the problem being checked by the semantic patch, and +includes a reference to Coccinelle. + +As any static code analyzer, Coccinelle produces false +positives. Thus, reports must be carefully checked, and patches +reviewed. + + + Using Coccinelle with a single semantic patch +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The optional make variable COCCI can be used to check a single +semantic patch. In that case, the variable must be initialized with +the name of the semantic patch to apply. + +For instance: + + make coccicheck COCCI=<my_SP.cocci> MODE=patch +or + make coccicheck COCCI=<my_SP.cocci> MODE=report + + + Proposing new semantic patches +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +New semantic patches can be proposed and submitted by kernel +developers. For sake of clarity, they should be organized in the +subdirectories of 'scripts/coccinelle/'. + + + Detailed description of the 'report' mode +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +'report' generates a list in the following format: + file:line:column-column: message + +Example: + +Running + + make coccicheck MODE=report COCCI=scripts/coccinelle/err_cast.cocci + +will execute the following part of the SmPL script. + +<smpl> +@r depends on !context && !patch && (org || report)@ +expression x; +position p; +@@ + + ERR_PTR@p(PTR_ERR(x)) + +@script:python depends on report@ +p << r.p; +x << r.x; +@@ + +msg="ERR_CAST can be used with %s" % (x) +coccilib.report.print_report(p[0], msg) +</smpl> + +This SmPL excerpt generates entries on the standard output, as +illustrated below: + +/home/user/linux/crypto/ctr.c:188:9-16: ERR_CAST can be used with alg +/home/user/linux/crypto/authenc.c:619:9-16: ERR_CAST can be used with auth +/home/user/linux/crypto/xts.c:227:9-16: ERR_CAST can be used with alg + + + Detailed description of the 'patch' mode +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +When the 'patch' mode is available, it proposes a fix for each problem +identified. + +Example: + +Running + make coccicheck MODE=patch COCCI=scripts/coccinelle/err_cast.cocci + +will execute the following part of the SmPL script. + +<smpl> +@ depends on !context && patch && !org && !report @ +expression x; +@@ + +- ERR_PTR(PTR_ERR(x)) ++ ERR_CAST(x) +</smpl> + +This SmPL excerpt generates patch hunks on the standard output, as +illustrated below: + +diff -u -p a/crypto/ctr.c b/crypto/ctr.c +--- a/crypto/ctr.c 2010-05-26 10:49:38.000000000 +0200 ++++ b/crypto/ctr.c 2010-06-03 23:44:49.000000000 +0200 +@@ -185,7 +185,7 @@ static struct crypto_instance *crypto_ct + alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_CIPHER, + CRYPTO_ALG_TYPE_MASK); + if (IS_ERR(alg)) +- return ERR_PTR(PTR_ERR(alg)); ++ return ERR_CAST(alg); + + /* Block size must be >= 4 bytes. */ + err = -EINVAL; + + Detailed description of the 'context' mode +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +'context' highlights lines of interest and their context +in a diff-like style. + +NOTE: The diff-like output generated is NOT an applicable patch. The + intent of the 'context' mode is to highlight the important lines + (annotated with minus, '-') and gives some surrounding context + lines around. This output can be used with the diff mode of + Emacs to review the code. + +Example: + +Running + make coccicheck MODE=context COCCI=scripts/coccinelle/err_cast.cocci + +will execute the following part of the SmPL script. + +<smpl> +@ depends on context && !patch && !org && !report@ +expression x; +@@ + +* ERR_PTR(PTR_ERR(x)) +</smpl> + +This SmPL excerpt generates diff hunks on the standard output, as +illustrated below: + +diff -u -p /home/user/linux/crypto/ctr.c /tmp/nothing +--- /home/user/linux/crypto/ctr.c 2010-05-26 10:49:38.000000000 +0200 ++++ /tmp/nothing +@@ -185,7 +185,6 @@ static struct crypto_instance *crypto_ct + alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_CIPHER, + CRYPTO_ALG_TYPE_MASK); + if (IS_ERR(alg)) +- return ERR_PTR(PTR_ERR(alg)); + + /* Block size must be >= 4 bytes. */ + err = -EINVAL; + + Detailed description of the 'org' mode +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +'org' generates a report in the Org mode format of Emacs. + +Example: + +Running + make coccicheck MODE=org COCCI=scripts/coccinelle/err_cast.cocci + +will execute the following part of the SmPL script. + +<smpl> +@r depends on !context && !patch && (org || report)@ +expression x; +position p; +@@ + + ERR_PTR@p(PTR_ERR(x)) + +@script:python depends on org@ +p << r.p; +x << r.x; +@@ + +msg="ERR_CAST can be used with %s" % (x) +msg_safe=msg.replace("[","@(").replace("]",")") +coccilib.org.print_todo(p[0], msg_safe) +</smpl> + +This SmPL excerpt generates Org entries on the standard output, as +illustrated below: + +* TODO [[view:/home/user/linux/crypto/ctr.c::face=ovl-face1::linb=188::colb=9::cole=16][ERR_CAST can be used with alg]] +* TODO [[view:/home/user/linux/crypto/authenc.c::face=ovl-face1::linb=619::colb=9::cole=16][ERR_CAST can be used with auth]] +* TODO [[view:/home/user/linux/crypto/xts.c::face=ovl-face1::linb=227::colb=9::cole=16][ERR_CAST can be used with alg]] diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index be7030e4dd73..56cee4727b1a 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -116,29 +116,6 @@ Who: Mauro Carvalho Chehab <mchehab@infradead.org> --------------------------- -What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl]) -When: 2.6.35/2.6.36 -Files: drivers/pcmcia/: pcmcia_ioctl.c -Why: With the 16-bit PCMCIA subsystem now behaving (almost) like a - normal hotpluggable bus, and with it using the default kernel - infrastructure (hotplug, driver core, sysfs) keeping the PCMCIA - control ioctl needed by cardmgr and cardctl from pcmcia-cs is - unnecessary and potentially harmful (it does not provide for - proper locking), and makes further cleanups and integration of the - PCMCIA subsystem into the Linux kernel device driver model more - difficult. The features provided by cardmgr and cardctl are either - handled by the kernel itself now or are available in the new - pcmciautils package available at - http://kernel.org/pub/linux/utils/kernel/pcmcia/ - - For all architectures except ARM, the associated config symbol - has been removed from kernel 2.6.34; for ARM, it will be likely - be removed from kernel 2.6.35. The actual code will then likely - be removed from kernel 2.6.36. -Who: Dominik Brodowski <linux@dominikbrodowski.net> - ---------------------------- - What: sys_sysctl When: September 2010 Option: CONFIG_SYSCTL_SYSCALL @@ -174,6 +151,31 @@ Who: Eric Biederman <ebiederm@xmission.com> --------------------------- +What: /proc/<pid>/oom_adj +When: August 2012 +Why: /proc/<pid>/oom_adj allows userspace to influence the oom killer's + badness heuristic used to determine which task to kill when the kernel + is out of memory. + + The badness heuristic has since been rewritten since the introduction of + this tunable such that its meaning is deprecated. The value was + implemented as a bitshift on a score generated by the badness() + function that did not have any precise units of measure. With the + rewrite, the score is given as a proportion of available memory to the + task allocating pages, so using a bitshift which grows the score + exponentially is, thus, impossible to tune with fine granularity. + + A much more powerful interface, /proc/<pid>/oom_score_adj, was + introduced with the oom killer rewrite that allows users to increase or + decrease the badness() score linearly. This interface will replace + /proc/<pid>/oom_adj. + + A warning will be emitted to the kernel log if an application uses this + deprecated interface. After it is printed once, future warnings will be + suppressed until the kernel is rebooted. + +--------------------------- + What: remove EXPORT_SYMBOL(kernel_thread) When: August 2006 Files: arch/*/kernel/*_ksyms.c @@ -468,16 +470,6 @@ Who: Jan Kiszka <jan.kiszka@web.de> ---------------------------- -What: xtime, wall_to_monotonic -When: 2.6.36+ -Files: kernel/time/timekeeping.c include/linux/time.h -Why: Cleaning up timekeeping internal values. Please use - existing timekeeping accessor functions to access - the equivalent functionality. -Who: John Stultz <johnstul@us.ibm.com> - ----------------------------- - What: KVM paravirt mmu host support When: January 2011 Why: The paravirt mmu host support is slower than non-paravirt mmu, both diff --git a/Documentation/filesystems/caching/fscache.txt b/Documentation/filesystems/caching/fscache.txt index a91e2e2095b0..770267af5b3e 100644 --- a/Documentation/filesystems/caching/fscache.txt +++ b/Documentation/filesystems/caching/fscache.txt @@ -343,8 +343,8 @@ This will look something like: [root@andromeda ~]# head /proc/fs/fscache/objects OBJECT PARENT STAT CHLDN OPS OOP IPR EX READS EM EV F S | NETFS_COOKIE_DEF TY FL NETFS_DATA OBJECT_KEY, AUX_DATA ======== ======== ==== ===== === === === == ===== == == = = | ================ == == ================ ================ - 17e4b 2 ACTV 0 0 0 0 0 0 7b 4 0 8 | NFS.fh DT 0 ffff88001dd82820 010006017edcf8bbc93b43298fdfbe71e50b57b13a172c0117f38472, e567634700000000000000000000000063f2404a000000000000000000000000c9030000000000000000000063f2404a - 1693a 2 ACTV 0 0 0 0 0 0 7b 4 0 8 | NFS.fh DT 0 ffff88002db23380 010006017edcf8bbc93b43298fdfbe71e50b57b1e0162c01a2df0ea6, 420ebc4a000000000000000000000000420ebc4a0000000000000000000000000e1801000000000000000000420ebc4a + 17e4b 2 ACTV 0 0 0 0 0 0 7b 4 0 0 | NFS.fh DT 0 ffff88001dd82820 010006017edcf8bbc93b43298fdfbe71e50b57b13a172c0117f38472, e567634700000000000000000000000063f2404a000000000000000000000000c9030000000000000000000063f2404a + 1693a 2 ACTV 0 0 0 0 0 0 7b 4 0 0 | NFS.fh DT 0 ffff88002db23380 010006017edcf8bbc93b43298fdfbe71e50b57b1e0162c01a2df0ea6, 420ebc4a000000000000000000000000420ebc4a0000000000000000000000000e1801000000000000000000420ebc4a where the first set of columns before the '|' describe the object: @@ -362,7 +362,7 @@ where the first set of columns before the '|' describe the object: EM Object's event mask EV Events raised on this object F Object flags - S Object slow-work work item flags + S Object work item busy state mask (1:pending 2:running) and the second set of columns describe the object's cookie, if present: @@ -395,8 +395,8 @@ and the following paired letters: w Show objects that don't have pending writes R Show objects that have outstanding reads r Show objects that don't have outstanding reads - S Show objects that have slow work queued - s Show objects that don't have slow work queued + S Show objects that have work queued + s Show objects that don't have work queued If neither side of a letter pair is given, then both are implied. For example: diff --git a/Documentation/filesystems/nilfs2.txt b/Documentation/filesystems/nilfs2.txt index d3e7673995eb..d5c0cef38a71 100644 --- a/Documentation/filesystems/nilfs2.txt +++ b/Documentation/filesystems/nilfs2.txt @@ -49,7 +49,10 @@ Mount options NILFS2 supports the following mount options: (*) == default -nobarrier Disables barriers. +barrier(*) This enables/disables the use of write barriers. This +nobarrier requires an IO stack which can support barriers, and + if nilfs gets an error on a barrier write, it will + disable again with a warning. 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. @@ -74,9 +77,10 @@ norecovery Disable recovery of the filesystem on mount. This disables every write access on the device for read-only mounts or snapshots. This option will fail for r/w mounts on an unclean volume. -discard Issue discard/TRIM commands to the underlying block - device when blocks are freed. This is useful for SSD - devices and sparse/thinly-provisioned LUNs. +discard This enables/disables the use of discard/TRIM commands. +nodiscard(*) The discard/TRIM commands are sent to the underlying + block device when blocks are freed. This is useful + for SSD devices and sparse/thinly-provisioned LUNs. NILFS2 usage ============ diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 8fe8895894d8..a6aca8740883 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -33,7 +33,8 @@ Table of Contents 2 Modifying System Parameters 3 Per-Process Parameters - 3.1 /proc/<pid>/oom_adj - Adjust the oom-killer score + 3.1 /proc/<pid>/oom_adj & /proc/<pid>/oom_score_adj - Adjust the oom-killer + score 3.2 /proc/<pid>/oom_score - Display current oom-killer score 3.3 /proc/<pid>/io - Display the IO accounting fields 3.4 /proc/<pid>/coredump_filter - Core dump filtering settings @@ -1234,42 +1235,64 @@ of the kernel. CHAPTER 3: PER-PROCESS PARAMETERS ------------------------------------------------------------------------------ -3.1 /proc/<pid>/oom_adj - Adjust the oom-killer score ------------------------------------------------------- - -This file can be used to adjust the score used to select which processes -should be killed in an out-of-memory situation. Giving it a high score will -increase the likelihood of this process being killed by the oom-killer. Valid -values are in the range -16 to +15, plus the special value -17, which disables -oom-killing altogether for this process. - -The process to be killed in an out-of-memory situation is selected among all others -based on its badness score. This value equals the original memory size of the process -and is then updated according to its CPU time (utime + stime) and the -run time (uptime - start time). The longer it runs the smaller is the score. -Badness score is divided by the square root of the CPU time and then by -the double square root of the run time. - -Swapped out tasks are killed first. Half of each child's memory size is added to -the parent's score if they do not share the same memory. Thus forking servers -are the prime candidates to be killed. Having only one 'hungry' child will make -parent less preferable than the child. - -/proc/<pid>/oom_score shows process' current badness score. - -The following heuristics are then applied: - * if the task was reniced, its score doubles - * superuser or direct hardware access tasks (CAP_SYS_ADMIN, CAP_SYS_RESOURCE - or CAP_SYS_RAWIO) have their score divided by 4 - * if oom condition happened in one cpuset and checked process does not belong - to it, its score is divided by 8 - * the resulting score is multiplied by two to the power of oom_adj, i.e. - points <<= oom_adj when it is positive and - points >>= -(oom_adj) otherwise - -The task with the highest badness score is then selected and its children -are killed, process itself will be killed in an OOM situation when it does -not have children or some of them disabled oom like described above. +3.1 /proc/<pid>/oom_adj & /proc/<pid>/oom_score_adj- Adjust the oom-killer score +-------------------------------------------------------------------------------- + +These file can be used to adjust the badness heuristic used to select which +process gets killed in out of memory conditions. + +The badness heuristic assigns a value to each candidate task ranging from 0 +(never kill) to 1000 (always kill) to determine which process is targeted. The +units are roughly a proportion along that range of allowed memory the process +may allocate from based on an estimation of its current memory and swap use. +For example, if a task is using all allowed memory, its badness score will be +1000. If it is using half of its allowed memory, its score will be 500. + +There is an additional factor included in the badness score: root +processes are given 3% extra memory over other tasks. + +The amount of "allowed" memory depends on the context in which the oom killer +was called. If it is due to the memory assigned to the allocating task's cpuset +being exhausted, the allowed memory represents the set of mems assigned to that +cpuset. If it is due to a mempolicy's node(s) being exhausted, the allowed +memory represents the set of mempolicy nodes. If it is due to a memory +limit (or swap limit) being reached, the allowed memory is that configured +limit. Finally, if it is due to the entire system being out of memory, the +allowed memory represents all allocatable resources. + +The value of /proc/<pid>/oom_score_adj is added to the badness score before it +is used to determine which task to kill. Acceptable values range from -1000 +(OOM_SCORE_ADJ_MIN) to +1000 (OOM_SCORE_ADJ_MAX). This allows userspace to +polarize the preference for oom killing either by always preferring a certain +task or completely disabling it. The lowest possible value, -1000, is +equivalent to disabling oom killing entirely for that task since it will always +report a badness score of 0. + +Consequently, it is very simple for userspace to define the amount of memory to +consider for each task. Setting a /proc/<pid>/oom_score_adj value of +500, for +example, is roughly equivalent to allowing the remainder of tasks sharing the +same system, cpuset, mempolicy, or memory controller resources to use at least +50% more memory. A value of -500, on the other hand, would be roughly +equivalent to discounting 50% of the task's allowed memory from being considered +as scoring against the task. + +For backwards compatibility with previous kernels, /proc/<pid>/oom_adj may also +be used to tune the badness score. Its acceptable values range from -16 +(OOM_ADJUST_MIN) to +15 (OOM_ADJUST_MAX) and a special value of -17 +(OOM_DISABLE) to disable oom killing entirely for that task. Its value is +scaled linearly with /proc/<pid>/oom_score_adj. + +Writing to /proc/<pid>/oom_score_adj or /proc/<pid>/oom_adj will change the +other with its scaled value. + +NOTICE: /proc/<pid>/oom_adj is deprecated and will be removed, please see +Documentation/feature-removal-schedule.txt. + +Caveat: when a parent task is selected, the oom killer will sacrifice any first +generation children with seperate address spaces instead, if possible. This +avoids servers and important system daemons from being killed and loses the +minimal amount of work. + 3.2 /proc/<pid>/oom_score - Display current oom-killer score ------------------------------------------------------------- diff --git a/Documentation/filesystems/sysfs-pci.txt b/Documentation/filesystems/sysfs-pci.txt index 85354b32d731..74eaac26f8b8 100644 --- a/Documentation/filesystems/sysfs-pci.txt +++ b/Documentation/filesystems/sysfs-pci.txt @@ -39,7 +39,7 @@ files, each with their own function. local_cpus nearby CPU mask (cpumask, ro) remove remove device from kernel's list (ascii, wo) resource PCI resource host addresses (ascii, ro) - resource0..N PCI resource N, if present (binary, mmap) + resource0..N PCI resource N, if present (binary, mmap, rw[1]) resource0_wc..N_wc PCI WC map resource N, if prefetchable (binary, mmap) rom PCI ROM resource, if present (binary, ro) subsystem_device PCI subsystem device (ascii, ro) @@ -54,13 +54,16 @@ files, each with their own function. binary - file contains binary data cpumask - file contains a cpumask type +[1] rw for RESOURCE_IO (I/O port) regions only + The read only files are informational, writes to them will be ignored, with the exception of the 'rom' file. Writable files can be used to perform actions on the device (e.g. changing config space, detaching a device). mmapable files are available via an mmap of the file at offset 0 and can be used to do actual device programming from userspace. Note that some platforms don't support mmapping of certain resources, so be sure to check the return -value from any attempted mmap. +value from any attempted mmap. The most notable of these are I/O port +resources, which also provide read/write access. The 'enable' file provides a counter that indicates how many times the device has been enabled. If the 'enable' file currently returns '4', and a '1' is diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt index 931c806642c5..5d1335faec2d 100644 --- a/Documentation/filesystems/sysfs.txt +++ b/Documentation/filesystems/sysfs.txt @@ -4,7 +4,7 @@ sysfs - _The_ filesystem for exporting kernel objects. Patrick Mochel <mochel@osdl.org> Mike Murphy <mamurph@cs.clemson.edu> -Revised: 22 February 2009 +Revised: 15 July 2010 Original: 10 January 2003 @@ -124,7 +124,7 @@ show and store methods of the attribute owners. struct sysfs_ops { ssize_t (*show)(struct kobject *, struct attribute *, char *); - ssize_t (*store)(struct kobject *, struct attribute *, const char *); + ssize_t (*store)(struct kobject *, struct attribute *, const char *, size_t); }; [ Subsystems should have already defined a struct kobj_type as a @@ -139,18 +139,22 @@ calls the associated methods. To illustrate: +#define to_dev(obj) container_of(obj, struct device, kobj) #define to_dev_attr(_attr) container_of(_attr, struct device_attribute, attr) -#define to_dev(d) container_of(d, struct device, kobj) -static ssize_t -dev_attr_show(struct kobject * kobj, struct attribute * attr, char * buf) +static ssize_t dev_attr_show(struct kobject *kobj, struct attribute *attr, + char *buf) { - struct device_attribute * dev_attr = to_dev_attr(attr); - struct device * dev = to_dev(kobj); - ssize_t ret = 0; + struct device_attribute *dev_attr = to_dev_attr(attr); + struct device *dev = to_dev(kobj); + ssize_t ret = -EIO; if (dev_attr->show) - ret = dev_attr->show(dev, buf); + ret = dev_attr->show(dev, dev_attr, buf); + if (ret >= (ssize_t)PAGE_SIZE) { + print_symbol("dev_attr_show: %s returned bad count\n", + (unsigned long)dev_attr->show); + } return ret; } @@ -163,10 +167,9 @@ To read or write attributes, show() or store() methods must be specified when declaring the attribute. The method types should be as simple as those defined for device attributes: -ssize_t (*show)(struct device * dev, struct device_attribute * attr, - char * buf); -ssize_t (*store)(struct device * dev, struct device_attribute * attr, - const char * buf); +ssize_t (*show)(struct device *dev, struct device_attribute *attr, char *buf); +ssize_t (*store)(struct device *dev, struct device_attribute *attr, + const char *buf, size_t count); IOW, they should take only an object, an attribute, and a buffer as parameters. @@ -209,8 +212,8 @@ Other notes: - show() should always use snprintf(). -- store() should return the number of bytes used from the buffer. This - can be done using strlen(). +- store() should return the number of bytes used from the buffer. If the + entire buffer has been used, just return the count argument. - show() or store() can always return errors. If a bad value comes through, be sure to return an error. @@ -223,15 +226,18 @@ Other notes: A very simple (and naive) implementation of a device attribute is: -static ssize_t show_name(struct device *dev, struct device_attribute *attr, char *buf) +static ssize_t show_name(struct device *dev, struct device_attribute *attr, + char *buf) { return snprintf(buf, PAGE_SIZE, "%s\n", dev->name); } -static ssize_t store_name(struct device * dev, const char * buf) +static ssize_t store_name(struct device *dev, struct device_attribute *attr, + const char *buf, size_t count) { - sscanf(buf, "%20s", dev->name); - return strnlen(buf, PAGE_SIZE); + snprintf(dev->name, sizeof(dev->name), "%.*s", + (int)min(count, sizeof(dev->name) - 1), buf); + return count; } static DEVICE_ATTR(name, S_IRUGO, show_name, store_name); @@ -327,7 +333,7 @@ Structure: struct bus_attribute { struct attribute attr; ssize_t (*show)(struct bus_type *, char * buf); - ssize_t (*store)(struct bus_type *, const char * buf); + ssize_t (*store)(struct bus_type *, const char * buf, size_t count); }; Declaring: diff --git a/Documentation/firmware_class/hotplug-script b/Documentation/firmware_class/hotplug-script index 1990130f2ab1..8143a950b607 100644 --- a/Documentation/firmware_class/hotplug-script +++ b/Documentation/firmware_class/hotplug-script @@ -6,11 +6,12 @@ HOTPLUG_FW_DIR=/usr/lib/hotplug/firmware/ -echo 1 > /sys/$DEVPATH/loading -cat $HOTPLUG_FW_DIR/$FIRMWARE > /sys/$DEVPATH/data -echo 0 > /sys/$DEVPATH/loading - -# To cancel the load in case of error: -# -# echo -1 > /sys/$DEVPATH/loading -# +if [ "$SUBSYSTEM" == "firmware" -a "$ACTION" == "add" ]; then + if [ -f $HOTPLUG_FW_DIR/$FIRMWARE ]; then + echo 1 > /sys/$DEVPATH/loading + cat $HOTPLUG_FW_DIR/$FIRMWARE > /sys/$DEVPATH/data + echo 0 > /sys/$DEVPATH/loading + else + echo -1 > /sys/$DEVPATH/loading + fi +fi diff --git a/Documentation/hwmon/coretemp b/Documentation/hwmon/coretemp index 92267b62db59..25568f844804 100644 --- a/Documentation/hwmon/coretemp +++ b/Documentation/hwmon/coretemp @@ -21,8 +21,8 @@ Temperature is measured in degrees Celsius and measurement resolution is 1 degree C. Valid temperatures are from 0 to TjMax degrees C, because the actual value of temperature register is in fact a delta from TjMax. -Temperature known as TjMax is the maximum junction temperature of processor. -Intel defines this temperature as 85C or 100C. At this temperature, protection +Temperature known as TjMax is the maximum junction temperature of processor, +which depends on the CPU model. See table below. At this temperature, protection mechanism will perform actions to forcibly cool down the processor. Alarm may be raised, if the temperature grows enough (more than TjMax) to trigger the Out-Of-Spec bit. Following table summarizes the exported sysfs files: @@ -38,3 +38,104 @@ temp1_label - Contains string "Core X", where X is processor The TjMax temperature is set to 85 degrees C if undocumented model specific register (UMSR) 0xee has bit 30 set. If not the TjMax is 100 degrees C as (sometimes) documented in processor datasheet. + +Appendix A. Known TjMax lists (TBD): +Some information comes from ark.intel.com + +Process Processor TjMax(C) + +32nm Core i3/i5/i7 Processors + i7 660UM/640/620, 640LM/620, 620M, 610E 105 + i5 540UM/520/430, 540M/520/450/430 105 + i3 330E, 370M/350/330 90 rPGA, 105 BGA + i3 330UM 105 + +32nm Core i7 Extreme Processors + 980X 100 + +32nm Celeron Processors + U3400 105 + P4505/P4500 90 + +45nm Xeon Processors 5400 Quad-Core + X5492, X5482, X5472, X5470, X5460, X5450 85 + E5472, E5462, E5450/40/30/20/10/05 85 + L5408 95 + L5430, L5420, L5410 70 + +45nm Xeon Processors 5200 Dual-Core + X5282, X5272, X5270, X5260 90 + E5240 90 + E5205, E5220 70, 90 + L5240 70 + L5238, L5215 95 + +45nm Atom Processors + D525/510/425/410 100 + Z560/550/540/530P/530/520PT/520/515/510PT/510P 90 + Z510/500 90 + N475/470/455/450 100 + N280/270 90 + 330/230 125 + +45nm Core2 Processors + Solo ULV SU3500/3300 100 + T9900/9800/9600/9550/9500/9400/9300/8300/8100 105 + T6670/6500/6400 105 + T6600 90 + SU9600/9400/9300 105 + SP9600/9400 105 + SL9600/9400/9380/9300 105 + P9700/9600/9500/8800/8700/8600/8400/7570 105 + P7550/7450 90 + +45nm Core2 Quad Processors + Q9100/9000 100 + +45nm Core2 Extreme Processors + X9100/9000 105 + QX9300 100 + +45nm Core i3/i5/i7 Processors + i7 940XM/920 100 + i7 840QM/820/740/720 100 + +45nm Celeron Processors + SU2300 100 + 900 105 + +65nm Core2 Duo Processors + Solo U2200, U2100 100 + U7700/7600/7500 100 + T7800/7700/7600/7500/7400/7300/7250/7200/7100 100 + T5870/5670/5600/5550/5500/5470/5450/5300/5270 100 + T5250 100 + T5800/5750/5200 85 + L7700/7500/7400/7300/7200 100 + +65nm Core2 Extreme Processors + X7900/7800 100 + +65nm Core Duo Processors + U2500/2400 100 + T2700/2600/2450/2400/2350/2300E/2300/2250/2050 100 + L2500/2400/2300 100 + +65nm Core Solo Processors + U1500/1400/1300 100 + T1400/1350/1300/1250 100 + +65nm Xeon Processors 5000 Quad-Core + X5000 90-95 + E5000 80 + L5000 70 + L5318 95 + +65nm Xeon Processors 5000 Dual-Core + 5080, 5063, 5060, 5050, 5030 80-90 + 5160, 5150, 5148, 5140, 5130, 5120, 5110 80 + L5138 100 + +65nm Celeron Processors + T1700/1600 100 + 560/550/540/530 100 diff --git a/Documentation/hwmon/f71882fg b/Documentation/hwmon/f71882fg index a7952c2bd959..1a07fd674cd0 100644 --- a/Documentation/hwmon/f71882fg +++ b/Documentation/hwmon/f71882fg @@ -2,6 +2,10 @@ Kernel driver f71882fg ====================== Supported chips: + * Fintek F71808E + Prefix: 'f71808fg' + Addresses scanned: none, address read from Super I/O config space + Datasheet: Not public * Fintek F71858FG Prefix: 'f71858fg' Addresses scanned: none, address read from Super I/O config space diff --git a/Documentation/hwmon/jc42 b/Documentation/hwmon/jc42 new file mode 100644 index 000000000000..0e76ef12e4c6 --- /dev/null +++ b/Documentation/hwmon/jc42 @@ -0,0 +1,97 @@ +Kernel driver jc42 +================== + +Supported chips: + * Analog Devices ADT7408 + Prefix: 'adt7408' + Addresses scanned: I2C 0x18 - 0x1f + Datasheets: + http://www.analog.com/static/imported-files/data_sheets/ADT7408.pdf + * IDT TSE2002B3, TS3000B3 + Prefix: 'tse2002b3', 'ts3000b3' + Addresses scanned: I2C 0x18 - 0x1f + Datasheets: + http://www.idt.com/products/getdoc.cfm?docid=18715691 + http://www.idt.com/products/getdoc.cfm?docid=18715692 + * Maxim MAX6604 + Prefix: 'max6604' + Addresses scanned: I2C 0x18 - 0x1f + Datasheets: + http://datasheets.maxim-ic.com/en/ds/MAX6604.pdf + * Microchip MCP9805, MCP98242, MCP98243, MCP9843 + Prefixes: 'mcp9805', 'mcp98242', 'mcp98243', 'mcp9843' + Addresses scanned: I2C 0x18 - 0x1f + Datasheets: + http://ww1.microchip.com/downloads/en/DeviceDoc/21977b.pdf + http://ww1.microchip.com/downloads/en/DeviceDoc/21996a.pdf + http://ww1.microchip.com/downloads/en/DeviceDoc/22153c.pdf + * NXP Semiconductors SE97, SE97B + Prefix: 'se97' + Addresses scanned: I2C 0x18 - 0x1f + Datasheets: + http://www.nxp.com/documents/data_sheet/SE97.pdf + http://www.nxp.com/documents/data_sheet/SE97B.pdf + * NXP Semiconductors SE98 + Prefix: 'se98' + Addresses scanned: I2C 0x18 - 0x1f + Datasheets: + http://www.nxp.com/documents/data_sheet/SE98.pdf + * ON Semiconductor CAT34TS02, CAT6095 + Prefix: 'cat34ts02', 'cat6095' + Addresses scanned: I2C 0x18 - 0x1f + Datasheet: + http://www.onsemi.com/pub_link/Collateral/CAT34TS02-D.PDF + http://www.onsemi.com/pub/Collateral/CAT6095-D.PDF + * ST Microelectronics STTS424, STTS424E02 + Prefix: 'stts424' + Addresses scanned: I2C 0x18 - 0x1f + Datasheets: + http://www.st.com/stonline/products/literature/ds/13447/stts424.pdf + http://www.st.com/stonline/products/literature/ds/13448/stts424e02.pdf + * JEDEC JC 42.4 compliant temperature sensor chips + Prefix: 'jc42' + Addresses scanned: I2C 0x18 - 0x1f + Datasheet: - + +Author: + Guenter Roeck <guenter.roeck@ericsson.com> + + +Description +----------- + +This driver implements support for JEDEC JC 42.4 compliant temperature sensors. +The driver auto-detects the chips listed above, but can be manually instantiated +to support other JC 42.4 compliant chips. + +Example: the following will load the driver for a generic JC 42.4 compliant +temperature sensor at address 0x18 on I2C bus #1: + +# modprobe jc42 +# echo jc42 0x18 > /sys/bus/i2c/devices/i2c-1/new_device + +A JC 42.4 compliant chip supports a single temperature sensor. Minimum, maximum, +and critical temperature can be configured. There are alarms for high, low, +and critical thresholds. + +There is also an hysteresis to control the thresholds for resetting alarms. +Per JC 42.4 specification, the hysteresis threshold can be configured to 0, 1.5, +3.0, and 6.0 degrees C. Configured hysteresis values will be rounded to those +limits. The chip supports only a single register to configure the hysteresis, +which applies to all limits. This register can be written by writing into +temp1_crit_hyst. Other hysteresis attributes are read-only. + +Sysfs entries +------------- + +temp1_input Temperature (RO) +temp1_min Minimum temperature (RW) +temp1_max Maximum temperature (RW) +temp1_crit Critical high temperature (RW) + +temp1_crit_hyst Critical hysteresis temperature (RW) +temp1_max_hyst Maximum hysteresis temperature (RO) + +temp1_min_alarm Temperature low alarm +temp1_max_alarm Temperature high alarm +temp1_crit_alarm Temperature critical alarm diff --git a/Documentation/hwmon/pkgtemp b/Documentation/hwmon/pkgtemp new file mode 100644 index 000000000000..c8e1fb0fadd3 --- /dev/null +++ b/Documentation/hwmon/pkgtemp @@ -0,0 +1,36 @@ +Kernel driver pkgtemp +====================== + +Supported chips: + * Intel family + Prefix: 'pkgtemp' + CPUID: + Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual + Volume 3A: System Programming Guide + +Author: Fenghua Yu + +Description +----------- + +This driver permits reading package level temperature sensor embedded inside +Intel CPU package. The sensors can be in core, uncore, memory controller, or +other components in a package. The feature is first implemented in Intel Sandy +Bridge platform. + +Temperature is measured in degrees Celsius and measurement resolution is +1 degree C. Valid temperatures are from 0 to TjMax degrees C, because the actual +value of temperature register is in fact a delta from TjMax. + +Temperature known as TjMax is the maximum junction temperature of package. +We get this from MSR_IA32_TEMPERATURE_TARGET. If the MSR is not accessible, +we define TjMax as 100 degrees Celsius. At this temperature, protection +mechanism will perform actions to forcibly cool down the package. Alarm +may be raised, if the temperature grows enough (more than TjMax) to trigger +the Out-Of-Spec bit. Following table summarizes the exported sysfs files: + +temp1_input - Package temperature (in millidegrees Celsius). +temp1_max - All cooling devices should be turned on. +temp1_crit - Maximum junction temperature (in millidegrees Celsius). +temp1_crit_alarm - Set when Out-of-spec bit is set, never clears. + Correct CPU operation is no longer guaranteed. diff --git a/Documentation/hwmon/smm665 b/Documentation/hwmon/smm665 new file mode 100644 index 000000000000..3820fc9ca52d --- /dev/null +++ b/Documentation/hwmon/smm665 @@ -0,0 +1,157 @@ +Kernel driver smm665 +==================== + +Supported chips: + * Summit Microelectronics SMM465 + Prefix: 'smm465' + Addresses scanned: - + Datasheet: + http://www.summitmicro.com/prod_select/summary/SMM465/SMM465DS.pdf + * Summit Microelectronics SMM665, SMM665B + Prefix: 'smm665' + Addresses scanned: - + Datasheet: + http://www.summitmicro.com/prod_select/summary/SMM665/SMM665B_2089_20.pdf + * Summit Microelectronics SMM665C + Prefix: 'smm665c' + Addresses scanned: - + Datasheet: + http://www.summitmicro.com/prod_select/summary/SMM665C/SMM665C_2125.pdf + * Summit Microelectronics SMM764 + Prefix: 'smm764' + Addresses scanned: - + Datasheet: + http://www.summitmicro.com/prod_select/summary/SMM764/SMM764_2098.pdf + * Summit Microelectronics SMM766, SMM766B + Prefix: 'smm766' + Addresses scanned: - + Datasheets: + http://www.summitmicro.com/prod_select/summary/SMM766/SMM766_2086.pdf + http://www.summitmicro.com/prod_select/summary/SMM766B/SMM766B_2122.pdf + +Author: Guenter Roeck <guenter.roeck@ericsson.com> + + +Module Parameters +----------------- + +* vref: int + Default: 1250 (mV) + Reference voltage on VREF_ADC pin in mV. It should not be necessary to set + this parameter unless a non-default reference voltage is used. + + +Description +----------- + +[From datasheet] The SMM665 is an Active DC Output power supply Controller +that monitors, margins and cascade sequences power. The part monitors six +power supply channels as well as VDD, 12V input, two general-purpose analog +inputs and an internal temperature sensor using a 10-bit ADC. + +Each monitored channel has its own high and low limits, plus a critical +limit. + +Support for SMM465, SMM764, and SMM766 has been implemented but is untested. + + +Usage Notes +----------- + +This driver does not probe for devices, since there is no register which +can be safely used to identify the chip. You will have to instantiate +the devices explicitly. When instantiating the device, you have to specify +its configuration register address. + +Example: the following will load the driver for an SMM665 at address 0x57 +on I2C bus #1: +$ modprobe smm665 +$ echo smm665 0x57 > /sys/bus/i2c/devices/i2c-1/new_device + + +Sysfs entries +------------- + +This driver uses the values in the datasheet to convert ADC register values +into the values specified in the sysfs-interface document. All attributes are +read only. + +Min, max, lcrit, and crit values are used by the chip to trigger external signals +and/or other activity. Triggered signals can include HEALTHY, RST, Power Off, +or Fault depending on the chip configuration. The driver reports values as lcrit +or crit if exceeding the limits triggers RST, Power Off, or Fault, and as min or +max otherwise. For details please see the SMM665 datasheet. + +For SMM465 and SMM764, values for Channel E and F are reported but undefined. + +in1_input 12V input voltage (mV) +in2_input 3.3V (VDD) input voltage (mV) +in3_input Channel A voltage (mV) +in4_input Channel B voltage (mV) +in5_input Channel C voltage (mV) +in6_input Channel D voltage (mV) +in7_input Channel E voltage (mV) +in8_input Channel F voltage (mV) +in9_input AIN1 voltage (mV) +in10_input AIN2 voltage (mV) + +in1_min 12v input minimum voltage (mV) +in2_min 3.3V (VDD) input minimum voltage (mV) +in3_min Channel A minimum voltage (mV) +in4_min Channel B minimum voltage (mV) +in5_min Channel C minimum voltage (mV) +in6_min Channel D minimum voltage (mV) +in7_min Channel E minimum voltage (mV) +in8_min Channel F minimum voltage (mV) +in9_min AIN1 minimum voltage (mV) +in10_min AIN2 minimum voltage (mV) + +in1_max 12v input maximum voltage (mV) +in2_max 3.3V (VDD) input maximum voltage (mV) +in3_max Channel A maximum voltage (mV) +in4_max Channel B maximum voltage (mV) +in5_max Channel C maximum voltage (mV) +in6_max Channel D maximum voltage (mV) +in7_max Channel E maximum voltage (mV) +in8_max Channel F maximum voltage (mV) +in9_max AIN1 maximum voltage (mV) +in10_max AIN2 maximum voltage (mV) + +in1_lcrit 12v input critical minimum voltage (mV) +in2_lcrit 3.3V (VDD) input critical minimum voltage (mV) +in3_lcrit Channel A critical minimum voltage (mV) +in4_lcrit Channel B critical minimum voltage (mV) +in5_lcrit Channel C critical minimum voltage (mV) +in6_lcrit Channel D critical minimum voltage (mV) +in7_lcrit Channel E critical minimum voltage (mV) +in8_lcrit Channel F critical minimum voltage (mV) +in9_lcrit AIN1 critical minimum voltage (mV) +in10_lcrit AIN2 critical minimum voltage (mV) + +in1_crit 12v input critical maximum voltage (mV) +in2_crit 3.3V (VDD) input critical maximum voltage (mV) +in3_crit Channel A critical maximum voltage (mV) +in4_crit Channel B critical maximum voltage (mV) +in5_crit Channel C critical maximum voltage (mV) +in6_crit Channel D critical maximum voltage (mV) +in7_crit Channel E critical maximum voltage (mV) +in8_crit Channel F critical maximum voltage (mV) +in9_crit AIN1 critical maximum voltage (mV) +in10_crit AIN2 critical maximum voltage (mV) + +in1_crit_alarm 12v input critical alarm +in2_crit_alarm 3.3V (VDD) input critical alarm +in3_crit_alarm Channel A critical alarm +in4_crit_alarm Channel B critical alarm +in5_crit_alarm Channel C critical alarm +in6_crit_alarm Channel D critical alarm +in7_crit_alarm Channel E critical alarm +in8_crit_alarm Channel F critical alarm +in9_crit_alarm AIN1 critical alarm +in10_crit_alarm AIN2 critical alarm + +temp1_input Chip tempererature +temp1_min Mimimum chip tempererature +temp1_max Maximum chip tempererature +temp1_crit Critical chip tempererature +temp1_crit_alarm Temperature critical alarm diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 2ec3d7d89984..33223ff121d8 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -79,6 +79,7 @@ Code Seq#(hex) Include File Comments 0x22 all scsi/sg.h '#' 00-3F IEEE 1394 Subsystem Block for the entire subsystem '$' 00-0F linux/perf_counter.h, linux/perf_event.h +'&' 00-07 drivers/firewire/nosy-user.h '1' 00-1F <linux/timepps.h> PPS kit from Ulrich Windl <ftp://ftp.de.kernel.org/pub/linux/daemons/ntp/PPS/> '2' 01-04 linux/i2o.h diff --git a/Documentation/kbuild/kbuild.txt b/Documentation/kbuild/kbuild.txt index 634c625da8ce..1e5165aa9e4e 100644 --- a/Documentation/kbuild/kbuild.txt +++ b/Documentation/kbuild/kbuild.txt @@ -22,11 +22,33 @@ building C files and assembler files. KAFLAGS -------------------------------------------------- -Additional options to the assembler. +Additional options to the assembler (for built-in and modules). + +AFLAGS_MODULE +-------------------------------------------------- +Addtional module specific options to use for $(AS). + +AFLAGS_KERNEL +-------------------------------------------------- +Addtional options for $(AS) when used for assembler +code for code that is compiled as built-in. KCFLAGS -------------------------------------------------- -Additional options to the C compiler. +Additional options to the C compiler (for built-in and modules). + +CFLAGS_KERNEL +-------------------------------------------------- +Addtional options for $(CC) when used to compile +code that is compiled as built-in. + +CFLAGS_MODULE +-------------------------------------------------- +Addtional module specific options to use for $(CC). + +LDFLAGS_MODULE +-------------------------------------------------- +Additional options used for $(LD) when linking modules. KBUILD_VERBOSE -------------------------------------------------- @@ -40,15 +62,15 @@ Set the directory to look for the kernel source when building external modules. The directory can be specified in several ways: 1) Use "M=..." on the command line -2) Environmnet variable KBUILD_EXTMOD -3) Environmnet variable SUBDIRS +2) Environment variable KBUILD_EXTMOD +3) Environment variable SUBDIRS The possibilities are listed in the order they take precedence. Using "M=..." will always override the others. KBUILD_OUTPUT -------------------------------------------------- Specify the output directory when building the kernel. -The output directory can also be specificed using "O=...". +The output directory can also be specified using "O=...". Setting "O=..." takes precedence over KBUILD_OUTPUT. ARCH @@ -90,7 +112,7 @@ The script will be called with the following arguments: $3 - kernel map file $4 - default install path (use root directory if blank) -The implmentation of "make install" is architecture specific +The implementation of "make install" is architecture specific and it may differ from the above. INSTALLKERNEL is provided to enable the possibility to diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt index b2cb16ebcb16..cca46b1a0f6c 100644 --- a/Documentation/kbuild/kconfig.txt +++ b/Documentation/kbuild/kconfig.txt @@ -65,7 +65,7 @@ also use the environment variable KCONFIG_ALLCONFIG as a flag or a filename that contains config symbols that the user requires to be set to a specific value. If KCONFIG_ALLCONFIG is used without a filename, "make *config" checks for a file named -"all{yes/mod/no/random}.config" (corresponding to the *config command +"all{yes/mod/no/def/random}.config" (corresponding to the *config command that was used) for symbol values that are to be forced. If this file is not found, it checks for a file named "all.config" to contain forced values. diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 71c602d61680..c375313cb128 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -168,7 +168,7 @@ more details, with real examples. #drivers/isdn/i4l/Makefile # Makefile for the kernel ISDN subsystem and device drivers. # Each configuration option enables a list of files. - obj-$(CONFIG_ISDN) += isdn.o + obj-$(CONFIG_ISDN_I4L) += isdn.o obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o --- 3.3 Loadable module goals - obj-m @@ -187,34 +187,35 @@ more details, with real examples. Note: In this example $(CONFIG_ISDN_PPP_BSDCOMP) evaluates to 'm' If a kernel module is built from several source files, you specify - that you want to build a module in the same way as above. - - Kbuild needs to know which the parts that you want to build your - module from, so you have to tell it by setting an - $(<module_name>-objs) variable. + that you want to build a module in the same way as above; however, + kbuild needs to know which object files you want to build your + module from, so you have to tell it by setting a $(<module_name>-y) + variable. Example: #drivers/isdn/i4l/Makefile - obj-$(CONFIG_ISDN) += isdn.o - isdn-objs := isdn_net_lib.o isdn_v110.o isdn_common.o + obj-$(CONFIG_ISDN_I4L) += isdn.o + isdn-y := isdn_net_lib.o isdn_v110.o isdn_common.o In this example, the module name will be isdn.o. Kbuild will - compile the objects listed in $(isdn-objs) and then run + compile the objects listed in $(isdn-y) and then run "$(LD) -r" on the list of these files to generate isdn.o. - Kbuild recognises objects used for composite objects by the suffix - -objs, and the suffix -y. This allows the Makefiles to use - the value of a CONFIG_ symbol to determine if an object is part - of a composite object. + Due to kbuild recognizing $(<module_name>-y) for composite objects, + you can use the value of a CONFIG_ symbol to optionally include an + object file as part of a composite object. Example: #fs/ext2/Makefile - obj-$(CONFIG_EXT2_FS) += ext2.o - ext2-y := balloc.o bitmap.o - ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o + obj-$(CONFIG_EXT2_FS) += ext2.o + ext2-y := balloc.o dir.o file.o ialloc.o inode.o ioctl.o \ + namei.o super.o symlink.o + ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o xattr_user.o \ + xattr_trusted.o - In this example, xattr.o is only part of the composite object - ext2.o if $(CONFIG_EXT2_FS_XATTR) evaluates to 'y'. + In this example, xattr.o, xattr_user.o and xattr_trusted.o are only + part of the composite object ext2.o if $(CONFIG_EXT2_FS_XATTR) + evaluates to 'y'. Note: Of course, when you are building objects into the kernel, the syntax above will also work. So, if you have CONFIG_EXT2_FS=y, @@ -244,12 +245,12 @@ more details, with real examples. may contain both a built-in.o and a lib.a file. Example: - #arch/i386/lib/Makefile - lib-y := checksum.o delay.o + #arch/x86/lib/Makefile + lib-y := delay.o - This will create a library lib.a based on checksum.o and delay.o. - For kbuild to actually recognize that there is a lib.a being built, - the directory shall be listed in libs-y. + This will create a library lib.a based on delay.o. For kbuild to + actually recognize that there is a lib.a being built, the directory + shall be listed in libs-y. See also "6.3 List directories to visit when descending". Use of lib-y is normally restricted to lib/ and arch/*/lib. @@ -284,43 +285,40 @@ more details, with real examples. --- 3.7 Compilation flags ccflags-y, asflags-y and ldflags-y - The three flags listed above applies only to the kbuild makefile - where they are assigned. They are used for all the normal - cc, as and ld invocation happenign during a recursive build. + These three flags apply only to the kbuild makefile in which they + are assigned. They are used for all the normal cc, as and ld + invocations happening during a recursive build. Note: Flags with the same behaviour were previously named: EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS. - They are yet supported but their use are deprecated. + They are still supported but their usage is deprecated. - ccflags-y specifies options for compiling C files with $(CC). + ccflags-y specifies options for compiling with $(CC). Example: - # drivers/sound/emu10k1/Makefile - ccflags-y += -I$(obj) - ccflags-$(DEBUG) += -DEMU10K1_DEBUG - + # drivers/acpi/Makefile + ccflags-y := -Os + ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT This variable is necessary because the top Makefile owns the variable $(KBUILD_CFLAGS) and uses it for compilation flags for the entire tree. - asflags-y is a similar string for per-directory options - when compiling assembly language source. + asflags-y specifies options for assembling with $(AS). Example: - #arch/x86_64/kernel/Makefile - asflags-y := -traditional - + #arch/sparc/kernel/Makefile + asflags-y := -ansi - ldflags-y is a string for per-directory options to $(LD). + ldflags-y specifies options for linking with $(LD). Example: - #arch/m68k/fpsp040/Makefile - ldflags-y := -x + #arch/cris/boot/compressed/Makefile + ldflags-y += -T $(srctree)/$(src)/decompress_$(arch-y).lds subdir-ccflags-y, subdir-asflags-y - The two flags listed above are similar to ccflags-y and as-falgs-y. - The difference is that the subdir- variants has effect for the kbuild - file where tey are present and all subdirectories. + The two flags listed above are similar to ccflags-y and asflags-y. + The difference is that the subdir- variants have effect for the kbuild + file where they are present and all subdirectories. Options specified using subdir-* are added to the commandline before the options specified using the non-subdir variants. @@ -340,18 +338,18 @@ more details, with real examples. CFLAGS_aha152x.o = -DAHA152X_STAT -DAUTOCONF CFLAGS_gdth.o = # -DDEBUG_GDTH=2 -D__SERIAL__ -D__COM2__ \ -DGDTH_STATISTICS - CFLAGS_seagate.o = -DARBITRATE -DPARITY -DSEAGATE_USE_ASM - These three lines specify compilation flags for aha152x.o, - gdth.o, and seagate.o + These two lines specify compilation flags for aha152x.o and gdth.o. $(AFLAGS_$@) is a similar feature for source files in assembly languages. Example: # arch/arm/kernel/Makefile - AFLAGS_head-armv.o := -DTEXTADDR=$(TEXTADDR) -traditional - AFLAGS_head-armo.o := -DTEXTADDR=$(TEXTADDR) -traditional + AFLAGS_head.o := -DTEXT_OFFSET=$(TEXT_OFFSET) + AFLAGS_crunch-bits.o := -Wa,-mcpu=ep9312 + AFLAGS_iwmmxt.o := -Wa,-mcpu=iwmmxt + --- 3.9 Dependency tracking @@ -923,16 +921,33 @@ When kbuild executes, the following steps are followed (roughly): The first example utilises the trick that a config option expands to 'y' when selected. - CFLAGS_KERNEL $(CC) options specific for built-in + KBUILD_AFLAGS_KERNEL $(AS) options specific for built-in + + $(KBUILD_AFLAGS_KERNEL) contains extra C compiler flags used to compile + resident kernel code. + + KBUILD_AFLAGS_MODULE Options for $(AS) when building modules + + $(KBUILD_AFLAGS_MODULE) is used to add arch specific options that + are used for $(AS). + From commandline AFLAGS_MODULE shall be used (see kbuild.txt). - $(CFLAGS_KERNEL) contains extra C compiler flags used to compile + KBUILD_CFLAGS_KERNEL $(CC) options specific for built-in + + $(KBUILD_CFLAGS_KERNEL) contains extra C compiler flags used to compile resident kernel code. - CFLAGS_MODULE $(CC) options specific for modules + KBUILD_CFLAGS_MODULE Options for $(CC) when building modules + + $(KBUILD_CFLAGS_MODULE) is used to add arch specific options that + are used for $(CC). + From commandline CFLAGS_MODULE shall be used (see kbuild.txt). - $(CFLAGS_MODULE) contains extra C compiler flags used to compile code - for loadable kernel modules. + KBUILD_LDFLAGS_MODULE Options for $(LD) when linking modules + $(KBUILD_LDFLAGS_MODULE) is used to add arch specific options + used when linking modules. This is often a linker script. + From commandline LDFLAGS_MODULE shall be used (see kbuild.txt). --- 6.2 Add prerequisites to archprepare: @@ -1176,14 +1191,14 @@ When kbuild executes, the following steps are followed (roughly): === 7 Kbuild syntax for exported headers The kernel include a set of headers that is exported to userspace. -Many headers can be exported as-is but other headers requires a +Many headers can be exported as-is but other headers require 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__) +- drop all sections that are kernel internal (guarded by ifdef __KERNEL__) -Each relevant directory contain a file name "Kbuild" which specify the +Each relevant directory contains a file name "Kbuild" which specifies the headers to be exported. See subsequent chapter for the syntax of the Kbuild file. diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index d9239d5f3ad3..44f6b19c50bb 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -73,7 +73,6 @@ parameter is applicable: MTD MTD (Memory Technology Device) support is enabled. NET Appropriate network support is enabled. NUMA NUMA support is enabled. - GENERIC_TIME The generic timeofday code is enabled. NFS Appropriate NFS support is enabled. OSS OSS sound support is enabled. PV_OPS A paravirtualized kernel is enabled. @@ -116,6 +115,7 @@ parameter is applicable: More X86-64 boot options can be found in Documentation/x86/x86_64/boot-options.txt . X86 Either 32bit or 64bit x86 (same as X86-32+X86-64) + XEN Xen support is enabled In addition, the following text indicates that the option: @@ -281,19 +281,12 @@ 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. - ad1848= [HW,OSS] - Format: <io>,<irq>,<dma>,<dma2>,<type> - add_efi_memmap [EFI; X86] Include EFI memory map in kernel's map of available physical RAM. advansys= [HW,SCSI] See header of drivers/scsi/advansys.c. - aedsp16= [HW,OSS] Audio Excel DSP 16 - 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 @@ -312,6 +305,9 @@ and is between 256 and 4096 characters. It is defined in the file aic79xx= [HW,SCSI] See Documentation/scsi/aic79xx.txt. + ALSA [HW,ALSA] + See Documentation/sound/alsa/alsa-parameters.txt + alignment= [KNL,ARM] Allow the default userspace alignment fault handler behaviour to be specified. Bit 0 enables warnings, @@ -469,7 +465,7 @@ and is between 256 and 4096 characters. It is defined in the file clocksource is not available, it defaults to PIT. Format: { pit | tsc | cyclone | pmtmr } - clocksource= [GENERIC_TIME] Override the default clocksource + clocksource= Override the default clocksource Format: <string> Override the default clocksource and use the clocksource with the name specified. @@ -656,8 +652,6 @@ and is between 256 and 4096 characters. It is defined in the file 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. @@ -1144,9 +1138,12 @@ and is between 256 and 4096 characters. It is defined in the file kgdboc= [KGDB,HW] kgdb over consoles. Requires a tty driver that supports console polling, or a supported polling keyboard driver (non-usb). - Serial only format: <serial_device>[,baud] - keyboard only format: kbd - keyboard and serial format: kbd,<serial_device>[,baud] + Serial only format: <serial_device>[,baud] + keyboard only format: kbd + keyboard and serial format: kbd,<serial_device>[,baud] + Optional Kernel mode setting: + kms, kbd format: kms,kbd + kms, kbd and serial format: kms,kbd,<ser_dev>[,baud] kgdbwait [KGDB] Stop kernel execution and enter the kernel debugger at the earliest opportunity. @@ -1524,9 +1521,6 @@ and is between 256 and 4096 characters. It is defined in the file that the amount of memory usable for all allocations is not too small. - mpu401= [HW,OSS] - Format: <io>,<irq> - MTD_Partition= [MTD] Format: <name>,<region-number>,<size>,<offset> @@ -1812,6 +1806,8 @@ and is between 256 and 4096 characters. It is defined in the file nousb [USB] Disable the USB subsystem + nowatchdog [KNL] Disable the lockup detector. + nowb [ARM] nox2apic [X86-64,APIC] Do not enable x2APIC mode. @@ -1849,9 +1845,6 @@ and is between 256 and 4096 characters. It is defined in the file For example, to override I2C bus2: omap_mux=i2c2_scl.i2c2_scl=0x100,i2c2_sda.i2c2_sda=0x100 - opl3= [HW,OSS] - Format: <io> - oprofile.timer= [HW] Use timer interrupt instead of performance counters @@ -1863,6 +1856,9 @@ and is between 256 and 4096 characters. It is defined in the file perfmon on Intel CPUs instead of the CPU specific event set. + OSS [HW,OSS] + See Documentation/sound/oss/oss-parameters.txt + osst= [HW,SCSI] SCSI Tape Driver Format: <buffer_size>,<write_threshold> See also Documentation/scsi/st.txt. @@ -1899,9 +1895,6 @@ and is between 256 and 4096 characters. It is defined in the file Currently this function knows 686a and 8231 chips. Format: [spp|ps2|epp|ecp|ecpepp] - pas2= [HW,OSS] Format: - <io>,<irq>,<dma>,<dma16>,<sb_io>,<sb_irq>,<sb_dma>,<sb_dma16> - pas16= [HW,SCSI] See header of drivers/scsi/pas16.c. @@ -1970,6 +1963,8 @@ and is between 256 and 4096 characters. It is defined in the file norom [X86] Do not assign address space to expansion ROMs that do not already have BIOS assigned address ranges. + nobar [X86] Do not assign address space to the + BARs that weren't assigned by the BIOS. irqmask=0xMMMM [X86] Set a bit mask of IRQs allowed to be assigned automatically to PCI devices. You can make the kernel exclude IRQs of your ISA cards @@ -2171,10 +2166,6 @@ and is between 256 and 4096 characters. It is defined in the file [HW,MOUSE] Controls Logitech smartscroll autorepeat. 0 = disabled, 1 = enabled (default). - pss= [HW,OSS] Personal Sound System (ECHO ESC614) - Format: - <io>,<mss_io>,<mss_irq>,<mss_dma>,<mpu_io>,<mpu_irq> - pt. [PARIDE] See Documentation/blockdev/paride.txt. @@ -2390,128 +2381,6 @@ and is between 256 and 4096 characters. It is defined in the file 1: Fast pin select (default) 2: ATC IRMode - snd-ad1816a= [HW,ALSA] - - snd-ad1848= [HW,ALSA] - - snd-ali5451= [HW,ALSA] - - snd-als100= [HW,ALSA] - - snd-als4000= [HW,ALSA] - - snd-azt2320= [HW,ALSA] - - snd-cmi8330= [HW,ALSA] - - snd-cmipci= [HW,ALSA] - - snd-cs4231= [HW,ALSA] - - snd-cs4232= [HW,ALSA] - - snd-cs4236= [HW,ALSA] - - snd-cs4281= [HW,ALSA] - - snd-cs46xx= [HW,ALSA] - - snd-dt019x= [HW,ALSA] - - snd-dummy= [HW,ALSA] - - snd-emu10k1= [HW,ALSA] - - snd-ens1370= [HW,ALSA] - - snd-ens1371= [HW,ALSA] - - snd-es968= [HW,ALSA] - - snd-es1688= [HW,ALSA] - - snd-es18xx= [HW,ALSA] - - snd-es1938= [HW,ALSA] - - snd-es1968= [HW,ALSA] - - snd-fm801= [HW,ALSA] - - snd-gusclassic= [HW,ALSA] - - snd-gusextreme= [HW,ALSA] - - snd-gusmax= [HW,ALSA] - - snd-hdsp= [HW,ALSA] - - snd-ice1712= [HW,ALSA] - - snd-intel8x0= [HW,ALSA] - - snd-interwave= [HW,ALSA] - - snd-interwave-stb= - [HW,ALSA] - - snd-korg1212= [HW,ALSA] - - snd-maestro3= [HW,ALSA] - - snd-mpu401= [HW,ALSA] - - snd-mtpav= [HW,ALSA] - - snd-nm256= [HW,ALSA] - - snd-opl3sa2= [HW,ALSA] - - snd-opti92x-ad1848= - [HW,ALSA] - - snd-opti92x-cs4231= - [HW,ALSA] - - snd-opti93x= [HW,ALSA] - - snd-pmac= [HW,ALSA] - - snd-rme32= [HW,ALSA] - - snd-rme96= [HW,ALSA] - - snd-rme9652= [HW,ALSA] - - snd-sb8= [HW,ALSA] - - snd-sb16= [HW,ALSA] - - snd-sbawe= [HW,ALSA] - - snd-serial= [HW,ALSA] - - snd-sgalaxy= [HW,ALSA] - - snd-sonicvibes= [HW,ALSA] - - snd-sun-amd7930= - [HW,ALSA] - - snd-sun-cs4231= [HW,ALSA] - - snd-trident= [HW,ALSA] - - snd-usb-audio= [HW,ALSA,USB] - - snd-via82xx= [HW,ALSA] - - snd-virmidi= [HW,ALSA] - - snd-wavefront= [HW,ALSA] - - snd-ymfpci= [HW,ALSA] - softlockup_panic= [KNL] Should the soft-lockup detector generate panics. @@ -2526,9 +2395,6 @@ and is between 256 and 4096 characters. It is defined in the file spia_pedr= spia_peddr= - sscape= [HW,OSS] - Format: <io>,<irq>,<dma>,<mpu_io>,<mpu_irq> - st= [HW,SCSI] SCSI tape parameters (buffers, etc.) See Documentation/scsi/st.txt. @@ -2668,10 +2534,6 @@ and is between 256 and 4096 characters. It is defined in the file to facilitate early boot debugging. See also Documentation/trace/events.txt - trix= [HW,OSS] MediaTrix AudioTrix Pro - Format: - <io>,<irq>,<dma>,<dma2>,<sb_io>,<sb_irq>,<sb_dma>,<mpu_io>,<mpu_irq> - tsc= Disable clocksource-must-verify flag for TSC. Format: <string> [x86] reliable: mark tsc clocksource as reliable, this @@ -2688,12 +2550,6 @@ and is between 256 and 4096 characters. It is defined in the file u14-34f= [HW,SCSI] UltraStor 14F/34F SCSI host adapter See header of drivers/scsi/u14-34f.c. - uart401= [HW,OSS] - Format: <io>,<irq> - - uart6850= [HW,OSS] - Format: <io>,<irq> - uhash_entries= [KNL,NET] Set number of hash buckets for UDP/UDP-Lite connections @@ -2859,9 +2715,6 @@ and is between 256 and 4096 characters. It is defined in the file overridden by individual drivers. 0 will hide cursors, 1 will display them. - waveartist= [HW,OSS] - Format: <io>,<irq>,<dma>,<dma2> - wd33c93= [HW,SCSI] See header of drivers/scsi/wd33c93.c. @@ -2886,6 +2739,16 @@ and is between 256 and 4096 characters. It is defined in the file xd= [HW,XT] Original XT pre-IDE (RLL encoded) disks. xd_geo= See header of drivers/block/xd.c. + xen_emul_unplug= [HW,X86,XEN] + Unplug Xen emulated devices + Format: [unplug0,][unplug1] + ide-disks -- unplug primary master IDE devices + aux-ide-disks -- unplug non-primary-master IDE devices + nics -- unplug network devices + all -- unplug all emulated devices (NICs and IDE disks) + ignore -- continue loading the Xen platform PCI driver even + if the version check failed + xirc2ps_cs= [NET,PCMCIA] Format: <irq>,<irq_mask>,<io>,<full_duplex>,<do_sound>,<lockup_hack>[,<irq2>[,<irq3>[,<irq4>]]] @@ -2894,5 +2757,4 @@ ______________________________________________________________________ TODO: - Add documentation for ALSA options. Add more DRM drivers. diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt index 6653017680dd..1762b81fcdf2 100644 --- a/Documentation/kprobes.txt +++ b/Documentation/kprobes.txt @@ -285,6 +285,7 @@ architectures: - sparc64 (Return probes not yet implemented.) - arm - ppc +- mips 3. Configuring Kprobes diff --git a/Documentation/networking/dns_resolver.txt b/Documentation/networking/dns_resolver.txt new file mode 100644 index 000000000000..aefd1e681804 --- /dev/null +++ b/Documentation/networking/dns_resolver.txt @@ -0,0 +1,146 @@ + =================== + DNS Resolver Module + =================== + +Contents: + + - Overview. + - Compilation. + - Setting up. + - Usage. + - Mechanism. + - Debugging. + + +======== +OVERVIEW +======== + +The DNS resolver module provides a way for kernel services to make DNS queries +by way of requesting a key of key type dns_resolver. These queries are +upcalled to userspace through /sbin/request-key. + +These routines must be supported by userspace tools dns.upcall, cifs.upcall and +request-key. It is under development and does not yet provide the full feature +set. The features it does support include: + + (*) Implements the dns_resolver key_type to contact userspace. + +It does not yet support the following AFS features: + + (*) Dns query support for AFSDB resource record. + +This code is extracted from the CIFS filesystem. + + +=========== +COMPILATION +=========== + +The module should be enabled by turning on the kernel configuration options: + + CONFIG_DNS_RESOLVER - tristate "DNS Resolver support" + + +========== +SETTING UP +========== + +To set up this facility, the /etc/request-key.conf file must be altered so that +/sbin/request-key can appropriately direct the upcalls. For example, to handle +basic dname to IPv4/IPv6 address resolution, the following line should be +added: + + #OP TYPE DESC CO-INFO PROGRAM ARG1 ARG2 ARG3 ... + #====== ============ ======= ======= ========================== + create dns_resolver * * /usr/sbin/cifs.upcall %k + +To direct a query for query type 'foo', a line of the following should be added +before the more general line given above as the first match is the one taken. + + create dns_resolver foo:* * /usr/sbin/dns.foo %k + + + +===== +USAGE +===== + +To make use of this facility, one of the following functions that are +implemented in the module can be called after doing: + + #include <linux/dns_resolver.h> + + (1) int dns_query(const char *type, const char *name, size_t namelen, + const char *options, char **_result, time_t *_expiry); + + This is the basic access function. It looks for a cached DNS query and if + it doesn't find it, it upcalls to userspace to make a new DNS query, which + may then be cached. The key description is constructed as a string of the + form: + + [<type>:]<name> + + where <type> optionally specifies the particular upcall program to invoke, + and thus the type of query to do, and <name> specifies the string to be + looked up. The default query type is a straight hostname to IP address + set lookup. + + The name parameter is not required to be a NUL-terminated string, and its + length should be given by the namelen argument. + + The options parameter may be NULL or it may be a set of options + appropriate to the query type. + + The return value is a string appropriate to the query type. For instance, + for the default query type it is just a list of comma-separated IPv4 and + IPv6 addresses. The caller must free the result. + + The length of the result string is returned on success, and a negative + error code is returned otherwise. -EKEYREJECTED will be returned if the + DNS lookup failed. + + If _expiry is non-NULL, the expiry time (TTL) of the result will be + returned also. + + +========= +MECHANISM +========= + +The dnsresolver module registers a key type called "dns_resolver". Keys of +this type are used to transport and cache DNS lookup results from userspace. + +When dns_query() is invoked, it calls request_key() to search the local +keyrings for a cached DNS result. If that fails to find one, it upcalls to +userspace to get a new result. + +Upcalls to userspace are made through the request_key() upcall vector, and are +directed by means of configuration lines in /etc/request-key.conf that tell +/sbin/request-key what program to run to instantiate the key. + +The upcall handler program is responsible for querying the DNS, processing the +result into a form suitable for passing to the keyctl_instantiate_key() +routine. This then passes the data to dns_resolver_instantiate() which strips +off and processes any options included in the data, and then attaches the +remainder of the string to the key as its payload. + +The upcall handler program should set the expiry time on the key to that of the +lowest TTL of all the records it has extracted a result from. This means that +the key will be discarded and recreated when the data it holds has expired. + +dns_query() returns a copy of the value attached to the key, or an error if +that is indicated instead. + +See <file:Documentation/keys-request-key.txt> for further information about +request-key function. + + +========= +DEBUGGING +========= + +Debugging messages can be turned on dynamically by writing a 1 into the +following file: + + /sys/module/dnsresolver/parameters/debug diff --git a/Documentation/pcmcia/driver-changes.txt b/Documentation/pcmcia/driver-changes.txt index 61bc4e943116..26c0f9c00545 100644 --- a/Documentation/pcmcia/driver-changes.txt +++ b/Documentation/pcmcia/driver-changes.txt @@ -1,4 +1,16 @@ This file details changes in 2.6 which affect PCMCIA card driver authors: +* pcmcia_request_io changes (as of 2.6.36) + Instead of io_req_t, drivers are now requested to fill out + struct pcmcia_device *p_dev->resource[0,1] for up to two ioport + ranges. After a call to pcmcia_request_io(), the ports found there + are reserved, after calling pcmcia_request_configuration(), they may + be used. + +* No dev_info_t, no cs_types.h (as of 2.6.36) + dev_info_t and a few other typedefs are removed. No longer use them + in PCMCIA device drivers. Also, do not include pcmcia/cs_types.h, as + this file is gone. + * No dev_node_t (as of 2.6.35) There is no more need to fill out a "dev_node_t" structure. diff --git a/Documentation/powerpc/dts-bindings/fsl/diu.txt b/Documentation/powerpc/dts-bindings/fsl/diu.txt index deb35de70988..b66cb6d31d69 100644 --- a/Documentation/powerpc/dts-bindings/fsl/diu.txt +++ b/Documentation/powerpc/dts-bindings/fsl/diu.txt @@ -4,10 +4,17 @@ The Freescale DIU is a LCD controller, with proper hardware, it can also drive DVI monitors. Required properties: -- compatible : should be "fsl-diu". +- compatible : should be "fsl,diu" or "fsl,mpc5121-diu". - reg : should contain at least address and length of the DIU register set. -- Interrupts : one DIU interrupt should be describe here. +- interrupts : one DIU interrupt should be described here. +- interrupt-parent : the phandle for the interrupt controller that + services interrupts for this device. + +Optional properties: +- edid : verbatim EDID data block describing attached display. + Data from the detailed timing descriptor will be used to + program the display controller. Example (MPC8610HPCD): display@2c000 { @@ -16,3 +23,12 @@ Example (MPC8610HPCD): interrupts = <72 2>; interrupt-parent = <&mpic>; }; + +Example for MPC5121: + display@2100 { + compatible = "fsl,mpc5121-diu"; + reg = <0x2100 0x100>; + interrupts = <64 0x8>; + interrupt-parent = <&ipic>; + edid = [edid-data]; + }; diff --git a/Documentation/powerpc/dts-bindings/fsl/i2c.txt b/Documentation/powerpc/dts-bindings/fsl/i2c.txt index 50da20310585..1eacd6b20ed5 100644 --- a/Documentation/powerpc/dts-bindings/fsl/i2c.txt +++ b/Documentation/powerpc/dts-bindings/fsl/i2c.txt @@ -20,6 +20,7 @@ Recommended properties : - fsl,preserve-clocking : boolean; if defined, the clock settings from the bootloader are preserved (not touched). - clock-frequency : desired I2C bus clock frequency in Hz. + - fsl,timeout : I2C bus timeout in microseconds. Examples : @@ -59,4 +60,5 @@ Examples : interrupts = <43 2>; interrupt-parent = <&mpic>; clock-frequency = <400000>; + fsl,timeout = <10000>; }; diff --git a/Documentation/slow-work.txt b/Documentation/slow-work.txt deleted file mode 100644 index 9dbf4470c7e1..000000000000 --- a/Documentation/slow-work.txt +++ /dev/null @@ -1,322 +0,0 @@ - ==================================== - SLOW WORK ITEM EXECUTION THREAD POOL - ==================================== - -By: David Howells <dhowells@redhat.com> - -The slow work item execution thread pool is a pool of threads for performing -things that take a relatively long time, such as making mkdir calls. -Typically, when processing something, these items will spend a lot of time -blocking a thread on I/O, thus making that thread unavailable for doing other -work. - -The standard workqueue model is unsuitable for this class of work item as that -limits the owner to a single thread or a single thread per CPU. For some -tasks, however, more threads - or fewer - are required. - -There is just one pool per system. It contains no threads unless something -wants to use it - and that something must register its interest first. When -the pool is active, the number of threads it contains is dynamic, varying -between a maximum and minimum setting, depending on the load. - - -==================== -CLASSES OF WORK ITEM -==================== - -This pool support two classes of work items: - - (*) Slow work items. - - (*) Very slow work items. - -The former are expected to finish much quicker than the latter. - -An operation of the very slow class may do a batch combination of several -lookups, mkdirs, and a create for instance. - -An operation of the ordinarily slow class may, for example, write stuff or -expand files, provided the time taken to do so isn't too long. - -Operations of both types may sleep during execution, thus tying up the thread -loaned to it. - -A further class of work item is available, based on the slow work item class: - - (*) Delayed slow work items. - -These are slow work items that have a timer to defer queueing of the item for -a while. - - -THREAD-TO-CLASS ALLOCATION --------------------------- - -Not all the threads in the pool are available to work on very slow work items. -The number will be between one and one fewer than the number of active threads. -This is configurable (see the "Pool Configuration" section). - -All the threads are available to work on ordinarily slow work items, but a -percentage of the threads will prefer to work on very slow work items. - -The configuration ensures that at least one thread will be available to work on -very slow work items, and at least one thread will be available that won't work -on very slow work items at all. - - -===================== -USING SLOW WORK ITEMS -===================== - -Firstly, a module or subsystem wanting to make use of slow work items must -register its interest: - - int ret = slow_work_register_user(struct module *module); - -This will return 0 if successful, or a -ve error upon failure. The module -pointer should be the module interested in using this facility (almost -certainly THIS_MODULE). - - -Slow work items may then be set up by: - - (1) Declaring a slow_work struct type variable: - - #include <linux/slow-work.h> - - struct slow_work myitem; - - (2) Declaring the operations to be used for this item: - - struct slow_work_ops myitem_ops = { - .get_ref = myitem_get_ref, - .put_ref = myitem_put_ref, - .execute = myitem_execute, - }; - - [*] For a description of the ops, see section "Item Operations". - - (3) Initialising the item: - - slow_work_init(&myitem, &myitem_ops); - - or: - - delayed_slow_work_init(&myitem, &myitem_ops); - - or: - - vslow_work_init(&myitem, &myitem_ops); - - depending on its class. - -A suitably set up work item can then be enqueued for processing: - - int ret = slow_work_enqueue(&myitem); - -This will return a -ve error if the thread pool is unable to gain a reference -on the item, 0 otherwise, or (for delayed work): - - int ret = delayed_slow_work_enqueue(&myitem, my_jiffy_delay); - - -The items are reference counted, so there ought to be no need for a flush -operation. But as the reference counting is optional, means to cancel -existing work items are also included: - - cancel_slow_work(&myitem); - cancel_delayed_slow_work(&myitem); - -can be used to cancel pending work. The above cancel function waits for -existing work to have been executed (or prevent execution of them, depending -on timing). - - -When all a module's slow work items have been processed, and the -module has no further interest in the facility, it should unregister its -interest: - - slow_work_unregister_user(struct module *module); - -The module pointer is used to wait for all outstanding work items for that -module before completing the unregistration. This prevents the put_ref() code -from being taken away before it completes. module should almost certainly be -THIS_MODULE. - - -================ -HELPER FUNCTIONS -================ - -The slow-work facility provides a function by which it can be determined -whether or not an item is queued for later execution: - - bool queued = slow_work_is_queued(struct slow_work *work); - -If it returns false, then the item is not on the queue (it may be executing -with a requeue pending). This can be used to work out whether an item on which -another depends is on the queue, thus allowing a dependent item to be queued -after it. - -If the above shows an item on which another depends not to be queued, then the -owner of the dependent item might need to wait. However, to avoid locking up -the threads unnecessarily be sleeping in them, it can make sense under some -circumstances to return the work item to the queue, thus deferring it until -some other items have had a chance to make use of the yielded thread. - -To yield a thread and defer an item, the work function should simply enqueue -the work item again and return. However, this doesn't work if there's nothing -actually on the queue, as the thread just vacated will jump straight back into -the item's work function, thus busy waiting on a CPU. - -Instead, the item should use the thread to wait for the dependency to go away, -but rather than using schedule() or schedule_timeout() to sleep, it should use -the following function: - - bool requeue = slow_work_sleep_till_thread_needed( - struct slow_work *work, - signed long *_timeout); - -This will add a second wait and then sleep, such that it will be woken up if -either something appears on the queue that could usefully make use of the -thread - and behind which this item can be queued, or if the event the caller -set up to wait for happens. True will be returned if something else appeared -on the queue and this work function should perhaps return, of false if -something else woke it up. The timeout is as for schedule_timeout(). - -For example: - - wq = bit_waitqueue(&my_flags, MY_BIT); - init_wait(&wait); - requeue = false; - do { - prepare_to_wait(wq, &wait, TASK_UNINTERRUPTIBLE); - if (!test_bit(MY_BIT, &my_flags)) - break; - requeue = slow_work_sleep_till_thread_needed(&my_work, - &timeout); - } while (timeout > 0 && !requeue); - finish_wait(wq, &wait); - if (!test_bit(MY_BIT, &my_flags) - goto do_my_thing; - if (requeue) - return; // to slow_work - - -=============== -ITEM OPERATIONS -=============== - -Each work item requires a table of operations of type struct slow_work_ops. -Only ->execute() is required; the getting and putting of a reference and the -describing of an item are all optional. - - (*) Get a reference on an item: - - int (*get_ref)(struct slow_work *work); - - This allows the thread pool to attempt to pin an item by getting a - reference on it. This function should return 0 if the reference was - granted, or a -ve error otherwise. If an error is returned, - slow_work_enqueue() will fail. - - The reference is held whilst the item is queued and whilst it is being - executed. The item may then be requeued with the same reference held, or - the reference will be released. - - (*) Release a reference on an item: - - void (*put_ref)(struct slow_work *work); - - This allows the thread pool to unpin an item by releasing the reference on - it. The thread pool will not touch the item again once this has been - called. - - (*) Execute an item: - - void (*execute)(struct slow_work *work); - - This should perform the work required of the item. It may sleep, it may - perform disk I/O and it may wait for locks. - - (*) View an item through /proc: - - void (*desc)(struct slow_work *work, struct seq_file *m); - - If supplied, this should print to 'm' a small string describing the work - the item is to do. This should be no more than about 40 characters, and - shouldn't include a newline character. - - See the 'Viewing executing and queued items' section below. - - -================== -POOL CONFIGURATION -================== - -The slow-work thread pool has a number of configurables: - - (*) /proc/sys/kernel/slow-work/min-threads - - The minimum number of threads that should be in the pool whilst it is in - use. This may be anywhere between 2 and max-threads. - - (*) /proc/sys/kernel/slow-work/max-threads - - The maximum number of threads that should in the pool. This may be - anywhere between min-threads and 255 or NR_CPUS * 2, whichever is greater. - - (*) /proc/sys/kernel/slow-work/vslow-percentage - - The percentage of active threads in the pool that may be used to execute - very slow work items. This may be between 1 and 99. The resultant number - is bounded to between 1 and one fewer than the number of active threads. - This ensures there is always at least one thread that can process very - slow work items, and always at least one thread that won't. - - -================================== -VIEWING EXECUTING AND QUEUED ITEMS -================================== - -If CONFIG_SLOW_WORK_DEBUG is enabled, a debugfs file is made available: - - /sys/kernel/debug/slow_work/runqueue - -through which the list of work items being executed and the queues of items to -be executed may be viewed. The owner of a work item is given the chance to -add some information of its own. - -The contents look something like the following: - - THR PID ITEM ADDR FL MARK DESC - === ===== ================ == ===== ========== - 0 3005 ffff880023f52348 a 952ms FSC: OBJ17d3: LOOK - 1 3006 ffff880024e33668 2 160ms FSC: OBJ17e5 OP60d3b: Write1/Store fl=2 - 2 3165 ffff8800296dd180 a 424ms FSC: OBJ17e4: LOOK - 3 4089 ffff8800262c8d78 a 212ms FSC: OBJ17ea: CRTN - 4 4090 ffff88002792bed8 2 388ms FSC: OBJ17e8 OP60d36: Write1/Store fl=2 - 5 4092 ffff88002a0ef308 2 388ms FSC: OBJ17e7 OP60d2e: Write1/Store fl=2 - 6 4094 ffff88002abaf4b8 2 132ms FSC: OBJ17e2 OP60d4e: Write1/Store fl=2 - 7 4095 ffff88002bb188e0 a 388ms FSC: OBJ17e9: CRTN - vsq - ffff880023d99668 1 308ms FSC: OBJ17e0 OP60f91: Write1/EnQ fl=2 - vsq - ffff8800295d1740 1 212ms FSC: OBJ16be OP4d4b6: Write1/EnQ fl=2 - vsq - ffff880025ba3308 1 160ms FSC: OBJ179a OP58dec: Write1/EnQ fl=2 - vsq - ffff880024ec83e0 1 160ms FSC: OBJ17ae OP599f2: Write1/EnQ fl=2 - vsq - ffff880026618e00 1 160ms FSC: OBJ17e6 OP60d33: Write1/EnQ fl=2 - vsq - ffff880025a2a4b8 1 132ms FSC: OBJ16a2 OP4d583: Write1/EnQ fl=2 - vsq - ffff880023cbe6d8 9 212ms FSC: OBJ17eb: LOOK - vsq - ffff880024d37590 9 212ms FSC: OBJ17ec: LOOK - vsq - ffff880027746cb0 9 212ms FSC: OBJ17ed: LOOK - vsq - ffff880024d37ae8 9 212ms FSC: OBJ17ee: LOOK - vsq - ffff880024d37cb0 9 212ms FSC: OBJ17ef: LOOK - vsq - ffff880025036550 9 212ms FSC: OBJ17f0: LOOK - vsq - ffff8800250368e0 9 212ms FSC: OBJ17f1: LOOK - vsq - ffff880025036aa8 9 212ms FSC: OBJ17f2: LOOK - -In the 'THR' column, executing items show the thread they're occupying and -queued threads indicate which queue they're on. 'PID' shows the process ID of -a slow-work thread that's executing something. 'FL' shows the work item flags. -'MARK' indicates how long since an item was queued or began executing. Lastly, -the 'DESC' column permits the owner of an item to give some information. - diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 1d38b0dfba95..03771d7c5dd7 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -114,6 +114,11 @@ ALC662/663/272 samsung-nc10 Samsung NC10 mini notebook auto auto-config reading BIOS (default) +ALC680 +====== + base Base model (ASUS NX90) + auto auto-config reading BIOS (default) + ALC882/883/885/888/889 ====================== 3stack-dig 3-jack with SPDIF I/O @@ -282,6 +287,7 @@ Conexant 5051 hp HP Spartan laptop hp-dv6736 HP dv6736 hp-f700 HP Compaq Presario F700 + ideapad Lenovo IdeaPad laptop lenovo-x200 Lenovo X200 laptop toshiba Toshiba Satellite M300 diff --git a/Documentation/sound/alsa/Procfile.txt b/Documentation/sound/alsa/Procfile.txt index 07301de12cc4..7fcd1ad96fcc 100644 --- a/Documentation/sound/alsa/Procfile.txt +++ b/Documentation/sound/alsa/Procfile.txt @@ -103,6 +103,8 @@ card*/pcm*/xrun_debug bit 2 = Enable additional jiffies check bit 3 = Log hwptr update at each period interrupt bit 4 = Log hwptr update at each snd_pcm_update_hw_ptr() + bit 5 = Show last 10 positions on error + bit 6 = Do above only once When the bit 0 is set, the driver will show the messages to kernel log when an xrun is detected. The debug message is @@ -122,6 +124,12 @@ card*/pcm*/xrun_debug Bits 3 and 4 are for logging the hwptr records. Note that these will give flood of kernel messages. + When bit 5 is set, the driver logs the last 10 xrun errors and + the proc file shows each jiffies, position, period_size, + buffer_size, old_hw_ptr, and hw_ptr_base values. + + When bit 6 is set, the full xrun log is shown only once. + card*/pcm*/sub*/info The general information of this PCM sub-stream. diff --git a/Documentation/sound/alsa/alsa-parameters.txt b/Documentation/sound/alsa/alsa-parameters.txt new file mode 100644 index 000000000000..0fa40679b080 --- /dev/null +++ b/Documentation/sound/alsa/alsa-parameters.txt @@ -0,0 +1,135 @@ + ALSA Kernel Parameters + ~~~~~~~~~~~~~~~~~~~~~~ + +See Documentation/kernel-parameters.txt for general information on +specifying module parameters. + +This document may not be entirely up to date and comprehensive. The command +"modinfo -p ${modulename}" shows a current list of all parameters of a loadable +module. Loadable modules, after being loaded into the running kernel, also +reveal their parameters in /sys/module/${modulename}/parameters/. Some of these +parameters may be changed at runtime by the command +"echo -n ${value} > /sys/module/${modulename}/parameters/${parm}". + + + snd-ad1816a= [HW,ALSA] + + snd-ad1848= [HW,ALSA] + + snd-ali5451= [HW,ALSA] + + snd-als100= [HW,ALSA] + + snd-als4000= [HW,ALSA] + + snd-azt2320= [HW,ALSA] + + snd-cmi8330= [HW,ALSA] + + snd-cmipci= [HW,ALSA] + + snd-cs4231= [HW,ALSA] + + snd-cs4232= [HW,ALSA] + + snd-cs4236= [HW,ALSA] + + snd-cs4281= [HW,ALSA] + + snd-cs46xx= [HW,ALSA] + + snd-dt019x= [HW,ALSA] + + snd-dummy= [HW,ALSA] + + snd-emu10k1= [HW,ALSA] + + snd-ens1370= [HW,ALSA] + + snd-ens1371= [HW,ALSA] + + snd-es968= [HW,ALSA] + + snd-es1688= [HW,ALSA] + + snd-es18xx= [HW,ALSA] + + snd-es1938= [HW,ALSA] + + snd-es1968= [HW,ALSA] + + snd-fm801= [HW,ALSA] + + snd-gusclassic= [HW,ALSA] + + snd-gusextreme= [HW,ALSA] + + snd-gusmax= [HW,ALSA] + + snd-hdsp= [HW,ALSA] + + snd-ice1712= [HW,ALSA] + + snd-intel8x0= [HW,ALSA] + + snd-interwave= [HW,ALSA] + + snd-interwave-stb= + [HW,ALSA] + + snd-korg1212= [HW,ALSA] + + snd-maestro3= [HW,ALSA] + + snd-mpu401= [HW,ALSA] + + snd-mtpav= [HW,ALSA] + + snd-nm256= [HW,ALSA] + + snd-opl3sa2= [HW,ALSA] + + snd-opti92x-ad1848= + [HW,ALSA] + + snd-opti92x-cs4231= + [HW,ALSA] + + snd-opti93x= [HW,ALSA] + + snd-pmac= [HW,ALSA] + + snd-rme32= [HW,ALSA] + + snd-rme96= [HW,ALSA] + + snd-rme9652= [HW,ALSA] + + snd-sb8= [HW,ALSA] + + snd-sb16= [HW,ALSA] + + snd-sbawe= [HW,ALSA] + + snd-serial= [HW,ALSA] + + snd-sgalaxy= [HW,ALSA] + + snd-sonicvibes= [HW,ALSA] + + snd-sun-amd7930= + [HW,ALSA] + + snd-sun-cs4231= [HW,ALSA] + + snd-trident= [HW,ALSA] + + snd-usb-audio= [HW,ALSA,USB] + + snd-via82xx= [HW,ALSA] + + snd-virmidi= [HW,ALSA] + + snd-wavefront= [HW,ALSA] + + snd-ymfpci= [HW,ALSA] diff --git a/Documentation/sound/oss/oss-parameters.txt b/Documentation/sound/oss/oss-parameters.txt new file mode 100644 index 000000000000..3ab391e7c295 --- /dev/null +++ b/Documentation/sound/oss/oss-parameters.txt @@ -0,0 +1,51 @@ + OSS Kernel Parameters + ~~~~~~~~~~~~~~~~~~~~~ + +See Documentation/kernel-parameters.txt for general information on +specifying module parameters. + +This document may not be entirely up to date and comprehensive. The command +"modinfo -p ${modulename}" shows a current list of all parameters of a loadable +module. Loadable modules, after being loaded into the running kernel, also +reveal their parameters in /sys/module/${modulename}/parameters/. Some of these +parameters may be changed at runtime by the command +"echo -n ${value} > /sys/module/${modulename}/parameters/${parm}". + + + ad1848= [HW,OSS] + Format: <io>,<irq>,<dma>,<dma2>,<type> + + aedsp16= [HW,OSS] Audio Excel DSP 16 + Format: <io>,<irq>,<dma>,<mss_io>,<mpu_io>,<mpu_irq> + See also header of sound/oss/aedsp16.c. + + dmasound= [HW,OSS] Sound subsystem buffers + + mpu401= [HW,OSS] + Format: <io>,<irq> + + opl3= [HW,OSS] + Format: <io> + + pas2= [HW,OSS] Format: + <io>,<irq>,<dma>,<dma16>,<sb_io>,<sb_irq>,<sb_dma>,<sb_dma16> + + pss= [HW,OSS] Personal Sound System (ECHO ESC614) + Format: + <io>,<mss_io>,<mss_irq>,<mss_dma>,<mpu_io>,<mpu_irq> + + sscape= [HW,OSS] + Format: <io>,<irq>,<dma>,<mpu_io>,<mpu_irq> + + trix= [HW,OSS] MediaTrix AudioTrix Pro + Format: + <io>,<irq>,<dma>,<dma2>,<sb_io>,<sb_irq>,<sb_dma>,<mpu_io>,<mpu_irq> + + uart401= [HW,OSS] + Format: <io>,<irq> + + uart6850= [HW,OSS] + Format: <io>,<irq> + + waveartist= [HW,OSS] + Format: <io>,<irq>,<dma>,<dma2> diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index 82b2da18c45d..b606c2c4dd37 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -511,7 +511,7 @@ information may not be desired. If this is set to non-zero, this information is shown whenever the OOM killer actually kills a memory-hogging task. -The default value is 0. +The default value is 1 (enabled). ============================================================== diff --git a/Documentation/timers/timers-howto.txt b/Documentation/timers/timers-howto.txt new file mode 100644 index 000000000000..c9ef29d2ede3 --- /dev/null +++ b/Documentation/timers/timers-howto.txt @@ -0,0 +1,105 @@ +delays - Information on the various kernel delay / sleep mechanisms +------------------------------------------------------------------- + +This document seeks to answer the common question: "What is the +RightWay (TM) to insert a delay?" + +This question is most often faced by driver writers who have to +deal with hardware delays and who may not be the most intimately +familiar with the inner workings of the Linux Kernel. + + +Inserting Delays +---------------- + +The first, and most important, question you need to ask is "Is my +code in an atomic context?" This should be followed closely by "Does +it really need to delay in atomic context?" If so... + +ATOMIC CONTEXT: + You must use the *delay family of functions. These + functions use the jiffie estimation of clock speed + and will busy wait for enough loop cycles to achieve + the desired delay: + + ndelay(unsigned long nsecs) + udelay(unsigned long usecs) + mdelay(unsgined long msecs) + + udelay is the generally preferred API; ndelay-level + precision may not actually exist on many non-PC devices. + + mdelay is macro wrapper around udelay, to account for + possible overflow when passing large arguments to udelay. + In general, use of mdelay is discouraged and code should + be refactored to allow for the use of msleep. + +NON-ATOMIC CONTEXT: + You should use the *sleep[_range] family of functions. + There are a few more options here, while any of them may + work correctly, using the "right" sleep function will + help the scheduler, power management, and just make your + driver better :) + + -- Backed by busy-wait loop: + udelay(unsigned long usecs) + -- Backed by hrtimers: + usleep_range(unsigned long min, unsigned long max) + -- Backed by jiffies / legacy_timers + msleep(unsigned long msecs) + msleep_interruptible(unsigned long msecs) + + Unlike the *delay family, the underlying mechanism + driving each of these calls varies, thus there are + quirks you should be aware of. + + + SLEEPING FOR "A FEW" USECS ( < ~10us? ): + * Use udelay + + - Why not usleep? + On slower systems, (embedded, OR perhaps a speed- + stepped PC!) the overhead of setting up the hrtimers + for usleep *may* not be worth it. Such an evaluation + will obviously depend on your specific situation, but + it is something to be aware of. + + SLEEPING FOR ~USECS OR SMALL MSECS ( 10us - 20ms): + * Use usleep_range + + - Why not msleep for (1ms - 20ms)? + Explained originally here: + http://lkml.org/lkml/2007/8/3/250 + msleep(1~20) may not do what the caller intends, and + will often sleep longer (~20 ms actual sleep for any + value given in the 1~20ms range). In many cases this + is not the desired behavior. + + - Why is there no "usleep" / What is a good range? + Since usleep_range is built on top of hrtimers, the + wakeup will be very precise (ish), thus a simple + usleep function would likely introduce a large number + of undesired interrupts. + + With the introduction of a range, the scheduler is + free to coalesce your wakeup with any other wakeup + that may have happened for other reasons, or at the + worst case, fire an interrupt for your upper bound. + + The larger a range you supply, the greater a chance + that you will not trigger an interrupt; this should + be balanced with what is an acceptable upper bound on + delay / performance for your specific code path. Exact + tolerances here are very situation specific, thus it + is left to the caller to determine a reasonable range. + + SLEEPING FOR LARGER MSECS ( 10ms+ ) + * Use msleep or possibly msleep_interruptible + + - What's the difference? + msleep sets the current task to TASK_UNINTERRUPTIBLE + whereas msleep_interruptible sets the current task to + TASK_INTERRUPTIBLE before scheduling the sleep. In + short, the difference is whether the sleep can be ended + early by a signal. In general, just use msleep unless + you know you have a need for the interruptible variant. diff --git a/Documentation/trace/ftrace-design.txt b/Documentation/trace/ftrace-design.txt index f1f81afee8a0..dc52bd442c92 100644 --- a/Documentation/trace/ftrace-design.txt +++ b/Documentation/trace/ftrace-design.txt @@ -13,6 +13,9 @@ Note that this focuses on architecture implementation details only. If you want more explanation of a feature in terms of common code, review the common ftrace.txt file. +Ideally, everyone who wishes to retain performance while supporting tracing in +their kernel should make it all the way to dynamic ftrace support. + Prerequisites ------------- @@ -215,7 +218,7 @@ An arch may pass in a unique value (frame pointer) to both the entering and exiting of a function. On exit, the value is compared and if it does not match, then it will panic the kernel. This is largely a sanity check for bad code generation with gcc. If gcc for your port sanely updates the frame -pointer under different opitmization levels, then ignore this option. +pointer under different optimization levels, then ignore this option. However, adding support for it isn't terribly difficult. In your assembly code that calls prepare_ftrace_return(), pass the frame pointer as the 3rd argument. @@ -234,7 +237,7 @@ If you can't trace NMI functions, then skip this option. HAVE_SYSCALL_TRACEPOINTS ---------------------- +------------------------ You need very few things to get the syscalls tracing in an arch. @@ -250,12 +253,152 @@ You need very few things to get the syscalls tracing in an arch. HAVE_FTRACE_MCOUNT_RECORD ------------------------- -See scripts/recordmcount.pl for more info. +See scripts/recordmcount.pl for more info. Just fill in the arch-specific +details for how to locate the addresses of mcount call sites via objdump. +This option doesn't make much sense without also implementing dynamic ftrace. + +HAVE_DYNAMIC_FTRACE +------------------- + +You will first need HAVE_FTRACE_MCOUNT_RECORD and HAVE_FUNCTION_TRACER, so +scroll your reader back up if you got over eager. + +Once those are out of the way, you will need to implement: + - asm/ftrace.h: + - MCOUNT_ADDR + - ftrace_call_adjust() + - struct dyn_arch_ftrace{} + - asm code: + - mcount() (new stub) + - ftrace_caller() + - ftrace_call() + - ftrace_stub() + - C code: + - ftrace_dyn_arch_init() + - ftrace_make_nop() + - ftrace_make_call() + - ftrace_update_ftrace_func() + +First you will need to fill out some arch details in your asm/ftrace.h. + +Define MCOUNT_ADDR as the address of your mcount symbol similar to: + #define MCOUNT_ADDR ((unsigned long)mcount) +Since no one else will have a decl for that function, you will need to: + extern void mcount(void); + +You will also need the helper function ftrace_call_adjust(). Most people +will be able to stub it out like so: + static inline unsigned long ftrace_call_adjust(unsigned long addr) + { + return addr; + } <details to be filled> +Lastly you will need the custom dyn_arch_ftrace structure. If you need +some extra state when runtime patching arbitrary call sites, this is the +place. For now though, create an empty struct: + struct dyn_arch_ftrace { + /* No extra data needed */ + }; + +With the header out of the way, we can fill out the assembly code. While we +did already create a mcount() function earlier, dynamic ftrace only wants a +stub function. This is because the mcount() will only be used during boot +and then all references to it will be patched out never to return. Instead, +the guts of the old mcount() will be used to create a new ftrace_caller() +function. Because the two are hard to merge, it will most likely be a lot +easier to have two separate definitions split up by #ifdefs. Same goes for +the ftrace_stub() as that will now be inlined in ftrace_caller(). + +Before we get confused anymore, let's check out some pseudo code so you can +implement your own stuff in assembly: -HAVE_DYNAMIC_FTRACE ---------------------- +void mcount(void) +{ + return; +} + +void ftrace_caller(void) +{ + /* implement HAVE_FUNCTION_TRACE_MCOUNT_TEST if you desire */ + + /* save all state needed by the ABI (see paragraph above) */ + + unsigned long frompc = ...; + unsigned long selfpc = <return address> - MCOUNT_INSN_SIZE; + +ftrace_call: + ftrace_stub(frompc, selfpc); + + /* restore all state needed by the ABI */ + +ftrace_stub: + return; +} + +This might look a little odd at first, but keep in mind that we will be runtime +patching multiple things. First, only functions that we actually want to trace +will be patched to call ftrace_caller(). Second, since we only have one tracer +active at a time, we will patch the ftrace_caller() function itself to call the +specific tracer in question. That is the point of the ftrace_call label. + +With that in mind, let's move on to the C code that will actually be doing the +runtime patching. You'll need a little knowledge of your arch's opcodes in +order to make it through the next section. + +Every arch has an init callback function. If you need to do something early on +to initialize some state, this is the time to do that. Otherwise, this simple +function below should be sufficient for most people: + +int __init ftrace_dyn_arch_init(void *data) +{ + /* return value is done indirectly via data */ + *(unsigned long *)data = 0; + + return 0; +} + +There are two functions that are used to do runtime patching of arbitrary +functions. The first is used to turn the mcount call site into a nop (which +is what helps us retain runtime performance when not tracing). The second is +used to turn the mcount call site into a call to an arbitrary location (but +typically that is ftracer_caller()). See the general function definition in +linux/ftrace.h for the functions: + ftrace_make_nop() + ftrace_make_call() +The rec->ip value is the address of the mcount call site that was collected +by the scripts/recordmcount.pl during build time. + +The last function is used to do runtime patching of the active tracer. This +will be modifying the assembly code at the location of the ftrace_call symbol +inside of the ftrace_caller() function. So you should have sufficient padding +at that location to support the new function calls you'll be inserting. Some +people will be using a "call" type instruction while others will be using a +"branch" type instruction. Specifically, the function is: + ftrace_update_ftrace_func() + + +HAVE_DYNAMIC_FTRACE + HAVE_FUNCTION_GRAPH_TRACER +------------------------------------------------ + +The function grapher needs a few tweaks in order to work with dynamic ftrace. +Basically, you will need to: + - update: + - ftrace_caller() + - ftrace_graph_call() + - ftrace_graph_caller() + - implement: + - ftrace_enable_ftrace_graph_caller() + - ftrace_disable_ftrace_graph_caller() <details to be filled> +Quick notes: + - add a nop stub after the ftrace_call location named ftrace_graph_call; + stub needs to be large enough to support a call to ftrace_graph_caller() + - update ftrace_graph_caller() to work with being called by the new + ftrace_caller() since some semantics may have changed + - ftrace_enable_ftrace_graph_caller() will runtime patch the + ftrace_graph_call location with a call to ftrace_graph_caller() + - ftrace_disable_ftrace_graph_caller() will runtime patch the + ftrace_graph_call location with nops diff --git a/Documentation/trace/kmemtrace.txt b/Documentation/trace/kmemtrace.txt deleted file mode 100644 index 6308735e58ca..000000000000 --- a/Documentation/trace/kmemtrace.txt +++ /dev/null @@ -1,126 +0,0 @@ - kmemtrace - Kernel Memory Tracer - - by Eduard - Gabriel Munteanu - <eduard.munteanu@linux360.ro> - -I. Introduction -=============== - -kmemtrace helps kernel developers figure out two things: -1) how different allocators (SLAB, SLUB etc.) perform -2) how kernel code allocates memory and how much - -To do this, we trace every allocation and export information to the userspace -through the relay interface. We export things such as the number of requested -bytes, the number of bytes actually allocated (i.e. including internal -fragmentation), whether this is a slab allocation or a plain kmalloc() and so -on. - -The actual analysis is performed by a userspace tool (see section III for -details on where to get it from). It logs the data exported by the kernel, -processes it and (as of writing this) can provide the following information: -- the total amount of memory allocated and fragmentation per call-site -- the amount of memory allocated and fragmentation per allocation -- total memory allocated and fragmentation in the collected dataset -- number of cross-CPU allocation and frees (makes sense in NUMA environments) - -Moreover, it can potentially find inconsistent and erroneous behavior in -kernel code, such as using slab free functions on kmalloc'ed memory or -allocating less memory than requested (but not truly failed allocations). - -kmemtrace also makes provisions for tracing on some arch and analysing the -data on another. - -II. Design and goals -==================== - -kmemtrace was designed to handle rather large amounts of data. Thus, it uses -the relay interface to export whatever is logged to userspace, which then -stores it. Analysis and reporting is done asynchronously, that is, after the -data is collected and stored. By design, it allows one to log and analyse -on different machines and different arches. - -As of writing this, the ABI is not considered stable, though it might not -change much. However, no guarantees are made about compatibility yet. When -deemed stable, the ABI should still allow easy extension while maintaining -backward compatibility. This is described further in Documentation/ABI. - -Summary of design goals: - - allow logging and analysis to be done across different machines - - be fast and anticipate usage in high-load environments (*) - - be reasonably extensible - - make it possible for GNU/Linux distributions to have kmemtrace - included in their repositories - -(*) - one of the reasons Pekka Enberg's original userspace data analysis - tool's code was rewritten from Perl to C (although this is more than a - simple conversion) - - -III. Quick usage guide -====================== - -1) Get a kernel that supports kmemtrace and build it accordingly (i.e. enable -CONFIG_KMEMTRACE). - -2) Get the userspace tool and build it: -$ git clone git://repo.or.cz/kmemtrace-user.git # current repository -$ cd kmemtrace-user/ -$ ./autogen.sh -$ ./configure -$ make - -3) Boot the kmemtrace-enabled kernel if you haven't, preferably in the -'single' runlevel (so that relay buffers don't fill up easily), and run -kmemtrace: -# '$' does not mean user, but root here. -$ mount -t debugfs none /sys/kernel/debug -$ mount -t proc none /proc -$ cd path/to/kmemtrace-user/ -$ ./kmemtraced -Wait a bit, then stop it with CTRL+C. -$ cat /sys/kernel/debug/kmemtrace/total_overruns # Check if we didn't - # overrun, should - # be zero. -$ (Optionally) [Run kmemtrace_check separately on each cpu[0-9]*.out file to - check its correctness] -$ ./kmemtrace-report - -Now you should have a nice and short summary of how the allocator performs. - -IV. FAQ and known issues -======================== - -Q: 'cat /sys/kernel/debug/kmemtrace/total_overruns' is non-zero, how do I fix -this? Should I worry? -A: If it's non-zero, this affects kmemtrace's accuracy, depending on how -large the number is. You can fix it by supplying a higher -'kmemtrace.subbufs=N' kernel parameter. ---- - -Q: kmemtrace_check reports errors, how do I fix this? Should I worry? -A: This is a bug and should be reported. It can occur for a variety of -reasons: - - possible bugs in relay code - - possible misuse of relay by kmemtrace - - timestamps being collected unorderly -Or you may fix it yourself and send us a patch. ---- - -Q: kmemtrace_report shows many errors, how do I fix this? Should I worry? -A: This is a known issue and I'm working on it. These might be true errors -in kernel code, which may have inconsistent behavior (e.g. allocating memory -with kmem_cache_alloc() and freeing it with kfree()). Pekka Enberg pointed -out this behavior may work with SLAB, but may fail with other allocators. - -It may also be due to lack of tracing in some unusual allocator functions. - -We don't want bug reports regarding this issue yet. ---- - -V. See also -=========== - -Documentation/kernel-parameters.txt -Documentation/ABI/testing/debugfs-kmemtrace - diff --git a/Documentation/trace/kprobetrace.txt b/Documentation/trace/kprobetrace.txt index ec94748ae65b..5f77d94598dd 100644 --- a/Documentation/trace/kprobetrace.txt +++ b/Documentation/trace/kprobetrace.txt @@ -42,7 +42,7 @@ Synopsis of kprobe_events +|-offs(FETCHARG) : Fetch memory at FETCHARG +|- offs address.(**) NAME=FETCHARG : Set NAME as the argument name of FETCHARG. FETCHARG:TYPE : Set TYPE as the type of FETCHARG. Currently, basic types - (u8/u16/u32/u64/s8/s16/s32/s64) are supported. + (u8/u16/u32/u64/s8/s16/s32/s64) and string are supported. (*) only for return probe. (**) this is useful for fetching a field of data structures. diff --git a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl new file mode 100644 index 000000000000..1b55146d1c8d --- /dev/null +++ b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl @@ -0,0 +1,686 @@ +#!/usr/bin/perl +# This is a POC for reading the text representation of trace output related to +# page reclaim. It makes an attempt to extract some high-level information on +# what is going on. The accuracy of the parser may vary +# +# Example usage: trace-vmscan-postprocess.pl < /sys/kernel/debug/tracing/trace_pipe +# other options +# --read-procstat If the trace lacks process info, get it from /proc +# --ignore-pid Aggregate processes of the same name together +# +# Copyright (c) IBM Corporation 2009 +# Author: Mel Gorman <mel@csn.ul.ie> +use strict; +use Getopt::Long; + +# Tracepoint events +use constant MM_VMSCAN_DIRECT_RECLAIM_BEGIN => 1; +use constant MM_VMSCAN_DIRECT_RECLAIM_END => 2; +use constant MM_VMSCAN_KSWAPD_WAKE => 3; +use constant MM_VMSCAN_KSWAPD_SLEEP => 4; +use constant MM_VMSCAN_LRU_SHRINK_ACTIVE => 5; +use constant MM_VMSCAN_LRU_SHRINK_INACTIVE => 6; +use constant MM_VMSCAN_LRU_ISOLATE => 7; +use constant MM_VMSCAN_WRITEPAGE_FILE_SYNC => 8; +use constant MM_VMSCAN_WRITEPAGE_ANON_SYNC => 9; +use constant MM_VMSCAN_WRITEPAGE_FILE_ASYNC => 10; +use constant MM_VMSCAN_WRITEPAGE_ANON_ASYNC => 11; +use constant MM_VMSCAN_WRITEPAGE_ASYNC => 12; +use constant EVENT_UNKNOWN => 13; + +# Per-order events +use constant MM_VMSCAN_DIRECT_RECLAIM_BEGIN_PERORDER => 11; +use constant MM_VMSCAN_WAKEUP_KSWAPD_PERORDER => 12; +use constant MM_VMSCAN_KSWAPD_WAKE_PERORDER => 13; +use constant HIGH_KSWAPD_REWAKEUP_PERORDER => 14; + +# Constants used to track state +use constant STATE_DIRECT_BEGIN => 15; +use constant STATE_DIRECT_ORDER => 16; +use constant STATE_KSWAPD_BEGIN => 17; +use constant STATE_KSWAPD_ORDER => 18; + +# High-level events extrapolated from tracepoints +use constant HIGH_DIRECT_RECLAIM_LATENCY => 19; +use constant HIGH_KSWAPD_LATENCY => 20; +use constant HIGH_KSWAPD_REWAKEUP => 21; +use constant HIGH_NR_SCANNED => 22; +use constant HIGH_NR_TAKEN => 23; +use constant HIGH_NR_RECLAIM => 24; +use constant HIGH_NR_CONTIG_DIRTY => 25; + +my %perprocesspid; +my %perprocess; +my %last_procmap; +my $opt_ignorepid; +my $opt_read_procstat; + +my $total_wakeup_kswapd; +my ($total_direct_reclaim, $total_direct_nr_scanned); +my ($total_direct_latency, $total_kswapd_latency); +my ($total_direct_writepage_file_sync, $total_direct_writepage_file_async); +my ($total_direct_writepage_anon_sync, $total_direct_writepage_anon_async); +my ($total_kswapd_nr_scanned, $total_kswapd_wake); +my ($total_kswapd_writepage_file_sync, $total_kswapd_writepage_file_async); +my ($total_kswapd_writepage_anon_sync, $total_kswapd_writepage_anon_async); + +# Catch sigint and exit on request +my $sigint_report = 0; +my $sigint_exit = 0; +my $sigint_pending = 0; +my $sigint_received = 0; +sub sigint_handler { + my $current_time = time; + if ($current_time - 2 > $sigint_received) { + print "SIGINT received, report pending. Hit ctrl-c again to exit\n"; + $sigint_report = 1; + } else { + if (!$sigint_exit) { + print "Second SIGINT received quickly, exiting\n"; + } + $sigint_exit++; + } + + if ($sigint_exit > 3) { + print "Many SIGINTs received, exiting now without report\n"; + exit; + } + + $sigint_received = $current_time; + $sigint_pending = 1; +} +$SIG{INT} = "sigint_handler"; + +# Parse command line options +GetOptions( + 'ignore-pid' => \$opt_ignorepid, + 'read-procstat' => \$opt_read_procstat, +); + +# Defaults for dynamically discovered regex's +my $regex_direct_begin_default = 'order=([0-9]*) may_writepage=([0-9]*) gfp_flags=([A-Z_|]*)'; +my $regex_direct_end_default = 'nr_reclaimed=([0-9]*)'; +my $regex_kswapd_wake_default = 'nid=([0-9]*) order=([0-9]*)'; +my $regex_kswapd_sleep_default = 'nid=([0-9]*)'; +my $regex_wakeup_kswapd_default = 'nid=([0-9]*) zid=([0-9]*) order=([0-9]*)'; +my $regex_lru_isolate_default = 'isolate_mode=([0-9]*) order=([0-9]*) nr_requested=([0-9]*) nr_scanned=([0-9]*) nr_taken=([0-9]*) contig_taken=([0-9]*) contig_dirty=([0-9]*) contig_failed=([0-9]*)'; +my $regex_lru_shrink_inactive_default = 'lru=([A-Z_]*) nr_scanned=([0-9]*) nr_reclaimed=([0-9]*) priority=([0-9]*)'; +my $regex_lru_shrink_active_default = 'lru=([A-Z_]*) nr_scanned=([0-9]*) nr_rotated=([0-9]*) priority=([0-9]*)'; +my $regex_writepage_default = 'page=([0-9a-f]*) pfn=([0-9]*) flags=([A-Z_|]*)'; + +# Dyanically discovered regex +my $regex_direct_begin; +my $regex_direct_end; +my $regex_kswapd_wake; +my $regex_kswapd_sleep; +my $regex_wakeup_kswapd; +my $regex_lru_isolate; +my $regex_lru_shrink_inactive; +my $regex_lru_shrink_active; +my $regex_writepage; + +# Static regex used. Specified like this for readability and for use with /o +# (process_pid) (cpus ) ( time ) (tpoint ) (details) +my $regex_traceevent = '\s*([a-zA-Z0-9-]*)\s*(\[[0-9]*\])\s*([0-9.]*):\s*([a-zA-Z_]*):\s*(.*)'; +my $regex_statname = '[-0-9]*\s\((.*)\).*'; +my $regex_statppid = '[-0-9]*\s\(.*\)\s[A-Za-z]\s([0-9]*).*'; + +sub generate_traceevent_regex { + my $event = shift; + my $default = shift; + my $regex; + + # Read the event format or use the default + if (!open (FORMAT, "/sys/kernel/debug/tracing/events/$event/format")) { + print("WARNING: Event $event format string not found\n"); + return $default; + } else { + my $line; + while (!eof(FORMAT)) { + $line = <FORMAT>; + $line =~ s/, REC->.*//; + if ($line =~ /^print fmt:\s"(.*)".*/) { + $regex = $1; + $regex =~ s/%s/\([0-9a-zA-Z|_]*\)/g; + $regex =~ s/%p/\([0-9a-f]*\)/g; + $regex =~ s/%d/\([-0-9]*\)/g; + $regex =~ s/%ld/\([-0-9]*\)/g; + $regex =~ s/%lu/\([0-9]*\)/g; + } + } + } + + # Can't handle the print_flags stuff but in the context of this + # script, it really doesn't matter + $regex =~ s/\(REC.*\) \? __print_flags.*//; + + # Verify fields are in the right order + my $tuple; + foreach $tuple (split /\s/, $regex) { + my ($key, $value) = split(/=/, $tuple); + my $expected = shift; + if ($key ne $expected) { + print("WARNING: Format not as expected for event $event '$key' != '$expected'\n"); + $regex =~ s/$key=\((.*)\)/$key=$1/; + } + } + + if (defined shift) { + die("Fewer fields than expected in format"); + } + + return $regex; +} + +$regex_direct_begin = generate_traceevent_regex( + "vmscan/mm_vmscan_direct_reclaim_begin", + $regex_direct_begin_default, + "order", "may_writepage", + "gfp_flags"); +$regex_direct_end = generate_traceevent_regex( + "vmscan/mm_vmscan_direct_reclaim_end", + $regex_direct_end_default, + "nr_reclaimed"); +$regex_kswapd_wake = generate_traceevent_regex( + "vmscan/mm_vmscan_kswapd_wake", + $regex_kswapd_wake_default, + "nid", "order"); +$regex_kswapd_sleep = generate_traceevent_regex( + "vmscan/mm_vmscan_kswapd_sleep", + $regex_kswapd_sleep_default, + "nid"); +$regex_wakeup_kswapd = generate_traceevent_regex( + "vmscan/mm_vmscan_wakeup_kswapd", + $regex_wakeup_kswapd_default, + "nid", "zid", "order"); +$regex_lru_isolate = generate_traceevent_regex( + "vmscan/mm_vmscan_lru_isolate", + $regex_lru_isolate_default, + "isolate_mode", "order", + "nr_requested", "nr_scanned", "nr_taken", + "contig_taken", "contig_dirty", "contig_failed"); +$regex_lru_shrink_inactive = generate_traceevent_regex( + "vmscan/mm_vmscan_lru_shrink_inactive", + $regex_lru_shrink_inactive_default, + "nid", "zid", + "lru", + "nr_scanned", "nr_reclaimed", "priority"); +$regex_lru_shrink_active = generate_traceevent_regex( + "vmscan/mm_vmscan_lru_shrink_active", + $regex_lru_shrink_active_default, + "nid", "zid", + "lru", + "nr_scanned", "nr_rotated", "priority"); +$regex_writepage = generate_traceevent_regex( + "vmscan/mm_vmscan_writepage", + $regex_writepage_default, + "page", "pfn", "flags"); + +sub read_statline($) { + my $pid = $_[0]; + my $statline; + + if (open(STAT, "/proc/$pid/stat")) { + $statline = <STAT>; + close(STAT); + } + + if ($statline eq '') { + $statline = "-1 (UNKNOWN_PROCESS_NAME) R 0"; + } + + return $statline; +} + +sub guess_process_pid($$) { + my $pid = $_[0]; + my $statline = $_[1]; + + if ($pid == 0) { + return "swapper-0"; + } + + if ($statline !~ /$regex_statname/o) { + die("Failed to math stat line for process name :: $statline"); + } + return "$1-$pid"; +} + +# Convert sec.usec timestamp format +sub timestamp_to_ms($) { + my $timestamp = $_[0]; + + my ($sec, $usec) = split (/\./, $timestamp); + return ($sec * 1000) + ($usec / 1000); +} + +sub process_events { + my $traceevent; + my $process_pid; + my $cpus; + my $timestamp; + my $tracepoint; + my $details; + my $statline; + + # Read each line of the event log +EVENT_PROCESS: + while ($traceevent = <STDIN>) { + if ($traceevent =~ /$regex_traceevent/o) { + $process_pid = $1; + $timestamp = $3; + $tracepoint = $4; + + $process_pid =~ /(.*)-([0-9]*)$/; + my $process = $1; + my $pid = $2; + + if ($process eq "") { + $process = $last_procmap{$pid}; + $process_pid = "$process-$pid"; + } + $last_procmap{$pid} = $process; + + if ($opt_read_procstat) { + $statline = read_statline($pid); + if ($opt_read_procstat && $process eq '') { + $process_pid = guess_process_pid($pid, $statline); + } + } + } else { + next; + } + + # Perl Switch() sucks majorly + if ($tracepoint eq "mm_vmscan_direct_reclaim_begin") { + $timestamp = timestamp_to_ms($timestamp); + $perprocesspid{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN}++; + $perprocesspid{$process_pid}->{STATE_DIRECT_BEGIN} = $timestamp; + + $details = $5; + if ($details !~ /$regex_direct_begin/o) { + print "WARNING: Failed to parse mm_vmscan_direct_reclaim_begin as expected\n"; + print " $details\n"; + print " $regex_direct_begin\n"; + next; + } + my $order = $1; + $perprocesspid{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN_PERORDER}[$order]++; + $perprocesspid{$process_pid}->{STATE_DIRECT_ORDER} = $order; + } elsif ($tracepoint eq "mm_vmscan_direct_reclaim_end") { + # Count the event itself + my $index = $perprocesspid{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_END}; + $perprocesspid{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_END}++; + + # Record how long direct reclaim took this time + if (defined $perprocesspid{$process_pid}->{STATE_DIRECT_BEGIN}) { + $timestamp = timestamp_to_ms($timestamp); + my $order = $perprocesspid{$process_pid}->{STATE_DIRECT_ORDER}; + my $latency = ($timestamp - $perprocesspid{$process_pid}->{STATE_DIRECT_BEGIN}); + $perprocesspid{$process_pid}->{HIGH_DIRECT_RECLAIM_LATENCY}[$index] = "$order-$latency"; + } + } elsif ($tracepoint eq "mm_vmscan_kswapd_wake") { + $details = $5; + if ($details !~ /$regex_kswapd_wake/o) { + print "WARNING: Failed to parse mm_vmscan_kswapd_wake as expected\n"; + print " $details\n"; + print " $regex_kswapd_wake\n"; + next; + } + + my $order = $2; + $perprocesspid{$process_pid}->{STATE_KSWAPD_ORDER} = $order; + if (!$perprocesspid{$process_pid}->{STATE_KSWAPD_BEGIN}) { + $timestamp = timestamp_to_ms($timestamp); + $perprocesspid{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE}++; + $perprocesspid{$process_pid}->{STATE_KSWAPD_BEGIN} = $timestamp; + $perprocesspid{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE_PERORDER}[$order]++; + } else { + $perprocesspid{$process_pid}->{HIGH_KSWAPD_REWAKEUP}++; + $perprocesspid{$process_pid}->{HIGH_KSWAPD_REWAKEUP_PERORDER}[$order]++; + } + } elsif ($tracepoint eq "mm_vmscan_kswapd_sleep") { + + # Count the event itself + my $index = $perprocesspid{$process_pid}->{MM_VMSCAN_KSWAPD_SLEEP}; + $perprocesspid{$process_pid}->{MM_VMSCAN_KSWAPD_SLEEP}++; + + # Record how long kswapd was awake + $timestamp = timestamp_to_ms($timestamp); + my $order = $perprocesspid{$process_pid}->{STATE_KSWAPD_ORDER}; + my $latency = ($timestamp - $perprocesspid{$process_pid}->{STATE_KSWAPD_BEGIN}); + $perprocesspid{$process_pid}->{HIGH_KSWAPD_LATENCY}[$index] = "$order-$latency"; + $perprocesspid{$process_pid}->{STATE_KSWAPD_BEGIN} = 0; + } elsif ($tracepoint eq "mm_vmscan_wakeup_kswapd") { + $perprocesspid{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD}++; + + $details = $5; + if ($details !~ /$regex_wakeup_kswapd/o) { + print "WARNING: Failed to parse mm_vmscan_wakeup_kswapd as expected\n"; + print " $details\n"; + print " $regex_wakeup_kswapd\n"; + next; + } + my $order = $3; + $perprocesspid{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD_PERORDER}[$order]++; + } elsif ($tracepoint eq "mm_vmscan_lru_isolate") { + $details = $5; + if ($details !~ /$regex_lru_isolate/o) { + print "WARNING: Failed to parse mm_vmscan_lru_isolate as expected\n"; + print " $details\n"; + print " $regex_lru_isolate/o\n"; + next; + } + my $nr_scanned = $4; + my $nr_contig_dirty = $7; + $perprocesspid{$process_pid}->{HIGH_NR_SCANNED} += $nr_scanned; + $perprocesspid{$process_pid}->{HIGH_NR_CONTIG_DIRTY} += $nr_contig_dirty; + } elsif ($tracepoint eq "mm_vmscan_writepage") { + $details = $5; + if ($details !~ /$regex_writepage/o) { + print "WARNING: Failed to parse mm_vmscan_writepage as expected\n"; + print " $details\n"; + print " $regex_writepage\n"; + next; + } + + my $flags = $3; + my $file = 0; + my $sync_io = 0; + if ($flags =~ /RECLAIM_WB_FILE/) { + $file = 1; + } + if ($flags =~ /RECLAIM_WB_SYNC/) { + $sync_io = 1; + } + if ($sync_io) { + if ($file) { + $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC}++; + } else { + $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC}++; + } + } else { + if ($file) { + $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC}++; + } else { + $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC}++; + } + } + } else { + $perprocesspid{$process_pid}->{EVENT_UNKNOWN}++; + } + + if ($sigint_pending) { + last EVENT_PROCESS; + } + } +} + +sub dump_stats { + my $hashref = shift; + my %stats = %$hashref; + + # Dump per-process stats + my $process_pid; + my $max_strlen = 0; + + # Get the maximum process name + foreach $process_pid (keys %perprocesspid) { + my $len = length($process_pid); + if ($len > $max_strlen) { + $max_strlen = $len; + } + } + $max_strlen += 2; + + # Work out latencies + printf("\n") if !$opt_ignorepid; + printf("Reclaim latencies expressed as order-latency_in_ms\n") if !$opt_ignorepid; + foreach $process_pid (keys %stats) { + + if (!$stats{$process_pid}->{HIGH_DIRECT_RECLAIM_LATENCY}[0] && + !$stats{$process_pid}->{HIGH_KSWAPD_LATENCY}[0]) { + next; + } + + printf "%-" . $max_strlen . "s ", $process_pid if !$opt_ignorepid; + my $index = 0; + while (defined $stats{$process_pid}->{HIGH_DIRECT_RECLAIM_LATENCY}[$index] || + defined $stats{$process_pid}->{HIGH_KSWAPD_LATENCY}[$index]) { + + if ($stats{$process_pid}->{HIGH_DIRECT_RECLAIM_LATENCY}[$index]) { + printf("%s ", $stats{$process_pid}->{HIGH_DIRECT_RECLAIM_LATENCY}[$index]) if !$opt_ignorepid; + my ($dummy, $latency) = split(/-/, $stats{$process_pid}->{HIGH_DIRECT_RECLAIM_LATENCY}[$index]); + $total_direct_latency += $latency; + } else { + printf("%s ", $stats{$process_pid}->{HIGH_KSWAPD_LATENCY}[$index]) if !$opt_ignorepid; + my ($dummy, $latency) = split(/-/, $stats{$process_pid}->{HIGH_KSWAPD_LATENCY}[$index]); + $total_kswapd_latency += $latency; + } + $index++; + } + print "\n" if !$opt_ignorepid; + } + + # Print out process activity + printf("\n"); + printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s %8s\n", "Process", "Direct", "Wokeup", "Pages", "Pages", "Pages", "Time"); + printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s %8s\n", "details", "Rclms", "Kswapd", "Scanned", "Sync-IO", "ASync-IO", "Stalled"); + foreach $process_pid (keys %stats) { + + if (!$stats{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN}) { + next; + } + + $total_direct_reclaim += $stats{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN}; + $total_wakeup_kswapd += $stats{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD}; + $total_direct_nr_scanned += $stats{$process_pid}->{HIGH_NR_SCANNED}; + $total_direct_writepage_file_sync += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC}; + $total_direct_writepage_anon_sync += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC}; + $total_direct_writepage_file_async += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC}; + + $total_direct_writepage_anon_async += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC}; + + my $index = 0; + my $this_reclaim_delay = 0; + while (defined $stats{$process_pid}->{HIGH_DIRECT_RECLAIM_LATENCY}[$index]) { + my ($dummy, $latency) = split(/-/, $stats{$process_pid}->{HIGH_DIRECT_RECLAIM_LATENCY}[$index]); + $this_reclaim_delay += $latency; + $index++; + } + + printf("%-" . $max_strlen . "s %8d %10d %8u %8u %8u %8.3f", + $process_pid, + $stats{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN}, + $stats{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD}, + $stats{$process_pid}->{HIGH_NR_SCANNED}, + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC} + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC}, + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC} + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC}, + $this_reclaim_delay / 1000); + + if ($stats{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN}) { + print " "; + for (my $order = 0; $order < 20; $order++) { + my $count = $stats{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN_PERORDER}[$order]; + if ($count != 0) { + print "direct-$order=$count "; + } + } + } + if ($stats{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD}) { + print " "; + for (my $order = 0; $order < 20; $order++) { + my $count = $stats{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD_PERORDER}[$order]; + if ($count != 0) { + print "wakeup-$order=$count "; + } + } + } + if ($stats{$process_pid}->{HIGH_NR_CONTIG_DIRTY}) { + print " "; + my $count = $stats{$process_pid}->{HIGH_NR_CONTIG_DIRTY}; + if ($count != 0) { + print "contig-dirty=$count "; + } + } + + print "\n"; + } + + # Print out kswapd activity + printf("\n"); + printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s\n", "Kswapd", "Kswapd", "Order", "Pages", "Pages", "Pages"); + printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s\n", "Instance", "Wakeups", "Re-wakeup", "Scanned", "Sync-IO", "ASync-IO"); + foreach $process_pid (keys %stats) { + + if (!$stats{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE}) { + next; + } + + $total_kswapd_wake += $stats{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE}; + $total_kswapd_nr_scanned += $stats{$process_pid}->{HIGH_NR_SCANNED}; + $total_kswapd_writepage_file_sync += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC}; + $total_kswapd_writepage_anon_sync += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC}; + $total_kswapd_writepage_file_async += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC}; + $total_kswapd_writepage_anon_async += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC}; + + printf("%-" . $max_strlen . "s %8d %10d %8u %8i %8u", + $process_pid, + $stats{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE}, + $stats{$process_pid}->{HIGH_KSWAPD_REWAKEUP}, + $stats{$process_pid}->{HIGH_NR_SCANNED}, + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC} + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC}, + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC} + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC}); + + if ($stats{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE}) { + print " "; + for (my $order = 0; $order < 20; $order++) { + my $count = $stats{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE_PERORDER}[$order]; + if ($count != 0) { + print "wake-$order=$count "; + } + } + } + if ($stats{$process_pid}->{HIGH_KSWAPD_REWAKEUP}) { + print " "; + for (my $order = 0; $order < 20; $order++) { + my $count = $stats{$process_pid}->{HIGH_KSWAPD_REWAKEUP_PERORDER}[$order]; + if ($count != 0) { + print "rewake-$order=$count "; + } + } + } + printf("\n"); + } + + # Print out summaries + $total_direct_latency /= 1000; + $total_kswapd_latency /= 1000; + print "\nSummary\n"; + print "Direct reclaims: $total_direct_reclaim\n"; + print "Direct reclaim pages scanned: $total_direct_nr_scanned\n"; + print "Direct reclaim write file sync I/O: $total_direct_writepage_file_sync\n"; + print "Direct reclaim write anon sync I/O: $total_direct_writepage_anon_sync\n"; + print "Direct reclaim write file async I/O: $total_direct_writepage_file_async\n"; + print "Direct reclaim write anon async I/O: $total_direct_writepage_anon_async\n"; + print "Wake kswapd requests: $total_wakeup_kswapd\n"; + printf "Time stalled direct reclaim: %-1.2f seconds\n", $total_direct_latency; + print "\n"; + print "Kswapd wakeups: $total_kswapd_wake\n"; + print "Kswapd pages scanned: $total_kswapd_nr_scanned\n"; + print "Kswapd reclaim write file sync I/O: $total_kswapd_writepage_file_sync\n"; + print "Kswapd reclaim write anon sync I/O: $total_kswapd_writepage_anon_sync\n"; + print "Kswapd reclaim write file async I/O: $total_kswapd_writepage_file_async\n"; + print "Kswapd reclaim write anon async I/O: $total_kswapd_writepage_anon_async\n"; + printf "Time kswapd awake: %-1.2f seconds\n", $total_kswapd_latency; +} + +sub aggregate_perprocesspid() { + my $process_pid; + my $process; + undef %perprocess; + + foreach $process_pid (keys %perprocesspid) { + $process = $process_pid; + $process =~ s/-([0-9])*$//; + if ($process eq '') { + $process = "NO_PROCESS_NAME"; + } + + $perprocess{$process}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN} += $perprocesspid{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN}; + $perprocess{$process}->{MM_VMSCAN_KSWAPD_WAKE} += $perprocesspid{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE}; + $perprocess{$process}->{MM_VMSCAN_WAKEUP_KSWAPD} += $perprocesspid{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD}; + $perprocess{$process}->{HIGH_KSWAPD_REWAKEUP} += $perprocesspid{$process_pid}->{HIGH_KSWAPD_REWAKEUP}; + $perprocess{$process}->{HIGH_NR_SCANNED} += $perprocesspid{$process_pid}->{HIGH_NR_SCANNED}; + $perprocess{$process}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC} += $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC}; + $perprocess{$process}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC} += $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC}; + $perprocess{$process}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC} += $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC}; + $perprocess{$process}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC} += $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC}; + + for (my $order = 0; $order < 20; $order++) { + $perprocess{$process}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN_PERORDER}[$order] += $perprocesspid{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN_PERORDER}[$order]; + $perprocess{$process}->{MM_VMSCAN_WAKEUP_KSWAPD_PERORDER}[$order] += $perprocesspid{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD_PERORDER}[$order]; + $perprocess{$process}->{MM_VMSCAN_KSWAPD_WAKE_PERORDER}[$order] += $perprocesspid{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE_PERORDER}[$order]; + + } + + # Aggregate direct reclaim latencies + my $wr_index = $perprocess{$process}->{MM_VMSCAN_DIRECT_RECLAIM_END}; + my $rd_index = 0; + while (defined $perprocesspid{$process_pid}->{HIGH_DIRECT_RECLAIM_LATENCY}[$rd_index]) { + $perprocess{$process}->{HIGH_DIRECT_RECLAIM_LATENCY}[$wr_index] = $perprocesspid{$process_pid}->{HIGH_DIRECT_RECLAIM_LATENCY}[$rd_index]; + $rd_index++; + $wr_index++; + } + $perprocess{$process}->{MM_VMSCAN_DIRECT_RECLAIM_END} = $wr_index; + + # Aggregate kswapd latencies + my $wr_index = $perprocess{$process}->{MM_VMSCAN_KSWAPD_SLEEP}; + my $rd_index = 0; + while (defined $perprocesspid{$process_pid}->{HIGH_KSWAPD_LATENCY}[$rd_index]) { + $perprocess{$process}->{HIGH_KSWAPD_LATENCY}[$wr_index] = $perprocesspid{$process_pid}->{HIGH_KSWAPD_LATENCY}[$rd_index]; + $rd_index++; + $wr_index++; + } + $perprocess{$process}->{MM_VMSCAN_DIRECT_RECLAIM_END} = $wr_index; + } +} + +sub report() { + if (!$opt_ignorepid) { + dump_stats(\%perprocesspid); + } else { + aggregate_perprocesspid(); + dump_stats(\%perprocess); + } +} + +# Process events or signals until neither is available +sub signal_loop() { + my $sigint_processed; + do { + $sigint_processed = 0; + process_events(); + + # Handle pending signals if any + if ($sigint_pending) { + my $current_time = time; + + if ($sigint_exit) { + print "Received exit signal\n"; + $sigint_pending = 0; + } + if ($sigint_report) { + if ($current_time >= $sigint_received + 2) { + report(); + $sigint_report = 0; + $sigint_pending = 0; + $sigint_processed = 1; + } + } + } + } while ($sigint_pending || $sigint_processed); +} + +signal_loop(); +report(); diff --git a/Documentation/vm/page-types.c b/Documentation/vm/page-types.c index 66e9358e2144..ccd951fa94ee 100644 --- a/Documentation/vm/page-types.c +++ b/Documentation/vm/page-types.c @@ -694,7 +694,7 @@ static void usage(void) #endif " -l|--list Show page details in ranges\n" " -L|--list-each Show page details one by one\n" -" -N|--no-summary Don't show summay info\n" +" -N|--no-summary Don't show summary info\n" " -X|--hwpoison hwpoison pages\n" " -x|--unpoison unpoison pages\n" " -h|--help Show this usage message\n" diff --git a/Documentation/x86/zero-page.txt b/Documentation/x86/zero-page.txt index feb37e177010..cf5437deda81 100644 --- a/Documentation/x86/zero-page.txt +++ b/Documentation/x86/zero-page.txt @@ -18,6 +18,7 @@ Offset Proto Name Meaning 080/010 ALL hd0_info hd0 disk parameter, OBSOLETE!! 090/010 ALL hd1_info hd1 disk parameter, OBSOLETE!! 0A0/010 ALL sys_desc_table System description table (struct sys_desc_table) +0B0/010 ALL olpc_ofw_header OLPC's OpenFirmware CIF and friends 140/080 ALL edid_info Video mode setup (struct edid_info) 1C0/020 ALL efi_info EFI 32 information (struct efi_info) 1E0/004 ALL alk_mem_k Alternative mem check, in KB |