mactel-linux-devel — mactel-linux Development

Re: [Mactel-linux-devel] C4 state - Status report

[Till S. <str...@sl...>]

/I can confirm your report (mbp, c1d here) - I also
found similar results (~17-18W) under osx. On linux
I get down to 20-21W (low brighness, disk at rest, CPU freq
at 1GHz, ati powerstate=1) but I found that unloading
the 'uvcvideo' driver (isight) seems to save almost
another ~1W or so - I'm at 19-20W right now.

-- Till

PS I still have the wireless up; shutting it down probably
saves also some power.
/
Soeren Sonnenburg wrote:
> On Tue, 2007-04-24 at 08:10 +0200, Sven Anders wrote:
>   
>> Hello!
>>
>> I thought about the power consumption. Maybe we can track the problem down
>> some other way...
>>
>> 1. Is the output of '/proc/acpi/battery/BAT0/state' reliable? If it is,
>>    we can use it for testing, otherwise we have to test how long the battery
>>    really lasts.
>>     
>
> well at least the predicted time matched very well the time when the mbp
> went out of batteries and as that time is based on powerconsumption
> estimates in /proc/*/BAT0/state I would tend to say it is OK.
>
>   
>> 2. As far as I remember, the MacBook is very similar to the MacBook Pro in
>>    the hardware it's using. The main difference is the GPU.
>>    How long does the battery of the MacBook under Linux last in comparison to
>>    MacOS X?
>>    If it's a small difference, so our problem is the power consumption of
>>    the ATI GPU (assuming the Intel-GPU draws as less power under Linux as it
>>    does under MacOSX). On the MacBook we have the advantage, that it's an
>>    open-source driver.
>>    If the power drain is as bad as on the MacBook Pro (and we checked the
>>    Intel-GPU driver, that is's using all power-saving states available),
>>    the problem lies somewhere else...
>>
>> To check these, we need some output of the MacBook's /proc/acpi values or
>> somebody who helps us to prove these theory...
>>     
>
> well I am using a mbp c1d and it eats about 27W with everything on +
> full brightness. as you know powerplay is supported on this book,
> aticonfig --set-powerstate=1 (low power mode) gives me 1-2W less boiling
> down to 25-26W or max. 10 extra minutes (*), if you further set
> display-brightness to the lowest level it goes down to 21-22W and
> backlight off still has 20W.
>
> In OSX I get 23.8W (=2h 18min) with everything on and 18.5W (=2h 58min)
> with everything off+low brightness
>
> so we are looking for reasons (I don't expect it to be a single one)
> that explain a gap of ~4W ... which seems a lot considering that this is
> essentially what the display at full brightness eats up but still may
> not be as big as we expected.
>
> Soeren
>
> (*): this assumes that your battery can be charged to 55Wh mine after
> half a year of intensive usage is already down to 35Wh
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Mactel-linux-devel mailing list
> Mac...@li...
> https://lists.sourceforge.net/lists/listinfo/mactel-linux-devel
>   

Re: [Mactel-linux-devel] C4 state - Status report

[Davide B. <da...@da...>]

Ok, I trust him.
I was wrong

On 4/25/07, Thomas Meyer <th...@m3...> wrote:
>
> Davide Bertola schrieb:
> > On 4/24/07, Sven Anders <an...@an...> wrote:
> >
> >> Sheer El-Showk schrieb:
> >>
> >>
> >>>> On my system osx idles at ~1200 mA, linux does 16 W -> 1600 mA.
> >>>>
> >> My MacBook Pro idles at 32W almost constantly.
> >>
> >
> > 32W means you get almost 1,5 hours. That's ridicolus.
> > Maybe your scaling governor is not working, or battery is not
> calibrated..
> > Then you have a macbook pro so you may have that problem with ati
> drivers.
> >
> >
> >>>> It's also hotter when using linux. Why ?
> >>>> I guess:
> >>>> - Lack of C4 state support.
> >>>>
> >> I think Linux is using C4(E) state too, but it does not stay as long
> >> as MacOSX in it.
> >>
> >>
> > You think, but it's not true. linux sees onlin C1 C2 and C3 state. On
> > some macbooks pro only C1 and C2. You can verify that looking
> > somewhere in /proc or /sys I don't remember now.
> >
> >
>
> Better trust him. Linux does use C4 state. See also
>
> http://www.mail-archive.com/mac...@li.../msg00918.html
>

Re: [Mactel-linux-devel] C4 state - Status report

[Soeren S. <mac...@nn...>]

On Tue, 2007-04-24 at 08:10 +0200, Sven Anders wrote:
> Hello!
> 
> I thought about the power consumption. Maybe we can track the problem down
> some other way...
> 
> 1. Is the output of '/proc/acpi/battery/BAT0/state' reliable? If it is,
>    we can use it for testing, otherwise we have to test how long the battery
>    really lasts.

well at least the predicted time matched very well the time when the mbp
went out of batteries and as that time is based on powerconsumption
estimates in /proc/*/BAT0/state I would tend to say it is OK.

