Root/
1 | |
2 | The Linux IPMI Driver |
3 | --------------------- |
4 | Corey Minyard |
5 | <minyard@mvista.com> |
6 | <minyard@acm.org> |
7 | |
8 | The Intelligent Platform Management Interface, or IPMI, is a |
9 | standard for controlling intelligent devices that monitor a system. |
10 | It provides for dynamic discovery of sensors in the system and the |
11 | ability to monitor the sensors and be informed when the sensor's |
12 | values change or go outside certain boundaries. It also has a |
13 | standardized database for field-replaceable units (FRUs) and a watchdog |
14 | timer. |
15 | |
16 | To use this, you need an interface to an IPMI controller in your |
17 | system (called a Baseboard Management Controller, or BMC) and |
18 | management software that can use the IPMI system. |
19 | |
20 | This document describes how to use the IPMI driver for Linux. If you |
21 | are not familiar with IPMI itself, see the web site at |
22 | http://www.intel.com/design/servers/ipmi/index.htm. IPMI is a big |
23 | subject and I can't cover it all here! |
24 | |
25 | Configuration |
26 | ------------- |
27 | |
28 | The Linux IPMI driver is modular, which means you have to pick several |
29 | things to have it work right depending on your hardware. Most of |
30 | these are available in the 'Character Devices' menu then the IPMI |
31 | menu. |
32 | |
33 | No matter what, you must pick 'IPMI top-level message handler' to use |
34 | IPMI. What you do beyond that depends on your needs and hardware. |
35 | |
36 | The message handler does not provide any user-level interfaces. |
37 | Kernel code (like the watchdog) can still use it. If you need access |
38 | from userland, you need to select 'Device interface for IPMI' if you |
39 | want access through a device driver. |
40 | |
41 | The driver interface depends on your hardware. If your system |
42 | properly provides the SMBIOS info for IPMI, the driver will detect it |
43 | and just work. If you have a board with a standard interface (These |
44 | will generally be either "KCS", "SMIC", or "BT", consult your hardware |
45 | manual), choose the 'IPMI SI handler' option. A driver also exists |
46 | for direct I2C access to the IPMI management controller. Some boards |
47 | support this, but it is unknown if it will work on every board. For |
48 | this, choose 'IPMI SMBus handler', but be ready to try to do some |
49 | figuring to see if it will work on your system if the SMBIOS/APCI |
50 | information is wrong or not present. It is fairly safe to have both |
51 | these enabled and let the drivers auto-detect what is present. |
52 | |
53 | You should generally enable ACPI on your system, as systems with IPMI |
54 | can have ACPI tables describing them. |
55 | |
56 | If you have a standard interface and the board manufacturer has done |
57 | their job correctly, the IPMI controller should be automatically |
58 | detected (via ACPI or SMBIOS tables) and should just work. Sadly, |
59 | many boards do not have this information. The driver attempts |
60 | standard defaults, but they may not work. If you fall into this |
61 | situation, you need to read the section below named 'The SI Driver' or |
62 | "The SMBus Driver" on how to hand-configure your system. |
63 | |
64 | IPMI defines a standard watchdog timer. You can enable this with the |
65 | 'IPMI Watchdog Timer' config option. If you compile the driver into |
66 | the kernel, then via a kernel command-line option you can have the |
67 | watchdog timer start as soon as it initializes. It also have a lot |
68 | of other options, see the 'Watchdog' section below for more details. |
69 | Note that you can also have the watchdog continue to run if it is |
70 | closed (by default it is disabled on close). Go into the 'Watchdog |
71 | Cards' menu, enable 'Watchdog Timer Support', and enable the option |
72 | 'Disable watchdog shutdown on close'. |
73 | |
74 | IPMI systems can often be powered off using IPMI commands. Select |
75 | 'IPMI Poweroff' to do this. The driver will auto-detect if the system |
76 | can be powered off by IPMI. It is safe to enable this even if your |
77 | system doesn't support this option. This works on ATCA systems, the |
78 | Radisys CPI1 card, and any IPMI system that supports standard chassis |
79 | management commands. |
80 | |
81 | If you want the driver to put an event into the event log on a panic, |
82 | enable the 'Generate a panic event to all BMCs on a panic' option. If |
83 | you want the whole panic string put into the event log using OEM |
84 | events, enable the 'Generate OEM events containing the panic string' |
85 | option. |
86 | |
87 | Basic Design |
88 | ------------ |
89 | |
90 | The Linux IPMI driver is designed to be very modular and flexible, you |
91 | only need to take the pieces you need and you can use it in many |
92 | different ways. Because of that, it's broken into many chunks of |
93 | code. These chunks (by module name) are: |
94 | |
95 | ipmi_msghandler - This is the central piece of software for the IPMI |
96 | system. It handles all messages, message timing, and responses. The |
97 | IPMI users tie into this, and the IPMI physical interfaces (called |
98 | System Management Interfaces, or SMIs) also tie in here. This |
99 | provides the kernelland interface for IPMI, but does not provide an |
100 | interface for use by application processes. |
101 | |
102 | ipmi_devintf - This provides a userland IOCTL interface for the IPMI |
103 | driver, each open file for this device ties in to the message handler |
104 | as an IPMI user. |
105 | |
106 | ipmi_si - A driver for various system interfaces. This supports KCS, |
107 | SMIC, and BT interfaces. Unless you have an SMBus interface or your |
108 | own custom interface, you probably need to use this. |
109 | |
110 | ipmi_smb - A driver for accessing BMCs on the SMBus. It uses the |
111 | I2C kernel driver's SMBus interfaces to send and receive IPMI messages |
112 | over the SMBus. |
113 | |
114 | ipmi_watchdog - IPMI requires systems to have a very capable watchdog |
115 | timer. This driver implements the standard Linux watchdog timer |
116 | interface on top of the IPMI message handler. |
117 | |
118 | ipmi_poweroff - Some systems support the ability to be turned off via |
119 | IPMI commands. |
120 | |
121 | These are all individually selectable via configuration options. |
122 | |
123 | Note that the KCS-only interface has been removed. The af_ipmi driver |
124 | is no longer supported and has been removed because it was impossible |
125 | to do 32 bit emulation on 64-bit kernels with it. |
126 | |
127 | Much documentation for the interface is in the include files. The |
128 | IPMI include files are: |
129 | |
130 | net/af_ipmi.h - Contains the socket interface. |
131 | |
132 | linux/ipmi.h - Contains the user interface and IOCTL interface for IPMI. |
133 | |
134 | linux/ipmi_smi.h - Contains the interface for system management interfaces |
135 | (things that interface to IPMI controllers) to use. |
136 | |
137 | linux/ipmi_msgdefs.h - General definitions for base IPMI messaging. |
138 | |
139 | |
140 | Addressing |
141 | ---------- |
142 | |
143 | The IPMI addressing works much like IP addresses, you have an overlay |
144 | to handle the different address types. The overlay is: |
145 | |
146 | struct ipmi_addr |
147 | { |
148 | int addr_type; |
149 | short channel; |
150 | char data[IPMI_MAX_ADDR_SIZE]; |
151 | }; |
152 | |
153 | The addr_type determines what the address really is. The driver |
154 | currently understands two different types of addresses. |
155 | |
156 | "System Interface" addresses are defined as: |
157 | |
158 | struct ipmi_system_interface_addr |
159 | { |
160 | int addr_type; |
161 | short channel; |
162 | }; |
163 | |
164 | and the type is IPMI_SYSTEM_INTERFACE_ADDR_TYPE. This is used for talking |
165 | straight to the BMC on the current card. The channel must be |
166 | IPMI_BMC_CHANNEL. |
167 | |
168 | Messages that are destined to go out on the IPMB bus use the |
169 | IPMI_IPMB_ADDR_TYPE address type. The format is |
170 | |
171 | struct ipmi_ipmb_addr |
172 | { |
173 | int addr_type; |
174 | short channel; |
175 | unsigned char slave_addr; |
176 | unsigned char lun; |
177 | }; |
178 | |
179 | The "channel" here is generally zero, but some devices support more |
180 | than one channel, it corresponds to the channel as defined in the IPMI |
181 | spec. |
182 | |
183 | |
184 | Messages |
185 | -------- |
186 | |
187 | Messages are defined as: |
188 | |
189 | struct ipmi_msg |
190 | { |
191 | unsigned char netfn; |
192 | unsigned char lun; |
193 | unsigned char cmd; |
194 | unsigned char *data; |
195 | int data_len; |
196 | }; |
197 | |
198 | The driver takes care of adding/stripping the header information. The |
199 | data portion is just the data to be send (do NOT put addressing info |
200 | here) or the response. Note that the completion code of a response is |
201 | the first item in "data", it is not stripped out because that is how |
202 | all the messages are defined in the spec (and thus makes counting the |
203 | offsets a little easier :-). |
204 | |
205 | When using the IOCTL interface from userland, you must provide a block |
206 | of data for "data", fill it, and set data_len to the length of the |
207 | block of data, even when receiving messages. Otherwise the driver |
208 | will have no place to put the message. |
209 | |
210 | Messages coming up from the message handler in kernelland will come in |
211 | as: |
212 | |
213 | struct ipmi_recv_msg |
214 | { |
215 | struct list_head link; |
216 | |
217 | /* The type of message as defined in the "Receive Types" |
218 | defines above. */ |
219 | int recv_type; |
220 | |
221 | ipmi_user_t *user; |
222 | struct ipmi_addr addr; |
223 | long msgid; |
224 | struct ipmi_msg msg; |
225 | |
226 | /* Call this when done with the message. It will presumably free |
227 | the message and do any other necessary cleanup. */ |
228 | void (*done)(struct ipmi_recv_msg *msg); |
229 | |
230 | /* Place-holder for the data, don't make any assumptions about |
231 | the size or existence of this, since it may change. */ |
232 | unsigned char msg_data[IPMI_MAX_MSG_LENGTH]; |
233 | }; |
234 | |
235 | You should look at the receive type and handle the message |
236 | appropriately. |
237 | |
238 | |
239 | The Upper Layer Interface (Message Handler) |
240 | ------------------------------------------- |
241 | |
242 | The upper layer of the interface provides the users with a consistent |
243 | view of the IPMI interfaces. It allows multiple SMI interfaces to be |
244 | addressed (because some boards actually have multiple BMCs on them) |
245 | and the user should not have to care what type of SMI is below them. |
246 | |
247 | |
248 | Creating the User |
249 | |
250 | To user the message handler, you must first create a user using |
251 | ipmi_create_user. The interface number specifies which SMI you want |
252 | to connect to, and you must supply callback functions to be called |
253 | when data comes in. The callback function can run at interrupt level, |
254 | so be careful using the callbacks. This also allows to you pass in a |
255 | piece of data, the handler_data, that will be passed back to you on |
256 | all calls. |
257 | |
258 | Once you are done, call ipmi_destroy_user() to get rid of the user. |
259 | |
260 | From userland, opening the device automatically creates a user, and |
261 | closing the device automatically destroys the user. |
262 | |
263 | |
264 | Messaging |
265 | |
266 | To send a message from kernel-land, the ipmi_request() call does |
267 | pretty much all message handling. Most of the parameter are |
268 | self-explanatory. However, it takes a "msgid" parameter. This is NOT |
269 | the sequence number of messages. It is simply a long value that is |
270 | passed back when the response for the message is returned. You may |
271 | use it for anything you like. |
272 | |
273 | Responses come back in the function pointed to by the ipmi_recv_hndl |
274 | field of the "handler" that you passed in to ipmi_create_user(). |
275 | Remember again, these may be running at interrupt level. Remember to |
276 | look at the receive type, too. |
277 | |
278 | From userland, you fill out an ipmi_req_t structure and use the |
279 | IPMICTL_SEND_COMMAND ioctl. For incoming stuff, you can use select() |
280 | or poll() to wait for messages to come in. However, you cannot use |
281 | read() to get them, you must call the IPMICTL_RECEIVE_MSG with the |
282 | ipmi_recv_t structure to actually get the message. Remember that you |
283 | must supply a pointer to a block of data in the msg.data field, and |
284 | you must fill in the msg.data_len field with the size of the data. |
285 | This gives the receiver a place to actually put the message. |
286 | |
287 | If the message cannot fit into the data you provide, you will get an |
288 | EMSGSIZE error and the driver will leave the data in the receive |
289 | queue. If you want to get it and have it truncate the message, us |
290 | the IPMICTL_RECEIVE_MSG_TRUNC ioctl. |
291 | |
292 | When you send a command (which is defined by the lowest-order bit of |
293 | the netfn per the IPMI spec) on the IPMB bus, the driver will |
294 | automatically assign the sequence number to the command and save the |
295 | command. If the response is not receive in the IPMI-specified 5 |
296 | seconds, it will generate a response automatically saying the command |
297 | timed out. If an unsolicited response comes in (if it was after 5 |
298 | seconds, for instance), that response will be ignored. |
299 | |
300 | In kernelland, after you receive a message and are done with it, you |
301 | MUST call ipmi_free_recv_msg() on it, or you will leak messages. Note |
302 | that you should NEVER mess with the "done" field of a message, that is |
303 | required to properly clean up the message. |
304 | |
305 | Note that when sending, there is an ipmi_request_supply_msgs() call |
306 | that lets you supply the smi and receive message. This is useful for |
307 | pieces of code that need to work even if the system is out of buffers |
308 | (the watchdog timer uses this, for instance). You supply your own |
309 | buffer and own free routines. This is not recommended for normal use, |
310 | though, since it is tricky to manage your own buffers. |
311 | |
312 | |
313 | Events and Incoming Commands |
314 | |
315 | The driver takes care of polling for IPMI events and receiving |
316 | commands (commands are messages that are not responses, they are |
317 | commands that other things on the IPMB bus have sent you). To receive |
318 | these, you must register for them, they will not automatically be sent |
319 | to you. |
320 | |
321 | To receive events, you must call ipmi_set_gets_events() and set the |
322 | "val" to non-zero. Any events that have been received by the driver |
323 | since startup will immediately be delivered to the first user that |
324 | registers for events. After that, if multiple users are registered |
325 | for events, they will all receive all events that come in. |
326 | |
327 | For receiving commands, you have to individually register commands you |
328 | want to receive. Call ipmi_register_for_cmd() and supply the netfn |
329 | and command name for each command you want to receive. You also |
330 | specify a bitmask of the channels you want to receive the command from |
331 | (or use IPMI_CHAN_ALL for all channels if you don't care). Only one |
332 | user may be registered for each netfn/cmd/channel, but different users |
333 | may register for different commands, or the same command if the |
334 | channel bitmasks do not overlap. |
335 | |
336 | From userland, equivalent IOCTLs are provided to do these functions. |
337 | |
338 | |
339 | The Lower Layer (SMI) Interface |
340 | ------------------------------- |
341 | |
342 | As mentioned before, multiple SMI interfaces may be registered to the |
343 | message handler, each of these is assigned an interface number when |
344 | they register with the message handler. They are generally assigned |
345 | in the order they register, although if an SMI unregisters and then |
346 | another one registers, all bets are off. |
347 | |
348 | The ipmi_smi.h defines the interface for management interfaces, see |
349 | that for more details. |
350 | |
351 | |
352 | The SI Driver |
353 | ------------- |
354 | |
355 | The SI driver allows up to 4 KCS or SMIC interfaces to be configured |
356 | in the system. By default, scan the ACPI tables for interfaces, and |
357 | if it doesn't find any the driver will attempt to register one KCS |
358 | interface at the spec-specified I/O port 0xca2 without interrupts. |
359 | You can change this at module load time (for a module) with: |
360 | |
361 | modprobe ipmi_si.o type=<type1>,<type2>.... |
362 | ports=<port1>,<port2>... addrs=<addr1>,<addr2>... |
363 | irqs=<irq1>,<irq2>... trydefaults=[0|1] |
364 | regspacings=<sp1>,<sp2>,... regsizes=<size1>,<size2>,... |
365 | regshifts=<shift1>,<shift2>,... |
366 | slave_addrs=<addr1>,<addr2>,... |
367 | force_kipmid=<enable1>,<enable2>,... |
368 | kipmid_max_busy_us=<ustime1>,<ustime2>,... |
369 | unload_when_empty=[0|1] |
370 | |
371 | Each of these except si_trydefaults is a list, the first item for the |
372 | first interface, second item for the second interface, etc. |
373 | |
374 | The si_type may be either "kcs", "smic", or "bt". If you leave it blank, it |
375 | defaults to "kcs". |
376 | |
377 | If you specify si_addrs as non-zero for an interface, the driver will |
378 | use the memory address given as the address of the device. This |
379 | overrides si_ports. |
380 | |
381 | If you specify si_ports as non-zero for an interface, the driver will |
382 | use the I/O port given as the device address. |
383 | |
384 | If you specify si_irqs as non-zero for an interface, the driver will |
385 | attempt to use the given interrupt for the device. |
386 | |
387 | si_trydefaults sets whether the standard IPMI interface at 0xca2 and |
388 | any interfaces specified by ACPE are tried. By default, the driver |
389 | tries it, set this value to zero to turn this off. |
390 | |
391 | The next three parameters have to do with register layout. The |
392 | registers used by the interfaces may not appear at successive |
393 | locations and they may not be in 8-bit registers. These parameters |
394 | allow the layout of the data in the registers to be more precisely |
395 | specified. |
396 | |
397 | The regspacings parameter give the number of bytes between successive |
398 | register start addresses. For instance, if the regspacing is set to 4 |
399 | and the start address is 0xca2, then the address for the second |
400 | register would be 0xca6. This defaults to 1. |
401 | |
402 | The regsizes parameter gives the size of a register, in bytes. The |
403 | data used by IPMI is 8-bits wide, but it may be inside a larger |
404 | register. This parameter allows the read and write type to specified. |
405 | It may be 1, 2, 4, or 8. The default is 1. |
406 | |
407 | Since the register size may be larger than 32 bits, the IPMI data may not |
408 | be in the lower 8 bits. The regshifts parameter give the amount to shift |
409 | the data to get to the actual IPMI data. |
410 | |
411 | The slave_addrs specifies the IPMI address of the local BMC. This is |
412 | usually 0x20 and the driver defaults to that, but in case it's not, it |
413 | can be specified when the driver starts up. |
414 | |
415 | The force_ipmid parameter forcefully enables (if set to 1) or disables |
416 | (if set to 0) the kernel IPMI daemon. Normally this is auto-detected |
417 | by the driver, but systems with broken interrupts might need an enable, |
418 | or users that don't want the daemon (don't need the performance, don't |
419 | want the CPU hit) can disable it. |
420 | |
421 | If unload_when_empty is set to 1, the driver will be unloaded if it |
422 | doesn't find any interfaces or all the interfaces fail to work. The |
423 | default is one. Setting to 0 is useful with the hotmod, but is |
424 | obviously only useful for modules. |
425 | |
426 | When compiled into the kernel, the parameters can be specified on the |
427 | kernel command line as: |
428 | |
429 | ipmi_si.type=<type1>,<type2>... |
430 | ipmi_si.ports=<port1>,<port2>... ipmi_si.addrs=<addr1>,<addr2>... |
431 | ipmi_si.irqs=<irq1>,<irq2>... ipmi_si.trydefaults=[0|1] |
432 | ipmi_si.regspacings=<sp1>,<sp2>,... |
433 | ipmi_si.regsizes=<size1>,<size2>,... |
434 | ipmi_si.regshifts=<shift1>,<shift2>,... |
435 | ipmi_si.slave_addrs=<addr1>,<addr2>,... |
436 | ipmi_si.force_kipmid=<enable1>,<enable2>,... |
437 | ipmi_si.kipmid_max_busy_us=<ustime1>,<ustime2>,... |
438 | |
439 | It works the same as the module parameters of the same names. |
440 | |
441 | By default, the driver will attempt to detect any device specified by |
442 | ACPI, and if none of those then a KCS device at the spec-specified |
443 | 0xca2. If you want to turn this off, set the "trydefaults" option to |
444 | false. |
445 | |
446 | If your IPMI interface does not support interrupts and is a KCS or |
447 | SMIC interface, the IPMI driver will start a kernel thread for the |
448 | interface to help speed things up. This is a low-priority kernel |
449 | thread that constantly polls the IPMI driver while an IPMI operation |
450 | is in progress. The force_kipmid module parameter will all the user to |
451 | force this thread on or off. If you force it off and don't have |
452 | interrupts, the driver will run VERY slowly. Don't blame me, |
453 | these interfaces suck. |
454 | |
455 | Unfortunately, this thread can use a lot of CPU depending on the |
456 | interface's performance. This can waste a lot of CPU and cause |
457 | various issues with detecting idle CPU and using extra power. To |
458 | avoid this, the kipmid_max_busy_us sets the maximum amount of time, in |
459 | microseconds, that kipmid will spin before sleeping for a tick. This |
460 | value sets a balance between performance and CPU waste and needs to be |
461 | tuned to your needs. Maybe, someday, auto-tuning will be added, but |
462 | that's not a simple thing and even the auto-tuning would need to be |
463 | tuned to the user's desired performance. |
464 | |
465 | The driver supports a hot add and remove of interfaces. This way, |
466 | interfaces can be added or removed after the kernel is up and running. |
467 | This is done using /sys/modules/ipmi_si/parameters/hotmod, which is a |
468 | write-only parameter. You write a string to this interface. The string |
469 | has the format: |
470 | <op1>[:op2[:op3...]] |
471 | The "op"s are: |
472 | add|remove,kcs|bt|smic,mem|i/o,<address>[,<opt1>[,<opt2>[,...]]] |
473 | You can specify more than one interface on the line. The "opt"s are: |
474 | rsp=<regspacing> |
475 | rsi=<regsize> |
476 | rsh=<regshift> |
477 | irq=<irq> |
478 | ipmb=<ipmb slave addr> |
479 | and these have the same meanings as discussed above. Note that you |
480 | can also use this on the kernel command line for a more compact format |
481 | for specifying an interface. Note that when removing an interface, |
482 | only the first three parameters (si type, address type, and address) |
483 | are used for the comparison. Any options are ignored for removing. |
484 | |
485 | The SMBus Driver |
486 | ---------------- |
487 | |
488 | The SMBus driver allows up to 4 SMBus devices to be configured in the |
489 | system. By default, the driver will register any SMBus interfaces it finds |
490 | in the I2C address range of 0x20 to 0x4f on any adapter. You can change this |
491 | at module load time (for a module) with: |
492 | |
493 | modprobe ipmi_smb.o |
494 | addr=<adapter1>,<i2caddr1>[,<adapter2>,<i2caddr2>[,...]] |
495 | dbg=<flags1>,<flags2>... |
496 | [defaultprobe=1] [dbg_probe=1] |
497 | |
498 | The addresses are specified in pairs, the first is the adapter ID and the |
499 | second is the I2C address on that adapter. |
500 | |
501 | The debug flags are bit flags for each BMC found, they are: |
502 | IPMI messages: 1, driver state: 2, timing: 4, I2C probe: 8 |
503 | |
504 | Setting smb_defaultprobe to zero disabled the default probing of SMBus |
505 | interfaces at address range 0x20 to 0x4f. This means that only the |
506 | BMCs specified on the smb_addr line will be detected. |
507 | |
508 | Setting smb_dbg_probe to 1 will enable debugging of the probing and |
509 | detection process for BMCs on the SMBusses. |
510 | |
511 | Discovering the IPMI compliant BMC on the SMBus can cause devices |
512 | on the I2C bus to fail. The SMBus driver writes a "Get Device ID" IPMI |
513 | message as a block write to the I2C bus and waits for a response. |
514 | This action can be detrimental to some I2C devices. It is highly recommended |
515 | that the known I2c address be given to the SMBus driver in the smb_addr |
516 | parameter. The default address range will not be used when a smb_addr |
517 | parameter is provided. |
518 | |
519 | When compiled into the kernel, the addresses can be specified on the |
520 | kernel command line as: |
521 | |
522 | ipmb_smb.addr=<adapter1>,<i2caddr1>[,<adapter2>,<i2caddr2>[,...]] |
523 | ipmi_smb.dbg=<flags1>,<flags2>... |
524 | ipmi_smb.defaultprobe=0 ipmi_smb.dbg_probe=1 |
525 | |
526 | These are the same options as on the module command line. |
527 | |
528 | Note that you might need some I2C changes if CONFIG_IPMI_PANIC_EVENT |
529 | is enabled along with this, so the I2C driver knows to run to |
530 | completion during sending a panic event. |
531 | |
532 | |
533 | Other Pieces |
534 | ------------ |
535 | |
536 | Get the detailed info related with the IPMI device |
537 | -------------------------------------------------- |
538 | |
539 | Some users need more detailed information about a device, like where |
540 | the address came from or the raw base device for the IPMI interface. |
541 | You can use the IPMI smi_watcher to catch the IPMI interfaces as they |
542 | come or go, and to grab the information, you can use the function |
543 | ipmi_get_smi_info(), which returns the following structure: |
544 | |
545 | struct ipmi_smi_info { |
546 | enum ipmi_addr_src addr_src; |
547 | struct device *dev; |
548 | union { |
549 | struct { |
550 | void *acpi_handle; |
551 | } acpi_info; |
552 | } addr_info; |
553 | }; |
554 | |
555 | Currently special info for only for SI_ACPI address sources is |
556 | returned. Others may be added as necessary. |
557 | |
558 | Note that the dev pointer is included in the above structure, and |
559 | assuming ipmi_smi_get_info returns success, you must call put_device |
560 | on the dev pointer. |
561 | |
562 | |
563 | Watchdog |
564 | -------- |
565 | |
566 | A watchdog timer is provided that implements the Linux-standard |
567 | watchdog timer interface. It has three module parameters that can be |
568 | used to control it: |
569 | |
570 | modprobe ipmi_watchdog timeout=<t> pretimeout=<t> action=<action type> |
571 | preaction=<preaction type> preop=<preop type> start_now=x |
572 | nowayout=x ifnum_to_use=n |
573 | |
574 | ifnum_to_use specifies which interface the watchdog timer should use. |
575 | The default is -1, which means to pick the first one registered. |
576 | |
577 | The timeout is the number of seconds to the action, and the pretimeout |
578 | is the amount of seconds before the reset that the pre-timeout panic will |
579 | occur (if pretimeout is zero, then pretimeout will not be enabled). Note |
580 | that the pretimeout is the time before the final timeout. So if the |
581 | timeout is 50 seconds and the pretimeout is 10 seconds, then the pretimeout |
582 | will occur in 40 second (10 seconds before the timeout). |
583 | |
584 | The action may be "reset", "power_cycle", or "power_off", and |
585 | specifies what to do when the timer times out, and defaults to |
586 | "reset". |
587 | |
588 | The preaction may be "pre_smi" for an indication through the SMI |
589 | interface, "pre_int" for an indication through the SMI with an |
590 | interrupts, and "pre_nmi" for a NMI on a preaction. This is how |
591 | the driver is informed of the pretimeout. |
592 | |
593 | The preop may be set to "preop_none" for no operation on a pretimeout, |
594 | "preop_panic" to set the preoperation to panic, or "preop_give_data" |
595 | to provide data to read from the watchdog device when the pretimeout |
596 | occurs. A "pre_nmi" setting CANNOT be used with "preop_give_data" |
597 | because you can't do data operations from an NMI. |
598 | |
599 | When preop is set to "preop_give_data", one byte comes ready to read |
600 | on the device when the pretimeout occurs. Select and fasync work on |
601 | the device, as well. |
602 | |
603 | If start_now is set to 1, the watchdog timer will start running as |
604 | soon as the driver is loaded. |
605 | |
606 | If nowayout is set to 1, the watchdog timer will not stop when the |
607 | watchdog device is closed. The default value of nowayout is true |
608 | if the CONFIG_WATCHDOG_NOWAYOUT option is enabled, or false if not. |
609 | |
610 | When compiled into the kernel, the kernel command line is available |
611 | for configuring the watchdog: |
612 | |
613 | ipmi_watchdog.timeout=<t> ipmi_watchdog.pretimeout=<t> |
614 | ipmi_watchdog.action=<action type> |
615 | ipmi_watchdog.preaction=<preaction type> |
616 | ipmi_watchdog.preop=<preop type> |
617 | ipmi_watchdog.start_now=x |
618 | ipmi_watchdog.nowayout=x |
619 | |
620 | The options are the same as the module parameter options. |
621 | |
622 | The watchdog will panic and start a 120 second reset timeout if it |
623 | gets a pre-action. During a panic or a reboot, the watchdog will |
624 | start a 120 timer if it is running to make sure the reboot occurs. |
625 | |
626 | Note that if you use the NMI preaction for the watchdog, you MUST NOT |
627 | use the nmi watchdog. There is no reasonable way to tell if an NMI |
628 | comes from the IPMI controller, so it must assume that if it gets an |
629 | otherwise unhandled NMI, it must be from IPMI and it will panic |
630 | immediately. |
631 | |
632 | Once you open the watchdog timer, you must write a 'V' character to the |
633 | device to close it, or the timer will not stop. This is a new semantic |
634 | for the driver, but makes it consistent with the rest of the watchdog |
635 | drivers in Linux. |
636 | |
637 | |
638 | Panic Timeouts |
639 | -------------- |
640 | |
641 | The OpenIPMI driver supports the ability to put semi-custom and custom |
642 | events in the system event log if a panic occurs. if you enable the |
643 | 'Generate a panic event to all BMCs on a panic' option, you will get |
644 | one event on a panic in a standard IPMI event format. If you enable |
645 | the 'Generate OEM events containing the panic string' option, you will |
646 | also get a bunch of OEM events holding the panic string. |
647 | |
648 | |
649 | The field settings of the events are: |
650 | * Generator ID: 0x21 (kernel) |
651 | * EvM Rev: 0x03 (this event is formatting in IPMI 1.0 format) |
652 | * Sensor Type: 0x20 (OS critical stop sensor) |
653 | * Sensor #: The first byte of the panic string (0 if no panic string) |
654 | * Event Dir | Event Type: 0x6f (Assertion, sensor-specific event info) |
655 | * Event Data 1: 0xa1 (Runtime stop in OEM bytes 2 and 3) |
656 | * Event data 2: second byte of panic string |
657 | * Event data 3: third byte of panic string |
658 | See the IPMI spec for the details of the event layout. This event is |
659 | always sent to the local management controller. It will handle routing |
660 | the message to the right place |
661 | |
662 | Other OEM events have the following format: |
663 | Record ID (bytes 0-1): Set by the SEL. |
664 | Record type (byte 2): 0xf0 (OEM non-timestamped) |
665 | byte 3: The slave address of the card saving the panic |
666 | byte 4: A sequence number (starting at zero) |
667 | The rest of the bytes (11 bytes) are the panic string. If the panic string |
668 | is longer than 11 bytes, multiple messages will be sent with increasing |
669 | sequence numbers. |
670 | |
671 | Because you cannot send OEM events using the standard interface, this |
672 | function will attempt to find an SEL and add the events there. It |
673 | will first query the capabilities of the local management controller. |
674 | If it has an SEL, then they will be stored in the SEL of the local |
675 | management controller. If not, and the local management controller is |
676 | an event generator, the event receiver from the local management |
677 | controller will be queried and the events sent to the SEL on that |
678 | device. Otherwise, the events go nowhere since there is nowhere to |
679 | send them. |
680 | |
681 | |
682 | Poweroff |
683 | -------- |
684 | |
685 | If the poweroff capability is selected, the IPMI driver will install |
686 | a shutdown function into the standard poweroff function pointer. This |
687 | is in the ipmi_poweroff module. When the system requests a powerdown, |
688 | it will send the proper IPMI commands to do this. This is supported on |
689 | several platforms. |
690 | |
691 | There is a module parameter named "poweroff_powercycle" that may |
692 | either be zero (do a power down) or non-zero (do a power cycle, power |
693 | the system off, then power it on in a few seconds). Setting |
694 | ipmi_poweroff.poweroff_control=x will do the same thing on the kernel |
695 | command line. The parameter is also available via the proc filesystem |
696 | in /proc/sys/dev/ipmi/poweroff_powercycle. Note that if the system |
697 | does not support power cycling, it will always do the power off. |
698 | |
699 | The "ifnum_to_use" parameter specifies which interface the poweroff |
700 | code should use. The default is -1, which means to pick the first one |
701 | registered. |
702 | |
703 | Note that if you have ACPI enabled, the system will prefer using ACPI to |
704 | power off. |
705 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9