Linux Kernel 2.6 Documentation:
/usr/src/linux/Documentation/IPMI.txt
IPMI.txt
Linux でハードウェアの IPMI 情報にアクセスする方法
[プレインテキスト版]
- 原著作者: Corey Minyard <minyard at mvista dot com> <minyard at acm dot org>
- 翻訳者: Akira YOSHIYAMA <yosshy at debian dot or dot jp>
- バージョン: 2.6.10
- 翻訳日時: 2005/03/04
The Linux IPMI Driver
---------------------
Corey Minyard
<minyard@mvista.com>
<minyard@acm.org>
The Intelligent Platform Management Interface, or IPMI, is a
standard for controlling intelligent devices that monitor a system.
It provides for dynamic discovery of sensors in the system and the
ability to monitor the sensors and be informed when the sensor's
values change or go outside certain boundaries. It also has a
standardized database for field-replacable units (FRUs) and a watchdog
timer.
Intelligent Platform Management Interface (IPMI) はシステムを監視する
高度なデバイス制御の為の標準です。これはシステム中のセンサーの動的検出
とセンサーのモニタリング機能を提供し、センサーの値が変化した時やある境
界値を越えた時に通知します。また、IPMI は現地置換可能ユニット(FRU) と
ウォッチドッグタイマに関する標準化されたデータベースを持ちます。
(訳注：ウォッチドッグタイマ…システムのハングアップを検知する為のデバ
イス)
To use this, you need an interface to an IPMI controller in your
system (called a Baseboard Management Controller, or BMC) and
management software that can use the IPMI system.
IPMI を使用する為には、システム中の IPMI コントローラ (Baseboard
Management Controller または BMC と言います) へのインターフェースと、
IPMI システムを使用できる管理ソフトウェアが必要です。
This document describes how to use the IPMI driver for Linux. If you
are not familiar with IPMI itself, see the web site at
http://www.intel.com/design/servers/ipmi/index.htm. IPMI is a big
subject and I can't cover it all here.
このドキュメントは Linux 用 IPMI ドライバを使用する方法を説明します。
もしあなたが IPMI 自体をよく知らない場合は、
http://www.intel.com/design/servers/ipmi/index.htm の Web サイトを参照
してください。IPMI は大きなテーマであり、ここで全てをカバーする事は出
来ません。
Configuration
設定
-------------
The LinuxIPMI driver is modular, which means you have to pick several
things to have it work right depending on your hardware. Most of
these are available in the 'Character Devices' menu.
LinuxIPMI ドライバはモジュール化(分割)されています。これは、IPMI ドラ
イバを正しく機能させる為に、ハードウェアに合わせて幾つかのモジュールを
選ばないといけない事を意味します。これらの物はほとんど、'Character
Devices' メニュー中で選択可能です。
No matter what, you must pick 'IPMI top-level message handler' to use
IPMI. What you do beyond that depends on your needs and hardware.
とりあえず、IPMI を使用するために 'IPMI top-level message handler' を
選択しなければなりません。その後に選択するものはあなたのニーズとハード
ウェアに依存します。
The message handler does not provide any user-level interfaces.
Kernel code (like the watchdog) can still use it. If you need access
from userland, you need to select 'Device interface for IPMI' if you
want access through a device driver. Another interface is also
available, you may select 'IPMI sockets' in the 'Networking Support'
main menu. This provides a socket interface to IPMI. You may select
both of these at the same time, they will both work together.
メッセージハンドラはユーザレベルのインターフェースを一切提供しません。
それでも、ウォッチドッグのようなカーネル内コードはこれを使用できます。
ユーザランドからのアクセスが必要な場合、デバイスドライバ経由でアクセス
したいのであれば、'Device interface for IPMI' を選択する必要があります。
他のインターフェースも利用できます。'IPMI sockets' in the 'Networking
Support' メインメニューを選択して下さい。これは IPMI に対するソケット
インターフェースを提供します。両方を同時に選択する事も出来ますし、同時
に両方とも機能します。
(訳注：ユーザランド＝カーネルによって保護管理された、プロセスが実行さ
れる世界を指します。対比語にカーネルランドがあり、カーネル自体が実行さ
れる世界を指します。同義語にそれぞれ、ユーザスペースやユーザモード、カー
ネルスペースやカーネルモードがあります)
The driver interface depends on your hardware. If you have a board
with a standard interface (These will generally be either "KCS",
"SMIC", or "BT", consult your hardware manual), choose the 'IPMI SI
handler' option. A driver also exists for direct I2C access to the
IPMI management controller. Some boards support this, but it is
unknown if it will work on every board. For this, choose 'IPMI SMBus
handler', but be ready to try to do some figuring to see if it will
work.
ドライバインターフェースはハードウェアに依存します。標準インターフェー
ス (これらは一般に、KCS, SMIC, BT のいずれかです。ハードウェアのマニュ
アルを参照して下さい) 付きのボードがある場合は、'IPMI SI handler' オプ
ションを選択して下さい。IPMI 管理コントローラへの I2C 直接アクセスの為
のドライバも存在します。幾つかのボードはこれをサポートしますが、全ての
ボードでこのドライバが機能するかどうかは分かりません。これには、'
IPMISMBus handler' を選択します。しかし、このドライバが動くかどうか調
べる為には、いろいろと試してみる覚悟をして下さい。
There is also a KCS-only driver interface supplied, but it is
depracated in favor of the SI interface.
KCS のみのドライバインターフェースも提供されていますが、SI インターフェー
スがあるため推奨されません。
You should generally enable ACPI on your system, as systems with IPMI
should have ACPI tables describing them.
一般に、IPMI 付システムは IPMI を記述した ACPI テーブルを持っている筈
なので、システムの ACPI を有効にすべきです。
If you have a standard interface and the board manufacturer has done
their job correctly, the IPMI controller should be automatically
detect (via ACPI or SMBIOS tables) and should just work. Sadly, many
boards do not have this information. The driver attempts standard
defaults, but they may not work. If you fall into this situation, you
need to read the section below named 'The SI Driver' on how to
hand-configure your system.
標準インターフェースがあり、ボード製造者がちゃんとした仕事をしたのであ
れば、ACPI または SMBIOS テーブルを介して IPMI コントローラは自動的に
検知され、ちゃんと機能するはずです。悲しいことに、多くのボードがこの情
報を持っていません。このドライバは標準値を試みますが、動作しないかもし
れません。この状態に陥った場合、システムを手動で設定する方法について、
下記の「SI ドライバ」の章を読む必要があります。
IPMI defines a standard watchdog timer. You can enable this with the
'IPMI Watchdog Timer' config option. If you compile the driver into
the kernel, then via a kernel command-line option you can have the
watchdog timer start as soon as it intitializes. It also have a lot
of other options, see the 'Watchdog' section below for more details.
Note that you can also have the watchdog continue to run if it is
closed (by default it is disabled on close). Go into the 'Watchdog
Cards' menu, enable 'Watchdog Timer Support', and enable the option
'Disable watchdog shutdown on close'.
IPMI は標準ウォッチドッグタイマを定義します。'IPMI ウォッチドッグタイ
マ' 設定オプションでこの機能を有効にできます。このドライバをカーネルに
組み込んだ場合、カーネルコマンドラインオプション経由で、ドライバが初期
化され次第ウォッチドッグタイマを有効にする事ができます。他にも多数のオ
プションがあります。詳細は下記の「ウォッチドッグ」の章を参照して下さい。
ウォッチドッグタイマは close された後も有効にする事ができる事に注意し
てください (デフォルトでは close された時に無効化されます)。'Watchdog
Cards' メニューに行き、'Watchdog Timer Support' を有効にして、'Disable
watchdog shutdown on close' オプションを選択して下さい。
Basic Design
基本デザイン
------------
The Linux IPMI driver is designed to be very modular and flexible, you
only need to take the pieces you need and you can use it in many
different ways. Because of that, it's broken into many chunks of
code. These chunks are:
Linux IPMI ドライバは高度にモジュール化・柔軟化されるようデザインされ
ています。必要な部分だけ選べば良いですし、幾つかの異なる方法で使用する
事ができます。このため、IPMI ドライバは多数のモジュールに分割されてい
ます。これらは下記の通りです：
ipmi_msghandler - This is the central piece of software for the IPMI
system. It handles all messages, message timing, and responses. The
IPMI users tie into this, and the IPMI physical interfaces (called
System Management Interfaces, or SMIs) also tie in here. This
provides the kernelland interface for IPMI, but does not provide an
interface for use by application processes.
ipmi_msghandler - これが IPMI システム用ソフトウェアの中核モジュールで
す。これは全てのメッセージ、メッセージタイミング、応答を扱います。IPMI
ユーザはこのドライバに結びつけられ、IPMI 物理インターフェース (System
Management Interface または SMI と呼ばれています) もこのモジュールに結
びつけられます。このモジュールは IPMI 用のカーネルランドインターフェー
スを提供しますが、アプリケーションプロセスによって使用されるインター
フェースは提供しません。
ipmi_devintf - This provides a userland IOCTL interface for the IPMI
driver, each open file for this device ties in to the message handler
as an IPMI user.
ipmi_devintf - これはIPMI ドライバに対するユーザランドの IOCTL インター
フェースを提供します。このドライバへの open されたファイルはそれぞれ、
IPMI ユーザとしてメッセージハンドラに結びつけられます。
ipmi_si - A driver for various system interfaces. This supports
KCS, SMIC, and may support BT in the future. Unless you have your own
custom interface, you probably need to use this.
ipmi_si - 様々なシステムインターフェースの為のドライバを提供します。こ
れは KCS と SMIC をサポートしており、将来 BT をサポートするかもしれま
せん。独自に専用インターフェースを用意したのでない限り、多分このドライ
バが必要になるでしょう。
ipmi_smb - A driver for accessing BMCs on the SMBus. It uses the
I2C kernel driver's SMBus interfaces to send and receive IPMI messages
over the SMBus.
ipmi_smb - SMBus 上の BMC にアクセスする為のドライバです。このドライバ
は、SMbus 上で IPMI メッセージを送受信する為に、I2C カーネルドライバの
SMBus インターフェースを使用します。
af_ipmi - A network socket interface to IPMI. This doesn't take up
a character device in your system.
af_ipmi - IPMI へのネットワークソケットインターフェースです。このドラ
イバはシステムのキャラクターデバイスを使用しません。
Note that the KCS-only interface ahs been removed.
KCS のみのインターフェースは削除された事に注意して下さい。
Much documentation for the interface is in the include files. The
IPMI include files are:
このインターフェースのほとんどのドキュメントは include ファイル中にあ
ります。IPMI include ファイルは：
net/af_ipmi.h - Contains the socket interface.
net/af_ipmi.h - ソケットインターフェースを含みます。
linux/ipmi.h - Contains the user interface and IOCTL interface for IPMI.
linux/ipmi.h - IPMI 用ユーザインターフェースと IOCTL インターフェース
を含みます。
linux/ipmi_smi.h - Contains the interface for system management interfaces
(things that interface to IPMI controllers) to use.
linux/ipmi_smi.h - SMI (IPMI コントローラへのインターフェース) を使用
する為のインターフェースを含みます。
linux/ipmi_msgdefs.h - General definitions for base IPMI messaging.
linux/ipmi_msgdefs.h - 基本 IPMI メッセージの為の一般的な定義
Addressing
アドレッシング
----------
The IPMI addressing works much like IP addresses, you have an overlay
to handle the different address types. The overlay is:
IPMI アドレッシングは IP アドレスのように動作し、異なるアドレスタイプ
を扱う為のオーバレイがあります。オーバレイは下記の通りです：
struct ipmi_addr
{
int addr_type;
short channel;
char data[IPMI_MAX_ADDR_SIZE];
};
The addr_type determines what the address really is. The driver
currently understands two different types of addresses.
addr_type はアドレスが実際何であるのかを決定します。現在、ドライバは2
種類の異なるアドレッシングを理解します。
"System Interface" addresses are defined as:
"System Interface" アドレッシングは次のように定義されます：
struct ipmi_system_interface_addr
{
int addr_type;
short channel;
};
and the type is IPMI_SYSTEM_INTERFACE_ADDR_TYPE. This is used for talking
straight to the BMC on the current card. The channel must be
IPMI_BMC_CHANNEL.
このタイプは IPMI_SYSTEM_INTERFACE_ADDR_TYPE です。このタイプは現在の
カード上の BMC と直接会話する為に使用されます。このチャンネルは
IPMI_BMC_CHANNEL でなければなりません。
Messages that are destined to go out on the IPMB bus use the
IPMI_IPMB_ADDR_TYPE address type. The format is
IPMB バス上で外に出ていくよう指定されたメッセージは
IPMI_IPMB_ADDR_TYPE アドレッシングタイプを使用します。このフォーマット
は以下の通りです。
struct ipmi_ipmb_addr
{
int addr_type;
short channel;
unsigned char slave_addr;
unsigned char lun;
};
The "channel" here is generally zero, but some devices support more
than one channel, it corresponds to the channel as defined in the IPMI
spec.
ここでの "channel" とは一般に0ですが、幾つかのデバイスは1つ以上のチャ
ンネルをサポートします。これは IPMI 仕様にて定義されたチャンネルに適合
しています。
Messages
メッセージ
--------
Messages are defined as:
struct ipmi_msg
{
unsigned char netfn;
unsigned char lun;
unsigned char cmd;
unsigned char *data;
int data_len;
};
The driver takes care of adding/stripping the header information. The
data portion is just the data to be send (do NOT put addressing info
here) or the response. Note that the completion code of a response is
the first item in "data", it is not stripped out because that is how
all the messages are defined in the spec (and thus makes counting the
offsets a little easier :-).
このドライバはヘッダ情報の追加/削除の面倒をみます。data 部は送付/応答
されるデータそのものです (ここにアドレッシング情報を置かないでください)。
応答の完了コードは "data" の最初のアイテムであり、仕様上、全メッセージ
がそのように定義されているので、このコードは分割されない事に注意して下
さい (そしてこれは、オフセットのカウントをちょっとだけ楽にします :-)。
When using the IOCTL interface from userland, you must provide a block
of data for "data", fill it, and set data_len to the length of the
block of data, even when receiving messages. Otherwise the driver
will have no place to put the message.
ユーザランドから IOCTL インターフェースを使用する際、メッセージの受信
であっても、"data" 用のデータブロックを提供し、データを埋めて、
data_len にデータブロックの長さをセットしなければなりません。さもなけ
れば、このドライバはメッセージを置く場所がない事になります。
Messages coming up from the message handler in kernelland will come in
as:
カーネルランド中でメッセージハンドラから得られるメッセージは下記のよう
になります：
struct ipmi_recv_msg
{
struct list_head link;
/* The type of message as defined in the "Receive Types"
defines above. */
/* メッセージのタイプは下記の "Receive Types" 定義で定義されま
す。*/
int recv_type;
ipmi_user_t *user;
struct ipmi_addr addr;
long msgid;
struct ipmi_msg msg;
/* Call this when done with the message. It will presumably free
the message and do any other necessary cleanup. */
/* メッセージが行われた際にこの関数が呼ばれます。多分、この関
数はメッセージを開放し、他の必要なクリーンアップを行います
*/
void (*done)(struct ipmi_recv_msg *msg);
/* Place-holder for the data, don't make any assumptions about
the size or existence of this, since it may change. */
/* データの為の場所取りです。これは変化するかもしれないので、
サイズやその存在を仮定しないでください */
unsigned char msg_data[IPMI_MAX_MSG_LENGTH];
};
You should look at the receive type and handle the message
appropriately.
受信タイプを見て、メッセージを適切に処理すべきでしょう。
The Upper Layer Interface (Message Handler)
上位レイヤインターフェース (メッセージハンドラ)
-------------------------------------------
The upper layer of the interface provides the users with a consistent
view of the IPMI interfaces. It allows multiple SMI interfaces to be
addressed (because some boards actually have multiple BMCs on them)
and the user should not have to care what type of SMI is below them.
インターフェースの上位レイヤは、IPMI インターフェースの一貫性のあるビュー
をユーザに提供します。また、これは複数の SMI インターフェースがアドレッ
シングされる事を許可します (現存する幾つかのボードは複数の BMC を持つ
ため)。このインターフェースを利用するユーザは、何の SMI タイプがその下
にあるかを意識すべきではありません。
Creating the User
ユーザの作成
To user the message handler, you must first create a user using
ipmi_create_user. The interface number specifies which SMI you want
to connect to, and you must supply callback functions to be called
when data comes in. The callback function can run at interrupt level,
so be careful using the callbacks. This also allows to you pass in a
piece of data, the handler_data, that will be passed back to you on
all calls.
メッセージハンドラのユーザ用に、まず ipmi_create_user を使用してユーザ
を作らなければなりません。インターフェース番号はあなたが接続したい SMI
がどれかを特定します。データが戻ってきた際に呼ばれるコールバック関数を
提供しなければなりません。コールバック関数は割り込みレベルで実行可能な
ので、コールバックの使用には注意すべきです。これはまた、全てのコールに
おいて返されるデータ片 (handler_data) を渡す事を許可します。
Once you are done, call ipmi_destroy_user() to get rid of the user.
一旦完了すれば、ipmi_destroy_user() でユーザを削除できます。
>From userland, opening the device automatically creates a user, and
closing the device automatically destroys the user.
ユーザランドからは、デバイスを開く事で自動的にユーザが作成され、デバイ
スがクローズされる事で自動的にユーザが削除されます。
Messaging
メッセージング
To send a message from kernel-land, the ipmi_request() call does
pretty much all message handling. Most of the parameter are
self-explanatory. However, it takes a "msgid" parameter. This is NOT
the sequence number of messages. It is simply a long value that is
passed back when the response for the message is returned. You may
use it for anything you like.
カーネルランドからメッセージを送る場合、ipmi_request() コールがあらゆ
るメッセージハンドリングを行います。ほとんどのパラメータは自明です。し
かしながら、msgid パラメータには説明が必要でしょう。これはメッセージの
シーケンス番号ではありません。これは単に、応答メッセージが戻されてきた
際に返される long 型の値です。この値は好きに使ってもらって構いません。
Responses come back in the function pointed to by the ipmi_recv_hndl
field of the "handler" that you passed in to ipmi_create_user().
Remember again, these may be running at interrupt level. Remember to
look at the receive type, too.
ipmi_create_user() へ渡された handler の ipmi_recv_hndl フィールドで指
定された関数中に応答が戻ってきます。繰り返しますが、この関数は割り込み
レベルで動作する可能性がある事に注意してください。受信タイプを見る事も
忘れないでください。
>From userland, you fill out an ipmi_req_t structure and use the
IPMICTL_SEND_COMMAND ioctl. For incoming stuff, you can use select()
or poll() to wait for messages to come in. However, you cannot use
read() to get them, you must call the IPMICTL_RECEIVE_MSG with the
ipmi_recv_t structure to actually get the message. Remember that you
must supply a pointer to a block of data in the msg.data field, and
you must fill in the msg.data_len field with the size of the data.
This gives the receiver a place to actually put the message.
ユーザランドからは、ipmi_req_t 構造体を埋めて IPMICTL_SEND_COMMAND
ioctl を使用して下さい。入ってくるものの為には、select() または poll()
を使用してメッセージの入力を待つことが出来ます。しかしながら、そのメッ
セージを得る為に read() を使う事は出来ません。実際にメッセージを得る為
には ipmi_recv_t 構造体付きで IPMICTL_RECEIVE_MSG をコールしなければな
りません。msg.data フィールド中でデータブロックへのポインタを提供しな
ければならない事と、msg.data_len フィールドにデータのサイズを入れてお
かないといけない事を覚えておいてください。これはレシーバーに対して実際
にメッセージを置く場所を与えます。
If the message cannot fit into the data you provide, you will get an
EMSGSIZE error and the driver will leave the data in the receive
queue. If you want to get it and have it truncate the message, us
the IPMICTL_RECEIVE_MSG_TRUNC ioctl.
提供されたデータにメッセージが収まらなかった場合、EMSGSIZE エラーが返
され、ドライバは受信キュー中にデータを残すでしょう。もしエラーを受け取っ
て、エラーによってメッセージを切り詰めたいのであれば、
IPMICTL_RECEIVE_MSG_TRUNC ioctl を使用して下さい。
When you send a command (which is defined by the lowest-order bit of
the netfn per the IPMI spec) on the IPMB bus, the driver will
automatically assign the sequence number to the command and save the
command. If the response is not receive in the IPMI-specified 5
seconds, it will generate a response automatically saying the command
timed out. If an unsolicited response comes in (if it was after 5
seconds, for instance), that response will be ignored.
(IPMI 仕様毎に netfn の最下位ビットで定義された) コマンドを送った際、
このドライバはコマンドにシーケンス番号を自動的に割り当て、コマンドを保
存します。応答が IPMI 仕様で定義された5秒を過ぎても受信されなかった場
合、コマンドがタイムアウトした事を意味する応答を自動的に生成します。意
図しない応答が返された時 (例えば5秒以上後の場合)、この応答は無視されま
す。
In kernelland, after you receive a message and are done with it, you
MUST call ipmi_free_recv_msg() on it, or you will leak messages. Note
that you should NEVER mess with the "done" field of a message, that is
required to properly clean up the message.
カーネルランドでは、メッセージを受信してそれで完了してしまった後、その
上で ipmi_free_recv_msg() をコールしなければなりません。さもなくば、メッ
セージを取りこぼす事になります。メッセージの "done" フィールドを決して
滅茶苦茶にしてはならない事に注意して下さい。これはメッセージを適切にク
リーンアップする為に必要です。
Note that when sending, there is an ipmi_request_supply_msgs() call
that lets you supply the smi and receive message. This is useful for
pieces of code that need to work even if the system is out of buffers
(the watchdog timer uses this, for instance). You supply your own
buffer and own free routines. This is not recommended for normal use,
though, since it is tricky to manage your own buffers.
送信する際、smi を提供し、メッセージを受信する
ipmi_request_supply_msg() コールがある事に注意して下さい。これはシステ
ムがバッファ不足になった場合でも動く必要があるコードの場所として便利で
す (例えばウォッチドッグタイマはこれを使用しています)。独自のバッファ
や自由なルーチンを提供する事も出来ます。もっとも、独自のバッファを管理
するのは細工が必要なので、この関数は通常の使用では推奨されません。
Events and Incoming Commands
イベントと入力コマンド
The driver takes care of polling for IPMI events and receiving
commands (commands are messages that are not responses, they are
commands that other things on the IPMB bus have sent you). To receive
these, you must register for them, they will not automatically be sent
to you.
このドライバはIPMI イベントのポーリングとコマンドの受信の面倒をみます
(コマンドは応答のないメッセージで、IPMB バス上の他のデバイスがユーザに
対して送信したものです)。コマンドを受信するためにはコマンドを登録しな
ければなりません。コマンドは自動的には送信されません。
To receive events, you must call ipmi_set_gets_events() and set the
"val" to non-zero. Any events that have been received by the driver
since startup will immediately be delivered to the first user that
registers for events. After that, if multiple users are registered
for events, they will all receive all events that come in.
イベントを受信するためには、ipmi_set_gets_events() コールを発行して
"val" を0以外にセットしなければなりません。ドライバの初期化以降、ドラ
イバによって受信された全てのイベントはイベントを登録した最初のユーザへ
即時に配信されます。この後、複数のユーザがイベントを登録していた場合は、
全ユーザが入力された全てのイベントを受信する事になります。
For receiving commands, you have to individually register commands you
want to receive. Call ipmi_register_for_cmd() and supply the netfn
and command name for each command you want to receive. Only one user
may be registered for each netfn/cmd, but different users may register
for different commands.
コマンドを受信するためには、受信したいコマンドを個別に登録する必要があ
ります。ipmi_register_for_cmd() をコールして、受信したいコマンドそれぞ
れに対して netfn とコマンド名を提供してください。各 netfn/cmd に対して
唯一のユーザが登録可能ですが、別のユーザが別のコマンドを登録する事はで
きます。
>From userland, equivalent IOCTLs are provided to do these functions.
ユーザランドからは、これらの機能を実行するための同等の IOCTL が提供さ
れています。
The Lower Layer (SMI) Interface
低位レイヤー (SMI) インターフェース
-------------------------------
As mentioned before, multiple SMI interfaces may be registered to the
message handler, each of these is assigned an interface number when
they register with the message handler. They are generally assigned
in the order they register, although if an SMI unregisters and then
another one registers, all bets are off.
先述の通り、メッセージハンドラには複数の SMI インターフェースを登録す
る事が出来ます。これらはそれぞれ、メッセージハンドラに登録される際にイ
ンターフェース番号が割り当てられます。番号は一般に登録順に割り当てられ
ますが、SMI が登録抹消されて他のものが登録された場合はその限りではあり
ません。
The ipmi_smi.h defines the interface for management interfaces, see
that for more details.
ipmi_smi.h は管理インターフェースの為のインターフェースを定義します。
詳細はこのファイルを参照して下さい。
The SI Driver
SI ドライバ
-------------
The SI driver allows up to 4 KCS or SMIC interfaces to be configured
in the system. By default, scan the ACPI tables for interfaces, and
if it doesn't find any the driver will attempt to register one KCS
interface at the spec-specified I/O port 0xca2 without interrupts.
You can change this at module load time (for a module) with:
SI ドライバでは KCS または SMIC インターフェースを最大4つまでシステム
中で設定可能です。デフォルトでは、これらのインターフェースを探す為に
ACPI テーブルをスキャンし、何も見つけられなかった場合ば、ドライバは
IPMI 仕様で規定された I/O ポート0xca2 にある1つの KCS インターフェー
スを割り込みなしで登録しようとします。
You can change this at module load time (for a module) with:
(モジュールの場合) モジュールのロード時にこのインターフェースを変更す
る事ができます：
modprobe ipmi_si.o type=<type1>,<type2>....
ports=<port1>,<port2>... addrs=<addr1>,<addr2>...
irqs=<irq1>,<irq2>... trydefaults=[0|1]
regspacings=<sp1>,<sp2>,... regsizes=<size1>,<size2>,...
regshifts=<shift1>,<shift2>,...
Each of these except si_trydefaults is a list, the first item for the
first interface, second item for the second interface, etc.
si_trydefaults を除くこれらパラメータはそれぞれリストであり、最初のイ
ンターフェースには最初の項目、2つめのインターフェースには2つめの項目、
となります。
The si_type may be either "kcs", "smic", or "bt". If you leave it blank, it
defaults to "kcs".
si_type は "kcs", "smic", "bt" のいずれかです。空白の場合は、デフォル
トで "kcs" になります。
If you specify si_addrs as non-zero for an interface, the driver will
use the memory address given as the address of the device. This
overrides si_ports.
インターフェースの si_addrs を0以外で指定した場合は、ドライバはデバイ
スのアドレスとして与えられたメモリアドレスを使用します。これは
si_ports を上書きします。
If you specify si_ports as non-zero for an interface, the driver will
use the I/O port given as the device address.
インターフェースの si_ports を0以外で指定した場合は、ドライバはデバイ
スアドレスとして与えられたI/O ポートを使用します。
If you specify si_irqs as non-zero for an interface, the driver will
attempt to use the given interrupt for the device.
インターフェースの si_irqs を0以外で指定した場合は、ドライバはこのデ
バイス用に与えられた割り込みを使用しようとします。
si_trydefaults sets whether the standard IPMI interface at 0xca2 and
any interfaces specified by ACPE are tried. By default, the driver
tries it, set this value to zero to turn this off.
si_trydefaults は 0xca2 にある標準 IPMI インターフェースと ACPE で指定
されたインターフェースを試すかどうかを設定します。デフォルトではドライ
バはこれらのインターフェースを試みますが、この値を0にすると試行しなく
なります。
The next three parameters have to do with register layout. The
registers used by the interfaces may not appear at successive
locations and they may not be in 8-bit registers. These parameters
allow the layout of the data in the registers to be more precisely
specified.
次の3つのパラメータはレジスタ配置に合わせる必要があります。インター
フェースによって使用されるレジスタは連続した場所に現れるとは限らず、ま
た8ビットレジスタでないかも知れません。これらのパラメータは、レジスタ
中のデータのレイアウトより正確に指定する為に許容されます。
The regspacings parameter give the number of bytes between successive
register start addresses. For instance, if the regspacing is set to 4
and the start address is 0xca2, then the address for the second
register would be 0xca6. This defaults to 1.
regspacings パラメータは連続したレジスタの開始アドレス群のバイト数を与
えます。例えば、regspacings が4、開始アドレスが 0xca2 の場合、2番目
のレジスタのアドレスは 0xca6 になります。デフォルトは1です。
The regsizes parameter gives the size of a register, in bytes. The
data used by IPMI is 8-bits wide, but it may be inside a larger
register. This parameter allows the read and write type to specified.
It may be 1, 2, 4, or 8. The default is 1.
regsies パラメータはレジスタのサイズをバイト単位で指定します。IPMI で
使用されるデータは8ビット幅ですが、より大きな幅のレジスタ中にあるかも
しれません。このパラメータは read/write タイプを指定可能にします。この
値は 1,2,4,8 のどれかです。デフォルトは1です。
Since the register size may be larger than 32 bits, the IPMI data may not
be in the lower 8 bits. The regshifts parameter give the amount to shift
the data to get to the actual IPMI data.
レジスタサイズは 32bit より大きいかも知れないので、IPMI データは低位
8bit であるとは限りません。regshifts パラメータは実際の IPMI データを
得る為のデータのシフト量を指定します。
When compiled into the kernel, the addresses can be specified on the
kernel command line as:
ドライバをカーネルに組み込んだ場合、アドレスはカーネルコマンドラインパ
ラメータで下記のように指定する事ができます：
ipmi_si.type=<type1>,<type2>...
ipmi_si.ports=<port1>,<port2>... ipmi_si.addrs=<addr1>,<addr2>...
ipmi_si.irqs=<irq1>,<irq2>... ipmi_si.trydefaults=[0|1]
ipmi_si.regspacings=<sp1>,<sp2>,...
ipmi_si.regsizes=<size1>,<size2>,...
ipmi_si.regshifts=<shift1>,<shift2>,...
It works the same as the module parameters of the same names.
これは同じ名称のモジュールパラメータと同様に機能します。
By default, the driver will attempt to detect any device specified by
ACPI, and if none of those then a KCS device at the spec-specified
0xca2. If you want to turn this off, set the "trydefaults" option to
false.
デフォルトでは、ドライバは ACPI で指定されたデバイスを検知しようとし、
見つからなかった場合は仕様で 0xca2 に規定された KCS デバイスの検知を試
みます。この自動検知を off にしたい場合は、"trydefaults" オプションを
0に設定してください。
If you have high-res timers compiled into the kernel, the driver will
use them to provide much better performance. Note that if you do not
have high-res timers enabled in the kernel and you don't have
interrupts enabled, the driver will run VERY slowly. Don't blame me,
these interfaces suck.
高精度タイマーをカーネルに組み込んだ場合は、ずっと良いパフォーマンスを
提供する為にドライバはこのタイマーを使用します。カーネル中で高精度タイ
マーを有効にせず、また割り込みを有効にしなかった場合、ドライバは非常に
低速で動作する事に注意してください。私を責めないでください。これらのイ
ンターフェースが腐っているせいです。
The SMBus Driver
SMBus ドライバ
----------------
The SMBus driver allows up to 4 SMBus devices to be configured in the
system. By default, the driver will register any SMBus interfaces it finds
in the I2C address range of 0x20 to 0x4f on any adapter. You can change this
at module load time (for a module) with:
SMBus ドライバは SMBus デバイスを1システムで最大4つまで設定可能です。
デフォルトでは、このドライバは各アダプタ上の I2C アドレス範囲 0x20〜
0x4f 中で検出された SMBus インターフェースを登録します。(モジュールの
場合) モジュールロード時にこの設定を変更する事ができます：
modprobe ipmi_smb.o
addr=<adapter1>,<i2caddr1>[,<adapter2>,<i2caddr2>[,...]]
dbg=<flags1>,<flags2>...
[defaultprobe=0] [dbg_probe=1]
The addresses are specified in pairs, the first is the adapter ID and the
second is the I2C address on that adapter.
このアドレスはペアで指定されます。最初のものはアダプタ ID で、2つめの
ものはそのアダプタの I2C アドレスです。
The debug flags are bit flags for each BMC found, they are:
IPMI messages: 1, driver state: 2, timing: 4, I2C probe: 8
デバッグフラグは各 BMC で検出されるもののビットフラグです。これらは
IPMI メッセージ：1、ドライバ状態：2、タイミング：4、I2C プローブ：
8です。
Setting smb_defaultprobe to zero disabled the default probing of SMBus
interfaces at address range 0x20 to 0x4f. This means that only the
BMCs specified on the smb_addr line will be detected.
smb_defaultprobe に0を設定すると、標準動作であるアドレス範囲 0x20〜
0x4f の SMBus インターフェースの検出を無効化します。これは smb_addr ラ
インで指定された BMC のみ検知される事を意味します。
Setting smb_dbg_probe to 1 will enable debugging of the probing and
detection process for BMCs on the SMBusses.
smb_dbg_probe を1に設定すると、SMBus 上の BMC のプローブと検知過程の
デバッグを有効にします。
Discovering the IPMI compilant BMC on the SMBus can cause devices
on the I2C bus to fail. The SMBus driver writes a "Get Device ID" IPMI
message as a block write to the I2C bus and waits for a response.
This action can be detrimental to some I2C devices. It is highly recommended
that the known I2c address be given to the SMBus driver in the smb_addr
parameter. The default adrress range will not be used when a smb_addr
parameter is provided.
SMbus 上の IPMI 準拠の BMC 検出は、I2C バス上のデバイスを動作不能にさ
せる原因になりかねません。SMBus ドライバは、I2C バスに対してブロック書
き込みとして "Get Device ID" IPMI メッセージを書き込み、応答を待ちます。
この動作は幾つかの I2C デバイスにとって有害になり得ます。既知の I2C ア
ドレスを smb_addr パラメータ中で SMBus ドライバに与える事を強く推奨し
ます。smb_addr パラメータが与えられた場合、デフォルトアドレス範囲は使
用されません。
When compiled into the kernel, the addresses can be specified on the
kernel command line as:
ドライバがカーネルに組み込まれた場合、アドレスはカーネルコマンドライン
で指定する事が出来ます：
ipmb_smb.addr=<adapter1>,<i2caddr1>[,<adapter2>,<i2caddr2>[,...]]
ipmi_smb.dbg=<flags1>,<flags2>...
ipmi_smb.defaultprobe=0 ipmi_smb.dbg_probe=1
These are the same options as on the module command line.
モジュールコマンドラインと同じオプションがあります。
Note that you might need some I2C changes if CONFIG_IPMI_PANIC_EVENT
is enabled along with this, so the I2C driver knows to run to
completion during sending a panic event.
このモジュールと一緒に CONFIG_IPMI_PANIC_EVENT を有効にした場合、幾つ
かの I2C の変更が必要になるかもしれない事に注意してください。そうする
と I2C ドライバはパニックイベントを送信している間に動作を完了する事を
把握します。
Other Pieces
他の部分
------------
Watchdog
ウォッチドッグ
--------
A watchdog timer is provided that implements the Linux-standard
watchdog timer interface. It has three module parameters that can be
used to control it:
ウォッチドッグタイマは Linux 標準のウォッチドッグタイマインターフェー
スを実装するものが提供されています。これには制御用に使用される3つのモ
ジュールパラメータがあります：
modprobe ipmi_watchdog timeout=<t> pretimeout=<t> action=<action type>
preaction=<preaction type> preop=<preop type> start_now=x
nowayout=x
The timeout is the number of seconds to the action, and the pretimeout
is the amount of seconds before the reset that the pre-timeout panic will
occur (if pretimeout is zero, then pretimeout will not be enabled). Note
that the pretimeout is the time before the final timeout. So if the
timeout is 50 seconds and the pretimeout is 10 seconds, then the pretimeout
will occur in 40 second (10 seconds before the timeout).
timeout は動作するまでの秒数であり、pretimeout はpre-timeout パニック
の発生をリセットするまでの秒数です (pretimeout が0の場合、pretimeout
は有効になりません)。pretimeout は最終的なタイムアウトまでの時間である
事に注意して下さい。つまり、timeout が 50秒で pretimeout が 10秒の場合、
pretimeout は 40秒で発生します (timeout まで 10秒)。
The action may be "reset", "power_cycle", or "power_off", and
specifies what to do when the timer times out, and defaults to
"reset".
動作は reset, power_cycle, power_off のいずれかであり、タイムアウトが
発生した際の動作を指定します。デフォルトは reset です。
The preaction may be "pre_smi" for an indication through the SMI
interface, "pre_int" for an indication through the SMI with an
interrupts, and "pre_nmi" for a NMI on a preaction. This is how
the driver is informed of the pretimeout.
preaction には SMI インターフェースへの通知を示す pre_smi、SMI への割
り込み付き通知を示す pre_int、NMI を示す pre_nmi が指定できます。これ
らは、ドライバが pretimeout を通知する方法を示します。
The preop may be set to "preop_none" for no operation on a pretimeout,
"preop_panic" to set the preoperation to panic, or "preop_give_data"
to provide data to read from the watchdog device when the pretimeout
occurs. A "pre_nmi" setting CANNOT be used with "preop_give_data"
because you can't do data operations from an NMI.
preop には pretimeout 時に何もしない preop_none、事前動作に panic をセッ
トする preop_panic、pretimeout 時にウォッチドッグタイマから読み出すデー
タを提供する preop_give_data が指定できます。NMI からはデータ操作が出
来ないので、pre_nmi 設定は "preop_give_data" と一緒には使用できません。
When preop is set to "preop_give_data", one byte comes ready to read
on the device when the pretimeout occurs. Select and fasync work on
the device, as well.
preop_give_data が preop にセットされた場合、pretimeout が発生した際に
デバイス上で1バイトが読み出し可能になります。select や fasync も同様
にデバイス上で機能します。
If start_now is set to 1, the watchdog timer will start running as
soon as the driver is loaded.
start_now が1にセットされた場合、ウォッチドッグタイマはドライバがロー
ドされると同時に実行されます。
If nowayout is set to 1, the watchdog timer will not stop when the
watchdog device is closed. The default value of nowayout is true
if the CONFIG_WATCHDOG_NOWAYOUT option is enabled, or false if not.
nowayout が1にセットされた場合、ウォッチドッグタイマはウォッチドッグ
デバイスが close された場合でも停止しません。CONFIG_WATCHDOG_NOWAYOUT
オプションが有効の場合、nowayout のデフォルト値は真であり、無効の場合
は負になります。
When compiled into the kernel, the kernel command line is available
for configuring the watchdog:
カーネルに組み込まれた場合、ウォッチドッグの設定にカーネルコマンドライ
ンが利用できます：
ipmi_watchdog.timeout=<t> ipmi_watchdog.pretimeout=<t>
ipmi_watchdog.action=<action type>
ipmi_watchdog.preaction=<preaction type>
ipmi_watchdog.preop=<preop type>
ipmi_watchdog.start_now=x
ipmi_watchdog.nowayout=x
The options are the same as the module parameter options.
これらのオプションはモジュールパラメータと同様です。
The watchdog will panic and start a 120 second reset timeout if it
gets a pre-action. During a panic or a reboot, the watchdog will
start a 120 timer if it is running to make sure the reboot occurs.
ウォッチドッグは pre-action を得るとパニックを発生させ、120 秒のリセッ
トタイムアウトを開始します。パニックまたは再起動の間、ウォッチドッグは
動作中であれば確実に再起動が開始されるよう 120秒タイマーを開始します。
Note that if you use the NMI preaction for the watchdog, you MUST
NOT use nmi watchdog mode 1. If you use the NMI watchdog, you
must use mode 2.
ウォッチドッグで NMI preaction を使用したい場合、NMI ウォッチドッグモー
ド1を使用してはいけない事に注意して下さい。NMI ウォッチドッグを使用す
る場合、モード2を使用しなければなりません。
Once you open the watchdog timer, you must write a 'V' character to the
device to close it, or the timer will not stop. This is a new semantic
for the driver, but makes it consistent with the rest of the watchdog
drivers in Linux.
一旦ウォッチドッグタイマを開いた場合、デバイスをクローズするためにはデ
バイスに 'V' キャラクタを書き込まなければなりません。でないとタイマー
は停止しません。これはこのドライバの新しいセマンティックですが、Linux
の他のウォッチドッグドライバとの一貫性を提供します。
Linux カーネル 2.6 付属文書一覧へ戻る