---

yaml
---
r: 84056
b: refs/heads/master
c: ad3399c
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 4383f18b7f94a4d668c5eec68645c75d44556235
+refs/heads/master: ad3399c378993152f12c23304ee56d7f9108e758

trunk/.gitignore

@@ -17,7 +17,6 @@
 *.i
 *.lst
 *.symtypes
-*.order
 
 #
 # Top-level generic files

trunk/CREDITS

@@ -508,8 +508,12 @@ D: REINER SCT cyberJack pinpad/e-com USB chipcard reader driver
 S: Germany
 
 N: Adrian Bunk
+E: bunk@stusta.de
 P: 1024D/4F12B400  B29C E71E FE19 6755 5C8A  84D4 99FC EA98 4F12 B400
 D: misc kernel hacking and testing
+S: Grasmeierstrasse 11
+S: 80805 Muenchen
+S: Germany
 
 N: Ray Burr
 E: ryb@nightmare.com
@@ -1120,9 +1124,6 @@ S: 1150 Ringwood Court
 S: San Jose, California 95131
 S: USA
 
-N: Adam Fritzler
-E: mid@zigamorph.net
-
 N: Fernando Fuganti
 E: fuganti@conectiva.com.br
 E: fuganti@netbank.com.br
@@ -1352,14 +1353,6 @@ S: Gen Stedmanstraat 212
 S: 5623 HZ Eindhoven
 S: The Netherlands
 
-N: Oliver Hartkopp
-E: oliver.hartkopp@volkswagen.de
-W: http://www.volkswagen.de
-D: Controller Area Network (network layer core)
-S: Brieffach 1776
-S: 38436 Wolfsburg
-S: Germany
-
 N: Andrew Haylett
 E: ajh@primag.co.uk
 D: Selection mechanism
@@ -3313,14 +3306,6 @@ S: Universit=E9 de Rennes I
 S: F-35042 Rennes Cedex
 S: France
 
-N: Urs Thuermann
-E: urs.thuermann@volkswagen.de
-W: http://www.volkswagen.de
-D: Controller Area Network (network layer core)
-S: Brieffach 1776
-S: 38436 Wolfsburg
-S: Germany
-
 N: Jon Tombs
 E: jon@gte.esi.us.es
 W: http://www.esi.us.es/~jon

trunk/Documentation/00-INDEX

@@ -126,16 +126,18 @@ devices.txt
 	- plain ASCII listing of all the nodes in /dev/ with major minor #'s.
 digiepca.txt
 	- info on Digi Intl. {PC,PCI,EISA}Xx and Xem series cards.
+dnotify.txt
+	- info about directory notification in Linux.
 dontdiff
 	- file containing a list of files that should never be diff'ed.
 driver-model/
 	- directory with info about Linux driver model.
+drivers/
+	- directory with driver documentation (currently only EDAC).
 dvb/
 	- info on Linux Digital Video Broadcast (DVB) subsystem.
 early-userspace/
 	- info about initramfs, klibc, and userspace early during boot.
-edac.txt
-	- information on EDAC - Error Detection And Correction
 eisa.txt
 	- info on EISA bus support.
 exception.txt
@@ -152,7 +154,7 @@ firmware_class/
 	- request_firmware() hotplug interface info.
 floppy.txt
 	- notes and driver options for the floppy disk driver.
-frv/
+fujitsu/
 	- Fujitsu FR-V Linux documentation.
 gpio.txt
 	- overview of GPIO (General Purpose Input/Output) access conventions.
@@ -332,8 +334,20 @@ rtc.txt
 	- notes on how to use the Real Time Clock (aka CMOS clock) driver.
 s390/
 	- directory with info on using Linux on the IBM S390.
-scheduler/
-	- directory with info on the scheduler.
+sched-arch.txt
+	- CPU Scheduler implementation hints for architecture specific code.
+sched-coding.txt
+	- reference for various scheduler-related methods in the O(1) scheduler.
+sched-design.txt
+	- goals, design and implementation of the Linux O(1) scheduler.
+sched-design-CFS.txt
+	- goals, design and implementation of the Complete Fair Scheduler.
+sched-domains.txt
+	- information on scheduling domains.
+sched-nice-design.txt
+	- How and why the scheduler's nice levels are implemented.
+sched-stats.txt
+	- information on schedstats (Linux Scheduler Statistics).
 scsi/
 	- directory with info on Linux scsi support.
 serial/
@@ -346,8 +360,12 @@ sgi-visws.txt
 	- short blurb on the SGI Visual Workstations.
 sh/
 	- directory with info on porting Linux to a new architecture.
+sharedsubtree.txt
+	- a description of shared subtrees for namespaces.
 smart-config.txt
 	- description of the Smart Config makefile feature.
+smp.txt
+	- a few notes on symmetric multi-processing.
 sony-laptop.txt
 	- Sony Notebook Control Driver (SNC) Readme.
 sonypi.txt

trunk/Documentation/ABI/testing/sysfs-bus-usb

