Red Hat Bugzilla – Full Text Bug Listing
|Summary:||[Cantiga] Screen goes blank (either completely or gradually with acpi_osi=Linux)|
|Product:||[Fedora] Fedora||Reporter:||Kalpa Welivitigoda <callkalpa>|
|Component:||xorg-x11-drv-intel||Assignee:||Adam Jackson <ajax>|
|Status:||CLOSED WONTFIX||QA Contact:|
|Version:||15||CC:||ajax, antonio.montagnani, bill-bugzilla.redhat.com, xgl-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-08-07 10:43:14 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Kalpa Welivitigoda 2011-06-09 13:49:30 EDT
Description of problem: After I select Fedora from the grub menu the screen goes blank, nothing is visible. How reproducible: By booting the system without "nomodeset" kernel argument. Actual results: Blank screen. It seems that the brightness is low or it is off completely. Expected results: Visible screen with loading information Additional info: The issue is on my laptop. It is Acer Aspire 4736z. I tried to install (fresh install) Fedora 15 with a DVD. After I select "install or upgrade system" the progress of loading the kernel ran and the screen went blank. Then I managed to install with "Basic video settings" option. Now there is "nomodeset" kernel argument set by default. If I remove it at booting the screen goes blank. If I boot with it, the GUI appears but the screen is stretched and it is difficult to read the screen. Further GNOME 3 doesn't work, it is the fail safe mode.
Comment 1 Matěj Cepl 2011-06-10 05:01:04 EDT
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information especially concerning your hardware we require that will be helpful in our diagnosis of this issue. If the computer is not completely frozen when installation fails, switch to the console (Ctrl+Alt+F2) and copy /tmp/X* and /var/log/anaconda.xlog to some other place -- USB stick, some other computer via network, somewhere on the Internet, and please attach it to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above. If the computer is completely useless after installation fails, you can also install Fedora with a VESA mode driver (see http://docs.fedoraproject.org/en-US/Fedora/13/html/Installation_Guide/ for more information on that). Then after successful installation you can collect /var/log/anaconda.xlog, /var/log/Xorg.0.log, and the output of the program dmesg instead. Or you can install Fedora in a text mode completely, and then start X after that. If it fails, still /var/log/Xorg.0.log and the output of dmesg program from the failed attempt to start X would be useful. We will review this issue again once you've had a chance to attach this information. Thank you very much in advance.
Comment 3 Kalpa Welivitigoda 2011-06-10 06:57:51 EDT
Thanks for the concern. Well, installation didn't fail. I managed to install with Basic Video Settings option and now I am on Fedora 15. The issue is that when I try to install normally my laptop screen goes off. Now (after I login after the installation) the screen is stretched. And by default the system boots with nomodeset argument set. If I remove it the screen goes off. The log file I have attached is the file after I login to GNOME.
Comment 4 Matěj Cepl 2011-06-10 12:48:03 EDT
This is most likely issue in kernel, and that isn't covered in /var/log/Xorg.0.log you gave us. Please add drm.debug=0x04 to the kernel command line, remove nomodeset, restart computer, and attach from failed attempt * your X server config file (/etc/X11/xorg.conf, if available), * X server log file (/var/log/Xorg.*.log) * output of the dmesg command (if you manage to get to the command line somehow - Ctrl-Alt-F2 or ssh), and * system log (/var/log/messages) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Comment 5 Kalpa Welivitigoda 2011-06-10 13:36:21 EDT
I attached drm.debug=0x04 and removed nomodeset. Then the screen was hardly visible. So I set drm.debug=0x004 and nomodeset.
Comment 10 Kalpa Welivitigoda 2011-06-10 13:41:07 EDT
Created attachment 504172 [details] Xorg.4.log
Comment 11 Kalpa Welivitigoda 2011-06-10 13:41:47 EDT
Created attachment 504173 [details] Xorg.5.log
Comment 12 Kalpa Welivitigoda 2011-06-10 13:42:09 EDT
Created attachment 504174 [details] Xorg.9.log
Comment 14 Kalpa Welivitigoda 2011-06-10 13:50:49 EDT
Created attachment 504178 [details] system log
Comment 15 Matěj Cepl 2011-06-10 15:05:47 EDT
(In reply to comment #5) > I attached drm.debug=0x04 and removed nomodeset. Then the screen was hardly > visible. So I set drm.debug=0x004 and nomodeset. I am sorry, I should be more explicit about that. That removing of nomodeset was not meant to be used permanently, but just for the one case so that we can get logs with the kernel messages showing us what is wrong. nomodeset switches off all kernel parts of X driver, so we don't get any information about what's wrong. So yes, removing nomodeset will probably make your screen very dim (does it mean that the backlight of your LCD monitor is switched off?), but I hope it could be enough for you to login in the text console and run dmesg >dmesg.out and switching off the computer. That dmesg.out would be very helpful to us. Thank you
Comment 16 Kalpa Welivitigoda 2011-06-10 23:35:49 EDT
Created attachment 504230 [details] dmesg.out (without nomodeset)
Comment 17 Kalpa Welivitigoda 2011-06-10 23:37:45 EDT
(In reply to comment #15) > (In reply to comment #5) > > I attached drm.debug=0x04 and removed nomodeset. Then the screen was hardly > > visible. So I set drm.debug=0x004 and nomodeset. > > I am sorry, I should be more explicit about that. That removing of nomodeset > was not meant to be used permanently, but just for the one case so that we can > get logs with the kernel messages showing us what is wrong. nomodeset switches > off all kernel parts of X driver, so we don't get any information about what's > wrong. > > So yes, removing nomodeset will probably make your screen very dim (does it > mean that the backlight of your LCD monitor is switched off?), but I hope it > could be enough for you to login in the text console and run > Nope it is dim. When it is in dim I can switch off the monitor and I can see a difference. So it is dim and not switched off > dmesg >dmesg.out > > > and switching off the computer. That dmesg.out would be very helpful to us. > > Thank you I have attached the dmesg as dmesg.out and this file is when nomodeset is off
Comment 18 Kalpa Welivitigoda 2011-06-11 02:30:35 EDT
I followed the discussion and added "acpi_osi=Linux" at the end of the kernel line at boot up (without nomodeset). Initially the screen was dim. Then I tried to change the brightness with my keyboard shortcuts. And it worked. But there was still an issue. When I press brightness up shortcut the brightness went down and when I press brightness down shortcut the brightness went up. However I managed to make it visible. And the GNOME3 functionality is there. It's no more fail safe mode. Then I restarted without nomodeset and acpi_osi=Linux, and it works fine now. What I suspect is that at boot up system tries to give the maximum brightness. For me that is the minimum brightness (because keyboard shortcuts worked completely the opposite way). Earlier when the screen was dim I tried to adjust the brightness with keyboard shortcuts but didn't work. So acpi_osi=Linux has done something. And now the systems functions well even without acpi_osi=Linux. Now (without acpi_osi=Linux) I can't change the screen brightness with keyboard shortcuts, the progress bar in the popup works but the brightness is not adjusted. I hope this will give you some clues to figure out where things went wrong and I am happy provide you any information and see this bug fixed. 1 - http://www.fedoraforum.org/forum/showthread.php?t=247355 Thanks
Comment 19 Kalpa Welivitigoda 2011-06-12 06:53:56 EDT
I have to have acpi_osi=Linux as an kernel argument all the time and initially the screen is all black. I have to adjust the brightness with keyboard shortcuts all the time.
Comment 20 Bill McGonigle 2011-06-21 00:58:25 EDT
Same problem here, Acer Aspire 5736, f15 w/ current updates. Notes: 1) without i915.modeset=0 the backlight does appear to start in the off position. Hitting Fn-brighter once turns it back on. On my keyboard, brighter is Fn-left-arrow and dimmer is Fn-right-arrow, which is different than I usually see. 2) Starting with kernel modesetting gets me a graphical console that works fine until X tries to start. 3) X won't start with kernel modesetting, either automatically or from runlevel 3. X -configure fails. With nomodeset 1024x768 is the only available resolution once logged in to a session. Of note, kdm comes up at the correct resolution with nomodeset but once the X session starts it falls back to 1024x768. 4) acpi_osi=Linux is required for the backlight keys to function. I see no lasting benefit to having turned it on and off as described in Comment #18 - still doesn't work with it off here. 5) same symptoms booting from the F15 DVD. nomodeset option works at reduced resolution, black screen with default graphical installer. 6) Fedora 14 LiveCD brings up video with what seems to be full resolution. xrandr reports 1366x768.
Comment 21 Bill McGonigle 2011-06-21 00:59:59 EDT
Created attachment 505741 [details] kernel messages with drm.debug=0x04, kms
Comment 22 Bill McGonigle 2011-06-21 01:00:49 EDT
Created attachment 505742 [details] Xorg.0.log for kdm, i915.modeset=0
Comment 23 Bill McGonigle 2011-06-21 01:02:38 EDT
Created attachment 505743 [details] Xorg.0.log for user, kms
Comment 24 Fedora End Of Life 2012-08-07 10:43:19 EDT
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping