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
--
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
