Created attachment 94577 [details] Xorg.0.log I attached Xorg.0.log And here is the dsmeg output : http://paste.fedoraproject.org/79496/94102139/ I have a Dell Inspiron 1525 running with Intel® 965GM graphics
My kernel version is 3.13.3-201.fc20.x86_64
What's the failure mode?
Chris Wilson, the failure mode is 'black screen on resuming', on other words, the screen stays black and the capslock light doesn't toggle.
The blank screen is because your BIOS changed the hardware state across resume, but I had expected that to be solvable with xrandr --output LVDS1 --off ; xrandr --output LVDS1 --preferred (which is what would have happened automatically during resume but until quite recently). However, that capslock is no longer responsive suggests that there is also a system hang not apparent from the dmesg. Is the machine pingable? Are you able to log in remotely? Or does closing and opening the lid help?
I actually solved my problem by booting into Fedora with an older version of the kernel, that is 3.11.10-301.fc20.x86_64
(In reply to comment #3) > Chris Wilson, the failure mode is 'black screen on resuming', on other > words, the screen stays black and the capslock light doesn't toggle. Please blacklist i915.ko and try a suspend resume cycle.
(In reply to comment #6) > (In reply to comment #3) > > Chris Wilson, the failure mode is 'black screen on resuming', on other > > words, the screen stays black and the capslock light doesn't toggle. > > Please blacklist i915.ko and try a suspend resume cycle. Well, I don't know how to do that. I checked http://docs.fedoraproject.org/en-US/Fedora/16/html/Installation_Guide/rescuemode_drivers-blacklisting.html However, I do not know how Rescue Mode works. And is the name of the driver “i915.ko”?
Depending on your distro, modprobe.blacklist=i915 kernel parameter might be enough. Or adding "blacklist i915" to /etc/modprobe.d/blacklist.conf. Check lsmod before suspend/resume to be sure.
(In reply to comment #8) > Depending on your distro, modprobe.blacklist=i915 kernel parameter might be > enough. Or adding "blacklist i915" to /etc/modprobe.d/blacklist.conf. Check > lsmod before suspend/resume to be sure. Sorry for the late reply, I didn't really have the time to get deeper into the problem. I tried the latter (adding "blacklist i915" to /etc/modprobe.d/blacklist.conf), but in fact I had to create the blacklist file, therefore I don't know if just putting in "blacklist i915" is enough. Anyway, it didn't work. I could still see i915 in lsmod and the suspend-resume cycle didn't work just like before.
This may help? http://comments.gmane.org/gmane.linux.redhat.fedora.general/435296ivers-blacklisting.html You have to rebuild your initrd after blacklisting the module. We're trying to figure out whether i915 is causing your resume crash or something else. If the resume still fails without i915 loaded, then you can look elsewhere for the problem. Another thing you could try would be to build the drm-intel-nightly branch from git://anongit.freedesktop.org/drm-intel and see if that works. If so, it would mean Fedora has something to backport and you could file a bug with them.
Ping, any update?
Sorry, this sort of tweaking is too advanced for me. I don't know what 'On the long run, you could disable all CONFIG_DRM_i915 options in your kernel .config and recompile.' means, I don't know what recompiling is, I don't know what 'Rebuild the initial ramdisk.' means and I sure don't want to play with nightly builds. I'm not interested in going further. I prefer using 3.11.10-301.fc20.x86_64 and giving up on this bug. I hope someone more advanced and interested that me will have the same issue and will work on this matter. I doesn't matter if it never happens.
Dell Inspiron 1525, 965gm, resume broken since 3.13 -> I'm assuming this is a dupe. I expect the fix to be backported to stable kernels within a few weeks. *** This bug has been marked as a duplicate of bug 76520 ***
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.