> 2. As far as I remember, the MacBook is very similar to the MacBook Pro in
>    the hardware it's using. The main difference is the GPU.
>    How long does the battery of the MacBook under Linux last in comparison to
>    MacOS X?
>    If it's a small difference, so our problem is the power consumption of
>    the ATI GPU (assuming the Intel-GPU draws as less power under Linux as it
>    does under MacOSX). On the MacBook we have the advantage, that it's an
>    open-source driver.
>    If the power drain is as bad as on the MacBook Pro (and we checked the
>    Intel-GPU driver, that is's using all power-saving states available),
>    the problem lies somewhere else...
> 
> To check these, we need some output of the MacBook's /proc/acpi values or
> somebody who helps us to prove these theory...

well I am using a mbp c1d and it eats about 27W with everything on +
full brightness. as you know powerplay is supported on this book,
aticonfig --set-powerstate=1 (low power mode) gives me 1-2W less boiling
down to 25-26W or max. 10 extra minutes (*), if you further set
display-brightness to the lowest level it goes down to 21-22W and
backlight off still has 20W.

In OSX I get 23.8W (=2h 18min) with everything on and 18.5W (=2h 58min)
with everything off+low brightness

so we are looking for reasons (I don't expect it to be a single one)
that explain a gap of ~4W ... which seems a lot considering that this is
essentially what the display at full brightness eats up but still may
not be as big as we expected.

Soeren

(*): this assumes that your battery can be charged to 55Wh mine after
half a year of intensive usage is already down to 35Wh

[Mactel-linux-devel] [Fwd: Re: C4 state - Status report]

[Thomas M. <tho...@we...>]

I can't send messages from my th...@m3... mail account to the
mactel-linux-devel mailing list. Need to remember...

-------- Original-Nachricht --------
Betreff: 	Re: [Mactel-linux-devel] C4 state - Status report
Datum: 	Wed, 25 Apr 2007 07:40:21 +0200
Von: 	Thomas Meyer <th...@m3...>
An: 	Davide Bertola <da...@da...>
CC: 	mac...@li...
Referenzen: 	<462...@an...>
<4b0...@ma...>
<7c8...@ma...>
<4b0...@ma...>
<462...@an...>
<7c8...@ma...>
<7c8...@ma...>



Davide Bertola schrieb:
> On 4/24/07, Sven Anders <an...@an...> wrote:
>   
>> Sheer El-Showk schrieb:
>>
>>     
>>>> On my system osx idles at ~1200 mA, linux does 16 W -> 1600 mA.
>>>>         
>> My MacBook Pro idles at 32W almost constantly.
>>     
>
> 32W means you get almost 1,5 hours. That's ridicolus.
> Maybe your scaling governor is not working, or battery is not calibrated..
> Then you have a macbook pro so you may have that problem with ati drivers.
>
>   
>>>> It's also hotter when using linux. Why ?
>>>> I guess:
>>>> - Lack of C4 state support.
>>>>         
>> I think Linux is using C4(E) state too, but it does not stay as long
>> as MacOSX in it.
>>
>>     
> You think, but it's not true. linux sees onlin C1 C2 and C3 state. On
> some macbooks pro only C1 and C2. You can verify that looking
> somewhere in /proc or /sys I don't remember now.
>
>   

Better trust him. Linux does use C4 state. See also
http://www.mail-archive.com/mac...@li.../msg00918.html

Re: [Mactel-linux-devel] C4 state - Status report

[Davide B. <da...@da...>]

On 4/24/07, Sven Anders <an...@an...> wrote:
> Sheer El-Showk schrieb:
>
> >> On my system osx idles at ~1200 mA, linux does 16 W -> 1600 mA.
>
> My MacBook Pro idles at 32W almost constantly.

32W means you get almost 1,5 hours. That's ridicolus.
Maybe your scaling governor is not working, or battery is not calibrated..
Then you have a macbook pro so you may have that problem with ati drivers.

>
> >> It's also hotter when using linux. Why ?
> >> I guess:
> >> - Lack of C4 state support.
>
> I think Linux is using C4(E) state too, but it does not stay as long
> as MacOSX in it.
>
You think, but it's not true. linux sees onlin C1 C2 and C3 state. On
some macbooks pro only C1 and C2. You can verify that looking
somewhere in /proc or /sys I don't remember now.

> >> - No way to turn off bluetooth (always looking for devices).
>
> Just try to unload the module... Maybe this is enough.
>
It's not. If I unload the module for bluetooth and the userspace
bluetooth daemon.. the bluetooth act in some sort of emulation. My
bluetooth mouse keeps working but it's seen as an USB mouse. It's
cool, but drains power.

Another thing I've seen is that linux is much faster pairing devices
when they get in range, so i guess that bluetooth under linux polls
for devices more often. (draining more power)

> >> - maybe GPU Power Management support is not so efficent.
>
> Maybe...
>
> >> Anyway, I think that after a battery calibration, it's ok to compare
> >> Watts and Amperes outputs of Linux and OSX.
>
> Regards
>  Sven
>
> --
>  Sven Anders <an...@an...>                 () Ascii Ribbon Campaign
>                                                  /\ Support plain text e-=
mail
>  ANDURAS service solutions AG
>  Innstra=DFe 71 - 94036 Passau - Germany
>  Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 5=
0-55
>
> Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB 60=
32
> Mitglieder des Vorstands: Sven Anders, Marcus Junker
> Vorsitzender des Aufsichtsrats: Dipl. Kfm. Thomas Tr=E4ger
>
>

Re: [Mactel-linux-devel] C4 state - Status report

[Davide B. <da...@da...>]

you can see the power drain using System Profiiler.app under section 'power=
'

On 4/24/07, Sheer El-Showk <sh...@gm...> wrote:
> Hi Davide,
>
> Thanks for the info.  I'm hope you don't mind that I'm CCing the list
> but I think others will appreciate this info.
>
> How did you measure the power drain in OS X (i.e. 1200 mA)?
>
> Cheers,
> Sheer
>
>
> On 4/24/07, Davide Bertola <da...@da...> wrote:
> > At fist macbooks do not have ATI card. It's Intel (macbook non-pro).
> >
> > I use a macbook and i get ~3 hours on linux and ~4.5 hours on OSX.
> > It's a macbook core duo (not core 2 duo) and the battery is new.
> >
> > Linux measures capacity in Watts (W), osx in Amperes * 10^(-3) (mA).
> > Under linux I see a maximum capacity of ~52000 mW, and using OSX it's ~=
5200
> > mA.
> > Since mW -> mA is a simple conversion because we only have to /10
> > (should be 11 'cause battery works at 11 volts average but let's say
> > it's 10) we can compare the idle power consumpition.
> >
> > On my system osx idles at ~1200 mA, linux does 16 W -> 1600 mA.
> > It's also hotter when using linux. Why ?
> > I guess:
> > - Lack of C4 state support.
> > - No way to turn off bluetooth (always looking for devices).
> > - maybe GPU Power Management support is not so efficent.
> > - don't know
> >
> > Anyway, I think that after a battery calibration, it's ok to compare
> > Watts and Amperes outputs of Linux and OSX.
> >
> > On 4/24/07, Sheer El-Showk <sh...@gm...> wrote:
> > > Hi Sven,
> > >
> > > I asked about the MacBook issue in a previous post somewhere.  I've
> > > also become convinced that the problem is the GPU (there was an
> > > article I mentioned on Phoronix where someone compared the temperatur=
e
> > > of the GPU of an ATI card in Linux and windows and found it much
> > > higher in the former).  Regarding the MacBook,  here's a webpage
> > > claiming a 3 hour battery life under linux:
> > >
> > > http://desrt.mcmaster.ca/macbook.xhtml
> > > http://bbs.archlinux.org/viewtopic.php?id=3D22960
> > >
> > > The second link has a bit of discussion about battery life under Linu=
x
> > > on the MB.  I don't know what the OS X battery life is but I'm
> > > guessing its at least 4 hours (people there say 3-4 hrs).
> > >
> > > I agree that looking into this is the right approach.  If the GPU is
> > > the problem there's very little we can do about it but wait for ATI s=
o
> > > we might as well find out if this is the case.  Hopefully somebody
> > > from the list can post some specific MB stats.  It would also be good
> > > to see if its possible to get the MB battery life up to its OS X valu=
e
> > > using USB autosuspend and dynticks.
> > >
> > > cheers,
> > > Sheer
> > >
> > > On 4/24/07, Sven Anders <an...@an...> wrote:
> > > > Hello!
> > > >
> > > > I thought about the power consumption. Maybe we can track the probl=
em
> > down
> > > > some other way...
> > > >
> > > > 1. Is the output of '/proc/acpi/battery/BAT0/state' reliable? If it=
 is,
> > > >    we can use it for testing, otherwise we have to test how long th=
e
> > battery
> > > >    really lasts.
> > > >
> > > > 2. As far as I remember, the MacBook is very similar to the MacBook=
 Pro
> > in
> > > >    the hardware it's using. The main difference is the GPU.
> > > >    How long does the battery of the MacBook under Linux last in
> > comparison
> > > > to
> > > >    MacOS X?
> > > >    If it's a small difference, so our problem is the power consumpt=
ion
> > of
> > > >    the ATI GPU (assuming the Intel-GPU draws as less power under Li=
nux
> > as it
> > > >    does under MacOSX). On the MacBook we have the advantage, that i=
t's
> > an
> > > >    open-source driver.
> > > >    If the power drain is as bad as on the MacBook Pro (and we check=
ed
> > the
> > > >    Intel-GPU driver, that is's using all power-saving states
> > available),
> > > >    the problem lies somewhere else...
> > > >
> > > > To check these, we need some output of the MacBook's /proc/acpi val=
ues
> > or
> > > > somebody who helps us to prove these theory...
> > > >
> > > > Any comments to these thoughts? Any errors in it?
> > > >
> > > >
> > > > Best regards
> > > >  Sven
> > > >
> > > > --
> > > >  Sven Anders <an...@an...>                 () Ascii Ribbon
> > Campaign
> > > >                                                  /\ Support plain t=
ext
> > > > e-mail
> > > >  ANDURAS service solutions AG
> > > >  Innstra=DFe 71 - 94036 Passau - Germany
> > > >  Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-=
4 90
> > > > 50-55
> > > >
> > > > Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau =
HRB
> > 6032
> > > > Mitglieder des Vorstands: Sven Anders, Marcus Junker
> > > > Vorsitzender des Aufsichtsrats: Dipl. Kfm. Thomas Tr=E4ger
> > > >
> > >
> > > ---------------------------------------------------------------------=
----
> > > This SF.net email is sponsored by DB2 Express
> > > Download DB2 Express C - the FREE version of DB2 express and take
> > > control of your XML. No limits. Just data. Click to get it now.
> > > http://sourceforge.net/powerbar/db2/
> > > _______________________________________________
> > > Mactel-linux-devel mailing list
> > > Mac...@li...
> > > https://lists.sourceforge.net/lists/listinfo/mactel-linux-devel
> > >
> >
>

[Mactel-linux-devel] Important, report.

[Neto M. <Mc...@As...>]

optimized

Re: [Mactel-linux-devel] C4 state - Status report

[Thomas M. <tho...@we...>]

Sven Anders schrieb:
> Sheer El-Showk schrieb:
>
>   
>>> On my system osx idles at ~1200 mA, linux does 16 W -> 1600 mA.
>>>       
>
> My MacBook Pro idles at 32W almost constantly.
>   
cat /proc/acpi/battery/BAT0/state
present:                 yes
capacity state:          ok
charging state:          discharging
present rate:            26189 mW -> without wlan and without
appletouch, using an external mouse...

Re: [Mactel-linux-devel] C4 state - Status report

[Sven A. <an...@an...>]

Sheer El-Showk schrieb:

>> On my system osx idles at ~1200 mA, linux does 16 W -> 1600 mA.

My MacBook Pro idles at 32W almost constantly.

>> It's also hotter when using linux. Why ?
>> I guess:
>> - Lack of C4 state support.

I think Linux is using C4(E) state too, but it does not stay as long
as MacOSX in it.

>> - No way to turn off bluetooth (always looking for devices).

Just try to unload the module... Maybe this is enough.

>> - maybe GPU Power Management support is not so efficent.

Maybe...

>> Anyway, I think that after a battery calibration, it's ok to compare
>> Watts and Amperes outputs of Linux and OSX.

Regards
 Sven

-- 
 Sven Anders <an...@an...>                 () Ascii Ribbon Campaign
                                                 /\ Support plain text e-mail
 ANDURAS service solutions AG
 Innstraße 71 - 94036 Passau - Germany
 Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55

Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB 6032
Mitglieder des Vorstands: Sven Anders, Marcus Junker
Vorsitzender des Aufsichtsrats: Dipl. Kfm. Thomas Träger

Re: [Mactel-linux-devel] C4 state - Status report

[Sheer El-S. <sh...@gm...>]

Hi Davide,

Thanks for the info.  I'm hope you don't mind that I'm CCing the list
but I think others will appreciate this info.

How did you measure the power drain in OS X (i.e. 1200 mA)?

Cheers,
Sheer


On 4/24/07, Davide Bertola <da...@da...> wrote:
> At fist macbooks do not have ATI card. It's Intel (macbook non-pro).
>
> I use a macbook and i get ~3 hours on linux and ~4.5 hours on OSX.
> It's a macbook core duo (not core 2 duo) and the battery is new.
>
> Linux measures capacity in Watts (W), osx in Amperes * 10^(-3) (mA).
> Under linux I see a maximum capacity of ~52000 mW, and using OSX it's ~52=
00
> mA.
> Since mW -> mA is a simple conversion because we only have to /10
> (should be 11 'cause battery works at 11 volts average but let's say
> it's 10) we can compare the idle power consumpition.
>
> On my system osx idles at ~1200 mA, linux does 16 W -> 1600 mA.
> It's also hotter when using linux. Why ?
> I guess:
> - Lack of C4 state support.
> - No way to turn off bluetooth (always looking for devices).
> - maybe GPU Power Management support is not so efficent.
> - don't know
>
> Anyway, I think that after a battery calibration, it's ok to compare
> Watts and Amperes outputs of Linux and OSX.
>
> On 4/24/07, Sheer El-Showk <sh...@gm...> wrote:
> > Hi Sven,
> >
> > I asked about the MacBook issue in a previous post somewhere.  I've
> > also become convinced that the problem is the GPU (there was an
> > article I mentioned on Phoronix where someone compared the temperature
> > of the GPU of an ATI card in Linux and windows and found it much
> > higher in the former).  Regarding the MacBook,  here's a webpage
> > claiming a 3 hour battery life under linux:
> >
> > http://desrt.mcmaster.ca/macbook.xhtml
> > http://bbs.archlinux.org/viewtopic.php?id=3D22960
> >
> > The second link has a bit of discussion about battery life under Linux
> > on the MB.  I don't know what the OS X battery life is but I'm
> > guessing its at least 4 hours (people there say 3-4 hrs).
> >
> > I agree that looking into this is the right approach.  If the GPU is
> > the problem there's very little we can do about it but wait for ATI so
> > we might as well find out if this is the case.  Hopefully somebody
> > from the list can post some specific MB stats.  It would also be good
> > to see if its possible to get the MB battery life up to its OS X value
> > using USB autosuspend and dynticks.
> >
> > cheers,
> > Sheer
> >
> > On 4/24/07, Sven Anders <an...@an...> wrote:
> > > Hello!
> > >
> > > I thought about the power consumption. Maybe we can track the problem
> down
> > > some other way...
> > >
> > > 1. Is the output of '/proc/acpi/battery/BAT0/state' reliable? If it i=
s,
> > >    we can use it for testing, otherwise we have to test how long the
> battery
> > >    really lasts.
> > >
> > > 2. As far as I remember, the MacBook is very similar to the MacBook P=
ro
> in
> > >    the hardware it's using. The main difference is the GPU.
> > >    How long does the battery of the MacBook under Linux last in
> comparison
> > > to
> > >    MacOS X?
> > >    If it's a small difference, so our problem is the power consumptio=
n
> of
> > >    the ATI GPU (assuming the Intel-GPU draws as less power under Linu=
x
> as it
> > >    does under MacOSX). On the MacBook we have the advantage, that it'=
s
> an
> > >    open-source driver.
> > >    If the power drain is as bad as on the MacBook Pro (and we checked
> the
> > >    Intel-GPU driver, that is's using all power-saving states
> available),
> > >    the problem lies somewhere else...
> > >
> > > To check these, we need some output of the MacBook's /proc/acpi value=
s
> or
> > > somebody who helps us to prove these theory...
> > >
> > > Any comments to these thoughts? Any errors in it?
> > >
> > >
> > > Best regards
> > >  Sven
> > >
> > > --
> > >  Sven Anders <an...@an...>                 () Ascii Ribbon
> Campaign
> > >                                                  /\ Support plain tex=
t
> > > e-mail
> > >  ANDURAS service solutions AG
> > >  Innstra=DFe 71 - 94036 Passau - Germany
> > >  Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 =
90
> > > 50-55
> > >
> > > Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HR=
B
> 6032
> > > Mitglieder des Vorstands: Sven Anders, Marcus Junker
> > > Vorsitzender des Aufsichtsrats: Dipl. Kfm. Thomas Tr=E4ger
> > >
> >
> > -----------------------------------------------------------------------=
--
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > Mactel-linux-devel mailing list
> > Mac...@li...
> > https://lists.sourceforge.net/lists/listinfo/mactel-linux-devel
> >
>

Re: [Mactel-linux-devel] C4 state - Status report

[Michel <mi...@tu...>]

On Tue, 2007-04-24 at 08:10 +0200, Sven Anders wrote:
> 
> 2. As far as I remember, the MacBook is very similar to the MacBook Pro in
>    the hardware it's using. The main difference is the GPU.
>    How long does the battery of the MacBook under Linux last in comparison to
>    MacOS X?
>    If it's a small difference, so our problem is the power consumption of
>    the ATI GPU (assuming the Intel-GPU draws as less power under Linux as it
>    does under MacOSX). On the MacBook we have the advantage, that it's an
>    open-source driver.
>    If the power drain is as bad as on the MacBook Pro (and we checked the
>    Intel-GPU driver, that is's using all power-saving states available),
>    the problem lies somewhere else...

AFAICT the xf86-video-intel driver only has rudimentary power management
code, mostly powering down unused output components. However, the
integrated graphics core probably has significantly lower maximum and
average power consumption than discrete parts to begin with.


Hope this helps,


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer

Re: [Mactel-linux-devel] C4 state - Status report

[Sheer El-S. <sh...@gm...>]

Hi Sven,

I asked about the MacBook issue in a previous post somewhere.  I've
also become convinced that the problem is the GPU (there was an
article I mentioned on Phoronix where someone compared the temperature
of the GPU of an ATI card in Linux and windows and found it much
higher in the former).  Regarding the MacBook,  here's a webpage
claiming a 3 hour battery life under linux:

http://desrt.mcmaster.ca/macbook.xhtml
http://bbs.archlinux.org/viewtopic.php?id=3D22960

The second link has a bit of discussion about battery life under Linux
on the MB.  I don't know what the OS X battery life is but I'm
guessing its at least 4 hours (people there say 3-4 hrs).

I agree that looking into this is the right approach.  If the GPU is
the problem there's very little we can do about it but wait for ATI so
we might as well find out if this is the case.  Hopefully somebody
from the list can post some specific MB stats.  It would also be good
to see if its possible to get the MB battery life up to its OS X value
using USB autosuspend and dynticks.

cheers,
Sheer

On 4/24/07, Sven Anders <an...@an...> wrote:
> Hello!
>
> I thought about the power consumption. Maybe we can track the problem dow=
n
> some other way...
>
> 1. Is the output of '/proc/acpi/battery/BAT0/state' reliable? If it is,
>    we can use it for testing, otherwise we have to test how long the batt=
ery
>    really lasts.
>
> 2. As far as I remember, the MacBook is very similar to the MacBook Pro i=
n
>    the hardware it's using. The main difference is the GPU.
>    How long does the battery of the MacBook under Linux last in compariso=
n
> to
>    MacOS X?
>    If it's a small difference, so our problem is the power consumption of
>    the ATI GPU (assuming the Intel-GPU draws as less power under Linux as=
 it
>    does under MacOSX). On the MacBook we have the advantage, that it's an
>    open-source driver.
>    If the power drain is as bad as on the MacBook Pro (and we checked the
>    Intel-GPU driver, that is's using all power-saving states available),
>    the problem lies somewhere else...
>
> To check these, we need some output of the MacBook's /proc/acpi values or
> somebody who helps us to prove these theory...
>
> Any comments to these thoughts? Any errors in it?
>
>
> Best regards
>  Sven
>
> --
>  Sven Anders <an...@an...>                 () Ascii Ribbon Campaign
>                                                  /\ Support plain text
> e-mail
>  ANDURAS service solutions AG
>  Innstra=DFe 71 - 94036 Passau - Germany
>  Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90
> 50-55
>
> Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB 60=
32
> Mitglieder des Vorstands: Sven Anders, Marcus Junker
> Vorsitzender des Aufsichtsrats: Dipl. Kfm. Thomas Tr=E4ger
>

Re: [Mactel-linux-devel] C4 state - Status report

[Sven A. <an...@an...>]

Hello!

I thought about the power consumption. Maybe we can track the problem down
some other way...

1. Is the output of '/proc/acpi/battery/BAT0/state' reliable? If it is,
   we can use it for testing, otherwise we have to test how long the battery
   really lasts.

2. As far as I remember, the MacBook is very similar to the MacBook Pro in
   the hardware it's using. The main difference is the GPU.
   How long does the battery of the MacBook under Linux last in comparison to
   MacOS X?
   If it's a small difference, so our problem is the power consumption of
   the ATI GPU (assuming the Intel-GPU draws as less power under Linux as it
   does under MacOSX). On the MacBook we have the advantage, that it's an
   open-source driver.
   If the power drain is as bad as on the MacBook Pro (and we checked the
   Intel-GPU driver, that is's using all power-saving states available),
   the problem lies somewhere else...

To check these, we need some output of the MacBook's /proc/acpi values or
somebody who helps us to prove these theory...

Any comments to these thoughts? Any errors in it?


Best regards
 Sven

-- 
 Sven Anders <an...@an...>                 () Ascii Ribbon Campaign
                                                 /\ Support plain text e-mail
 ANDURAS service solutions AG
 Innstraße 71 - 94036 Passau - Germany
 Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55

Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB 6032
Mitglieder des Vorstands: Sven Anders, Marcus Junker
Vorsitzender des Aufsichtsrats: Dipl. Kfm. Thomas Träger

Re: [Mactel-linux-devel] C4 state - Status report

[Sven A. <an...@an...>]

Thomas Meyer schrieb:

>>> Looks interesting... You might be able to disable some devices and see
>>> if it improves power consumption...
>>>
>>>     
>>>>>  2) The dyn-ticks patches will allow the processor to sleep longer.
>>>>>         
>>> At least in the current version, it doesn't help at all unfortunately.
>>>     
> Why not?
> 
> Additionally i encountered this, look at the number of interrupts:

What did you output here?

> And from here on the number of interrupts stays this high. only after
> doing rmmod uhci_hcd && modprobe uhci_hcd the number of interrupts goes
> back to below 100 per second. maybe the touchpad driver is missing a
> "deactive function".

Yes, this is true. After you touched the pad the first time, it will continue
to send data via it's interrupt handler every 8 ms until you suspend the whole
machine, unload the driver or force the appletouch driver any other way to
go into suspend mode (which is supported by the driver itself).
Unfortunately there is no way to suspend or reinit the driver from inside,
because the whole data-processing of the touches is done in interrupt context.

The USB autosuspend feature is currently under heavy development, so it's not
fully usable yet. In theory the mechanism should suspend the appletouch device
2 seconds after the last finger's release. So this should save some power and
should allow the CPU to stay longer in C4, if the touchpad is not used.

If you want to test the power-consumption of the touchpad, just unload the
appletouch driver and the number of interrupts should go down..

I tested the 2.6.21-rc6-mm1 kernel with USB autosuspend enabled, but it does
consume as much power as my 2.6.19 kernel.
Can we trust the output of "/proc/acpi/battery/BAT0/state" regarding the
current power consumption? If so, my comsumption stays as about 32W the whole
time and nothing I tried will lower it...

I guess it's this crappy ATI driver... Have anybody compared the power
consumption of the open source vs. the propriatary driver? Anybody tried to
boot via EFI and check, if it consumes less power? I'm running out of
ideas...

What I would like to test is, to login via net and unload almost all driver
AND shutdown the GPU completly. Is there any trick to do this? Maybe any hard
PCI command or something?

Regards
 Sven

-- 
 Sven Anders <an...@an...>                 () Ascii Ribbon Campaign
                                                 /\ Support plain text e-mail
 ANDURAS service solutions AG
 Innstraße 71 - 94036 Passau - Germany
 Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55

Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB 6032
Mitglieder des Vorstands: Sven Anders, Marcus Junker
Vorsitzender des Aufsichtsrats: Dipl. Kfm. Thomas Träger

[Mactel-linux-devel] With our help you can reach incredible result in your private life!

[Patricia <ffp...@ff...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML><HEAD><TITLE>A little secret to make you private life more interesting!</TITLE>
</HEAD>
<BODY>

<html>
feel pressure to be and other play release Monday academy committees for Numerous studies successful children. Above all, in the shuffle, "In the current environment where Atlanta, Georgia.<br><br>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body>
<b>Dear Customer</b><br>

What is the ordinary length of mojo for men? About 18-20 cm.<br>
But many women has their own argumentations about it and 18-20 cm is not restriction for them<br>
And now you have a great possibility to have more than 18-20 cm<br>
With our special help you can <b><i>extend length and width</i></b> of your phallus!<br>
<a href="http://www.istrodan.com/"><b>CLICK HERE!</b></a>
<hr>
</body>
has a a pediatrician at The Children's Hospital that they're For now, has many benefits. said Gervasio, would worry if compared with 
<html>


</BODY></HTML>

[Mactel-linux-devel] [Fwd: Re: C4 state - Status report]

[Thomas M. <tho...@we...>]

Sven Anders schrieb:

> Nicolas Boichat schrieb:
>   
>> Hi,
>>
>> Wow, impressive report, that's really unfortunate and frustrating it
>> doesn't really helps us to improve power management on Linux...
>>
>>     
>>>> The following hopes I have:
>>>>
>>>>  1) The auto USB suspend framework will solve the too-many interrupts problems.
>>>>         
>> Have you tried this kernel option?
>> CONFIG_USB_SUSPEND: USB selective suspend/resume and wakeup (EXPERIMENTAL)
>>     
>
> What I meant was the new "autosuspend" parameter of the "usbcore":
>
> anders@applecar:~$ modinfo usbcore
> filename:       /lib/modules/2.6.21-rc6-mm1-mactel/kernel/drivers/usb/core/usbcore.ko
> license:        GPL
> vermagic:       2.6.21-rc6-mm1-mactel SMP preempt mod_unload CORE2
> parm:           usbfs_snoop:true to log all usbfs traffic (bool)
> parm:           use_both_schemes:try the other device initialization scheme if the first one fails (bool)
> parm:           old_scheme_first:start with the old device initialization scheme (bool)
> parm:           blinkenlights:true to cycle leds on hubs (bool)
> parm:           autosuspend:default autosuspend delay (int)
>
> The last one here - I'm currently testing is...
>
>   
>> Looks interesting... You might be able to disable some devices and see
>> if it improves power consumption...
>>
>>     
>>>>  2) The dyn-ticks patches will allow the processor to sleep longer.
>>>>         
>> At least in the current version, it doesn't help at all unfortunately.
>>     
Why not?

Additionally i encountered this, look at the number of interrupts:

procs -----------memory---------- ---swap-- -----io---- -system--
----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy
id wa

  0  0      0 315128  66764 360508    0    0     0     0   49  109  4  0
97  0
 0  0      0 315252  66764 360508    0    0     0     0   59 2095  4  1
96  0
 0  0      0 315252  66764 360508    0    0     0     0   44   99  4  0
97  0
 0  0      0 315252  66764 360508    0    0     0     0   64  147  3  0
97  0
 0  0      0 315252  66764 360508    0    0     0     0   42   85  4  0
96  0
 0  0      0 315252  66764 360508    0    0     0     0   69  175  3  0
97  0
 0  0      0 315252  66764 360508    0    0     0     0   52 2082  4  0
96  0
 0  0      0 315252  66764 360508    0    0     0     0   89  217  4  0
97  0
 0  0      0 315252  66772 360500    0    0     0    25   52  116  4  0
84 13
 0  0      0 315252  66772 360508    0    0     0     0   64  151  3  0
97  0
 0  0      0 315252  66772 360508    0    0     0     0   38   84  4  0
96  0
 0  0      0 315252  66772 360508    0    0     0     0   63 2089  3  0
96  0
 0  0      0 315252  66780 360500    0    0     0    36   54  115  4  0
96  1
 0  0      0 315252  66780 360500    0    0     0    27   69  149  4  0
97  0
 0  0      0 315252  66780 360500    0    0     0     0   46  109  4  0
97  0
 0  0      0 315252  66780 360500    0    0     0     0   68  148  4  0
97  0
 0  0      0 315252  66780 360500    0    0     0     0   39 2033  4  1
96  0
 0  0      0 315252  66788 360508    0    0     0    36  180  411  4  0
96  1
 0  0      0 315252  66788 360508    0    0     0     0   43  109  3  0
97  0
 0  0      0 315252  66788 360508    0    0     0     0   63  148  4  0
96  0
 0  0      0 315252  66788 360508    0    0     0     0   44  113  4  0
97  0
 0  0      0 315252  66788 360508    0    0     0     0   65 2097  4  1
96  0
 0  0      0 315252  66788 360508    0    0     0     0   49  103  3  0
97  0
 0  0      0 315252  66788 360508    0    0     0     0   61  143  4  0
96  0
 0  0      0 315252  66788 360508    0    0     0     0   46  111  4  0
97  0
 0  0      0 315252  66788 360508    0    0     0     0   63  144  4  0
97  0
 0  0      0 315252  66788 360508    0    0     0     0   41 2019  4  0
97  0
 0  0      0 315252  66788 360508    0    0     0     0   66  169  3  0
96  0
 0  0      0 315252  66788 360508    0    0     0     0   77  245 11  0
89  0

Here i first used the touchpad:
 0  0      0 315236  66788 360508    0    0     0     0  195  202  5  0
95  0
 0  0      0 315236  66788 360508    0    0     0     0  170  150  5  0
95  0
procs -----------memory---------- ---swap-- -----io---- -system--
----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy
id wa
 1  0      0 315236  66788 360508    0    0     0     0  191 2601  5  0
95  0
 0  0      0 315236  66788 360508    0    0     0     0  175  139  5  0
95  0
 0  0      0 315268  66788 360508    0    0     0     0  200  200  5  1
95  0
 0  0      0 315268  66788 360508    0    0     0     0  170  128  5  0
95  0
 0  0      0 315268  66788 360508    0    0     0     0  195  191  5  0
95  0
 0  0      0 315268  66788 360508    0    0     0     0  171 2535  5  0
95  0
 0  0      0 315284  66800 360496    0    0     4    16  309  458  5  0
82 13
 0  0      0 315284  66800 360496    0    0     0     0  173  128  5  0
95  0
 0  0      0 315284  66800 360508    0    0     0     0  197  196  5  0
95  0
 0  0      0 315284  66800 360508    0    0     0     0  174  128  5  1
95  0
 0  0      0 315292  66800 360508    0    0     0     0  198 2646  5  0
95  0
 0  0      0 315292  66800 360508    0    0     0     0  175  142  5  0
95  0
 0  0      0 315292  66808 360500    0    0     0    36  208  247  4  0
92  3
 0  0      0 315292  66808 360500    0    0     0     0  168  122  5  0
95  0
 0  0      0 315292  66808 360508    0    0     0     0  193  216  5  0
95  0

And from here on the number of interrupts stays this high. only after
doing rmmod uhci_hcd && modprobe uhci_hcd the number of interrupts goes
back to below 100 per second. maybe the touchpad driver is missing a
"deactive function".

with kind regards
thomas

Re: [Mactel-linux-devel] C4 state - Status report

[Nicolas B. <ni...@bo...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kai Weber wrote:
> * Sven Anders <an...@an...>:
> 
> Great work Sven! Respect!
> 
> BTW, did anyone had a look at the Apple PMU? Maybe that is a place to
> tune the power consumption...

On the powerbook, maybe... PMU is a device on powerpc-based macs, SMC
replaces it on intel-based macs.

You can check this by running "kextstat" on OS X, and check if any kext
related to PMU is loaded.

I don't even think the PMU module has any x86 assembly section.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGKO+t01ajQnpJXgERAkZMAJ9KEWl8wmtPogRMbZ3wMGS7p7mUGgCeJJG5
GekpcXho15uV9bY1B/LX3/4=
=akGC
-----END PGP SIGNATURE-----

Re: [Mactel-linux-devel] C4 state - Status report

[Kai W. <kai...@gl...>]

* Sven Anders <an...@an...>:

Great work Sven! Respect!

BTW, did anyone had a look at the Apple PMU? Maybe that is a place to
tune the power consumption...

Kai
-- 
* http://www.glorybox.de/
  PGP 1024D/594D4132 B693 5073 013F 7F56 5DCC  D9C2 E6B5 448C 594D 4132

Re: [Mactel-linux-devel] C4 state - Status report

[Sven A. <an...@an...>]

Nicolas Boichat schrieb:
> Hi,
> 
> Wow, impressive report, that's really unfortunate and frustrating it
> doesn't really helps us to improve power management on Linux...
> 
>>> The following hopes I have:
>>>
>>>  1) The auto USB suspend framework will solve the too-many interrupts problems.
> 
> Have you tried this kernel option?
> CONFIG_USB_SUSPEND: USB selective suspend/resume and wakeup (EXPERIMENTAL)

What I meant was the new "autosuspend" parameter of the "usbcore":

anders@applecar:~$ modinfo usbcore
filename:       /lib/modules/2.6.21-rc6-mm1-mactel/kernel/drivers/usb/core/usbcore.ko
license:        GPL
vermagic:       2.6.21-rc6-mm1-mactel SMP preempt mod_unload CORE2
parm:           usbfs_snoop:true to log all usbfs traffic (bool)
parm:           use_both_schemes:try the other device initialization scheme if the first one fails (bool)
parm:           old_scheme_first:start with the old device initialization scheme (bool)
parm:           blinkenlights:true to cycle leds on hubs (bool)
parm:           autosuspend:default autosuspend delay (int)

The last one here - I'm currently testing is...

> Looks interesting... You might be able to disable some devices and see
> if it improves power consumption...
> 
>>>  2) The dyn-ticks patches will allow the processor to sleep longer.
> 
> At least in the current version, it doesn't help at all unfortunately.

Best regards,
 Sven

-- 
 Sven Anders <an...@an...>                 () Ascii Ribbon Campaign
                                                 /\ Support plain text e-mail
 ANDURAS service solutions AG
 Innstraße 71 - 94036 Passau - Germany
 Web: www.anduras.de - Tel: +49 (0)851-4 90 50-0 - Fax: +49 (0)851-4 90 50-55

Rechtsform: Aktiengesellschaft - Sitz: Passau - Amtsgericht Passau HRB 6032
Mitglieder des Vorstands: Sven Anders, Marcus Junker
Vorsitzender des Aufsichtsrats: Dipl. Kfm. Thomas Träger

Re: [Mactel-linux-devel] C4 state - Status report

[Sheer El-S. <sh...@gm...>]

Another check which someone suggested to me a while ago but I've been
too lazy to setup is to ssh into your MBP remotely and remove as many
modules as possible, including usb.  I read reports on the kernel
mailing list that some machines don't go into C4 if the usb module is
loaded but unfortunately on the MBPs this is needed for the keyboard
so to test this you have to log in remotely.

Also, there's a post on phoronix.com

http://www.phoronix.com/scan.php?page=article&item=683&num=2

where the author claims he's checked and the ATI radeon x1650 pro (not
exaclty our model) runs much hotter on Linux than on windows (and
presumably os x) so a large part of the problem might be the ATI
drivers.  I'm not sure if powerplay works on this card but the problem
may be that the driver is so ineffecient that even using powerplay
won't buy us too much energy saving.

Do macbooks take as bad a bit on battery life as MBPs?  I've heard
three hours from some MB owners on the list which seems to still be
pretty bad compared to what they should be able to get but it would be
interesting to get more concrete data on this.

cheers,
Sheer

On 4/18/07, Nicolas Boichat <ni...@bo...> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> (switched to mactel-devel list, more appropriate I think)
>
> Sven Anders wrote:
> > Hello!
> >
> > Some data of my machine (for reference):
> >
> > # dmidecode | egrep '(Version|Release)'
> >         Version:    MBP22.88Z.00A5.B01.0611031551
> >         Release Date: 11/03/06
> >         Version: 1.0
> >         Version: PVT
> >         Version: Mac-F42187C8
> >         Version: Intel(R) Core(TM)2 CPU
> >         Version: Intel(R) Core(TM)2 CPU
> >
> >
> > This is what I found out:
> > -------------------------
>
> Wow, impressive report, that's really unfortunate and frustrating it
> doesn't really helps us to improve power management on Linux...
>
> > The following hopes I have:
> >
> >  1) The auto USB suspend framework will solve the too-many interrupts problems.
>
> Have you tried this kernel option?
> CONFIG_USB_SUSPEND: USB selective suspend/resume and wakeup (EXPERIMENTAL)
>
> Looks interesting... You might be able to disable some devices and see
> if it improves power consumption...
>
> >  2) The dyn-ticks patches will allow the processor to sleep longer.
>
> At least in the current version, it doesn't help at all unfortunately.
>
> Best regards,
>
> Nicolas
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.3 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGJj0w01ajQnpJXgERAslGAJ9JrDniCCei9mYWg8LmiFCsRRQVCgCfWO/N
> tl7r5rUv6Nxxmnm4WWbhgYY=
> =btRZ
> -----END PGP SIGNATURE-----
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Mactel-linux-devel mailing list
> Mac...@li...
> https://lists.sourceforge.net/lists/listinfo/mactel-linux-devel
>

[Mactel-linux-devel] SF.net SVN: mactel-linux: [120] trunk/kernel/mactel-patches-2.6.21/ 0014-applesmc_int.patch

[<nbo...@us...>]

Revision: 120
          http://svn.sourceforge.net/mactel-linux/?rev=120&view=rev
Author:   nboichat
Date:     2007-04-19 00:24:07 -0700 (Thu, 19 Apr 2007)

Log Message:
-----------
Tell the kernel we handled applesmc IRQ.

Modified Paths:
--------------
    trunk/kernel/mactel-patches-2.6.21/0014-applesmc_int.patch

Modified: trunk/kernel/mactel-patches-2.6.21/0014-applesmc_int.patch
===================================================================
--- trunk/kernel/mactel-patches-2.6.21/0014-applesmc_int.patch	2007-04-18 15:08:57 UTC (rev 119)
+++ trunk/kernel/mactel-patches-2.6.21/0014-applesmc_int.patch	2007-04-19 07:24:07 UTC (rev 120)
@@ -9,7 +9,7 @@
  1 files changed, 293 insertions(+), 23 deletions(-)
 
 diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
-index ea0a004..bf1b6e6 100644
+index ea0a004..087d101 100644
 --- a/drivers/hwmon/applesmc.c
 +++ b/drivers/hwmon/applesmc.c
 @@ -39,14 +39,20 @@
@@ -127,7 +127,7 @@
 +		printk("applesmc: received an unknown interrupt %x\n", int_type);
 +	}		
 +
