I'm using git tip sources for intel-drm, (lib)drm and xf86-video-intel. Everything seems to work but my display is black (backlight is on). xrandr output: # DISPLAY=:0.0 xrandr Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 VGA1 disconnected (normal left inverted right x axis y axis) DP1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 194mm 1920x1080 60.0*+ 40.0 HDMI1 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) HDMI3 disconnected (normal left inverted right x axis y axis) DP3 disconnected (normal left inverted right x axis y axis) DP4 disconnected (normal left inverted right x axis y axis) I can disable the backlight using xrandr --output DP1 --off
Created attachment 35578 [details] Xorg.0.log
Created attachment 35579 [details] intel_reg_dump
Created attachment 35580 [details] dmesg
From the info in comment #2 it seems that the eDP port is not enable. Not sure why it is not enabled. Will you please add the boot option of "drm.debug=0x04" and attach the output of dmesg? (Had better compile the i915 as built-in kernel module). It will be great if you can also try it on 2.6.33 kernel and see whether the issue also exists. Please also attach the output of dmesg, intel_reg_dumper on 2.6.33 kernel. Please attach the vbios.dump on this box, which can be obtained by using the following command: 1. echo 1 > /sys/devices/pci0000:00/0000:00:02.0/rom 2. cat /sys/devices/pci0000:00/0000:00:02.0/rom >vbios.dump 3. echo 0 > /sys/devices/pci0000:00/0000:00:02.0/rom Please also attach the output of "xrandr -q --verbose" on this box. Thanks.
Created attachment 35584 [details] dmesg-drm.debug=0x04
Created attachment 35585 [details] vbios
Created attachment 35586 [details] xrandr-verbose
Created attachment 35587 [details] dmesg-2.6.33
Created attachment 35588 [details] intel_reg_dump-2.6.33 The problem persists using this kernel (2.6.33)
Hi, Zhenyu any idea about this issue on eDP panel? thanks.
I haven't tried current driver for eDP recently. Could you try drm-intel-next to see how's going?
Please help to test ajax's patch at http://lists.freedesktop.org/archives/intel-gfx/2010-May/006847.html
(In reply to comment #11) > I haven't tried current driver for eDP recently. Could you try drm-intel-next > to see how's going? drm-intel-next is probably broken on Ironlake now: bug#28046 Dick, is this regression on this machine?
(In reply to comment #13) > (In reply to comment #11) > > I haven't tried current driver for eDP recently. Could you try drm-intel-next > > to see how's going? > > drm-intel-next is probably broken on Ironlake now: bug#28046 > > Dick, is this regression on this machine? I've first tried drm-intel-next and later "vanilla" 2.6.33 they both aren't working.
Created attachment 35625 [details] dmesg-ajax I've tried the patch from ajax (using intel-drm-next sources) but it still doesn't give any output.
I'm using drm-intel-next on Ironlake but I don't have the errors like bug#28046. My output is still black.
Can you please also attach intel_reg_dump output from booting with nomodeset?
Created attachment 35629 [details] intel_reg_dump_nomodeset
From mailing list: > We just have one 1366x768 panel which works fine for me last time I tried, > but that [this] bug has a larger one, and from log it seems driver still > use 1.6Ghz which may lead to the problem as you addressed. Ick. His VBT reports 1.62GHz x1, which is definitely not going to hold a 1920x1080 mode. Guess we'll have to do this the hard way. I really like to know what the "hard way" is :)
Ajax told me yesterday he is a little bit behind because he broke his arm. Best wishes for a speedy recovery!
Created attachment 35782 [details] [review] [Patch 1/2]: set the DP sync polarity according to the desired mode
Created attachment 35783 [details] [review] [Patch 2/2]: try the max link rate
Hi, Dick Will you please try the two debug patches in comment #21/22 on the 2.6.33 kernel and see whether it is helpful? Please add the boot option of "drm.debug=0x04" and attach the output of dmesg. Please also attach the output of intel_reg_dumper. Thanks. Yakui
Created attachment 35789 [details] dmesg-ykzhao Thanks! It works
Created attachment 35790 [details] intel_reg_dump_ykzhao
Yakui, some comment for your patch. We already have the first one from ajax. For second one, maybe we can try to convert the loop with for (clock = max_clock; clock >= 0; clock--) {..} instead of always using max_clock. I'm not sure about if power consumption will be higher with high clock? And hopefully we don't have regression on some eDP panels?
(In reply to comment #24) > Created an attachment (id=35789) [details] > dmesg-ykzhao > > Thanks! It works Thanks for the testing. It is good news that the eDP can work after applying the two debugs patches in comment #21/22. The next step is to identify which patch is required to solve the issue. Hi, Dick Can you try the debug patch in comment #21/22 one by one and see whether the issue can be resolved? thanks. Yakui
It still works when I only apply the first patch (from comment #21, 0001-set-the-DP-sync-polarity-according-to-the-desired-mo.patch). Do you want me to try the second patch (without the first)?
(In reply to comment #26) > instead of always using max_clock. I'm not sure about if power consumption will > be higher with high clock? And hopefully we don't have regression on some eDP > panels? Power consumption will always be higher at higher frequencies. And some panels may only go so fast. So using the maximum clock frequency, if that is what you are doing, is probably not a great idea, if lower options are available. Most built-in panels go at 60hz, FWIW.
(In reply to comment #28) > It still works when I only apply the first patch (from comment #21, > 0001-set-the-DP-sync-polarity-according-to-the-desired-mo.patch). Do you want > me to try the second patch (without the first)? It is good news that it still can work only when the first patch in comment #21 is applied. Can you also try the second patch(without the first) and see whether it is helpful? Thanks.
(In reply to comment #29) > (In reply to comment #26) > > instead of always using max_clock. I'm not sure about if power consumption will > > be higher with high clock? And hopefully we don't have regression on some eDP > > panels? > > Power consumption will always be higher at higher frequencies. And some panels > may only go so fast. So using the maximum clock frequency, if that is what you > are doing, is probably not a great idea, if lower options are available. Most > built-in panels go at 60hz, FWIW. What I am doing only affects the link rate of display port. It has no effect on the clock for eDP panel. I agree with your concern. The power consumption will be higher when using the high link rate for display port. I look at the bios code and it seems that the BIOS code uses the high link rate to calculate the link setting for the eDP. Maybe it is safe, which can assure that the system has the correct the link setting. On the Dick's laptop: before applying the patches in comment #21/22, lane count is 2, and low link rate(1.62G) is used. The active pixel rate occupies nearly 96% bandwidth of the link. (137.7 * 18 / 8) / (162 * 2) = 95.6% Let's wait for the Dick's test result and see whether the high link rate is helpful to solve the issue. thanks.
I've tried the second patch - try the max link rate (without the first) and I still have output. So both patches seem to work combined or seperate. Please let me know when I need to do some other testing.
(In reply to comment #32) > I've tried the second patch - try the max link rate (without the first) and I > still have output. So both patches seem to work combined or seperate. > > Please let me know when I need to do some other testing. Hi, Dick Thank you for the nice testing. It seems that the both two patches in comment #21/22 can solve the issue. In fact the patch similar to that in comment #21 is already pushed by Ajax and in drm-intel-next tree. >commit 9c9e792795f96d201d85188607261f9f8bbf3219 Author: Adam Jackson <ajax@redhat.com> Date: Mon Apr 5 17:57:59 2010 -0400 drm/i915: Set sync polarity correctly on DisplayPort Will you please test the drm-intel-next tree again and see whether the issue still exists? thanks.
(In reply to comment #28) > It still works when I only apply the first patch (from comment #21, > 0001-set-the-DP-sync-polarity-according-to-the-desired-mo.patch). Do you want > me to try the second patch (without the first)? Will you please also attach the output of dmesg, intel_reg_dumper only when the patch in comment #21 is applied on 2.6.33 kernel?(The boot option of "drm.debug=0x04" should be added). thanks.
(In reply to comment #33) > Will you please test the drm-intel-next tree again and see whether the > issue still exists? I've just tried drm-intel-next and it doesn't give any output on my eDP. (So my issue still exist using this kernel)
Created attachment 35958 [details] dmesg-2.6.33-set-the-DP-sync-polarity-according-to-the-desired-mode
Created attachment 35959 [details] intel_reg_dump-2.6.33-set-the-DP-sync-polarity-according-to-the-desired-mode
(In reply to comment #37) > Created an attachment (id=35959) [details] > intel_reg_dump-2.6.33-set-the-DP-sync-polarity-according-to-the-desired-mode Hi, Dick From the register dump in comment #37 it seems that the eDP port is not enabled. >PCH_eDP_A: 0x300c001c Will you please double check whether the system can work well only when the patch in comment #21 is applied on 2.6.33 kernel? Thanks.
Created attachment 35974 [details] intel_reg_dump-2.6.33-set-the-DP-sync-polarity-according-to-the-desired-mode whoops, I guess gnome disabled the eDP when I logged in. I hope this dump is better.
(In reply to comment #39) > Created an attachment (id=35974) [details] > intel_reg_dump-2.6.33-set-the-DP-sync-polarity-according-to-the-desired-mode > > whoops, I guess gnome disabled the eDP when I logged in. > I hope this dump is better. thanks for the confirmation. From the log it seems that the issue can be resolved when the patch in comment #21 is applied on the 2.6.33 kernel. And the similar patch is already shipped in drm-intel-next tree as mentioned in comment #33. But it is very strange that the issue still exists when using drm-intel-next tree. Maybe the issue is affected by something else in drm-intel-next tree. the next step is to track which commit affects this issue. >
(In reply to comment #40) > thanks for the confirmation. > From the log it seems that the issue can be resolved when the patch in comment > #21 is applied on the 2.6.33 kernel. And the similar patch is already shipped > in drm-intel-next tree as mentioned in comment #33. > But it is very strange that the issue still exists when using > drm-intel-next tree. Maybe the issue is affected by something else in > drm-intel-next tree. the next step is to track which commit affects this issue. > Any progress figuring out why drm-intel-next is having trouble? - Jim
There is a new patch on the intel-gfx mailing list today that may fix this. http://lists.freedesktop.org/archives/intel-gfx/2010-June/007216.html
http://lists.freedesktop.org/archives/intel-gfx/2010-June/007216.html please try this patch.
lols some ppl are faster than me ;-)
Geir Ove Myhr, Dave Airlie thanks for pointing me to this patch. This fixes drm-intel-next for me! Please commit.
new patch http://lists.freedesktop.org/archives/intel-gfx/2010-June/007232.html please test.
(In reply to comment #46) > new patch > > http://lists.freedesktop.org/archives/intel-gfx/2010-June/007232.html > > please test. I registered an account just to say: This patch, applied to a kernel pulled today from kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git, makes my Dell Latitude E6510 (with Intel HD graphics, not the Nvidia option) work for the first time with mode setting. Thanks!
*** Bug 28224 has been marked as a duplicate of this bug. ***
*** Bug 28746 has been marked as a duplicate of this bug. ***
(In reply to comment #47) > (In reply to comment #46) > > new patch > > > > http://lists.freedesktop.org/archives/intel-gfx/2010-June/007232.html > > > > please test. > > I registered an account just to say: > This patch, applied to a kernel pulled today from > kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel.git, makes my Dell > Latitude E6510 (with Intel HD graphics, not the Nvidia option) work for the > first time with mode setting. Thanks! Hi I tried this, against a debian 2.6.34-1 experimental.2 build, works as well, but if I start X with an external monitor attached the machine hangs.... I can attach after X has started. So (with i915 blacklisted) 1.a boot 1.b modprobe i915 modeset=1 1.c startx 1.d attached ext display 1.e xrandr add second display works 2.a boot 2.b modprobe i915 modeset=1 2.c attach ext monitor 2.d startx dead have to hold the power button for a while Alex
Created attachment 36650 [details] portions of the syslog that show the crash to the system This is the section of the syslog, that shows the crash when I try and start X with 2 screens (edp and external). This is on a HP 2540p Alex
Hi, I add CC the people which CC in others bigs that are marked as duplicated , I hope that don't miss any ... 2nd, I am testing kernel 2.6.33.5-137.fc13.x86_64 from http://koji.fedoraproject.org/koji/packageinfo?packageID=8 , which have the latest patch of airlied mention on this report. which works ...
(In reply to comment #46) > new patch > > http://lists.freedesktop.org/archives/intel-gfx/2010-June/007232.html > > please test. I tested this patch against mainline 2.6.34 and can report that this combination works on my Dell Latitude E6510. (Which is good because I can avoid bleeding-edge problems in drm-intel-next like the udevd 100% bug.)
Done some more testing with suspending/hibernating and the patched driver. the edp doesn't come back on, I have to attach a second screen, restart gdm/X and then use xrandr to restart the eDP. So its nearly there, if only I could do this from the command line with one of the fb* tools. Thanks
FWIW, a build of (In reply to comment #53) > (In reply to comment #46) > > new patch > > > > http://lists.freedesktop.org/archives/intel-gfx/2010-June/007232.html > > > > please test. > > I tested this patch against mainline 2.6.34 and can report that this > combination works on my Dell Latitude E6510. (Which is good because I can > avoid bleeding-edge problems in drm-intel-next like the udevd 100% bug.) FWIW, this patch also works with the E6410, when applied against a clean 2.6.34 kernel. drm-intel-next, and 2.6.35 both seem to be problematic. Thanks for chasing this down!
Hi There is a still an issue with 2 monitors being attached when starting up #51 and attachment. Or do I need to start a new bug report ?
Yes, please.
If you create a new bug report to deal with the problem with two monitors, please leave a message here with the new bug number.
(In reply to comment #54) > Done some more testing with suspending/hibernating and the patched driver. > > the edp doesn't come back on, I have to attach a second screen, restart gdm/X > and then use xrandr to restart the eDP. > > So its nearly there, if only I could do this from the command line with one of > the fb* tools. > > Thanks see bug #28739, and comment there please, about suspending/hibernating problems .
(In reply to comment #58) > If you create a new bug report to deal with the problem with two monitors, > please leave a message here with the new bug number. done https://bugs.freedesktop.org/show_bug.cgi?id=28911
the exact same issue still persists with kernel 2.6.35-rc6+ (containing the latest commits up to 14h ago) even though the (supposedly) fixing patch is already included there. this is on a dell E6510 can anybody confirm?
josh, please do not hijack bug reports. This one was clearly identified and fixed, so if you are seeing a very similar bug on different hardware, you have a different bug and need to file a separate bug report.
(In reply to comment #61) > the exact same issue still persists with kernel 2.6.35-rc6+ (containing the > latest commits up to 14h ago) even though the (supposedly) fixing patch is > already included there. > this is on a dell E6510 > can anybody confirm? To simplify , jost try fedora 13 updated with kernel , http://admin.fedoraproject.org/updates/kernel-2.6.33.6-147.2.4.fc13 as you can see the patch can be applied to kernel 2.6.33/4 , you may have lots of thing not updated
(In reply to comment #61) Josch is right, I've tried drm-intel git sources (2.6.36-rc2+) and I lost my working eDP. I've noticed not all (none?) of the patches referred in this bug report are committed to drm-intel. I was using the drm patch from fedora but since an update of my kernel that doesn't work anymore either.
(In reply to comment #54) > Done some more testing with suspending/hibernating and the patched driver. > > the edp doesn't come back on, I have to attach a second screen, restart gdm/X > and then use xrandr to restart the eDP. > > So its nearly there, if only I could do this from the command line with one of > the fb* tools. > > Thanks The original bug has been fixed, so I am closing this report so that we can't focus on the remaining issues in separate bug reports. There have been many more eDP fixes in git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git drm-intel-next so please bare those in mind when opening new bugs.
So should we concentrate on https://bugs.freedesktop.org/show_bug.cgi?id=29278 ? I can confirm that as of the 21/11/2010 that drm-intel and drm-intel-next based of the 2.6.37rc2 merges fail with an HP elitebook 2740p (Samsung touch eDP). So I don't think anyone can say this is fixed upstream.
(In reply to comment #66) > So should we concentrate on https://bugs.freedesktop.org/show_bug.cgi?id=29278 > ? > > I can confirm that as of the 21/11/2010 that drm-intel and drm-intel-next based > of the 2.6.37rc2 merges fail with an HP elitebook 2740p (Samsung touch eDP). > > So I don't think anyone can say this is fixed upstream. Fedora kernel works very well on dell latitude E6410,
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.