Commit 087021ba authored by Ingo Molnar's avatar Ingo Molnar
Browse files

Merge branch 'linus' into perfcounters/urgent 



Merge reason: this branch was on a .30-ish base before, update
              it to an almost-.31-rc2 upstream base to pick up fixes.

Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
parents fb9c8188 e83c2b0f

Documentation/ABI/testing/sysfs-bus-pci

+7 −0
Original line number Diff line number Diff line
@@ -122,3 +122,10 @@ 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.



What:		/sys/bus/pci/slots/.../module

Date:		June 2009

Contact:	linux-pci@vger.kernel.org

Description:

		This symbolic link points to the PCI hotplug controller driver

		module that manages the hotplug slot.

Documentation/ABI/testing/sysfs-class-mtd

0 → 100644
+125 −0
Original line number Diff line number Diff line 
What:		/sys/class/mtd/

Date:		April 2009

KernelVersion:	2.6.29

Contact:	linux-mtd@lists.infradead.org

Description:

		The mtd/ class subdirectory belongs to the MTD subsystem

		(MTD core).



What:		/sys/class/mtd/mtdX/

Date:		April 2009

KernelVersion:	2.6.29

Contact:	linux-mtd@lists.infradead.org

Description:

		The /sys/class/mtd/mtd{0,1,2,3,...} directories correspond

		to each /dev/mtdX character device.  These may represent

		physical/simulated flash devices, partitions on a flash

		device, or concatenated flash devices.  They exist regardless

		of whether CONFIG_MTD_CHAR is actually enabled.



What:		/sys/class/mtd/mtdXro/

Date:		April 2009

KernelVersion:	2.6.29

Contact:	linux-mtd@lists.infradead.org

Description:

		These directories provide the corresponding read-only device

		nodes for /sys/class/mtd/mtdX/ .  They are only created

		(for the benefit of udev) if CONFIG_MTD_CHAR is enabled.



What:		/sys/class/mtd/mtdX/dev

Date:		April 2009

KernelVersion:	2.6.29

Contact:	linux-mtd@lists.infradead.org

Description:

		Major and minor numbers of the character device corresponding

		to this MTD device (in <major>:<minor> format).  This is the

		read-write device so <minor> will be even.



What:		/sys/class/mtd/mtdXro/dev

Date:		April 2009

KernelVersion:	2.6.29

Contact:	linux-mtd@lists.infradead.org

Description:

		Major and minor numbers of the character device corresponding

		to the read-only variant of thie MTD device (in

		<major>:<minor> format).  In this case <minor> will be odd.



What:		/sys/class/mtd/mtdX/erasesize

Date:		April 2009

KernelVersion:	2.6.29

Contact:	linux-mtd@lists.infradead.org

Description:

		"Major" erase size for the device.  If numeraseregions is

		zero, this is the eraseblock size for the entire device.

		Otherwise, the MEMGETREGIONCOUNT/MEMGETREGIONINFO ioctls

		can be used to determine the actual eraseblock layout.



What:		/sys/class/mtd/mtdX/flags

Date:		April 2009

KernelVersion:	2.6.29

Contact:	linux-mtd@lists.infradead.org

Description:

		A hexadecimal value representing the device flags, ORed

		together:



		0x0400: MTD_WRITEABLE - device is writable

		0x0800: MTD_BIT_WRITEABLE - single bits can be flipped

		0x1000: MTD_NO_ERASE - no erase necessary

		0x2000: MTD_POWERUP_LOCK - always locked after reset



What:		/sys/class/mtd/mtdX/name

Date:		April 2009

KernelVersion:	2.6.29

Contact:	linux-mtd@lists.infradead.org

Description:

		A human-readable ASCII name for the device or partition.

		This will match the name in /proc/mtd .



What:		/sys/class/mtd/mtdX/numeraseregions

Date:		April 2009

KernelVersion:	2.6.29

Contact:	linux-mtd@lists.infradead.org

Description:

		For devices that have variable eraseblock sizes, this

		provides the total number of erase regions.  Otherwise,

		it will read back as zero.



What:		/sys/class/mtd/mtdX/oobsize

Date:		April 2009

KernelVersion:	2.6.29

Contact:	linux-mtd@lists.infradead.org

Description:

		Number of OOB bytes per page.



What:		/sys/class/mtd/mtdX/size

Date:		April 2009

KernelVersion:	2.6.29

Contact:	linux-mtd@lists.infradead.org

Description:

		Total size of the device/partition, in bytes.



What:		/sys/class/mtd/mtdX/type

Date:		April 2009

KernelVersion:	2.6.29

Contact:	linux-mtd@lists.infradead.org

Description:

		One of the following ASCII strings, representing the device

		type:



		absent, ram, rom, nor, nand, dataflash, ubi, unknown



