[Debian-eeepc-devel] 1201n and pm-utils : pm-hibernate/pm-suspend

Alan Jenkins sourcejedi.lkml at googlemail.com
Mon Feb 8 09:02:08 UTC 2010


On 2/7/10, giggzounet <giggzounet at gmail.com> wrote:
> Alan Jenkins a écrit :
>> On 2/6/10, giggzounet <giggzounet at gmail.com> wrote:
>>> Hi,
>>>
>>> On my eeepc 1201n + lenny + backports + eeepc script from sid I have
>>> tested the pm-utils things :
>>>
>>> pm-hibernate seems to work without problem. I just enter "sudo
>>> pm-hibernate" and it seems to work : after resume I have internet
>>> through the ethernet card. sound. video.
>>>
>>> pm-suspend seems to work under X but not under a tty1. Is it normal ?
>>> under X If I enter "sudo pm-suspend" then I resume, all seems to work.
>>> But under a virtual terminal, I don't have the video after resume. is
>>> there a trick ?
>>
>> This is somewhat expected.
>>
>> You're not using the experimental free noveau kernel mode-setting
>> driver.  So the kernel can't restore the video card state.  You're
>> relying on the proprietary X driver to restore the video card state.
>>
>
> I don't understand.
> Under X (so with nvidia driver) it works great. But when I kill X...so
> no more nvidia proprio driver. and I enter "sudo pm-suspend" on a tty. I
> can't resume the video.
>
> Is the framebuffer necessary to resume ?

There isn't a standard way to resume (re-initialize) the video of an
"IBM PC".  In practice ACPI doesn't provide any help either.
Therefore you *need* either a BIOS-specific quirk, or a video-card
specific driver.  Does that explain it?

So without a working quirk, X with nvidia or nv can work, but not a
generic driver like the X vesa driver, or the kernel text console
driver.  Noveau can also work, and the latest version includes a
kernel modesetting driver, so it can work without X.

>> There are a couple of quirks like the "s3 bios" one, which may be used
>> to try and get the BIOS to re-initialize the video card.  (You can
>> find more about this in the documentation for the s2ram command on the
>> SuSE wiki.)  But I wouldn't bother with it; there are many different
>> combinations and there's no guarantee that you'll find a working one.
>>
>
> Thx for the tip.
>
>>> When I press the fn+f2 button the eeepc goes to sleep. But I'm seeing in
>>> the /etc/default/eeepc-script file that --quirk-s3-bios is used. Is
>>> there a reason ? what does it add for an eeepc ?
>>
>> See above, I guess.  It's clearly not working on your machine.
>>
>>> I would like that my eeepc goes into suspend to ram when I close the
>>> LID. I have seen the LID_CLOSE_ACTION= option. WHat is the right command
>>> to enter ? I have try pm-suspend and I got a relativ serious problem :
>>> the eeepc has brutally stopped with a temperature of 95°C...I don't know
>>> exactly where is the problem. but it comes from the suspend. (I'm using
>>> nvidia proprio driver)
>>
>> It's not very clear what you mean.  But I doubt there's much you can
>> do about it, other than trying to installing the experimental noveau
>> driver.  I don't see why pm-suspend should do that, other than a
>> driver bug of some sort.
>>
>
> With the LID_CLOSE_ACTION= option : I mean I want that my computer go to
> sleep when I close the lid. How I do that correctly ?

It should be correct to use pm-suspend as you've described.

>> If you want to isolate the problem, you should try the open source
>> stable NV driver for X.  On some (most?) systems it is even able to
>> resume the video card.  Even if it can't, you're saying your problem
>> happens before resume, right?  So if it still happens, you would then
>> be able to ask for help from the open-source devs.
>>
>
> This temperature problem was total new. And was not reproducible after
> new test with suspend/resume. I will try to investigate further.

Good luck!



More information about the Debian-eeepc-devel mailing list