@@ -52,36 +52,3 @@ Description:
 		facility is inherently dangerous, it is disabled by default
 		for all devices except hubs.  For more information, see
 		Documentation/usb/persist.txt.
-
-What:		/sys/bus/usb/device/.../power/connected_duration
-Date:		January 2008
-KernelVersion:	2.6.25
-Contact:	Sarah Sharp <sarah.a.sharp@intel.com>
-Description:
-		If CONFIG_PM and CONFIG_USB_SUSPEND are enabled, then this file
-		is present.  When read, it returns the total time (in msec)
-		that the USB device has been connected to the machine.  This
-		file is read-only.
-Users:
-		PowerTOP <power@bughost.org>
-		http://www.lesswatts.org/projects/powertop/
-
-What:		/sys/bus/usb/device/.../power/active_duration
-Date:		January 2008
-KernelVersion:	2.6.25
-Contact:	Sarah Sharp <sarah.a.sharp@intel.com>
-Description:
-		If CONFIG_PM and CONFIG_USB_SUSPEND are enabled, then this file
-		is present.  When read, it returns the total time (in msec)
-		that the USB device has been active, i.e. not in a suspended
-		state.  This file is read-only.
-
-		Tools can use this file and the connected_duration file to
-		compute the percentage of time that a device has been active.
-		For example,
-		echo $((100 * `cat active_duration` / `cat connected_duration`))
-		will give an integer percentage.  Note that this does not
-		account for counter wrap.
-Users:
-		PowerTOP <power@bughost.org>
-		http://www.lesswatts.org/projects/powertop/

trunk/Documentation/ABI/testing/sysfs-kernel-uids

@@ -11,4 +11,4 @@ Description:
 		example would be, if User A has shares = 1024 and user
 		B has shares = 2048, User B will get twice the CPU
 		bandwidth user A will. For more details refer
-		Documentation/scheduler/sched-design-CFS.txt
+		Documentation/sched-design-CFS.txt

trunk/Documentation/BUG-HUNTING

@@ -53,7 +53,7 @@ Finding it the old way
 
 [Sat Mar  2 10:32:33 PST 1996 KERNEL_BUG-HOWTO lm@sgi.com (Larry McVoy)]
 
-This is how to track down a bug if you know nothing about kernel hacking.
+This is how to track down a bug if you know nothing about kernel hacking.  
 It's a brute force approach but it works pretty well.
 
 You need:
@@ -66,12 +66,12 @@ You will then do:
 
         . Rebuild a revision that you believe works, install, and verify that.
         . Do a binary search over the kernels to figure out which one
-          introduced the bug.  I.e., suppose 1.3.28 didn't have the bug, but
+          introduced the bug.  I.e., suppose 1.3.28 didn't have the bug, but 
           you know that 1.3.69 does.  Pick a kernel in the middle and build
           that, like 1.3.50.  Build & test; if it works, pick the mid point
           between .50 and .69, else the mid point between .28 and .50.
         . You'll narrow it down to the kernel that introduced the bug.  You
-          can probably do better than this but it gets tricky.
+          can probably do better than this but it gets tricky.  
 
         . Narrow it down to a subdirectory
 
@@ -81,27 +81,27 @@ You will then do:
             directories:
 
                 Copy the non-working directory next to the working directory
-                as "dir.63".
+                as "dir.63".  
                 One directory at time, try moving the working directory to
-                "dir.62" and mv dir.63 dir"time, try
+                "dir.62" and mv dir.63 dir"time, try 
 
                         mv dir dir.62
                         mv dir.63 dir
                         find dir -name '*.[oa]' -print | xargs rm -f
 
                 And then rebuild and retest.  Assuming that all related
-                changes were contained in the sub directory, this should
-                isolate the change to a directory.
+                changes were contained in the sub directory, this should 
+                isolate the change to a directory.  
 
                 Problems: changes in header files may have occurred; I've
-                found in my case that they were self explanatory - you may
+                found in my case that they were self explanatory - you may 
                 or may not want to give up when that happens.
 
         . Narrow it down to a file
 
           - You can apply the same technique to each file in the directory,
-            hoping that the changes in that file are self contained.
-
+            hoping that the changes in that file are self contained.  
+            
         . Narrow it down to a routine
 
           - You can take the old file and the new file and manually create
@@ -130,7 +130,7 @@ You will then do:
             that makes the difference.
 
 Finally, you take all the info that you have, kernel revisions, bug
-description, the extent to which you have narrowed it down, and pass
+description, the extent to which you have narrowed it down, and pass 
 that off to whomever you believe is the maintainer of that section.
 A post to linux.dev.kernel isn't such a bad idea if you've done some
 work to narrow it down.
@@ -214,23 +214,6 @@ And recompile the kernel with CONFIG_DEBUG_INFO enabled:
   gdb vmlinux
   (gdb) p vt_ioctl
   (gdb) l *(0x<address of vt_ioctl> + 0xda8)
