We are using a small legacy driver which communicates with a device over
SMBus using the controller in an Intel ICH6. The ICH6 includes a
software-semaphore in I/O space at register BASE+0x00, bit 6. This software
semaphore, INUSE_STS, allows multiple drivers to share access to the SMBus
To request the semaphore, you simply read BASE+0x00. If INUSE_STS reads back
as a 0x00, you have been granted the semaphore. All future reads of
INUSE_STS will read back as a 1. To release the semaphore, you write a 1 to
this register; the next read of INUSE_STS will come back as a 0. This keeps
the semaphore request operation atomic, with the drawback that a careless
read of BASE+0x00 can inadvertently request the semaphore.
Our legacy driver works properly with the semaphore, requesting it per the
Intel specification before modifying any SMBus controller registers and
releasing it after we have finished each SMBus operation. The driver works
fine on Windows XP systems, with the exception of a few programs (such as
CPU-Z) which also use the SMBus and "steal" the semaphore, requesting it and
never releasing it.
However, running tests of our driver under Vista build 5270, we find that
whenever the operating system enters into sleep mode, there is three bytes of
activity on the SMBus (0x5E,0x04,0xF0), and whenever the operating system
leaves sleep mode, there are three more bytes of activity (0x5E,0x04,0xx07).
We have been unable to determine the reason for this SMBus activity, and it
would not be a concern except that when our driver attempts to request the
INUSE_STS semaphore after coming out of sleep mode, we find that the
semaphore is permanently in use. This indicates that whatever OS mechanism
is communicating over the SMBus during sleep/return is inadvertently
requesting the SMBus semaphore and never releasing it, locking any programs
or drivers which use the semaphore out from using the SMBus until the system
The system that we are using was upgraded from Windows XP SP2 to Vista build
5270. We did not install additional applications or drivers other than our
own driver which uses the legacy SMBus. We have also found that this issue
only occurs with Vista Sleep mode; it does not happen in Hibernate mode on XP.
Can someone shed some light on what might be causing this problem, and what
can be done to fix this issue? At this point, our only option is to disable
checking of the INUSE_STS semaphore, but this is dangerous as it allows for
collisions if preemption occurs while multiple drivers are accessing the
SMBus controller. We wish to comply with the Intel-specified mechanism for
collision avoidance, but clearly a semaphore can only be used if all parties
support its use.