t41, suspend on ram, power consumption

t41, suspend on ram, power consumption

[Frédéric Gobry]

Hi,

On my Thinkpad T41, I try to use ACPI (Debian unstable, kernel 2.6.15)
to suspend the system on RAM. It works quite well (ie, it goes to sleep
and resumes properly), but I guess that some hardware parts are not
actually stopped properly, as:

  - the autonomy of the mode is very short (a few hours for a fully
    charged battery), whereas I managed to get at least one day of
    autonomy when APM used to work.

  - the laptop gets warm

Do you have an idea what could cause this behavior, or alternatively how
I could start tracking it down myself?

thanks,

Frédéric


Jan 13 10:06:45 mnementh kernel: Stopping tasks: ===================================================================================|
Jan 13 10:06:45 mnementh kernel: ACPI: PCI interrupt for device 0000:02:02.0 disabled
Jan 13 10:06:45 mnementh kernel: ACPI: PCI interrupt for device 0000:02:01.0 disabled
Jan 13 10:06:45 mnementh kernel: ACPI: PCI interrupt for device 0000:02:00.1 disabled
Jan 13 10:06:45 mnementh kernel: ACPI: PCI interrupt for device 0000:02:00.0 disabled
Jan 13 10:06:45 mnementh kernel: ACPI: PCI interrupt for device 0000:00:1f.6 disabled
Jan 13 10:06:45 mnementh kernel: ACPI: PCI interrupt for device 0000:00:1f.5 disabled
Jan 13 10:06:45 mnementh kernel: ACPI: PCI interrupt for device 0000:00:1d.7 disabled
Jan 13 10:06:45 mnementh kernel: ACPI: PCI interrupt for device 0000:00:1d.2 disabled
Jan 13 10:06:45 mnementh kernel: ACPI: PCI interrupt for device 0000:00:1d.1 disabled
Jan 13 10:06:45 mnementh kernel: ACPI: PCI interrupt for device 0000:00:1d.0 disabled
Jan 13 10:06:45 mnementh kernel: Intel machine check architecture supported.
Jan 13 10:06:45 mnementh kernel: Intel machine check reporting enabled on CPU#0.
Jan 13 10:06:45 mnementh kernel: PCI: Enabling device 0000:00:1d.0 (0000 -> 0001)
Jan 13 10:06:45 mnementh kernel: ACPI: PCI Interrupt 0000:00:1d.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
Jan 13 10:06:45 mnementh kernel: PCI: Enabling device 0000:00:1d.1 (0000 -> 0001)
Jan 13 10:06:45 mnementh kernel: ACPI: PCI Interrupt 0000:00:1d.1[B] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
Jan 13 10:06:45 mnementh kernel: PCI: Enabling device 0000:00:1d.2 (0000 -> 0001)
Jan 13 10:06:45 mnementh kernel: ACPI: PCI Interrupt 0000:00:1d.2[C] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
Jan 13 10:06:45 mnementh kernel: PCI: Enabling device 0000:00:1d.7 (0000 -> 0002)
Jan 13 10:06:45 mnementh kernel: ACPI: PCI Interrupt 0000:00:1d.7[D] -> Link [LNKH] -> GSI 11 (level, low) -> IRQ 11
Jan 13 10:06:45 mnementh kernel: ehci_hcd 0000:00:1d.7: debug port 1
Jan 13 10:06:45 mnementh kernel: ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
Jan 13 10:06:45 mnementh kernel: ACPI: PCI Interrupt 0000:00:1f.1[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
Jan 13 10:06:45 mnementh kernel: ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11
Jan 13 10:06:45 mnementh kernel: ACPI: PCI Interrupt 0000:00:1f.6[B] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11
Jan 13 10:06:45 mnementh kernel: ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
Jan 13 10:06:45 mnementh kernel: ACPI: PCI Interrupt 0000:02:00.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
Jan 13 10:06:45 mnementh kernel: ACPI: PCI Interrupt 0000:02:00.1[B] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11
Jan 13 10:06:45 mnementh kernel: ACPI: PCI Interrupt 0000:02:01.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
Jan 13 10:06:45 mnementh kernel: ACPI: PCI Interrupt 0000:02:02.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
Jan 13 10:06:45 mnementh kernel: e1000: eth0: e1000_watchdog_task: NIC Link is Up 100 Mbps Full Duplex
Jan 13 10:06:45 mnementh kernel: Restarting tasks...<3>hub 2-0:1.0: over-current change on port 1
Jan 13 10:06:45 mnementh kernel:  done
Jan 13 10:06:45 mnementh kernel: agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
Jan 13 10:06:45 mnementh kernel: agpgart: Putting AGP V2 device at 0000:00:00.0 into 1x mode
Jan 13 10:06:45 mnementh kernel: agpgart: Putting AGP V2 device at 0000:01:00.0 into 1x mode
Jan 13 10:15:26 mnementh kernel: usb 3-1: new full speed USB device using uhci_hcd and address 2
Jan 13 10:15:26 mnementh kernel: Bluetooth: HCI USB driver ver 2.9
Jan 13 10:15:26 mnementh kernel: usbcore: registered new driver hci_usb
Jan 13 10:15:29 mnementh kernel: usb 3-1: USB disconnect, address 2


  
-- 
Frédéric Gobry    Infoscience
                  SISB / EPFL
                  Tel: +41216932288
http://people.epfl.ch/frederic.gobry

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: t41, suspend on ram, power consumption

[foo_bar_baz_boo-acpi-/E1597aS9LQAvxtiuMwx3w]

--- Frédéric Gobry <frederic.gobry-p8DiymsW2f8@public.gmane.org> wrote:
> Hi,
> 
> On my Thinkpad T41, I try to use ACPI (Debian unstable, kernel
> 2.6.15)
> to suspend the system on RAM. It works quite well (ie, it goes to
> sleep
> and resumes properly), but I guess that some hardware parts are not
> actually stopped properly, as:
> 
>   - the autonomy of the mode is very short (a few hours for a fully
>     charged battery), whereas I managed to get at least one day of
>     autonomy when APM used to work.
> 
>   - the laptop gets warm
> 
> Do you have an idea what could cause this behavior, or alternatively
> how
> I could start tracking it down myself?
> 
> thanks,
> 
> Frédéric

I'll take a stab at this.

Please install cpufreqd to control the speed of the CPU. You'll need to
enable some underlying kernel support, something along the lines of:
CONFIG_CPU_FREQ and friends.

Additionally, you probably want to consider the suspend2 kernel patch
series from http://www.suspend2.net/ to allow for reliably shutting the
system off without losing state and storing memory into your swap
partition or a file.

You'll probably want to poke around /proc/acpi and such to find out if
C1, C2, and C3 are getting entered a reasonable amount of time by the
processor. This might lead to the possibility that one or multiple of
these states are underused, which could be caused by anything from a
kernel bug to some kind of problem with your DSDT that prevents one or
more of these states from being marked as available.

Last thing I can think of, try building a kernel that uses APM (it's
still available under Power Management as far as I recall) instead of
ACPI and see how it works for comparison purposes.

Good Luck!
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: t41, suspend on ram, power consumption

[Frédéric Gobry]

(sorry for answered with more questions, I really wish to understand how
all that stuff operates together)

> Please install cpufreqd to control the speed of the CPU. You'll need to
> enable some underlying kernel support, something along the lines of:
> CONFIG_CPU_FREQ and friends.

I use powernowd: would it make a difference?

> Additionally, you probably want to consider the suspend2 kernel patch
> series from http://www.suspend2.net/ to allow for reliably shutting the
> system off without losing state and storing memory into your swap
> partition or a file.

Does suspend2 change the behavior of the system for suspend to mem, or
is it only for suspend to disk? I hesitated to use these patches, as the
debian kernel is far from a vanilla kernel, and I don't think they
packaged a version of it.

> You'll probably want to poke around /proc/acpi and such to find out if
> C1, C2, and C3 are getting entered a reasonable amount of time by the
> processor. This might lead to the possibility that one or multiple of
> these states are underused, which could be caused by anything from a
> kernel bug to some kind of problem with your DSDT that prevents one or
> more of these states from being marked as available.

The system actually goes in sleep mode, I don't know which part of the
hardware does not. By comparing the list of PCI devices being disabled
(in the log I sent in the previous message) with the output of lspci, it
seems that the graphical card is not disabled. But I don't know if some
other part of the code does the job, neither do I know what this
'disabled' state actually means (maybe only regarding interrupts?)

> Last thing I can think of, try building a kernel that uses APM (it's
> still available under Power Management as far as I recall) instead of
> ACPI and see how it works for comparison purposes.

I was hoping I could start using debian's packaged kernels again :-) In
fact, APM worked well in 2.6.8, but from that version upward, it really
was a source of random crashes when the system was going up again. I was
not using then hibernate script at that time. Do you think it would have
improved the experience?

Frédéric

-- 
Frédéric Gobry    Infoscience
                  SISB / EPFL
                  Tel: +41216932288
http://people.epfl.ch/frederic.gobry

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: t41, suspend on ram, power consumption

[Luca Capello]

[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]

Hello!

On Fri, 13 Jan 2006 14:30:23 +0100, Frédéric Gobry wrote:
>> Additionally, you probably want to consider the suspend2 kernel
>> patch series from http://www.suspend2.net/ to allow for reliably
>> shutting the system off without losing state and storing memory
>> into your swap partition or a file.
>
> Does suspend2 change the behavior of the system for suspend to mem,
> or is it only for suspend to disk? I hesitated to use these patches,
> as the debian kernel is far from a vanilla kernel, and I don't think
> they packaged a version of it.

As you're on Debian:
=====
$ apt-cache search suspend2
kernel-patch-suspend2 - Linux kernel patch for software suspend 2

$ apt-cache policy kernel-patch-suspend2
kernel-patch-suspend2:
  Installed: (none)
  Candidate: 2.1.9.9-4
  Version table:
     2.1.9.9-4 0
          1 http://debian.fastweb.it experimental/main Packages
=====

FWIW, I've a T42p with a vanilla 2.6.15: suspend-to-ram and
suspend-to-disk works out of the box, with all the drivers enabled
(included ipw2100, radeonfb and Xorg radeon without DRI), even with
multiple repeated cycles.

BTW, I'm on Debian unstable ;-)

Thx, bye,
Gismo / Luca

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: t41, suspend on ram, power consumption

[Frédéric Gobry]

>           1 http://debian.fastweb.it experimental/main Packages

aha ! that's why my own apt-cache search returned nothing :-)

> FWIW, I've a T42p with a vanilla 2.6.15: suspend-to-ram and
> suspend-to-disk works out of the box, with all the drivers enabled
> (included ipw2100, radeonfb and Xorg radeon without DRI), even with
> multiple repeated cycles.

vanilla 2.6.15 means "debian-vanilla" or vanilla from kernel.org ?

I use the radeon and dri modules, maybe I should try your setup. I'd be
sad to give up dri, though.

Frédéric

-- 
Frédéric Gobry    Infoscience
                  SISB / EPFL
                  Tel: +41216932288
http://people.epfl.ch/frederic.gobry

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: t41, suspend on ram, power consumption

[Luca Capello]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

Hello!

On Fri, 13 Jan 2006 15:12:32 +0100, Frédéric Gobry wrote:
>>           1 http://debian.fastweb.it experimental/main Packages
>
> aha ! that's why my own apt-cache search returned nothing :-)

And that's why I put that line ;-)

>> FWIW, I've a T42p with a vanilla 2.6.15: suspend-to-ram and
>> suspend-to-disk works out of the box, with all the drivers enabled
>> (included ipw2100, radeonfb and Xorg radeon without DRI), even with
>> multiple repeated cycles.
>
> vanilla 2.6.15 means "debian-vanilla" or vanilla from kernel.org ?

"vanilla" = "kernel.org".  The kernel is the only thing I compile by
myself.

> I use the radeon and dri modules, maybe I should try your setup. I'd
> be sad to give up dri, though.

I suggest to try without DRI and from the console.  Then in a console
and so on.  A lot were my tests...

Thx, bye,
Gismo / Luca

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: t41, suspend on ram, power consumption

[Stefan Seyfried]

On Fri, Jan 13, 2006 at 02:16:38AM -0800, foo_bar_baz_boo-acpi-/E1597aS9LQ@public.gmane.orgm wrote:
> --- Frédéric Gobry <frederic.gobry-p8DiymsW2f8@public.gmane.org> wrote:
> > Hi,
> > 
> > On my Thinkpad T41, I try to use ACPI (Debian unstable, kernel
> > 2.6.15)
> > to suspend the system on RAM. It works quite well (ie, it goes to
> > sleep
> > and resumes properly), but I guess that some hardware parts are not
> > actually stopped properly, as:
> > 
> >   - the autonomy of the mode is very short (a few hours for a fully
> >     charged battery), whereas I managed to get at least one day of
> >     autonomy when APM used to work.
> > 
> >   - the laptop gets warm
> > 
> > Do you have an idea what could cause this behavior, or alternatively
> > how
> > I could start tracking it down myself?

There have been some "thinkpad needs to much energy when suspended" reports
some time ago. Probably search the archives of the thinkpad list for
solutions. IIRC it was the graphics chip that was not completely shut down.

> > thanks,
> > 
> > Frédéric
> 
> I'll take a stab at this.

And you are writing completely unrelated stuff.
 
> Please install cpufreqd to control the speed of the CPU. You'll need to
> enable some underlying kernel support, something along the lines of:
> CONFIG_CPU_FREQ and friends.

Has nothing to do at all with the power consumption when the system is
suspended.

> Additionally, you probably want to consider the suspend2 kernel patch
> series from http://www.suspend2.net/ to allow for reliably shutting the
> system off without losing state and storing memory into your swap
> partition or a file.

Has nothing to do at all with suspend to ram and the power consumption
when suspended.
 
> You'll probably want to poke around /proc/acpi and such to find out if
> C1, C2, and C3 are getting entered a reasonable amount of time by the
> processor. This might lead to the possibility that one or multiple of
> these states are underused, which could be caused by anything from a
> kernel bug to some kind of problem with your DSDT that prevents one or
> more of these states from being marked as available.

Has nothing to do at all with the power consumption when the system is
suspended.
 
> Last thing I can think of, try building a kernel that uses APM (it's
> still available under Power Management as far as I recall) instead of
> ACPI and see how it works for comparison purposes.

He already wrote that the system was suspending for a longer time with
APM.
-- 
Stefan Seyfried

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: t41, suspend on ram, power consumption

[Bruno Ducrot]

On Tue, Jan 17, 2006 at 09:37:32PM +0100, Stefan Seyfried wrote:
> > Additionally, you probably want to consider the suspend2 kernel patch
> > series from http://www.suspend2.net/ to allow for reliably shutting the
> > system off without losing state and storing memory into your swap
> > partition or a file.
> 
> Has nothing to do at all with suspend to ram and the power consumption
> when suspended.

I'm not sure you are right with that claim.  There may be some code
onto suspend2 patches that may help improve suspend/resume devices that
are not yet merged to mainline.  I don't think however this fill fix
the thinkpad problem of the OP though.

It's actually more or less a guess since I have not looked actually to
the suspend2 code.

-- 
Bruno Ducrot

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

Re: t41, suspend on ram, power consumption

[Matthew Garrett]

On Thu, Jan 19, 2006 at 11:50:01AM +0100, Bruno Ducrot wrote:

> I'm not sure you are right with that claim.  There may be some code
> onto suspend2 patches that may help improve suspend/resume devices that
> are not yet merged to mainline.  I don't think however this fill fix
> the thinkpad problem of the OP though.

Last time I checked, there was some code to restore AGP bridge state. 
I think that's pretty much it.
 
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: t41, suspend on ram, power consumption

[Vernon Mauery]

Bruno Ducrot wrote:
> On Tue, Jan 17, 2006 at 09:37:32PM +0100, Stefan Seyfried wrote:
> 
>>>Additionally, you probably want to consider the suspend2 kernel patch
>>>series from http://www.suspend2.net/ to allow for reliably shutting the
>>>system off without losing state and storing memory into your swap
>>>partition or a file.
>>
>>Has nothing to do at all with suspend to ram and the power consumption
>>when suspended.
> 
> 
> I'm not sure you are right with that claim.  There may be some code
> onto suspend2 patches that may help improve suspend/resume devices that
> are not yet merged to mainline.  I don't think however this fill fix
> the thinkpad problem of the OP though.

See "S3: high power consumption - Thinkpad T40/T41"
http://bugme.osdl.org/show_bug.cgi?id=3022

They have a patch that applies to the mainline kernel and fixes the problem.  It
is a video problem.  If the patch doesn't work immediatly for you, you might
have to add video=radeonfb:force_sleep=1 to the kernel command line and then add
your machine's dmi data to the whitelist.  The whitelist is pretty big by now,
though, so you may already be covered.

--Vernon

> 
> It's actually more or less a guess since I have not looked actually to
> the suspend2 code.
>