-or, as one command
-  (gdb) l *(vt_ioctl + 0xda8)
-
-If you have a call trace, such as :-
->Call Trace:
-> [<ffffffff8802c8e9>] :jbd:log_wait_commit+0xa3/0xf5
-> [<ffffffff810482d9>] autoremove_wake_function+0x0/0x2e
-> [<ffffffff8802770b>] :jbd:journal_stop+0x1be/0x1ee
-> ...
-this shows the problem in the :jbd: module. You can load that module in gdb
-and list the relevant code.
-  gdb fs/jbd/jbd.ko
-  (gdb) p log_wait_commit
-  (gdb) l *(0x<address> + 0xa3)
-or
-  (gdb) l *(log_wait_commit + 0xa3)
-
 
 Another very useful option of the Kernel Hacking section in menuconfig is
 Debug memory allocations. This will help you see whether data has been

trunk/Documentation/DocBook/Makefile

@@ -11,7 +11,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
 	    procfs-guide.xml writing_usb_driver.xml \
 	    kernel-api.xml filesystems.xml lsm.xml usb.xml \
 	    gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
-	    genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml
+	    genericirq.xml s390-drivers.xml uio-howto.xml
 
 ###
 # The build process is as follows (targets):

trunk/Documentation/DocBook/genericirq.tmpl

@@ -172,7 +172,7 @@
 	  <listitem><para>Chiplevel hardware encapsulation</para></listitem>
 	</orderedlist>
     </para>
-    <sect1 id="Interrupt_control_flow">
+    <sect1>
 	<title>Interrupt control flow</title>
 	<para>
 	Each interrupt is described by an interrupt descriptor structure
@@ -190,7 +190,7 @@
 	referenced by the assigned chip descriptor structure.
 	</para>
     </sect1>
-    <sect1 id="Highlevel_Driver_API">
+    <sect1>
 	<title>Highlevel Driver API</title>
 	<para>
 	  The highlevel Driver API consists of following functions:
@@ -210,7 +210,7 @@
 	  See the autogenerated function documentation for details.
 	</para>
     </sect1>
-    <sect1 id="Highlevel_IRQ_flow_handlers">
+    <sect1>
 	<title>Highlevel IRQ flow handlers</title>
 	<para>
 	  The generic layer provides a set of pre-defined irq-flow methods:
@@ -224,9 +224,9 @@
 	  specific) are assigned to specific interrupts by the architecture
 	  either during bootup or during device initialization.
 	</para>
-	<sect2 id="Default_flow_implementations">
+	<sect2>
 	<title>Default flow implementations</title>
-	    <sect3 id="Helper_functions">
+	    <sect3>
 	 	<title>Helper functions</title>
 		<para>
 		The helper functions call the chip primitives and
@@ -267,9 +267,9 @@ noop(irq)
 	        </para>
 	    </sect3>
 	</sect2>
-	<sect2 id="Default_flow_handler_implementations">
+	<sect2>
 	<title>Default flow handler implementations</title>
-	    <sect3 id="Default_Level_IRQ_flow_handler">
+	    <sect3>
 	 	<title>Default Level IRQ flow handler</title>
 		<para>
 		handle_level_irq provides a generic implementation
@@ -284,7 +284,7 @@ desc->chip->end();
 		</programlisting>
 		</para>
    	    </sect3>
-	    <sect3 id="Default_Edge_IRQ_flow_handler">
+	    <sect3>
 	 	<title>Default Edge IRQ flow handler</title>
 		<para>
 		handle_edge_irq provides a generic implementation
@@ -311,7 +311,7 @@ desc->chip->end();
 		</programlisting>
 		</para>
    	    </sect3>
-	    <sect3 id="Default_simple_IRQ_flow_handler">
+	    <sect3>
 	 	<title>Default simple IRQ flow handler</title>
 		<para>
 		handle_simple_irq provides a generic implementation
@@ -328,7 +328,7 @@ handle_IRQ_event(desc->action);
 		</programlisting>
 		</para>
    	    </sect3>
-	    <sect3 id="Default_per_CPU_flow_handler">
+	    <sect3>
 	 	<title>Default per CPU flow handler</title>
 		<para>
 		handle_percpu_irq provides a generic implementation
@@ -349,7 +349,7 @@ desc->chip->end();
 		</para>
    	    </sect3>
 	</sect2>
-	<sect2 id="Quirks_and_optimizations">
+	<sect2>
 	<title>Quirks and optimizations</title>
 	<para>
 	The generic functions are intended for 'clean' architectures and chips,
@@ -358,7 +358,7 @@ desc->chip->end();
 	overriding the highlevel irq-flow handler.
 	</para>
 	</sect2>
-	<sect2 id="Delayed_interrupt_disable">
+	<sect2>
 	<title>Delayed interrupt disable</title>
 	<para>
 	This per interrupt selectable feature, which was introduced by Russell
@@ -380,7 +380,7 @@ desc->chip->end();
 	</para>
 	</sect2>
     </sect1>
-    <sect1 id="Chiplevel_hardware_encapsulation">
+    <sect1>
 	<title>Chiplevel hardware encapsulation</title>
 	<para>
 	The chip level hardware descriptor structure irq_chip