RE: UBUNTU - acpi battery on ACER TRAVELMATE 4000 WLMI

RE: UBUNTU - acpi battery on ACER TRAVELMATE 4000 WLMI

[Brown, Len]

>> I wish the repository of DSDTs on sourceforge.net would simply GO
>> AWAY for this reason. It is a crutch that makes Linux WORSE, NOT
>> BETTER.
>
>I too run Linux (Fedora Core) on a TravelMate 4001WLMi[1]. I needed to
>change the DSDT since it returned the wrong values for the processor
>speeds (!) which, I have been assured, is not an uncommon problem. No
>other changes were necessary. In fact, I could have continued using
>the unmodified DSDT except for the frequencey scaling.

This is mostly a cosmetic, rather than functional fix.
Changing the MHz values in the 1st slot of each PSS entry
will change the numbers you see in /sysfs.  It can also
have a small effect on how a governor such as ondemand
chooses the next state, since the % of maximum for each state
are now slightly different.  Eg. for P2, original 1200/1600 is 75%,
but modified 1000/1500 is 67%.  But either of these 13% from 
P1 (88% original, 80% modified) and 19% & 14% above the
original and correct P3 -- so is isn't going to make much
difference on which state is slected for a given workload.
I'd be impressed if you were able to measure any difference.

As the PERF_CTRL values in the patches _PSS are unchanged,
The actual MHz that the processor runs at when a certain
P-state is selected is unmodified.

If I were to hack the DSDT, probably a more interesting thing
to do would be fill in CPSS with some of the entries from PPSS
to give your system P-states when on AC power.

Also, you may find that the current speedstep-centrino
is able to load on this system.  Without hard-coded tables
for this processor family/model/stepping, it too would use
the ACPI PSS, but it would use native MSR access, which
is lower overhead than the IO port access used by acpi-cpufreq.
(in the future, acpi-cpufreq and speedstep-centrino should
be combined into a single driver)

>For the smart battery, I use the original, EC based implementation by
>Rich Townsend, and it works like a charm.
>
>Later (AFAIK) Rich went to a DSDT-based approach of the smart battery
>problem. I personally prefer the EC based version.

The DSDT-based approach is an interesting science project,
but it has no place in a product.  Distros would be crazy
to support users running modified platform firmware.

The EC smart battery driver has been on the list several times,
most recently from Vladimir, and that is the direction to go
to get a distro to support SB out of the box.  I expect it
to be upstream shortly -- the hold-up was the EC update.

>[1] 
>http://www.squirrel.nl/people/jvromans/articles/TM4001WLMi/index.html

great job getting your laptop running and sharing your notes
for others to benefit from your experience!  The only thing
I didn't notice there was a copy of /proc/cpuinfo

cheers,
-Len

Re: UBUNTU - acpi battery on ACER TRAVELMATE 4000 WLMI

[Johan Vromans]

"Brown, Len" <len.brown@intel.com> writes:

> If I were to hack the DSDT, probably a more interesting thing to do
> would be fill in CPSS with some of the entries from PPSS to give
> your system P-states when on AC power.

What exactly would that provide?

>>http://www.squirrel.nl/people/jvromans/articles/TM4001WLMi/index.html
>
> great job getting your laptop running and sharing your notes
> for others to benefit from your experience!  The only thing
> I didn't notice there was a copy of /proc/cpuinfo

It is, now. Thanks for the suggestion.

-- Johan

Re: UBUNTU - acpi battery on ACER TRAVELMATE 4000 WLMI

[Bruno Ducrot]

Hi Len,

On Fri, Jan 27, 2006 at 02:05:23PM -0500, Brown, Len wrote:
> Also, you may find that the current speedstep-centrino
> is able to load on this system.  Without hard-coded tables
> for this processor family/model/stepping, it too would use
> the ACPI PSS, but it would use native MSR access, which
> is lower overhead than the IO port access used by acpi-cpufreq.
> (in the future, acpi-cpufreq and speedstep-centrino should
> be combined into a single driver)

Do you mean you want to combine all possible drivers into only
one?  That is at that time of writing:

