Created attachment 61852 [details]
Dmesg output of correct resume

On a small sidenote, compiling current head with

!CONFIG_DRM_NOUVEAU_BACKLIGHT

results in:

http://pastebin.com/8TvZNDqz

Current head means:

1. git pull git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
2. git pull git://anongit.freedesktop.org/nouveau/linux-2.6

Through googling I found out that drm has it's own debug facility (duh...). I have added 4 files that are generated with the following kernel boot parameters:

drm.debug=15 log_buf_len=32M

The 'bad' state contains the bootlog and suspend log of the kernel at commit 5d720f2450 from the nouveau/linux-2.6 tree.

The 'good' state contains the bootlog and suspend log of the kernel at the commit before 5d720f2450 fron the nouveau/linux-2.6 tree. (Which is the default kernel for now.)

I'm out of idea's right now, so any pointers would be great.

Created attachment 61858 [details]
Dmesg boot log of the 'bad' kernel

Created attachment 61859 [details]
Dmesg resume log of the 'bad' kernel

Created attachment 61860 [details]
Dmesg boot log of the 'good' kernel

Created attachment 61861 [details]
Dmesg resume log of the 'good' kernel

I tried kernel 3.5-rc1, because it seems that some recent patches were left out during the merge. I was hoping that this newer kernel would somehow solve this. However, I'm still having the same issue's in this release.

On a further note, the commit before 5d720f2450 was a pretty good release for this card. Glxgears reported almost 400fps and window resizing was smooth. With v3.4.1 or v3.5-rc1, this performance regressed to it's original state. Glxgears reports 100ftps and resizing is choppy again.

Now that I have found out the root cause of my resume trouble (documented in 53101) I found this bug.

Here's the info so far: (replicating from bug 53101)

ThinkPad W520 4276CTO NVC3 (2000M)
openSUSE 12.2 + nouveau 20120813 872dcac

* Booting works (nox2apic, W520 ACPI table issue)
* gdm has graphics distortions though (see early dmesg excerpt)
* double ctrl+alt+backspace "fixes" this and gdm looks good
* suspend from gnome-shell 3.4.2 works
* resume shows gdm-password prompt and usually a white-noise background
** the gnome-shellish top-panel looks intact, though
** mouse cursor not movable, cpu load
** looks like "something" tries to restart gdm/X over and over again
* switching to vt possible with some insisting
* restarting gdm does lock up the system
* the "channel x kick timeout" seems new since some commits IIRC

repeatedly in dmesg:
[  156.925301] nouveau E[   PFIFO][0000:01:00.0] playlist update failed
[  159.924800] nouveau E[     DRM][0000:01:00.0] failed to idle channel
0xcccc0000
[  161.924690] nouveau E[   PFIFO][0000:01:00.0] channel 1 kick timeout
[  161.924787] nouveau  [   PFIFO][0000:01:00.0] unknown status 0x00000100
[  163.924603] nouveau E[   PFIFO][0000:01:00.0] playlist update failed
[  163.989722] nouveau  [   PFIFO][0000:01:00.0] unknown status 0x00000100
[  165.989535] nouveau E[   PFIFO][0000:01:00.0] channel 3 kick timeout
[  165.989670] nouveau  [   PFIFO][0000:01:00.0] unknown status 0x00000100
[  167.989455] nouveau E[   PFIFO][0000:01:00.0] playlist update failed
[  167.989517] nouveau ![   PFIFO][0000:01:00.0] unhandled status 0x00000001
[  170.649537] nouveau E[   PFIFO][0000:01:00.0] playlist update failed
[  172.660200] nouveau E[   PFIFO][0000:01:00.0] playlist update failed
[  185.103713] nouveau E[     DRM][0000:01:00.0] failed to idle channel
0xcccc0001
[  187.103627] nouveau E[   PFIFO][0000:01:00.0] channel 2 kick timeout

I tried a fc17 install and the original kernel (3.3.4-5.fc17.x86_64) worked.
Suspend/resume fine at least when not in docking station. After updating that
test install to 3.5.1-1.fc17.x86_64 the same issues cropped up I see in
openSUSE 12.2. So this looks distribution agnostic.

--
Bisection rounds testing successful suspend/resume cycles on NVC3/2000M:

note:
* gdm greeter is showing garbage (screen content from before reboot) somewhere
before the last known good commits
** this issue was ignored and still present in the last good commit but is not
the topic of this bug

