broken bm_sts on 82801CA?

DISCUSSION Nate Lawson 2 participants 8 messages Oct 7, 2003 – Oct 10, 2003 8 messages not in the archive ACPI

Share & tools

Nate Lawson

author

2003-10-07 06:38 UTC #0 lore raw

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

Ducrot Bruno

2003-10-07 08:55 UTC #2 lore raw

In reply to a message not in the archive

Quoted 7 lines · 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.

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

Signature · 10 lines

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

Nate Lawson

author

2003-10-07 18:10 UTC #4 lore raw

In reply to a message not in the archive

Quoted 10 lines · Ducrot Bruno

Quoted 6 lines · 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.
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

Nate Lawson

author

2003-10-08 16:55 UTC #7 lore raw

In reply to a message not in the archive

Quoted 13 lines · Ducrot Bruno

Quoted 12 lines · Nate Lawson
Quoted 10 lines · Ducrot Bruno
Quoted 6 lines · 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.
Have you any kind of usb bus support compiled in your kernel? If yes, try without.

Quoted 7 lines

Quoted 2 lines
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

Ducrot Bruno

2003-10-08 17:28 UTC #9 lore raw

In reply to a message not in the archive

Quoted 22 lines · Nate Lawson

Quoted 13 lines · Ducrot Bruno
Quoted 12 lines · Nate Lawson
Quoted 10 lines · Ducrot Bruno
Quoted 6 lines · 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.
Have you any kind of usb bus support compiled in your kernel? If yes, try without.
Quoted 7 lines
Quoted 2 lines
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.

Quoted 7 lines

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.

Signature · 11 lines

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

Nate Lawson

author

2003-10-08 17:40 UTC #11 lore raw

In reply to a message not in the archive

Quoted 10 lines · Ducrot Bruno

Quoted 9 lines · Nate Lawson
Quoted 4 lines · Ducrot Bruno
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.

Quoted 8 lines

Quoted 3 lines
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

Ducrot Bruno

2003-10-10 10:58 UTC #13 lore raw

In reply to a message not in the archive

Quoted 40 lines · Nate Lawson

Quoted 10 lines · Ducrot Bruno
Quoted 9 lines · Nate Lawson
Quoted 4 lines · Ducrot Bruno
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.
Quoted 8 lines
Quoted 3 lines
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;
		}

Quoted 4 lines

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.

Signature · 11 lines

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

Nate Lawson

author

2003-10-10 19:35 UTC #15 lore raw

In reply to a message not in the archive

Quoted 11 lines · Ducrot Bruno

Quoted 3 lines · Nate Lawson
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