ichwd on ich9 attach failing ?

[Andriy Gapon]

on 16/03/2009 18:44 Andriy Gapon said the following:
> http://lists.freebsd.org/pipermail/freebsd-acpi/2009-January/005419.html

BTW, Harald, I found your older report:
http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076381.html
I wonder if that was with the same HW as now.

I think that I got some additional evidence that SMI handler just clears timeout
status bit and doesn't do anything else.

1. When watchdogd is running TCO_RLD has value very close to value of TCO_TMR,
e.g. TCO_TMR has 0x1C and TCO_RLD oscillates from 0x1C to 0x1A.
When I kill -9 watchdogd then TCO_RLD value cycles from 4 to 1 (zero value is
probably only observable to SMM code), all status bits remain cleared (from
non-SMM observer's point of view). Because TCO_TMR still has 0x1C value, I believe
that 4 is a default internal value for "second" timeout.
2. I also observe behavior of another status bit, PERIODIC_STS, that supports my
theory that SMI handler simply clears all SMI-related status bits. Normally
PERIODIC_STS is set to 1, because on my system periodic SMI timer is enabled but
actual SMI generation by this timer is disabled. So it sets the bit to 1 on teh
first timeout, but SMI handler is never run, so there is nobody to clear this bit.
On the other hand, when watchdogd is killed, SMIs are egenrated regularly by
watchdog hw and the handler seems to clear all SMI status bits, including this one.

Maybe it's possible to somehow ask BIOS to do something useful on watchdog SMI,
but I do not see any options in my (Intel's actually) BIOS nor do I know of any
other way.

Fortunately GBL_SMI_EN bit is not locked on my system as I have discovered, so I
will try tonight to let watchdog timer expire with SMIs disabled.
This is quite a sledge-hummer approach.

-- 
Andriy Gapon