broken bm_sts on 82801CA?

broken bm_sts on 82801CA?

[Nate Lawson]

My chipset claims to be: Intel 82801CA/CAM (ICH3) and it's on an IBM T23
thinkpad.  While testing my Cx driver, I noticed that bm_sts is always
set, even when I clear it by writing a 1 to the register.  I _know_ the
box is idle so I believe this bit to be broken.  Can anyone confirm this?
I noticed the errata probe for the PIIX4 but I don't think it covers my
part.

Thanks,
Nate


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: broken bm_sts on 82801CA?

[Ducrot Bruno]

On Mon, Oct 06, 2003 at 11:38:07PM -0700, Nate Lawson wrote:
> My chipset claims to be: Intel 82801CA/CAM (ICH3) and it's on an IBM T23
> thinkpad.  While testing my Cx driver, I noticed that bm_sts is always
> set, even when I clear it by writing a 1 to the register.  I _know_ the
> box is idle so I believe this bit to be broken.  Can anyone confirm this?
> I noticed the errata probe for the PIIX4 but I don't think it covers my
> part.
> 

Have you any kind of usb bus support compiled in your kernel?
If yes, try without.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: broken bm_sts on 82801CA?

[Nate Lawson]

On Tue, 7 Oct 2003, Ducrot Bruno wrote:
> On Mon, Oct 06, 2003 at 11:38:07PM -0700, Nate Lawson wrote:
> > My chipset claims to be: Intel 82801CA/CAM (ICH3) and it's on an IBM T23
> > thinkpad.  While testing my Cx driver, I noticed that bm_sts is always
> > set, even when I clear it by writing a 1 to the register.  I _know_ the
> > box is idle so I believe this bit to be broken.  Can anyone confirm this?
> > I noticed the errata probe for the PIIX4 but I don't think it covers my
> > part.
>
> Have you any kind of usb bus support compiled in your kernel?
> If yes, try without.

Ah, I'll try that.  I do have USB support compiled in.  This is on
FreeBSD, btw.

-Nate


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: broken bm_sts on 82801CA?

[Nate Lawson]

On Wed, 8 Oct 2003, Ducrot Bruno wrote:
> On Tue, Oct 07, 2003 at 11:10:37AM -0700, Nate Lawson wrote:
> > On Tue, 7 Oct 2003, Ducrot Bruno wrote:
> > > On Mon, Oct 06, 2003 at 11:38:07PM -0700, Nate Lawson wrote:
> > > > My chipset claims to be: Intel 82801CA/CAM (ICH3) and it's on an IBM T23
> > > > thinkpad.  While testing my Cx driver, I noticed that bm_sts is always
> > > > set, even when I clear it by writing a 1 to the register.  I _know_ the
> > > > box is idle so I believe this bit to be broken.  Can anyone confirm this?
> > > > I noticed the errata probe for the PIIX4 but I don't think it covers my
> > > > part.
> > >
> > > Have you any kind of usb bus support compiled in your kernel?
> > > If yes, try without.
> >
> > Ah, I'll try that.  I do have USB support compiled in.  This is on
> > FreeBSD, btw.
>
> That more an hardware design issue due to how hotplug work in usb busses
> in general, and it may need to be workaround, so if anybody haven't yet worked on
> C-states on FreeBSD..  Please note also that Linux do not workaround that
> btw.

I have implemented C-states in freebsd, that's how I ran into this
problem.  I'll be committing the code once it's cleaned up a little.

Since Linux always demotes to "don't enter a Cx state" if bm_sts indicates
activity, are you saying that if you have a USB bus configured in Linux,
you don't even use C1 (HLT)?

-Nate


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: broken bm_sts on 82801CA?

[Ducrot Bruno]

On Wed, Oct 08, 2003 at 09:55:35AM -0700, Nate Lawson wrote:
> On Wed, 8 Oct 2003, Ducrot Bruno wrote:
> > On Tue, Oct 07, 2003 at 11:10:37AM -0700, Nate Lawson wrote:
> > > On Tue, 7 Oct 2003, Ducrot Bruno wrote:
> > > > On Mon, Oct 06, 2003 at 11:38:07PM -0700, Nate Lawson wrote:
> > > > > My chipset claims to be: Intel 82801CA/CAM (ICH3) and it's on an IBM T23
> > > > > thinkpad.  While testing my Cx driver, I noticed that bm_sts is always
> > > > > set, even when I clear it by writing a 1 to the register.  I _know_ the
> > > > > box is idle so I believe this bit to be broken.  Can anyone confirm this?
> > > > > I noticed the errata probe for the PIIX4 but I don't think it covers my
> > > > > part.
> > > >
> > > > Have you any kind of usb bus support compiled in your kernel?
> > > > If yes, try without.
> > >
> > > Ah, I'll try that.  I do have USB support compiled in.  This is on
> > > FreeBSD, btw.
> >
> > That more an hardware design issue due to how hotplug work in usb busses
> > in general, and it may need to be workaround, so if anybody haven't yet worked on
> > C-states on FreeBSD..  Please note also that Linux do not workaround that
> > btw.
> 
> I have implemented C-states in freebsd, that's how I ran into this
> problem.  I'll be committing the code once it's cleaned up a little.
> 
> Since Linux always demotes to "don't enter a Cx state" if bm_sts indicates
> activity, are you saying that if you have a USB bus configured in Linux,
> you don't even use C1 (HLT)?
> 

