Date: Mon, 14 May 2012 13:55:04 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: Mitsuru IWASAKI <iwasaki@jp.FreeBSD.org> Cc: freebsd-acpi@freebsd.org, gperez@entel.upc.edu, freebsd-current@freebsd.org Subject: Re: [CFT] SMP/i386 suspend/resume Message-ID: <4FB146F8.9090901@FreeBSD.org> In-Reply-To: <20120514.131617.129792413.iwasaki@jp.FreeBSD.org> References: <4FAF696D.3060806@entel.upc.edu> <20120513.234014.26960250.iwasaki@jp.FreeBSD.org> <9E61BC2D-2654-40D9-936F-A99CD7AC1354@entel.upc.edu> <20120514.131617.129792413.iwasaki@jp.FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FB146F8.9090901>