Merge cantab.net:/home/src/bklinux-2.6

into cantab.net:/home/src/ntfs-2.6

8 files changed, 166 insertions, 25 deletions

diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index 378722d5bb704f..013d8c79da7040 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -1208,6 +1208,14 @@ On the  other  hand,  enabling this feature can cause you to run out of memory
 and thrash the system to death, so large and/or important servers will want to
 set this value to 0.
 
+nr_hugepages and hugetlb_shm_group
+----------------------------------
+
+nr_hugepages configures number of hugetlb page reserved for the system.
+
+hugetlb_shm_group contains group id that is allowed to create SysV shared
+memory segment using hugetlb page.
+
 2.5 /proc/sys/dev - Device specific parameters
 ----------------------------------------------
 
@@ -1848,10 +1856,3 @@ need to  recompile  the kernel, or even to reboot the system. The files in the
 command to write value into these files, thereby changing the default settings
 of the kernel.
 ------------------------------------------------------------------------------
-
-
-
-
-
-
-
diff --git a/Documentation/laptop-mode.txt b/Documentation/laptop-mode.txt
index 9df8d2677bef64..a54adaddab42a0 100644
--- a/Documentation/laptop-mode.txt
+++ b/Documentation/laptop-mode.txt
@@ -76,6 +76,11 @@ Caveats
   variables in centisecs (like most other subsystems do) but in "jiffies",
   which is an internal kernel measure. Once this is fixed things will get better.
 
+* It has been reported that some versions of the mutt mail client use file access
+  times to determine whether a folder contains new mail. If you use mutt and
+  experience this, you must disable the noatime remounting in the control script
+  by setting DO_REMOUNT_NOATIME=0.
+
 
 The details
 -----------
@@ -295,6 +300,9 @@ esac
 # Shall we remount journaled fs. with appropiate commit interval? (1=yes)
 DO_REMOUNTS=1
 
+# And shall we add the "noatime" option to that as well? (1=yes)
+DO_REMOUNT_NOATIME=1
+
 # age time, in seconds. should be put into a sysconfig file
 MAX_AGE=600
 
@@ -335,6 +343,10 @@ if [ ! -w /proc/sys/vm/laptop_mode ]; then
 	exit 1
 fi
 
+if [ $DO_REMOUNT_NOATIME -eq 1 ]; then
+	NOATIME_OPT=",noatime"
+fi
+
 case "$1" in
 	start)
 		AGE=$((100*$MAX_AGE))
@@ -376,10 +388,10 @@ case "$1" in
 				case "$FST" in
 					"ext3"|"reiserfs")
 						PARSEDOPTS="$(parse_mount_opts commit "$OPTS")"
-						mount $DEV -t $FST $MP -o remount,$PARSEDOPTS,commit=$MAX_AGE,noatime
+						mount $DEV -t $FST $MP -o remount,$PARSEDOPTS,commit=$MAX_AGE$NOATIME_OPT
 						;;
 					"xfs")
-						mount $DEV -t $FST $MP -o remount,$OPTS,noatime
+						mount $DEV -t $FST $MP -o remount,$OPTS$NOATIME_OPT
 						;;
 				esac
 				if [ -b $DEV ] ; then
diff --git a/Documentation/md.txt b/Documentation/md.txt
index 203231307a2606..3fb3b1ef18fb9c 100644
--- a/Documentation/md.txt
+++ b/Documentation/md.txt
@@ -2,6 +2,8 @@ Tools that manage md devices can be found at
    http://www.<country>.kernel.org/pub/linux/utils/raid/....
 
 
+Boot time assembly of RAID arrays
+---------------------------------
 
 You can boot with your md device with the following kernel command
 lines:
@@ -11,6 +13,8 @@ for old raid arrays without persistent superblocks:
 
 for raid arrays with persistent superblocks
   md=<md device no.>,dev0,dev1,...,devn
+or, to assemble a partitionable array:
+  md=d<md device no.>,dev0,dev1,...,devn
   
 md device no. = the number of the md device ... 
               0 means md0, 
@@ -34,7 +38,22 @@ A possible loadlin line (Harald Hoyer <HarryH@Royal.Net>)  looks like this:
 
 e:\loadlin\loadlin e:\zimage root=/dev/md0 md=0,0,4,0,/dev/hdb2,/dev/hdc3 ro
 
