MFC of ichwd(4) and ipmi

From: Joerg Pulz <Joerg.Pulz_at_frm2.tum.de>
Date: Fri, 24 Mar 2006 08:17:57 +0100 (CET)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi,

are there any plans to MFC the latest ichwd(4) to RELENG_6?
I use it on several RELENG_6 systems since it was commit'ed the CURRENT 
without problems, and i like it really much.
The same question belongs to the new ipmi(currently no manpage) stuff. 
It's really hot and works for me on several systems without problems.

It would be really nice to see this in RELENG_6.

There is another question which came to my mind when i started using ichwd 
and ipmi.
I see currently no way to tell watchdogd(8) to talk to the ichwd watchdog 
or the ipmi watchdog. There is only one /dev/fido.
I have some systems where ichwd attaches a watchdog first and later ipmi 
attaches a second watchdog. But when i start watchdogd(8) it talks to the 
ichwd watchdog every time (debug.bootverbose is set to "1" to get this 
information).
Who makes the decision to use ichwd and not ipmi. Is this because ipmi 
forces the device to be /dev/ipmi, but the code looks like the watchdog is 
attached using the normal watchdog attach routines and therefore this part 
of ipmi should end as /dev/fido.
Thats a little bit confusing.

Here are some dmesg lines in the order they are shown when booting the 
system.

ichwd0: <Intel ICH5 watchdog timer> on isa0
...
ipmi0: <System Management BIOS> at iomem 0xf77a0-0xf77be,0x3feee000-0x3feee61a on isa0
ipmi0: SMBIOS Version: 2.34
ipmi0: KCS mode found at io 0xca2 alignment 0x1 on isa
ipmi0: IPMI device rev. 3, firmware rev. 4.81, version 1.5
ipmi0: Number of channels 1
ipmi0: Attached watchdog

Any clarification would be appreciated.

regards
Joerg

- -- 
The beginning is the most important part of the work.
 				-Plato
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (FreeBSD)

iD8DBQFEI50nSPOsGF+KA+MRApUbAKCZjuh78zwRBtuYoxMB5Qh6ytFbwwCfUsOd
2AMJZiDr/fgea+dnuFse57I=
=EQjA
-----END PGP SIGNATURE-----
Received on Fri Mar 24 2006 - 06:18:16 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:54 UTC