> >> >> 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 >Received on Mon May 14 2012 - 07:03:13 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:26 UTC