You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge branch 'master' into next
This commit is contained in:
James Morris
@@ -49,6 +49,7 @@ include/linux/compile.h
|
||||
include/linux/version.h
|
||||
include/linux/utsrelease.h
|
||||
include/linux/bounds.h
|
||||
include/generated
|
||||
|
||||
# stgit generated dirs
|
||||
patches-*
|
||||
|
||||
@@ -495,6 +495,11 @@ S: Kopmansg 2
|
||||
S: 411 13 Goteborg
|
||||
S: Sweden
|
||||
|
||||
N: Paul Bristow
|
||||
E: paul@paulbristow.net
|
||||
W: http://paulbristow.net/linux/idefloppy.html
|
||||
D: Maintainer of IDE/ATAPI floppy driver
|
||||
|
||||
N: Dominik Brodowski
|
||||
E: linux@brodo.de
|
||||
W: http://www.brodo.de/
|
||||
@@ -1407,8 +1412,8 @@ P: 1024D/77D4FC9B F5C5 1C20 1DFC DEC3 3107 54A4 2332 ADFC 77D4 FC9B
|
||||
D: National Language Support
|
||||
D: Linux Internationalization Project
|
||||
D: German Localization for Linux and GNU software
|
||||
S: Kriemhildring 12a
|
||||
S: 65795 Hattersheim am Main
|
||||
S: Auf der Fittel 18
|
||||
S: 53347 Alfter
|
||||
S: Germany
|
||||
|
||||
N: Christoph Hellwig
|
||||
@@ -2642,6 +2647,10 @@ S: C/ Mieses 20, 9-B
|
||||
S: Valladolid 47009
|
||||
S: Spain
|
||||
|
||||
N: Gadi Oxman
|
||||
E: gadio@netvision.net.il
|
||||
D: Original author and maintainer of IDE/ATAPI floppy/tape drivers
|
||||
|
||||
N: Greg Page
|
||||
E: gpage@sovereign.org
|
||||
D: IPX development and support
|
||||
@@ -3571,6 +3580,12 @@ N: Dirk Verworner
|
||||
D: Co-author of German book ``Linux-Kernel-Programmierung''
|
||||
D: Co-founder of Berlin Linux User Group
|
||||
|
||||
N: Riku Voipio
|
||||
E: riku.voipio@iki.fi
|
||||
D: Author of PCA9532 LED and Fintek f75375s hwmon driver
|
||||
D: Some random ARM board patches
|
||||
S: Finland
|
||||
|
||||
N: Patrick Volkerding
|
||||
E: volkerdi@ftp.cdrom.com
|
||||
D: Produced the Slackware distribution, updated the SVGAlib
|
||||
|
||||
@@ -86,6 +86,8 @@ cachetlb.txt
|
||||
- describes the cache/TLB flushing interfaces Linux uses.
|
||||
cdrom/
|
||||
- directory with information on the CD-ROM drivers that Linux has.
|
||||
cgroups/
|
||||
- cgroups features, including cpusets and memory controller.
|
||||
connector/
|
||||
- docs on the netlink based userspace<->kernel space communication mod.
|
||||
console/
|
||||
@@ -98,8 +100,6 @@ cpu-load.txt
|
||||
- document describing how CPU load statistics are collected.
|
||||
cpuidle/
|
||||
- info on CPU_IDLE, CPU idle state management subsystem.
|
||||
cpusets.txt
|
||||
- documents the cpusets feature; assign CPUs and Mem to a set of tasks.
|
||||
cputopology.txt
|
||||
- documentation on how CPU topology info is exported via sysfs.
|
||||
cris/
|
||||
|
||||
@@ -0,0 +1,71 @@
|
||||
What: /sys/kernel/debug/kmemtrace/
|
||||
Date: July 2008
|
||||
Contact: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
|
||||
Description:
|
||||
|
||||
In kmemtrace-enabled kernels, the following files are created:
|
||||
|
||||
/sys/kernel/debug/kmemtrace/
|
||||
cpu<n> (0400) Per-CPU tracing data, see below. (binary)
|
||||
total_overruns (0400) Total number of bytes which were dropped from
|
||||
cpu<n> files because of full buffer condition,
|
||||
non-binary. (text)
|
||||
abi_version (0400) Kernel's kmemtrace ABI version. (text)
|
||||
|
||||
Each per-CPU file should be read according to the relay interface. That is,
|
||||
the reader should set affinity to that specific CPU and, as currently done by
|
||||
the userspace application (though there are other methods), use poll() with
|
||||
an infinite timeout before every read(). Otherwise, erroneous data may be
|
||||
read. The binary data has the following _core_ format:
|
||||
|
||||
Event ID (1 byte) Unsigned integer, one of:
|
||||
0 - represents an allocation (KMEMTRACE_EVENT_ALLOC)
|
||||
1 - represents a freeing of previously allocated memory
|
||||
(KMEMTRACE_EVENT_FREE)
|
||||
Type ID (1 byte) Unsigned integer, one of:
|
||||
0 - this is a kmalloc() / kfree()
|
||||
1 - this is a kmem_cache_alloc() / kmem_cache_free()
|
||||
2 - this is a __get_free_pages() et al.
|
||||
Event size (2 bytes) Unsigned integer representing the
|
||||
size of this event. Used to extend
|
||||
kmemtrace. Discard the bytes you
|
||||
don't know about.
|
||||
Sequence number (4 bytes) Signed integer used to reorder data
|
||||
logged on SMP machines. Wraparound
|
||||
must be taken into account, although
|
||||
it is unlikely.
|
||||
Caller address (8 bytes) Return address to the caller.
|
||||
Pointer to mem (8 bytes) Pointer to target memory area. Can be
|
||||
NULL, but not all such calls might be
|
||||
recorded.
|
||||
|
||||
In case of KMEMTRACE_EVENT_ALLOC events, the next fields follow:
|
||||
|
||||
Requested bytes (8 bytes) Total number of requested bytes,
|
||||
unsigned, must not be zero.
|
||||
Allocated bytes (8 bytes) Total number of actually allocated
|
||||
bytes, unsigned, must not be lower
|
||||
than requested bytes.
|
||||
Requested flags (4 bytes) GFP flags supplied by the caller.
|
||||
Target CPU (4 bytes) Signed integer, valid for event id 1.
|
||||
If equal to -1, target CPU is the same
|
||||
as origin CPU, but the reverse might
|
||||
not be true.
|
||||
|
||||
The data is made available in the same endianness the machine has.
|
||||
|
||||
Other event ids and type ids may be defined and added. Other fields may be
|
||||
added by increasing event size, but see below for details.
|
||||
Every modification to the ABI, including new id definitions, are followed
|
||||
by bumping the ABI version by one.
|
||||
|
||||
Adding new data to the packet (features) is done at the end of the mandatory
|
||||
data:
|
||||
Feature size (2 byte)
|
||||
Feature ID (1 byte)
|
||||
Feature data (Feature size - 3 bytes)
|
||||
|
||||
|
||||
Users:
|
||||
kmemtrace-user - git://repo.or.cz/kmemtrace-user.git
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
What: /debug/pktcdvd/pktcdvd[0-7]
|
||||
What: /sys/kernel/debug/pktcdvd/pktcdvd[0-7]
|
||||
Date: Oct. 2006
|
||||
KernelVersion: 2.6.20
|
||||
Contact: Thomas Maier <balagi@justmail.de>
|
||||
@@ -10,10 +10,10 @@ debugfs interface
|
||||
The pktcdvd module (packet writing driver) creates
|
||||
these files in debugfs:
|
||||
|
||||
/debug/pktcdvd/pktcdvd[0-7]/
|
||||
/sys/kernel/debug/pktcdvd/pktcdvd[0-7]/
|
||||
info (0444) Lots of driver statistics and infos.
|
||||
|
||||
Example:
|
||||
-------
|
||||
|
||||
cat /debug/pktcdvd/pktcdvd0/info
|
||||
cat /sys/kernel/debug/pktcdvd/pktcdvd0/info
|
||||
|
||||
@@ -41,6 +41,49 @@ Description:
|
||||
for the device and attempt to bind to it. For example:
|
||||
# echo "8086 10f5" > /sys/bus/pci/drivers/foo/new_id
|
||||
|
||||
What: /sys/bus/pci/drivers/.../remove_id
|
||||
Date: February 2009
|
||||
Contact: Chris Wright <chrisw@sous-sol.org>
|
||||
Description:
|
||||
Writing a device ID to this file will remove an ID
|
||||
that was dynamically added via the new_id sysfs entry.
|
||||
The format for the device ID is:
|
||||
VVVV DDDD SVVV SDDD CCCC MMMM. That is Vendor ID, Device
|
||||
ID, Subsystem Vendor ID, Subsystem Device ID, Class,
|
||||
and Class Mask. The Vendor ID and Device ID fields are
|
||||
required, the rest are optional. After successfully
|
||||
removing an ID, the driver will no longer support the
|
||||
device. This is useful to ensure auto probing won't
|
||||
match the driver to the device. For example:
|
||||
# echo "8086 10f5" > /sys/bus/pci/drivers/foo/remove_id
|
||||
|
||||
What: /sys/bus/pci/rescan
|
||||
Date: January 2009
|
||||
Contact: Linux PCI developers <linux-pci@vger.kernel.org>
|
||||
Description:
|
||||
Writing a non-zero value to this attribute will
|
||||
force a rescan of all PCI buses in the system, and
|
||||
re-discover previously removed devices.
|
||||
Depends on CONFIG_HOTPLUG.
|
||||
|
||||
What: /sys/bus/pci/devices/.../remove
|
||||
Date: January 2009
|
||||
Contact: Linux PCI developers <linux-pci@vger.kernel.org>
|
||||
Description:
|
||||
Writing a non-zero value to this attribute will
|
||||
hot-remove the PCI device and any of its children.
|
||||
Depends on CONFIG_HOTPLUG.
|
||||
|
||||
What: /sys/bus/pci/devices/.../rescan
|
||||
Date: January 2009
|
||||
Contact: Linux PCI developers <linux-pci@vger.kernel.org>
|
||||
Description:
|
||||
Writing a non-zero value to this attribute will
|
||||
force a rescan of the device's parent bus and all
|
||||
child buses, and re-discover devices removed earlier
|
||||
from this part of the device tree.
|
||||
Depends on CONFIG_HOTPLUG.
|
||||
|
||||
What: /sys/bus/pci/devices/.../vpd
|
||||
Date: February 2008
|
||||
Contact: Ben Hutchings <bhutchings@solarflare.com>
|
||||
@@ -52,3 +95,30 @@ Description:
|
||||
that some devices may have malformatted data. If the
|
||||
underlying VPD has a writable section then the
|
||||
corresponding section of this file will be writable.
|
||||
|
||||
What: /sys/bus/pci/devices/.../virtfnN
|
||||
Date: March 2009
|
||||
Contact: Yu Zhao <yu.zhao@intel.com>
|
||||
Description:
|
||||
This symbolic link appears when hardware supports the SR-IOV
|
||||
capability and the Physical Function driver has enabled it.
|
||||
The symbolic link points to the PCI device sysfs entry of the
|
||||
Virtual Function whose index is N (0...MaxVFs-1).
|
||||
|
||||
What: /sys/bus/pci/devices/.../dep_link
|
||||
Date: March 2009
|
||||
Contact: Yu Zhao <yu.zhao@intel.com>
|
||||
Description:
|
||||
This symbolic link appears when hardware supports the SR-IOV
|
||||
capability and the Physical Function driver has enabled it,
|
||||
and this device has vendor specific dependencies with others.
|
||||
The symbolic link points to the PCI device sysfs entry of
|
||||
Physical Function this device depends on.
|
||||
|
||||
What: /sys/bus/pci/devices/.../physfn
|
||||
Date: March 2009
|
||||
Contact: Yu Zhao <yu.zhao@intel.com>
|
||||
Description:
|
||||
This symbolic link appears when a device is a Virtual Function.
|
||||
The symbolic link points to the PCI device sysfs entry of the
|
||||
Physical Function this device associates with.
|
||||
|
||||
@@ -4,8 +4,8 @@ KernelVersion: 2.6.26
|
||||
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
||||
Description:
|
||||
Some regulator directories will contain a field called
|
||||
state. This reports the regulator enable status, for
|
||||
regulators which can report that value.
|
||||
state. This reports the regulator enable control, for
|
||||
regulators which can report that input value.
|
||||
|
||||
This will be one of the following strings:
|
||||
|
||||
@@ -14,16 +14,54 @@ Description:
|
||||
'unknown'
|
||||
|
||||
'enabled' means the regulator output is ON and is supplying
|
||||
power to the system.
|
||||
power to the system (assuming no error prevents it).
|
||||
|
||||
'disabled' means the regulator output is OFF and is not
|
||||
supplying power to the system..
|
||||
supplying power to the system (unless some non-Linux
|
||||
control has enabled it).
|
||||
|
||||
'unknown' means software cannot determine the state, or
|
||||
the reported state is invalid.
|
||||
|
||||
NOTE: this field can be used in conjunction with microvolts
|
||||
and microamps to determine regulator output levels.
|
||||
or microamps to determine configured regulator output levels.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../status
|
||||
Description:
|
||||
Some regulator directories will contain a field called
|
||||
"status". This reports the current regulator status, for
|
||||
regulators which can report that output value.
|
||||
|
||||
This will be one of the following strings:
|
||||
|
||||
off
|
||||
on
|
||||
error
|
||||
fast
|
||||
normal
|
||||
idle
|
||||
standby
|
||||
|
||||
"off" means the regulator is not supplying power to the
|
||||
system.
|
||||
|
||||
"on" means the regulator is supplying power to the system,
|
||||
and the regulator can't report a detailed operation mode.
|
||||
|
||||
"error" indicates an out-of-regulation status such as being
|
||||
disabled due to thermal shutdown, or voltage being unstable
|
||||
because of problems with the input power supply.
|
||||
|
||||
"fast", "normal", "idle", and "standby" are all detailed
|
||||
regulator operation modes (described elsewhere). They
|
||||
imply "on", but provide more detail.
|
||||
|
||||
Note that regulator status is a function of many inputs,
|
||||
not limited to control inputs from Linux. For example,
|
||||
the actual load presented may trigger "error" status; or
|
||||
a regulator may be enabled by another user, even though
|
||||
Linux did not enable it.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../type
|
||||
@@ -58,7 +96,7 @@ Description:
|
||||
Some regulator directories will contain a field called
|
||||
microvolts. This holds the regulator output voltage setting
|
||||
measured in microvolts (i.e. E-6 Volts), for regulators
|
||||
which can report that voltage.
|
||||
which can report the control input for voltage.
|
||||
|
||||
NOTE: This value should not be used to determine the regulator
|
||||
output voltage level as this value is the same regardless of
|
||||
@@ -73,7 +111,7 @@ Description:
|
||||
Some regulator directories will contain a field called
|
||||
microamps. This holds the regulator output current limit
|
||||
setting measured in microamps (i.e. E-6 Amps), for regulators
|
||||
which can report that current.
|
||||
which can report the control input for a current limit.
|
||||
|
||||
NOTE: This value should not be used to determine the regulator
|
||||
output current level as this value is the same regardless of
|
||||
@@ -87,7 +125,7 @@ Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
||||
Description:
|
||||
Some regulator directories will contain a field called
|
||||
opmode. This holds the current regulator operating mode,
|
||||
for regulators which can report it.
|
||||
for regulators which can report that control input value.
|
||||
|
||||
The opmode value can be one of the following strings:
|
||||
|
||||
@@ -101,7 +139,8 @@ Description:
|
||||
|
||||
NOTE: This value should not be used to determine the regulator
|
||||
output operating mode as this value is the same regardless of
|
||||
whether the regulator is enabled or disabled.
|
||||
whether the regulator is enabled or disabled. A "status"
|
||||
attribute may be available to determine the actual mode.
|
||||
|
||||
|
||||
What: /sys/class/regulator/.../min_microvolts
|
||||
|
||||
@@ -69,9 +69,13 @@ Description:
|
||||
gpe1F: 0 invalid
|
||||
gpe_all: 1192
|
||||
sci: 1194
|
||||
sci_not: 0
|
||||
|
||||
sci - The total number of times the ACPI SCI
|
||||
has claimed an interrupt.
|
||||
sci - The number of times the ACPI SCI
|
||||
has been called and claimed an interrupt.
|
||||
|
||||
sci_not - The number of times the ACPI SCI
|
||||
has been called and NOT claimed an interrupt.
|
||||
|
||||
gpe_all - count of SCI caused by GPEs.
|
||||
|
||||
|
||||
@@ -0,0 +1,81 @@
|
||||
What: /sys/fs/ext4/<disk>/mb_stats
|
||||
Date: March 2008
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
Controls whether the multiblock allocator should
|
||||
collect statistics, which are shown during the unmount.
|
||||
1 means to collect statistics, 0 means not to collect
|
||||
statistics
|
||||
|
||||
What: /sys/fs/ext4/<disk>/mb_group_prealloc
|
||||
Date: March 2008
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
The multiblock allocator will round up allocation
|
||||
requests to a multiple of this tuning parameter if the
|
||||
stripe size is not set in the ext4 superblock
|
||||
|
||||
What: /sys/fs/ext4/<disk>/mb_max_to_scan
|
||||
Date: March 2008
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
The maximum number of extents the multiblock allocator
|
||||
will search to find the best extent
|
||||
|
||||
What: /sys/fs/ext4/<disk>/mb_min_to_scan
|
||||
Date: March 2008
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
The minimum number of extents the multiblock allocator
|
||||
will search to find the best extent
|
||||
|
||||
What: /sys/fs/ext4/<disk>/mb_order2_req
|
||||
Date: March 2008
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
Tuning parameter which controls the minimum size for
|
||||
requests (as a power of 2) where the buddy cache is
|
||||
used
|
||||
|
||||
What: /sys/fs/ext4/<disk>/mb_stream_req
|
||||
Date: March 2008
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
Files which have fewer blocks than this tunable
|
||||
parameter will have their blocks allocated out of a
|
||||
block group specific preallocation pool, so that small
|
||||
files are packed closely together. Each large file
|
||||
will have its blocks allocated out of its own unique
|
||||
preallocation pool.
|
||||
|
||||
What: /sys/fs/ext4/<disk>/inode_readahead
|
||||
Date: March 2008
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
Tuning parameter which controls the maximum number of
|
||||
inode table blocks that ext4's inode table readahead
|
||||
algorithm will pre-read into the buffer cache
|
||||
|
||||
What: /sys/fs/ext4/<disk>/delayed_allocation_blocks
|
||||
Date: March 2008
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
This file is read-only and shows the number of blocks
|
||||
that are dirty in the page cache, but which do not
|
||||
have their location in the filesystem allocated yet.
|
||||
|
||||
What: /sys/fs/ext4/<disk>/lifetime_write_kbytes
|
||||
Date: March 2008
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
This file is read-only and shows the number of kilobytes
|
||||
of data that have been written to this filesystem since it was
|
||||
created.
|
||||
|
||||
What: /sys/fs/ext4/<disk>/session_write_kbytes
|
||||
Date: March 2008
|
||||
Contact: "Theodore Ts'o" <tytso@mit.edu>
|
||||
Description:
|
||||
This file is read-only and shows the number of
|
||||
kilobytes of data that have been written to this
|
||||
filesystem since it was mounted.
|
||||
@@ -609,3 +609,109 @@ size is the size (and should be a page-sized multiple).
|
||||
The return value will be either a pointer to the processor virtual
|
||||
address of the memory, or an error (via PTR_ERR()) if any part of the
|
||||
region is occupied.
|
||||
|
||||
Part III - Debug drivers use of the DMA-API
|
||||
-------------------------------------------
|
||||
|
||||
The DMA-API as described above as some constraints. DMA addresses must be
|
||||
released with the corresponding function with the same size for example. With
|
||||
the advent of hardware IOMMUs it becomes more and more important that drivers
|
||||
do not violate those constraints. In the worst case such a violation can
|
||||
result in data corruption up to destroyed filesystems.
|
||||
|
||||
To debug drivers and find bugs in the usage of the DMA-API checking code can
|
||||
be compiled into the kernel which will tell the developer about those
|
||||
violations. If your architecture supports it you can select the "Enable
|
||||
debugging of DMA-API usage" option in your kernel configuration. Enabling this
|
||||
option has a performance impact. Do not enable it in production kernels.
|
||||
|
||||
If you boot the resulting kernel will contain code which does some bookkeeping
|
||||
about what DMA memory was allocated for which device. If this code detects an
|
||||
error it prints a warning message with some details into your kernel log. An
|
||||
example warning message may look like this:
|
||||
|
||||
------------[ cut here ]------------
|
||||
WARNING: at /data2/repos/linux-2.6-iommu/lib/dma-debug.c:448
|
||||
check_unmap+0x203/0x490()
|
||||
Hardware name:
|
||||
forcedeth 0000:00:08.0: DMA-API: device driver frees DMA memory with wrong
|
||||
function [device address=0x00000000640444be] [size=66 bytes] [mapped as
|
||||
single] [unmapped as page]
|
||||
Modules linked in: nfsd exportfs bridge stp llc r8169
|
||||
Pid: 0, comm: swapper Tainted: G W 2.6.28-dmatest-09289-g8bb99c0 #1
|
||||
Call Trace:
|
||||
<IRQ> [<ffffffff80240b22>] warn_slowpath+0xf2/0x130
|
||||
[<ffffffff80647b70>] _spin_unlock+0x10/0x30
|
||||
[<ffffffff80537e75>] usb_hcd_link_urb_to_ep+0x75/0xc0
|
||||
[<ffffffff80647c22>] _spin_unlock_irqrestore+0x12/0x40
|
||||
[<ffffffff8055347f>] ohci_urb_enqueue+0x19f/0x7c0
|
||||
[<ffffffff80252f96>] queue_work+0x56/0x60
|
||||
[<ffffffff80237e10>] enqueue_task_fair+0x20/0x50
|
||||
[<ffffffff80539279>] usb_hcd_submit_urb+0x379/0xbc0
|
||||
[<ffffffff803b78c3>] cpumask_next_and+0x23/0x40
|
||||
[<ffffffff80235177>] find_busiest_group+0x207/0x8a0
|
||||
[<ffffffff8064784f>] _spin_lock_irqsave+0x1f/0x50
|
||||
[<ffffffff803c7ea3>] check_unmap+0x203/0x490
|
||||
[<ffffffff803c8259>] debug_dma_unmap_page+0x49/0x50
|
||||
[<ffffffff80485f26>] nv_tx_done_optimized+0xc6/0x2c0
|
||||
[<ffffffff80486c13>] nv_nic_irq_optimized+0x73/0x2b0
|
||||
[<ffffffff8026df84>] handle_IRQ_event+0x34/0x70
|
||||
[<ffffffff8026ffe9>] handle_edge_irq+0xc9/0x150
|
||||
[<ffffffff8020e3ab>] do_IRQ+0xcb/0x1c0
|
||||
[<ffffffff8020c093>] ret_from_intr+0x0/0xa
|
||||
<EOI> <4>---[ end trace f6435a98e2a38c0e ]---
|
||||
|
||||
The driver developer can find the driver and the device including a stacktrace
|
||||
of the DMA-API call which caused this warning.
|
||||
|
||||
Per default only the first error will result in a warning message. All other
|
||||
errors will only silently counted. This limitation exist to prevent the code
|
||||
from flooding your kernel log. To support debugging a device driver this can
|
||||
be disabled via debugfs. See the debugfs interface documentation below for
|
||||
details.
|
||||
|
||||
The debugfs directory for the DMA-API debugging code is called dma-api/. In
|
||||
this directory the following files can currently be found:
|
||||
|
||||
dma-api/all_errors This file contains a numeric value. If this
|
||||
value is not equal to zero the debugging code
|
||||
will print a warning for every error it finds
|
||||
into the kernel log. Be carefull with this
|
||||
option. It can easily flood your logs.
|
||||
|
||||
dma-api/disabled This read-only file contains the character 'Y'
|
||||
if the debugging code is disabled. This can
|
||||
happen when it runs out of memory or if it was
|
||||
disabled at boot time
|
||||
|
||||
dma-api/error_count This file is read-only and shows the total
|
||||
numbers of errors found.
|
||||
|
||||
dma-api/num_errors The number in this file shows how many
|
||||
warnings will be printed to the kernel log
|
||||
before it stops. This number is initialized to
|
||||
one at system boot and be set by writing into
|
||||
this file
|
||||
|
||||
dma-api/min_free_entries
|
||||
This read-only file can be read to get the
|
||||
minimum number of free dma_debug_entries the
|
||||
allocator has ever seen. If this value goes
|
||||
down to zero the code will disable itself
|
||||
because it is not longer reliable.
|
||||
|
||||
dma-api/num_free_entries
|
||||
The current number of free dma_debug_entries
|
||||
in the allocator.
|
||||
|
||||
If you have this code compiled into your kernel it will be enabled by default.
|
||||
If you want to boot without the bookkeeping anyway you can provide
|
||||
'dma_debug=off' as a boot parameter. This will disable DMA-API debugging.
|
||||
Notice that you can not enable it again at runtime. You have to reboot to do
|
||||
so.
|
||||
|
||||
When the code disables itself at runtime this is most likely because it ran
|
||||
out of dma_debug_entries. These entries are preallocated at boot. The number
|
||||
of preallocated entries is defined per architecture. If it is too low for you
|
||||
boot with 'dma_debug_entries=<your_desired_number>' to overwrite the
|
||||
architectural default.
|
||||
|
||||
@@ -136,7 +136,7 @@ exactly why.
|
||||
The standard 32-bit addressing PCI device would do something like
|
||||
this:
|
||||
|
||||
if (pci_set_dma_mask(pdev, DMA_32BIT_MASK)) {
|
||||
if (pci_set_dma_mask(pdev, DMA_BIT_MASK(32))) {
|
||||
printk(KERN_WARNING
|
||||
"mydev: No suitable DMA available.\n");
|
||||
goto ignore_this_device;
|
||||
@@ -155,9 +155,9 @@ all 64-bits when accessing streaming DMA:
|
||||
|
||||
int using_dac;
|
||||
|
||||
if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) {
|
||||
if (!pci_set_dma_mask(pdev, DMA_BIT_MASK(64))) {
|
||||
using_dac = 1;
|
||||
} else if (!pci_set_dma_mask(pdev, DMA_32BIT_MASK)) {
|
||||
} else if (!pci_set_dma_mask(pdev, DMA_BIT_MASK(32))) {
|
||||
using_dac = 0;
|
||||
} else {
|
||||
printk(KERN_WARNING
|
||||
@@ -170,14 +170,14 @@ the case would look like this:
|
||||
|
||||
int using_dac, consistent_using_dac;
|
||||
|
||||
if (!pci_set_dma_mask(pdev, DMA_64BIT_MASK)) {
|
||||
if (!pci_set_dma_mask(pdev, DMA_BIT_MASK(64))) {
|
||||
using_dac = 1;
|
||||
consistent_using_dac = 1;
|
||||
pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
|
||||
} else if (!pci_set_dma_mask(pdev, DMA_32BIT_MASK)) {
|
||||
pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(64));
|
||||
} else if (!pci_set_dma_mask(pdev, DMA_BIT_MASK(32))) {
|
||||
using_dac = 0;
|
||||
consistent_using_dac = 0;
|
||||
pci_set_consistent_dma_mask(pdev, DMA_32BIT_MASK);
|
||||
pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(32));
|
||||
} else {
|
||||
printk(KERN_WARNING
|
||||
"mydev: No suitable DMA available.\n");
|
||||
@@ -192,7 +192,7 @@ check the return value from pci_set_consistent_dma_mask().
|
||||
Finally, if your device can only drive the low 24-bits of
|
||||
address during PCI bus mastering you might do something like:
|
||||
|
||||
if (pci_set_dma_mask(pdev, DMA_24BIT_MASK)) {
|
||||
if (pci_set_dma_mask(pdev, DMA_BIT_MASK(24))) {
|
||||
printk(KERN_WARNING
|
||||
"mydev: 24-bit DMA addressing not available.\n");
|
||||
goto ignore_this_device;
|
||||
@@ -213,7 +213,7 @@ most specific mask.
|
||||
|
||||
Here is pseudo-code showing how this might be done:
|
||||
|
||||
#define PLAYBACK_ADDRESS_BITS DMA_32BIT_MASK
|
||||
#define PLAYBACK_ADDRESS_BITS DMA_BIT_MASK(32)
|
||||
#define RECORD_ADDRESS_BITS 0x00ffffff
|
||||
|
||||
struct my_sound_card *card;
|
||||
|
||||
@@ -4,3 +4,7 @@
|
||||
*.html
|
||||
*.9.gz
|
||||
*.9
|
||||
*.aux
|
||||
*.dvi
|
||||
*.log
|
||||
*.out
|
||||
|
||||
@@ -31,7 +31,7 @@ PS_METHOD = $(prefer-db2x)
|
||||
|
||||
###
|
||||
# The targets that may be used.
|
||||
PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs
|
||||
PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs
|
||||
|
||||
BOOKS := $(addprefix $(obj)/,$(DOCBOOKS))
|
||||
xmldocs: $(BOOKS)
|
||||
@@ -143,7 +143,8 @@ quiet_cmd_db2pdf = PDF $@
|
||||
$(call cmd,db2pdf)
|
||||
|
||||
|
||||
main_idx = Documentation/DocBook/index.html
|
||||
index = index.html
|
||||
main_idx = Documentation/DocBook/$(index)
|
||||
build_main_index = rm -rf $(main_idx) && \
|
||||
echo '<h1>Linux Kernel HTML Documentation</h1>' >> $(main_idx) && \
|
||||
echo '<h2>Kernel Version: $(KERNELVERSION)</h2>' >> $(main_idx) && \
|
||||
@@ -213,11 +214,12 @@ silent_gen_xml = :
|
||||
dochelp:
|
||||
@echo ' Linux kernel internal documentation in different formats:'
|
||||
@echo ' htmldocs - HTML'
|
||||
@echo ' installmandocs - install man pages generated by mandocs'
|
||||
@echo ' mandocs - man pages'
|
||||
@echo ' pdfdocs - PDF'
|
||||
@echo ' psdocs - Postscript'
|
||||
@echo ' xmldocs - XML DocBook'
|
||||
@echo ' mandocs - man pages'
|
||||
@echo ' installmandocs - install man pages generated by mandocs'
|
||||
@echo ' cleandocs - clean all generated DocBook files'
|
||||
|
||||
###
|
||||
# Temporary files left by various tools
|
||||
@@ -231,10 +233,14 @@ clean-files := $(DOCBOOKS) \
|
||||
$(patsubst %.xml, %.pdf, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.html, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.9, $(DOCBOOKS)) \
|
||||
$(C-procfs-example)
|
||||
$(C-procfs-example) $(index)
|
||||
|
||||
clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man
|
||||
|
||||
cleandocs:
|
||||
$(Q)rm -f $(call objectify, $(clean-files))
|
||||
$(Q)rm -rf $(call objectify, $(clean-dirs))
|
||||
|
||||
# Declare the contents of the .PHONY variable as phony. We keep that
|
||||
# information in a variable se we can use it in if_changed and friends.
|
||||
|
||||
|
||||
@@ -190,15 +190,20 @@ X!Ekernel/module.c
|
||||
!Edrivers/pci/pci.c
|
||||
!Edrivers/pci/pci-driver.c
|
||||
!Edrivers/pci/remove.c
|
||||
!Edrivers/pci/pci-acpi.c
|
||||
!Edrivers/pci/search.c
|
||||
!Edrivers/pci/msi.c
|
||||
!Edrivers/pci/bus.c
|
||||
!Edrivers/pci/access.c
|
||||
!Edrivers/pci/irq.c
|
||||
!Edrivers/pci/htirq.c
|
||||
<!-- FIXME: Removed for now since no structured comments in source
|
||||
X!Edrivers/pci/hotplug.c
|
||||
-->
|
||||
!Edrivers/pci/probe.c
|
||||
!Edrivers/pci/slot.c
|
||||
!Edrivers/pci/rom.c
|
||||
!Edrivers/pci/iov.c
|
||||
!Idrivers/pci/pci-sysfs.c
|
||||
</sect1>
|
||||
<sect1><title>PCI Hotplug Support Library</title>
|
||||
!Edrivers/pci/hotplug/pci_hotplug_core.c
|
||||
@@ -258,7 +263,7 @@ X!Earch/x86/kernel/mca_32.c
|
||||
!Eblock/blk-tag.c
|
||||
!Iblock/blk-tag.c
|
||||
!Eblock/blk-integrity.c
|
||||
!Iblock/blktrace.c
|
||||
!Ikernel/trace/blktrace.c
|
||||
!Iblock/genhd.c
|
||||
!Eblock/genhd.c
|
||||
</chapter>
|
||||
|
||||
@@ -117,9 +117,6 @@ static int __init init_procfs_example(void)
|
||||
rv = -ENOMEM;
|
||||
goto out;
|
||||
}
|
||||
|
||||
example_dir->owner = THIS_MODULE;
|
||||
|
||||
/* create jiffies using convenience function */
|
||||
jiffies_file = create_proc_read_entry("jiffies",
|
||||
0444, example_dir,
|
||||
@@ -130,8 +127,6 @@ static int __init init_procfs_example(void)
|
||||
goto no_jiffies;
|
||||
}
|
||||
|
||||
jiffies_file->owner = THIS_MODULE;
|
||||
|
||||
/* create foo and bar files using same callback
|
||||
* functions
|
||||
*/
|
||||
@@ -146,7 +141,6 @@ static int __init init_procfs_example(void)
|
||||
foo_file->data = &foo_data;
|
||||
foo_file->read_proc = proc_read_foobar;
|
||||
foo_file->write_proc = proc_write_foobar;
|
||||
foo_file->owner = THIS_MODULE;
|
||||
|
||||
bar_file = create_proc_entry("bar", 0644, example_dir);
|
||||
if(bar_file == NULL) {
|
||||
@@ -159,7 +153,6 @@ static int __init init_procfs_example(void)
|
||||
bar_file->data = &bar_data;
|
||||
bar_file->read_proc = proc_read_foobar;
|
||||
bar_file->write_proc = proc_write_foobar;
|
||||
bar_file->owner = THIS_MODULE;
|
||||
|
||||
/* create symlink */
|
||||
symlink = proc_symlink("jiffies_too", example_dir,
|
||||
@@ -169,8 +162,6 @@ static int __init init_procfs_example(void)
|
||||
goto no_symlink;
|
||||
}
|
||||
|
||||
symlink->owner = THIS_MODULE;
|
||||
|
||||
/* everything OK */
|
||||
printk(KERN_INFO "%s %s initialised\n",
|
||||
MODULE_NAME, MODULE_VERS);
|
||||
|
||||
@@ -1137,8 +1137,8 @@
|
||||
if (err < 0)
|
||||
return err;
|
||||
/* check PCI availability (28bit DMA) */
|
||||
if (pci_set_dma_mask(pci, DMA_28BIT_MASK) < 0 ||
|
||||
pci_set_consistent_dma_mask(pci, DMA_28BIT_MASK) < 0) {
|
||||
if (pci_set_dma_mask(pci, DMA_BIT_MASK(28)) < 0 ||
|
||||
pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(28)) < 0) {
|
||||
printk(KERN_ERR "error to set 28bit mask DMA\n");
|
||||
pci_disable_device(pci);
|
||||
return -ENXIO;
|
||||
@@ -1252,8 +1252,8 @@
|
||||
err = pci_enable_device(pci);
|
||||
if (err < 0)
|
||||
return err;
|
||||
if (pci_set_dma_mask(pci, DMA_28BIT_MASK) < 0 ||
|
||||
pci_set_consistent_dma_mask(pci, DMA_28BIT_MASK) < 0) {
|
||||
if (pci_set_dma_mask(pci, DMA_BIT_MASK(28)) < 0 ||
|
||||
pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(28)) < 0) {
|
||||
printk(KERN_ERR "error to set 28bit mask DMA\n");
|
||||
pci_disable_device(pci);
|
||||
return -ENXIO;
|
||||
|
||||
+276
-426
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,99 @@
|
||||
PCI Express I/O Virtualization Howto
|
||||
Copyright (C) 2009 Intel Corporation
|
||||
Yu Zhao <yu.zhao@intel.com>
|
||||
|
||||
|
||||
1. Overview
|
||||
|
||||
1.1 What is SR-IOV
|
||||
|
||||
Single Root I/O Virtualization (SR-IOV) is a PCI Express Extended
|
||||
capability which makes one physical device appear as multiple virtual
|
||||
devices. The physical device is referred to as Physical Function (PF)
|
||||
while the virtual devices are referred to as Virtual Functions (VF).
|
||||
Allocation of the VF can be dynamically controlled by the PF via
|
||||
registers encapsulated in the capability. By default, this feature is
|
||||
not enabled and the PF behaves as traditional PCIe device. Once it's
|
||||
turned on, each VF's PCI configuration space can be accessed by its own
|
||||
Bus, Device and Function Number (Routing ID). And each VF also has PCI
|
||||
Memory Space, which is used to map its register set. VF device driver
|
||||
operates on the register set so it can be functional and appear as a
|
||||
real existing PCI device.
|
||||
|
||||
2. User Guide
|
||||
|
||||
2.1 How can I enable SR-IOV capability
|
||||
|
||||
The device driver (PF driver) will control the enabling and disabling
|
||||
of the capability via API provided by SR-IOV core. If the hardware
|
||||
has SR-IOV capability, loading its PF driver would enable it and all
|
||||
VFs associated with the PF.
|
||||
|
||||
2.2 How can I use the Virtual Functions
|
||||
|
||||
The VF is treated as hot-plugged PCI devices in the kernel, so they
|
||||
should be able to work in the same way as real PCI devices. The VF
|
||||
requires device driver that is same as a normal PCI device's.
|
||||
|
||||
3. Developer Guide
|
||||
|
||||
3.1 SR-IOV API
|
||||
|
||||
To enable SR-IOV capability:
|
||||
int pci_enable_sriov(struct pci_dev *dev, int nr_virtfn);
|
||||
'nr_virtfn' is number of VFs to be enabled.
|
||||
|
||||
To disable SR-IOV capability:
|
||||
void pci_disable_sriov(struct pci_dev *dev);
|
||||
|
||||
To notify SR-IOV core of Virtual Function Migration:
|
||||
irqreturn_t pci_sriov_migration(struct pci_dev *dev);
|
||||
|
||||
3.2 Usage example
|
||||
|
||||
Following piece of code illustrates the usage of the SR-IOV API.
|
||||
|
||||
static int __devinit dev_probe(struct pci_dev *dev, const struct pci_device_id *id)
|
||||
{
|
||||
pci_enable_sriov(dev, NR_VIRTFN);
|
||||
|
||||
...
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
static void __devexit dev_remove(struct pci_dev *dev)
|
||||
{
|
||||
pci_disable_sriov(dev);
|
||||
|
||||
...
|
||||
}
|
||||
|
||||
static int dev_suspend(struct pci_dev *dev, pm_message_t state)
|
||||
{
|
||||
...
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
static int dev_resume(struct pci_dev *dev)
|
||||
{
|
||||
...
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
static void dev_shutdown(struct pci_dev *dev)
|
||||
{
|
||||
...
|
||||
}
|
||||
|
||||
static struct pci_driver dev_driver = {
|
||||
.name = "SR-IOV Physical Function driver",
|
||||
.id_table = dev_id_table,
|
||||
.probe = dev_probe,
|
||||
.remove = __devexit_p(dev_remove),
|
||||
.suspend = dev_suspend,
|
||||
.resume = dev_resume,
|
||||
.shutdown = dev_shutdown,
|
||||
};
|
||||
@@ -118,7 +118,7 @@ Following are the RCU equivalents for these two functions:
|
||||
list_for_each_entry(e, list, list) {
|
||||
if (!audit_compare_rule(rule, &e->rule)) {
|
||||
list_del_rcu(&e->list);
|
||||
call_rcu(&e->rcu, audit_free_rule, e);
|
||||
call_rcu(&e->rcu, audit_free_rule);
|
||||
return 0;
|
||||
}
|
||||
}
|
||||
@@ -206,7 +206,7 @@ RCU ("read-copy update") its name. The RCU code is as follows:
|
||||
ne->rule.action = newaction;
|
||||
ne->rule.file_count = newfield_count;
|
||||
list_replace_rcu(e, ne);
|
||||
call_rcu(&e->rcu, audit_free_rule, e);
|
||||
call_rcu(&e->rcu, audit_free_rule);
|
||||
return 0;
|
||||
}
|
||||
}
|
||||
@@ -283,7 +283,7 @@ flag under the spinlock as follows:
|
||||
list_del_rcu(&e->list);
|
||||
e->deleted = 1;
|
||||
spin_unlock(&e->lock);
|
||||
call_rcu(&e->rcu, audit_free_rule, e);
|
||||
call_rcu(&e->rcu, audit_free_rule);
|
||||
return 0;
|
||||
}
|
||||
}
|
||||
|
||||
@@ -81,7 +81,7 @@ o I hear that RCU needs work in order to support realtime kernels?
|
||||
This work is largely completed. Realtime-friendly RCU can be
|
||||
enabled via the CONFIG_PREEMPT_RCU kernel configuration parameter.
|
||||
However, work is in progress for enabling priority boosting of
|
||||
preempted RCU read-side critical sections.This is needed if you
|
||||
preempted RCU read-side critical sections. This is needed if you
|
||||
have CPU-bound realtime threads.
|
||||
|
||||
o Where can I find more information on RCU?
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user