acpi-cpufreq (IO version), speedstep-centrino, powernow-k7
and powernow-k8?

Well, it might be possible that some cpufreq devellopers
would be against this approach I'm afraid.

-- 
Bruno Ducrot

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

RE: UBUNTU - acpi battery on ACER TRAVELMATE 4000 WLMI

[Brown, Len]

>> If I were to hack the DSDT, probably a more interesting thing to do
>> would be fill in CPSS with some of the entries from PPSS to give
>> your system P-states when on AC power.
>
>What exactly would that provide?

It would provide power savings when on AC power.
While you might not notice this in your utility bill,
you may notice it in the tempearture or fan speed
of the system.

-Len

Re: UBUNTU - acpi battery on ACER TRAVELMATE 4000 WLMI

[Johan Vromans]

"Brown, Len" <len.brown@intel.com> writes:

> It would provide power savings when on AC power.
> While you might not notice this in your utility bill,
> you may notice it in the tempearture or fan speed
> of the system.

Interesting. Would that be different (more, less, or otherwise
different) from playing with the CPU frequency? My notebook is
practically always running at its lowest speed anyway...

-- Johan

RE: UBUNTU - acpi battery on ACER TRAVELMATE 4000 WLMI

[Brown, Len]

>On Fri, Jan 27, 2006 at 02:05:23PM -0500, Brown, Len wrote:
>> Also, you may find that the current speedstep-centrino
>> is able to load on this system.  Without hard-coded tables
>> for this processor family/model/stepping, it too would use
>> the ACPI PSS, but it would use native MSR access, which
>> is lower overhead than the IO port access used by acpi-cpufreq.
>> (in the future, acpi-cpufreq and speedstep-centrino should
>> be combined into a single driver)
>
>Do you mean you want to combine all possible drivers into only
>one?  That is at that time of writing:
>
>acpi-cpufreq (IO version), speedstep-centrino, powernow-k7
>and powernow-k8?
>
>Well, it might be possible that some cpufreq devellopers
>would be against this approach I'm afraid.

acpi-cpufreq + speedstep-centrino = intel-enhanced-speedstep

unless you can think of a better name.  Both acpi-cpufreq
and speedstep-centrino turn out not to be good names,
since they don't describe either the function of the driver
or what hardware they run on.

No, it wouldn't' make sense to combine the intel and amd drivers.

-Len

Re: UBUNTU - acpi battery on ACER TRAVELMATE 4000 WLMI

[Bruno Ducrot]

On Tue, Jan 31, 2006 at 09:35:05PM -0500, Brown, Len wrote:
> 
> >On Fri, Jan 27, 2006 at 02:05:23PM -0500, Brown, Len wrote:
> >> Also, you may find that the current speedstep-centrino
> >> is able to load on this system.  Without hard-coded tables
> >> for this processor family/model/stepping, it too would use
> >> the ACPI PSS, but it would use native MSR access, which
> >> is lower overhead than the IO port access used by acpi-cpufreq.
> >> (in the future, acpi-cpufreq and speedstep-centrino should
> >> be combined into a single driver)
> >
> >Do you mean you want to combine all possible drivers into only
> >one?  That is at that time of writing:
> >
> >acpi-cpufreq (IO version), speedstep-centrino, powernow-k7
> >and powernow-k8?
> >
> >Well, it might be possible that some cpufreq devellopers
> >would be against this approach I'm afraid.
> 
> acpi-cpufreq + speedstep-centrino = intel-enhanced-speedstep

I see.  I thought you wanted to kill processor_perflib.c.  I was
indeed wrong.  I would like to point that acpi-cpufreq could also be
somewhat in "conflict" with speedstep-smi and speedstep-ich.
That remind me that acpi-cpufreq is not only intel enhanced speedstep (a
la Pentium Mobile, or Xeons, I means), but can work on some Pentium III
or IV IIRC.

> unless you can think of a better name.  Both acpi-cpufreq
> and speedstep-centrino turn out not to be good names,
> since they don't describe either the function of the driver
> or what hardware they run on.

Especially for speedstep-centrino.  I'm not sure for acpi-cpufreq
though, but it's true this driver works only with Intel processors.

