RE: [GIT PATCH] ACPI for 2.6.14

From: Brown, Len
Date: Thu Sep 08 2005 - 03:56:58 EST


>"Brown, Len" <len.brown@xxxxxxxxx> wrote:
>>
>> I saw lots of transient battery issues from 2.6.13-rc3
>> until 2.6.13-rc6, but the ones I followed went away
>> as of 2.6.13 final. Do you have your eye on others
>> besides 4980?
>
>Not specifically, but then ACPI bugs are the one sort which I
>don't track.
>a) because there are so many and b) because the ACPI team use bugzilla
>well.

In the last 5 weeks we've reduced our unresolved bug count
to 160 from 196 -- even as 50 new sightings rolled in:

9/8/05: 739 Resolved 160 Unresolved 899 Total
8/31/05: 733 Resolved 161 Unresolved 894 Total
8/24/05: 721 Resolved 166 Unresolved 887 Total
8/17/05: 694 Resolved 181 Unresolved 875 Total
8/10/05: 666 Resolved 194 Unresolved 860 Total
8/3/05: 653 Resolved 196 Unresolved 849 Total

>Sticking "battery" into the bugzilla Summary field turns up a few.
><vague>There seem to have been four or five reports in recent weeks.

<specific:->
We have a bugzilla category for battery issues.
There are 12 open, 4 of them resolved -- 3 of those
fixes are included in the proposed patch:
http://bugzilla.kernel.org/show_bug.cgi?id=4892
through the ec_burst=1 fix is still optional:
http://bugzilla.kernel.org/show_bug.cgi?id=3851
http://bugzilla.kernel.org/show_bug.cgi?id=3974

I think it makes sense to proceed to get broader
testing on the latest code. We're not getting
new failure reports from -mm.

Indeed, I'd like to try enabling the new ec_burst=1
by default in -mm. It is not perfect, but it works
for me, so it should do much better than the 2.6.13-rc3 attempt.

We'll keep ec_burst=0 as the default in Linus' tree
for now. The systems that require ec_burst=1 will
have to supply it manually for now, which is better
than not having it all per 2.6.12.

thanks,
-Len
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/