$ git bisect log
# bad: [f9b495fca46836a6a05cedde8058ccb8a3e62c3d] drm/nouveau: use
ioread32_native/iowrite32_native for fifo control registers
# good: [f887c425f9eeed8ffbca64c8be45da62b07096c0] drm/nouveau: bump version to
1.0.0
git bisect start 'HEAD' 'f887c425f9eeed8ffbca64c8be45da62b07096c0' '--'
'drivers/gpu/drm/nouveau/'
# bad: [9bd0c15fcfb42f6245447c53347d65ad9e72080b] drm/nouveau/fbcon: using
nv_two_heads is not a good idea
git bisect bad 9bd0c15fcfb42f6245447c53347d65ad9e72080b
# good: [5132f37700210740117f5163b5df7aa1c8469a55] drm/nve0/fifo: initial
implementation
git bisect good 5132f37700210740117f5163b5df7aa1c8469a55
# bad: [71af5e62db5d7d6348e838d0f79533653e2f8cfe] drm/nv50/gr: make sure
NEXT_TO_CURRENT is executed even if nothing done
git bisect bad 71af5e62db5d7d6348e838d0f79533653e2f8cfe
# good: [afada5e0bb3cac8530c2ae36aa0abca41d60e063] drm/nv04/disp: disable
vblank interrupts when disabling display
git bisect good afada5e0bb3cac8530c2ae36aa0abca41d60e063
# bad: [5e120f6e4b3f35b741c5445dfc755f50128c3c44] drm/nouveau/fence: convert to
exec engine, and improve channel sync
git bisect bad 5e120f6e4b3f35b741c5445dfc755f50128c3c44
# good: [35bcf5d55540e47091a67e5962f12b88d51d7131] drm/nouveau: move
flip-related channel setup to software engine
git bisect good 35bcf5d55540e47091a67e5962f12b88d51d7131
# good: [d375e7d56dffa564a6c337d2ed3217fb94826100] drm/nouveau/fence: minor api
changes for an upcoming rework
git bisect good d375e7d56dffa564a6c337d2ed3217fb94826100


5e120f6e4b3f35b741c5445dfc755f50128c3c44 is the first bad commit
commit 5e120f6e4b3f35b741c5445dfc755f50128c3c44
Author: Ben Skeggs <bskeggs@redhat.com>
Date:   Mon Apr 30 13:55:29 2012 +1000

    drm/nouveau/fence: convert to exec engine, and improve channel sync

    Now have a somewhat simpler semaphore sync implementation for nv17:nv84,
    and a switched to using semaphores as fences on nv84+ and making use of
    the hardware's >= acquire operation.

    Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

:040000 040000 8f2ca4ddf4969c75f688a96fdb152e449fda4852
da67a1bd8d608577e659a26715cf8af3644d8efe M    drivers

--

@Ronald
* can it be the ticket subject carries the wrong commitish? (because the bad commit we both identified is "5e120f6e4b3f35b741c5445dfc755f50128c3c44" in the nouveau/linux-2.6 tree)
* if you like, extend the subject with NVC3/Quadro 2000M

Created attachment 65931 [details]
W520-4276CTO-NVC3 dmesg commitish-872dcac gdm + suspend/resume cycle

Thanks for your info and a 'me2'. I updated the title as you requested. I placed the entire commit title.

Everytime a new kernel is released, the nouveau project does a 'git rebase' which essentially wipes all patches outside of Linus' tree and places them back one by one. This implies a change in the SHA hash since git treats those patches that are being reapplied (but are essentially the same) and new (and thus different commits).

One a sidenote (just to summarize/confirm this bug), it seems that:
- symptoms are the exact same
-  regression fails
-  cursor invisible
-  screen is corrupted
-  no visual response
-  vt switching works with some persistence
-  logs are flooded (with generic messages)
- bisected patch is the exact same (as in title)
-  however, as of now, based on different kernel versions (v3.4 vs v3.5)

However, there is one nitpick. I have pinned this computer's kernel on 3.4 since 3.5-rc0 and higher suffer from another regression which I have failed to bisect (I forgot why/how that did not work).

When I have time this weekend, I will see how far I can get with Linus' tree and then combine with the nouveau tree and we will see what happens. A refresh of testdata might be good since the patches from the nouveau tree allow setting debug levels which is nice.

Ah, thanks for clearing that up with the rebased commits. Didn't know they'd get a new hash then.

Apart from providing more verbose logs, I am unsure what else one can do here. I think a dev (Ben?) should get us into some direction. The bisected bad commit is a tad bit too huge to understand/revert/trial-and-error-tinker for me ;)

*** Bug 55744 has been marked as a duplicate of this bug. ***

Same issue here with my EVGA GeForce 450 GTS (1GB).

It works fine with the nVidia drivers.

Kernel: 3.6.1
nouveau-git & libdrm-git
OS: Archlinux

Francois,

You can you confirm that your regression is also caused by the following commit?

drm/nouveau/fence: convert to exec engine, and improve channel sync

Michael and my problems are not there when we build a kernel before this patch is applied.

Please test to make sure that you are not having a seperate problem. Thank you.

