On 17.11.2013 00:22, Emil Velikov wrote: > On 04/10/13 01:54, Christoph Rudorff wrote: >> Am Donnerstag, den 03.10.2013, 23:50 +0100 schrieb Emil Velikov: >>> I'm not entirely sure this is correct. One needs to save and disable >>> accleration before suspending the fb. Please try the following >>> >>> - if (state == 0) >>> + if (state == 1) >>> nouveau_fbcon_save_disable_accel(dev); >>> fb_set_suspend(drm->fbcon->helper.fbdev, state); >>> - if (state == 1) >>> + if (state == 0) >>> nouveau_fbcon_restore_accel(dev); >>> console_unlock(); >>> >>> Cheers, >>> Emil >> >> Hi! >> >> That was my first try! I guessed the same but I got exactly one trap >> message on resume. >> > Hi Chris, >
Hi Emil! > Just got around to playing with s2disk on my laptop(nv96) and AFAICS > it seems to be OK without either patch. That does not make me wonder. The "nouveau_fbcon_restore_accel" is restoring from uninitialized memory. So the resulting behavior is undefined. It must not fail. (My experience with vga-drivers is, it may makes a difference if u just reboot or power down the machine when testing another kernel! And I do believe we can't catch the remaining bugs just with testing.) > Can you provide some more context regarding the issue ? > * What hardware are you running A MacBookPro6,2 with GT216 [GeForce GT 330M] Debian 6 Boot via UEFI, not using pc-bios emulation. It's my working horse and usually an uptime monster thanks to s2disk. So I can't test that much and only during a mandatory kernel upgrade. > * Which kernel are you having problems with That's the fun part. I was stuck with 3.6.9 which was fine and later kernels were a mess. I did not upgrade any more until longterm 3.10 came out. However, this bug was already in 3.6.9, but it did not trigger: 3.6.9 ok 3.6.10 problems *) 3.7.1 problems ... never touch a running system ... until 3.10.13 ok 3.10.14 problems ... *) There were no changes below drivers/gpu/drm/nouveau ! I think the difference is, that the kernel size increased so memory allocations were just shifted ... so we may get an used memory page, no? It's a race condition. > * Can you resume from s2disk correctly if you never start X The machine never locked up and X was also fine. The console gets messed: just snow. A s2ram clears it up. I may test this later. > * Do you have the problem with s2ram No. > * dmesg without and with either patch Blame me. I didn't kept them. But I remember I diffed them but that did not gave any hint. I found it by reading the source code. > > It might be useful if you can open a bug report and attach the > information in there [1] I didn't opened a report because there are already many reports about garbled console. I just thought that the actual nouveau_fbcon_set_suspend() is obviously doing the wrong thing and the fix is too easy. And the remaining snow on the console, which other users get, are other causes. Actually reproducible is this (also with my patch): 1. Fresh boot up, run mplayer (-vo xv), switch to fullscreen: GPU lockup. If I do a s2ram before, it works. https://bugs.freedesktop.org/show_bug.cgi?id=68037 ^^ same issue?! Are we missing some initialization? 2. Try a sysrq-"space"-key on console: The help text, which should appear, is just snow (Can you reproduce this?). 3. On boot up, I'll still get some snow just before X start, _sometimes_, not always: 3-4 lines of nouveau E[ PFB][0000:01:00.0] trapped write at 0x0000710540 on channel 0x0000fee0 [unknown] BAR/PFIFO_WRITE/FB reason: PAGE_NOT_PRESENT greets, chris > > Cheers, > Emil > > [1] http://nouveau.freedesktop.org/wiki/Bugs/ > >> So it's about first put the bucket and then open the water tap. >> >> ;) >> >> chris >> >> ps: just found these macros for the state in fb.h: >> >> FBINFO_STATE_RUNNING = 0 >> FBINFO_STATE_SUSPENDED = 1 >> >> > _______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
