Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 14 May 2012 09:49:56 +0200
From:      Gustau Perez Querol <gperez@entel.upc.edu>
To:        <freebsd-current@freebsd.org>, <freebsd-acpi@freebsd.org>
Cc:        iwasaki@jp.FreeBSD.org
Subject:   Re: [CFT] SMP/i386 suspend/resume
Message-ID:  <f35b182a89a55ade52b5034012658ad7@webmail.entel.upc.edu>
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
>
>> >>   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
>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f35b182a89a55ade52b5034012658ad7>