---

yaml
---
r: 249963
b: refs/heads/master
c: 16dc062
h: refs/heads/master
i:
  249961: 4b9a8a7
  249959: 213fddb
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 399bc4863e2a3b4b255ca22189820c81ca34f4e0
+refs/heads/master: 16dc062b42459e6ddd244c2bc8255cac45db47e4

trunk/Documentation/cgroups/memory.txt

@@ -52,10 +52,8 @@ Brief summary of control files.
  tasks				 # attach a task(thread) and show list of threads
  cgroup.procs			 # show list of processes
  cgroup.event_control		 # an interface for event_fd()
- memory.usage_in_bytes		 # show current res_counter usage for memory
-				 (See 5.5 for details)
- memory.memsw.usage_in_bytes	 # show current res_counter usage for memory+Swap
-				 (See 5.5 for details)
+ memory.usage_in_bytes		 # show current memory(RSS+Cache) usage.
+ memory.memsw.usage_in_bytes	 # show current memory+Swap usage
  memory.limit_in_bytes		 # set/show limit of memory usage
  memory.memsw.limit_in_bytes	 # set/show limit of memory+Swap usage
  memory.failcnt			 # show the number of memory usage hits limits
@@ -455,15 +453,6 @@ memory under it will be reclaimed.
 You can reset failcnt by writing 0 to failcnt file.
 # echo 0 > .../memory.failcnt
 
-5.5 usage_in_bytes
-
-For efficiency, as other kernel components, memory cgroup uses some optimization
-to avoid unnecessary cacheline false sharing. usage_in_bytes is affected by the
-method and doesn't show 'exact' value of memory(and swap) usage, it's an fuzz
-value for efficient access. (Of course, when necessary, it's synchronized.)
-If you want to know more exact memory usage, you should use RSS+CACHE(+SWAP)
-value in memory.stat(see 5.2).
-
 6. Hierarchy support
 
 The memory controller supports a deep hierarchy and hierarchical accounting.

trunk/Documentation/flexible-arrays.txt

@@ -66,10 +66,10 @@ trick is to ensure that any needed memory allocations are done before
 entering atomic context, using:
 
     int flex_array_prealloc(struct flex_array *array, unsigned int start,
-			    unsigned int nr_elements, gfp_t flags);
+			    unsigned int end, gfp_t flags);
 
 This function will ensure that memory for the elements indexed in the range
-defined by start and nr_elements has been allocated.  Thereafter, a
+defined by start and end has been allocated.  Thereafter, a
 flex_array_put() call on an element in that range is guaranteed not to
 block.
 

trunk/Documentation/hwmon/adm1021

@@ -14,6 +14,10 @@ Supported chips:
     Prefix: 'gl523sm'
     Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
     Datasheet:
+  * Intel Xeon Processor
+    Prefix: - any other - may require 'force_adm1021' parameter
+    Addresses scanned: none
+    Datasheet: Publicly available at Intel website
   * Maxim MAX1617
     Prefix: 'max1617'
     Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
@@ -87,27 +91,21 @@ will do no harm, but will return 'old' values. It is possible to make
 ADM1021-clones do faster measurements, but there is really no good reason
 for that.
 
+Xeon support
+------------
 
-Netburst-based Xeon support
----------------------------
+Some Xeon processors have real max1617, adm1021, or compatible chips
+within them, with two temperature sensors.
 
-Some Xeon processors based on the Netburst (early Pentium 4, from 2001 to
-2003) microarchitecture had real MAX1617, ADM1021, or compatible chips
-within them, with two temperature sensors. Other Xeon processors of this
-era (with 400 MHz FSB) had chips with only one temperature sensor.
+Other Xeons have chips with only one sensor.
 
-If you have such an old Xeon, and you get two valid temperatures when
-loading the adm1021 module, then things are good.
+If you have a Xeon, and the adm1021 module loads, and both temperatures
+appear valid, then things are good.
 
-If nothing happens when loading the adm1021 module, and you are certain
-that your specific Xeon processor model includes compatible sensors, you
-will have to explicitly instantiate the sensor chips from user-space. See
-method 4 in Documentation/i2c/instantiating-devices. Possible slave
-addresses are 0x18, 0x1a, 0x29, 0x2b, 0x4c, or 0x4e. It is likely that
-only temp2 will be correct and temp1 will have to be ignored.
+If the adm1021 module doesn't load, you should try this:
+	modprobe adm1021 force_adm1021=BUS,ADDRESS
+	ADDRESS can only be 0x18, 0x1a, 0x29, 0x2b, 0x4c, or 0x4e.
 
-Previous generations of the Xeon processor (based on Pentium II/III)
-didn't have these sensors. Next generations of Xeon processors (533 MHz
-FSB and faster) lost them, until the Core-based generation which
-introduced integrated digital thermal sensors. These are supported by
-the coretemp driver.
+If you have dual Xeons you may have appear to have two separate
+adm1021-compatible chips, or two single-temperature sensors, at distinct
+addresses.

