Merge branch 'linus' into cpus4096 (82638844) · Commits · jan.koester / Linux

Documentation/ABI/testing/sysfs-block

+34 −0

Original line number	Diff line number	Diff line
		@@ -26,3 +26,37 @@ Description:
		I/O statistics of partition <part>. The format is the
		same as the above-written /sys/block/<disk>/stat
		format.


		What: /sys/block/<disk>/integrity/format
		Date: June 2008
		Contact: Martin K. Petersen <martin.petersen@oracle.com>
		Description:
		Metadata format for integrity capable block device.
		E.g. T10-DIF-TYPE1-CRC.


		What: /sys/block/<disk>/integrity/read_verify
		Date: June 2008
		Contact: Martin K. Petersen <martin.petersen@oracle.com>
		Description:
		Indicates whether the block layer should verify the
		integrity of read requests serviced by devices that
		support sending integrity metadata.


		What: /sys/block/<disk>/integrity/tag_size
		Date: June 2008
		Contact: Martin K. Petersen <martin.petersen@oracle.com>
		Description:
		Number of bytes of integrity tag space available per
		512 bytes of data.


		What: /sys/block/<disk>/integrity/write_generate
		Date: June 2008
		Contact: Martin K. Petersen <martin.petersen@oracle.com>
		Description:
		Indicates whether the block layer should automatically
		generate checksums for write requests bound for
		devices that support receiving integrity metadata.

Documentation/ABI/testing/sysfs-bus-css

0 → 100644

+35 −0

Original line number	Diff line number	Diff line
		What: /sys/bus/css/devices/.../type
		Date: March 2008
		Contact: Cornelia Huck <cornelia.huck@de.ibm.com>
		linux-s390@vger.kernel.org
		Description: Contains the subchannel type, as reported by the hardware.
		This attribute is present for all subchannel types.

		What: /sys/bus/css/devices/.../modalias
		Date: March 2008
		Contact: Cornelia Huck <cornelia.huck@de.ibm.com>
		linux-s390@vger.kernel.org
		Description: Contains the module alias as reported with uevents.
		It is of the format css:t<type> and present for all
		subchannel types.

		What: /sys/bus/css/drivers/io_subchannel/.../chpids
		Date: December 2002
		Contact: Cornelia Huck <cornelia.huck@de.ibm.com>
		linux-s390@vger.kernel.org
		Description: Contains the ids of the channel paths used by this
		subchannel, as reported by the channel subsystem
		during subchannel recognition.
		Note: This is an I/O-subchannel specific attribute.
		Users: s390-tools, HAL

		What: /sys/bus/css/drivers/io_subchannel/.../pimpampom
		Date: December 2002
		Contact: Cornelia Huck <cornelia.huck@de.ibm.com>
		linux-s390@vger.kernel.org
		Description: Contains the PIM/PAM/POM values, as reported by the
		channel subsystem when last queried by the common I/O
		layer (this implies that this attribute is not neccessarily
		in sync with the values current in the channel subsystem).
		Note: This is an I/O-subchannel specific attribute.
		Users: s390-tools, HAL

Documentation/ABI/testing/sysfs-firmware-memmap

0 → 100644

+71 −0

Original line number	Diff line number	Diff line
		What: /sys/firmware/memmap/
		Date: June 2008
		Contact: Bernhard Walle <bwalle@suse.de>
		Description:
		On all platforms, the firmware provides a memory map which the
		kernel reads. The resources from that memory map are registered
		in the kernel resource tree and exposed to userspace via
		/proc/iomem (together with other resources).

		However, on most architectures that firmware-provided memory
		map is modified afterwards by the kernel itself, either because
		the kernel merges that memory map with other information or
		just because the user overwrites that memory map via command
		line.

		kexec needs the raw firmware-provided memory map to setup the
		parameter segment of the kernel that should be booted with
		kexec. Also, the raw memory map is useful for debugging. For
		that reason, /sys/firmware/memmap is an interface that provides
		the raw memory map to userspace.

		The structure is as follows: Under /sys/firmware/memmap there
		are subdirectories with the number of the entry as their name:

		/sys/firmware/memmap/0
		/sys/firmware/memmap/1
		/sys/firmware/memmap/2
		/sys/firmware/memmap/3
		...

		The maximum depends on the number of memory map entries provided
		by the firmware. The order is just the order that the firmware
		provides.

		Each directory contains three files:

		start : The start address (as hexadecimal number with the
		'0x' prefix).
		end : The end address, inclusive (regardless whether the
		firmware provides inclusive or exclusive ranges).
		type : Type of the entry as string. See below for a list of
		valid types.

		So, for example:

		/sys/firmware/memmap/0/start
		/sys/firmware/memmap/0/end
		/sys/firmware/memmap/0/type
		/sys/firmware/memmap/1/start
		...

		Currently following types exist:

		- System RAM
		- ACPI Tables
		- ACPI Non-volatile Storage
		- reserved

		Following shell snippet can be used to display that memory
		map in a human-readable format:

		-------------------- 8< ----------------------------------------
		#!/bin/bash
		cd /sys/firmware/memmap
		for dir in * ; do
		start=$(cat $dir/start)
		end=$(cat $dir/end)
		type=$(cat $dir/type)
		printf "%016x-%016x (%s)\n" $start $[ $end +1] "$type"
		done
		-------------------- >8 ----------------------------------------

