From owner-freebsd-current@FreeBSD.ORG Mon May 14 09:03:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A26EC106564A; Mon, 14 May 2012 09:03:13 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 67B288FC12; Mon, 14 May 2012 09:03:11 +0000 (UTC) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id q4E7o1b8018671; Mon, 14 May 2012 09:50:01 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.es [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id 203DE2CBD0E; Mon, 14 May 2012 09:49:56 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 14 May 2012 09:49:56 +0200 From: Gustau Perez Querol To: , 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> Message-ID: X-Sender: gperez@entel.upc.edu User-Agent: RoundCube Webmail/0.5.1 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Mon, 14 May 2012 09:50:03 +0200 (CEST) Cc: iwasaki@jp.FreeBSD.org Subject: Re: [CFT] SMP/i386 suspend/resume X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 09:03:13 -0000 > >> >> 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? > > Yes, if it doesn't bother you. What follows was still done with your patch there. First, I tried with acpi_bounce. I saw this on dmesg: vgapci0: calling BIOS POST I also tried the complete suspend/resume without the nvidia blob. The machine showed the same behavior; it came online after suspending. Everything working but the video. After the suspend/resume cycle and w/o the nvidia blob, I tried to ssh it. The screen was completely black. After logging in, I kldload'ed the nvidia blob and tried to start X. I got a panic (I was unable to read it) and a core after rebooting. The relevant part was: ************************************************* Unread portion of the kernel message buffer: NVRM: failed to copy vbios to system memory. NVRM: RmInitAdapter failed! (0x30:0xffffffff:858) nvidia0: NVRM: rm_init_adapter() failed! ************************************************* So I would say the bios is doing something during the suspend/resume cycle. I would say the nvidia module knows to handle this, but the module must be loaded before the first suspend/resume cycle. That would explain why it works with X running. That would also somehow explain why I can resume while working with ttyv1 having X working on ttvy9 (remember, in that case I had to vidcontrol -s 9 < /dev/console to get my screen back online). I'm just guessing. Could it be that > Hmmm, it doesn't seem related with my SMP/i386 sleep patches. > Could you try also Uni-processer kernel (w/o SMP and apic from config > file) without my patches? I tried smp disabled on boot (kern.smp.disabled=1) and failed the same way. I'm compiling w/o your patch (will take it a while) but I guess it will do worst. Last time I tried, when 9 was head, it did not resume at all. > >> 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 ;) > 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. Could this all be an ASL problem? Thanks, Gus >