Created attachment 28444 [details] Dmesg just after I completed startup. The card suspended fine when I was still able to use malc0's 0001-merge-nv40fp.patch . But after the shift to another drm git, KMS must be enabled to be able to hibernate. I have KMS enabled now, and hibernate hangs at the first line. (like: Freezing system or something (let me know if you need the exact sentence)). On IRC, pq said that bisecting was hard (but doable), but it was better to report it first and see what comments I get. Attached are a bunch of files, which (I think) are hopefully useful. Especially the file dmesgwhens2disk seems useful. At first glance the numbers don't seem to change, but eventually they do... Let met know if you need more info :) drm (master-compat): 781edc5696881d268781300961fbe99390fe21f9 ddx:77d6bcfb45fca069aafdca0687760d668acd185a Btw, the kernel documentation says that you need to modprobe nouveau modeset=1 (to enable KMS) . BUT, the nouveau module is already probed by *something else in my system*. Adding nouveau.modeset=1 to my grub.conf enables it as well o.0
Created attachment 28445 [details] Dmesg, when I do dmesg -c && echo 1 > /sys/module/drm/parameters/debug && s2disk
Created attachment 28446 [details] lspci -s 01:00.0 -v -v -v > lspci
Created attachment 28447 [details] The log of the running Xorg server when I'm trying to suspend (I don't see anything)
Can you try the latest code in git, and kernel modesetting? Thanks.
Yes, I will try in a week or two, thanks for the reminder.
Nope, still does not work. Same effect as initial report, the thing hangs on the exact same sentence. Any data needed?
Just tried v3.8rc1 + nouveau HEAD and a patch from: https://bugs.freedesktop.org/show_bug.cgi?id=50121#c31 . It suspends now, altough it takes a while. I hear stuff power down twice, I don't think that's correct... Recent rework made things worse, the screen resumed with a black screen. Latest HEAD with mentioned patch makes stuff regress like pre kernel v3.5 rework: The screen comes up, slightly garbled. It won't respond, and eventually the entire screen locks-up. Any pointers on what to do next??
Created attachment 72137 [details] Dmesg v3.8rc1+Nouveau_HEAD+patch from #50121#c31 (boot)
Created attachment 72138 [details] Dmesg v3.8rc1+Nouveau_HEAD+patch from #50121#c31 (s2disk cycle) Suspend and resume cycle: echo disk > /sys/power/state; dmesg -c >& v3.8rc1_nouveaudebug_cycle.txt I see some errors in there. Hope it helps. Purged all the other old data, I hope that's okay since this is new.
Does it boot (yes, boot, not resume) if you add nouveau.config=DEVINIT=NvForcePost=1 to kernel command line?
Yes, it boots. But that is it, actually. By passing that kernel paremeter it seems to reproduce the exact same screen distortion if I resume: lot's of stuff is a little off (both in location and color). But I could see what I typed and recognize my splash screen wallpaper. It just had this local distorted area's that flipped state every once in a while... I'm attaching a dmesg for your viewing pleasure. Lot's of errors...
Created attachment 72251 [details] Dmesg v3.8rc1+Nouveau_HEAD+patch from #50121#c31 + nouveau.config=DEVINIT=NvForcePost=1
That's exactly what I was hoping to see :). Please attach your VBIOS (see http://nouveau.freedesktop.org/wiki/DumpingVideoBios )
Created attachment 72262 [details] G73 (NV4B) VBIOS, version 05.73.22.54.00 retrieved with DebugFS and kernel v3.6.9 I tried to update the Wiki to reflect the current situation but my account (Rexilion) is not allowed to do so... . So this is the VBIOS retrieved from a v3.6.9 kernel.
Please attach boot log with above option and nouveau.debug=trace
Created attachment 72265 [details] Dmesg v3.8rc1+Nouveau_HEAD+patch from #50121#c31 + nouveau.config=DEVINIT=NvForcePost=1 + nouveau.debug=trace
Created attachment 72615 [details] Dmesg v3.8rc2 + Nouveau HEAD - NV4B - nouveau.config=DEVINIT=NvForcePost=1 + nouveau.debug=trace - deprecating old logs
Created attachment 72637 [details] [review] script limitter VBIOS contains some scripts, which are normally run by BIOS. Nouveau executes those scripts: 1) when it detects the card is uninitialized 2) when NvForcePost=1 option is passed 3) on resume It seems Nouveau does something wrong on your card when it executes those scripts. So, if we will fix boot with NvForcePost=1, we will also fix the resume issue. Now, how to fix boot with NvForcePost=1? Good question ;). Figuring out which script makes the trouble will probably make it easier. With the above patch you will be able to tell how many scripts are executed and then limit which one to execute by passing module parameters: minscript and maxscript. Try it. (start by setting maxscript only)
Created attachment 72648 [details] Cat'ed dmesg logs Yay, script bisect! I did every combination (assuming order does not matter) since I could not find any apparent pattern. Too bad... I have scripts -1,0,1,2 and 3 on this card. Combinations that work: - -1 - -1,0 - -1,0,1 - 0 - 0,1 - 0,1,2 - 0,1,2,3 - 1 - 1,2 - 1,2,3 - 2 - 2,3 - 3 Combinations that fail: - -1,0,1,2 - -1,0,1,2,3 (normal) Weird thing is that the only other failing combination is the regular boot without script 3. Do you see any patterns? I will attach dmesg of all combo's in one file. Please note that: minscript=2 will execute script 1,2,3. Maxscript 2 will execute -1,0,1. So minscript=2 and maxscript=2 will execute script 1 only. If boot is scrambled, nouveau will give fbcon messages on each lockup. If it's not scrambled it won't, so it's directly related.
Argh, I made a mistake in this patch - I subtracted 1 from printed indexes. So the only failing combination are 0-3 and 0-4, which means something about script 3 is not ok (4th script is empty).
No problem. Glad I could help. You mentioned script 3 being not okay. And 4 being empty. Then I noticed that the combination of 0 and 3 is fatal somehow. Because sometimes, including script 3 works out correctly.
Please attach an mmiotrace [1] of binary driver handling suspend & resume. [1] http://nouveau.freedesktop.org/wiki/MmioTrace
Created attachment 72669 [details] Mmiotrace of NV4B s2disk cycle, kernel v3.7.1 and nVidia 304.64 I think it worked out. Weird thing is: I tried booting with init=/bin/bash, setting up the mounts myself and making root rw and all that. Then I get a 750kb uncompressed file. So I tried again, booting using Gentoo, but without X and terminal only, and it's 30MB uncompressed. What is the difference? I think it worked out okay though.
Yes it worked out properly. The difference was that udev is started if I use init and seems to change something with my display. If I then do an s2disk cycle, everything is peachy and the mmiotrace is 30MB. I started in single mode and started udev as well, I got the same result. Sorry for bothering you, thought it was a driver issue. At least I can confirm that the above mmiotrace should be okay for use.
The card died on me yesterday. The BIOS splash shows small but many garbled artifacts. Once nouveau loads it tears the entire screen with (DMA) errors. Two weeks ago I installed Windows on it for upgrading an e-reader. The last time I did that was maybe 4 years ago. Now, 2 Weeks later after the install the GPU dies. Food for thought! Time to buy a new one...
Original card is gone now, no more testing can be done. Marking as invalid.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.