|Summary:||Video failed on resume from suspend - G94 / GeForce 9600 GT, 10de:0622|
|Product:||xorg||Reporter:||Adam Williamson <adamw>|
|Component:||Driver/nouveau||Assignee:||Nouveau Project <nouveau>|
|Status:||RESOLVED MOVED||QA Contact:||Xorg Project Team <xorg-team>|
|i915 platform:||i915 features:|
Description Adam Williamson 2014-04-18 01:33:04 UTC
Created attachment 97551 [details] relevant journal output Running Fedora Rawhide, with kernel-3.15.0-0.rc1.git2.2.fc21.x86_64 , xorg-x11-drv-nouveau-1.0.10-1.fc21.x86_64 , xorg-x11-server-common-1.15.0-5.fc21.x86_64 . My hardware is: 01:00.0 VGA compatible controller : NVIDIA Corporation G94 [GeForce 9600 GT] [10de:0622] (rev a1) I just came home and resumed from suspend, and graphics didn't come back. Tried sshing in and restarting X, no go - seems like nouveau crapped the bed and wouldn't come back short of a reboot. I don't think this is reliably reproducible unless it's only just started with a new kernel (I haven't been seeing it on every suspend/resume cycle recently or anything), but I thought I'd log in. Attaching the relevant journalctl output (grepped for 'nouveau', isolated the important time).
Comment 1 Adam Williamson 2014-04-23 22:27:50 UTC
Hum, so actually, this seems fairly reproducible - I'll try and nail down precisely when it started, but likely between 3.14 and 3.15. I tried a suspend and almost immediate resume very soon after booting, and that didn't cause it, but each time I've suspended 'normally' (after the system's been running for a while) and waited for some time before resuming, video has failed on resume. I grabbed drm.debug=15 logs the last time, attaching those. This seems like a fairly significant regression somewhere.
Comment 2 Adam Williamson 2014-04-23 22:41:36 UTC
Created attachment 97836 [details] journalctl output from the attempt to resume onwards (xzipped)
Comment 3 Adam Williamson 2014-05-22 16:32:43 UTC
I'm still hitting this fairly regularly with 3.15rc5. If 3.15 goes out like this, it'll be a noticeable regression from 3.14.
Comment 4 Ilia Mirkin 2014-05-22 16:34:10 UTC
Can you bisect?
Comment 5 Adam Williamson 2014-05-22 16:39:15 UTC
I never really set things up for it, I always mean to but never get around to it :/ I know Ben has an identical card (he picked it up a couple of years back when I had another slippery issue with it), and he was going to try and reproduce this, so that comment was mainly a reminder for him. I will try and get to it if I can, though.
Comment 6 Adam Williamson 2014-05-22 16:58:11 UTC
it's also not 'nicely' reproducible for bisection purposes :/ just booting the system, quickly suspending, and quickly resuming almost never seems to trigger it. it seems to happen much more often when you do a 'production' suspend - really use the system for a while, then suspend, walk away, come back a few hours later and resume. which isn't exactly great for doing a bisect.
Comment 7 Adam Williamson 2014-06-14 15:39:46 UTC
Created attachment 101053 [details] distinctive noise pattern associated with the bug I've continued to see this intermittently throughout the 3.15 cycle. On my first attempt with a 3.16 kernel, nouveau dies on X startup, and on one of the boots, it displayed a distinctive noise pattern I often see in association with this bug too, so it seems like the failure modes might be related.
Comment 8 Adam Williamson 2014-06-14 15:40:35 UTC
It's not really visible with my phone cam, but there are red/green/blue 'noise speckles' in both the white and black blocks.
Comment 9 Adam Williamson 2014-06-25 00:41:27 UTC
Well, 3.16 is broken worse, but I figured it was probably best to file a new bug for clarity. So: https://bugs.freedesktop.org/show_bug.cgi?id=80506