What:		/sys/class/mtd/mtdX/writesize

Date:		April 2009

KernelVersion:	2.6.29

Contact:	linux-mtd@lists.infradead.org

Description:

		Minimal writable flash unit size.  This will always be

		a positive integer.



		In the case of NOR flash it is 1 (even though individual

		bits can be cleared).



		In the case of NAND flash it is one NAND page (or a

		half page, or a quarter page).



		In the case of ECC NOR, it is the ECC block size.

Documentation/PCI/pcieaer-howto.txt

+25 −0
Original line number Diff line number Diff line
@@ -61,6 +61,10 @@ be initiated although firmwares have no _OSC support. To enable the 
walkaround, pls. add aerdriver.forceload=y to kernel boot parameter line

when booting kernel. Note that forceload=n by default.



nosourceid, another parameter of type bool, can be used when broken

hardware (mostly chipsets) has root ports that cannot obtain the reporting

source ID. nosourceid=n by default.



2.3 AER error output

When a PCI-E AER error is captured, an error message will be outputed to

console. If it's a correctable error, it is outputed as a warning.
@@ -246,3 +250,24 @@ with the PCI Express AER Root driver? 
A: It could call the helper functions to enable AER in devices and

cleanup uncorrectable status register. Pls. refer to section 3.3.





4. Software error injection



Debugging PCIE AER error recovery code is quite difficult because it

is hard to trigger real hardware errors. Software based error

injection can be used to fake various kinds of PCIE errors.



First you should enable PCIE AER software error injection in kernel

configuration, that is, following item should be in your .config.



CONFIG_PCIEAER_INJECT=y or CONFIG_PCIEAER_INJECT=m



After reboot with new kernel or insert the module, a device file named

/dev/aer_inject should be created.



Then, you need a user space tool named aer-inject, which can be gotten

from:

    http://www.kernel.org/pub/linux/utils/pci/aer-inject/



More information about aer-inject can be found in the document comes

with its source code.

Documentation/cgroups/cpusets.txt

+12 −0
Original line number Diff line number Diff line
@@ -777,6 +777,18 @@ in cpuset directories: 
# /bin/echo 1-4 > cpus		-> set cpus list to cpus 1,2,3,4

# /bin/echo 1,2,3,4 > cpus	-> set cpus list to cpus 1,2,3,4



To add a CPU to a cpuset, write the new list of CPUs including the

CPU to be added. To add 6 to the above cpuset:



# /bin/echo 1-4,6 > cpus	-> set cpus list to cpus 1,2,3,4,6



Similarly to remove a CPU from a cpuset, write the new list of CPUs

without the CPU to be removed.



To remove all the CPUs:



# /bin/echo "" > cpus		-> clear cpus list



2.3 Setting flags

-----------------

Documentation/device-mapper/dm-log.txt

0 → 100644
+54 −0
Original line number Diff line number Diff line 
Device-Mapper Logging

=====================

The device-mapper logging code is used by some of the device-mapper

RAID targets to track regions of the disk that are not consistent.

A region (or portion of the address space) of the disk may be

inconsistent because a RAID stripe is currently being operated on or

a machine died while the region was being altered.  In the case of

mirrors, a region would be considered dirty/inconsistent while you

are writing to it because the writes need to be replicated for all

the legs of the mirror and may not reach the legs at the same time.

Once all writes are complete, the region is considered clean again.



There is a generic logging interface that the device-mapper RAID

implementations use to perform logging operations (see

dm_dirty_log_type in include/linux/dm-dirty-log.h).  Various different

logging implementations are available and provide different

capabilities.  The list includes:



Type		Files

====		=====

disk		drivers/md/dm-log.c

core		drivers/md/dm-log.c

userspace	drivers/md/dm-log-userspace* include/linux/dm-log-userspace.h



The "disk" log type

-------------------

This log implementation commits the log state to disk.  This way, the

logging state survives reboots/crashes.



The "core" log type

-------------------

This log implementation keeps the log state in memory.  The log state

will not survive a reboot or crash, but there may be a small boost in

performance.  This method can also be used if no storage device is

available for storing log state.



The "userspace" log type

------------------------

This log type simply provides a way to export the log API to userspace,

so log implementations can be done there.  This is done by forwarding most

logging requests to userspace, where a daemon receives and processes the

request.



The structure used for communication between kernel and userspace are

located in include/linux/dm-log-userspace.h.  Due to the frequency,

diversity, and 2-way communication nature of the exchanges between

kernel and userspace, 'connector' is used as the interface for

communication.



There are currently two userspace log implementations that leverage this

framework - "clustered_disk" and "clustered_core".  These implementations

provide a cluster-coherent log for shared-storage.  Device-mapper mirroring

can be used in a shared-storage environment when the cluster log implementations

are employed.