Still not working with 3.7-rc4:


nouveau  [     DRM] re-enabling device...
nouveau  [     DRM] resuming client object trees...
nouveau  [   VBIOS][0000:01:00.0] running init tables
nouveau W[  PTIMER][0000:01:00.0] unknown input clock freq
agpgart-via 0000:00:00.0: AGP 3.5 bridge
agpgart: kworker/u:30 tried to set rate=x12. Setting to AGP3 x8 mode.
agpgart-via 0000:00:00.0: putting AGP V3 device into 8x mode
nouveau 0000:01:00.0: putting AGP V3 device into 8x mode
nouveau  [     DRM] Loading NV17 power sequencing microcode
nouveau  [     DRM] resuming display...
nouveau  [     DRM] Setting dpms mode 3 on TV encoder (output 1)
Restarting tasks ... done.
nouveau E[     DRM] reloc wait_idle failed: -16
nouveau E[     DRM] reloc apply: -16
nouveau E[     DRM] reloc wait_idle failed: -16
nouveau E[     DRM] reloc apply: -16
nouveau E[     DRM] reloc wait_idle failed: -16
nouveau E[     DRM] reloc apply: -16

Screen stays black on resume. I tested this +nouveau tree which enables z-compression.

Linux kernel 3.7-rc4 + nouveau tree (see nouveau.txt for patches):

CONFIG_LOG_BUF_SHIFT=21
CONFIG_NOUVEAU_DEBUG=6
CONFIG_NOUVEAU_DEBUG_DEFAULT=6 # 7 gave a >16MB log

Did a 'dmesg -c' for each seperate logfile just before doing 'pm-hibernate'. Logfiles are from the same boot. First resume succeeds, second hangs just like the first occurence of this bug.

Attaching files...

Created attachment 69606 [details]
Dmesg of boot

Created attachment 69607 [details]
Dmesg of succesful first resume

Created attachment 69608 [details]
Dmesg of failed second resume

Created attachment 69609 [details]
v3.7-rc4 + nouveau patchlist

I'm also attaching a diff of both logs. I filtered them using sed to get rid of the timestamps.

One thing stands out (to me):

The logs of the correct resume mention this:

-ACPI: Invalid Power Resource to register!
-agpgart-via 0000:00:00.0: Refused to change power state, currently in D0

The rest of the diff contains errors from the bad resume and subsequent trace thereof.

Created attachment 69612 [details]
Diff of both resume sessions

Created attachment 69616 [details] [review]
Reset agp.stat to unknown during suspend

Something to test :P

No dice =) Even hangs at suspend sometimes. Besides, this bug is not slot specific. Someone else with a 'NVC3/Quadro 2000M' (PCI-E) also has these problems since the mentioned commit:

'drm/nouveau/fence: convert to exec engine, and improve channel sync'.

Just tested v3.8-rc1 + nouveau @ 'drm/nouveau/fan: handle the cases where we are outside of the linear zone' on this FX5200.

