From owner-freebsd-acpi@FreeBSD.ORG Mon May 14 17:55:05 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F9EC1065672; Mon, 14 May 2012 17:55:05 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 96BEE8FC17; Mon, 14 May 2012 17:55:04 +0000 (UTC) Message-ID: <4FB146F8.9090901@FreeBSD.org> Date: Mon, 14 May 2012 13:55:04 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120502 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mitsuru IWASAKI 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> In-Reply-To: <20120514.131617.129792413.iwasaki@jp.FreeBSD.org> X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, gperez@entel.upc.edu, freebsd-current@freebsd.org Subject: Re: [CFT] SMP/i386 suspend/resume X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 17:55:05 -0000 -----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-----