hi, these days I read IPMI.pdf, and found some typos. the attachment is
my patch for these typos based on IPMI.ltx from CVS.
hope helping.
Coly
Index: IPMI.ltx
===================================================================
RCS file: /cvsroot/openipmi/OpenIPMI/doc/IPMI.ltx,v
retrieving revision 1.36
diff -u -r1.36 IPMI.ltx
--- IPMI.ltx 5 Nov 2005 04:10:40 -0000 1.36
+++ IPMI.ltx 26 Dec 2005 10:16:11 -0000
@@ -232,7 +232,7 @@
Replacable Unit. This includes things like the manufacturer, the
serial number, date of manufacture, etc. A system generally has
information about the chassis and information about each field
-replacable unit it has. Field replacable units may include power
+replaceable unit it has. Field replaceable units may include power
supplies, DIMMs (memory devices), plug-in-boards, or a host of other
things.
@@ -423,9 +423,9 @@
sensors, how the sensors advertise those capabilties, and the things
that can be done to the sensors.
-You may register with an entity to be told when it's physical presence
+You may register with an entity to be told when its physical presence
in the system changes. Some devices (like power supplies) are
-field-replacable while the system is running; this type of device is
+field-replaceable while the system is running; this type of device is
called a hot-swappable \ac{FRU}. They may have sensors that monitor
them, but those sensors may not be active if the device is not
physically present in the system.
@@ -494,7 +494,7 @@
call when the operation completes. The functions passed around are
called ``callbacks''. You allocate and pass around chunks
of data to be passed to the handlers. And you register input handlers
-that get called when certain event occur. So the code runs in short
+that get called when certain event occurs. So the code runs in short
non-blocking sections, registers for the next operation, then returns
back to some invisible main loop that handles the details of scheduling
operations. This may seem more complicated than the previous example,
@@ -922,7 +922,7 @@
doing multi-threaded programming.
\end{itemize}
-This it is pretty standard in multi-threaded systems. \ac{HPI}, for
+This is pretty standard in multi-threaded systems. \ac{HPI}, for
instance has the same problem. If you have one thread waiting for
events from an \ac{HPI} domain, and another iterating the RDRs, or you
have two threads each doing operations on sensors, you have exactly
@@ -979,7 +979,7 @@
\paragraph{Device-Relative vs System-Relative Entities}
-In \acs{IPMI}, entities may be be either in a fixed place in the system, or
+In \acs{IPMI}, entities may be either in a fixed place in the system, or
they may be moved about the system. Fixed entities, are, well, in a
fixed location in the system. These are called system relative
entities. They have an entity instance less than 60h.
@@ -1195,7 +1195,7 @@
give it a handler to call when the reading has been fetched.
This is always done for things that OpenIPMI might have to send a
-message to do. If it a result of OpenIPMI's requirement to be able to
+message to do. If it is a result of OpenIPMI's requirement to be able to
work in non-threaded systems and still be responsive to operations
while waiting.
@@ -1489,7 +1489,7 @@
\chapter{IPMI Interfaces}
\label{ipmi-interfaces}
-\acs{IPMI} has a large number of interfaces for talking to to management
+\acs{IPMI} has a large number of interfaces for talking to management
controllers. They vary in performance and capability, but the same
messages work over the top of all of them. Generally, it does not
matter how you interface to an \acs{IPMI} system, the messages will work the
@@ -1503,7 +1503,7 @@
but once set up, the interfaces all work the same. The file shown in
Appendix \ref{ipmi-conn-h} defines the interface for connections.
-Note that not all operations are not available on all interfaces. \acs{LAN}
+Note that not all operations are available on all interfaces. \acs{LAN}
connections, for instance, cannot receive commands.
\section{System Interfaces}
@@ -1667,7 +1667,7 @@
req.msg.cmd = 0x2d; /* Get sensor reading */
req.msg.data = data;
req.msg.data_len = 1;
-data[1] = 10; /* Read sensor 10 */
+data[0] = 10; /* Read sensor 10 */
rv = ioctl(fd, IPMICTL_SEND_COMMAND, &req);
\end{verbatim}
@@ -1857,7 +1857,7 @@
printf("parms were: %d %d", tparms.retries, tparms.retry_time_ms);
tparms.retries = 0; /* No resends */
-tparms.retry_time = 1000; /* one second */
+tparms.retry_time_ms = 1000; /* one second */
rv = ioctl(fd, IPMICTL_SET_TIMING_PARMS_CMD, &tparms);
if (rv == -1)
error handling...
@@ -1946,7 +1946,7 @@
interface, and any other messaging interfaces will each have their own
channel on the \ac{MC}.
-Messages directly sent to the local management controller do nor
+Messages directly sent to the local management controller do not
require any type of channel information. When the user sends a
message out to another interface, it must specify the channel. This
is called ``bridging''. Channels also may have some type of
@@ -2081,7 +2081,7 @@
\end{tightdefs}
\end{tightdefs}}
\msgitem{5-7}{Vendor ID, used to specify the IANA number for the organization
- the defined the protocol. This should always be the IPMI IANA,
+ defined the protocol. This should always be the IPMI IANA,
which is 7154 (decimal), or F2H, 1Bh, and 00H for these bytes.}
\msgitem{8-9}{Auxiliary channel info.
@@ -2184,7 +2184,7 @@
\msgitem{1}{Channel information, bits are:
\begin{tightdefs}
\item[0-4] - Channel number
- \item[4-7] - Inferred privilege leel for the message. Table
+ \item[4-7] - Inferred privilege level for the message. Table
\ref{ipmi-priv-levels} describes the privilege levels.
If the message is received from a session-oriented channel,
@@ -3539,7 +3539,7 @@
interfaces, and whatnot. Channel Fh is used for the system interface.
If you specify channel Eh in a command, it will use the channel the
-command comes in on and any returned channel number will be the actual
+command comes in and any returned channel number will be the actual
channel number of the channel. This can be used to discover the
channel number of the current channel.
@@ -3936,7 +3936,7 @@
an \ac{NMI}.\\
\hline
Send Alert & 5 & Send an alert of some type, via an \acs{SNMP} trap,
- a page, or a modem dialin. Note that unlike the rest of the
+ a page, or a modem dialing. Note that unlike the rest of the
actions, this action will still be done if a higher priority
action is done. Alerts can also be prioritized via the
Alert Policy Table as described in section \ref{sec-pef-conf-parms}.\\
@@ -4314,7 +4314,7 @@
byte 3 of an alert policy table entry is set to 0, or indirectly
through parameter 12 of this table if that bit is one.
- The meanings of the values in this table are dependend on the
+ The meanings of the values in this table are dependent on the
alert type and channel.
For dial paging, this string will have a carraige return
@@ -4351,10 +4351,10 @@
The \ac{PEF} table is read and written as part of the PEF
Configuration table, parameter 6, but the contents are documented
-separately in table \ref{pef-table-entry}. When and event comes in,
+separately in table \ref{pef-table-entry}. When an event comes in,
it is compared against each filter in order. If a match occurs on
multiple filters, then the highest priority action is done and the
-rest except for alerts are ignored. After the operation is complete,
+rest except for alerts are ignored. After the operation is completed,
any alert operations are done by scanning the alert policy table in
order. The order of the alert policy table defines the priority of
the different alerts.
@@ -4991,7 +4991,7 @@
responses. A user sends a command to an \ac{MC}, and the \ac{MC}
returns a response. All commands have responses. Commands may
optionally have some data; the data depends on the command. The same
-goes for responses, except that all responses contain at least on data
+goes for responses, except that all responses contain at least one data
byte holding the completion code. Every response has a completion
code in the first byte.
@@ -5635,7 +5635,7 @@
\hline
31 & CABLE \_INTERCONNECT & A cable routing device.\\
\hline
-32 & MEMORY\_DEVICE & A replacable memory device, like a DIMM. This should
+32 & MEMORY\_DEVICE & A replaceable memory device, like a DIMM. This should
not be used for individual memory chips, but for the board that
holds the memory chips.\\
\hline
@@ -5680,7 +5680,7 @@
\section{Discovering Entities}
In OpenIPMI, the entities in a system are part of the domain. As
-OpenIPMI scans \acs{SDR}s it find, it will create the entities
+OpenIPMI scans \acs{SDR}s it finds, it will create the entities
referenced in those SDRs. The user can discover the entities in a
domain in two ways: iterating or registering callbacks.
@@ -5831,7 +5831,7 @@
Entities come in four different flavors:
\begin{description}
\item[\acs{MC}] - An \acs{MC} entity is for a \acs{MC}.
-\item[FRU] - This is for field-replacable entities that are
+\item[FRU] - This is for field-replaceable entities that are
not \acs{MC}s.
\item[Generic] - Some other device on the \acs{IPMB} bus.
\item[Unknown] - This is for entities that do not have an \acs{SDR}
@@ -6048,7 +6048,7 @@
int allocated = 0;
if (length == 0)
- name = ``empty name'';
+ name = "empty name";
else {
name = malloc(length+1);
if (!name) {
@@ -6121,7 +6121,7 @@
int allocated = 0;
if (length == 0)
- name = ``empty name'';
+ name = "empty name";
else {
name = malloc(length+1);
if (!name) {
@@ -6401,7 +6401,7 @@
const char **name,
ipmi_fru_node_t **node);
\end{verbatim}
-This function returns the name of the FRU (either ``SPD FRU'' or
+This function returns the name of the FRU, either ``SPD FRU'' or
``standard FRU'' or some other OEM name and the actual root node. If
either of these is NULL, it will be ignored. The root node is always
a record node.
@@ -6419,7 +6419,7 @@
unsigned int *data_len,
ipmi_fru_node_t **sub_node);
\end{verbatim}
-The index is a contiguous range from zero that holds every field. So
+The index is a continuous range from zero that holds every field. So
you can iterate through the indexes from 0 until it returns EINVAL to
find all the fields. If a field is not present in the \acs{FRU} data,
this will return \verb=ENOSYS=. Note that later fields may still be
@@ -6603,7 +6603,7 @@
unsigned int area,
unsigned int *used_length);
\end{verbatim}
-The \verb=used_length= variable tells how much of teh length of the
+The \verb=used_length= variable tells how much of the length of the
FRU is actually used. Note that area offsets and length must be
multiples of 8.
@@ -6833,7 +6833,7 @@
can only do so much.
So starting at the beginning, the first thing you need to know about a
-sensor is it's type. You fetch that with the function:
+sensor is its type. You fetch that with the function:
\begin{verbatim}
int ipmi_sensor_get_event_reading_type(ipmi_sensor_t *sensor);
\end{verbatim}
@@ -7333,7 +7333,7 @@
\subsubsection{Sensor Name}
The SDR contains a string giving a name for the sensor. This is
-useful for printing out sensorinformation. The functions to get
+useful for printing out sensor information. The functions to get
this are:
\begin{verbatim}
int ipmi_sensor_get_id_length(ipmi_sensor_t *sensor);
@@ -8701,7 +8701,7 @@
\section{\acs{IPMI} strings}
\label{appendix-ipmi-strings}
-IPMI uses a special format for storing strings. It allows data two be
+IPMI uses a special format for storing strings. It allows data to be
stored in four different formats. The first byte describes the type
and length; the format is:
\begin{tightdefs}