trunk/Documentation/hwmon/lm90

@@ -32,16 +32,6 @@ Supported chips:
     Addresses scanned: I2C 0x4c and 0x4d
     Datasheet: Publicly available at the ON Semiconductor website
                http://www.onsemi.com/PowerSolutions/product.do?id=ADT7461
-  * Analog Devices ADT7461A
-    Prefix: 'adt7461a'
-    Addresses scanned: I2C 0x4c and 0x4d
-    Datasheet: Publicly available at the ON Semiconductor website
-               http://www.onsemi.com/PowerSolutions/product.do?id=ADT7461A
-  * ON Semiconductor NCT1008
-    Prefix: 'nct1008'
-    Addresses scanned: I2C 0x4c and 0x4d
-    Datasheet: Publicly available at the ON Semiconductor website
-               http://www.onsemi.com/PowerSolutions/product.do?id=NCT1008
   * Maxim MAX6646
     Prefix: 'max6646'
     Addresses scanned: I2C 0x4d
@@ -159,7 +149,7 @@ ADM1032:
   * ALERT is triggered by open remote sensor.
   * SMBus PEC support for Write Byte and Receive Byte transactions.
 
-ADT7461, ADT7461A, NCT1008:
+ADT7461:
   * Extended temperature range (breaks compatibility)
   * Lower resolution for remote temperature
 
@@ -205,22 +195,21 @@ are exported, one for each channel, but these values are of course linked.
 Only the local hysteresis can be set from user-space, and the same delta
 applies to the remote hysteresis.
 
-The lm90 driver will not update its values more frequently than configured with
-the update_interval attribute; reading them more often will do no harm, but will
-return 'old' values.
+The lm90 driver will not update its values more frequently than every
+other second; reading them more often will do no harm, but will return
+'old' values.
 
 SMBus Alert Support
 -------------------
 
 This driver has basic support for SMBus alert. When an alert is received,
 the status register is read and the faulty temperature channel is logged.
 
-The Analog Devices chips (ADM1032, ADT7461 and ADT7461A) and ON
-Semiconductor chips (NCT1008) do not implement the SMBus alert protocol
-properly so additional care is needed: the ALERT output is disabled when
-an alert is received, and is re-enabled only when the alarm is gone.
-Otherwise the chip would block alerts from other chips in the bus as long
-as the alarm is active.
+The Analog Devices chips (ADM1032 and ADT7461) do not implement the SMBus
+alert protocol properly so additional care is needed: the ALERT output is
+disabled when an alert is received, and is re-enabled only when the alarm
+is gone. Otherwise the chip would block alerts from other chips in the bus
+as long as the alarm is active.
 
 PEC Support
 -----------

trunk/Documentation/workqueue.txt

@@ -12,7 +12,6 @@ CONTENTS
 4. Application Programming Interface (API)
 5. Example Execution Scenarios
 6. Guidelines
-7. Debugging
 
 
 1. Introduction
@@ -380,42 +379,3 @@ If q1 has WQ_CPU_INTENSIVE set,
 * Unless work items are expected to consume a huge amount of CPU
   cycles, using a bound wq is usually beneficial due to the increased
   level of locality in wq operations and work item execution.
-
-
-7. Debugging
-
-Because the work functions are executed by generic worker threads
-there are a few tricks needed to shed some light on misbehaving
-workqueue users.
-
-Worker threads show up in the process list as:
-
-root      5671  0.0  0.0      0     0 ?        S    12:07   0:00 [kworker/0:1]
-root      5672  0.0  0.0      0     0 ?        S    12:07   0:00 [kworker/1:2]
-root      5673  0.0  0.0      0     0 ?        S    12:12   0:00 [kworker/0:0]
-root      5674  0.0  0.0      0     0 ?        S    12:13   0:00 [kworker/1:0]
-
-If kworkers are going crazy (using too much cpu), there are two types
-of possible problems:
-
-	1. Something beeing scheduled in rapid succession
-	2. A single work item that consumes lots of cpu cycles
-
-The first one can be tracked using tracing:
-
-	$ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event
-	$ cat /sys/kernel/debug/tracing/trace_pipe > out.txt
-	(wait a few secs)
-	^C
-
-If something is busy looping on work queueing, it would be dominating
-the output and the offender can be determined with the work item
-function.
-
-For the second type of problems it should be possible to just check
-the stack trace of the offending worker thread.
-
-	$ cat /proc/THE_OFFENDING_KWORKER/stack
-
-The work item's function should be trivially visible in the stack
-trace.

trunk/MAINTAINERS

@@ -1032,13 +1032,12 @@ W:	http://www.fluff.org/ben/linux/
 S:	Maintained
 F:	arch/arm/mach-s3c64xx/
 
