Hide Forgot
Booting a x420s after initial installation of Fedora 15 comes up with a gabled screen (black, some vertical stripes on the right side) on the internal display after running through the text-mode part of the kernel start-up. If an external display is attached, that may work. Pressing FN+F7 a couple of times to cycle through different modes gives you the internal display back, however flickering. After pluggin / unplugging the external monitor a couple of times, the flickering went away. I have not found a way other than nomodeset to get the internal display to work without first attaching an external display. Kernel: 2.6.38.6-27.fc15.x86_64 The device info from dmidecode is: System Information Manufacturer: LENOVO Product Name: 4170CTO Version: ThinkPad T420s lspci -v says about the graphics card: 00:02.0 VGA compatible controller: Intel Corporation Device 0126 (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 21d2 Flags: bus master, fast devsel, latency 0, IRQ 43 Memory at d0000000 (64-bit, non-prefetchable) [size=4M] Memory at c0000000 (64-bit, prefetchable) [size=256M] I/O ports at 5000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 Kernel modules: i915
In addition, dmesg has this: """ [ 1.993970] i915 0000:00:02.0: power state changed by ACPI to D0 [ 1.993974] i915 0000:00:02.0: power state changed by ACPI to D0 [ 1.993980] i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 1.993983] i915 0000:00:02.0: setting latency timer to 64 [ 2.022673] mtrr: no more MTRRs available [ 2.022676] [drm] MTRR allocation failed. Graphics performance may suffer. [ 2.023162] i915 0000:00:02.0: irq 43 for MSI/MSI-X [ 2.023167] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 2.023168] [drm] Driver supports precise vblank timestamp query. [ 2.150951] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 2.230598] fbcon: inteldrmfb (fb0) is primary device [ 2.291561] Console: switching to colour frame buffer device 200x56 [ 2.295808] fb0: inteldrmfb frame buffer device [ 2.295810] drm: registered panic notifier [ 2.298561] acpi device:01: registered as cooling_device4 [ 2.298706] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input5 [ 2.298771] ACPI: Video Device [VID] (multi-head: yes rom: no post: no) [ 2.298912] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 [ 2.309241] dracut: Starting plymouth daemon """ and later """ [ 4440.826795] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 52927, at 52927], missed IRQ? [ 5372.719653] [drm:i915_hangcheck_ring_idle] *ERROR* Hangcheck timer elapsed... blt ring idle [waiting on 177820, at 177820], missed IRQ? """ which re-appears a couple of times.
Another workaround is to log-in blindly and then suspend by FN+F4 or closing the lid. Once the machine comes back from suspend, the screen works fine.
I'm getting the same on my T420s. Garbles about the vgaarb: line. Came up fine the first boot after install, but not since.
From IRC - apparently the gentoo 2.6.39-intel-drm-fixes kernel works. Also, rawhide kernel 3.0-0.rc3.git5.1.fc16 works as well. Hope that helps.
This also is happening for me on i686. The blind boot workaround works for me. You don't need to log in before suspending/closing the lid in order to get the screen back. The screen flicker is bad after the first suspend, but decreases over time. Kernel: 2.6.38.8-32.fc15.i686 lspci -v: 00:02.0 VGA compatible controller: Intel Corporation Device 0126 (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 21d2 Flags: bus master, fast devsel, latency 0, IRQ 41 Memory at d0000000 (64-bit, non-prefetchable) [size=4M] Memory at c0000000 (64-bit, prefetchable) [size=256M] I/O ports at 4000 [size=64] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 Kernel modules: i915 # modinfo i915 | grep -v alias filename: /lib/modules/2.6.38.8-32.fc15.i686/kernel/drivers/gpu/drm/i915/i915.ko license: GPL and additional rights description: Intel Graphics author: Tungsten Graphics, Inc. license: GPL and additional rights srcversion: 30C49E803852A529DC4103E depends: drm,drm_kms_helper,i2c-core,video,i2c-algo-bit vermagic: 2.6.38.8-32.fc15.i686 SMP mod_unload 686 parm: modeset:int parm: fbpercrtc:int parm: powersave:int parm: semaphores:int parm: i915_enable_rc6:int parm: lvds_downclock:int parm: lvds_use_ssc:int parm: reset:bool
Possibly fixed in 2.6.38.8-34? please test...
Downloaded 2.6.38.8-34.fc15.i686 from koji.fedoraproject.org, installed and still have the same symptoms.
Same here, still didn't work.
Installed 2.6.38.8-35.fc15.i686 from koji, still have same symptoms.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please add drm.debug=0x04 to the kernel command line, restart computer, and attach * your X server config file (/etc/X11/xorg.conf, if available), * X server log file (/var/log/Xorg.*.log) * output of the dmesg command, 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.
Created attachment 512664 [details] excerpt from /var/log/messages
Created attachment 512665 [details] Xorg.0.log
Created attachment 512666 [details] dmesg
Attached requested information. I replaced my hostname with "myhost" and removed lines from messages that were not part of the boot process.
Still waiting on logs from the reporter.
Logs attached to this bug on 2011-07-13.
(In reply to comment #16) > Logs attached to this bug on 2011-07-13. The key word has been "reporter".
(In reply to comment #17) > The key word has been "reporter". Ah, my apologies. However, I do have a couple of questions: Your initial request for the logs did not specify that they must come from the reporter. As I have experienced the exact same symptoms reported by Mr. Riek, I thought my logs would be useful to the resolution of this bug. Do I need to submit my own bug in order for you to review the information I provided? Thank you, Jeremy
Sorry, wasn't watching the mail address that I used for my personal account. I apologize for the delay. I am uploading a log now. The problem still exists - interestingly the workaround for the flickering stopped working (which is why I happened to check back on the bug).
Created attachment 516388 [details] Log of X startup on t420s
I believe this is now fixed?
Works here with kernel-2.6.41.1-1.fc15.x86_64
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