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> | ||||||||
Severity: | normal | ||||||||||
Priority: | high | ||||||||||
Version: | unspecified | ||||||||||
Hardware: | x86-64 (AMD64) | ||||||||||
OS: | Linux (All) | ||||||||||
Whiteboard: | |||||||||||
i915 platform: | i915 features: | ||||||||||
Attachments: |
|
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. Created attachment 97836 [details]
journalctl output from the attempt to resume onwards (xzipped)
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. Can you bisect? 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. 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. 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.
It's not really visible with my phone cam, but there are red/green/blue 'noise speckles' in both the white and black blocks. 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 |
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.
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 [0300]: 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).