Re: [CFT] SMP/i386 suspend/resume

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

On 2012-05-14 00:16:17 -0400, Mitsuru IWASAKI wrote:
> Hi,
> 
>>>> Reporting from an Acer Centrino Duo, running CURRENT r235266.
>>>> The machine has an nvidia card (Ge7300go). The acpi_video and
>>>> nvidia modules are there.
>>>> 
>>>> I did test it a few times with X running (plain twm) and
>>>> worked just fine. Setting hw.acpi.lid_switch_state=S3 allowed
>>>> me to use the close-the-lid-to-sleep functionality.
>>>> 
>>>> The problem comes when I suspend the machine in the console.
>>>> The machine resumes fine (I can ping and ssh it) but the
>>>> screen remains black. I set hw.acpi.reset_video to 0 or 1 but
>>>> no go. If I'm in a console but X is running, after the resume
>>>> I can CTRL+ALT+F9 and get my video back; then I can return to
>>>> the console. If I don't have X running, I don't know how to
>>>> get my console back.
>>> 
>>> I think this is graphic driver problem.  nvidia's driver seems 
>>> to have correct suspend/resume method. 
>>> http://www.nvidia.com/object/freebsd_archive.html
>>> 
>>> Have you try it?
>> 
>> Yes, it is running the propietary driver. Everything was done
>> with it loaded. Do you want me to try without the nvidia binary
>> driver?

First of all, thank you very much for your work!  I wanted to do it
for very long time but I had no time to actually implement it. :-)

> Yes, if it doesn't bother you. Hmmm, it doesn't seem related with
> my SMP/i386 sleep patches.

I know for sure it is not related to your patches.  In fact, we cannot
resume most NVIDIA controllers without NVIDIA kernel driver + binary
X.org driver + VT switching hack (i.e.,
hw.syscons.sc_no_suspend_vtswitch=0, which is default).  Also, there
is ACPI_PM option for ports/x11/nvidia-driver but it doesn't help much
because it doesn't seem to save/restore GPU registers by itself (off
by default).  Very few NVIDIA controllers can be reset with BIOS POST
or saved/restored with VBE functions.  Many Intel controllers have
similar issues and they need kib's KMS driver.  Usually, ATI/AMD
controllers have no problem when (relatively recent) vesa.ko is
compiled into kernel or loaded as module as they have complete VBE
save/restore functions.  Similarly, any video controllers with correct
save/restore functions should work with vesa.ko.

> Could you try also Uni-processer kernel (w/o SMP and apic from
> config file) without my patches?
> 
>> OTOH, IIRC the console only test (without X) without acpi_video
>> lead to freeze. No crash dump. The machine has no serial or fwire
>> ports :(
> 
> We can improve video initialization on another opportunity. Linux
> have many video hacks while we have only hw.acpi.reset_video ;)

FYI, we don't need hw.acpi.reset_video any more (and it is even
harmful).  It is done from vesa.ko now.

> http://www.kernel.org/doc/Documentation/power/video.txt I believe
> there are some solutions for you in this document, then we can
> implement them in our source if found.

Most of these Linux hacks are completely obsolete since KMS.  I really
don't want to reiterate Linux mistakes again.

Jung-uk Kim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+xRvcACgkQmlay1b9qnVP1NwCfVPMz1YhvUcyyhWkQjs4JZdgd
B0gAoKuv4ST+N7FInyfaMwMYuFe4AfNx
=jk3/
-----END PGP SIGNATURE-----