--------------------------------
+
+Boot time autodetection of RAID arrays
+--------------------------------------
+
+When md is compiled into the kernel (not as module), partitions of
+type 0xfd are scanned and automatically assembled into RAID arrays.
+This autodetection may be suppressed with the kernel parameter
+"raid=noautodetect".
+
+The kernel parameter "raid=partitionable" (or "raid=part") means
+that all auto-detected arrays are assembled as partitionable.
+
+
+Superblock formats
+------------------
+
 The md driver can support a variety of different superblock formats.
 (It doesn't yet, but it can)
 
@@ -82,7 +101,7 @@ array using HOT_REMOVE_DISK.
 
 
 Specific Rules that apply to format-0 super block arrays, and
-       arrays with no superblock (non-presistant).
+       arrays with no superblock (non-persistant).
 -------------------------------------------------------------
 
 An array can be 'created' by describing the array (level, chunksize
diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt
index afe9bb766f42e8..168322ef857740 100644
--- a/Documentation/power/swsusp.txt
+++ b/Documentation/power/swsusp.txt
@@ -123,10 +123,61 @@ server is not hotplug capable. What do you do? Suspend to disk,
 replace ethernet card, resume. If you are fast your users will not
 even see broken connections.
 
-Any other idea you might have tell me!
+Q: Maybe I'm missing something, but why doesn't the regular io paths
+work?
 
-Contacting the author
-If you have any question or any patch that solves the above or detected
-problems please contact me at seasons@falcon.sch.bme.hu. I might delay
-answering, sorry about that.
+A: (Basically) you want to replace all kernel data with kernel data saved
+on disk. How do you do that using normal i/o paths? If you'll read
+"new" data 4KB at a time, you'll crash... because you still need "old"
+data to do the reading, and "new" data may fit on same physical spot
+in memory.
 
+There are two solutions to this:
+
+* require half of memory to be free during suspend. That way you can
+read "new" data onto free spots, then cli and copy
+
+* assume we had special "polling" ide driver that only uses memory
+between 0-640KB. That way, I'd have to make sure that 0-640KB is free
+during suspending, but otherwise it would work...
+
+Q: Does linux support ACPI S4?
+
+A: No.
+
+When swsusp was created, ACPI was not too widespread, so we tried to
+avoid using ACPI-specific stuff. ACPI also is/was notoriously
+buggy. These days swsusp works on APM-only i386 machines and even
+without any power managment at all. Some versions also work on PPC.
+
+That means that machine does not enter S4 on suspend-to-disk, but
+simply enters S5. That has few advantages, you can for example boot
+windows on next boot, and return to your Linux session later. You
+could even have few different Linuxes on your box (not sharing any
+partitions), and switch between them.
+
+It also has disadvantages. On HP nx5000, if you unplug power cord
+while machine is suspended-to-disk, Linux will fail to notice that.
+
+Q: My machine doesn't work with ACPI. How can I use swsusp than ?
+
+A: Do reboot() syscall with right parameters. Warning: glibc gets in
+its way, so check with strace:
+
+reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, 0xd000fce2)
+
+(Thanks to Peter Osterlund:)
+
+#include <unistd.h>
+#include <syscall.h>
+
+#define LINUX_REBOOT_MAGIC1     0xfee1dead
+#define LINUX_REBOOT_MAGIC2     672274793
+#define LINUX_REBOOT_CMD_SW_SUSPEND     0xD000FCE2
+
+int main()
+{
+    syscall(SYS_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
+            LINUX_REBOOT_CMD_SW_SUSPEND, 0);
+    return 0;
+}
diff --git a/Documentation/sched-domains.txt b/Documentation/sched-domains.txt
new file mode 100644
index 00000000000000..b5da811fcbcb7d
--- /dev/null
+++ b/Documentation/sched-domains.txt
@@ -0,0 +1,55 @@
+Each CPU has a "base" scheduling domain (struct sched_domain). These are
+accessed via cpu_sched_domain(i) and this_sched_domain() macros. The domain
+hierarchy is built from these base domains via the ->parent pointer. ->parent
+MUST be NULL terminated, and domain structures should be per-CPU as they
+are locklessly updated.
+
+Each scheduling domain spans a number of CPUs (stored in the ->span field).
+A domain's span MUST be a superset of it child's span, and a base domain
+for CPU i MUST span at least i. The top domain for each CPU will generally
+span all CPUs in the system although strictly it doesn't have to, but this
+could lead to a case where some CPUs will never be given tasks to run unless
+the CPUs allowed mask is explicitly set. A sched domain's span means "balance
+process load among these CPUs".
+
+Each scheduling domain must have one or more CPU groups (struct sched_group)
+which are organised as a circular one way linked list from the ->groups
+pointer. The union of cpumasks of these groups MUST be the same as the
+domain's span. The intersection of cpumasks from any two of these groups
+MUST be the empty set. The group pointed to by the ->groups pointer MUST
+contain the CPU to which the domain belongs. Groups may be shared among
+CPUs as they contain read only data after they have been set up.
+
+Balancing within a sched domain occurs between groups. That is, each group
+is treated as one entity. The load of a group is defined as the sum of the
+load of each of its member CPUs, and only when the load of a group becomes
+out of balance are tasks moved between groups.
+
+In kernel/sched.c, rebalance_tick is run periodically on each CPU. This
+function takes its CPU's base sched domain and checks to see if has reached
+its rebalance interval. If so, then it will run load_balance on that domain.
+rebalance_tick then checks the parent sched_domain (if it exists), and the
+parent of the parent and so forth.
+
+*** Implementing sched domains ***
+The "base" domain will "span" the first level of the hierarchy. In the case
+of SMT, you'll span all siblings of the physical CPU, with each group being
+a single virtual CPU.
+
+In SMP, the parent of the base domain will span all physical CPUs in the
+node. Each group being a single physical CPU. Then with NUMA, the parent
+of the SMP domain will span the entire machine, with each group having the
+cpumask of a node. Or, you could do multi-level NUMA or Opteron, for example,
+might have just one domain covering its one NUMA level.
+
+The implementor should read comments in include/linux/sched.h:
+struct sched_domain fields, SD_FLAG_*, SD_*_INIT to get an idea of
+the specifics and what to tune.
+
+Implementors should change the line
+#undef SCHED_DOMAIN_DEBUG
+to
+#define SCHED_DOMAIN_DEBUG
+in kernel/sched.c as this enables an error checking parse of the sched domains
+which should catch most possible errors (described above). It also prints out
+the domain structure in a visual format.
diff --git a/Documentation/sound/oss/OPL3-SA b/Documentation/sound/oss/OPL3-SA
index 0d91c8bf3b83a2..66a91835d91866 100644
--- a/Documentation/sound/oss/OPL3-SA
+++ b/Documentation/sound/oss/OPL3-SA
@@ -34,7 +34,7 @@ Module options in detail:
 	mpu_irq: This is the MPU401's IRQ.
 
 If you'd like to use the OPL3 FM Synthesizer, make sure you enable
-CONFIG_YM3812 (in 'make config'). That'll build the opl3.o module.
+CONFIG_SOUND_YM3812 (in 'make config'). That'll build the opl3.o module.
 
 Then a simple 'insmod opl3 io=0x388', and you now have FM Synth.
 
diff --git a/Documentation/sound/oss/VIBRA16 b/Documentation/sound/oss/VIBRA16
index 0a0aff9d75314e..68a5a46beb88ed 100644
--- a/Documentation/sound/oss/VIBRA16
+++ b/Documentation/sound/oss/VIBRA16
@@ -62,12 +62,12 @@ modprobe sb io=0x220 irq=5 dma=1 dma16=3
 
 	Or, take the hard way:
 
-insmod souncore
-insmod sound
-insmod uart401
-insmod sb io=0x220 irq=5 dma=1 dma16=3
+modprobe soundcore
+modprobe sound
+modprobe uart401
+modprobe sb io=0x220 irq=5 dma=1 dma16=3
 # do you need MIDI?
-insmod opl3=0x388
+modprobe opl3=0x388
 
 	Just in case, the kernel sound support should be:
 
diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt
index 61ae09f49abc71..47a7121b4dc5ee 100644
--- a/Documentation/vm/hugetlbpage.txt
+++ b/Documentation/vm/hugetlbpage.txt
@@ -91,9 +91,12 @@ A regular chown, chgrp and chmod commands (with right permissions) could be
 used to change the file attributes on hugetlbfs.
 
 Also, it is important to note that no such mount command is required if the
-applications are going to use only shmat/shmget system calls.  It is possible
-for same or different applications to use any combination of mmaps and shm*
-calls.  Though the mount of filesystem will be required for using mmaps.
+applications are going to use only shmat/shmget system calls.  Users who
+wish to use hugetlb page via shared memory segment should be a member of
+a supplementary group and system admin needs to configure that gid into
+/proc/sys/vm/hugetlb_shm_group.  It is possible for same or different
+applications to use any combination of mmaps and shm* calls.  Though the
+mount of filesystem will be required for using mmaps.
 
 /* Example of using hugepage in user application using Sys V shared memory
  * system calls.  In this example, app is requesting memory of size 256MB that