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
controller.



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
is rebooted.

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.

Thank you.

-Paula

It might help if you Re-tried that Experiment on The Windows Vista Febuary
CTP Build (Build 5308 CTP).

P.S. I also have an Intel ICH6R Chipset and although I was unable to get
Build 5270 CTP to install (most of the time, that is), I had much better
luck with Build 5308 CTP (until some of my hard drives started going bad,
that is). So I would be Very Interested what the results of your test would
be on Build 5308 CTP, just FYI.

"kat333" <kat333@discussions.microsoft.com> wrote in message
newsEA72E37-E0F5-4057-BD27-A4094F51BB57@microsoft.com...
> 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
> controller.
>
> 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
> is rebooted.
>
> 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.
>
> Thank you.
>
> -Paula

Hi Kevin.

I just tried the same test on Windows Vista February CTP Build (build 5308
CTP). I got the same results.

In Power Options, there is a setting that asks if you want a password when
returning from Sleep mode. Enabling/Disabling this option did not make a
difference though.

Any other thoughts?

Thanks for your help.


"Kevin John Panzke" wrote:

> It might help if you Re-tried that Experiment on The Windows Vista Febuary
> CTP Build (Build 5308 CTP).
>
> P.S. I also have an Intel ICH6R Chipset and although I was unable to get
> Build 5270 CTP to install (most of the time, that is), I had much better
> luck with Build 5308 CTP (until some of my hard drives started going bad,
> that is). So I would be Very Interested what the results of your test would
> be on Build 5308 CTP, just FYI.
>
> "kat333" <kat333@discussions.microsoft.com> wrote in message
> newsEA72E37-E0F5-4057-BD27-A4094F51BB57@microsoft.com...
> > 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
> > controller.
> >
> > 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
> > is rebooted.
> >
> > 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.
> >
> > Thank you.
> >
> > -Paula
>
>
>

Try it again when Beta 2 comes out later this month or early next month.

"kat333" <kat333@discussions.microsoft.com> wrote in message
news:207F4666-AF31-41D4-92A4-309DE915BB1F@microsoft.com...
> Hi Kevin.
>
> I just tried the same test on Windows Vista February CTP Build (build 5308
> CTP). I got the same results.
>
> In Power Options, there is a setting that asks if you want a password when
> returning from Sleep mode. Enabling/Disabling this option did not make a
> difference though.
>
> Any other thoughts?
>
> Thanks for your help.
>
>
> "Kevin John Panzke" wrote:
>
>> It might help if you Re-tried that Experiment on The Windows Vista
>> Febuary
>> CTP Build (Build 5308 CTP).
>>
>> P.S. I also have an Intel ICH6R Chipset and although I was unable to get
>> Build 5270 CTP to install (most of the time, that is), I had much better
>> luck with Build 5308 CTP (until some of my hard drives started going bad,
>> that is). So I would be Very Interested what the results of your test
>> would
>> be on Build 5308 CTP, just FYI.
>>
>> "kat333" <kat333@discussions.microsoft.com> wrote in message
>> newsEA72E37-E0F5-4057-BD27-A4094F51BB57@microsoft.com...
>> > 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
>> > controller.
>> >
>> > 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
>> > is rebooted.
>> >
>> > 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.
>> >
>> > Thank you.
>> >
>> > -Paula
>>
>>
>>

It's a bug, fixed in later builds )

--
Zack Whittaker
» ZackNET Enterprises: www.zacknet.co.uk
» MSBlog on ResDev: www.msblog.org
» Vista Knowledge Base: www.vistabase.co.uk
» This mailing is provided "as is" with no warranties, and confers no
rights. All opinions expressed are those of myself unless stated so, and not
of my employer, best friend, Ghandi, my mother or my cat. Glad we cleared
that up!

--: Original message follows :--
"kat333" <kat333@discussions.microsoft.com> wrote in message
news:207F4666-AF31-41D4-92A4-309DE915BB1F@microsoft.com...
> Hi Kevin.
>
> I just tried the same test on Windows Vista February CTP Build (build 5308
> CTP). I got the same results.
>
> In Power Options, there is a setting that asks if you want a password when
> returning from Sleep mode. Enabling/Disabling this option did not make a
> difference though.
>
> Any other thoughts?
>
> Thanks for your help.
>
>
> "Kevin John Panzke" wrote:
>
>> It might help if you Re-tried that Experiment on The Windows Vista
>> Febuary
>> CTP Build (Build 5308 CTP).
>>
>> P.S. I also have an Intel ICH6R Chipset and although I was unable to get
>> Build 5270 CTP to install (most of the time, that is), I had much better
>> luck with Build 5308 CTP (until some of my hard drives started going bad,
>> that is). So I would be Very Interested what the results of your test
>> would
>> be on Build 5308 CTP, just FYI.
>>
>> "kat333" <kat333@discussions.microsoft.com> wrote in message
>> newsEA72E37-E0F5-4057-BD27-A4094F51BB57@microsoft.com...
>> > 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
>> > controller.
>> >
>> > 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
>> > is rebooted.
>> >
>> > 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.
>> >
>> > Thank you.
>> >
>> > -Paula
>>
>>
>>

