Merge commit 'v2.6.28-rc6' into irq/urgent

This commit is contained in:
Ingo Molnar
2008-11-23 10:52:33 +01:00
668 changed files with 19601 additions and 6860 deletions
+4 -40
View File
@@ -42,14 +42,8 @@ IRQ.txt
- description of what an IRQ is.
ManagementStyle
- how to (attempt to) manage kernel hackers.
MSI-HOWTO.txt
- the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
RCU/
- directory with info on RCU (read-copy update).
README.DAC960
- info on Mylex DAC960/DAC1100 PCI RAID Controller Driver for Linux.
README.cycladesZ
- info on Cyclades-Z firmware loading.
SAK.txt
- info on Secure Attention Keys.
SM501.txt
@@ -86,20 +80,16 @@ blackfin/
- directory with documentation for the Blackfin arch.
block/
- info on the Block I/O (BIO) layer.
blockdev/
- info on block devices & drivers
cachetlb.txt
- describes the cache/TLB flushing interfaces Linux uses.
cciss.txt
- info, major/minor #'s for Compaq's SMART Array Controllers.
cdrom/
- directory with information on the CD-ROM drivers that Linux has.
computone.txt
- info on Computone Intelliport II/Plus Multiport Serial Driver.
connector/
- docs on the netlink based userspace<->kernel space communication mod.
console/
- documentation on Linux console drivers.
cpqarray.txt
- info on using Compaq's SMART2 Intelligent Disk Array Controllers.
cpu-freq/
- info on CPU frequency and voltage scaling.
cpu-hotplug.txt
@@ -126,8 +116,6 @@ device-mapper/
- directory with info on Device Mapper.
devices.txt
- plain ASCII listing of all the nodes in /dev/ with major minor #'s.
digiepca.txt
- info on Digi Intl. {PC,PCI,EISA}Xx and Xem series cards.
dontdiff
- file containing a list of files that should never be diff'ed.
driver-model/
@@ -152,14 +140,10 @@ filesystems/
- info on the vfs and the various filesystems that Linux supports.
firmware_class/
- request_firmware() hotplug interface info.
floppy.txt
- notes and driver options for the floppy disk driver.
frv/
- Fujitsu FR-V Linux documentation.
gpio.txt
- overview of GPIO (General Purpose Input/Output) access conventions.
hayes-esp.txt
- info on using the Hayes ESP serial driver.
highuid.txt
- notes on the change from 16 bit to 32 bit user/group IDs.
timers/
@@ -186,8 +170,6 @@ io_ordering.txt
- info on ordering I/O writes to memory-mapped addresses.
ioctl/
- directory with documents describing various IOCTL calls.
ioctl-number.txt
- how to implement and register device/driver ioctl calls.
iostats.txt
- info on I/O statistics Linux kernel provides.
irqflags-tracing.txt
@@ -250,14 +232,10 @@ mips/
- directory with info about Linux on MIPS architecture.
mono.txt
- how to execute Mono-based .NET binaries with the help of BINFMT_MISC.
moxa-smartio
- file with info on installing/using Moxa multiport serial driver.
mutex-design.txt
- info on the generic mutex subsystem.
namespaces/
- directory with various information about namespaces
nbd.txt
- info on a TCP implementation of a network block device.
netlabel/
- directory with information on the NetLabel subsystem.
networking/
@@ -270,8 +248,6 @@ numastat.txt
- info on how to read Numa policy hit/miss statistics in sysfs.
oops-tracing.txt
- how to decode those nasty internal kernel error dump messages.
paride.txt
- information about the parallel port IDE subsystem.
parisc/
- directory with info on using Linux on PA-RISC architecture.
parport.txt
@@ -290,20 +266,16 @@ powerpc/
- directory with info on using Linux with the PowerPC.
preempt-locking.txt
- info on locking under a preemptive kernel.
printk-formats.txt
- how to get printk format specifiers right
prio_tree.txt
- info on radix-priority-search-tree use for indexing vmas.
ramdisk.txt
- short guide on how to set up and use the RAM disk.
rbtree.txt
- info on what red-black trees are and what they are for.
riscom8.txt
- notes on using the RISCom/8 multi-port serial driver.
robust-futex-ABI.txt
- documentation of the robust futex ABI.
robust-futexes.txt
- a description of what robust futexes are.
rocket.txt
- info on the Comtrol RocketPort multiport serial driver.
rt-mutex-design.txt
- description of the RealTime mutex implementation design.
rt-mutex.txt
@@ -332,8 +304,6 @@ sparc/
- directory with info on using Linux on Sparc architecture.
sparse.txt
- info on how to obtain and use the sparse tool for typechecking.
specialix.txt
- info on hardware/driver for specialix IO8+ multiport serial card.
spi/
- overview of Linux kernel Serial Peripheral Interface (SPI) support.
spinlocks.txt
@@ -342,14 +312,10 @@ stable_api_nonsense.txt
- info on why the kernel does not have a stable in-kernel api or abi.
stable_kernel_rules.txt
- rules and procedures for the -stable kernel releases.
stallion.txt
- info on using the Stallion multiport serial driver.
svga.txt
- short guide on selecting video modes at boot via VGA BIOS.
sysfs-rules.txt
- How not to use sysfs.
sx.txt
- info on the Specialix SX/SI multiport serial driver.
sysctl/
- directory with info on the /proc/sys/* files.
sysrq.txt
@@ -358,8 +324,6 @@ telephony/
- directory with info on telephony (e.g. voice over IP) support.
time_interpolators.txt
- info on time interpolators.
tty.txt
- guide to the locking policies of the tty layer.
uml/
- directory with information about User Mode Linux.
unicode.txt
+88
View File
@@ -0,0 +1,88 @@
What: /sys/class/c2port/
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/ directory will contain files and
directories that will provide a unified interface to
the C2 port interface.
What: /sys/class/c2port/c2portX
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/ directory is related to X-th
C2 port into the system. Each directory will contain files to
manage and control its C2 port.
What: /sys/class/c2port/c2portX/access
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/access file enable the access
to the C2 port from the system. No commands can be sent
till this entry is set to 0.
What: /sys/class/c2port/c2portX/dev_id
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/dev_id file show the device ID
of the connected micro.
What: /sys/class/c2port/c2portX/flash_access
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/flash_access file enable the
access to the on-board flash of the connected micro.
No commands can be sent till this entry is set to 0.
What: /sys/class/c2port/c2portX/flash_block_size
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/flash_block_size file show
the on-board flash block size of the connected micro.
What: /sys/class/c2port/c2portX/flash_blocks_num
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/flash_blocks_num file show
the on-board flash blocks number of the connected micro.
What: /sys/class/c2port/c2portX/flash_data
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/flash_data file export
the content of the on-board flash of the connected micro.
What: /sys/class/c2port/c2portX/flash_erase
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/flash_erase file execute
the "erase" command on the on-board flash of the connected
micro.
What: /sys/class/c2port/c2portX/flash_erase
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/flash_erase file show the
on-board flash size of the connected micro.
What: /sys/class/c2port/c2portX/reset
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/reset file execute a "reset"
command on the connected micro.
What: /sys/class/c2port/c2portX/rev_id
Date: October 2008
Contact: Rodolfo Giometti <giometti@linux.it>
Description:
The /sys/class/c2port/c2portX/rev_id file show the revision ID
of the connected micro.
@@ -89,7 +89,7 @@ Description:
error - an interrupt that can't be accounted for above.
invalid: it's either a wakeup GPE or a GPE/Fixed Event that
invalid: it's either a GPE or a Fixed Event that
doesn't have an event handler.
disable: the GPE/Fixed Event is valid but disabled.
@@ -117,30 +117,30 @@ Description:
and other user space applications so that the machine won't shutdown
when pressing the power button.
# cat ff_pwr_btn
0
0 enabled
# press the power button for 3 times;
# cat ff_pwr_btn
3
3 enabled
# echo disable > ff_pwr_btn
# cat ff_pwr_btn
disable
3 disabled
# press the power button for 3 times;
# cat ff_pwr_btn
disable
3 disabled
# echo enable > ff_pwr_btn
# cat ff_pwr_btn
4
4 enabled
/*
* this is because the status bit is set even if the enable bit is cleared,
* and it triggers an ACPI fixed event when the enable bit is set again
*/
# press the power button for 3 times;
# cat ff_pwr_btn
7
7 enabled
# echo disable > ff_pwr_btn
# press the power button for 3 times;
# echo clear > ff_pwr_btn /* clear the status bit */
# echo disable > ff_pwr_btn
# cat ff_pwr_btn
7
7 enabled
+2
View File
@@ -1,5 +1,7 @@
00-INDEX
- this file
MSI-HOWTO.txt
- the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
PCI-DMA-mapping.txt
- info for PCI drivers using DMA portably across all platforms
PCIEBUS-HOWTO.txt
+148
View File
@@ -0,0 +1,148 @@
ACPI Debug Output
The ACPI CA, the Linux ACPI core, and some ACPI drivers can generate debug
output. This document describes how to use this facility.
Compile-time configuration
--------------------------
ACPI debug output is globally enabled by CONFIG_ACPI_DEBUG. If this config
option is turned off, the debug messages are not even built into the
kernel.
Boot- and run-time configuration
--------------------------------
When CONFIG_ACPI_DEBUG=y, you can select the component and level of messages
you're interested in. At boot-time, use the acpi.debug_layer and
acpi.debug_level kernel command line options. After boot, you can use the
debug_layer and debug_level files in /sys/module/acpi/parameters/ to control
the debug messages.
debug_layer (component)
-----------------------
The "debug_layer" is a mask that selects components of interest, e.g., a
specific driver or part of the ACPI interpreter. To build the debug_layer
bitmask, look for the "#define _COMPONENT" in an ACPI source file.
You can set the debug_layer mask at boot-time using the acpi.debug_layer
command line argument, and you can change it after boot by writing values
to /sys/module/acpi/parameters/debug_layer.
The possible components are defined in include/acpi/acoutput.h and
include/acpi/acpi_drivers.h. Reading /sys/module/acpi/parameters/debug_layer
shows the supported mask values, currently these:
ACPI_UTILITIES 0x00000001
ACPI_HARDWARE 0x00000002
ACPI_EVENTS 0x00000004
ACPI_TABLES 0x00000008
ACPI_NAMESPACE 0x00000010
ACPI_PARSER 0x00000020
ACPI_DISPATCHER 0x00000040
ACPI_EXECUTER 0x00000080
ACPI_RESOURCES 0x00000100
ACPI_CA_DEBUGGER 0x00000200
ACPI_OS_SERVICES 0x00000400
ACPI_CA_DISASSEMBLER 0x00000800
ACPI_COMPILER 0x00001000
ACPI_TOOLS 0x00002000
ACPI_BUS_COMPONENT 0x00010000
ACPI_AC_COMPONENT 0x00020000
ACPI_BATTERY_COMPONENT 0x00040000
ACPI_BUTTON_COMPONENT 0x00080000
ACPI_SBS_COMPONENT 0x00100000
ACPI_FAN_COMPONENT 0x00200000
ACPI_PCI_COMPONENT 0x00400000
ACPI_POWER_COMPONENT 0x00800000
ACPI_CONTAINER_COMPONENT 0x01000000
ACPI_SYSTEM_COMPONENT 0x02000000
ACPI_THERMAL_COMPONENT 0x04000000
ACPI_MEMORY_DEVICE_COMPONENT 0x08000000
ACPI_VIDEO_COMPONENT 0x10000000
ACPI_PROCESSOR_COMPONENT 0x20000000
debug_level
-----------
The "debug_level" is a mask that selects different types of messages, e.g.,
those related to initialization, method execution, informational messages, etc.
To build debug_level, look at the level specified in an ACPI_DEBUG_PRINT()
statement.
The ACPI interpreter uses several different levels, but the Linux
ACPI core and ACPI drivers generally only use ACPI_LV_INFO.
You can set the debug_level mask at boot-time using the acpi.debug_level
command line argument, and you can change it after boot by writing values
to /sys/module/acpi/parameters/debug_level.
The possible levels are defined in include/acpi/acoutput.h. Reading
/sys/module/acpi/parameters/debug_level shows the supported mask values,
currently these:
ACPI_LV_INIT 0x00000001
ACPI_LV_DEBUG_OBJECT 0x00000002
ACPI_LV_INFO 0x00000004
ACPI_LV_INIT_NAMES 0x00000020
ACPI_LV_PARSE 0x00000040
ACPI_LV_LOAD 0x00000080
ACPI_LV_DISPATCH 0x00000100
ACPI_LV_EXEC 0x00000200
ACPI_LV_NAMES 0x00000400
ACPI_LV_OPREGION 0x00000800
ACPI_LV_BFIELD 0x00001000
ACPI_LV_TABLES 0x00002000
ACPI_LV_VALUES 0x00004000
ACPI_LV_OBJECTS 0x00008000
ACPI_LV_RESOURCES 0x00010000
ACPI_LV_USER_REQUESTS 0x00020000
ACPI_LV_PACKAGE 0x00040000
ACPI_LV_ALLOCATIONS 0x00100000
ACPI_LV_FUNCTIONS 0x00200000
ACPI_LV_OPTIMIZATIONS 0x00400000
ACPI_LV_MUTEX 0x01000000
ACPI_LV_THREADS 0x02000000
ACPI_LV_IO 0x04000000
ACPI_LV_INTERRUPTS 0x08000000
ACPI_LV_AML_DISASSEMBLE 0x10000000
ACPI_LV_VERBOSE_INFO 0x20000000
ACPI_LV_FULL_TABLES 0x40000000
ACPI_LV_EVENTS 0x80000000
Examples
--------
For example, drivers/acpi/bus.c contains this:
#define _COMPONENT ACPI_BUS_COMPONENT
...
ACPI_DEBUG_PRINT((ACPI_DB_INFO, "Device insertion detected\n"));
To turn on this message, set the ACPI_BUS_COMPONENT bit in acpi.debug_layer
and the ACPI_LV_INFO bit in acpi.debug_level. (The ACPI_DEBUG_PRINT
statement uses ACPI_DB_INFO, which is macro based on the ACPI_LV_INFO
definition.)
Enable all AML "Debug" output (stores to the Debug object while interpreting
AML) during boot:
acpi.debug_layer=0xffffffff acpi.debug_level=0x2
Enable PCI and PCI interrupt routing debug messages:
acpi.debug_layer=0x400000 acpi.debug_level=0x4
Enable all ACPI hardware-related messages:
acpi.debug_layer=0x2 acpi.debug_level=0xffffffff
Enable all ACPI_DB_INFO messages after boot:
# echo 0x4 > /sys/module/acpi/parameters/debug_level
Show all valid component values:
# cat /sys/module/acpi/parameters/debug_layer
+16
View File
@@ -0,0 +1,16 @@
00-INDEX
- this file
README.DAC960
- info on Mylex DAC960/DAC1100 PCI RAID Controller Driver for Linux.
cciss.txt
- info, major/minor #'s for Compaq's SMART Array Controllers.
cpqarray.txt
- info on using Compaq's SMART2 Intelligent Disk Array Controllers.
floppy.txt
- notes and driver options for the floppy disk driver.
nbd.txt
- info on a TCP implementation of a network block device.
paride.txt
- information about the parallel port IDE subsystem.
ramdisk.txt
- short guide on how to set up and use the RAM disk.
+90
View File
@@ -0,0 +1,90 @@
C2 port support
---------------
(C) Copyright 2007 Rodolfo Giometti <giometti@enneenne.com>
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
Overview
--------
This driver implements the support for Linux of Silicon Labs (Silabs)
C2 Interface used for in-system programming of micro controllers.
By using this driver you can reprogram the in-system flash without EC2
or EC3 debug adapter. This solution is also useful in those systems
where the micro controller is connected via special GPIOs pins.
References
----------
The C2 Interface main references are at (http://www.silabs.com)
Silicon Laboratories site], see:
- AN127: FLASH Programming via the C2 Interface at
http://www.silabs.com/public/documents/tpub_doc/anote/Microcontrollers/Small_Form_Factor/en/an127.pdf, and
- C2 Specification at
http://www.silabs.com/public/documents/tpub_doc/spec/Microcontrollers/en/C2spec.pdf,
however it implements a two wire serial communication protocol (bit
banging) designed to enable in-system programming, debugging, and
boundary-scan testing on low pin-count Silicon Labs devices. Currently
this code supports only flash programming but extensions are easy to
add.
Using the driver
----------------
Once the driver is loaded you can use sysfs support to get C2port's
info or read/write in-system flash.
# ls /sys/class/c2port/c2port0/
access flash_block_size flash_erase rev_id
dev_id flash_blocks_num flash_size subsystem/
flash_access flash_data reset uevent
Initially the C2port access is disabled since you hardware may have
such lines multiplexed with other devices so, to get access to the
C2port, you need the command:
# echo 1 > /sys/class/c2port/c2port0/access
after that you should read the device ID and revision ID of the
connected micro controller:
# cat /sys/class/c2port/c2port0/dev_id
8
# cat /sys/class/c2port/c2port0/rev_id
1
However, for security reasons, the in-system flash access in not
enabled yet, to do so you need the command:
# echo 1 > /sys/class/c2port/c2port0/flash_access
After that you can read the whole flash:
# cat /sys/class/c2port/c2port0/flash_data > image
erase it:
# echo 1 > /sys/class/c2port/c2port0/flash_erase
and write it:
# cat image > /sys/class/c2port/c2port0/flash_data
after writing you have to reset the device to execute the new code:
# echo 1 > /sys/class/c2port/c2port0/reset
+12 -9
View File
@@ -1,4 +1,4 @@
The cgroup freezer is useful to batch job management system which start
The cgroup freezer is useful to batch job management system which start
and stop sets of tasks in order to schedule the resources of a machine
according to the desires of a system administrator. This sort of program
is often used on HPC clusters to schedule access to the cluster as a
@@ -6,7 +6,7 @@ whole. The cgroup freezer uses cgroups to describe the set of tasks to
be started/stopped by the batch job management system. It also provides
a means to start and stop the tasks composing the job.
The cgroup freezer will also be useful for checkpointing running groups
The cgroup freezer will also be useful for checkpointing running groups
of tasks. The freezer allows the checkpoint code to obtain a consistent
image of the tasks by attempting to force the tasks in a cgroup into a
quiescent state. Once the tasks are quiescent another task can
@@ -16,7 +16,7 @@ recoverable error occur. This also allows the checkpointed tasks to be
migrated between nodes in a cluster by copying the gathered information
to another node and restarting the tasks there.
Sequences of SIGSTOP and SIGCONT are not always sufficient for stopping
Sequences of SIGSTOP and SIGCONT are not always sufficient for stopping
and resuming tasks in userspace. Both of these signals are observable
from within the tasks we wish to freeze. While SIGSTOP cannot be caught,
blocked, or ignored it can be seen by waiting or ptracing parent tasks.
@@ -37,26 +37,29 @@ demonstrate this problem using nested bash shells:
<at this point 16990 exits and causes 16644 to exit too>
This happens because bash can observe both signals and choose how it
This happens because bash can observe both signals and choose how it
responds to them.
Another example of a program which catches and responds to these
Another example of a program which catches and responds to these
signals is gdb. In fact any program designed to use ptrace is likely to
have a problem with this method of stopping and resuming tasks.
In contrast, the cgroup freezer uses the kernel freezer code to
In contrast, the cgroup freezer uses the kernel freezer code to
prevent the freeze/unfreeze cycle from becoming visible to the tasks
being frozen. This allows the bash example above and gdb to run as
expected.
The freezer subsystem in the container filesystem defines a file named
The freezer subsystem in the container filesystem defines a file named
freezer.state. Writing "FROZEN" to the state file will freeze all tasks in the
cgroup. Subsequently writing "THAWED" will unfreeze the tasks in the cgroup.
Reading will return the current state.
Note freezer.state doesn't exist in root cgroup, which means root cgroup
is non-freezable.
* Examples of usage :
# mkdir /containers/freezer
# mkdir /containers
# mount -t cgroup -ofreezer freezer /containers
# mkdir /containers/0
# echo $some_pid > /containers/0/tasks
@@ -94,6 +97,6 @@ things happens:
the freezer.state file
2) Userspace retries the freezing operation by writing "FROZEN" to
the freezer.state file (writing "FREEZING" is not legal
and returns EIO)
and returns EINVAL)
3) The tasks that blocked the cgroup from entering the "FROZEN"
state disappear from the cgroup's set of tasks.
@@ -56,30 +56,6 @@ Who: Mauro Carvalho Chehab <mchehab@infradead.org>
---------------------------
What: old tuner-3036 i2c driver
When: 2.6.28
Why: This driver is for VERY old i2c-over-parallel port teletext receiver
boxes. Rather then spending effort on converting this driver to V4L2,
and since it is extremely unlikely that anyone still uses one of these
devices, it was decided to drop it.
Who: Hans Verkuil <hverkuil@xs4all.nl>
Mauro Carvalho Chehab <mchehab@infradead.org>
---------------------------
What: V4L2 dpc7146 driver
When: 2.6.28
Why: Old driver for the dpc7146 demonstration board that is no longer
relevant. The last time this was tested on actual hardware was
probably around 2002. Since this is a driver for a demonstration
board the decision was made to remove it rather than spending a
lot of effort continually updating this driver to stay in sync
with the latest internal V4L2 or I2C API.
Who: Hans Verkuil <hverkuil@xs4all.nl>
Mauro Carvalho Chehab <mchehab@infradead.org>
---------------------------
What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
When: November 2005
Files: drivers/pcmcia/: pcmcia_ioctl.c
+5 -4
View File
@@ -39,10 +39,11 @@ The block device operation is optional, these block devices support it as of
today:
- dcssblk: s390 dcss block device driver
An address space operation named get_xip_page is used to retrieve reference
to a struct page. To address the target page, a reference to an address_space,
and a sector number is provided. A 3rd argument indicates whether the
function should allocate blocks if needed.
An address space operation named get_xip_mem is used to retrieve references
to a page frame number and a kernel address. To obtain these values a reference
to an address_space is provided. This function assigns values to the kmem and
pfn parameters. The third argument indicates whether the function should allocate
blocks if needed.
This address space operation is mutually exclusive with readpage&writepage that
do page cache read/write operations.
+72 -97
View File
@@ -8,7 +8,7 @@ Copyright 2008 Red Hat Inc.
Reviewers: Elias Oltmanns, Randy Dunlap, Andrew Morton,
John Kacur, and David Teigland.
Written for: 2.6.27-rc1
Written for: 2.6.28-rc2
Introduction
------------
@@ -50,26 +50,26 @@ of ftrace. Here is a list of some of the key files:
Note: all time values are in microseconds.
current_tracer : This is used to set or display the current tracer
current_tracer: This is used to set or display the current tracer
that is configured.
available_tracers : This holds the different types of tracers that
available_tracers: This holds the different types of tracers that
have been compiled into the kernel. The tracers
listed here can be configured by echoing their name
into current_tracer.
tracing_enabled : This sets or displays whether the current_tracer
tracing_enabled: This sets or displays whether the current_tracer
is activated and tracing or not. Echo 0 into this
file to disable the tracer or 1 to enable it.
trace : This file holds the output of the trace in a human readable
trace: This file holds the output of the trace in a human readable
format (described below).
latency_trace : This file shows the same trace but the information
latency_trace: This file shows the same trace but the information
is organized more to display possible latencies
in the system (described below).
trace_pipe : The output is the same as the "trace" file but this
trace_pipe: The output is the same as the "trace" file but this
file is meant to be streamed with live tracing.
Reads from this file will block until new data
is retrieved. Unlike the "trace" and "latency_trace"
@@ -82,11 +82,11 @@ of ftrace. Here is a list of some of the key files:
tracer is not adding more data, they will display
the same information every time they are read.
iter_ctrl : This file lets the user control the amount of data
iter_ctrl: This file lets the user control the amount of data
that is displayed in one of the above output
files.
trace_max_latency : Some of the tracers record the max latency.
trace_max_latency: Some of the tracers record the max latency.
For example, the time interrupts are disabled.
This time is saved in this file. The max trace
will also be stored, and displayed by either
@@ -94,29 +94,26 @@ of ftrace. Here is a list of some of the key files:
only be recorded if the latency is greater than
the value in this file. (in microseconds)
trace_entries : This sets or displays the number of trace
entries each CPU buffer can hold. The tracer buffers
are the same size for each CPU. The displayed number
is the size of the CPU buffer and not total size. The
trace_entries: This sets or displays the number of bytes each CPU
buffer can hold. The tracer buffers are the same size
for each CPU. The displayed number is the size of the
CPU buffer and not total size of all buffers. The
trace buffers are allocated in pages (blocks of memory
that the kernel uses for allocation, usually 4 KB in size).
Since each entry is smaller than a page, if the last
allocated page has room for more entries than were
requested, the rest of the page is used to allocate
entries.
If the last page allocated has room for more bytes
than requested, the rest of the page will be used,
making the actual allocation bigger than requested.
(Note, the size may not be a multiple of the page size due
to buffer managment overhead.)
This can only be updated when the current_tracer
is set to "none".
is set to "nop".
NOTE: It is planned on changing the allocated buffers
from being the number of possible CPUS to
the number of online CPUS.
tracing_cpumask : This is a mask that lets the user only trace
tracing_cpumask: This is a mask that lets the user only trace
on specified CPUS. The format is a hex string
representing the CPUS.
set_ftrace_filter : When dynamic ftrace is configured in (see the
set_ftrace_filter: When dynamic ftrace is configured in (see the
section below "dynamic ftrace"), the code is dynamically
modified (code text rewrite) to disable calling of the
function profiler (mcount). This lets tracing be configured
@@ -130,14 +127,11 @@ of ftrace. Here is a list of some of the key files:
be traced. If a function exists in both set_ftrace_filter
and set_ftrace_notrace, the function will _not_ be traced.
available_filter_functions : When a function is encountered the first
time by the dynamic tracer, it is recorded and
later the call is converted into a nop. This file
lists the functions that have been recorded
by the dynamic tracer and these functions can
be used to set the ftrace filter by the above
"set_ftrace_filter" file. (See the section "dynamic ftrace"
below for more details).
available_filter_functions: This lists the functions that ftrace
has processed and can trace. These are the function
names that you can pass to "set_ftrace_filter" or
"set_ftrace_notrace". (See the section "dynamic ftrace"
below for more details.)
The Tracers
@@ -145,7 +139,7 @@ The Tracers
Here is the list of current tracers that may be configured.
ftrace - function tracer that uses mcount to trace all functions.
function - function tracer that uses mcount to trace all functions.
sched_switch - traces the context switches between tasks.
@@ -166,8 +160,8 @@ Here is the list of current tracers that may be configured.
the highest priority task to get scheduled after
it has been woken up.
none - This is not a tracer. To remove all tracers from tracing
simply echo "none" into current_tracer.
nop - This is not a tracer. To remove all tracers from tracing
simply echo "nop" into current_tracer.
Examples of using the tracer
@@ -182,7 +176,7 @@ Output format:
Here is an example of the output format of the file "trace"
--------
# tracer: ftrace
# tracer: function
#
# TASK-PID CPU# TIMESTAMP FUNCTION
# | | | | |
@@ -192,7 +186,7 @@ Here is an example of the output format of the file "trace"
--------
A header is printed with the tracer name that is represented by the trace.
In this case the tracer is "ftrace". Then a header showing the format. Task
In this case the tracer is "function". Then a header showing the format. Task
name "bash", the task PID "4251", the CPU that it was running on
"01", the timestamp in <secs>.<usecs> format, the function name that was
traced "path_put" and the parent function that called this function
@@ -1003,22 +997,20 @@ is the stack for the hard interrupt. This hides the fact that NEED_RESCHED
has been set. We do not see the 'N' until we switch back to the task's
assigned stack.
ftrace
------
function
--------
ftrace is not only the name of the tracing infrastructure, but it
is also a name of one of the tracers. The tracer is the function
tracer. Enabling the function tracer can be done from the
debug file system. Make sure the ftrace_enabled is set otherwise
this tracer is a nop.
This tracer is the function tracer. Enabling the function tracer
can be done from the debug file system. Make sure the ftrace_enabled is
set; otherwise this tracer is a nop.
# sysctl kernel.ftrace_enabled=1
# echo ftrace > /debug/tracing/current_tracer
# echo function > /debug/tracing/current_tracer
# echo 1 > /debug/tracing/tracing_enabled
# usleep 1
# echo 0 > /debug/tracing/tracing_enabled
# cat /debug/tracing/trace
# tracer: ftrace
# tracer: function
#
# TASK-PID CPU# TIMESTAMP FUNCTION
# | | | | |
@@ -1040,10 +1032,10 @@ this tracer is a nop.
[...]
Note: ftrace uses ring buffers to store the above entries. The newest data
may overwrite the oldest data. Sometimes using echo to stop the trace
is not sufficient because the tracing could have overwritten the data
that you wanted to record. For this reason, it is sometimes better to
Note: function tracer uses ring buffers to store the above entries.
The newest data may overwrite the oldest data. Sometimes using echo to
stop the trace is not sufficient because the tracing could have overwritten
the data that you wanted to record. For this reason, it is sometimes better to
disable tracing directly from a program. This allows you to stop the
tracing at the point that you hit the part that you are interested in.
To disable the tracing directly from a C program, something like following
@@ -1077,18 +1069,31 @@ every kernel function, produced by the -pg switch in gcc), starts
of pointing to a simple return. (Enabling FTRACE will include the
-pg switch in the compiling of the kernel.)
When dynamic ftrace is initialized, it calls kstop_machine to make
the machine act like a uniprocessor so that it can freely modify code
without worrying about other processors executing that same code. At
initialization, the mcount calls are changed to call a "record_ip"
function. After this, the first time a kernel function is called,
it has the calling address saved in a hash table.
At compile time every C file object is run through the
recordmcount.pl script (located in the scripts directory). This
script will process the C object using objdump to find all the
locations in the .text section that call mcount. (Note, only
the .text section is processed, since processing other sections
like .init.text may cause races due to those sections being freed).
Later on the ftraced kernel thread is awoken and will again call
kstop_machine if new functions have been recorded. The ftraced thread
will change all calls to mcount to "nop". Just calling mcount
and having mcount return has shown a 10% overhead. By converting
it to a nop, there is no measurable overhead to the system.
A new section called "__mcount_loc" is created that holds references
to all the mcount call sites in the .text section. This section is
compiled back into the original object. The final linker will add
all these references into a single table.
On boot up, before SMP is initialized, the dynamic ftrace code
scans this table and updates all the locations into nops. It also
records the locations, which are added to the available_filter_functions
list. Modules are processed as they are loaded and before they are
executed. When a module is unloaded, it also removes its functions from
the ftrace function list. This is automatic in the module unload
code, and the module author does not need to worry about it.
When tracing is enabled, kstop_machine is called to prevent races
with the CPUS executing code being modified (which can cause the
CPU to do undesireable things), and the nops are patched back
to calls. But this time, they do not call mcount (which is just
a function stub). They now call into the ftrace infrastructure.
One special side-effect to the recording of the functions being
traced is that we can now selectively choose which functions we
@@ -1251,36 +1256,6 @@ Produces:
We can see that there's no more lock or preempt tracing.
ftraced
-------
As mentioned above, when dynamic ftrace is configured in, a kernel
thread wakes up once a second and checks to see if there are mcount
calls that need to be converted into nops. If there are not any, then
it simply goes back to sleep. But if there are some, it will call
kstop_machine to convert the calls to nops.
There may be a case in which you do not want this added latency.
Perhaps you are doing some audio recording and this activity might
cause skips in the playback. There is an interface to disable
and enable the "ftraced" kernel thread.
# echo 0 > /debug/tracing/ftraced_enabled
This will disable the calling of kstop_machine to update the
mcount calls to nops. Remember that there is a large overhead
to calling mcount. Without this kernel thread, that overhead will
exist.
If there are recorded calls to mcount, any write to the ftraced_enabled
file will cause the kstop_machine to run. This means that a
user can manually perform the updates when they want to by simply
echoing a '0' into the ftraced_enabled file.
The updates are also done at the beginning of enabling a tracer
that uses ftrace function recording.
trace_pipe
----------
@@ -1289,14 +1264,14 @@ on the tracing is different. Every read from trace_pipe is consumed.
This means that subsequent reads will be different. The trace
is live.
# echo ftrace > /debug/tracing/current_tracer
# echo function > /debug/tracing/current_tracer
# cat /debug/tracing/trace_pipe > /tmp/trace.out &
[1] 4153
# echo 1 > /debug/tracing/tracing_enabled
# usleep 1
# echo 0 > /debug/tracing/tracing_enabled
# cat /debug/tracing/trace
# tracer: ftrace
# tracer: function
#
# TASK-PID CPU# TIMESTAMP FUNCTION
# | | | | |
@@ -1317,7 +1292,7 @@ is live.
Note, reading the trace_pipe file will block until more input is added.
By changing the tracer, trace_pipe will issue an EOF. We needed
to set the ftrace tracer _before_ cating the trace_pipe file.
to set the function tracer _before_ we "cat" the trace_pipe file.
trace entries
@@ -1334,10 +1309,10 @@ number of entries.
65620
Note, to modify this, you must have tracing completely disabled. To do that,
echo "none" into the current_tracer. If the current_tracer is not set
to "none", an EINVAL error will be returned.
echo "nop" into the current_tracer. If the current_tracer is not set
to "nop", an EINVAL error will be returned.
# echo none > /debug/tracing/current_tracer
# echo nop > /debug/tracing/current_tracer
# echo 100000 > /debug/tracing/trace_entries
# cat /debug/tracing/trace_entries
100045
+67
View File
@@ -0,0 +1,67 @@
Kernel driver adt7462
======================
Supported chips:
* Analog Devices ADT7462
Prefix: 'adt7462'
Addresses scanned: I2C 0x58, 0x5C
Datasheet: Publicly available at the Analog Devices website
Author: Darrick J. Wong
Description
-----------
This driver implements support for the Analog Devices ADT7462 chip family.
This chip is a bit of a beast. It has 8 counters for measuring fan speed. It
can also measure 13 voltages or 4 temperatures, or various combinations of the
two. See the chip documentation for more details about the exact set of
configurations. This driver does not allow one to configure the chip; that is
left to the system designer.
A sophisticated control system for the PWM outputs is designed into the ADT7462
that allows fan speed to be adjusted automatically based on any of the three
temperature sensors. Each PWM output is individually adjustable and
programmable. Once configured, the ADT7462 will adjust the PWM outputs in
response to the measured temperatures without further host intervention. This
feature can also be disabled for manual control of the PWM's.
Each of the measured inputs (voltage, temperature, fan speed) has
corresponding high/low limit values. The ADT7462 will signal an ALARM if
any measured value exceeds either limit.
The ADT7462 samples all inputs continuously. The driver will not read
the registers more often than once every other second. Further,
configuration data is only read once per minute.
Special Features
----------------
The ADT7462 have a 10-bit ADC and can therefore measure temperatures
with 0.25 degC resolution.
The Analog Devices datasheet is very detailed and describes a procedure for
determining an optimal configuration for the automatic PWM control.
The driver will report sensor labels when it is able to determine that
information from the configuration registers.
Configuration Notes
-------------------
Besides standard interfaces driver adds the following:
* PWM Control
* pwm#_auto_point1_pwm and temp#_auto_point1_temp and
* pwm#_auto_point2_pwm and temp#_auto_point2_temp -
point1: Set the pwm speed at a lower temperature bound.
point2: Set the pwm speed at a higher temperature bound.
The ADT7462 will scale the pwm between the lower and higher pwm speed when
the temperature is between the two temperature boundaries. PWM values range
from 0 (off) to 255 (full speed). Fan speed will be set to maximum when the
temperature sensor associated with the PWM control exceeds temp#_max.

Some files were not shown because too many files have changed in this diff Show More