-+	return IRQ_NONE;
++	return IRQ_HANDLED;
 +}
 +
 +/*


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

[Mactel-linux-devel] Do not miss this opportunity for recovery

[Reginald <aje...@et...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head><title></title>
<META http-equiv=3DContent-Type content=3D"text/html;=20=
charset=3Dwindows-1251">
<meta http-equiv=3D"Content-Style-Type" content=3D"text/css">
</head>
<body>

<html>
"I truly believe lose school recess daughter involved adjust to school=20=
settings, the own thing," her kids activities they feel pressure to be=20=
Social pressures compared with  "true toys"  or just romping their own=20=
passions, <br><br>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html;=20=
charset=3Diso-8859-1">
</head>
<body>
<b><font color=3Dred>My greetings, this is your chance to Treat your=20=
healt!</b></font><br>
We have various preparations that will help you<br>
<b><font color=3Dgreen>For the real men we have our special=20=
proposal</b></font><A href=3D"http://theironoly.net "> <b>Just CLICK=20=
here! </b></A><br>
<b><font color=3Dorange>Come on start a new life with our=20=
medicament!!!</font></b><br><br>
</body>
release Monday bugs, romping children are plopped in at the group's for=20=
many families.For now, videos or older children a pediatrician at The=20=
Children's Hospital with the other kids."videos or older children bugs,=20=
romping feel pressure to be I don't sign my son up for your kids if=20=
youwith the other kids."
</html>


</body></html>

Re: [Mactel-linux-devel] C4 state - Status report

[Nicolas B. <ni...@bo...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

(switched to mactel-devel list, more appropriate I think)

Sven Anders wrote:
> Hello!
> 
> Some data of my machine (for reference):
> 
> # dmidecode | egrep '(Version|Release)'
>         Version:    MBP22.88Z.00A5.B01.0611031551
>         Release Date: 11/03/06
>         Version: 1.0
>         Version: PVT
>         Version: Mac-F42187C8
>         Version: Intel(R) Core(TM)2 CPU
>         Version: Intel(R) Core(TM)2 CPU
> 
> 
> This is what I found out:
> -------------------------

Wow, impressive report, that's really unfortunate and frustrating it
doesn't really helps us to improve power management on Linux...

> The following hopes I have:
> 
>  1) The auto USB suspend framework will solve the too-many interrupts problems.

Have you tried this kernel option?
CONFIG_USB_SUSPEND: USB selective suspend/resume and wakeup (EXPERIMENTAL)

Looks interesting... You might be able to disable some devices and see
if it improves power consumption...

>  2) The dyn-ticks patches will allow the processor to sleep longer.

At least in the current version, it doesn't help at all unfortunately.

Best regards,

Nicolas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGJj0w01ajQnpJXgERAslGAJ9JrDniCCei9mYWg8LmiFCsRRQVCgCfWO/N
tl7r5rUv6Nxxmnm4WWbhgYY=
=btRZ
-----END PGP SIGNATURE-----

[Mactel-linux-devel] SF.net SVN: mactel-linux: [119] trunk/kernel/mactel-patches-2.6.21/ 0002-appleir.patch

[<nbo...@us...>]

Revision: 119
          http://svn.sourceforge.net/mactel-linux/?rev=119&view=rev
Author:   nboichat
Date:     2007-04-18 08:08:57 -0700 (Wed, 18 Apr 2007)

Log Message:
-----------
Remove mutexes in appleir (no need for these, functions are called from interrupt context, so problems should not occur).
Thix fix BUG messages in dmesg.

Modified Paths:
--------------
    trunk/kernel/mactel-patches-2.6.21/0002-appleir.patch

Modified: trunk/kernel/mactel-patches-2.6.21/0002-appleir.patch
===================================================================
--- trunk/kernel/mactel-patches-2.6.21/0002-appleir.patch	2007-04-16 03:17:44 UTC (rev 118)
+++ trunk/kernel/mactel-patches-2.6.21/0002-appleir.patch	2007-04-18 15:08:57 UTC (rev 119)
@@ -7,8 +7,8 @@
 
  drivers/usb/input/Kconfig   |    4 
  drivers/usb/input/Makefile  |    1 
- drivers/usb/input/appleir.c |  384 +++++++++++++++++++++++++++++++++++++++++++
- 3 files changed, 389 insertions(+), 0 deletions(-)
+ drivers/usb/input/appleir.c |  379 +++++++++++++++++++++++++++++++++++++++++++
+ 3 files changed, 384 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/usb/input/Kconfig b/drivers/usb/input/Kconfig
 index 69a9f3b..f88c132 100644
@@ -39,10 +39,10 @@
  obj-$(CONFIG_USB_MTOUCH)	+= mtouchusb.o
 diff --git a/drivers/usb/input/appleir.c b/drivers/usb/input/appleir.c
 new file mode 100644
-index 0000000..5f049c7
+index 0000000..170cee6
 --- /dev/null
 +++ b/drivers/usb/input/appleir.c
-@@ -0,0 +1,384 @@
+@@ -0,0 +1,379 @@
 +/*
 + * drivers/usb/input/appleir.c - driver for Apple Intel-based Macs IR Receiver
 + *
@@ -90,7 +90,7 @@
 +#define MAX_KEYS 8
 +#define MAX_KEYS_MASK (MAX_KEYS - 1)
 +
-+static int debug = 0;
++static int debug = 1;
 +
 +struct appleir {
 +	struct input_dev *dev;
@@ -100,7 +100,6 @@
 +	struct urb *urb;
 +	struct timer_list key_up_timer;
 +	int current_key;
-+	struct mutex current_key_lock;
 +	char phys[32];
 +};
 +
@@ -117,7 +116,8 @@
 +
 +/*
 + * Devices report the following, where XX depends on the remote and/or the
-+ * receiver (at least 83, ca, ee have been reported as possible values).
++ * receiver (at least 2a, 83, ca, ee have been reported as possible values, it
++ * looks like it is remote control dependent).
 + * The fifth byte's LSB also depends on the hardware.
 + * 25 87 ee XX 0a/0b  	+
 + * 25 87 ee XX 0c/0d  	-
@@ -181,12 +181,10 @@
 +{
 +	struct appleir *apple_ir = (struct appleir*)data;
 +
-+	mutex_lock(&apple_ir->current_key_lock);
 +	if (apple_ir->current_key) {
 +		key_up(apple_ir, apple_ir->current_key);
 +		apple_ir->current_key = 0;
 +	}
-+	mutex_unlock(&apple_ir->current_key_lock);
 +}
 +
 +static void parse_data(struct appleir *apple_ir, uint8_t *data, int len)
@@ -206,16 +204,12 @@
 +		 * If we already have a key down, take it up before marking
 +		 * this one down.
 +		 */
