diff options
Diffstat (limited to 'Documentation')
25 files changed, 861 insertions, 325 deletions
diff --git a/Documentation/acpi-hotkey.txt b/Documentation/acpi-hotkey.txt deleted file mode 100644 index 38040fa37649..000000000000 --- a/Documentation/acpi-hotkey.txt +++ /dev/null @@ -1,38 +0,0 @@ -driver/acpi/hotkey.c implement: -1. /proc/acpi/hotkey/event_config -(event based hotkey or event config interface): -a. add a event based hotkey(event) : -echo "0:bus::action:method:num:num" > event_config - -b. delete a event based hotkey(event): -echo "1:::::num:num" > event_config - -c. modify a event based hotkey(event): -echo "2:bus::action:method:num:num" > event_config - -2. /proc/acpi/hotkey/poll_config -(polling based hotkey or event config interface): -a.add a polling based hotkey(event) : -echo "0:bus:method:action:method:num" > poll_config -this adding command will create a proc file -/proc/acpi/hotkey/method, which is used to get -result of polling. - -b.delete a polling based hotkey(event): -echo "1:::::num" > event_config - -c.modify a polling based hotkey(event): -echo "2:bus:method:action:method:num" > poll_config - -3./proc/acpi/hotkey/action -(interface to call aml method associated with a -specific hotkey(event)) -echo "event_num:event_type:event_argument" > - /proc/acpi/hotkey/action. -The result of the execution of this aml method is -attached to /proc/acpi/hotkey/poll_method, which is dynamically -created. Please use command "cat /proc/acpi/hotkey/polling_method" -to retrieve it. - -Note: Use cmdline "acpi_generic_hotkey" to over-ride -platform-specific with generic driver. diff --git a/Documentation/arm/Samsung-S3C24XX/DMA.txt b/Documentation/arm/Samsung-S3C24XX/DMA.txt new file mode 100644 index 000000000000..37f4edcc5d87 --- /dev/null +++ b/Documentation/arm/Samsung-S3C24XX/DMA.txt @@ -0,0 +1,46 @@ + S3C2410 DMA + =========== + +Introduction +------------ + + The kernel provides an interface to manage DMA transfers + using the DMA channels in the cpu, so that the central + duty of managing channel mappings, and programming the + channel generators is in one place. + + +DMA Channel Ordering +-------------------- + + Many of the range do not have connections for the DMA + channels to all sources, which means that some devices + have a restricted number of channels that can be used. + + To allow flexibilty for each cpu type and board, the + dma code can be given an dma ordering structure which + allows the order of channel search to be specified, as + well as allowing the prohibition of certain claims. + + struct s3c24xx_dma_order has a list of channels, and + each channel within has a slot for a list of dma + channel numbers. The slots are searched in order, for + the presence of a dma channel number with DMA_CH_VALID + orred in. + + If the order has the flag DMA_CH_NEVER set, then after + checking the channel list, the system will return no + found channel, thus denying the request. + + A board support file can call s3c24xx_dma_order_set() + to register an complete ordering set. The routine will + copy the data, so the original can be discared with + __initdata. + + +Authour +------- + +Ben Dooks, +Copyright (c) 2007 Ben Dooks, Simtec Electronics +Licensed under the GPL v2 diff --git a/Documentation/arm/Samsung-S3C24XX/Overview.txt b/Documentation/arm/Samsung-S3C24XX/Overview.txt index 28d014714ab8..c31b76fa66c4 100644 --- a/Documentation/arm/Samsung-S3C24XX/Overview.txt +++ b/Documentation/arm/Samsung-S3C24XX/Overview.txt @@ -8,13 +8,10 @@ Introduction The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported by the 's3c2410' architecture of ARM Linux. Currently the S3C2410, - S3C2440 and S3C2442 devices are supported. + S3C2412, S3C2413, S3C2440 and S3C2442 devices are supported. Support for the S3C2400 series is in progress. - Support for the S3C2412 and S3C2413 CPUs is being merged. - - Configuration ------------- @@ -26,6 +23,22 @@ Configuration please check the machine specific documentation. +Layout +------ + + The core support files are located in the platform code contained in + arch/arm/plat-s3c24xx with headers in include/asm-arm/plat-s3c24xx. + This directory should be kept to items shared between the platform + code (arch/arm/plat-s3c24xx) and the arch/arm/mach-s3c24* code. + + Each cpu has a directory with the support files for it, and the + machines that carry the device. For example S3C2410 is contained + in arch/arm/mach-s3c2410 and S3C2440 in arch/arm/mach-s3c2440 + + Register, kernel and platform data definitions are held in the + include/asm-arm/arch-s3c2410 directory. + + Machines -------- diff --git a/Documentation/driver-model/platform.txt b/Documentation/driver-model/platform.txt index 9f0bc3bfd776..f7c9262b2dc8 100644 --- a/Documentation/driver-model/platform.txt +++ b/Documentation/driver-model/platform.txt @@ -66,7 +66,7 @@ runtime memory footprint: Device Enumeration ~~~~~~~~~~~~~~~~~~ -As a rule, platform specific (and often board-specific) setup code wil +As a rule, platform specific (and often board-specific) setup code will register platform devices: int platform_device_register(struct platform_device *pdev); @@ -106,7 +106,7 @@ It's built from two components: * platform_device.id ... the device instance number, or else "-1" to indicate there's only one. -These are catenated, so name/id "serial"/0 indicates bus_id "serial.0", and +These are concatenated, so name/id "serial"/0 indicates bus_id "serial.0", and "serial/3" indicates bus_id "serial.3"; both would use the platform_driver named "serial". While "my_rtc"/-1 would be bus_id "my_rtc" (no instance id) and use the platform_driver called "my_rtc". diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index c585aa8d62b4..6a451f47d40f 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -253,29 +253,6 @@ Who: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> --------------------------- -<<<<<<< test:Documentation/feature-removal-schedule.txt -What: ACPI hotkey driver (CONFIG_ACPI_HOTKEY) -When: 2.6.21 -Why: hotkey.c was an attempt to consolidate multiple drivers that use - ACPI to implement hotkeys. However, hotkeys are not documented - in the ACPI specification, so the drivers used undocumented - vendor-specific hooks and turned out to be more different than - the same. - - Further, the keys and the features supplied by each platform - are different, so there will always be a need for - platform-specific drivers. - - So the new plan is to delete hotkey.c and instead, work on the - platform specific drivers to try to make them look the same - to the user when they supply the same features. - - hotkey.c has always depended on CONFIG_EXPERIMENTAL - -Who: Len Brown <len.brown@intel.com> - ---------------------------- - What: /sys/firmware/acpi/namespace When: 2.6.21 Why: The ACPI namespace is effectively the symbol list for @@ -306,13 +283,6 @@ Who: Len Brown <len.brown@intel.com> --------------------------- -What: JFFS (version 1) -When: 2.6.21 -Why: Unmaintained for years, superceded by JFFS2 for years. -Who: Jeff Garzik <jeff@garzik.org> - ---------------------------- - What: sk98lin network driver When: July 2007 Why: In kernel tree version of driver is unmaintained. Sk98lin driver diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX index 4dc28cc93503..571785887a4f 100644 --- a/Documentation/filesystems/00-INDEX +++ b/Documentation/filesystems/00-INDEX @@ -4,6 +4,8 @@ Exporting - explanation of how to make filesystems exportable. Locking - info on locking rules as they pertain to Linux VFS. +9p.txt + - 9p (v9fs) is an implementation of the Plan 9 remote fs protocol. adfs.txt - info and mount options for the Acorn Advanced Disc Filing System. afs.txt @@ -82,8 +84,6 @@ udf.txt - info and mount options for the UDF filesystem. ufs.txt - info on the ufs filesystem. -v9fs.txt - - v9fs is a Unix implementation of the Plan 9 9p remote fs protocol. vfat.txt - info on using the VFAT filesystem used in Windows NT and Windows 95 vfs.txt diff --git a/Documentation/filesystems/9p.txt b/Documentation/filesystems/9p.txt index 4d075a4558f9..bbd8b28c13de 100644 --- a/Documentation/filesystems/9p.txt +++ b/Documentation/filesystems/9p.txt @@ -40,6 +40,10 @@ OPTIONS aname=name aname specifies the file tree to access when the server is offering several exported file systems. + cache=mode specifies a cacheing policy. By default, no caches are used. + loose = no attempts are made at consistency, + intended for exclusive, read-only mounts + debug=n specifies debug level. The debug level is a bitmask. 0x01 = display verbose error messages 0x02 = developer debug (DEBUG_CURRENT) diff --git a/Documentation/filesystems/sysfs-pci.txt b/Documentation/filesystems/sysfs-pci.txt index 7ba2baa165ff..5daa2aaec2c5 100644 --- a/Documentation/filesystems/sysfs-pci.txt +++ b/Documentation/filesystems/sysfs-pci.txt @@ -65,7 +65,7 @@ Accessing legacy resources through sysfs ---------------------------------------- Legacy I/O port and ISA memory resources are also provided in sysfs if the -underlying platform supports them. They're located in the PCI class heirarchy, +underlying platform supports them. They're located in the PCI class hierarchy, e.g. /sys/class/pci_bus/0000:17/ diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt index 09dd510c4a5f..576ce463cf44 100644 --- a/Documentation/gpio.txt +++ b/Documentation/gpio.txt @@ -78,7 +78,8 @@ Identifying GPIOs ----------------- GPIOs are identified by unsigned integers in the range 0..MAX_INT. That reserves "negative" numbers for other purposes like marking signals as -"not available on this board", or indicating faults. +"not available on this board", or indicating faults. Code that doesn't +touch the underlying hardware treats these integers as opaque cookies. Platforms define how they use those integers, and usually #define symbols for the GPIO lines so that board-specific setup code directly corresponds @@ -139,10 +140,10 @@ issues including wire-OR and output latencies. The get/set calls have no error returns because "invalid GPIO" should have been reported earlier in gpio_set_direction(). However, note that not all platforms can read the value of output pins; those that can't should always -return zero. Also, these calls will be ignored for GPIOs that can't safely -be accessed wihtout sleeping (see below). +return zero. Also, using these calls for GPIOs that can't safely be accessed +without sleeping (see below) is an error. -Platform-specific implementations are encouraged to optimise the two +Platform-specific implementations are encouraged to optimize the two calls to access the GPIO value in cases where the GPIO number (and for output, value) are constant. It's normal for them to need only a couple of instructions in such cases (reading or writing a hardware register), @@ -239,7 +240,8 @@ options are part of the IRQ interface, e.g. IRQF_TRIGGER_FALLING, as are system wakeup capabilities. Non-error values returned from irq_to_gpio() would most commonly be used -with gpio_get_value(). +with gpio_get_value(), for example to initialize or update driver state +when the IRQ is edge-triggered. @@ -260,9 +262,10 @@ pullups (or pulldowns) so that the on-chip ones should not be used. There are other system-specific mechanisms that are not specified here, like the aforementioned options for input de-glitching and wire-OR output. Hardware may support reading or writing GPIOs in gangs, but that's usually -configuration dependednt: for GPIOs sharing the same bank. (GPIOs are +configuration dependent: for GPIOs sharing the same bank. (GPIOs are commonly grouped in banks of 16 or 32, with a given SOC having several such -banks.) Code relying on such mechanisms will necessarily be nonportable. +banks.) Some systems can trigger IRQs from output GPIOs. Code relying on +such mechanisms will necessarily be nonportable. Dynamic definition of GPIOs is not currently supported; for example, as a side effect of configuring an add-on board with some GPIO expanders. diff --git a/Documentation/hrtimer/timer_stats.txt b/Documentation/hrtimer/timer_stats.txt new file mode 100644 index 000000000000..27f782e3593f --- /dev/null +++ b/Documentation/hrtimer/timer_stats.txt @@ -0,0 +1,68 @@ +timer_stats - timer usage statistics +------------------------------------ + +timer_stats is a debugging facility to make the timer (ab)usage in a Linux +system visible to kernel and userspace developers. It is not intended for +production usage as it adds significant overhead to the (hr)timer code and the +(hr)timer data structures. + +timer_stats should be used by kernel and userspace developers to verify that +their code does not make unduly use of timers. This helps to avoid unnecessary +wakeups, which should be avoided to optimize power consumption. + +It can be enabled by CONFIG_TIMER_STATS in the "Kernel hacking" configuration +section. + +timer_stats collects information about the timer events which are fired in a +Linux system over a sample period: + +- the pid of the task(process) which initialized the timer +- the name of the process which initialized the timer +- the function where the timer was intialized +- the callback function which is associated to the timer +- the number of events (callbacks) + +timer_stats adds an entry to /proc: /proc/timer_stats + +This entry is used to control the statistics functionality and to read out the +sampled information. + +The timer_stats functionality is inactive on bootup. + +To activate a sample period issue: +# echo 1 >/proc/timer_stats + +To stop a sample period issue: +# echo 0 >/proc/timer_stats + +The statistics can be retrieved by: +# cat /proc/timer_stats + +The readout of /proc/timer_stats automatically disables sampling. The sampled +information is kept until a new sample period is started. This allows multiple +readouts. + +Sample output of /proc/timer_stats: + +Timerstats sample period: 3.888770 s + 12, 0 swapper hrtimer_stop_sched_tick (hrtimer_sched_tick) + 15, 1 swapper hcd_submit_urb (rh_timer_func) + 4, 959 kedac schedule_timeout (process_timeout) + 1, 0 swapper page_writeback_init (wb_timer_fn) + 28, 0 swapper hrtimer_stop_sched_tick (hrtimer_sched_tick) + 22, 2948 IRQ 4 tty_flip_buffer_push (delayed_work_timer_fn) + 3, 3100 bash schedule_timeout (process_timeout) + 1, 1 swapper queue_delayed_work_on (delayed_work_timer_fn) + 1, 1 swapper queue_delayed_work_on (delayed_work_timer_fn) + 1, 1 swapper neigh_table_init_no_netlink (neigh_periodic_timer) + 1, 2292 ip __netdev_watchdog_up (dev_watchdog) + 1, 23 events/1 do_cache_clean (delayed_work_timer_fn) +90 total events, 30.0 events/sec + +The first column is the number of events, the second column the pid, the third +column is the name of the process. The forth column shows the function which +initialized the timer and in parantheses the callback function which was +executed on expiry. + + Thomas, Ingo + diff --git a/Documentation/hrtimers/highres.txt b/Documentation/hrtimers/highres.txt new file mode 100644 index 000000000000..ce0e9a91e157 --- /dev/null +++ b/Documentation/hrtimers/highres.txt @@ -0,0 +1,249 @@ +High resolution timers and dynamic ticks design notes +----------------------------------------------------- + +Further information can be found in the paper of the OLS 2006 talk "hrtimers +and beyond". The paper is part of the OLS 2006 Proceedings Volume 1, which can +be found on the OLS website: +http://www.linuxsymposium.org/2006/linuxsymposium_procv1.pdf + +The slides to this talk are available from: +http://tglx.de/projects/hrtimers/ols2006-hrtimers.pdf + +The slides contain five figures (pages 2, 15, 18, 20, 22), which illustrate the +changes in the time(r) related Linux subsystems. Figure #1 (p. 2) shows the +design of the Linux time(r) system before hrtimers and other building blocks +got merged into mainline. + +Note: the paper and the slides are talking about "clock event source", while we +switched to the name "clock event devices" in meantime. + +The design contains the following basic building blocks: + +- hrtimer base infrastructure +- timeofday and clock source management +- clock event management +- high resolution timer functionality +- dynamic ticks + + +hrtimer base infrastructure +--------------------------- + +The hrtimer base infrastructure was merged into the 2.6.16 kernel. Details of +the base implementation are covered in Documentation/hrtimers/hrtimer.txt. See +also figure #2 (OLS slides p. 15) + +The main differences to the timer wheel, which holds the armed timer_list type +timers are: + - time ordered enqueueing into a rb-tree + - independent of ticks (the processing is based on nanoseconds) + + +timeofday and clock source management +------------------------------------- + +John Stultz's Generic Time Of Day (GTOD) framework moves a large portion of +code out of the architecture-specific areas into a generic management +framework, as illustrated in figure #3 (OLS slides p. 18). The architecture +specific portion is reduced to the low level hardware details of the clock +sources, which are registered in the framework and selected on a quality based +decision. The low level code provides hardware setup and readout routines and +initializes data structures, which are used by the generic time keeping code to +convert the clock ticks to nanosecond based time values. All other time keeping +related functionality is moved into the generic code. The GTOD base patch got +merged into the 2.6.18 kernel. + +Further information about the Generic Time Of Day framework is available in the +OLS 2005 Proceedings Volume 1: +http://www.linuxsymposium.org/2005/linuxsymposium_procv1.pdf + +The paper "We Are Not Getting Any Younger: A New Approach to Time and +Timers" was written by J. Stultz, D.V. Hart, & N. Aravamudan. + +Figure #3 (OLS slides p.18) illustrates the transformation. + + +clock event management +---------------------- + +While clock sources provide read access to the monotonically increasing time +value, clock event devices are used to schedule the next event +interrupt(s). The next event is currently defined to be periodic, with its +period defined at compile time. The setup and selection of the event device +for various event driven functionalities is hardwired into the architecture +dependent code. This results in duplicated code across all architectures and +makes it extremely difficult to change the configuration of the system to use +event interrupt devices other than those already built into the +architecture. Another implication of the current design is that it is necessary +to touch all the architecture-specific implementations in order to provide new +functionality like high resolution timers or dynamic ticks. + +The clock events subsystem tries to address this problem by providing a generic +solution to manage clock event devices and their usage for the various clock +event driven kernel functionalities. The goal of the clock event subsystem is +to minimize the clock event related architecture dependent code to the pure +hardware related handling and to allow easy addition and utilization of new +clock event devices. It also minimizes the duplicated code across the +architectures as it provides generic functionality down to the interrupt +service handler, which is almost inherently hardware dependent. + +Clock event devices are registered either by the architecture dependent boot +code or at module insertion time. Each clock event device fills a data +structure with clock-specific property parameters and callback functions. The +clock event management decides, by using the specified property parameters, the +set of system functions a clock event device will be used to support. This +includes the distinction of per-CPU and per-system global event devices. + +System-level global event devices are used for the Linux periodic tick. Per-CPU +event devices are used to provide local CPU functionality such as process +accounting, profiling, and high resolution timers. + +The management layer assignes one or more of the folliwing functions to a clock +event device: + - system global periodic tick (jiffies update) + - cpu local update_process_times + - cpu local profiling + - cpu local next event interrupt (non periodic mode) + +The clock event device delegates the selection of those timer interrupt related +functions completely to the management layer. The clock management layer stores +a function pointer in the device description structure, which has to be called +from the hardware level handler. This removes a lot of duplicated code from the +architecture specific timer interrupt handlers and hands the control over the +clock event devices and the assignment of timer interrupt related functionality +to the core code. + +The clock event layer API is rather small. Aside from the clock event device +registration interface it provides functions to schedule the next event +interrupt, clock event device notification service and support for suspend and +resume. + +The framework adds about 700 lines of code which results in a 2KB increase of +the kernel binary size. The conversion of i386 removes about 100 lines of +code. The binary size decrease is in the range of 400 byte. We believe that the +increase of flexibility and the avoidance of duplicated code across +architectures justifies the slight increase of the binary size. + +The conversion of an architecture has no functional impact, but allows to +utilize the high resolution and dynamic tick functionalites without any change +to the clock event device and timer interrupt code. After the conversion the +enabling of high resolution timers and dynamic ticks is simply provided by +adding the kernel/time/Kconfig file to the architecture specific Kconfig and +adding the dynamic tick specific calls to the idle routine (a total of 3 lines +added to the idle function and the Kconfig file) + +Figure #4 (OLS slides p.20) illustrates the transformation. + + +high resolution timer functionality +----------------------------------- + +During system boot it is not possible to use the high resolution timer +functionality, while making it possible would be difficult and would serve no +useful function. The initialization of the clock event device framework, the +clock source framework (GTOD) and hrtimers itself has to be done and +appropriate clock sources and clock event devices have to be registered before +the high resolution functionality can work. Up to the point where hrtimers are +initialized, the system works in the usual low resolution periodic mode. The +clock source and the clock event device layers provide notification functions +which inform hrtimers about availability of new hardware. hrtimers validates +the usability of the registered clock sources and clock event devices before +switching to high resolution mode. This ensures also that a kernel which is +configured for high resolution timers can run on a system which lacks the +necessary hardware support. + +The high resolution timer code does not support SMP machines which have only +global clock event devices. The support of such hardware would involve IPI +calls when an interrupt happens. The overhead would be much larger than the +benefit. This is the reason why we currently disable high resolution and +dynamic ticks on i386 SMP systems which stop the local APIC in C3 power +state. A workaround is available as an idea, but the problem has not been +tackled yet. + +The time ordered insertion of timers provides all the infrastructure to decide +whether the event device has to be reprogrammed when a timer is added. The +decision is made per timer base and synchronized across per-cpu timer bases in +a support function. The design allows the system to utilize separate per-CPU +clock event devices for the per-CPU timer bases, but currently only one +reprogrammable clock event device per-CPU is utilized. + +When the timer interrupt happens, the next event interrupt handler is called +from the clock event distribution code and moves expired timers from the +red-black tree to a separate double linked list and invokes the softirq +handler. An additional mode field in the hrtimer structure allows the system to +execute callback functions directly from the next event interrupt handler. This +is restricted to code which can safely be executed in the hard interrupt +context. This applies, for example, to the common case of a wakeup function as +used by nanosleep. The advantage of executing the handler in the interrupt +context is the avoidance of up to two context switches - from the interrupted +context to the softirq and to the task which is woken up by the expired +timer. + +Once a system has switched to high resolution mode, the periodic tick is +switched off. This disables the per system global periodic clock event device - +e.g. the PIT on i386 SMP systems. + +The periodic tick functionality is provided by an per-cpu hrtimer. The callback +function is executed in the next event interrupt context and updates jiffies +and calls update_process_times and profiling. The implementation of the hrtimer +based periodic tick is designed to be extended with dynamic tick functionality. +This allows to use a single clock event device to schedule high resolution +timer and periodic events (jiffies tick, profiling, process accounting) on UP +systems. This has been proved to work with the PIT on i386 and the Incrementer +on PPC. + +The softirq for running the hrtimer queues and executing the callbacks has been +separated from the tick bound timer softirq to allow accurate delivery of high +resolution timer signals which are used by itimer and POSIX interval +timers. The execution of this softirq can still be delayed by other softirqs, +but the overall latencies have been significantly improved by this separation. + +Figure #5 (OLS slides p.22) illustrates the transformation. + + +dynamic ticks +------------- + +Dynamic ticks are the logical consequence of the hrtimer based periodic tick +replacement (sched_tick). The functionality of the sched_tick hrtimer is +extended by three functions: + +- hrtimer_stop_sched_tick +- hrtimer_restart_sched_tick +- hrtimer_update_jiffies + +hrtimer_stop_sched_tick() is called when a CPU goes into idle state. The code +evaluates the next scheduled timer event (from both hrtimers and the timer +wheel) and in case that the next event is further away than the next tick it +reprograms the sched_tick to this future event, to allow longer idle sleeps +without worthless interruption by the periodic tick. The function is also +called when an interrupt happens during the idle period, which does not cause a +reschedule. The call is necessary as the interrupt handler might have armed a +new timer whose expiry time is before the time which was identified as the +nearest event in the previous call to hrtimer_stop_sched_tick. + +hrtimer_restart_sched_tick() is called when the CPU leaves the idle state before +it calls schedule(). hrtimer_restart_sched_tick() resumes the periodic tick, +which is kept active until the next call to hrtimer_stop_sched_tick(). + +hrtimer_update_jiffies() is called from irq_enter() when an interrupt happens +in the idle period to make sure that jiffies are up to date and the interrupt +handler has not to deal with an eventually stale jiffy value. + +The dynamic tick feature provides statistical values which are exported to +userspace via /proc/stats and can be made available for enhanced power +management control. + +The implementation leaves room for further development like full tickless +systems, where the time slice is controlled by the scheduler, variable +frequency profiling, and a complete removal of jiffies in the future. + + +Aside the current initial submission of i386 support, the patchset has been +extended to x86_64 and ARM already. Initial (work in progress) support is also +available for MIPS and PowerPC. + + Thomas, Ingo + + + diff --git a/Documentation/hrtimers.txt b/Documentation/hrtimers/hrtimers.txt index ce31f65e12e7..ce31f65e12e7 100644 --- a/Documentation/hrtimers.txt +++ b/Documentation/hrtimers/hrtimers.txt diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 4b3d6710c504..bb5306e9a5c3 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -34,7 +34,7 @@ This document describes the Linux kernel Makefiles. --- 6.1 Set variables to tweak the build to the architecture --- 6.2 Add prerequisites to archprepare: --- 6.3 List directories to visit when descending - --- 6.4 Architecture specific boot images + --- 6.4 Architecture-specific boot images --- 6.5 Building non-kbuild targets --- 6.6 Commands useful for building a boot image --- 6.7 Custom kbuild commands @@ -124,7 +124,7 @@ more details, with real examples. Example: obj-y += foo.o - This tell kbuild that there is one object in that directory, named + This tells kbuild that there is one object in that directory, named foo.o. foo.o will be built from foo.c or foo.S. If foo.o shall be built as a module, the variable obj-m is used. @@ -353,7 +353,7 @@ more details, with real examples. Special rules are used when the kbuild infrastructure does not provide the required support. A typical example is header files generated during the build process. - Another example are the architecture specific Makefiles which + Another example are the architecture-specific Makefiles which need special rules to prepare boot images etc. Special rules are written as normal Make rules. @@ -416,7 +416,7 @@ more details, with real examples. #arch/i386/kernel/Makefile vsyscall-flags += $(call ld-option, -Wl$(comma)--hash-style=sysv) - In the above example vsyscall-flags will be assigned the option + In the above example, vsyscall-flags will be assigned the option -Wl$(comma)--hash-style=sysv if it is supported by $(CC). The second argument is optional, and if supplied will be used if first argument is not supported. @@ -434,7 +434,7 @@ more details, with real examples. #arch/i386/Makefile cflags-y += $(call cc-option,-march=pentium-mmx,-march=i586) - In the above example cflags-y will be assigned the option + In the above example, cflags-y will be assigned the option -march=pentium-mmx if supported by $(CC), otherwise -march=i586. The second argument to cc-option is optional, and if omitted, cflags-y will be assigned no value if first option is not supported. @@ -750,10 +750,10 @@ When kbuild executes, the following steps are followed (roughly): located at the root of the obj tree. The very first objects linked are listed in head-y, assigned by arch/$(ARCH)/Makefile. -7) Finally, the architecture specific part does any required post processing +7) Finally, the architecture-specific part does any required post processing and builds the final bootimage. - This includes building boot records - - Preparing initrd images and thelike + - Preparing initrd images and the like --- 6.1 Set variables to tweak the build to the architecture @@ -880,7 +880,7 @@ When kbuild executes, the following steps are followed (roughly): $(head-y) lists objects to be linked first in vmlinux. $(libs-y) lists directories where a lib.a archive can be located. - The rest lists directories where a built-in.o object file can be + The rest list directories where a built-in.o object file can be located. $(init-y) objects will be located after $(head-y). @@ -888,7 +888,7 @@ When kbuild executes, the following steps are followed (roughly): $(core-y), $(libs-y), $(drivers-y) and $(net-y). The top level Makefile defines values for all generic directories, - and arch/$(ARCH)/Makefile only adds architecture specific directories. + and arch/$(ARCH)/Makefile only adds architecture-specific directories. Example: #arch/sparc64/Makefile @@ -897,7 +897,7 @@ When kbuild executes, the following steps are followed (roughly): drivers-$(CONFIG_OPROFILE) += arch/sparc64/oprofile/ ---- 6.4 Architecture specific boot images +--- 6.4 Architecture-specific boot images An arch Makefile specifies goals that take the vmlinux file, compress it, wrap it in bootstrapping code, and copy the resulting files @@ -924,7 +924,7 @@ When kbuild executes, the following steps are followed (roughly): "$(Q)$(MAKE) $(build)=<dir>" is the recommended way to invoke make in a subdirectory. - There are no rules for naming architecture specific targets, + There are no rules for naming architecture-specific targets, but executing "make help" will list all relevant targets. To support this, $(archhelp) must be defined. @@ -982,7 +982,7 @@ When kbuild executes, the following steps are followed (roughly): $(call if_changed,ld/objcopy/gzip) When the rule is evaluated, it is checked to see if any files - needs an update, or the command line has changed since the last + need an update, or the command line has changed since the last invocation. The latter will force a rebuild if any options to the executable have changed. Any target that utilises if_changed must be listed in $(targets), @@ -1089,7 +1089,7 @@ When kbuild executes, the following steps are followed (roughly): assignment. The kbuild infrastructure for *lds file are used in several - architecture specific files. + architecture-specific files. === 7 Kbuild Variables @@ -1133,7 +1133,7 @@ The top Makefile exports the following variables: This variable defines a place for the arch Makefiles to install the resident kernel image and System.map file. - Use this for architecture specific install targets. + Use this for architecture-specific install targets. INSTALL_MOD_PATH, MODLIB diff --git a/Documentation/kernel-docs.txt b/Documentation/kernel-docs.txt index b53bccbd9727..c68dafeda7a7 100644 --- a/Documentation/kernel-docs.txt +++ b/Documentation/kernel-docs.txt @@ -1,10 +1,10 @@ - Index of Documentation for People Interested in Writing and/or - - Understanding the Linux Kernel. - - Juan-Mariano de Goyeneche <jmseyas@dit.upm.es> - + Index of Documentation for People Interested in Writing and/or + + Understanding the Linux Kernel. + + Juan-Mariano de Goyeneche <jmseyas@dit.upm.es> + /* * The latest version of this document may be found at: * http://www.dit.upm.es/~jmseyas/linux/kernel/hackers-docs.html @@ -61,18 +61,18 @@ 13.-The Linux Kernel Sources, A.-Linux Data Structures, B.-The Alpha AXP Processor, C.-Useful Web and FTP Sites, D.-The GNU General Public License, Glossary". In short: a must have. - - * Title: "The Linux Kernel Hackers' Guide" - Author: Michael K.Johnson and others. - URL: http://www.tldp.org/LDP/khg/HyperNews/get/khg.html - Keywords: everything! - Description: No more Postscript book-like version. Only HTML now. - Many people have contributed. The interface is similar to web - available mailing lists archives. You can find some articles and - then some mails asking questions about them and/or complementing - previous contributions. A little bit anarchic in this aspect, but - with some valuable information in some cases. - + + * Title: "Linux Device Drivers, 2nd Edition" + Author: Alessandro Rubini and Jonathan Corbet. + URL: http://www.xml.com/ldd/chapter/book/index.html + Keywords: device drivers, modules, debugging, memory, hardware, + interrupt handling, char drivers, block drivers, kmod, mmap, DMA, + buses. + Description: O'Reilly's popular book, now also on-line under the + GNU Free Documentation License. + Notes: You can also buy it in paper-form from O'Reilly. See below + under BOOKS (Not on-line). + * Title: "Conceptual Architecture of the Linux Kernel" Author: Ivan T. Bowman. URL: http://plg.uwaterloo.ca/~itbowman/papers/CS746G-a1.html @@ -81,17 +81,17 @@ Description: Conceptual software arquitecture of the Linux kernel, automatically extracted from the source code. Very detailed. Good figures. Gives good overall kernel understanding. - + * Title: "Concrete Architecture of the Linux Kernel" Author: Ivan T. Bowman, Saheem Siddiqi, and Meyer C. Tanuan. URL: http://plg.uwaterloo.ca/~itbowman/papers/CS746G-a2.html - Keywords: concrete arquitecture, extracted design, reverse + Keywords: concrete architecture, extracted design, reverse engineering, system structure, dependencies. - Description: Concrete arquitecture of the Linux kernel, + Description: Concrete architecture of the Linux kernel, automatically extracted from the source code. Very detailed. Good figures. Gives good overall kernel understanding. This papers focus on lower details than its predecessor (files, variables...). - + * Title: "Linux as a Case Study: Its Extracted Software Architecture" Author: Ivan T. Bowman, Richard C. Holt and Neil V. Brewster. @@ -101,7 +101,7 @@ Description: Paper appeared at ICSE'99, Los Angeles, May 16-22, 1999. A mixture of the previous two documents from the same author. - + * Title: "Overview of the Virtual File System" Author: Richard Gooch. URL: http://www.atnf.csiro.au/~rgooch/linux/vfs.txt @@ -111,20 +111,20 @@ What is it, how it works, operations taken when opening a file or mounting a file system and description of important data structures explaining the purpose of each of their entries. - + * Title: "The Linux RAID-1, 4, 5 Code" Author: Ingo Molnar, Gadi Oxman and Miguel de Icaza. - URL: http://www2.linuxjournal.com/lj-issues/issue44/2391.html + URL: http://www.linuxjournal.com/article.php?sid=2391 Keywords: RAID, MD driver. Description: Linux Journal Kernel Korner article. Here is it's abstract: "A description of the implementation of the RAID-1, RAID-4 and RAID-5 personalities of the MD device driver in the Linux kernel, providing users with high performance and reliable, secondary-storage capability using software". - + * Title: "Dynamic Kernels: Modularized Device Drivers" Author: Alessandro Rubini. - URL: http://www2.linuxjournal.com/lj-issues/issue23/1219.html + URL: http://www.linuxjournal.com/article.php?sid=1219 Keywords: device driver, module, loading/unloading modules, allocating resources. Description: Linux Journal Kernel Korner article. Here is it's @@ -134,10 +134,10 @@ loadable modules. This installment presents an introduction to the topic, preparing the reader to understand next month's installment". - + * Title: "Dynamic Kernels: Discovery" Author: Alessandro Rubini. - URL: http://www2.linuxjournal.com/lj-issues/issue24/1220.html + URL: http://www.linuxjournal.com/article.php?sid=1220 Keywords: character driver, init_module, clean_up module, autodetection, mayor number, minor number, file operations, open(), close(). @@ -146,20 +146,20 @@ the actual code to create custom module implementing a character device driver. It describes the code for module initialization and cleanup, as well as the open() and close() system calls". - + * Title: "The Devil's in the Details" Author: Georg v. Zezschwitz and Alessandro Rubini. - URL: http://www2.linuxjournal.com/lj-issues/issue25/1221.html + URL: http://www.linuxjournal.com/article.php?sid=1221 Keywords: read(), write(), select(), ioctl(), blocking/non blocking mode, interrupt handler. Description: Linux Journal Kernel Korner article. Here is it's abstract: "This article, the third of four on writing character device drivers, introduces concepts of reading, writing, and using ioctl-calls". - + * Title: "Dissecting Interrupts and Browsing DMA" Author: Alessandro Rubini and Georg v. Zezschwitz. - URL: http://www2.linuxjournal.com/lj-issues/issue26/1222.html + URL: http://www.linuxjournal.com/article.php?sid=1222 Keywords: interrupts, irqs, DMA, bottom halves, task queues. Description: Linux Journal Kernel Korner article. Here is it's abstract: "This is the fourth in a series of articles about @@ -170,10 +170,10 @@ writing, and several different facilities have been provided for different situations. We also investigate the complex topic of DMA". - + * Title: "Device Drivers Concluded" Author: Georg v. Zezschwitz. - URL: http://www2.linuxjournal.com/lj-issues/issue28/1287.html + URL: http://www.linuxjournal.com/article.php?sid=1287 Keywords: address spaces, pages, pagination, page management, demand loading, swapping, memory protection, memory mapping, mmap, virtual memory areas (VMAs), vremap, PCI. @@ -182,10 +182,10 @@ five articles about character device drivers. In this final section, Georg deals with memory mapping devices, beginning with an overall description of the Linux memory management concepts". - + * Title: "Network Buffers And Memory Management" Author: Alan Cox. - URL: http://www2.linuxjournal.com/lj-issues/issue30/1312.html + URL: http://www.linuxjournal.com/article.php?sid=1312 Keywords: sk_buffs, network devices, protocol/link layer variables, network devices flags, transmit, receive, configuration, multicast. @@ -214,28 +214,26 @@ of the Coda filesystem. This version document is meant to describe the current interface (version 1.0) as well as improvements we envisage". - + * Title: "Programming PCI-Devices under Linux" Author: Claus Schroeter. URL: - ftp://ftp.llp.fu-berlin.de/pub/linux/LINUX-LAB/whitepapers/pcip.ps - .gz + ftp://ftp.llp.fu-berlin.de/pub/linux/LINUX-LAB/whitepapers/pcip.ps.gz Keywords: PCI, device, busmastering. Description: 6 pages tutorial on PCI programming under Linux. Gives the basic concepts on the architecture of the PCI subsystem, as long as basic functions and macros to read/write the devices and perform busmastering. - + * Title: "Writing Character Device Driver for Linux" Author: R. Baruch and C. Schroeter. URL: - ftp://ftp.llp.fu-berlin.de/pub/linux/LINUX-LAB/whitepapers/drivers - .ps.gz + ftp://ftp.llp.fu-berlin.de/pub/linux/LINUX-LAB/whitepapers/drivers.ps.gz Keywords: character device drivers, I/O, signals, DMA, accessing ports in user space, kernel environment. Description: 68 pages paper on writing character drivers. A little bit old (1.993, 1.994) although still useful. - + * Title: "Design and Implementation of the Second Extended Filesystem" Author: Rémy Card, Theodore Ts'o, Stephen Tweedie. @@ -249,14 +247,14 @@ e2fsck's passes description... A must read! Notes: This paper was first published in the Proceedings of the First Dutch International Symposium on Linux, ISBN 90-367-0385-9. - + * Title: "Analysis of the Ext2fs structure" Author: Louis-Dominique Dubeau. - URL: http://step.polymtl.ca/~ldd/ext2fs/ext2fs_toc.html + URL: http://www.nondot.org/sabre/os/files/FileSystems/ext2fs/ Keywords: ext2, filesystem, ext2fs. Description: Description of ext2's blocks, directories, inodes, bitmaps, invariants... - + * Title: "Journaling the Linux ext2fs Filesystem" Author: Stephen C. Tweedie. URL: @@ -265,7 +263,7 @@ Description: Excellent 8-pages paper explaining the journaling capabilities added to ext2 by the author, showing different problems faced and the alternatives chosen. - + * Title: "Kernel API changes from 2.0 to 2.2" Author: Richard Gooch. URL: @@ -273,7 +271,7 @@ Keywords: 2.2, changes. Description: Kernel functions/structures/variables which changed from 2.0.x to 2.2.x. - + * Title: "Kernel API changes from 2.2 to 2.4" Author: Richard Gooch. URL: @@ -345,17 +343,7 @@ Notes: Beware: the main page states: "This document may not be published, printed or used in excerpts without explicit permission of the author". Fortunately, it may still be read... - - * Title: "Tour Of the Linux Kernel Source" - Author: Vijo Cherian. - URL: http://www.geocities.com/vijoc/tolks/tolks.html - Keywords: . - Description: A classic of this page! Was lost for a while and is - back again. Thanks Vijo! TOLKS: the name says it all. A tour of - the sources, describing directories, files, variables, data - structures... It covers general stuff, device drivers, - filesystems, IPC and Networking Code. - + * Title: "Linux Kernel Mailing List Glossary" Author: various URL: http://kernelnewbies.org/glossary/ @@ -377,7 +365,17 @@ kernels, but most of it applies to 2.2 too; 2.0 is slightly different". Freely redistributable under the conditions of the GNU General Public License. - + + * Title: "Global spinlock list and usage" + Author: Rick Lindsley. + URL: http://lse.sourceforge.net/lockhier/global-spin-lock + Keywords: spinlock. + Description: This is an attempt to document both the existence and + usage of the spinlocks in the Linux 2.4.5 kernel. Comprehensive + list of spinlocks showing when they are used, which functions + access them, how each lock is acquired, under what conditions it + is held, whether interrupts can occur or not while it is held... + * Title: "Porting Linux 2.0 Drivers To Linux 2.2: Changes and New Features " Author: Alan Cox. @@ -385,70 +383,70 @@ Keywords: ports, porting. Description: Article from Linux Magazine on porting from 2.0 to 2.2 kernels. - + * Title: "Porting Device Drivers To Linux 2.2: part II" Author: Alan Cox. URL: http://www.linux-mag.com/1999-06/gear_01.html Keywords: ports, porting. Description: Second part on porting from 2.0 to 2.2 kernels. - + * Title: "How To Make Sure Your Driver Will Work On The Power Macintosh" Author: Paul Mackerras. URL: http://www.linux-mag.com/1999-07/gear_01.html Keywords: Mac, Power Macintosh, porting, drivers, compatibility. Description: The title says it all. - + * Title: "An Introduction to SCSI Drivers" Author: Alan Cox. URL: http://www.linux-mag.com/1999-08/gear_01.html Keywords: SCSI, device, driver. Description: The title says it all. - + * Title: "Advanced SCSI Drivers And Other Tales" Author: Alan Cox. URL: http://www.linux-mag.com/1999-09/gear_01.html Keywords: SCSI, device, driver, advanced. Description: The title says it all. - + * Title: "Writing Linux Mouse Drivers" Author: Alan Cox. URL: http://www.linux-mag.com/1999-10/gear_01.html Keywords: mouse, driver, gpm. Description: The title says it all. - + * Title: "More on Mouse Drivers" Author: Alan Cox. URL: http://www.linux-mag.com/1999-11/gear_01.html Keywords: mouse, driver, gpm, races, asynchronous I/O. Description: The title still says it all. - + * Title: "Writing Video4linux Radio Driver" Author: Alan Cox. URL: http://www.linux-mag.com/1999-12/gear_01.html Keywords: video4linux, driver, radio, radio devices. Description: The title says it all. - + * Title: "Video4linux Drivers, Part 1: Video-Capture Device" Author: Alan Cox. URL: http://www.linux-mag.com/2000-01/gear_01.html Keywords: video4linux, driver, video capture, capture devices, camera driver. Description: The title says it all. - + * Title: "Video4linux Drivers, Part 2: Video-capture Devices" Author: Alan Cox. URL: http://www.linux-mag.com/2000-02/gear_01.html Keywords: video4linux, driver, video capture, capture devices, camera driver, control, query capabilities, capability, facility. Description: The title says it all. - + * Title: "PCI Management in Linux 2.2" Author: Alan Cox. URL: http://www.linux-mag.com/2000-03/gear_01.html Keywords: PCI, bus, bus-mastering. Description: The title says it all. - + * Title: "Linux 2.4 Kernel Internals" Author: Tigran Aivazian and Christoph Hellwig. URL: http://www.moses.uklinux.net/patches/lki.html @@ -456,13 +454,11 @@ Description: A little book used for a short training course. Covers building the kernel image, booting (including SMP bootup), process management, VFS and more. - + * Title: "Linux IP Networking. A Guide to the Implementation and Modification of the Linux Protocol Stack." Author: Glenn Herrin. - URL: - http://kernelnewbies.org/documents/ipnetworking/linuxipnetworking. - html + URL: http://www.cs.unh.edu/cnrg/gherrin Keywords: network, networking, protocol, IP, UDP, TCP, connection, socket, receiving, transmitting, forwarding, routing, packets, modules, /proc, sk_buff, FIB, tags. @@ -495,7 +491,7 @@ drivers for the Linux PCMCIA Card Services interface. It also describes how to write user-mode utilities for communicating with Card Services. - + * Title: "The Linux Kernel NFSD Implementation" Author: Neil Brown. URL: @@ -591,47 +587,22 @@ Pages: 520. ISBN: 2-212-08932-5 Notes: French. - - * Title: "The Linux Kernel Book" - Author: Remy Card, Eric Dumas, Franck Mevel. - Publisher: John Wiley & Sons. - Date: 1998. - ISBN: 0-471-98141-9 - Notes: English translation. - - * Title: "Linux 2.0" - Author: Remy Card, Eric Dumas, Franck Mevel. - Publisher: Gestión 2000. - Date: 1997. - Pages: 501. - ISBN: 8-480-88208-5 - Notes: Spanish translation. - + * Title: "Unix internals -- the new frontiers" Author: Uresh Vahalia. Publisher: Prentice Hall. Date: 1996. Pages: 600. ISBN: 0-13-101908-2 - - * Title: "Linux Core Kernel Commentary. Guide to Insider's Knowledge - on the Core Kernel of the Linux Code" - Author: Scott Maxwell. - Publisher: Coriolis. - Date: 1999. - Pages: 592. - ISBN: 1-57610-469-9 - Notes: CD-ROM included. Line by line commentary of the kernel - code. - - * Title: "Linux IP Stacks Commentary" - Author: Stephen Satchell and HBJ Clifford. - Publisher: Coriolis. - Date: 2000. - Pages: ???. - ISBN: 1-57610-470-2 - Notes: Line by line source code commentary book. - + + * Title: "The Design and Implementation of the 4.4 BSD UNIX + Operating System" + Author: Marshall Kirk McKusick, Keith Bostic, Michael J. Karels, + John S. Quarterman. + Publisher: Addison-Wesley. + Date: 1996. + ISBN: 0-201-54979-4 + * Title: "Programming for the real world - POSIX.4" Author: Bill O. Gallmeister. Publisher: O'Reilly & Associates, Inc.. @@ -640,18 +611,32 @@ ISBN: I-56592-074-0 Notes: Though not being directly about Linux, Linux aims to be POSIX. Good reference. - - * Title: "Understanding the Linux Kernel" - Author: Daniel P. Bovet and Marco Cesati. - Publisher: O'Reilly & Associates, Inc.. - Date: 2000. - Pages: 702. - ISBN: 0-596-00002-2 - Notes: Further information in - http://www.oreilly.com/catalog/linuxkernel/ - + + * Title: "UNIX Systems for Modern Architectures: Symmetric + Multiprocesssing and Caching for Kernel Programmers" + Author: Curt Schimmel. + Publisher: Addison Wesley. + Date: June, 1994. + Pages: 432. + ISBN: 0-201-63338-8 + + * Title: "The Design and Implementation of the 4.3 BSD UNIX + Operating System" + Author: Samuel J. Leffler, Marshall Kirk McKusick, Michael J. + Karels, John S. Quarterman. + Publisher: Addison-Wesley. + Date: 1989 (reprinted with corrections on October, 1990). + ISBN: 0-201-06196-1 + + * Title: "The Design of the UNIX Operating System" + Author: Maurice J. Bach. + Publisher: Prentice Hall. + Date: 1986. + Pages: 471. + ISBN: 0-13-201757-1 + MISCELLANEOUS: - + * Name: linux/Documentation Author: Many. URL: Just look inside your kernel sources. @@ -660,7 +645,7 @@ inside the Documentation directory. Some pages from this document (including this document itself) have been moved there, and might be more up to date than the web version. - + * Name: "Linux Source Driver" URL: http://lsd.linux.cz Keywords: Browsing source code. @@ -671,7 +656,7 @@ you can search Linux kernel (fulltext, macros, types, functions and variables) and LSD can generate patches for you on the fly (files, directories or kernel)". - + * Name: "Linux Kernel Source Reference" Author: Thomas Graichen. URL: http://innominate.org/~graichen/projects/lksr/ @@ -681,27 +666,27 @@ sources of any version starting from 1.0 up to the (daily updated) current version available. Also you can check the differences between two versions of a file". - + * Name: "Cross-Referencing Linux" URL: http://lxr.linux.no/source/ Keywords: Browsing source code. Description: Another web-based Linux kernel source code browser. Lots of cross references to variables and functions. You can see where they are defined and where they are used. - + * Name: "Linux Weekly News" URL: http://lwn.net Keywords: latest kernel news. Description: The title says it all. There's a fixed kernel section summarizing developers' work, bug fixes, new features and versions produced during the week. Published every Thursday. - + * Name: "Kernel Traffic" - URL: http://www.kerneltraffic.org/kernel-traffic/ + URL: http://kt.zork.net/kernel-traffic/ Keywords: linux-kernel mailing list, weekly kernel news. Description: Weekly newsletter covering the most relevant discussions of the linux-kernel mailing list. - + * Name: "CuTTiNG.eDGe.LiNuX" URL: http://edge.kernelnotes.org Keywords: changelist. @@ -709,7 +694,7 @@ release. What's new, what's better, what's changed. Myrdraal reads the patches and describes them. Pointers to the patches are there, too. - + * Name: "New linux-kernel Mailing List FAQ" URL: http://www.tux.org/lkml/ Keywords: linux-kernel mailing list FAQ. @@ -719,7 +704,7 @@ it. Read it to see how to join the mailing list. Dozens of interesting questions regarding the list, Linux, developers (who is ...?), terms (what is...?) are answered here too. Just read it. - + * Name: "Linux Virtual File System" Author: Peter J. Braam. URL: http://www.coda.cs.cmu.edu/doc/talks/linuxvfs/ @@ -727,10 +712,10 @@ Description: Set of slides, presumably from a presentation on the Linux VFS layer. Covers version 2.1.x, with dentries and the dcache. - + * Name: "Gary's Encyclopedia - The Linux Kernel" Author: Gary (I suppose...). - URL: http://members.aa.net/~swear/pedia/kernel.html + URL: http://www.lisoleg.net/cgi-bin/lisoleg.pl?view=kernel.htm Keywords: links, not found here?. Description: Gary's Encyclopedia exists to allow the rapid finding of documentation and other information of interest to GNU/Linux @@ -738,7 +723,7 @@ categories. This link is for kernel-specific links, documents, sites... Look there if you could not find here what you were looking for. - + * Name: "The home page of Linux-MM" Author: The Linux-MM team. URL: http://linux-mm.org/ @@ -747,7 +732,7 @@ Description: Site devoted to Linux Memory Management development. Memory related patches, HOWTOs, links, mm developers... Don't miss it if you are interested in memory management development! - + * Name: "Kernel Newbies IRC Channel" URL: http://www.kernelnewbies.org Keywords: IRC, newbies, channel, asking doubts. diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index d25acd51e181..c479d30eeaa3 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -48,6 +48,7 @@ parameter is applicable: ISAPNP ISA PnP code is enabled. ISDN Appropriate ISDN support is enabled. JOY Appropriate joystick support is enabled. + LIBATA Libata driver is enabled LP Printer support is enabled. LOOP Loopback device support is enabled. M68k M68k architecture is enabled. @@ -104,6 +105,9 @@ loader, and have no meaning to the kernel directly. Do not modify the syntax of boot loader parameters without extreme need or coordination with <Documentation/i386/boot.txt>. +There are also arch-specific kernel-parameters not documented here. +See for example <Documentation/x86_64/boot-options.txt>. + Note that ALL kernel parameters listed below are CASE SENSITIVE, and that a trailing = on the name of any parameter states that that parameter will be entered as an environment variable, whereas its absence indicates that @@ -361,6 +365,11 @@ 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 } + code_bytes [IA32] How many bytes of object code to print in an + oops report. + Range: 0 - 8192 + Default: 64 + disable_8254_timer enable_8254_timer [IA32/X86_64] Disable/Enable interrupt 0 timer routing @@ -601,6 +610,10 @@ and is between 256 and 4096 characters. It is defined in the file highmem otherwise. This also works to reduce highmem size on bigger boxes. + highres= [KNL] Enable/disable high resolution timer mode. + Valid parameters: "on", "off" + Default: "on" + hisax= [HW,ISDN] See Documentation/isdn/README.HiSax. @@ -851,7 +864,14 @@ and is between 256 and 4096 characters. It is defined in the file Format: <1-256> maxcpus= [SMP] Maximum number of processors that an SMP kernel - should make use of + should make use of. + Using "nosmp" or "maxcpus=0" will disable SMP + entirely (the MPS table probe still happens, though). + A command-line option of "maxcpus=<NUM>", where <NUM> + is an integer greater than 0, limits the maximum number + of CPUs activated in SMP mode to <NUM>. + Using "maxcpus=1" on an SMP kernel is the trivial + case of an SMP kernel with only one CPU. max_addr=[KMG] [KNL,BOOT,ia64] All physical memory greater than or equal to this physical address is ignored. @@ -1026,6 +1046,10 @@ and is between 256 and 4096 characters. It is defined in the file emulation library even if a 387 maths coprocessor is present. + noacpi [LIBATA] Disables use of ACPI in libata suspend/resume + when set. + Format: <int> + noaliencache [MM, NUMA] Disables the allcoation of alien caches in the slab allocator. Saves per-node memory, but will impact performance on real NUMA hardware. @@ -1070,6 +1094,10 @@ and is between 256 and 4096 characters. It is defined in the file in certain environments such as networked servers or real-time systems. + nohz= [KNL] Boottime enable/disable dynamic ticks + Valid arguments: on, off + Default: on + noirqbalance [IA-32,SMP,KNL] Disable kernel irq balancing noirqdebug [IA-32] Disables the code which attempts to detect and @@ -1259,6 +1287,12 @@ and is between 256 and 4096 characters. It is defined in the file This sorting is done to get a device order compatible with older (<= 2.4) kernels. nobfsort Don't sort PCI devices into breadth-first order. + cbiosize=nn[KMG] The fixed amount of bus space which is + reserved for the CardBus bridge's IO window. + The default value is 256 bytes. + cbmemsize=nn[KMG] The fixed amount of bus space which is + reserved for the CardBus bridge's memory + window. The default value is 64 megabytes. pcmv= [HW,PCMCIA] BadgePAD 4 diff --git a/Documentation/pci.txt b/Documentation/pci.txt index fd5028eca13e..cdf2f3c0ab14 100644 --- a/Documentation/pci.txt +++ b/Documentation/pci.txt @@ -205,8 +205,8 @@ Tips on when/where to use the above attributes: exclusively called by the probe() routine, can be marked __devinit. Ditto for remove() and __devexit. - o If mydriver_probe() is marked with __devinit(), then all address - references to mydriver_probe must use __devexit_p(mydriver_probe) + o If mydriver_remove() is marked with __devexit(), then all address + references to mydriver_remove must use __devexit_p(mydriver_remove) (in the struct pci_driver declaration for example). __devexit_p() will generate the function name _or_ NULL if the function will be discarded. For an example, see drivers/net/tg3.c. diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index 3b514672b80e..b41397d6430a 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -497,7 +497,7 @@ looks like in practice. | |- device_type = "cpu" | |- reg = <0> | |- clock-frequency = <5f5e1000> - | |- linux,boot-cpu + | |- 64-bit | |- linux,phandle = <2> | o memory@0 @@ -509,7 +509,6 @@ looks like in practice. o chosen |- name = "chosen" |- bootargs = "root=/dev/sda2" - |- linux,platform = <00000600> |- linux,phandle = <4> This tree is almost a minimal tree. It pretty much contains the @@ -519,7 +518,7 @@ physical memory layout. It also includes misc information passed through /chosen, like in this example, the platform type (mandatory) and the kernel command line arguments (optional). -The /cpus/PowerPC,970@0/linux,boot-cpu property is an example of a +The /cpus/PowerPC,970@0/64-bit property is an example of a property without a value. All other properties have a value. The significance of the #address-cells and #size-cells properties will be explained in chapter IV which defines precisely the required nodes and @@ -733,8 +732,7 @@ address which can extend beyond that limit. that typically get driven by the same platform code in the kernel, you would use a different "model" property but put a value in "compatible". The kernel doesn't directly use that - value (see /chosen/linux,platform for how the kernel chooses a - platform type) but it is generally useful. + value but it is generally useful. The root node is also generally where you add additional properties specific to your board like the serial number if any, that sort of @@ -778,7 +776,6 @@ address which can extend beyond that limit. bytes - d-cache-size : one cell, size of L1 data cache in bytes - i-cache-size : one cell, size of L1 instruction cache in bytes - - linux, boot-cpu : Should be defined if this cpu is the boot cpu. Recommended properties: @@ -843,11 +840,6 @@ address which can extend beyond that limit. the prom_init() trampoline when booting with an OF client interface, but that you have to provide yourself when using the flattened format. - Required properties: - - - linux,platform : This is your platform number as assigned by the - architecture maintainers - Recommended properties: - bootargs : This zero-terminated string is passed as the kernel diff --git a/Documentation/sh/new-machine.txt b/Documentation/sh/new-machine.txt index 73988e0d112b..5482bf5d005b 100644 --- a/Documentation/sh/new-machine.txt +++ b/Documentation/sh/new-machine.txt @@ -17,7 +17,7 @@ of the board-specific code (with the exception of stboards) ended up in arch/sh/kernel/ directly, with board-specific headers ending up in include/asm-sh/. For the new kernel, things are broken out by board type, companion chip type, and CPU type. Looking at a tree view of this directory -heirarchy looks like the following: +hierarchy looks like the following: Board-specific code: @@ -108,7 +108,7 @@ overloading), and you can feel free to name the directory after the family member itself. There are a few things that each board is required to have, both in the -arch/sh/boards and the include/asm-sh/ heirarchy. In order to better +arch/sh/boards and the include/asm-sh/ hierarchy. In order to better explain this, we use some examples for adding an imaginary board. For setup code, we're required at the very least to provide definitions for get_system_type() and platform_setup(). For our imaginary board, this diff --git a/Documentation/sony-laptop.txt b/Documentation/sony-laptop.txt new file mode 100644 index 000000000000..dfd26df056f4 --- /dev/null +++ b/Documentation/sony-laptop.txt @@ -0,0 +1,106 @@ +Sony Notebook Control Driver (SNC) Readme +----------------------------------------- + Copyright (C) 2004- 2005 Stelian Pop <stelian@popies.net> + Copyright (C) 2007 Mattia Dongili <malattia@linux.it> + +This mini-driver drives the SNC device present in the ACPI BIOS of +the Sony Vaio laptops. + +It gives access to some extra laptop functionalities. In its current +form, this driver let the user set or query the screen brightness +through the backlight subsystem and remove/apply power to some devices. + +Backlight control: +------------------ +If your laptop model supports it, you will find sysfs files in the +/sys/class/backlight/sony/ +directory. You will be able to query and set the current screen +brightness: + brightness get/set screen brightness (an iteger + between 0 and 7) + actual_brightness reading from this file will query the HW + to get real brightness value + max_brightness the maximum brightness value + + +Platform specific: +------------------ +Loading the sony-laptop module will create a +/sys/devices/platform/sony-laptop/ +directory populated with some files. + +You then read/write integer values from/to those files by using +standard UNIX tools. + +The files are: + brightness_default screen brightness which will be set + when the laptop will be rebooted + cdpower power on/off the internal CD drive + audiopower power on/off the internal sound card + lanpower power on/off the internal ethernet card + (only in debug mode) + +Note that some files may be missing if they are not supported +by your particular laptop model. + +Example usage: + # echo "1" > /sys/devices/platform/sony-laptop/brightness_default +sets the lowest screen brightness for the next and later reboots, + # echo "8" > /sys/devices/platform/sony-laptop/brightness_default +sets the highest screen brightness for the next and later reboots, + # cat /sys/devices/platform/sony-laptop/brightness_default +retrieves the value. + + # echo "0" > /sys/devices/platform/sony-laptop/audiopower +powers off the sound card, + # echo "1" > /sys/devices/platform/sony-laptop/audiopower +powers on the sound card. + +Development: +------------ + +If you want to help with the development of this driver (and +you are not afraid of any side effects doing strange things with +your ACPI BIOS could have on your laptop), load the driver and +pass the option 'debug=1'. + +REPEAT: DON'T DO THIS IF YOU DON'T LIKE RISKY BUSINESS. + +In your kernel logs you will find the list of all ACPI methods +the SNC device has on your laptop. You can see the GCDP/GCDP methods +used to pwer on/off the CD drive, but there are others. + +I HAVE NO IDEA WHAT THOSE METHODS DO. + +The sony-laptop driver creates, for some of those methods (the most +current ones found on several Vaio models), an entry under +/sys/devices/platform/sony-laptop, just like the 'cdpower' one. +You can create other entries corresponding to your own laptop methods by +further editing the source (see the 'sony_acpi_values' table, and add a new +entry to this table with your get/set method names using the +HANDLE_NAMES macro). + +Your mission, should you accept it, is to try finding out what +those entries are for, by reading/writing random values from/to those +files and find out what is the impact on your laptop. + +Should you find anything interesting, please report it back to me, +I will not disavow all knowledge of your actions :) + +Bugs/Limitations: +----------------- + +* This driver is not based on official documentation from Sony + (because there is none), so there is no guarantee this driver + will work at all, or do the right thing. Although this hasn't + happened to me, this driver could do very bad things to your + laptop, including permanent damage. + +* The sony-laptop and sonypi drivers do not interact at all. In the + future, sonypi could use sony-laptop to do (part of) its business. + +* spicctrl, which is the userspace tool used to communicate with the + sonypi driver (through /dev/sonypi) does not try to use the + sony-laptop driver. In the future, spicctrl could try sonypi first, + and if it isn't present, try sony-laptop instead. + diff --git a/Documentation/video4linux/bttv/Insmod-options b/Documentation/video4linux/bttv/Insmod-options index bb7c2cac7917..5ef75787f83a 100644 --- a/Documentation/video4linux/bttv/Insmod-options +++ b/Documentation/video4linux/bttv/Insmod-options @@ -57,7 +57,7 @@ bttv.o i2c_udelay= Allow reduce I2C speed. Default is 5 usecs (meaning 66,67 Kbps). The default is the maximum supported speed by kernel bitbang - algoritm. You may use lower numbers, if I2C + algorithm. You may use lower numbers, if I2C messages are lost (16 is known to work on all supported cards). diff --git a/Documentation/x86_64/boot-options.txt b/Documentation/x86_64/boot-options.txt index 5c86ed6f0448..625a21db0c2a 100644 --- a/Documentation/x86_64/boot-options.txt +++ b/Documentation/x86_64/boot-options.txt @@ -180,40 +180,81 @@ PCI pci=lastbus=NUMBER Scan upto NUMBER busses, no matter what the mptable says. pci=noacpi Don't use ACPI to set up PCI interrupt routing. -IOMMU - - iommu=[size][,noagp][,off][,force][,noforce][,leak][,memaper[=order]][,merge] - [,forcesac][,fullflush][,nomerge][,noaperture][,calgary] - size set size of iommu (in bytes) - noagp don't initialize the AGP driver and use full aperture. - off don't use the IOMMU - leak turn on simple iommu leak tracing (only when CONFIG_IOMMU_LEAK is on) - memaper[=order] allocate an own aperture over RAM with size 32MB^order. - noforce don't force IOMMU usage. Default. - force Force IOMMU. - merge Do SG merging. Implies force (experimental) - nomerge Don't do SG merging. - forcesac For SAC mode for masks <40bits (experimental) - fullflush Flush IOMMU on each allocation (default) - nofullflush Don't use IOMMU fullflush - allowed overwrite iommu off workarounds for specific chipsets. - soft Use software bounce buffering (default for Intel machines) - noaperture Don't touch the aperture for AGP. - allowdac Allow DMA >4GB - When off all DMA over >4GB is forced through an IOMMU or bounce - buffering. - nodac Forbid DMA >4GB - panic Always panic when IOMMU overflows - calgary Use the Calgary IOMMU if it is available - - swiotlb=pages[,force] - - pages Prereserve that many 128K pages for the software IO bounce buffering. - force Force all IO through the software TLB. - - calgary=[64k,128k,256k,512k,1M,2M,4M,8M] - calgary=[translate_empty_slots] - calgary=[disable=<PCI bus number>] +IOMMU (input/output memory management unit) + + Currently four x86-64 PCI-DMA mapping implementations exist: + + 1. <arch/x86_64/kernel/pci-nommu.c>: use no hardware/software IOMMU at all + (e.g. because you have < 3 GB memory). + Kernel boot message: "PCI-DMA: Disabling IOMMU" + + 2. <arch/x86_64/kernel/pci-gart.c>: AMD GART based hardware IOMMU. + Kernel boot message: "PCI-DMA: using GART IOMMU" + + 3. <arch/x86_64/kernel/pci-swiotlb.c> : Software IOMMU implementation. Used + e.g. if there is no hardware IOMMU in the system and it is need because + you have >3GB memory or told the kernel to us it (iommu=soft)) + Kernel boot message: "PCI-DMA: Using software bounce buffering + for IO (SWIOTLB)" + + 4. <arch/x86_64/pci-calgary.c> : IBM Calgary hardware IOMMU. Used in IBM + pSeries and xSeries servers. This hardware IOMMU supports DMA address + mapping with memory protection, etc. + Kernel boot message: "PCI-DMA: Using Calgary IOMMU" + + iommu=[<size>][,noagp][,off][,force][,noforce][,leak[=<nr_of_leak_pages>] + [,memaper[=<order>]][,merge][,forcesac][,fullflush][,nomerge] + [,noaperture][,calgary] + + General iommu options: + off Don't initialize and use any kind of IOMMU. + noforce Don't force hardware IOMMU usage when it is not needed. + (default). + force Force the use of the hardware IOMMU even when it is + not actually needed (e.g. because < 3 GB memory). + soft Use software bounce buffering (SWIOTLB) (default for + Intel machines). This can be used to prevent the usage + of an available hardware IOMMU. + + iommu options only relevant to the AMD GART hardware IOMMU: + <size> Set the size of the remapping area in bytes. + allowed Overwrite iommu off workarounds for specific chipsets. + fullflush Flush IOMMU on each allocation (default). + nofullflush Don't use IOMMU fullflush. + leak Turn on simple iommu leak tracing (only when + CONFIG_IOMMU_LEAK is on). Default number of leak pages + is 20. + memaper[=<order>] Allocate an own aperture over RAM with size 32MB<<order. + (default: order=1, i.e. 64MB) + merge Do scatter-gather (SG) merging. Implies "force" + (experimental). + nomerge Don't do scatter-gather (SG) merging. + noaperture Ask the IOMMU not to touch the aperture for AGP. + forcesac Force single-address cycle (SAC) mode for masks <40bits + (experimental). + noagp Don't initialize the AGP driver and use full aperture. + allowdac Allow double-address cycle (DAC) mode, i.e. DMA >4GB. + DAC is used with 32-bit PCI to push a 64-bit address in + two cycles. When off all DMA over >4GB is forced through + an IOMMU or software bounce buffering. + nodac Forbid DAC mode, i.e. DMA >4GB. + panic Always panic when IOMMU overflows. + calgary Use the Calgary IOMMU if it is available + + iommu options only relevant to the software bounce buffering (SWIOTLB) IOMMU + implementation: + swiotlb=<pages>[,force] + <pages> Prereserve that many 128K pages for the software IO + bounce buffering. + force Force all IO through the software TLB. + + Settings for the IBM Calgary hardware IOMMU currently found in IBM + pSeries and xSeries machines: + + calgary=[64k,128k,256k,512k,1M,2M,4M,8M] + calgary=[translate_empty_slots] + calgary=[disable=<PCI bus number>] + panic Always panic when IOMMU overflows 64k,...,8M - Set the size of each PCI slot's translation table when using the Calgary IOMMU. This is the size of the translation @@ -234,14 +275,14 @@ IOMMU Debugging - oops=panic Always panic on oopses. Default is to just kill the process, - but there is a small probability of deadlocking the machine. - This will also cause panics on machine check exceptions. - Useful together with panic=30 to trigger a reboot. + oops=panic Always panic on oopses. Default is to just kill the process, + but there is a small probability of deadlocking the machine. + This will also cause panics on machine check exceptions. + Useful together with panic=30 to trigger a reboot. - kstack=N Print that many words from the kernel stack in oops dumps. + kstack=N Print N words from the kernel stack in oops dumps. - pagefaulttrace Dump all page faults. Only useful for extreme debugging + pagefaulttrace Dump all page faults. Only useful for extreme debugging and will create a lot of output. call_trace=[old|both|newfallback|new] @@ -251,15 +292,8 @@ Debugging newfallback: use new unwinder but fall back to old if it gets stuck (default) - call_trace=[old|both|newfallback|new] - old: use old inexact backtracer - new: use new exact dwarf2 unwinder - both: print entries from both - newfallback: use new unwinder but fall back to old if it gets - stuck (default) - -Misc +Miscellaneous noreplacement Don't replace instructions with more appropriate ones for the CPU. This may be useful on asymmetric MP systems - where some CPU have less capabilities than the others. + where some CPUs have less capabilities than others. diff --git a/Documentation/x86_64/cpu-hotplug-spec b/Documentation/x86_64/cpu-hotplug-spec index 5c0fa345e556..3c23e0587db3 100644 --- a/Documentation/x86_64/cpu-hotplug-spec +++ b/Documentation/x86_64/cpu-hotplug-spec @@ -2,7 +2,7 @@ Firmware support for CPU hotplug under Linux/x86-64 --------------------------------------------------- Linux/x86-64 supports CPU hotplug now. For various reasons Linux wants to -know in advance boot time the maximum number of CPUs that could be plugged +know in advance of boot time the maximum number of CPUs that could be plugged into the system. ACPI 3.0 currently has no official way to supply this information from the firmware to the operating system. diff --git a/Documentation/x86_64/kernel-stacks b/Documentation/x86_64/kernel-stacks index bddfddd466ab..5ad65d51fb95 100644 --- a/Documentation/x86_64/kernel-stacks +++ b/Documentation/x86_64/kernel-stacks @@ -9,9 +9,9 @@ zombie. While the thread is in user space the kernel stack is empty except for the thread_info structure at the bottom. In addition to the per thread stacks, there are specialized stacks -associated with each cpu. These stacks are only used while the kernel -is in control on that cpu, when a cpu returns to user space the -specialized stacks contain no useful data. The main cpu stacks is +associated with each CPU. These stacks are only used while the kernel +is in control on that CPU; when a CPU returns to user space the +specialized stacks contain no useful data. The main CPU stacks are: * Interrupt stack. IRQSTACKSIZE @@ -32,17 +32,17 @@ x86_64 also has a feature which is not available on i386, the ability to automatically switch to a new stack for designated events such as double fault or NMI, which makes it easier to handle these unusual events on x86_64. This feature is called the Interrupt Stack Table -(IST). There can be up to 7 IST entries per cpu. The IST code is an -index into the Task State Segment (TSS), the IST entries in the TSS -point to dedicated stacks, each stack can be a different size. +(IST). There can be up to 7 IST entries per CPU. The IST code is an +index into the Task State Segment (TSS). The IST entries in the TSS +point to dedicated stacks; each stack can be a different size. -An IST is selected by an non-zero value in the IST field of an +An IST is selected by a non-zero value in the IST field of an interrupt-gate descriptor. When an interrupt occurs and the hardware loads such a descriptor, the hardware automatically sets the new stack pointer based on the IST value, then invokes the interrupt handler. If software wants to allow nested IST interrupts then the handler must adjust the IST values on entry to and exit from the interrupt handler. -(this is occasionally done, e.g. for debug exceptions) +(This is occasionally done, e.g. for debug exceptions.) Events with different IST codes (i.e. with different stacks) can be nested. For example, a debug interrupt can safely be interrupted by an @@ -58,17 +58,17 @@ The currently assigned IST stacks are :- Used for interrupt 12 - Stack Fault Exception (#SS). - This allows to recover from invalid stack segments. Rarely + This allows the CPU to recover from invalid stack segments. Rarely happens. * DOUBLEFAULT_STACK. EXCEPTION_STKSZ (PAGE_SIZE). Used for interrupt 8 - Double Fault Exception (#DF). - Invoked when handling a exception causes another exception. Happens - when the kernel is very confused (e.g. kernel stack pointer corrupt) - Using a separate stack allows to recover from it well enough in many - cases to still output an oops. + Invoked when handling one exception causes another exception. Happens + when the kernel is very confused (e.g. kernel stack pointer corrupt). + Using a separate stack allows the kernel to recover from it well enough + in many cases to still output an oops. * NMI_STACK. EXCEPTION_STKSZ (PAGE_SIZE). diff --git a/Documentation/x86_64/machinecheck b/Documentation/x86_64/machinecheck new file mode 100644 index 000000000000..068a6d9904b9 --- /dev/null +++ b/Documentation/x86_64/machinecheck @@ -0,0 +1,70 @@ + +Configurable sysfs parameters for the x86-64 machine check code. + +Machine checks report internal hardware error conditions detected +by the CPU. Uncorrected errors typically cause a machine check +(often with panic), corrected ones cause a machine check log entry. + +Machine checks are organized in banks (normally associated with +a hardware subsystem) and subevents in a bank. The exact meaning +of the banks and subevent is CPU specific. + +mcelog knows how to decode them. + +When you see the "Machine check errors logged" message in the system +log then mcelog should run to collect and decode machine check entries +from /dev/mcelog. Normally mcelog should be run regularly from a cronjob. + +Each CPU has a directory in /sys/devices/system/machinecheck/machinecheckN +(N = CPU number) + +The directory contains some configurable entries: + +Entries: + +bankNctl +(N bank number) + 64bit Hex bitmask enabling/disabling specific subevents for bank N + When a bit in the bitmask is zero then the respective + subevent will not be reported. + By default all events are enabled. + Note that BIOS maintain another mask to disable specific events + per bank. This is not visible here + +The following entries appear for each CPU, but they are truly shared +between all CPUs. + +check_interval + How often to poll for corrected machine check errors, in seconds + (Note output is hexademical). Default 5 minutes. + +tolerant + Tolerance level. When a machine check exception occurs for a non + corrected machine check the kernel can take different actions. + Since machine check exceptions can happen any time it is sometimes + risky for the kernel to kill a process because it defies + normal kernel locking rules. The tolerance level configures + how hard the kernel tries to recover even at some risk of deadlock. + + 0: always panic, + 1: panic if deadlock possible, + 2: try to avoid panic, + 3: never panic or exit (for testing only) + + Default: 1 + + Note this only makes a difference if the CPU allows recovery + from a machine check exception. Current x86 CPUs generally do not. + +trigger + Program to run when a machine check event is detected. + This is an alternative to running mcelog regularly from cron + and allows to detect events faster. + +TBD document entries for AMD threshold interrupt configuration + +For more details about the x86 machine check architecture +see the Intel and AMD architecture manuals from their developer websites. + +For more details about the architecture see +see http://one.firstfloor.org/~andi/mce.pdf diff --git a/Documentation/x86_64/mm.txt b/Documentation/x86_64/mm.txt index 133561b9cb0c..f42798ed1c54 100644 --- a/Documentation/x86_64/mm.txt +++ b/Documentation/x86_64/mm.txt @@ -3,26 +3,26 @@ Virtual memory map with 4 level page tables: -0000000000000000 - 00007fffffffffff (=47bits) user space, different per mm +0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm hole caused by [48:63] sign extension -ffff800000000000 - ffff80ffffffffff (=40bits) guard hole -ffff810000000000 - ffffc0ffffffffff (=46bits) direct mapping of all phys. memory -ffffc10000000000 - ffffc1ffffffffff (=40bits) hole -ffffc20000000000 - ffffe1ffffffffff (=45bits) vmalloc/ioremap space +ffff800000000000 - ffff80ffffffffff (=40 bits) guard hole +ffff810000000000 - ffffc0ffffffffff (=46 bits) direct mapping of all phys. memory +ffffc10000000000 - ffffc1ffffffffff (=40 bits) hole +ffffc20000000000 - ffffe1ffffffffff (=45 bits) vmalloc/ioremap space ... unused hole ... -ffffffff80000000 - ffffffff82800000 (=40MB) kernel text mapping, from phys 0 +ffffffff80000000 - ffffffff82800000 (=40 MB) kernel text mapping, from phys 0 ... unused hole ... -ffffffff88000000 - fffffffffff00000 (=1919MB) module mapping space +ffffffff88000000 - fffffffffff00000 (=1919 MB) module mapping space -The direct mapping covers all memory in the system upto the highest +The direct mapping covers all memory in the system up to the highest memory address (this means in some cases it can also include PCI memory -holes) +holes). vmalloc space is lazily synchronized into the different PML4 pages of the processes using the page fault handler, with init_level4_pgt as reference. -Current X86-64 implementations only support 40 bit of address space, -but we support upto 46bits. This expands into MBZ space in the page tables. +Current X86-64 implementations only support 40 bits of address space, +but we support up to 46 bits. This expands into MBZ space in the page tables. -Andi Kleen, Jul 2004 |