Supermicro BIOS's watchdog feature?
Xin LI
Hash: SHA256
Hi,
Is there anybody used the Supermicro's BIOS watchdog feature (reboot if
no OS activities)?
It seems that ICH10R's watchdog is supported by ichwd(4) but Supermicro
BIOS needs some special treatments which is beyond what ichwd(4) and
watchdogd(8) would do...
Cheers,
- --
Xin LI <del...@delphij.net> http://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (FreeBSD)
iQEcBAEBCAAGBQJMKwf0AAoJEATO+BI/yjfB+uYH/j9c0VKgq84HUufNztoLvsJ8
zYNaj9xV+mKDSxTEeQsQelqqUkmwfEF/ibF8N6sSUZ9IH1fOVZTxu/NdTQQ4Vf9c
VZQB6gusBl3xL4/uYHubLwVLsZVYb6i/CiodFJ5h+5sv4rvQAy9thQARmyw+Lfpx
ID3zAxrAkwoCCjABEEppRpEXxzchb/Bvs4g40d+15Rk+aDqEG8HGtsw5QgXN+eZ+
eu/hXg+Z+j9A+RiBYB93kA1+o85e6C7v4hybtnXIXctGHxklt82QiGYMz2x1c1Jp
ZVbHfVqM+Kqdl7Cn2S3TCiBXR+zkaB9mwcDHXqu9iBgPxv5nrwZZPfmDhsC9QdM=
=TcIK
-----END PGP SIGNATURE-----
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
Matthew Jacob
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi,
>
> Is there anybody used the Supermicro's BIOS watchdog feature (reboot if
> no OS activities)?
>
> It seems that ICH10R's watchdog is supported by ichwd(4) but Supermicro
> BIOS needs some special treatments which is beyond what ichwd(4) and
> watchdogd(8) would do...
>
>
think) onward.
Hmm. We use this at Panasas for at least one class of machines and it
seems to work fine for those SuperMicro BIOS'.
What do mean "special" treatment?
Dag-Erling Smørgrav
> Xin LI <del...@delphij.net> writes:
> > It seems that ICH10R's watchdog is supported by ichwd(4) but
> > Supermicro BIOS needs some special treatments which is beyond what
> > ichwd(4) and watchdogd(8) would do...
The watchdog timer can be disabled in hardware (by pulling the speaker
pin high during boot, IIRC). Even if it is enabled, it can be caught
and ignored by the SMM firmware. Some BIOSes have options to enable or
disable the watchdog timer, which I assume means that they flip a bit
that tells the firmware to either catch it or pass it through.
Unfortunately, although it is possible for the ichwd driver to detect
programatically (by checking an MSR) if the watchdog timer is disabled
in hardware, it is not possible to determine whether it is disabled in
firmware.
DES
--
Dag-Erling Smørgrav - d...@des.no
Xin LI
Hash: SHA256
On 2010/06/30 14:49, Dag-Erling Smørgrav wrote:
> Matthew Jacob <m...@feral.com> writes:
>> Xin LI <del...@delphij.net> writes:
>>> It seems that ICH10R's watchdog is supported by ichwd(4) but
>>> Supermicro BIOS needs some special treatments which is beyond what
>>> ichwd(4) and watchdogd(8) would do...
>> What do mean "special" treatment?
>
> The watchdog timer can be disabled in hardware (by pulling the speaker
> pin high during boot, IIRC). Even if it is enabled, it can be caught
> and ignored by the SMM firmware. Some BIOSes have options to enable or
> disable the watchdog timer, which I assume means that they flip a bit
> that tells the firmware to either catch it or pass it through.
>
> Unfortunately, although it is possible for the ichwd driver to detect
> programatically (by checking an MSR) if the watchdog timer is disabled
> in hardware, it is not possible to determine whether it is disabled in
> firmware.
Hmm... Sorry I think I didn't described the behavior accurately.
Currently if I enable the "Watch Dog" option in BIOS, the system
reboots after ~5 mins regardless whether I have ichwd(4) and
watchdogd(8) loaded.
Looking at the boot -v output, ichwd would disable the watchdog and
watchdogd would enable it, pat it as expected, but this won't stop the
system from rebooting by the watchdog.
Cheers,
- --
Xin LI <del...@delphij.net> http://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (FreeBSD)
iQEcBAEBCAAGBQJMK788AAoJEATO+BI/yjfBPHkH/jWIZEX9/tmL50AgXzkfEEXU
zNn+d2CAGA/+6wUt73aizKq1dk0eIz5ze9V+RR59cjJH4ftXLg2Tn34Ed2OYNTZZ
JxFP7go4RIO1P5a3WIM6A8MVykUCIv+JhfXR3yG8Fy0h9DbmL2zwLPlqYPLBAXOK
y+2DKYXqmA94qetPmrrm8b4WDRD9a7dwH26E+D8AslPJcABynjrdv0Ou8MLKC3g7
K+3YcgaCP2dowyy0gJzfNi2WTJyPmEtLsmFGzw14enP5tpDNU0t6yR4rkPbHkQSM
6BRF7gwZiAQoa4Az/S72RvjVR+OXehJGNNJLM6YRTH4fB2QiZ3YdmJ3WyeUE/TU=
=EA7X
-----END PGP SIGNATURE-----
Xin LI
Hash: SHA256
On 2010/06/30 15:19, Dag-Erling Smørgrav wrote:
> Xin LI <del...@delphij.net> writes:
>> Hmm... Sorry I think I didn't described the behavior accurately.
>> Currently if I enable the "Watch Dog" option in BIOS, the system
>> reboots after ~5 mins regardless whether I have ichwd(4) and
>> watchdogd(8) loaded.
>
> Perhaps the motherboard has additional watchdog hardware? If you
> disable the watchdog in BIOS, does ichwd still work?
If I kill -9 watchdogd the system do reset itself so I think ichwd(4)
really works even if BIOS setting is 'Disabled' (but I'm not sure if
this method is right? Looking at the code I think the answer is
probably "Yes" though)
Cheers,
- --
Xin LI <del...@delphij.net> http://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (FreeBSD)
iQEcBAEBCAAGBQJMK9SYAAoJEATO+BI/yjfBUYIH/jPJX3kEZt7o9sia7+H21SBX
xtuRZ+bz7q0dPKmdpHVPuWZNUB7mauFgtlZdUcu7gx1bKLb8XrOO7FuUmh6n8QXy
MwzeCVnZCW8EbSthkOaJf7KnQjC6QebcRtSJr9buldYv7U5AW7YpzDyOwk7AhjOc
YBK12GSkmz/b9FtURh6NECtzY3v5W8cquHGHhLMVFe1t7/gKF2KVOHE8MEKjGG8a
dlG6JE4SJtFT7Y3utHZqHoDZkuI3SBdXY31PYFoUY31LSJ5cSkzA/3eYbB7l1WL6
BjhLAb1qeBwYyF3nzWYPtv/dtWs0dlxEtUGu2XFXr/vejCQ2VNdkGJN1FGkAjY4=
=fvdq
Dag-Erling Smørgrav
> Hmm... Sorry I think I didn't described the behavior accurately.
> Currently if I enable the "Watch Dog" option in BIOS, the system
> reboots after ~5 mins regardless whether I have ichwd(4) and
> watchdogd(8) loaded.
Perhaps the motherboard has additional watchdog hardware? If you
disable the watchdog in BIOS, does ichwd still work?
DES
--
Dag-Erling Smørgrav - d...@des.no
Xin LI
Hash: SHA256
On 2010/07/01 00:12, Dag-Erling Smørgrav wrote:
> Xin LI <del...@delphij.net> writes:
>> "Dag-Erling Smørgrav" <d...@des.no> writes:
>>> Perhaps the motherboard has additional watchdog hardware? If you
>>> disable the watchdog in BIOS, does ichwd still work?
>> If I kill -9 watchdogd the system do reset itself so I think ichwd(4)
>> really works even if BIOS setting is 'Disabled' (but I'm not sure if
>> this method is right? Looking at the code I think the answer is
>> probably "Yes" though)
>
> Yes. This confirms my hypothesis, which is that your motherboard has
> additional watchdog hardware, and that the BIOS setting controls that,
> not the ichwd watchdog timer. Just disable the watchdog in BIOS and use
> ichwd instead.
Thanks, you are absolutely correct that they are using another watchdog
(on Winbond Super I/O chip).
With help from some datasheets floating around the Internet and playing
with the motherboard a little bit, now I have a first cut of a
watchdog(9) interfaced driver for the chip and have confirmed working on
the motherboard.
I'm still polishing up the driver, there seems to be no way to figure
out the base port address directly (datasheet said it's either 0x2e and
0x4e) so for now I have its device identify method to do some dirty
hacks (outb/inb directly) and only check if with appropriate key entered
to the port we will get non-0xff value. I'm not sure if that would be
acceptable? I'll try to further read the spec and see if we have some
better way of doing this and publish the driver code hopefully in the
next week.
Cheers,
- --
Xin LI <del...@delphij.net> http://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (FreeBSD)
iQEcBAEBCAAGBQJMXUv9AAoJEATO+BI/yjfBd3QIAMi3JV5+kQA9Mq6VJvs307jM
GStdcuG0zXfXIsS4H4r8VYdphUD8aTk10QNCXBLnXSW5fZjFMlyEocpPlSn1Jtah
TM1uApjc5rrAIdM9S0GQxPUdJLvc7O3okTsQRnze0Nv8EvO0p6ZQinRjMJT/1qfH
CuggvbTsAO9Yg5N65CsbHIUgPm1vu5a/uyFVN7nhpWtzaCuex+mB0n1r5qObPqY2
UaiF/s3SFssJtx27cwCo4KuuLhX9aI/qaDzjpmpBXIGY//gGYjW5cd180bW8V744
abWfVExqQqtdRLXqacrjWeUyrRE27pZ6ghj/6cRBwK018GLweFntX9p5SJ9S3Rs=
=cK+Y
Dag-Erling Smørgrav
> I'm still polishing up the driver, there seems to be no way to figure
> out the base port address directly (datasheet said it's either 0x2e and
> 0x4e) so for now I have its device identify method to do some dirty
> hacks (outb/inb directly) and only check if with appropriate key entered
> to the port we will get non-0xff value.
Sounds gross, but if there's no other way, I guess it'll have to do. I
imagine you check the PCI id etc. first?
DES
--
Dag-Erling Smørgrav - d...@des.no
Bjoern A. Zeeb
Hey,
a bit unrealted but I faced some of those problems lately as well.
I have a fintek locally but they all basically seem to operate after
the same scheme.
I had a very simple inb/outb /dev/io based user space solution for it
and went to the quick and dirty kernel module.
There are not many assertions put in place and it only checks one of
the two base ports as I had only done it for me so far. Unfortunately
there is no ACPI WDRT entry here (either?). devinfo -r was to some use
though.
In case it'll help you or someone else I just put it online:
http://people.freebsd.org/~bz/20100807-02-wd-fintek-f71882fg.diff
/bz
--
Bjoern A. Zeeb This signature is about you not me.
Xin LI
> Xin LI <del...@delphij.net> writes:
>> I'm still polishing up the driver, there seems to be no way to figure
>> out the base port address directly (datasheet said it's either 0x2e and
>> 0x4e) so for now I have its device identify method to do some dirty
>> hacks (outb/inb directly) and only check if with appropriate key entered
>> to the port we will get non-0xff value.
>
> Sounds gross, but if there's no other way, I guess it'll have to do. I
> imagine you check the PCI id etc. first?
It's not a PCI device unfortunately (at least, not the one I have
encountered on my Supermicro board).
I have a code snapshot at:
http://people.freebsd.org/~delphij/for_review/winbondwd/
But there are some good features in bz@'s driver which I would like to bring in.
Cheers,
--
Xin LI <del...@delphij.net> http://www.delphij.net
Daniel O'Connor
On 23/08/2010, at 1:24, Xin LI wrote:
> 2010/8/7 Dag-Erling Smørgrav <d...@des.no>:
>> Xin LI <del...@delphij.net> writes:
>>> I'm still polishing up the driver, there seems to be no way to figure
>>> out the base port address directly (datasheet said it's either 0x2e and
>>> 0x4e) so for now I have its device identify method to do some dirty
>>> hacks (outb/inb directly) and only check if with appropriate key entered
>>> to the port we will get non-0xff value.
>>
>> Sounds gross, but if there's no other way, I guess it'll have to do. I
>> imagine you check the PCI id etc. first?
>
> It's not a PCI device unfortunately (at least, not the one I have
> encountered on my Supermicro board).
They're LPC ISA devices, I don't know if they appear in any PNP or ACPI tables though.
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
Dag-Erling Smørgrav
> They're LPC ISA devices, I don't know if they appear in any PNP or
> ACPI tables though.
Same issue with ichwd: ISTR there is actually supposed to be an entry
for it in an ACPI table, but on the motherboard I had when I tested it
before I committed it, that table either did not exist or was empty.
That was three years ago, though, so my recollection is a bit fuzzy.
DES
--
Dag-Erling Smørgrav - d...@des.no
per...@pluto.rain.com
> >> Xin LI <del...@delphij.net> writes:
> >>> I'm still polishing up the driver, there seems to be no way to
> >>> figure out the base port address directly (datasheet said it's
> >>> either 0x2e and 0x4e) so for now I have its device identify
> >>> method to do some dirty hacks (outb/inb directly) and only
> >>> check if with appropriate key entered to the port we will get
> >>> non-0xff value.
> >>
> >> Sounds gross, but if there's no other way, I guess it'll have
> >> to do. I imagine you check the PCI id etc. first?
> >
> > It's not a PCI device unfortunately (at least, not the one
> > I have encountered on my Supermicro board).
>
> They're LPC ISA devices, I don't know if they appear in any PNP
> or ACPI tables though.
Any mainboard device on a non-enumerable bus, including LPC, is
_supposed_ to be reported in the ACPI tables -- precisely to avoid
the need for drivers to engage in risky probing to find their
hardware. That's no guarantee of course -- there are plenty of
buggy BIOS around -- but it might be worth looking to see if this
one got it right.