> No, it wouldn't' make sense to combine the intel and amd drivers.

Well, a BIOS writer could write a SMI handler (after all,
they have the right to do what they want) in order to support
acpi-cpufreq for an AMD processor, but I highly doubt this will
ever happens.  It's simply too late now.

-- 
Bruno Ducrot

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

RE: UBUNTU - acpi battery on ACER TRAVELMATE 4000 WLMI

[Brown, Len]

>Hi, I'm a linux newbye.
>I installed Ubuntu Linux Breezy(5.10) on my notebook:
>acer travelmate 4000 WLMI.
>Everything run but the battery.
>I can't see the battery status.
>I tryed to patch the kernel (2.6.12) following the wiki instructions:
>https://wiki.ubuntu.com/ACPIBattery

I should state for the record (again) that a Linux distro
is really out on thin ice when they advocate that users
other than hackers modify and run the platform firmware -
as such a configuration is simply not supportable.

To make matters worse, if the modified DSDT works,
then the user doesn't complain about Linux and Linux
doesn't get fixed to work on an unmodified DSDT...

I wish the repository of DSDTs on sourceforge.net
would simply GO AWAY for this reason.  It is a crutch
that makes Linux  WORSE, NOT BETTER.

That said....
If you can boot a recent kernel.org kernel, say 2.6.15
and still have a problem, then please speak up on this
list and/or in bugzilla.kernel.org.  Run only the
DSDT that comes with the BIOS for the machine,
and change it only by updating to a newer BIOS
from the vendor for that machine.

thanks,
-Len

Re: UBUNTU - acpi battery on ACER TRAVELMATE 4000 WLMI

[Johan Vromans]

"Brown, Len" <len.brown@intel.com> writes:

> I wish the repository of DSDTs on sourceforge.net would simply GO
> AWAY for this reason. It is a crutch that makes Linux WORSE, NOT
> BETTER.

I too run Linux (Fedora Core) on a TravelMate 4001WLMi[1]. I needed to
change the DSDT since it returned the wrong values for the processor
speeds (!) which, I have been assured, is not an uncommon problem. No
other changes were necessary. In fact, I could have continued using
the unmodified DSDT except for the frequencey scaling.

For the smart battery, I use the original, EC based implementation by
Rich Townsend, and it works like a charm.

Later (AFAIK) Rich went to a DSDT-based approach of the smart battery
problem. I personally prefer the EC based version.

-- Johan

[1] http://www.squirrel.nl/people/jvromans/articles/TM4001WLMi/index.html

UBUNTU - acpi battery on ACER TRAVELMATE 4000 WLMI

[Marco Giumelli]

Hi, I'm a linux newbye.
I installed Ubuntu Linux Breezy(5.10) on my notebook:
acer travelmate 4000 WLMI.
Everything run but the battery.
I can't see the battery status.
I tryed to patch the kernel (2.6.12) following the wiki instructions:
https://wiki.ubuntu.com/ACPIBattery
But nothing happened.
I didn't find the right patch on sourceforge, I used the TM 4001
patch, may be this is the problem...
Someone can help me, please?
Tanks.
Marco

PS: sorry about my english...

Re: UBUNTU - acpi battery on ACER TRAVELMATE 4000 WLMI

[martin]

Hi,

I might be wrong, but this sounds like the Smart Battery "problem" on 
Acer notebooks. Have a look at https://sourceforge.net/projects/sbs-linux/

It's not only the DSDT on Acer. I have no link for documentation, so 
maybe you want to also search the net.

Cheers, Martin

Marco Giumelli wrote:
> Hi, I'm a linux newbye.
> I installed Ubuntu Linux Breezy(5.10) on my notebook:
> acer travelmate 4000 WLMI.
> Everything run but the battery.
> I can't see the battery status.
> I tryed to patch the kernel (2.6.12) following the wiki instructions:
> https://wiki.ubuntu.com/ACPIBattery
> But nothing happened.
> I didn't find the right patch on sourceforge, I used the TM 4001
> patch, may be this is the problem...
> Someone can help me, please?
> Tanks.
> Marco
> 
> PS: sorry about my english...
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>