Created attachment 76066 [details] eDP black screen dmesg Environment: ---------------------------- Kernel: (linux-3.8.y)19b00d2dc9bedf0856e366cb7b9c7733ded659e4 Some additional commit info: Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Date: Mon Mar 4 06:04:08 2013 +0800 Linux 3.8.2 lspci: ---------------------------- 00:00.0 Host bridge: Intel Corporation Device 0c04 (rev 06) 00:02.0 VGA compatible controller: Intel Corporation Device 0416 (rev 06) BIOS: ---------------------------- BR_Production_QM87_5MB_BIOS-112.1_ME-9.0.0.1310.v3_Undertest Reproduce step: ---------------------------- 1. Plugged DP and eDP 2. reboot 3. xinit& 4. Then you will find eDP black screen, but if I use xrandr clone mode, eDP will display OK. Description: ---------------------------- I have used an older kernel, there's not this issue. I will give detail description about which branch, other platform test results when all of our testing finished. If you need some special messages, please comments.
I have retest it on all branches, because our nightly kernel can reproduce this bug, so I trying to figure out which branch caused this issue: drm-intel-next-queued: correct drm-intel-fixes: correct up-stream branches: --------------------- drm-next: reproduced this bug Kernel Info: --------------------- Kernel: (drm-intel-nightly)b81e059ec5a7128622ab5d74d78e9b4f361b54ae Some additional commit info: Merge: 35f8bad 210561f Author: Dave Airlie <airlied@redhat.com> Date: Wed Feb 20 11:40:49 2013 +1000 Description: -------------------- This issue is caused by merging up stream branches, but internal branches are good, so I'm surprised that why nightly kernels also have this issue.
(In reply to comment #1) > This issue is caused by merging up stream branches, but internal branches > are good, so I'm surprised that why nightly kernels also have this issue. what do you mean by "internal branches"?
(In reply to comment #2) > (In reply to comment #1) > > This issue is caused by merging up stream branches, but internal branches > > are good, so I'm surprised that why nightly kernels also have this issue. > > what do you mean by "internal branches"? internal branches: drm-intel-next-queued and drm-intel-fixes Both of them don't exist this bug. I retest 3.8 kernel, it doesn't have this issue.
I've moved branches around a bit around the merge window, so could very well be that just testing drm-intel-* branches doesn't test all relevant things. Can you try to figure out a working baseline and then bisect from there to -nightly, please?
After bisect, I find the bad commit which I reported, is exactly the first bad.(this commit is on drm-next branch, and merged to nightly) Kernel Info: --------------------- Kernel: (drm-intel-nightly)b81e059ec5a7128622ab5d74d78e9b4f361b54ae Some additional commit info: Merge: 35f8bad 210561f Author: Dave Airlie <airlied@redhat.com> Date: Wed Feb 20 11:40:49 2013 +1000
I'm confused. Can you please cite the exact git sha1? There are already a few different sha1s mentioned in this bug report by you, and to me it's not clear which one it is.
(In reply to comment #6) > I'm confused. Can you please cite the exact git sha1? There are already a > few different sha1s mentioned in this bug report by you, and to me it's not > clear which one it is. Description: ----------------- I have tested the parents: 35f8badc1cf652381fa3f82c1fbea39f4dbe87fd(on drm-next) and 210561ffd72d00eccf12c0131b8024d5436bae95(on drm-intel-fixes) Both of the parents git sha1 are good, but if I tested with the merged commit in drm-next which I listed below, this bug will come up. I guess it's the problem by merging. -------------------------- commit b81e059ec5a7128622ab5d74d78e9b4f361b54ae Merge: 35f8bad 210561f Author: Dave Airlie <airlied@redhat.com> Date: Wed Feb 20 11:40:49 2013 +1000 Merge branch 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel into drm-next So here's my promised pile of fixes for 3.9. I've dropped the core prep patches for vt-switchless suspend/resume as discussed on irc. Highlights: - Fix dmar on g4x. Not really gfx related, but I'm fed up with getting blamed for dmar crapouts. - Disable wc ptes updates on ilk when dmar is enabled (Chris). So again, dmar, but this time gfx related :( - Reduced range support for hsw, using the pipe CSC (Ville). - Fixup pll limits for gen3/4 (Patrick Jakobsson). The sdvo patch is already confirmed to fix 2 bug reports, so added cc: stable on that one. - Regression fix for 8bit fb console (Ville). - Preserve lane reversal bits on DDI/FDI ports (Damien). - Page flip vs. gpu hang fixes (Ville). Unfortuntely not quite all of them, need to decide what to do with the currently still in-flight ones. - Panel fitter regression fix from Mika Kuoppala (was accidentally left on on some pipes with the new modset code since 3.7). This also improves the modeset sequence and might help a few other unrelated issues with lvds. - Write backlight regs even harder ... another installement in our eternal fight against the BIOS and backlights. - Fixup lid notifier vs. suspend/resume races (Zhang Rui). Prep work for new ACPI stuff, but closing the race itself seems worthwile on its own. - A few other small fixes and tiny cleanups all over.
Is this still an issue on latest dinq?
(In reply to comment #8) > Is this still an issue on latest dinq? I have retested latest dinq, and there's not this issue, I listed the information of the kernel which I tested below: ----------------------------------------- Kernel: (drm-intel-next-queued)99fb11e2d60385a2e10f063afd4cbb06032ef92a Some additional commit info: Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Apr 4 22:20:34 2013 +0200 drm/i915: set CB tuning also for the reduce clock
Thanks for retesting, I'm closing this as resolved now.
Closing old verified.
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.