Bug 596557
| Summary: | KMS initialization breaks display [8086:0046] | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> | ||||||||
| Component: | xorg-x11-drv-intel | Assignee: | Adam Jackson <ajax> | ||||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | low | ||||||||||
| Version: | 14 | CC: | aalam, ajax, alejandro_liu, alfredo.maria.ferrari, dks, giles, luke, mishu, redhat, twegener, xgl-maint | ||||||||
| Target Milestone: | --- | Keywords: | CommonBugs, Patch, Triaged | ||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | RejectedNTH https://fedoraproject.org/wiki/Common_F14_bugs#edp_problems | ||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2012-08-16 16:56:36 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Adam Williamson
2010-05-26 23:48:07 UTC
Created attachment 417065 [details]
lspci output on the affected system
By the looks of the logs, the following appears in /var/log/messages when loading i915 *without* KMS: May 26 16:39:05 vaioz kernel: [drm] Initialized drm 1.1.0 20060810 May 26 16:39:05 vaioz kernel: pci 0000:00:02.0: power state changed by ACPI to D0 May 26 16:39:05 vaioz kernel: pci 0000:00:02.0: power state changed by ACPI to D0 May 26 16:39:05 vaioz kernel: pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 May 26 16:39:05 vaioz kernel: mtrr: no more MTRRs available May 26 16:39:05 vaioz kernel: [drm] MTRR allocation failed. Graphics performance may suffer. May 26 16:39:05 vaioz kernel: acpi device:00: registered as cooling_device4 May 26 16:39:05 vaioz kernel: input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input7 May 26 16:39:05 vaioz kernel: ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) May 26 16:39:05 vaioz kernel: [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 May 26 16:39:05 vaioz kernel: modprobe used greatest stack depth: 3176 bytes left when loading i915 *with* KMS, nothing at all appears in the logs. There's nothing in /var/log/messages between where boot is complete, and when the next boot starts up. I will attach the entire /var/log/messages . Here's my timing notes. All refer to today, May 26th: 16:36:28 - boot complete ~16:37 - modprobe i915 , screen blank with backlight on 16:38:35 - second boot complete ~16:39 - modprobe i915 modeset=0, screen fine -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Created attachment 417066 [details]
/var/log/messages from the affected system
if you're wondering why the adapter apparently disappears entirely outside of these couple of test boots, to actually *use* the system I boot with the NVIDIA adapter selected, and use the NVIDIA proprietary driver (which works). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Final note - this happens with both 2.6.34-2.fc14.x86_64 and 2.6.33.4-95.fc13.x86_64 . -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers with thanks to the inhabitants of #fedora-devel, I'll attach the drm debug messages (with drm.debug=0x06 as directed by ajax). -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Created attachment 417742 [details]
drm debug messages from a load of i915
This is still the case with the latest F14 kernel (2.6.35.2-9.fc14) - same behaviour, as soon as KMS kicks in, the system hangs with backlight on. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers *** Bug 618481 has been marked as a duplicate of this bug. *** Upstream: https://bugs.freedesktop.org/show_bug.cgi?id=29141 Jesse Barnes apparently now has a matching system and is working on this. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers Jesse's posted fixes to his edp-hacks branch which others have tested with positive results - see the upstream bug. I'm trying to patch the fixes onto an F15 kernel build to test right now. I'm fairly sure the fixes are the commits: 17 hours ago Jesse Barnes drm/i915/dp: more broken sequencing fixes edp-hacks commit | commitdiff | tree | snapshot 43 hours ago Jesse Barnes drm/i915/dp: broken eDP power sequencing bits commit | commitdiff | tree | snapshot 43 hours ago Jesse Barnes drm/i915/dp: wait for panel idle when enabling/disablin... commit | commitdiff | tree | snapshot that's: * http://git.kernel.org/?p=linux/kernel/git/jbarnes/drm-intel.git;a=commit;h=f0c744bbce33c64bedbe15d9785efafd5380c58c * http://git.kernel.org/?p=linux/kernel/git/jbarnes/drm-intel.git;a=commit;h=050486e2f3f8aa97c5f8afdc9b898b00a7114493 * http://git.kernel.org/?p=linux/kernel/git/jbarnes/drm-intel.git;a=commit;h=4da9b7d2917beb1f8aa9e7e4f6d4f10338b0f637 i think the other changes in the branch are not directly related to this bug, but haven't checked yet, it would probably be best to ask Jesse. Proposing this as NTH for final. Discussed at the blocker/NTH review meeting today, given the ickiness of making changes to panel code this late, we decided not to take it as NTH. so I'm sucking at making these patches apply to the f15 kernel and build. But they have gone into drm-intel-next as part of a giant change set (just look at all the commits from Jesse dated together, late on 7th Oct). ajax, could you possibly just pull that whole change set into the f15 kernel (note: f15 not f14) for me to try? thanks! OK, so I couldn't get a clean patch against a Fedora kernel, but I just built a kernel straight from the upstream drm-intel-next tree and confirmed that it works great. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers bumping this to at least 14 because i don't see it being backported to 13; it may eventually only be fixed in rawhide/15. it was fixed briefly in rawhide by a backport of drm-intel-next/edp-fixes but that was backed out apparently for causing other problems, so current status is that it's still broken everywhere. I had similar problems on a Lenovo U160 with integrated Intel graphics. linux-2.6.37-rc8 fixes the problem for me. Have you tried it? Yes, and no. When it comes to graphics, 'similar' problems are generally not similar at all. I'm already well aware of all relevant changes for this bug. But thanks. The reason this report isn't changing much is that all the interesting stuff is happening on the upstream report. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. 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 '14' 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 14 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 |