Created attachment 107462 [details] system logs Asus EEE 1225C can boot correctly and start a X session only if you put i915.modeset=0 in Grub kernel line. Otherwise you will get a black screen. ===lspci output=== 00:02.0 VGA compatible controller: Intel Corporation Atom Processor D2xxx/N2xxx Integrated Graphics Controller (rev 09) ===Additional infos=== Using kernel flag i915.modeset=0 solved the problem only for a few boots. After that the system experienced again troubles. On a forum, a user told me he had the same problem and he solved by closing laptop lid, waiting for computer suspension and then resuming the machine. It's crazy but it works! The user also said that he experienced this problem only on 64bit Fedora, and he says that 32 bit Fedora works fine... # find /sys/class/drm/*/status /sys/class/drm/card0-DP-1/status /sys/class/drm/card0-DVI-D-1/status /sys/class/drm/card0-LVDS-1/status /sys/class/drm/card0-VGA-1/status ===Kernel Version=== 3.15.10-201.fc20.x86_64 ===Fedora bugreport=== https://bugzilla.redhat.com/show_bug.cgi?id=1140877
Hi Another test would be: instead of suspending/resuming, you could try to VT switch (press CTRL+ALT+F1-F8) and see if it works. Can you please boot with drm.debug=0xe, reproduce the issue, then suspend/resume and attach the dmesg here? Please attach the raw file, not a compressed version. Another thing which you could try: - Install intel-gpu-tools from http://cgit.freedesktop.org/xorg/app/intel-gpu-tools - Compile it - Boot the machine, reproduce the problem - Run "sudo ./tools/intel_reg_dumper > before-suspend.txt" - Suspend/resume - Run "sudo ./tools/intel_reg_dumper > after-suspend.txt" - Then attach both files to this bug report. You may need to use SSH for this, or maybe do some blind-typing :) Thanks, Paulo
Also: is this a regression? Are you aware of any Kernel that does not have this problem? Can you try to reproduce this problem on our latest development tree from http://cgit.freedesktop.org/drm-intel?h=drm-intel-nightly (drm-intel-nightly branch), or at least from one of the trees from Linus, or the most recent stable tree?
Created attachment 107923 [details] dmesg with drm.debug=0xe
(In reply to Paulo Zanoni from comment #1) > - Run "sudo ./tools/intel_reg_dumper > before-suspend.txt" There is no intel_reg_dumper. Here is the folder tree http://paste.fedoraproject.org/142403/34600861
(In reply to Paulo Zanoni from comment #2) > Also: is this a regression? Are you aware of any Kernel that does not have > this problem? > > Can you try to reproduce this problem on our latest development tree from > http://cgit.freedesktop.org/drm-intel?h=drm-intel-nightly (drm-intel-nightly > branch), or at least from one of the trees from Linus, or the most recent > stable tree? I cannot say if it is a regression, because it is a first installation. Neither newer kernel 3.16.4-200.fc20.x86_64 solved the problem. As soon as possible I try with latest drm development tree
(In reply to Germano Massullo from comment #4) > (In reply to Paulo Zanoni from comment #1) > > - Run "sudo ./tools/intel_reg_dumper > before-suspend.txt" > > There is no intel_reg_dumper. Here is the folder tree > > http://paste.fedoraproject.org/142403/34600861 You need to build igt and the tools first.
(In reply to Germano Massullo from comment #3) > Created attachment 107923 [details] > dmesg with drm.debug=0xe This is not using i915.ko, it's using the gma500 cdv driver. I'm not sure what's the proper way to reassign the bug to them...
Created attachment 108614 [details] intel_reg_dumper > before_suspend.txt
Created attachment 108615 [details] intel_reg_dumper > after_suspend.txt
I have no longer access to the affected machine, nor I had any feedback from component developers. I close the bugreport as wontfix
OK, thanks.
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.