Summary: | [Ironlake LVDS Vaio-Y] blank screen (with backlight) after resuming from suspend or hibernate | ||
---|---|---|---|
Product: | DRI | Reporter: | Michel Alexandre Salim <salimma> |
Component: | DRM/Intel | Assignee: | Chris Wilson <chris> |
Status: | CLOSED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | CC: | jbarnes |
Version: | XOrg git | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
See Also: | https://bugzilla.kernel.org/show_bug.cgi?id=27312 | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Bug Depends on: | 36656 | ||
Bug Blocks: | |||
Attachments: |
Description
Michel Alexandre Salim
2011-02-18 04:07:23 UTC
Created attachment 43515 [details]
dmesg before suspend
Created attachment 43516 [details]
dmesg after suspend
Created attachment 43517 [details]
intel_reg_dumper before suspend
Created attachment 43518 [details]
intel_reg_dumper after suspend
Created attachment 43520 [details]
intel_gpu_dump before suspend (part 1)
I used split for this since the original file size exceeds Bz limits. Just concat the file to get the original back
Created attachment 43521 [details]
intel_gpu_dump before suspend (part 2)
Created attachment 43522 [details]
intel_gpu_dump after suspend (part 1)
Created attachment 43523 [details]
intel_gpu_dump after suspend (part 2)
*** Bug 34417 has been marked as a duplicate of this bug. *** This should be fixed in rc6 with: commit ed764e7ca042dbf4cc1c7f4e12cd842c7789f133 Author: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de> Date: Sat Feb 12 01:40:16 2011 +0100 ACPI / Video: Probe for output switch method when searching video devices. This patch reverts one hunk of 677bd810eedce61edf15452491781ff046b92edc "ACPI video: remove output switching control", namely the removal of probing for _DOS/_DOD when searching for video devices. along with bug 34417. I'm still seeing this with both Fedora's 2.6.38-0.rc6.git2.1 and drm-intel-fixes 011b9910bdaf2e52c48c012490ab444fceea1959 (post-RC6) -- should I reopen this and my other bug? Reported fix does not actually work The brightness issue (34417) is still unresolved, but the kernel bug tracker report referenced in the Git commit does contain a user report of an additional kernel switch that I need to enable to at least get the display restored when resuming: i915.lvds_use_ssc=0 Now that there's a quirk infrastructure for disabling SSC on given models, perhaps this particular Vaio Y should be blacklisted as well (see the bug this depends on and the posted Git commit fixing it) Where do I get the subsystem_vendor and subsystem_device numbers that I need to add my machine to the blacklist? From lspci -nnvv, it looks like 104d:9076 needs to be added to the quirk list. Would blacklisting this affect other Sony devices, or are these numbers unique to my particular model? 00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02) (prog-if 00 [VGA controller]) Subsystem: Sony Corporation Device [104d:9076] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 41 Region 0: Memory at d0000000 (64-bit, non-prefetchable) [size=4M] Region 2: Memory at c0000000 (64-bit, prefetchable) [size=256M] Region 4: I/O ports at 5050 [size=8] Expansion ROM at <unassigned> [disabled] Capabilities: <access denied> Kernel driver in use: i915 Kernel modules: i915 Created attachment 49615 [details] [review] drm/i915: Add quirk to disable SSC on Sony Vaio Y2 Patch fixing this, to be applied to the 3.0 source tree, as sent to the mailing lists: http://article.gmane.org/gmane.linux.kernel/1172092 A patch referencing this bug report has been merged in Linux v3.1-rc1: commit 070d329ae52e2fde341771d753a5b728145881f4 Author: Michel Alexandre Salim <salimma@fedoraproject.org> Date: Thu Jul 28 18:52:06 2011 +0200 drm/i915: Add quirk to disable SSC on Sony Vaio Y2 |
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.