xserver fails to resume from suspend (f20)

[Dan Mossor]

On 12/19/2013 06:09 AM, Neal Becker wrote:
> Adam Williamson wrote:
>
>> On Wed, 2013-12-18 at 20:18 -0500, Neal Becker wrote:
>>> Adam Williamson wrote:
>>>
>>>> On Wed, 2013-12-18 at 11:56 -0800, Adam Williamson wrote:
>>>>> On Wed, 2013-12-18 at 07:33 -0500, Neal Becker wrote:
>>>>>> Neal Becker wrote:
>>>>>>
>>>>>>> Just updated f19->f20.  Now resume from suspend is broken.
>>>>>>>
>>>>>>> First tried with nvidia blob.  On resume just got blank screen.  Could
>>>>>>> switch vt, but couldn't wake up display.
>>>>>>>
>>>>>>> Then removed nvidia back to nouveau.  This time, on resume I just see
>>>>>>> the fedora
>>>>>>> boot splash.  Cannot get any response to keys, except ctrl-alt-bs
>>>>>>> (could switch vt).
>>>>>>>
>>>>>>
>>>>>> Nothing interesting found in /var/log/messages or
>>>>>> /var/log/Xorg.0.log.old, but one note: I'm using kde (kdm)
>>>>>
>>>>> That's fun - I'm seeing something similar on F21 (and had it
>>>>> intermittently with late F20) but on GNOME. On GNOME, restarting the
>>>>> Shell with alt-f2, r makes everything work.
>>>>>
>>>>> Do you have a cursor when you see the bootsplash? Can you move it, and
>>>>> does it change shape in the places you'd expect it to? I suspect the
>>>>> same thing's happening to us both...
>>>>
>>>> Just noticed something interesting - I just switched VTs, and saw the
>>>> same bug (when I came back to VT1, the bootsplash was showing, and I
>>>> needed alt-f2, r to get Shell back). Does that happen to you too?
>>>
>>> I have a cursor I can move.  Didn't notice it change shape - I'll check next
>>> time.
>>>
>>> Don't quite understand the 2nd phenomenon you're describing.  Is this when
>>> it's
>>> locked up on resume that you see this?  Or just any time you switch VTs?
>>> Don't quite understand how you triggered it - all I have to do is open the
>>> laptop lid and I'm looking at a bootsplash and have to kill xserver.
>>
>> Just switching VTs with no suspend involved seems to trigger it here,
>> now. I don't get much in the system logs, though. I'll have to
>> investigate with drm.debug , see if it's a nouveau issue.
>
> Remember I first saw this with nvidia blob - so it's not a nouveau issue.
>
> Here is another strange data point.
>
> It seems to happen 100% of the time when I close laptop and transport to/from
> work.  But last night tested 3 times close - wait till light is flashing
> indicating sleep, then open - and no failures.
>
> Then closed it for the night and checked in the morning.  It had failed.
>
> So strange as it may seem - it appears that it has to be shut for more than a
> short time to fail.
>
When I was on F20, I was experiencing this with nouveau. Switching to 
the nvidia blob fixed that and many other video related issues (with KDE 
- gnome is perpetually broken). I was never able to track down a reason 
for that because I wasn't ready to become a tester yet when this problem 
first occurred.

However, I am now using F21 and nouveau, and the problem is back. And 
yet, mine is still slightly different from both of the other cases - my 
system is 90% unresponsive. I say 90% because I can ssh into it, but it 
takes forever to authenticate and run any commands. The pipe eventually 
breaks and kicks me out. If I can manage to get in again (which is rare) 
I can try to reboot it from command line, but more often than not I have 
to do a hard shutdown since the system is unresponsive, even to the 
power button being pushed. The screen itself - whether the laptop screen 
or an external monitor connected via HDMI - never activates.

Upon rebooting today, though. ABRT had caught a race condition on CPU2, 
tied directly to nouveau and drm. I am currently working through those 
two ABRT bugs and will attach them to bz 1044304 because my gut feeling 
at this point is that it is tied together through the unknown opcode 
error, and is a much farther-reaching problem than I first thought.

-- 
Dan Mossor
Systems Engineer at Large
Fedora QA Team Volunteer FAS: dmossor IRC: danofsatx
San Antonio, Texas, USA