On 03/ 7/10 11:30 PM, Strony Zhang wrote:
The reason is that ehci_handle_root_hub_status_change() in ehci driver
is called once every 256 ms to poll the ehci root hub or port status
change. The fix way is to change the polling to the
interrupter-driven. Fortunately, there is a corresponding interrupt
enable bit(Port Change Interrupt Enable) offered in the ehci interrupt
register. It will be supported to fix the issue.
Thanks for the correction.
- Garrett
Regards,
Strony
Aubrey Li :
Garrett D'Amore <gdam...@sun.com> wrote:
I know that all USB host controllers interrupt *really* frequently.
聽(1000Hz.) 聽This is a flaw in the way those interfaces were
designed. 聽Its
true when *any* device is plugged into the port, I believe.
It's not ture on a Linux system. Plugging a USB stick onto a Linux
system,
we still can enter deep C-state.
I'd expect that if you unplug all USB devices, you should be able to
see
deep C-states. 聽If you can't, then it does sound like a potential
bug in the
EHCI driver.
Conditionally, some system is okay like supermicro's NHM-EP.
some system is bad like Demodepot's NHM-EP.
While Linux works perfect on both systems.
If the device is going to be idle/not used, can we put it into a state
called "Selective Suspend",
instead of doing a regular wake-up to check on the device? Maybe it's
already supported and
this problem is caused by another case, I just don't know.
Sorry I don't have USB background, what I can only do is to do the
comparision.
Hope USB experts can shed some lights on this issue. This makes a big
energy
efficiency gap between solaris and other OSes.
Thanks,
-Aubrey
聽 聽- Garrett
(Yes, this is one of the things that I hate about USB. 聽It doesn't
really
have a native interrupt facility, but instead requires the host to
"poll"
the device very frequently to on an interrupt endpoint to simulate a
true
interrupt.)
On 03/ 7/10 07:18 PM, Aubrey Li wrote:
Hi,
We catched this problem in a solaris power related characterization
report.
In an idle system, all the logical CPUs are ~99% in deep C-state while
the package
can't enter deep C-state. Theoretically, if all the logical CPUs in a
package can enter
deep C-state, the package should be able to enter deep C-state as
well.
The cases here:
1) If we disabled USB2.0 in the BIOS, the problem is gone.
2) Remove EHCI driver and reboot, the problem is gone.
3) If we plugged a USB stick onto the box, without any read/write
operations, the package
C-state is throttled as well, this is not expected.
If we boot the system with other OS, we didn't see any of these
problems. So these are more
likely the software problem.
Any helps will be greatly appreciated.
Thanks,
-Aubrey
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