Especially 'drm/nouveau/bios: cache ramcfg strap on later chipsets' looked promising (even though I don't have a recent chipset... there was hope...).

Things did not regress further. First suspend works most of the time, second suspend crashes. Symptoms did change a bit. When resume eventually completes, I do not see a frozen/unresponsive desktop but the screen goes black with red/green (I don't think i saw any blue) pixels scattered all over it. Density was really low, so maybe 200 pixels on the entire screen? These pixels did not move or alterate or anything, it was pretty static and boring actually.

But I recommend Michael and francoism to test latest HEAD as the mentioned commit might fix your issue's???

I will add a dmesg from v3.8rc1 kernel for your viewing convenience. This is a dmesg from syslog, not from the 'dmesg' command!

Created attachment 72060 [details]
Dmesg of v3.8rc1 + nouveau HEAD

referencing bug #55258 here

Kewl, that means that this regression is spread across several cards if you purely look at the symptoms.

- NV40 generation card (0x049200a2)
- twice on an NV34 [GeForce FX 5200] (IRC: FX5200 is an 'odd beast' :/)
- NVC3 (2000M)
- EVGA GeForce 450 GTS

From two of these, the regression has been confirmed to be resulting from commit:

'drm/nouveau/fence: convert to exec engine, and improve channel sync'

as part of the nouveau rework that got upstreamed in kernel 3.5:

- NV34 [GeForce FX 5200] by me
- NVC3 (2000M) by Michael Weirauch

I think it's safe to assume that ppl who are experiencing this regression as well using a kernel on 3.5 or above are suffering from the same issue.

Francoism is using 3.6, so that is okay.

@Raphaël Droz: What kernel version are you using? And maybe the kernel version from Mr-4 might be useful as well. Just to confirm.

Created attachment 72085 [details] [review]
fix

does this patch fix it?

nvc3 should be already fixed in 3.7

Seems to have fixed the bug. It has survived three consecutive suspend and resume cycles in a row. This was not possible after v3.5 without your supplied fix.

So it seems that the direct symptoms have been resolved with this patch. But if you don't mind, I would like to test it somewhat further for these days.

And I suggest that everyone else with this hardware (Raphael and Mr-4) to test as well.

Guess I won't be telling my parents they are running an rc1 kernel hehe...

The FX5200 still functions and survived another cycle.

I went ahead and tested your patch on a 'G73 (NV4B)' as well. Since modeset became mandatory suspend/resume never worked (anymore). It suspended, but resumed with a garbled console where some colors are off. Eventually, the card looks up.

Recent rework made the screen completely black. So the regression regressed even further. Current head with your patch restores the second regression back to where the display is garbled after resume (after which it looks up again).

So I'm fairly confident that your patch restores pre rework (v3.5) behaviour on these cards with respect to suspend and resume cycles.

I'm going to test an NV4E laptop later, when I have time.

Just tested v3.8rc1+nouveau+patch on an NV4E. Suspend and resume works! Though it takes about 1 minute before it shuts down (hangs somewhere). And maybe 1 or 2 minutes to resume (before screen is restored).

Restarting is faster, but this looks promising. At least it works.

Anyways, no regressions, just improvements.

Thanks Santa!

Good. Please open new bug reports for the other issues you have with these (4B & 4E) boxes.

Created attachment 72113 [details] [review]
fix v2

I simplified the fix a bit. Can you test it too? (Just one box would be enough)

(Note that you don't need to run it on 3.8-rc1 - it's applicable to 3.7 too)

Reverted the old patch and applied the new one. Did this on the same v3.8rc1+nouveau kernel tree. It only rebuilded the nouveau specific files.

The FX5200 survived 4 consecutive cycles with this patch. It seems to exhibit the same behaviour as the previous patch: During suspend and resume, for a short moment, there is a blue/green stray pixel in the top left corner. Everything works fine though.

Good to go if you ask me. Maybe apply it to 3.5 and 3.6 as well??

As for the other cards I mentioned (NV4E + NV4B) I merely referenced them to test the patch against regressions. Suspend is broken on NV4B since KMS became mandatory. And it seems to work somewhat on NV4E.

*My primary aim is to guard against regressions.* FWIW, do you really want seperate bugs for the NV4E and NV4B??? They are just bugs, not regressions.

This patch is not directly applicable to kernels < 3.7, although porting it is trivial.

WRT other bugs: Yes, I would like to see separate bug reports. Suspend/resume should work for all cards and not take too much time. I don't promise fixing them, of course.

Ok, I will file seperate bugs for these cards.

FYI, the FX5200 survived 11 cycles so far without a hitch. Thanks a lot =)

Marcin, I already filed bug #23223 for the NV4B, I'll update that one. It's quite old, but I'll continue from there. I'll open a new one for the NV4E.

I'm waiting on filing a bug for the NV4E. It seems that nouveau works properly, I don't see any delays or errors at all in dmesg. It is whining about the b43 firmware, but even if I unload the driver the resume still takes 1m and 30 seconds. But it works.

I'm not sure this is a nouveau bug, hence I'm not filing it. I will dig deeper when I have time.

perfect!
the last patch did the trick (tested with vanilla 3.7).

I hibernated several times, even with a running instance of glxgears.
No problem anymore.

On my side the startup time is not especially long.

thanks

*** Bug 55258 has been marked as a duplicate of this bug. ***

Created attachment 72499 [details]
W520-4276CTO-NVC3 dmesg 3.8.0-rc1 suspend/resumce cycle screen garbage

Tested NVC3 3.7.1 openSUSE kernel and nouveau 3.8.0-rc1 as of 2013-01-03. Both show same screen distortion (snowy background, button background and window border ok) on gdm when resuming. Though the system is "usable" load wise and doesn't lock-up.

Am I still in the scope of this bug with the following endlessly repeating errors on resume? (Which will go away if killing X.)

[ 1623.833303] nouveau E[  PGRAPH][0000:01:00.0] TRAP ch 1 [0x007fe00000 Xorg[1009]]
[ 1623.833311] nouveau E[  PGRAPH][0000:01:00.0] SHADER 0xa004021e

(In reply to comment #30)
> @Raphaël Droz: What kernel version are you using? And maybe the kernel
> version from Mr-4 might be useful as well. Just to confirm.
Apologies for this late reply, but since I first started experiencing these problems, and with no end in sight, I just got a bit fed up with it and was forced to downgrade my kernel - I am sticking with 3.3.x as it seems very stable as far as the nouveau suspend/resume problems go: I am getting an occasional "blip" (resume failure) about once every 15-20 suspend/resume cycles, which to me is as good and as manageable as it could be expected, given what I experienced with kernels 3.4, 3.5 and 3.6.

I am currently waiting for 3.7 to become mainstream for my distro (I am using Fedora) so that I could give it a go, but I don't hold my breath to be honest.

Just FYI: the problems I have experienced with kernels 3.4 - 3.6 have been the same as explained by a few others on here - every second suspend/resume cycle is a complete and utter failure, without exception. It's like a clockwork.

I haven't applied the patch in Comment#37, but will do as soon as 3.7 becomes "mainstream" in my distro and will post the results on here.

(In reply to comment #45)
> I am currently waiting for 3.7 to become mainstream for my distro (I am
> using Fedora) so that I could give it a go, but I don't hold my breath to be
> honest.
> 
It will be a while until Fedora ships 3.7+ kernels by default. If you want to help test vanilla kernels there is a well maintained repo to do so.

See https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories

michael.weirauch: this seems to be another bug

(In reply to comment #46)
> It will be a while until Fedora ships 3.7+ kernels by default. If you want
> to help test vanilla kernels there is a well maintained repo to do so.
> 
> See https://fedoraproject.org/wiki/Kernel_Vanilla_Repositories
Then I am better off adopting the patch in Comment#31 to work with 3.6.10 because I am not going to turn my development machine, which I use nearly 24/7 into a test harness.

(In reply to comment #38)
> This patch is not directly applicable to kernels < 3.7, although porting it
> is trivial.
"Porting" of that patch against 3.6 is far from "trivial" - exercise in futility more like!

There is no "nv50_fence.c" to start off with, "nouveau_drm" struct isn't there either, let alone that "nv10_fence_priv" doesn't seem to have "base.resume" defined at all.

I think I am going to stick with 3.3 until 3.7 comes out and then decide what to do next...

@Mr-4, I assumed that most of the rework went in at v3.5 regarding power management. But v3.7 had the huge overhaul everyone is talking about. So therefore I assumed that the patch might work at v3.5 and v3.6 as well. However, both kernels are EOL'ed. Sorry for the confusion and the false hope...

Maybe you can send a patch to Fedora? Maybe they will happily backport it for you. Especially since they try to be bleeding edge and all...

(In reply to comment #50)
> Maybe you can send a patch to Fedora? Maybe they will happily backport it
> for you. Especially since they try to be bleeding edge and all...
I would have if I knew how to fix it and make it work, since I assumed the changes will be ... (ahem) quite "trivial".

As it turns out, they aren't and my knowledge of this driver's inner workings isn't enough for me to re-create the patch for 3.6, which, incidentally, is still the latest mainstream-supported kernel by my distro. 

Ben Skeggs, who is responsible for the nvidia branch at Fedora (and who also appears listed in this bug) could do that - whether he chooses to is up to him, though given my past experiences with nvidia team @Fedora, I am not holding my breath.

A patch referencing this bug report has been merged in Linux v3.8-rc4:

commit f20ebd034eab43fd38c58b11c5bb5fb125e5f7d7
Author: Marcin Slusarz <marcin.slusarz@gmail.com>
Date:   Tue Dec 25 18:13:22 2012 +0100

    drm/nv17-50: restore fence buffer on resume

Created attachment 73421 [details] [review]
Backport for 3.5 (and may be 3.6)

For who is still using or interested in kernel 3.5 or 3.6, can you try/verify the attached patch? I checked and hope that it works, ended up being a simpler diff.

Created attachment 73488 [details] [review]
Backport for 3.5 (and may be 3.6) - fixed

Sorry, the patch I posted had a small typo, this one is ok...

I will try to test this weekend, cannot promise anything though.

Spot on! It worked :)

Just found a small window to test:

- 3.5.7+patch(v2): success! 5 cycles, clean dmesg
- 3.6.9+patch(v2): success! 5 cycles, clean dmesg

Backporting this will make a lot of people happy. Thank you.

This backported patch will crash on nv10-nv17 - priv->bo is only created for chipsets >= nv17.

Created attachment 73597 [details] [review]
Backport for 3.5 (and may be 3.6) - fixed again

argh, thanks. This is the fixed version.

(In reply to comment #58)
> Created attachment 73597 [details] [review] [review]
> Backport for 3.5 (and may be 3.6) - fixed again
I have to say, I didn't expect for this to be fixed, but this time it looks as though this nasty bug is being squashed. I have been doing hibernate/restore like mad (a couple of times a day) for the past week and not a single glitch, not one!

My one-and-only gripe with this (and it really is a minor one, given the circumstances) is that since I used a "fork" of the mainstream driver from Martin Peres (mupuf) at gitorious (http://gitorious.org/linux-nouveau-pm/linux-nouveau-pm/commits/thermal) to take advantage of the automatic fan management so that I don't have to execute "echo 40 > /sys/class/drm/card0/device/pwm0" every time I come out of hibernation and stop my nvidia fan wailing like a jet engine, this is still not implemented in the main stream driver code.

I used to have this so that when I come out of hibernate the automatic fan management takes over and reduces my fan speed according to the current temperature of the video card. It worked a treat, but I don't seem to be getting this any more and applying the patch which fixed the above bug is not possible against Martin's fork, unfortunately.

(In reply to comment #59)

You can put the following line:

"echo 40 > /sys/class/drm/card0/device/pwm0"

In a file in

/usr/lib/pm-utils/sleep.d/

Check out the other files on the format/arguments. Make sure you have the permissions right (root:root 700).

(In reply to comment #60)
> You can put the following line:
> 
> "echo 40 > /sys/class/drm/card0/device/pwm0"
> 
> In a file in
> 
> /usr/lib/pm-utils/sleep.d/
Thanks Roland, I'll try that, though, ideally, I would have liked to get my automatic fan management back - it was absolutely flawless. I don't know why it was discarded from the mainstream tree.

Sorry for not replying (for a long time).

I'm still having this issue when resume (gives RGB-stripes/freeze).

The following packages are installed from the Arch Linux repo:
nouveau-dri 9.0.2-1
xf86-video-nouveau 1.0.6-1
linux 3.7.8-1

I have not tried the GIT-version in AUR.

The GPU is an EVGA nVidia GeForce 450 GTS (1GB RAM).

Did you apply the patch from comment #36?

https://bugs.freedesktop.org/show_bug.cgi?id=50121#c36

Only v3.8 carries the fix.

(In reply to comment #63)
> Only v3.8 carries the fix.
Nope! My own distro (Fedora, as it turns out) had this patch already in their main nv tree as of kernel 3.7.4, so there was no need for me to apply it separately - I just built the kernel and had zero problems with my nv card ever since.

(In reply to comment #44)
I am experiencing the same problem on my w520 with Nvidia GF106 [Quadro 2000M].. I get the same symptoms / messages. Did you find a fix for the problem?

I noticed that suspend / resume works if using libdrm-nouveau1a only (without libdrm-nouveau2), however I the mouse gets lost on resume. If using libdrm-nouveau2, I get the problems.. Maybe the problem is somehow related to dri2?

> Am I still in the scope of this bug with the following endlessly repeating
> errors on resume? (Which will go away if killing X.)
> 
> [ 1623.833303] nouveau E[  PGRAPH][0000:01:00.0] TRAP ch 1 [0x007fe00000
> Xorg[1009]]
> [ 1623.833311] nouveau E[  PGRAPH][0000:01:00.0] SHADER 0xa004021e

(In reply to comment #65)
> (In reply to comment #44)
> I am experiencing the same problem on my w520 with Nvidia GF106 [Quadro
> 2000M].. I get the same symptoms / messages. Did you find a fix for the
> problem?
> 
> I noticed that suspend / resume works if using libdrm-nouveau1a only
> (without libdrm-nouveau2), however I the mouse gets lost on resume. If using
> libdrm-nouveau2, I get the problems.. Maybe the problem is somehow related
> to dri2?
> 
> > Am I still in the scope of this bug with the following endlessly repeating
> > errors on resume? (Which will go away if killing X.)
> > 
> > [ 1623.833303] nouveau E[  PGRAPH][0000:01:00.0] TRAP ch 1 [0x007fe00000
> > Xorg[1009]]
> > [ 1623.833311] nouveau E[  PGRAPH][0000:01:00.0] SHADER 0xa004021e

Very interessting comments. Please attach this info again to bug 59168 where the W520 lovers hang around regarding this issue.

Here we go again...

After experiencing the joy and the meaning of "stability" and what it feels like, I decided to upgrade to kernel 3.7.9 (the latest stable) from 3.7.4 and voila... this bug reared its ugly head again after the first hibernate/restore cycle.

This is what I get:

kernel: PM: Syncing filesystems ... done.
kernel: Freezing user space processes ... (elapsed 0.01 seconds) done.
kernel: PM: Preallocating image memory... done (allocated 220534 pages)
kernel: PM: Allocated 882136 kbytes in 0.25 seconds (3528.54 MB/s)
kernel: Freezing remaining freezable tasks ... (elapsed 3.29 seconds) done.
kernel: Suspending console(s) (use no_console_suspend to debug)
kernel: sd 2:0:0:0: [sda] Synchronizing SCSI cache
kernel: i8042 kbd 00:0a: wake-up capability enabled by ACPI
kernel: mpu401 00:05: disabled
kernel: nouveau  [     DRM] suspending fbcon...
kernel: nouveau  [     DRM] suspending display...
kernel: nouveau  [     DRM] unpinning framebuffer(s)...
kernel: nouveau  [     DRM] evicting buffers...
kernel: pciehp 0000:00:02.0:pcie04: pciehp_suspend ENTRY
kernel: agpgart-via 0000:00:00.0: Refused to change power state, currently in D0
kernel: pci 0000:00:13.1: wake-up capability enabled by ACPI
kernel: nouveau  [     DRM] suspending client object trees...
kernel: PM: freeze of devices complete after 343.943 msecs
kernel: PM: late freeze of devices complete after 0.310 msecs
kernel: PM: noirq freeze of devices complete after 0.488 msecs
kernel: ACPI: Preparing to enter system sleep state S4
kernel: PM: Saving platform NVS memory
kernel: Disabling non-boot CPUs ...
kernel: Broke affinity for irq 1
kernel: Broke affinity for irq 16
kernel: smpboot: CPU 1 is now offline
kernel: PM: Creating hibernation image:
kernel: PM: Need to copy 169979 pages
kernel: PM: Restoring platform NVS memory
kernel: Enabling non-boot CPUs ...
kernel: smpboot: Booting Node 0 Processor 1 APIC 0x1
kernel: CPU1 is up
kernel: ACPI: Waking up from system sleep state S4
kernel: PM: noirq restore of devices complete after 22.507 msecs
kernel: PM: early restore of devices complete after 0.121 msecs
kernel: pciehp 0000:00:02.0:pcie04: pciehp_resume ENTRY
kernel: nouveau  [     DRM] re-enabling device...
kernel: nouveau  [     DRM] resuming client object trees...
kernel: nouveau  [   VBIOS][0000:01:00.0] running init tables
kernel: pci 0000:00:13.1: wake-up capability disabled by ACPI
kernel: mpu401 00:05: activated
kernel: i8042 kbd 00:0a: wake-up capability disabled by ACPI
kernel: agpgart-via 0000:00:00.0: AGP 3.5 bridge
kernel: agpgart: kworker/u:1 tried to set rate=x12. Setting to AGP3 x8 mode.
kernel: agpgart-via 0000:00:00.0: putting AGP V3 device into 8x mode
kernel: nouveau 0000:01:00.0: putting AGP V3 device into 8x mode
kernel: nouveau  [     DRM] resuming display...
kernel: nouveau  [   PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 0
[...ad infinitum...]
kernel: nouveau  [   PFIFO][0000:01:00.0] still angry after 101 spins, halt
kernel: nouveau  [     DRM] 0xD3FB: Parsing digital output script table
kernel: nouveau  [     DRM] Setting dpms mode 3 on TV encoder (output 3)
kernel: nouveau  [     DRM] 0xD3FB: Parsing digital output script table
abrt[3701]: not dumping repeating crash in '/usr/bin/Xorg'
kernel: nouveau E[    3644] failed to idle channel 0xcccc0000
abrt[3716]: saved core dump of pid 3710 (/usr/bin/Xorg) to /var/spool/abrt/ccpp-1361815666-3710.new/coredump (3674112 bytes)
abrtd: Directory 'ccpp-1361815666-3710' creation detected
abrtd: Crash is in database already (dup of /var/spool/abrt/ccpp-1361815646-2078)
abrtd: Deleting crash ccpp-1361815666-3710 (dup of ccpp-1361815646-2078), sending dbus signal
kernel: nouveau E[    3710] failed to idle channel 0xcccc0000
abrt[3726]: not dumping repeating crash in '/usr/bin/Xorg'
kernel: nouveau E[    3720] failed to idle channel 0xcccc0000
[...the last two messages repeat ad-infinitum...]

So, I think that whatever was done in the nvidia kernel code after 3.7.4 (I haven't tested with version prior to 3.7.9) brought that nasty bug back to life and I think it should be reopened, seeing that I am not the only one experiencing this...

Is it consistent, git says 'no':

ronald@Alpha /usr/src/linux :) $ git log --oneline --no-merges v3.7.4...v3.7.9 -- drivers/gpu/drm
330b8ab drm/nouveau: add lockdep annotations
c7fc196 drm/radeon: Calling object_unrefer() when creating fb failure
b666341 drm/radeon: prevent crash in the ring space allocation
3e15c0b drm/radeon: protect against div by 0 in backend setup
f69c00e drm/radeon: fix backend map setup on 1 RB sumo boards
cb23301 drm/radeon: fix MC blackout on evergreen+
04589e1 drm/radeon: add quirk for RV100 board
4e370f5 drm/radeon: add WAIT_UNTIL to the non-VM safe regs list for cayman/TN
83f83a0 drm/radeon/evergreen+: wait for the MC to settle after MC blackout
ec8a7ca drm/i915: fix FORCEWAKE posting reads
710c8f5 drm/radeon: fix a rare case of double kfree
c140fec drm/radeon: fix error path in kpage allocation
72b56e8 efi: Make 'efi_enabled' a function to query EFI facilities
8a9d24b drm/i915: dump UTS_RELEASE into the error_state
36ce28c drm/i915: GFX_MODE Flush TLB Invalidate Mode must be '1' for scanline waits
924782c drm/i915: Disable AsyncFlip performance optimisations
18c8e49 radeon_display: Use pointer return error codes
45bced1 drm/radeon: fix cursor corruption on DCE6 and newer
dd1b4df drm/i915: Implement WaDisableHiZPlanesWhenMSAAEnabled
5afeb70 drm/i915: Invalidate the relocation presumed_offsets along the slow path

Don't think the lockdep annotations do anything that changes the code. But you might want to give it a try...

Whoops, typo in first sentence. What I meant was:

Is the crash consistent? Does it happen every time? The fix should be applied at v3.7.3:

ronald@Alpha /usr/src/linux :) $ git log --oneline --no-merges v3.7^...v3.7.9 -- drivers/gpu/drm/nouveau Makefile
5b7be63 Linux 3.7.9
7773647 Linux 3.7.8
330b8ab drm/nouveau: add lockdep annotations
89c5f13 Linux 3.7.7
07c4ee0 Linux 3.7.6
13280f4 Linux 3.7.5
8380f1a arm64: makefile: fix uname munging when setting ARCH on native machine
8a69ca2 Linux 3.7.4
078314e Linux 3.7.3
39c5cda drm/nvc0/fb: fix crash when different mutex is used to protect same list
c6f94c3 drm/nouveau/clock: fix support for more than 2 monitors on nve0
7fbc316 drm/nouveau: add locking around instobj list operations
4d64387 drm/nouveau: fix blank LVDS screen regression on pre-nv50 cards
ad30b29 drm/nv17-50: restore fence buffer on resume
2370a21 drm/prime: drop reference on imported dma-buf come from gem
cfdfb8f drm/nouveau: fix init with agpgart-uninorth
a77af8b kbuild: Do not remove vmlinux when cleaning external module
e6577f3 Linux 3.7.2
cc86050 Linux 3.7.1
2959440 Linux 3.7

Yes, I'm showing off my newly attained git skillz =P

(In reply to comment #69)
> Is the crash consistent? Does it happen every time? The fix should be
> applied at v3.7.3:
No.

I've downgraded the kernel slightly - from 3.7.9-201 to 3.7.9-101 (both official releases from Fedora) and after the first hibernate/restore cycle I get:

nouveau  [   PFIFO][0000:01:00.0] DMA_PUSHER - Ch 0 Get 0x00000004 Put 0x000000c0 State 0x80000720 (err: INVALID_CMD) Push 0x00000000


However, the restore seems to work OK - I have no side effects after it is done, apart from the above message, so this might be an indication on what goes wrong - don't know, but thought to post it here.

You should test with a vanilla kernel to exclude distro tampering of the kernel. Furthermore, maybe test if the above patch introduces this regression?

Whatever you do, I suggest you open a new bug for this to get some more exposure.

Things have been pretty stable with 3.8.1, but it is getting a bit "twitchy" with 3.8.7 - on two separate occasions I've got the following error on restore:

kernel: nouveau  [     DRM] re-enabling device...
kernel: nouveau  [     DRM] resuming client object trees...
kernel: nouveau  [   VBIOS][0000:01:00.0] running init tables
kernel: nouveau  [     DRM] resuming display...
kernel: nouveau W[   PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 0
kernel: nouveau W[   PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 0
kernel: nouveau W[   PFIFO][0000:01:00.0] unknown intr 0x00010000, ch 0
[...]
kernel: nouveau E[   PFIFO][0000:01:00.0] still angry after 101 spins, halt
kernel: nouveau  [     DRM] 0xD3FB: Parsing digital output script table
kernel: nouveau  [     DRM] Setting dpms mode 3 on TV encoder (output 3)
kernel: nouveau  [     DRM] 0xD3FB: Parsing digital output script table


at which point the whole screen starts with the now-familiar black-and-white rectangles and I have no option, but to reboot.

The above error does not happen very often - maybe every 8-10 hibernate/resume cycles, but with the 3.8.1. kernel I didn't have any errors at all.

Assuming it's nouveau specific and not drm:

2705de0 drm/nouveau: fix handling empty channel list in ioctl's

is between 3.8.6 and 3.8.7. However, there are some generic DRM changes as well:

faec22f KMS: fix EDID detailed timing frame rate
eaa1a61 KMS: fix EDID detailed timing vsync parsing

To be honest, my card is wonky too. Sometimes the screen goes black and it oopses (I think). But I think some of it is also old age...