Loading Documentation/ABI/testing/sysfs-bus-pci +7 −0 Original line number Original line Diff line number Diff line Loading @@ -122,3 +122,10 @@ Description: This symbolic link appears when a device is a Virtual Function. This symbolic link appears when a device is a Virtual Function. The symbolic link points to the PCI device sysfs entry of the The symbolic link points to the PCI device sysfs entry of the Physical Function this device associates with. 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 Original line 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 Original line Diff line number Diff line Loading @@ -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 walkaround, pls. add aerdriver.forceload=y to kernel boot parameter line when booting kernel. Note that forceload=n by default. 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 2.3 AER error output When a PCI-E AER error is captured, an error message will be outputed to 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. console. If it's a correctable error, it is outputed as a warning. Loading Loading @@ -246,3 +250,24 @@ with the PCI Express AER Root driver? A: It could call the helper functions to enable AER in devices and A: It could call the helper functions to enable AER in devices and cleanup uncorrectable status register. Pls. refer to section 3.3. 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/SubmitChecklist +1 −1 Original line number Original line Diff line number Diff line Loading @@ -54,7 +54,7 @@ kernel patches. CONFIG_PREEMPT. CONFIG_PREEMPT. 14: If the patch affects IO/Disk, etc: has been tested with and without 14: If the patch affects IO/Disk, etc: has been tested with and without CONFIG_LBD. CONFIG_LBDAF. 15: All codepaths have been exercised with all lockdep features enabled. 15: All codepaths have been exercised with all lockdep features enabled. Loading Documentation/device-mapper/dm-log.txt 0 → 100644 +54 −0 Original line number Original line 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. Loading
Documentation/ABI/testing/sysfs-bus-pci +7 −0 Original line number Original line Diff line number Diff line Loading @@ -122,3 +122,10 @@ Description: This symbolic link appears when a device is a Virtual Function. This symbolic link appears when a device is a Virtual Function. The symbolic link points to the PCI device sysfs entry of the The symbolic link points to the PCI device sysfs entry of the Physical Function this device associates with. 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 Original line 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 Original line Diff line number Diff line Loading @@ -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 walkaround, pls. add aerdriver.forceload=y to kernel boot parameter line when booting kernel. Note that forceload=n by default. 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 2.3 AER error output When a PCI-E AER error is captured, an error message will be outputed to 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. console. If it's a correctable error, it is outputed as a warning. Loading Loading @@ -246,3 +250,24 @@ with the PCI Express AER Root driver? A: It could call the helper functions to enable AER in devices and A: It could call the helper functions to enable AER in devices and cleanup uncorrectable status register. Pls. refer to section 3.3. 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/SubmitChecklist +1 −1 Original line number Original line Diff line number Diff line Loading @@ -54,7 +54,7 @@ kernel patches. CONFIG_PREEMPT. CONFIG_PREEMPT. 14: If the patch affects IO/Disk, etc: has been tested with and without 14: If the patch affects IO/Disk, etc: has been tested with and without CONFIG_LBD. CONFIG_LBDAF. 15: All codepaths have been exercised with all lockdep features enabled. 15: All codepaths have been exercised with all lockdep features enabled. Loading
Documentation/device-mapper/dm-log.txt 0 → 100644 +54 −0 Original line number Original line 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.
