bitkeeper revision 1.1159.1.353 (418903a56T1yUvYK5LHeS6GM6mXZaw)

cunning fix

2 files changed, 19 insertions, 16 deletions

diff --git a/docs/src/user.tex b/docs/src/user.tex
index f0be341112..cf18459188 100644
--- a/docs/src/user.tex
+++ b/docs/src/user.tex
@@ -492,7 +492,7 @@ details of the {\tt xm} tool in Section~\ref{s:xm}.
 This example explains how to use the \path{xmdefconfig} file.  If you
 require a more complex setup, you will want to write a custom
 configuration file --- details of the configuration file formats are
-included in Chapter~\ref{cha:config}.
+included in Section~\ref{s:cfiles}. 
 
 The \path{xmexample1} file is a simple template configuration file
 for describing a single VM.
@@ -503,9 +503,10 @@ to be reused for multiple virtual machines.  Setting the value of the
 fills in parts of this template.
 
 Both of them can be found in \path{/etc/xen/}
-\subsection{Editing \path{xmdefconfig}}
+\section{Editing \path{xmdefconfig}}
 
-At minimum, you should edit the following variables in \path{/etc/xen/xmdefconfig}:
+At minimum, you should edit the following 
+variables in \path{/etc/xen/xmdefconfig}:
 
 \begin{description}
 \item[kernel] Set this to the path of the kernel you compiled for use
@@ -530,7 +531,7 @@ from an unused range.
 
 If you don't have a \path{xmdefconfig} file, simply create your own 
 by copying one of the \path{/etc/xen/xmexample} files.
-\subsection{Starting the domain}
+\section{Starting the domain}
 
 The {\tt xm} tool provides a variety of commands for managing domains.
 Use the {\tt create} command to start new domains.  To start the
@@ -916,7 +917,7 @@ Once \xend is running, more sophisticated administration can be done
 using the xm tool (see Section~\ref{s:xm}) and the experimental
 Xensv web interface (see Section~\ref{s:xensv}).
 
-\section{The xm tool}
+\section{Xm (Command line interface)}
 \label{s:xm}
 
 The xm tool is the primary tool for managing Xen from the console.
@@ -1048,7 +1049,7 @@ scripting commands in configuration files.  An example of this is the
 
 %\part{Advanced Topics}
 
-\chapter{Network Configuration}
+\section{Network Configuration}
 
 For simple systems with a single ethernet interface with a simple
 configuration, the default installation should work `out of the
@@ -1059,7 +1060,7 @@ some special configuration.
 The purpose of this chapter is to describe the mechanisms provided by
 \xend to allow a flexible configuration for Xen's virtual networking.
 
-\section{Xen networking scripts}
+\subsection{Xen networking scripts}
 
 Xen's virtual networking is configured by 3 shell scripts.  These are
 called automatically by \xend when certain events occur, with arguments
@@ -1067,7 +1068,7 @@ to the scripts providing further contextual information.  These
 scripts are found by default in \path{/etc/xen}.  The names and
 locations of the scripts can be configured in \path{xend-config.sxp}.
 
-\subsection{\path{network}}
+\subsubsection{\path{network}}
 
 This script is called once when \xend is started and once when \xend is
 stopped.  Its job is to do any advance preparation required for the
@@ -1085,7 +1086,7 @@ When \xend exits, this script is called with the {\tt stop} argument,
 which causes it to delete the Xen bridge and remove {\tt eth0} from
 it, restoring the normal IP and routing configuration.
 
-\subsection{\path{vif-bridge}}
+\subsubsection{\path{vif-bridge}}
 
 This script is called for every domain virtual interface.  This should
 do things like configuring firewalling rules for that interface and
@@ -1095,9 +1096,9 @@ By default, this adds and removes VIFs on the default Xen bridge.
 This script can be customized to properly deal with more complicated
 bridging setups.
 
-\chapter{Scheduler Configuration}
+\section{Scheduler Configuration}
 
-\section{Scheduler selection}
+\subsection{Scheduler selection}
 
 Xen offers a boot time choice between multiple schedulers.  To select
 a scheduler, pass the boot parameter { \tt sched=sched\_name } to Xen,
@@ -1110,7 +1111,7 @@ use the scheduler most appropriate to their needs.  Currently, the BVT
 scheduler is the recommended choice, since the Atropos scheduler is
 not finished.
 
-\section{Borrowed Virtual Time}
+\subsection{Borrowed Virtual Time}
 
 {\tt sched=bvt } (the default) \\ 
 
@@ -1118,7 +1119,7 @@ BVT provides proportional fair shares of the CPU time.  It has been
 observed to penalise domains that block frequently (e.g. IO intensive
 domains), but this can be compensated by using warping. 
 
-\subsection{Global Parameters}
+\subsubsection{Global Parameters}
 
 \begin{description}
 \item[ctx\_allow]
@@ -1128,7 +1129,7 @@ domains), but this can be compensated by using warping.
   pre-empted.  This prevents thrashing of the CPU.
 \end{description}
 
-\subsection{Per-domain parameters}
+\subsubsection{Per-domain parameters}
 
 \begin{description}
 \item[mcuadv]
@@ -1145,7 +1146,7 @@ domains), but this can be compensated by using warping.
   run unwarped for before it can warp again
 \end{description}
 
-\section{Atropos}
+\subsection{Atropos}
 
 {\tt sched=atropos } \\
 
@@ -1167,7 +1168,7 @@ Note: don't overcommit the CPU when using Atropos (i.e. don't reserve
 more CPU than is available - the utilisation should be kept to
 slightly less than 100% in order to ensure predictable behaviour).
 
-\subsection{Per-domain parameters}
+\subsubsection{Per-domain parameters}
 
 \begin{description}
 \item[slice]
diff --git a/linux-2.6.9-xen-sparse/arch/xen/i386/kernel/ioport.c b/linux-2.6.9-xen-sparse/arch/xen/i386/kernel/ioport.c
index 4cae7675ae..89c1c7e38f 100644
--- a/linux-2.6.9-xen-sparse/arch/xen/i386/kernel/ioport.c
+++ b/linux-2.6.9-xen-sparse/arch/xen/i386/kernel/ioport.c
@@ -43,7 +43,9 @@ asmlinkage long sys_iopl(unsigned int new_io_pl)
 
 asmlinkage long sys_ioperm(unsigned long from, unsigned long num, int turn_on)
 {
+#if 0
 	printk(KERN_INFO "ioperm not fully supported - %s\n",
 		turn_on ? "set iopl to 3" : "ignore resource release");
+#endif
 	return turn_on ? sys_iopl(3) : 0;
 }