What?  If so, there is a bug somewhere since we should look at bm status only at
C2 (only if we have to go to C3) or C3 state.
Sound like you are right, btw.  I have to look a little deeper.  Thanks for pointing
this.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: broken bm_sts on 82801CA?

[Nate Lawson]

On Wed, 8 Oct 2003, Ducrot Bruno wrote:
> On Wed, Oct 08, 2003 at 09:55:35AM -0700, Nate Lawson wrote:
> > On Wed, 8 Oct 2003, Ducrot Bruno wrote:
> > > That more an hardware design issue due to how hotplug work in usb busses
> > > in general, and it may need to be workaround, so if anybody haven't yet worked on
> > > C-states on FreeBSD..  Please note also that Linux do not workaround that
> > > btw.
> >
> > I have implemented C-states in freebsd, that's how I ran into this
> > problem.  I'll be committing the code once it's cleaned up a little.
> >
> > Since Linux always demotes to "don't enter a Cx state" if bm_sts indicates
> > activity, are you saying that if you have a USB bus configured in Linux,
> > you don't even use C1 (HLT)?
>
> What?  If so, there is a bug somewhere since we should look at bm status only at
> C2 (only if we have to go to C3) or C3 state.
> Sound like you are right, btw.  I have to look a little deeper.  Thanks for pointing
> this.

This is from 2.5.74.  If C3 is supported by the platform, unconditionally
set flags.bm_check:

		else {
			pr->power.states[ACPI_STATE_C3].valid = 1;
			pr->power.states[ACPI_STATE_C3].latency_ticks =
				US_TO_PM_TIMER_TICKS(acpi_fadt.plvl3_lat);
			pr->flags.bm_check = 1;
		}

In acpi_processor_idle(), if bm_check, read the bm_sts register and if it
is non-zero, set next_state to be the demotion state but don't sleep this
quantum.  Instead, enable IRQs and stay active:

		if (pr->power.bm_activity & cx->demotion.threshold.bm) {
			local_irq_enable();
			next_state = cx->demotion.state;
			goto end;
		}

However, since this code is run every time acpi_processor_idle() is
called, it will never enter even C2 if you have a bm_sts bit that is
always 1.

-Nate


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: broken bm_sts on 82801CA?

[Ducrot Bruno]

On Wed, Oct 08, 2003 at 10:40:21AM -0700, Nate Lawson wrote:
> On Wed, 8 Oct 2003, Ducrot Bruno wrote:
> > On Wed, Oct 08, 2003 at 09:55:35AM -0700, Nate Lawson wrote:
> > > On Wed, 8 Oct 2003, Ducrot Bruno wrote:
> > > > That more an hardware design issue due to how hotplug work in usb busses
> > > > in general, and it may need to be workaround, so if anybody haven't yet worked on
> > > > C-states on FreeBSD..  Please note also that Linux do not workaround that
> > > > btw.
> > >
> > > I have implemented C-states in freebsd, that's how I ran into this
> > > problem.  I'll be committing the code once it's cleaned up a little.
> > >
> > > Since Linux always demotes to "don't enter a Cx state" if bm_sts indicates
> > > activity, are you saying that if you have a USB bus configured in Linux,
> > > you don't even use C1 (HLT)?
> >
> > What?  If so, there is a bug somewhere since we should look at bm status only at
> > C2 (only if we have to go to C3) or C3 state.
> > Sound like you are right, btw.  I have to look a little deeper.  Thanks for pointing
> > this.
> 
> This is from 2.5.74.  If C3 is supported by the platform, unconditionally
> set flags.bm_check:
> 
> 		else {
> 			pr->power.states[ACPI_STATE_C3].valid = 1;
> 			pr->power.states[ACPI_STATE_C3].latency_ticks =
> 				US_TO_PM_TIMER_TICKS(acpi_fadt.plvl3_lat);
> 			pr->flags.bm_check = 1;
> 		}
> 
> In acpi_processor_idle(), if bm_check, read the bm_sts register and if it
> is non-zero, set next_state to be the demotion state but don't sleep this
> quantum.  Instead, enable IRQs and stay active:
> 
> 		if (pr->power.bm_activity & cx->demotion.threshold.bm) {
> 			local_irq_enable();
> 			next_state = cx->demotion.state;
> 			goto end;
> 		}
> 
> However, since this code is run every time acpi_processor_idle() is
> called, it will never enter even C2 if you have a bm_sts bit that is
> always 1.
> 

I checked a little bit more, but I think you are wrong because
acpi_processor_power_activate(pr, next_state), with next_state == ACPI_STATE_C2,
will be called after the end label,
and since pr->power.states[ACPI_STATE_C2].demotion.threshold.bm  
is always 0 we do not go to the 'then' statement at the next run if we
were at C3 state.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: broken bm_sts on 82801CA?

[Nate Lawson]

On Fri, 10 Oct 2003, Ducrot Bruno wrote:
> On Wed, Oct 08, 2003 at 10:40:21AM -0700, Nate Lawson wrote:
> > However, since this code is run every time acpi_processor_idle() is
> > called, it will never enter even C2 if you have a bm_sts bit that is
> > always 1.
>
> I checked a little bit more, but I think you are wrong because
> acpi_processor_power_activate(pr, next_state), with next_state == ACPI_STATE_C2,
> will be called after the end label,
> and since pr->power.states[ACPI_STATE_C2].demotion.threshold.bm
> is always 0 we do not go to the 'then' statement at the next run if we
> were at C3 state.

Yes, I was incorrect.  It should always go to C2.

-Nate


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php