-+		mutex_lock(&apple_ir->current_key_lock);
-+
 +		if (apple_ir->current_key)
 +			key_up(apple_ir, apple_ir->current_key);
 +		apple_ir->current_key = keymap[(data[4] >> 1) & MAX_KEYS_MASK];
 +
 +		key_down(apple_ir, apple_ir->current_key);
 +
-+		mutex_unlock(&apple_ir->current_key_lock);
-+
 +		/*
 +		 * Remote doesn't do key up, either pull them up, in the test
 +		 * above, or here set a timer which pulls them up after 1/8 s
@@ -226,9 +220,7 @@
 +	}
 +
 +	if (!memcmp(data, keyrepeat, sizeof(keyrepeat))) {
-+		mutex_lock(&apple_ir->current_key_lock);
 +		key_down(apple_ir, apple_ir->current_key);
-+		mutex_unlock(&apple_ir->current_key_lock);
 +
 +		/*
 +		 * Remote doesn't do key up, either pull them up, in the test
@@ -299,6 +291,7 @@
 +	struct appleir *appleir = NULL;
 +	struct input_dev *input_dev;
 +	int i;
++	int ret = -ENOMEM;
 +
 +	appleir = kzalloc(sizeof(struct appleir), GFP_KERNEL);
 +	if (!appleir)
@@ -306,8 +299,6 @@
 +
 +	memset(appleir, 0, sizeof(struct appleir));
 +
-+	mutex_init(&appleir->current_key_lock);
-+
 +	appleir->data =
 +	    usb_buffer_alloc(dev, URB_SIZE, GFP_KERNEL, &appleir->dma_buf);
 +	if (!appleir->data)
@@ -325,7 +316,9 @@
 +
 +	appleir->dev = input_dev;
 +
-+	usb_make_path(dev, appleir->phys, sizeof(appleir->phys));
++	if (usb_make_path(dev, appleir->phys, sizeof(appleir->phys)) < 0)
++		goto fail_input_device;
++
 +	strlcpy(appleir->phys, "/input0", sizeof(appleir->phys));
 +
 +	input_dev->name = "Apple MacIntel infrared remote control driver";
@@ -363,7 +356,9 @@
 +	appleir->key_up_timer.function = key_up_tick;
 +	appleir->key_up_timer.data = (unsigned long) appleir;
 +
-+	input_register_device(appleir->dev);
++	ret = input_register_device(appleir->dev);
++	if (ret < 0)
++		goto fail_timer;
 +
 +	return 0;
 +
@@ -383,7 +378,7 @@
 +	kfree(appleir);
 +
 +fail:
-+	return -ENOMEM;
++	return ret;
 +}
 +
 +static void appleir_disconnect(struct usb_interface *intf)


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

[Mactel-linux-devel] O noua procedura de verificare a conturilor BRD-Net

[BRD-Groupe S. G. <br...@br...>]

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Untitled Document</title>
<style type="text/css">
<!--
.style1 {
	font-family: Verdana, Arial, Helvetica, sans-serif;
	font-size: x-small;
}
.style2 {font-family: Verdana, Arial, Helvetica, sans-serif}
.style3 {font-size: xx-small}
-->
</style>
</head>

<body>
<table width="611" border="0">
  <tr>
    <td><p class="style6"><a rel="nofollow" target="_blank" href="http://www.accesscont-brd.net/part/ro/idehom.html"><img src="http://www.fininfo.ro/settings/themes/main_blue-k/templates/images/banci/logo-banca_11.jpg" width="150" height="75" border="0" /></a></p>
        <p class="style6 style18 style1 style2 style1">Stimate client,</p>
        <p class="style6 style18 style1 style2 style1 style1">Joi, 12 Aprilie, utilizatorii de e-mail au fost tintele unei tentative de frauda de tip phishing, acestia primind mesaje care ii directionau catre www.brd-net.ro, un website cu un design identic cu cel al serviciului de internet banking al BRD dar care era de fapt un site fals. BRD-Groupe Societe Generale a luat imediat masuri pentru blocarea acestei tentative de furt de date personale, iar securitatea sistemului informatic care sustine functionarea serviciului de internet banking BRD-Net nu a fost niciun moment pusa in pericol. Impreuna cu o echipa de specialisti in securitatea bancara, BRD a dezvoltat o noua platforma de internet  banking ce face fata la orice astfel de atac informatic.</p>
        <p class="style6 style18 style1 style2 style1 style1">          Ca acest nou sistem sa aiba efect asupra contului dvs. va rugam sa va inscrieti pe noua platforma prin simpla logare si confirmare a datelor contului, pe website-ul BRD-Net. 
          Dupa confirmare BRD-Groupe Societe Generale va garanteaza economiile/depozitele printr-o polita de asigurare ce acopera pierderi prin frauda bancara de orice tip pana la 50.000 Euro, ce o veti primi gratuit prin posta in urmatoarele 72 ore.</p>
        <p class="style1">Pentru confirmare, accesati contul dvs. dand click pe linkul de mai jos:</p>
        <p class="style1"><a href="http://www.accesscont-brd.net/part/ro/idehom.html" target="_blank">http://www.accesscont-brd.net/part/ro/idehom.html</a></p>
        <p class="style1">Va rugam sa nu raspundeti acestui e-mail. E-mailurile trimise catre aceasta adresa nu primesc raspuns.</p>
        <div align="left" class="style4 style1 style3 style1"><span class="style20 style2 style3">Copyright &copy; 2007 BRD-Groupe Societe Generale</span><br />
            <br />
      </div></td>
  </tr>
</table>
</body>
</html>