So that must be what is causing my Hard Disk Drives to go Bad in Build 5308
CTP.

"Zack Whittaker" <admin@zacknet.co.uk> wrote in message
news:Oz98OaHdGHA.4912@TK2MSFTNGP05.phx.gbl...
> It's a bug, fixed in later builds )
>
> --
> Zack Whittaker
> » ZackNET Enterprises: www.zacknet.co.uk
> » MSBlog on ResDev: www.msblog.org
> » Vista Knowledge Base: www.vistabase.co.uk
> » This mailing is provided "as is" with no warranties, and confers no
> rights. All opinions expressed are those of myself unless stated so, and
> not
> of my employer, best friend, Ghandi, my mother or my cat. Glad we cleared
> that up!
>
> --: Original message follows :--
> "kat333" <kat333@discussions.microsoft.com> wrote in message
> news:207F4666-AF31-41D4-92A4-309DE915BB1F@microsoft.com...
>> Hi Kevin.
>>
>> I just tried the same test on Windows Vista February CTP Build (build
>> 5308
>> CTP). I got the same results.
>>
>> In Power Options, there is a setting that asks if you want a password
>> when
>> returning from Sleep mode. Enabling/Disabling this option did not make a
>> difference though.
>>
>> Any other thoughts?
>>
>> Thanks for your help.
>>
>>
>> "Kevin John Panzke" wrote:
>>
>>> It might help if you Re-tried that Experiment on The Windows Vista
>>> Febuary
>>> CTP Build (Build 5308 CTP).
>>>
>>> P.S. I also have an Intel ICH6R Chipset and although I was unable to
>>> get
>>> Build 5270 CTP to install (most of the time, that is), I had much better
>>> luck with Build 5308 CTP (until some of my hard drives started going
>>> bad,
>>> that is). So I would be Very Interested what the results of your test
>>> would
>>> be on Build 5308 CTP, just FYI.
>>>
>>> "kat333" <kat333@discussions.microsoft.com> wrote in message
>>> newsEA72E37-E0F5-4057-BD27-A4094F51BB57@microsoft.com...
>>> > 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
>>> > controller.
>>> >
>>> > 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
>>> > is rebooted.
>>> >
>>> > 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.
>>> >
>>> > Thank you.
>>> >
>>> > -Paula
>>>
>>>
>>>
>
>

I installed Vista beta 2 and was still able to duplicate the semaphore
problem. I did find some interesting information though. I am using a
system with an Intel BIOS. When I change the ACPI mode from the default of
S3 to S1, our driver can access the INUSE_STS semaphore when returning from
sleep mode.

Can someone offer an explanation?

Thanks.
-Paula


"Kevin John Panzke" wrote:

> So that must be what is causing my Hard Disk Drives to go Bad in Build 5308
> CTP.
>
> "Zack Whittaker" <admin@zacknet.co.uk> wrote in message
> news:Oz98OaHdGHA.4912@TK2MSFTNGP05.phx.gbl...
> > It's a bug, fixed in later builds )
> >
> > --
> > Zack Whittaker
> > » ZackNET Enterprises: www.zacknet.co.uk
> > » MSBlog on ResDev: www.msblog.org
> > » Vista Knowledge Base: www.vistabase.co.uk
> > » This mailing is provided "as is" with no warranties, and confers no
> > rights. All opinions expressed are those of myself unless stated so, and
> > not
> > of my employer, best friend, Ghandi, my mother or my cat. Glad we cleared
> > that up!
> >
> > --: Original message follows :--
> > "kat333" <kat333@discussions.microsoft.com> wrote in message
> > news:207F4666-AF31-41D4-92A4-309DE915BB1F@microsoft.com...
> >> Hi Kevin.
> >>
> >> I just tried the same test on Windows Vista February CTP Build (build
> >> 5308
> >> CTP). I got the same results.
> >>
> >> In Power Options, there is a setting that asks if you want a password
> >> when
> >> returning from Sleep mode. Enabling/Disabling this option did not make a
> >> difference though.
> >>
> >> Any other thoughts?
> >>
> >> Thanks for your help.
> >>
> >>
> >> "Kevin John Panzke" wrote:
> >>
> >>> It might help if you Re-tried that Experiment on The Windows Vista
> >>> Febuary
> >>> CTP Build (Build 5308 CTP).
> >>>
> >>> P.S. I also have an Intel ICH6R Chipset and although I was unable to
> >>> get
> >>> Build 5270 CTP to install (most of the time, that is), I had much better
> >>> luck with Build 5308 CTP (until some of my hard drives started going
> >>> bad,
> >>> that is). So I would be Very Interested what the results of your test
> >>> would
> >>> be on Build 5308 CTP, just FYI.
> >>>
> >>> "kat333" <kat333@discussions.microsoft.com> wrote in message
> >>> newsEA72E37-E0F5-4057-BD27-A4094F51BB57@microsoft.com...
> >>> > 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
> >>> > controller.
> >>> >
> >>> > 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
> >>> > is rebooted.
> >>> >
> >>> > 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.
> >>> >
> >>> > Thank you.
> >>> >
> >>> > -Paula
> >>>
> >>>
> >>>
> >
> >
>
>
>