Summary: | [bisected drm-intel-fixes regression] fail to initialise eDP on e6510 | ||||||
---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | wang,jinjin <jinjin.wang> | ||||
Component: | DRM/Intel | Assignee: | Jesse Barnes <jbarnes> | ||||
Status: | CLOSED FIXED | QA Contact: | |||||
Severity: | blocker | ||||||
Priority: | high | CC: | chris, jan, jbarnes, matt, zhenyu.z.wang | ||||
Version: | unspecified | ||||||
Hardware: | All | ||||||
OS: | Linux (All) | ||||||
Whiteboard: | |||||||
i915 platform: | i915 features: | ||||||
Attachments: |
|
Description
wang,jinjin
2010-10-28 01:41:25 UTC
Created attachment 39838 [details]
dmesg.log
some informantion: It was just black-screen when kernel boots.The system had no hang. test manchine are: Calpella with eDP [e6510], LVDS[t410] good commit info: Kernel: (drm-intel-fixes)6939a5aca7cfada279a24c307e772f33104fca20 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Oct 8 13:40:27 2010 +0100 drm/i915: Prevent module unload to avoid random memory corruption Let me just clarify: We failed to initialise the eDP on the e6510. Bug 29278? (In reply to comment #3) > Let me just clarify: > > We failed to initialise the eDP on the e6510. Bug 29278? probably not bug 29278, because our e6510 worked with -fixes just few days ago (see the commit in comment#2). Jinjin is trying bisecting. I bisected the first bad commit manually was : commit 01cb9ea633ddf3e8770dfe7851e88610087098bc Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Oct 7 16:01:12 2010 -0700 drm/i915/dp: eDP power sequencing fixes Enable the panel before adjusting eDP link params, make sure the panel is idle after powering it on before proceeding with other activity, delay backlight enable to avoid visible flicker. Also avoid using VDD per hw team recommendation; it can conflict with the builtin panel power sequencing logic and lead to panel power sequencing failures. its parent commit 5c5313c8db9bfb549e080fc4cb0a4c3c2aa7a73d had no the issue Jesse, any ideas? I'm promoting it as it blocks QA's nightly testing. (e6510 is our main test machine for i965 now) So if you revert 01cb9ea633ddf3e8770dfe7851e88610087098bc does the panel come up again? Maybe I should ask for another 6510; I sent back the old Dell machine I had but it was working ok... I git checkout to 01cb9ea633ddf3e8770dfe7851e88610087098bc and git revert it. With the new commit generated by git reverting, the issue did not happen. Do we have any other eDP machines available so that we can assess the impact from reverting this commit for 2.6.36? No, this is the only eDP machine owned by QA. Zhenyu, do you have any Calpella laptops with eDP? Jesse, do you still have the Vaio which I presume prompted this series of patches? Does that still work with this patch reverted? As this is our test platform, I think I'm going to revert it anyway and deal with the fallout later. I've pushed a reversion of 01cb9ea63 to drm-intel-staging. Can you please test that to see if it fixes this bug without introducing any other artifacts? Jesse can you sanity check that revert as well? commit ad078faf838c0dea90c2950c23cb6c3581d96197 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Nov 12 11:29:53 2010 +0000 Revert "drm/i915/dp: eDP power sequencing fixes" This reverts commit 01cb9ea633ddf3e8770dfe7851e88610087098bc. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31188 Reported-by: Wang Jinjin <jinjin.wang@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Damn, reverting that breaks my VAIO with a PCH attached eDP. I should be getting a 1920x1080 6510 soon, hopefully I can find something that will fix both machines. (In reply to comment #13) > Damn, reverting that breaks my VAIO with a PCH attached eDP. > > I should be getting a 1920x1080 6510 soon, hopefully I can find something that > will fix both machines. It breaks my VAIO too: VPCZ11C5E (1600x900, Core i5) As harsh as this sounds, but I must prioritise getting our regression testing up and running. Gordon, Jinjin any news on testing the revert on -staging? (In reply to comment #15) > As harsh as this sounds, but I must prioritise getting our regression testing > up and running. Gordon, Jinjin any news on testing the revert on -staging? I tested with the commit ad078faf838c0dea90c2950c23cb6c3581d96197 on drm-intel-staging branch, but it still boot up with black screen. :( Eek, I guess that was too much to hope for. Jesse, do you want to take a stab at finding a safe revert? Or propose an alternative? I'm a little confused about why the revert worked at first but now doesn't. I'll check on the 6510 I have coming, I don't really have any ideas at this point. (In reply to comment #18) > I'm a little confused about why the revert worked at first but now doesn't. > I'll check on the 6510 I have coming, I don't really have any ideas at this > point. We firstly find out it was caused by 01cb9ea633ddf3e8770dfe7851e88610087098bc, and if we revert it, it worked well. But if we want to revert this commit in the newer commit of drm-intel-fixes branch, it failed and have some conflict. Then we tested with Chris's drm-intel-staging branch, on which Chris make approximately a revert of that commit(but not exactly that commit's revert because of some function change or its arguments change) as commit ad078faf838c0dea90c2950c23cb6c3581d96197, but it failed. So I guess maybe it relates to some modification of code. Hope can help you. Dave Airlie bisected one failure on his HP 2540 to commit 869184a. I pushed the revert to drm-intel-staging. Can you please test to see if this also fixes this failure? (In reply to comment #20) > Dave Airlie bisected one failure on his HP 2540 to commit 869184a. I pushed the > revert to drm-intel-staging. Can you please test to see if this also fixes this > failure? That revert makes my display go blank after loading the Intel driver (VPCZ11C5E), a different fix would be appreciated. :-) (In reply to comment #20) > Dave Airlie bisected one failure on his HP 2540 to commit 869184a. I pushed the > revert to drm-intel-staging. Can you please test to see if this also fixes this > failure? It works well on our e6510 with the newest commit on -staging branch. Kernel: (drm-intel-staging)9311afae4a5841a7ba8ce91eb5ee8ef9e3bc0179 Thanks Zhao, I've pushed Dave's revert to drm-intel-fixes and shall close this on the presumption that our QA machine continues to work. ;-) verified with newest commit on -fixes branch. Kernel: (drm-intel-fixes)3cf2efb1a7c68d55d60dcb2ed9609e1a2fc25952 (In reply to comment #13) > Damn, reverting that breaks my VAIO with a PCH attached eDP. > > I should be getting a 1920x1080 6510 soon, hopefully I can find something that > will fix both machines. Well, I can confirm that with that commit my VAIO does not work either - back to black screen again ... :-( Any plans to fix that before release of linux-2.6.37? Is there a related bug entry to track that issue? (In reply to comment #25) > Any plans to fix that before release of linux-2.6.37? Is there a related bug > entry to track that issue? At this stage that looks unlikely. It is really is the choice of the lesser two evils. :( Hopefully all the machines have arrived and Jesse will find time to investigate when he's back from holiday soon. I'm using bug 31988 to track the status on the reverted patch. 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.