-ARM/S5P EXYNOS ARM ARCHITECTURES
+ARM/S5P ARM ARCHITECTURES
 M:	Kukjin Kim <kgene.kim@samsung.com>
 L:	linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
 L:	linux-samsung-soc@vger.kernel.org (moderated for non-subscribers)
 S:	Maintained
 F:	arch/arm/mach-s5p*/
-F:	arch/arm/mach-exynos*/
 
 ARM/SAMSUNG MOBILE MACHINE SUPPORT
 M:	Kyungmin Park <kyungmin.park@samsung.com>
@@ -2809,7 +2808,7 @@ GPIO SUBSYSTEM
 M:	Grant Likely <grant.likely@secretlab.ca>
 S:	Maintained
 T:	git git://git.secretlab.ca/git/linux-2.6.git
-F:	Documentation/gpio.txt
+F:	Documentation/gpio/gpio.txt
 F:	drivers/gpio/
 F:	include/linux/gpio*
 
@@ -6556,7 +6555,7 @@ S:	Maintained
 F:	drivers/usb/host/uhci*
 
 USB "USBNET" DRIVER FRAMEWORK
-M:	Oliver Neukum <oneukum@suse.de>
+M:	David Brownell <dbrownell@users.sourceforge.net>
 L:	netdev@vger.kernel.org
 W:	http://www.linux-usb.org/usbnet
 S:	Maintained
@@ -6922,18 +6921,6 @@ T:	git git://git.kernel.org/pub/scm/linux/kernel/git/mjg59/platform-drivers-x86.
 S:	Maintained
 F:	drivers/platform/x86
 
-XEN HYPERVISOR INTERFACE
-M:	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
-M:	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-L:	xen-devel@lists.xensource.com (moderated for non-subscribers)
-L:	virtualization@lists.linux-foundation.org
-S:	Supported
-F:	arch/x86/xen/
-F:	drivers/*/xen-*front.c
-F:	drivers/xen/
-F:	arch/x86/include/asm/xen/
-F:	include/xen/
-
 XEN NETWORK BACKEND DRIVER
 M:	Ian Campbell <ian.campbell@citrix.com>
 L:	xen-devel@lists.xensource.com (moderated for non-subscribers)
@@ -6955,6 +6942,18 @@ S:	Supported
 F:	arch/x86/xen/*swiotlb*
 F:	drivers/xen/*swiotlb*
 
+XEN HYPERVISOR INTERFACE
+M:	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
+M:	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+L:	xen-devel@lists.xensource.com (moderated for non-subscribers)
+L:	virtualization@lists.linux-foundation.org
+S:	Supported
+F:	arch/x86/xen/
+F:	drivers/*/xen-*front.c
+F:	drivers/xen/
+F:	arch/x86/include/asm/xen/
+F:	include/xen/
+
 XFS FILESYSTEM
 P:	Silicon Graphics Inc
 M:	Alex Elder <aelder@sgi.com>

trunk/Makefile

@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 39
-EXTRAVERSION = -rc7
+EXTRAVERSION = -rc5
 NAME = Flesh-Eating Bats with Fangs
 
 # *DOCUMENTATION*

trunk/arch/arm/Kconfig

@@ -554,18 +554,6 @@ config ARCH_KS8695
 	  Support for Micrel/Kendin KS8695 "Centaur" (ARM922T) based
 	  System-on-Chip devices.
 
-config ARCH_NS9XXX
-	bool "NetSilicon NS9xxx"
-	select CPU_ARM926T
-	select GENERIC_GPIO
-	select GENERIC_CLOCKEVENTS
-	select HAVE_CLK
-	help
-	  Say Y here if you intend to run this kernel on a NetSilicon NS9xxx
-	  System.
-
-	  <http://www.digi.com/products/microprocessors/index.jsp>
-
 config ARCH_W90X900
 	bool "Nuvoton W90X900 CPU"
 	select CPU_ARM926T
@@ -951,8 +939,6 @@ source "arch/arm/mach-netx/Kconfig"
 source "arch/arm/mach-nomadik/Kconfig"
 source "arch/arm/plat-nomadik/Kconfig"
 
-source "arch/arm/mach-ns9xxx/Kconfig"
-
 source "arch/arm/mach-nuc93x/Kconfig"
 
 source "arch/arm/plat-omap/Kconfig"

trunk/arch/arm/Makefile

@@ -164,7 +164,6 @@ machine-$(CONFIG_ARCH_MXC91231)		:= mxc91231
 machine-$(CONFIG_ARCH_MXS)		:= mxs
 machine-$(CONFIG_ARCH_NETX)		:= netx
 machine-$(CONFIG_ARCH_NOMADIK)		:= nomadik
-machine-$(CONFIG_ARCH_NS9XXX)		:= ns9xxx
 machine-$(CONFIG_ARCH_OMAP1)		:= omap1
 machine-$(CONFIG_ARCH_OMAP2)		:= omap2
 machine-$(CONFIG_ARCH_OMAP3)		:= omap2