>> 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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