Documentation/HOWTO

+1 −1

Original line number	Diff line number	Diff line
		@@ -377,7 +377,7 @@ Bug Reporting
		bugzilla.kernel.org is where the Linux kernel developers track kernel
		bugs. Users are encouraged to report all bugs that they find in this
		tool. For details on how to use the kernel bugzilla, please see:
		http://test.kernel.org/bugzilla/faq.html
		http://bugzilla.kernel.org/page.cgi?id=faq.html

		The file REPORTING-BUGS in the main kernel source directory has a good
		template for how to report a possible kernel bug, and details what kind

Documentation/IRQ-affinity.txt

+28 −9

Original line number	Diff line number	Diff line
		ChangeLog:
		Started by Ingo Molnar <mingo@redhat.com>
		Update by Max Krasnyansky <maxk@qualcomm.com>

		SMP IRQ affinity, started by Ingo Molnar <mingo@redhat.com>

		SMP IRQ affinity

		/proc/irq/IRQ#/smp_affinity specifies which target CPUs are permitted
		for a given IRQ source. It's a bitmask of allowed CPUs. It's not allowed
		to turn off all CPUs, and if an IRQ controller does not support IRQ
		affinity then the value will not change from the default 0xffffffff.

		/proc/irq/default_smp_affinity specifies default affinity mask that applies
		to all non-active IRQs. Once IRQ is allocated/activated its affinity bitmask
		will be set to the default mask. It can then be changed as described above.
		Default mask is 0xffffffff.

		Here is an example of restricting IRQ44 (eth1) to CPU0-3 then restricting
		the IRQ to CPU4-7 (this is an 8-CPU SMP box):
		it to CPU4-7 (this is an 8-CPU SMP box):

		[root@moon 44]# cd /proc/irq/44
		[root@moon 44]# cat smp_affinity
		ffffffff

		[root@moon 44]# echo 0f > smp_affinity
		[root@moon 44]# cat smp_affinity
		0000000f
		@@ -21,17 +30,27 @@ PING hell (195.4.7.3): 56 data bytes
		--- hell ping statistics ---
		6029 packets transmitted, 6027 packets received, 0% packet loss
		round-trip min/avg/max = 0.1/0.1/0.4 ms
		[root@moon 44]# cat /proc/interrupts \| grep 44:
		44: 0 1785 1785 1783 1783 1
		1 0 IO-APIC-level eth1
		[root@moon 44]# cat /proc/interrupts \| grep 'CPU\\|44:'
		CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
		44: 1068 1785 1785 1783 0 0 0 0 IO-APIC-level eth1

		As can be seen from the line above IRQ44 was delivered only to the first four
		processors (0-3).
		Now lets restrict that IRQ to CPU(4-7).

		[root@moon 44]# echo f0 > smp_affinity
		[root@moon 44]# cat smp_affinity
		000000f0
		[root@moon 44]# ping -f h
		PING hell (195.4.7.3): 56 data bytes
		..
		--- hell ping statistics ---
		2779 packets transmitted, 2777 packets received, 0% packet loss
		round-trip min/avg/max = 0.1/0.5/585.4 ms
		[root@moon 44]# cat /proc/interrupts \| grep 44:
		44: 1068 1785 1785 1784 1784 1069 1070 1069 IO-APIC-level eth1
		[root@moon 44]#
		[root@moon 44]# cat /proc/interrupts \| 'CPU\\|44:'
		CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
		44: 1068 1785 1785 1783 1784 1069 1070 1069 IO-APIC-level eth1

		This time around IRQ44 was delivered only to the last four processors.
		i.e counters for the CPU0-3 did not change.