On Mon, Apr 26, 2010 at 07:40:02PM -0700, Philip Langdale wrote: > On Fri, 05 Feb 2010 12:45:21 -0500 (EST) > Len Brown <lenb@xxxxxxxxxx> wrote: > > Jeff, > > What do you see if you apply just the patch below? > > > > Also, in addition to "powertop -d" to show what the kernel requests, > > please run turbostat to show what the hardware actually did: > > > > http://userweb.kernel.org/~lenb/acpi/utils/pmtools-latest/turbostat/turbostat.c > > > > eg. > > # turbostat -d -v sleep 5 > > > > thanks, > > -Len Brown, Intel Open Source Technology Center > > --- > > To resurrect this thread... > > I have a giga-byte GA-P55M-UD4 motherboard and I have this same problem > as well. Len's patch "works" in that I see C6 being used, but it also > cripples the system - if I do a make -j16 kernel build, I see most jobs > serialized onto one or two cores. Without the patch, I see the > full utilization of all 8 hyper-threads as expected. > > Now, gigabyte have already b0rked these boards up by using the UHCI > controllers on the PCH instead of the rate matching hubs. Maybe that's > directly the cause of BM activity - maybe they screwed something else > up - is it possible for BIOS/ACPI mistakes to lead to this behaviour? > > Jeff - is your board gigabyte too? > > --phil My board identifies it as a Dell. No idea if they rebranded a gigabyte. The patch seems to work for me as well, powertop shows 97.5% c3, turbostat shows 93.6% c6 now. I do get weird latency spikes (on I/O) from time to time. When I was investigating, I completely configured USB off, and it still wouldn't go into deep sleep. Not sure how well that meshes with your UHCI theory. -Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
