[CFT] SMP/i386 suspend/resume
Jung-uk Kim
jkim at FreeBSD.org
Mon May 14 17:55:05 UTC 2012
-----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-----
More information about the freebsd-current
mailing list