The Linux IPMI Driver --------------------- Corey Minyard 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=,.... ports=,... addrs=,... irqs=,... trydefaults=[0|1] regspacings=,,... regsizes=,,... regshifts=,,... 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=,... ipmi_si.ports=,... ipmi_si.addrs=,... ipmi_si.irqs=,... ipmi_si.trydefaults=[0|1] ipmi_si.regspacings=,,... ipmi_si.regsizes=,,... ipmi_si.regshifts=,,... 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=,[,,[,...]] dbg=,... [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=,[,,[,...]] ipmi_smb.dbg=,... 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= pretimeout= action= preaction= preop= 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= ipmi_watchdog.pretimeout= ipmi_watchdog.action= ipmi_watchdog.preaction= ipmi_watchdog.preop= 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 の他のウォッチドッグドライバとの一貫性を提供します。