|
Description
josch
2010-07-28 07:16:09 UTC
Created attachment 37420 [details]
intel_reg_dumper - working
According to these 6410 works now: http://launchpad.net/bugs/578673 http://launchpad.net/bugs/561802 Also see Manoj's mail to the stable team: Please consider the following upstream commits to stable 2.6.33.y 1. drm/i915: add PANEL_UNLOCK_REGS definition SHAID: 4a655f043160eeae447efd3be297b6b4c397a640 2. drm/i915: make sure eDP panel is turned on SHAID: 9934c132989d5c488d2e15188220ce240960ce96 Depends on 3. drm/i915: Rename intel_output to intel_encoder. SHAID: 21d40d37eca86872f2bf0af995809ebdef25c9d9 These patches fix video issues on Dell Latitude E6410. Reported in bugs http://launchpad.net/bugs/578673 http://launchpad.net/bugs/561802 The patches apply cleanly to 2.6.33.y (see attachments), and they were tested against the latest Lucid kernel and reported to fix the 2 issues. Kernel was tested by user community, as well as, on hardware available at Canonical. Regarding the issue with dim back-light on resume, Jesse wrote to me saying he suspects some other agent like firmware might be a suspect in zeroing it out before the driver saves it, ie driver seems to do the right thing. Do you have all the patches mentioned above? yes, all of these patches are already upstream: root@hoothoot:/home/linux-git# git log | grep -m1 -C1 4a655f043160eeae447efd3be297b6b4c397a640 commit 4a655f043160eeae447efd3be297b6b4c397a640 Author: Jesse Barnes <jbarnes@virtuousgeek.org> root@hoothoot:/home/linux-git# git log | grep -m1 -C1 9934c132989d5c488d2e15188220ce240960ce96 commit 9934c132989d5c488d2e15188220ce240960ce96 Author: Jesse Barnes <jbarnes@virtuousgeek.org> root@hoothoot:/home/linux-git# git log | grep -m1 -C1 21d40d37eca86872f2bf0af995809ebdef25c9d9 commit 21d40d37eca86872f2bf0af995809ebdef25c9d9 Author: Eric Anholt <eric@anholt.net> what else do you need? now that 2.6.35 was released i tested again. still getting a black screen as if the bugs mentioned above were not fixed even though 2.6.35 contains all the patches that were reported as fixing the problem(s). The bug was fixed in 2.6.35-rc6, but reintroduced in 2.6.35 final by this patch:
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5d42661..5dde80f 100644 (file)
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -798,7 +798,7 @@ intel_dp_dpms(struct drm_encoder *encoder, int mode)
intel_dp_link_down(intel_encoder, dp_priv->DP);
if (IS_eDP(intel_encoder)) {
ironlake_edp_backlight_off(dev);
- ironlake_edp_backlight_off(dev);
+ ironlake_edp_panel_off(dev);
}
}
} else {
so it looks like 'ironlake_edp_panel_off(dev)' breaks some stuff.
thanks henk, you are right! i undid what that patch did and rebooted and there it worked! of course suspend does neither work in that state (even though that was also supposed to be fixed on that hardware) but that will be the topic of another bugreport after this one is taken care of. so what is a real fix for that problem now? Still working with the hw guys on this. Moving the panel_on call above the dp link train call also works around this issue (and has the benefit of allowing the panel to fully turn off). Created attachment 37794 [details] [review] edp mode set fix Does this patch help? I'm still trying to figure out where our eDP mode setting is wrong, but this was able to get the display up somewhat reliably for me. Created attachment 37795 [details] intel_dp.c downloaded 11 aug and patched I have a vaio VPCZ1, but I was experimenting two issues: 1) the issue of this bug (of course) and, 2) the issue of that bug: https://bugs.freedesktop.org/show_bug.cgi?id=28911 I am trying with the latest drm-intel-next head. (Aug 11) Jeese, I have used your patch, but I applied it manually to the very last version of intel_dp.c, since my originial intel_dp.c seems to be changed recently in the git (my version is drm-intel-next downloaded on Aug 11). My manually patched file is also attached. Behavior before patch: - black screen on laptop screen (boots in background). - total freeze if an external monitor is attached before boot. After boot, I can attach it, and work with it. Behavior after patch: - black screen on laptop screen (boots in background) - Can boot with external monitor attached!! (seems to fix the other bug!) (In reply to comment #8) > Created an attachment (id=37794) [details] > edp mode set fix > > Does this patch help? I'm still trying to figure out where our eDP mode > setting is wrong, but this was able to get the display up somewhat reliably for > me. This patch (applied on top of 2.6.34.3) resolves the problem for me on a Dell e6410. (In reply to comment #10) > (In reply to comment #8) > > Created an attachment (id=37794) [details] [details] > > edp mode set fix > > > > Does this patch help? I'm still trying to figure out where our eDP mode > > setting is wrong, but this was able to get the display up somewhat reliably for > > me. > > This patch (applied on top of 2.6.34.3) resolves the problem for me on a Dell > e6410. Unfortunately, the patch only solves part of the problem. With the patch, I get text on the display panel on boot. After a resume, the panel is blank but backlit. What is the actual state of this bug ? I tried Ubuntu 9.04, current which information is missing ? i run ubuntu 10.10 unstable, last working kernel is 2.6.35-13 , all newer ones give black screen on boot. how can i see later in which kernel the problem is fixed ? jesse, thanks your patch fixed the issue of this bug. sorry for replying so late. now only suspend is not working but i will file a new bug for that. tried kernel 2.6.35.2, black screen when kernel is switching to KMS .. means waiting and hope that it is fixed in 2.6.36 or maybee 2.6.35.3 :) This looks like a timing issue. Adding a ssleep(1) to ironlake_edp_panel_on fixes the problem on my E6510:
..
pp |= PANEL_UNLOCK_REGS | POWER_TARGET_ON;
I915_WRITE(PCH_PP_CONTROL, pp);
if (wait_for(I915_READ(PCH_PP_STATUS) & PP_ON, 5000, 10))
DRM_ERROR("panel on wait timed out: 0x%08x\n",
I915_READ(PCH_PP_STATUS));
ssleep(1);
pp &= ~(PANEL_UNLOCK_REGS | EDP_FORCE_VDD);
pp |= PANEL_POWER_RESET; /* restore panel reset bit */
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
..
Created attachment 38110 [details] [review] fix edp detection at boot time Along with this patch, 2.6.36-rc2 works well on my E6510. Patch submitted upstream. The patch did not fix the problem on my Dell E6510 core i5 with bios rev. a04 Henk, you tried 2.6.36-rc2 plus the patch? Can you attach your dmesg with drm debug=4? I wonder if the panel on call is failing in your case. Created attachment 38127 [details]
dmesg of 2.6.26-rc2 with patch
This is the dmesg of today's git checkout of the Linux kernel with Jesse's patch applied.
Ok, so the eDP panel is being detected correctly (connected with a mode list) but the panel isn't coming on? Does it happen every time? echo 0 > /sys/class/vtconsole/vtcon1/bind rmmod i915 rmmod drm_kms_helper rmmod drm sync dmesg -n 8 modprobe drm #debug=4 modprobe i915 modeset=1 $@ sync echo 1 > /sys/class/vtconsole/vtcon1/bind if you run the above script does the display come on? Does it come on every other time? (You'll need Daniel's unload fixes for this to work reliably: http://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=drm-testing&ofs=50). Ok I've got one more thing for you to try, let me come up with a patch. I'm also affected by this issue (E6510, 32bit, i5 with integrated graphics). I can confirm that henk's workaround from comment 5 works. I have been very busy lately so I haven't had time to test other patches yet, but I will test the one in commment 17 and any newer ones as soon as I can. (In reply to comment #23) > Ok I've got one more thing for you to try, let me come up with a patch. Ok, can you try the edp-testing branch of my drm tree at git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel.git? It still works for me on E6510 but hopefully it'll work for you too this time. (In reply to comment #25) > Ok, can you try the edp-testing branch of my drm tree at > git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel.git? It still > works for me on E6510 but hopefully it'll work for you too this time. Unfortunately this branch didn't solve my problem either. Am I the only one who still has this problem with the latest patches? (In reply to comment #26) > Unfortunately this branch didn't solve my problem either. Am I the only one who > still has this problem with the latest patches? i use this package http://www.archlinux.org/packages/core/x86_64/kernel26/ . If anybody has a newer package i will test. nothing of this bugfix is in 2.6.35.4 , correct ? (this will come in next days as package) It (In reply to comment #26) > (In reply to comment #25) > > Ok, can you try the edp-testing branch of my drm tree at > > git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel.git? It still > > works for me on E6510 but hopefully it'll work for you too this time. > > Unfortunately this branch didn't solve my problem either. Am I the only one who > still has this problem with the latest patches? The edp-testing branch does not seem to work for me either. (dell E6510, i7, bios rev. A03) (In reply to comment #28) > It (In reply to comment #26) > > (In reply to comment #25) > > > Ok, can you try the edp-testing branch of my drm tree at > > > git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel.git? It still > > > works for me on E6510 but hopefully it'll work for you too this time. > > > > Unfortunately this branch didn't solve my problem either. Am I the only one who > > still has this problem with the latest patches? > > The edp-testing branch does not seem to work for me either. (dell E6510, i7, > bios rev. A03) Just tried vanilla 2.6.36-rc3 - it goes black immediately (presumably after modesetting), but X is displayed correctly when started, but console is still black if I switch to it afterwards... (In reply to comment #29) > (In reply to comment #28) > > It (In reply to comment #26) > > > (In reply to comment #25) > > > > Ok, can you try the edp-testing branch of my drm tree at > > > > git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel.git? It still > > > > works for me on E6510 but hopefully it'll work for you too this time. > > > > > > Unfortunately this branch didn't solve my problem either. Am I the only one who > > > still has this problem with the latest patches? > > > > The edp-testing branch does not seem to work for me either. (dell E6510, i7, > > bios rev. A03) > > Just tried vanilla 2.6.36-rc3 - it goes black immediately (presumably after > modesetting), but X is displayed correctly when started, but console is still > black if I switch to it afterwards... @Marek you are in the wrong bugreport. Core i7 on Latitude has no Arrandale Graphic, it has NVidia. (In reply to comment #30) > (In reply to comment #29) > > (In reply to comment #28) > > > It (In reply to comment #26) > > > > (In reply to comment #25) > > > > > Ok, can you try the edp-testing branch of my drm tree at > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel.git? It still > > > > > works for me on E6510 but hopefully it'll work for you too this time. > > > > > > > > Unfortunately this branch didn't solve my problem either. Am I the only one who > > > > still has this problem with the latest patches? > > > > > > The edp-testing branch does not seem to work for me either. (dell E6510, i7, > > > bios rev. A03) > > > > Just tried vanilla 2.6.36-rc3 - it goes black immediately (presumably after > > modesetting), but X is displayed correctly when started, but console is still > > black if I switch to it afterwards... > > @Marek you are in the wrong bugreport. Core i7 on Latitude has no Arrandale > Graphic, it has NVidia. Dell also sells an option with i7 CPU M 620 with arrandale, which is what I have... [marcho@dora ~]$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 37 model name : Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz stepping : 2 cpu MHz : 1199.000 cache size : 4096 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm ida arat tpr_shadow vnmi flexpriority ept vpid bogomips : 5320.10 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 37 model name : Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz stepping : 2 cpu MHz : 1199.000 cache size : 4096 KB physical id : 0 siblings : 4 core id : 2 cpu cores : 2 apicid : 4 initial apicid : 4 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm ida arat tpr_shadow vnmi flexpriority ept vpid bogomips : 5319.71 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 2 vendor_id : GenuineIntel cpu family : 6 model : 37 model name : Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz stepping : 2 cpu MHz : 2667.000 cache size : 4096 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm ida arat tpr_shadow vnmi flexpriority ept vpid bogomips : 5319.71 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 3 vendor_id : GenuineIntel cpu family : 6 model : 37 model name : Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz stepping : 2 cpu MHz : 1199.000 cache size : 4096 KB physical id : 0 siblings : 4 core id : 2 cpu cores : 2 apicid : 5 initial apicid : 5 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm ida arat tpr_shadow vnmi flexpriority ept vpid bogomips : 5319.71 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: [marcho@dora ~]$ lspci 00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 02) 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) 00:16.0 Communication controller: Intel Corporation 5 Series/3400 Series Chipset HECI Controller (rev 06) 00:16.3 Serial controller: Intel Corporation 5 Series/3400 Series Chipset KT Controller (rev 06) 00:19.0 Ethernet controller: Intel Corporation 82577LM Gigabit Network Connection (rev 05) 00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05) 00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 05) 00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 (rev 05) 00:1c.1 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 2 (rev 05) 00:1c.2 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 3 (rev 05) 00:1c.3 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 4 (rev 05) 00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev a5) 00:1f.0 ISA bridge: Intel Corporation Mobile 5 Series Chipset LPC Interface Controller (rev 05) 00:1f.2 RAID bus controller: Intel Corporation Mobile 82801 SATA RAID Controller (rev 05) 00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 05) 00:1f.6 Signal processing controller: Intel Corporation 5 Series/3400 Series Chipset Thermal Subsystem (rev 05) 02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6200 (rev 35) 03:00.0 CardBus bridge: Ricoh Co Ltd Device e476 (rev 02) 03:00.1 SD Host controller: Ricoh Co Ltd Device e822 (rev 03) 03:00.4 FireWire (IEEE 1394): Ricoh Co Ltd Device e832 (rev 03) 3f:00.0 Host bridge: Intel Corporation Core Processor QuickPath Architecture Generic Non-core Registers (rev 02) 3f:00.1 Host bridge: Intel Corporation Core Processor QuickPath Architecture System Address Decoder (rev 02) 3f:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 02) 3f:02.1 Host bridge: Intel Corporation Core Processor QPI Physical 0 (rev 02) 3f:02.2 Host bridge: Intel Corporation Core Processor Reserved (rev 02) 3f:02.3 Host bridge: Intel Corporation Core Processor Reserved (rev 02) (In reply to comment #29) > (In reply to comment #28) > > It (In reply to comment #26) > > > (In reply to comment #25) > > > > Ok, can you try the edp-testing branch of my drm tree at > > > > git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel.git? It still > > > > works for me on E6510 but hopefully it'll work for you too this time. > > > > > > Unfortunately this branch didn't solve my problem either. Am I the only one who > > > still has this problem with the latest patches? > > > > The edp-testing branch does not seem to work for me either. (dell E6510, i7, > > bios rev. A03) > > Just tried vanilla 2.6.36-rc3 - it goes black immediately (presumably after > modesetting), but X is displayed correctly when started, but console is still > black if I switch to it afterwards... I can confirm this behaviour. But my X is displayed correctly only after I switch to the console and back. The console still stays black though. On my Dell E6510 (i5 Arrandale, A3 BIOS), 2.6.36-rc3+38110 is considerably worse than 2.6.35.1+retry_count+ironlake_edp_panel_on. (Without patches I get no video at all.) On 2.6.35.1, the only problems are: (1) after suspend/resume, I have to plug in a monitor to get video on the panel, and (2) it panics when I run gnome-display-properties. On 2.6.36-rc3+38110, I generally have to plug in a monitor to get anything to happen, even after an inactivity timeout, and often not even then. Worse, it often panics, overheats, and shuts down after inactivity timeouts. (2.6.35.4+38110 also overheated.) Is there any information I can gather that would be helpful? I see that jesse's tree did not work for the other users, should I still compile and test it (checked it out using git one week ago) or is there a newer patch to try? I heard that the bug is still present in the beta for Maverick, the new Ubuntu release, and I'm hoping for a quick fix. Jesse, I just tried to compile your edp-testing branch, but it quit with the follwing errors: drivers/scsi/lpfc/lpfc_debugfs.c: In function ‘T.980’: drivers/scsi/lpfc/lpfc_debugfs.c:429: warning: the frame size of 1048 bytes is larger than 1024 bytes drivers/scsi/mpt2sas/mpt2sas_scsih.c: In function ‘_scsih_sas_control_complete’: drivers/scsi/mpt2sas/mpt2sas_scsih.c:2718: warning: unused variable ‘mpi_reply’ drivers/scsi/mpt2sas/mpt2sas_ctl.c:93: warning: ‘_ctl_sas_device_find_by_handle’ defined but not used drivers/scsi/sym53c8xx_2/sym_hipd.c: In function ‘sym_print_msg’: drivers/scsi/sym53c8xx_2/sym_hipd.c:78: warning: zero-length gnu_printf format string drivers/net/wan/cycx_x25.c: In function ‘hex_dump’: drivers/net/wan/cycx_x25.c:1030: warning: the frame size of 1040 bytes is larger than 1024 bytes (In reply to comment #34) > I see that jesse's tree did not work for the other users, should I still > compile and test it (checked it out using git one week ago) or is there a newer > patch to try? I heard that the bug is still present in the beta for Maverick, > the new Ubuntu release, and I'm hoping for a quick fix. Corona: Those are just warnings. that's what i thought, too, but the compilation process quit with error 2 and there weren't any other errors or warnings... (In reply to comment #36) > Corona: Those are just warnings. OK, never mind - it turned out that I had to disable a couple of modules that weren't compiling correctly. Jesse, I can confirm that the edp-testing branch of your git repo (fully up to date) does not work for my e6510 (core i5, intel integrated graphics, 32 bit kernel). I can see the backlight turn off and on, but the screen remains blank when I hear the gdm drums. Can you try the drm-intel-next branch at git://people.freedesktop.org/~ickle/drm-intel? It has all my edp fixes merged in along with a few others that might help. Ok the recent comments don't make sense to me... We should be testing the same bits. #2941 indicates that grub1 vs grub2 may be a factor, but I'm using grub2 and things work for me. I'll attach my config just in case that makes a difference. Created attachment 38527 [details]
kernel .config
Just copy this into your kernel tree as .config, then run 'make oldconfig' to use it. Then build and install as normal (don't forget to make an initrd in /boot and update grub though; the ubuntu /sbin/installkernel is still broken).
Created attachment 38538 [details] See comment #42 I built a pull from ~ickle/drm-intel, g8554048 on a Dell e6510 i5 arrandale with BIOS A3. Same as before: fb console shows only on an external monitor. On X, black screen, backlit. After a suspend/resume, plugging in an external monitor, I see screen background only on it; presumably the desktop is attempted on the main screen. After starting X, I cannot get back to an fb console (by ctrl-alt-f1) on either screen, but can SSH in. I am booting without an initrd. I attached the .config I used at #42. Strangely, after running a 2.6.36-derived kernel, the boot console sometimes remains blank after a power cycle; i.e it shows the Dell splash screen, but no boot menu; or, a boot menu, and initial boot log, but blank fb console, and probably an OOPS. This doesn't happen after running earlier kernels. If I wait ten minutes before turning power on again, fb console works OK again. Tried again with drm-intel-next and Jesse's .config from #41, but built for amd64. Same result. The X cursor does show up on the external monitor if I move it far enough to the right. Switching to fb console, the main panel backlight goes off, and the external monitor goes black but continues receiving a signal.
(I had to pause the build quite a few times to keep from overheating. I suppose that's Dell's fault. My .config builds much faster.)
What has worked better than anything else so far is a small patch applied to vanilla 2.6.35.1; first, in intel_crt.c:
+ u32 retry_count;
...
- while ((I915_READ(PCH_ADPA) & ADPA_CRT_HOTPLUG_FORCE_TRIGGER) != 0)
+ retry_count = 0;
+ while (((I915_READ(PCH_ADPA) & ADPA_CRT_HOTPLUG_FORCE_TRIGGER) != 0) && (retry_count++ < 10000))
;
and comment out the ironlake_edp_backlight_off and _panel_off around line 800 in intel_dp.c. (Remaining problems are that on suspend/resume I have to plug in an external monitor to get the panel to come back on, and it OOPSes if I run gnome-display-properties.)
OK, with recent drm-intel-next and the following trivial patch,
I get a 2.6.36-rc3 that works better than my patched 2.6.31.1.
That is, it boots and turns on the display, both fb console
and X, and turns it on again after an activity timeout blanking.
Furthermore, running gnome-display-properties no longer OOPSes.
After suspend/resume, I still have to plug in an external monitor
to get the main screen to come back on.
I have noticed that during long compiles (e.g. kernel build -j4),
the CPU gets 25-30K hotter with X running than when not. That is,
it reaches 75-80C without X, 100-105 with. When running under X
I have to pause the build periodically to keep it from overheating
and shutting down. Powertop indicates it turns off "Turbo mode"
above 100C, but that isn't always enough to keep it below 105C.
Is there a bug report open for this? Should I be surprised that
just keeping the screen on (with no activity) to produce this much
heat? I notice, too, that when I pause the build, the temperature
drops by 20K almost instantly, and jumps up again by 18K when
I restart the build. These sharp temperature changes seem odd.
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -861,7 +861,11 @@ static void intel_dp_prepare(struct drm_encoder *encoder)
uint32_t dp_reg = I915_READ(intel_dp->output_reg);
if (IS_eDP(intel_dp)) {
+#if 1
+ ironlake_edp_backlight_on(dev);
+#else
ironlake_edp_backlight_off(dev);
+#endif
ironlake_edp_panel_on(dev);
ironlake_edp_pll_on(encoder);
}
@@ -894,7 +898,9 @@ intel_dp_dpms(struct drm_encoder *encoder, int mode)
if (mode != DRM_MODE_DPMS_ON) {
if (IS_eDP(intel_dp) || IS_PCH_eDP(intel_dp)) {
ironlake_edp_backlight_off(dev);
+#if 0
ironlake_edp_panel_off(dev);
+#endif
}
if (dp_reg & DP_PORT_EN)
intel_dp_link_down(intel_dp);
Sorry, that was "better than my patched 2.6.35.1". only for information: Bios A05 1. Added Hyperthreading Enable/Disable Bios Setup Option. 2. Fixed booting to a CD using HDD emulation. 3. Fixed booting to the Dell Diag CD. 4. Fixed issue where the TouchPad sometimes does not work after hot docking. 5. Fixed intermittent issue with distorted audio and erratic mouse behavior. 6. Fixed issue where Bluetooth could be disabled after a reboot. 7. Fixed issue where an external monitor would not display when booting docked with the LCD Lid Closed. Bios A04 1. Fixed intermittent warm reboot hang issue. 2. Fixed BSOD during boot with 8GB of RAM and the latest Intel processors. Perhaps I spoke too soon. When I came in this morning, it was powered down. It must have OOPSed, overheated, and shut itself off. I had left it entirely quiescent. Just added a patch to 29141 that makes my E6510 behave a bit better, care to give it a try? With generic drm-intel-next g7839d95 and your patch 38588, behavior is same as before: no backlight on fb, backlight but no video on X. dmesg reports [drm] Cannot find any crtc or sizes - going 1024x768 [drm:ironlake_edp_panel_on] *ERROR* panel on wait timed out: 0x0000000a dell-wmi: Received unknown WMI event (0x11) Plugging in an external monitor and switching to fb console, I get text on the external monitor. Switching to vt7, I get a screen background and cursor (but not gnome panels) on the external monitor. Switching back to fb console, it's blank again. With my trivial patch above added, it's the same. dmesg reports, in both cases: intel ips 0000:00:1f.6: failed to get i915 symbols, graphics turbo disabled and drm: registered panic notifier acpi device:42: registered as cooling_device4 input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:02/input/input7 ACPI: Video Device [VID2] (multi-head: yes rom: no post: no) [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 alloc irq_desc for 22 on node -1 alloc kstat_irqs on node -1 After trying to switch back to fb console, I get: [drm:ironlake_crtc_dpms] *ERROR* failed to enable transcoder In both cases, starting with an external monitor plugged in, fb console displays on the external monitor only, and X startup cursor as well, but the external screen goes blank and loses signal before displaying a desktop, when the main panel backlight comes on. By the way, this is using Debian xserver-xorg-video-intel 2:2.9.1-4 There was another patch yesterday to disable self-refresh on ironlake, did you also have it applied for your testing? Nathan, your last log indicates that eDP isn't even being detected, while my E6510 works fine. I've been using git://people.freedesktop.org/~ickle/drm-intel with a few patches on top. Can you try the drm-ickle-next branch from git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel.git? (In reply to comment #49) > Just added a patch to 29141 that makes my E6510 behave a bit better, care to > give it a try? I have checked out git://people.freedesktop.org/~ickle/drm-intel about 24 hours ago, because you said it contained most of your changes. Here is how it works for me (latitude E6510, intel i5, integrated graphics, Full HD display): * On boot the panel is off, the backlight on. Switching to console, then back to graphic display turns panel on. But the consoles are always black; that is sometimes a problem if I want to switch to one of them to solve something. * Suspend/resume works with the acpi_sleep=s3_bios kernel option. Seems reliable. * If the panel is switched off (e.g., after closing the lid) I have to switch to console, then back to graphical display. * External monitors can be connected to the VGA port and they are detected (I tried two different models). I am using the "Monitors" graphical tool which comes with Ubuntu. However, if after using the external monitor / beamer I want to turn it off (in the same graphical tool) both the internal and the external displays are turned off. I found no way of switching the internal display again. If the external display is just unplugged, the internal display enters a flashing mode (black, grey unstable, black...) as if it were probing / trying to detect something. * I managed to compile VirtualBox from sources and make it work with this kernel (it was actually not difficult - just follow VirtualBox's instructions and tweak a small thing in the kernel configuration files to compile the vbox driver: it was complaining that the version of the sources and the installed kernel did not match. Best. (In reply to comment #53) > (In reply to comment #49) > > Just added a patch to 29141 that makes my E6510 behave a bit better, care to > > give it a try? > > I have checked out git://people.freedesktop.org/~ickle/drm-intel about 24 hours > ago, because you said it contained most of your changes. Here is how it works > for me (latitude E6510, intel i5, integrated graphics, Full HD display): > > * On boot the panel is off, the backlight on. Switching to console, then back > to graphic display turns panel on. But the consoles are always black; that is > sometimes a problem if I want to switch to one of them to solve something. Ok, that's something. > * Suspend/resume works with the acpi_sleep=s3_bios kernel option. Seems > reliable. Without the s3_bios option I'd expect suspend/resume to behave like boot, i.e. a blank screen for you. > * If the panel is switched off (e.g., after closing the lid) I have to switch > to console, then back to graphical display. > > * External monitors can be connected to the VGA port and they are detected (I > tried two different models). I am using the "Monitors" graphical tool which > comes with Ubuntu. However, if after using the external monitor / beamer I > want to turn it off (in the same graphical tool) both the internal and the > external displays are turned off. I found no way of switching the internal > display again. If the external display is just unplugged, the internal display > enters a flashing mode (black, grey unstable, black...) as if it were probing / > trying to detect something. Chris's tree should now have a fix for this bug. I should emphasize that with just drm-intel-next g7839d95, I don't get the [ironlake: complaints. That was a product of patch 38588. What is new in g7839d95 compared to my fairly functional 2.6.35.1+trivial kernel is quite reliable overnight overheating. This morning it had overheated but had not powered off. It smelled cooked. When I turned it off, it would not turn back on for quite a long time after. I had left X running, but had left it with the fb console displayed. I don't know if it's in i915 or elsewhere in the kernel. I don't see any recent patch in #29141 except your 38588. Pulling your drm-ickle-next branch will lead me to increased git-fu. (In reply to comment #54) > Chris's tree should now have a fix for this bug. Can you tell me its URL? Thanks! git tree is at git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git Nathan, I know it's a pain, but bisecting the overheating issue will help a lot. It could be turbo related; the CPU should throttle itself but if the GPU is running at the highest frequency all the time we have a problem. Created attachment 38750 [details]
intel_dp.c patch for kernel 2.6.36-rc4
This patch fixes the plymouth splash screen on my E6510. I still don't have a text-console though.
Created attachment 38805 [details]
intel_reg_dumper - nonworking, no X, no backlight
Running intel-drm-next 41a51428916ab04587bacee2dda61c4a0c4fc02f without further patches applied here.
- no backlight on boot
- X doesn't start
Output of intel_reg_dumper is attached.
BIOS is at A05.
(In reply to comment #59) > Created an attachment (id=38805) [details] > intel_reg_dumper - nonworking, no X, no backlight > > Running intel-drm-next 41a51428916ab04587bacee2dda61c4a0c4fc02f without further > patches applied here. Hmm, complete failure to detect the panel? Elias, can you attach a drm.debug=0xe dmesg? Created attachment 38810 [details] dmesg, drm.debug=0xe, no panel detected at all? (In reply to comment #60) > Hmm, complete failure to detect the panel? Elias, can you attach a > drm.debug=0xe dmesg? Attached a dmesg with drm.debug=0xe while having the laptop connected to the docking station. But I don't think the docking station is causing the problem, as it is exactly the same outside of the docking station. Created attachment 38828 [details] dmesg, drm.debug=0xe, KMS + X working, ironlake_edp_panel_off() disabled (In reply to comment #61) > Created an attachment (id=38810) [details] > dmesg, drm.debug=0xe, no panel detected at all? > > (In reply to comment #60) > > Hmm, complete failure to detect the panel? Elias, can you attach a > > drm.debug=0xe dmesg? By adding an early return in ironlake_edp_panel_off() in drivers/gpu/drm/i915/intel_dp.c I "disabled" this function. Now KMS + X is working just fine (although compositing is still really laggy, but that's another discussion...). Haven't tried yet whether suspend etc. works, but I assume suspend will not work anymore now. I've attached the current dmesg with drm debug output. If you need further data for analyzing this problem, let me know. Created attachment 38868 [details] [review] intel_dp.c patch for kernel 2.6.36-rc5 Adding an other delay to ironlake_panel_off fixes the console issue on 2.6.36-rc5 (see patch). With this patch everything works as expected on my E6510 (KMS, text console, suspend/resume) (In reply to comment #63) > Created an attachment (id=38868) [details] > intel_dp.c patch for kernel 2.6.36-rc5 > > Adding an other delay to ironlake_panel_off fixes the console issue on > 2.6.36-rc5 (see patch). With this patch everything works as expected on my > E6510 (KMS, text console, suspend/resume) This makes my dirty hack from the comment#62 obsolete. I have now a working KMS console on bootup + working X. Haven't tried suspending yet. Gradients in X still look a little strange, like they were rendered with 16 colordepth or so. There are other patches upstream that should fix the gradients (we weren't setting dither bits correctly for eDP). Henk, are both the delays needed? Either way, please push your patch upstream. eDP power sequencing is ugly and the delays are probably required to make things work on other panels as well. (In reply to comment #65) > There are other patches upstream that should fix the gradients (we weren't > setting dither bits correctly for eDP). > > Henk, are both the delays needed? Either way, please push your patch upstream. > eDP power sequencing is ugly and the delays are probably required to make > things work on other panels as well. Both delays are needed. The delay in ironlake_edp_panel_on is needed for the panel to turn on during boot and the delay in ironlake_edp_panel_off is needed for the text console to work. How do I push the patch upstream? Send it to intel-gfx@lists.freedesktop.org along with a commit message (see Documentation/SubmittingPatches in the kernel sources). Chris should pick it up quickly. henk's patch 38868 over vanilla 2.6.36-rc5 appears to completely solve the display problems on my E6510. The display comes up correctly on boot, both console and X, and comes back after inactivity timeout and suspend/resume. One problem in 2.6.35-rc4 I haven't had a chance to check, yet, in rc5: when resuming after more than a few hours suspended, once I got the screen display back (by switching to vt1 then vt7), it apparently OOPSed: frozen display, no cursor motion, no response to pings. This didn't happen after short suspends. Has anybody else noted this? Unfortunately, henk's patch (applied on top of 2.6.36-rc5) did not solve the problem on my E6510 (intel core i5, intel integrated graphics). I get an i915 error message and then the screen goes black, I can't see the boatloader but after a while I do hear the gdm drums. I compiled the kernel twice and I made sure the patch applied cleanly, so I really don't know what's going wrong. Let me know if you need any debugging info. (In reply to comment #69) > Unfortunately, henk's patch (applied on top of 2.6.36-rc5) did not solve the > problem on my E6510 (intel core i5, intel integrated graphics). I get an i915 > error message and then the screen goes black, I can't see the boatloader but > after a while I do hear the gdm drums. I compiled the kernel twice and I made > sure the patch applied cleanly, so I really don't know what's going wrong. > > Let me know if you need any debugging info. What if you increase the delays to 500ms? Nope, still no dice... Again, I see an intel ips error message and then I get a black screen. This is on 32bit. Do you have .deb packages for the kernel you compiled? I know it shouldn't make a difference, but maybe I can test them? (In reply to comment #70) > What if you increase the delays to 500ms? I increased the delay to 900ms and now it's working! I still get an i915 error message (something along the lines of "failed to get i915 symbols, graphics turbo disabled") but I can see the bootloader and the login screen now. I can resume from suspend, but after a couple of seconds the whole system freezes (killing X doesn't work, magic SysRq combination doesn't work, system doesn't seem to react to keyboard or mouse at all). I still need to figure out if this problem is due to a misbehaving running process or a bug in the kernel. (In reply to comment #71) > Nope, still no dice... Again, I see an intel ips error message and then I get a > black screen. This is on 32bit. > > Do you have .deb packages for the kernel you compiled? I know it shouldn't make > a difference, but maybe I can test them? > > > (In reply to comment #70) > > What if you increase the delays to 500ms? After a bit of experimenting I found out that resuming from suspend only results in a freeze when the laptop was booted with an external drive plugged in. Created attachment 38987 [details] [review] check for HPD before initiating DP AUX transactions I'm hoping this will eliminate the need for delays in various places, can you guys give it a try? It may not apply directly since it's from one of my working trees; if you have trouble figuring out how to munge it in let me know and I'll come up with something against ickle's latest. Oops, you'll also need to write to the hpd reg to enable hpd. For Dell E6510 (non-switchable) you should be able to intel_reg_write 0x44030 0x10 to enable it, then load the driver with the patch (or just add an I915_WRITE(DIGITAL_PORT_HOTPLUG_CNTRL, DIGITAL_PORTA_HOTPLUG_ENABLE) in the dp init function or similar). I'm afraid I'm not sure what you mean, how exactly do we enable hpd? (In reply to comment #75) > Oops, you'll also need to write to the hpd reg to enable hpd. > > For Dell E6510 (non-switchable) you should be able to intel_reg_write 0x44030 > 0x10 to enable it, then load the driver with the patch (or just add an > I915_WRITE(DIGITAL_PORT_HOTPLUG_CNTRL, DIGITAL_PORTA_HOTPLUG_ENABLE) in the dp > init function or similar). My problem with freezing up after suspend/resume has not occurred on my E6510 since I began running 2.6.36-rc5 + patch 38868. I will be happy to try an alternative without sleeps if it gets just a little clearer what that means. (In reply to comment #75) > Oops, you'll also need to write to the hpd reg to enable hpd. > > For Dell E6510 (non-switchable) you should be able to intel_reg_write 0x44030 > 0x10 to enable it, then load the driver with the patch (or just add an > I915_WRITE(DIGITAL_PORT_HOTPLUG_CNTRL, DIGITAL_PORTA_HOTPLUG_ENABLE) in the dp > init function or similar). Jesse, Any chance of getting a patch for 2.6.35.6? Or is there too many changes in 2.6.36rc? Thanks, Kirk (In reply to comment #74) > Created an attachment (id=38987) [details] > check for HPD before initiating DP AUX transactions > > I'm hoping this will eliminate the need for delays in various places, can you > guys give it a try? It may not apply directly since it's from one of my > working trees; if you have trouble figuring out how to munge it in let me know > and I'll come up with something against ickle's latest. Can you please make a patch against 2.6.36-rc6 or ickle's latest, the patch does not apply to any of my kernel sources. Created attachment 39104 [details] [review] check for HPD before initiating DP AUX transactions Ok here's one against the current drm-intel-next branch. I think we're still violating the eDP and PPS specs in other ways, but this may help avoid the random msleep in the panel power on/off code... (In reply to comment #80) I have tried this patch against the current drm-intel-next and I still have blank screen (have a dell 6410 though, but most probably it's the edp problem). Please try the edp-hacks branch of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel. It works now for people with switchable graphics, and I suspect the same bug affects CPU attached eDP in some cases as well. Thanks. Checked it out today, it doesn't work I'm afraid. This is on my Dell e6510 with intel GPU, 32bit. I can see the backlight come on and off, but I don't see the boatloader and the screen stays black when I hear the gdm drums. (In reply to comment #82) > Please try the edp-hacks branch of > git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel. It works now > for people with switchable graphics, and I suspect the same bug affects CPU > attached eDP in some cases as well. > > Thanks. Hm, if the boot loader doesn't show then you probably have a VBIOS bug of some kind. Is there a newer BIOS image available for your machine? (In reply to comment #84) > Hm, if the boot loader doesn't show then you probably have a VBIOS bug of some > kind. Is there a newer BIOS image available for your machine? I have the same notebook and similar problems, see also: https://bugzilla.novell.com/show_bug.cgi?id=642654 My BIOS is A05 and it is the latest revision. My notebook worked fine with OpenSUSE 11.3 and the initial kernel that came with it (2.6.34-12.3), but since then all new kernels seem to have problems. Oh great, if 2.6.34ish worked, maybe you can bisect down to the offending commit? git help bisect will give you an overview, it shouldn't take too long if you have a relatively fast machine. I have a Dell Latitude E6410 that exhibits similar behavior to this bug. I originally filed this kernel bug: https://bugzilla.kernel.org/show_bug.cgi?id=16514. The bug report includes a bisection and the offending patch that broke eDP for me. That bug was closed as a duplicate of this one. Is this bug also for fixing the behavior on E6410, or should I open a new bug here for that one? (In reply to comment #82) > Please try the edp-hacks branch of > git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel. It works now > for people with switchable graphics, and I suspect the same bug affects CPU > attached eDP in some cases as well. > > Thanks. Doesn't work for me. I still have a black screen during boot and suspend/resume doen't work. I can see my bootloader. When KMS starts, the screen goes off for a few seconds before the backlight turns on. After that, the screen stays black. One thing I don't see mentioned is that the E6510 comes with different displays, and AFAIK the (most) problematic one is the LG 1920x1080 one. Can those of you whose display still doesn't work confirm this? (In reply to comment #89) > One thing I don't see mentioned is that the E6510 comes with different > displays, and AFAIK the (most) problematic one is the LG 1920x1080 one. Can > those of you whose display still doesn't work confirm this? I can confirm that my problematic display is the LG 1920x1080 one. 1920x1080 here, too. Don't know, how to find out the manufacturer. Created attachment 39293 [details] [review] down the link even if DP is enabled Can you guys try this patch? We need to turn off the panel, so simply reverting the panel off calls won't work, but this may fix the issue by clearing out the DP reg when we shut things off before turning them on again. (In reply to comment #91) > 1920x1080 here, too. Don't know, how to find out the manufacturer. Mine is the 1600x900, dont know the manufacturer Sorry, I didn't mean the bios bootloader but the ubuntu bootloader i.e. the startup screen. My patched 2.6.35-rc5 kernel with 900ms delays (basically henk's patch but longer delays) works fine. My display is 15.6", but I have to check the exact specs. I'll test the new patch as soon as I can. (In reply to comment #84) > Hm, if the boot loader doesn't show then you probably have a VBIOS bug of some > kind. Is there a newer BIOS image available for your machine? We have Fedora downstream report of I think the same bug which is blocking F14: https://bugzilla.redhat.com/show_bug.cgi?id=639146 I have asked one of the reporters in that bug to test the current (as of yesterday) edp-fixes branch which I believe includes the patch you wanted tested; he reports it doesn't work (and actually behaves worse than a 'normal' kernel). See https://bugzilla.redhat.com/show_bug.cgi?id=639146#c17 . Just for info - I know you don't have to work to our timelines, Jesse :), but we'd really really love to have some kind of fix for this by Fedora 14 final change deadline, which is Monday 2010-10-18. Please do let us know if there's any info we can provide, some of the Fedora reporters on this are quite active and have the ability to provide debug output and test kernel patches and stuff. thanks! Damn, I shouldn't have given away my E6510. I'll have to get a CPU attached eDP panel for testing. I know we have a bisect pointing at the panel_off call, but is there a more recent commit that also worked? If so, can you bisect down to which recent commit broke things again? hey, Jesse. As far as I can tell it's been broken with all Fedora 2.6.34+ kernels. The F14 report only dates from last month and there's no report from any reporter of it working with any F14 kernel. There is an F13 report: https://bugzilla.redhat.com/show_bug.cgi?id=629547 which reports that it broke between 2.6.33.8-149 and 2.6.34.6-47 (so, basically, between 2.6.33 and 2.6.34 - that just happens to be the 2.6.34 build where we flipped F13 from 2.6.33 to 2.6.34). The F13 report points to this bisection someone did: http://lists.freedesktop.org/archives/intel-gfx/2010-May/006948.html which may be the one you're thinking of. That's all I can find ATM. Where are you located? I can always see if I can find a user of the affected hardware who's in your geographical area... (In reply to comment #92) > Created an attachment (id=39293) [details] > down the link even if DP is enabled > > Can you guys try this patch? We need to turn off the panel, so simply > reverting the panel off calls won't work, but this may fix the issue by > clearing out the DP reg when we shut things off before turning them on again. Hi. I have tested your edp-hacks branch and, separately, applied the patch you mention. Both kernels show the same behavior: they boot to X but the panel is off in both cases. Moreover, the panel is not switched on after changing to console and back to X display. The current kernel in the "ickle" intel-fixes branch does switch the display on. BTW, a previous intel-fixes kernel with the patch Henk proposed does switch on the panel. I have a Dell Latitude E6510 with BIOS A03, a 1920x1080 panel, and I am running 32 bit. Do not know the panel maker. Hope this helps. I can test other kernels (not immediately, but usually within one day or so). On a E6510 i3, intel gpu, fhd display, a vanilla kernel 2.6.36-rc6 (x86_64) works after (and only after) applying https://bugs.freedesktop.org/attachment.cgi?id=38868. Which branch and patches would be helpful to try out? Does this patch still make things work? Should be applicable to either my edp-fixes branch or drm-intel-next.
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -201,6 +201,8 @@ intel_dp_mode_valid(struct drm_connector *connector,
int max_link_clock = intel_dp_link_clock(intel_dp_max_link_bw(intel_dp))
int max_lanes = intel_dp_max_lane_count(intel_dp);
+ return MODE_OK;
+
if (is_edp(intel_dp) && dev_priv->panel_fixed_mode) {
if (mode->hdisplay > dev_priv->panel_fixed_mode->hdisplay)
return MODE_PANEL;
(In reply to comment #100) > On a E6510 i3, intel gpu, fhd display, a vanilla kernel 2.6.36-rc6 (x86_64) > works after (and only after) applying > https://bugs.freedesktop.org/attachment.cgi?id=38868. Which branch and patches > would be helpful to try out? That commit is included in drm-intel-next now, so you could confirm that it still works for you. Unfortunately, that commit isn't sufficient for everyone, so we still need another fix (I suspect the delays are just working around another problem we have somewhere). Fedora tester reports "Result: No change, blank screen, blacklight on. Sigh." with the patch from comment #101 (tester has an E4310) (In reply to comment #102) > (In reply to comment #100) > > On a E6510 i3, intel gpu, fhd display, a vanilla kernel 2.6.36-rc6 (x86_64) > > works after (and only after) applying > > https://bugs.freedesktop.org/attachment.cgi?id=38868. Which branch and patches > > would be helpful to try out? > > That commit is included in drm-intel-next now, so you could confirm that it > still works for you. Unfortunately, that commit isn't sufficient for everyone, > so we still need another fix (I suspect the delays are just working around > another problem we have somewhere). sorry it took me awhile to reply but i thought i was subscribed to the list and in fact i was not. anyway i cannot really say if the "msleep" solution still works for me. i was unable to clone git://people.freedesktop.org/~ickle/drm-intel. i tried the kernel.org repositories below with and without the patch you suggest in comment #101. 1. torvalds/linux-2.6 (2.6.36-rc8) HEAD: 2b666ca4a68cbc22483b0f2e1ba3c0e59b01ae9e 2. ickle/drm-intel (2.6.36-rc7) HEAD: 6939a5aca7cfada279a24c307e772f33104fca20 BRANCH: drm-intel-fixes 3. jbarnes/drm-intel 2.6.35 HEAD:78b40858edc6bd41cbc8cdb094d05d59d2feea4f BRANCH: drm-intel-next as a result: - screen goes blank as udev starts with 1, 1-patched, 2, and 2-p - backlight stays on with 1, 1-p, 2 - backlight goes off with 2-p - i can start x and switch to it with 2 p (i have not tried this with the other kernels) i could not compile 3 yet because of: "drivers/gpu/drm/i915/intel_overlay.c:1467: error: implicit declaration of function 'seq_printf'" i will keep trying. Does anyone know if this might be related to our problem? http://lists.freedesktop.org/archives/intel-gfx/2010-May/006948.html (In reply to comment #105) > Does anyone know if this might be related to our problem? > http://lists.freedesktop.org/archives/intel-gfx/2010-May/006948.html I have a DELL E6510 with Intel Ironlake and can confirm that kernel 2.6.34-12.3 works fine and 2.6.34.7-0.3.1 does not work anymore (blank screen with backlight on) (In reply to comment #65) > There are other patches upstream that should fix the gradients (we weren't > setting dither bits correctly for eDP). Does anyone know where this patches for fixing the dither bits are located? Gradients still look terribly ugly here. Latest intel-drm-next causes problems with suspending on a E6510 here: Suspending works fine, but after waking the laptop up again, the screen stays black (although the backlight is turned on). Besides that, everything else seems to work. I just cloned intel-drm and switched to the intel-drm-next branch but doesn't work for my E6510 (1920x1200). I still have a black screen. I'm using Ubuntu 10.10 and tried to compile some diffrent kernels with patches according to other discussions I've found but not got an working solution. I'm intrested in getting this solved and help out with testing. I've got.. Dell e6510 Bios A05 Intel Core i5 M520 @ 2,4ghz Video controller: Intel GMA HD Video BIOS Version: 1994v24 Video memory: 32 MB Panel type: 15,6" FHD Native res: 1920 by 1080 I also got an external display connected to a port replicator. I'm not sure if this is just mu machine or a problem with this model, but i don't think the graphics feels "stable" at all. Sometimes when rebooting the GRUB meny is not shown, and sometimes not even the firmware screen, without powering of and wait a few seconds and start again. If you want me to test anything let me know, I can reinstall my machine with another distro if that would be better aswell! I'm the Fedora tester that Adam Williamson is referring to. I've signed up as I'd like to contribute in any way to resolve this bug, the impact is not fun (In reply to comment #109) > Dell e6510 > Bios A05 > Intel Core i5 M520 @ 2,4ghz > > I'm not sure if this is just mu machine or a problem with this model, but i > don't think the graphics feels "stable" at all. Sometimes when rebooting the > GRUB meny is not shown, and sometimes not even the firmware screen, without > powering of and wait a few seconds and start again. I have an E4310, and agree with your issue, I have it too. Created attachment 39835 [details]
dmesg, drm.debug=0xe, no backlight during boot, backlight in X, but black
Using intel-drm-next/8f28f54aad8bcf52a47afb6447fac34f96597b6f the results on a DELL E6510 (no external display, no port replicator) are:
- Black screen without backlight on boot
- Black screen but backlight turned on, when X is started
See attached dmesg output for details.
intel_gpu_dump output will follow in next attachment.
Created attachment 39836 [details] intel_gpu_dump, no backlight during boot, backlight in X, but black See comment#111 for details. I have latest kubuntu and dell vostro 3300. I've tried yesterdays drm-intel-next (2.6.36-997-generic_2.6.36-997.201010280905_i386). LVDS works fine, as before, vith older kernels. VGA works only in 1024x768 in clone mode (single VGA 1024x768 output does not work). And image on VGA trembles with short (about 5px) waves which go down the screen, shifting screen lines in horisontal direction. And image on VGA screen periodically goes black for a moment and then restores. Image on LVDS is perfect. In any other mode or even in 1024x768 absolute position at 0.0 on both screens VGA display shows "Entering power saving mode". It looks like it is beeng reinitialized periodically, bacause this message is shown again and again. I've been pretty busy for a while but now I have more time to test patches on my e6510 with intel ironlake graphics. Does the one from comment 101 still need to be tested, or are there new patches to test now? Like everyone else I'd be glad to see this one solved... I am by the way also interested in a fix for the gradient problem mentioned above. A link to a patch would be much appreciated. (In reply to comment #101) > Does this patch still make things work? Should be applicable to either my > edp-fixes branch or drm-intel-next. > > > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -201,6 +201,8 @@ intel_dp_mode_valid(struct drm_connector *connector, > int max_link_clock = > intel_dp_link_clock(intel_dp_max_link_bw(intel_dp)) > int max_lanes = intel_dp_max_lane_count(intel_dp); > > + return MODE_OK; > + > if (is_edp(intel_dp) && dev_priv->panel_fixed_mode) { > if (mode->hdisplay > dev_priv->panel_fixed_mode->hdisplay) > return MODE_PANEL; It does not work on a Dell E6510, full HD panel, 32 bit installation, Ubuntu 10.10 (Maverick). In fact what happens is that X does not start at all: the message [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module! appears at boot time and in dmesg. Maybe I am applying the patch to a wrong version of drm-intel-next? The last commit in the repository I cloned is add354ddf62beac55ca3ba64835dd703a0649867 . (In reply to comment #115) > (In reply to comment #101) > > Does this patch still make things work? Should be applicable to either my > > edp-fixes branch or drm-intel-next. > > > > > > --- a/drivers/gpu/drm/i915/intel_dp.c > > +++ b/drivers/gpu/drm/i915/intel_dp.c > > @@ -201,6 +201,8 @@ intel_dp_mode_valid(struct drm_connector *connector, > > int max_link_clock = > > intel_dp_link_clock(intel_dp_max_link_bw(intel_dp)) > > int max_lanes = intel_dp_max_lane_count(intel_dp); > > > > + return MODE_OK; > > + > > if (is_edp(intel_dp) && dev_priv->panel_fixed_mode) { > > if (mode->hdisplay > dev_priv->panel_fixed_mode->hdisplay) > > return MODE_PANEL; > > It does not work on a Dell E6510, full HD panel, 32 bit installation, Ubuntu > 10.10 (Maverick). In fact what happens is that X does not start at all: the > message > > [drm:i915_init] *ERROR* drm/i915 can't work without intel_agp module! > > appears at boot time and in dmesg. Maybe I am applying the patch to a wrong > version of drm-intel-next? The last commit in the repository I cloned is > add354ddf62beac55ca3ba64835dd703a0649867 . Note: the same happens with the kernel version 2.6.36-999-generic_2.6.36-999.201010311115 from http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current . Created attachment 39970 [details]
dmesg, drm.debug=0xe, backlight on boot, but black screen
Using intel-drm-next c6afd658073f9fdb4cc80664dac71fa9db6fdf35 on a DELL E6150 now.
This is the resulting dmesg with drm debug info.
GPU dump will follow in next attachment.
Result:
- Completely black screen (no backlight, no content) for 2-3 seconds after GRUB.
- Backlight turned on after 2-3 seconds, but black screen content
- No change when X started
Created attachment 39971 [details] intel_gpu_dump See comment#117 On a dell e6410 bios A05 running F13 I can confirm this issue. With actual patches issue has gotten worse with newest xorg and kernel updates. [root@bender /]# uname -a Linux bender 2.6.34.7-61.fc13.x86_64 #1 SMP Tue Oct 19 04:06:30 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux [root@bender /]# rpm -qa | grep xorg-x11-drv-int xorg-x11-drv-intel-2.11.0-5.fc13.x86_64 [root@bender /]# rpm -qa | grep xorg-x11-ser* xorg-x11-server-utils-7.4-16.fc13.x86_64 xorg-x11-server-Xephyr-1.8.2-4.fc13.x86_64 xorg-x11-server-Xorg-1.8.2-4.fc13.x86_64 xorg-x11-server-common-1.8.2-4.fc13.x86_64 [root@bender /]# rpm -qa | grep grub grubby-7.0.16-1.fc13.x86_64 grub-0.97-64.fc13.x86_6 [root@bender /]# lspci -v | grep Intel 00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 02) 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller]) [root@bender /]# modinfo i915 filename: /lib/modules/2.6.34.7-61.fc13.x86_64/kernel/drivers/gpu/drm/i915/i915.ko license: GPL and additional rights description: Intel Graphics author: Tungsten Graphics, Inc. license: GPL and additional rights srcversion: BBF76EFB76067B7A489969A 1.)If in the docking station After BIOS Post, total blackscreen on the notebook monitor and no grub menu unless pressing shift f6. Kernel boot screen will appear on the external monitor through the docking station all the way until runlevel 5 is reached , Notebook monitor still black. Logging into GNOME will give me a screen on the external until I undock then Notebook has a screen , redocking gives mutiple display . 2.)If not in the docking station screen completely black after BIOS Post, no grub, no kernel boot screen, no GDM Greeter is shown. 3.)If not in the docking station and external monitor into External VGA Port, no grub, but kernel boot screen is shown , X GDM Greeter appears , everything works on external display only . Unplugging and replugging Notebook Monitor is still black. ____ With older kernel release vmlinuz-2.6.33.3-85.fc13.x86_64 and previous xorg release, Normal operation in issue #1 and #2 was possible. Although no grub screen was possible. #3 was not tested as the issue was not at hand. Now with all the updates if I boot the older kernel GNOME will freeze after logging in (which is porbably a different case but hey have to try all options here) What patches can I try now or what further information is needed to resolve this issue ? Todays (03-Nov-2010) http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/current/ works a little bit better. VGA output still jitters. But now it works in all modes that are less than LVDS (reolution is less or equal on every direction and refresh rate is less and equal). Once I had it working when LVDS was disabled, again only at 1024x768 and it was jittering. Now I can't repeat this. VGA also works when it is over or under LVDS when VGA is 800x600 and LVDS is 1366x787. When I make VGA resolution bigger it falls to power save mode. I have also noticed, that jittering changes with resolution change. The lower resolution, the bigger (in centimeters, I'm not shure about pixels) wave length are. Tried today's drm-intel-next on my e6510, still no dice. The screen goes black and then white during boot, but stays black (with backlight on) after gdm is loaded. Switching to VT1 and back doesn't help. Aren't there any new patches to try? I see that this bug report is becoming less active... I tried today's version of linus's tree (2.6.37-rc1). It has henk's patch with the delays and a couple of other fixes, but it doesn't work (even with delays up to 900ms). The backlight goes on and off a couple of times during boot, but the screen stays black. I also tried applying henk's patch to v2.6.36, and that worked, so I think there has been a regression somewhere. (In reply to comment #122) > I tried today's version of linus's tree (2.6.37-rc1). It has henk's patch with > the delays and a couple of other fixes, but it doesn't work (even with delays > up to 900ms). The backlight goes on and off a couple of times during boot, but > the screen stays black. > > I also tried applying henk's patch to v2.6.36, and that worked, so I think > there has been a regression somewhere. There is definitely a regression somewhere, with the SUSE 11.3 DVD and its kernel 2.6.34-12.3 its works completely fine on my DELL E6510, all later kernels that I have tried do not work anymore at all and show the above mentioned dark screen. I meant that there is also a regression between 2.6.36 and 2.6.37-rc1 which causes henk's workaround (the one with the delays, see one of his posts above) to fail. I'd do a bisect but unfortunately I don't have time for this... (In reply to comment #123) > (In reply to comment #122) > > I tried today's version of linus's tree (2.6.37-rc1). It has henk's patch with > > the delays and a couple of other fixes, but it doesn't work (even with delays > > up to 900ms). The backlight goes on and off a couple of times during boot, but > > the screen stays black. > > > > I also tried applying henk's patch to v2.6.36, and that worked, so I think > > there has been a regression somewhere. > > There is definitely a regression somewhere, with the SUSE 11.3 DVD and its > kernel 2.6.34-12.3 its works completely fine on my DELL E6510, all later > kernels that I have tried do not work anymore at all and show the above > mentioned dark screen. Created attachment 40116 [details] [review] Patch against 2.6.37-rc1 After some bisecting I found out that there are three commits that introduce the regression: commit c98e9dcf9023e72837c1c01251f370e2358a0de6: drm/i915: enable PCH PLL, FDI training and transcoder even for eDP commit 01cb9ea633ddf3e8770dfe7851e88610087098bc: drm/i915/dp: eDP power sequencing fixes commit 869184a675662bddcdf76c5b95665272facff2b8: drm/i915/dp: use VBT provided eDP params if available I've combined the parts that introduce the regression into one patch against 2.6.37-rc1. This patch should also work for the latest intel-next tree. (In reply to comment #125) > Created an attachment (id=40116) [details] > Patch against 2.6.37-rc1 > > After some bisecting I found out that there are three commits that introduce > the regression: > > commit c98e9dcf9023e72837c1c01251f370e2358a0de6: drm/i915: enable PCH PLL, FDI > training and transcoder even for eDP > > commit 01cb9ea633ddf3e8770dfe7851e88610087098bc: drm/i915/dp: eDP power > sequencing fixes > > commit 869184a675662bddcdf76c5b95665272facff2b8: drm/i915/dp: use VBT provided > eDP params if available > > I've combined the parts that introduce the regression into one patch against > 2.6.37-rc1. This patch should also work for the latest intel-next tree. Thanks for the bisect and the patch, henk. Are you going to forward this upstream? (In reply to comment #125) > Created an attachment (id=40116) [details] > Patch against 2.6.37-rc1 > > After some bisecting I found out that there are three commits that introduce > the regression: > > commit c98e9dcf9023e72837c1c01251f370e2358a0de6: drm/i915: enable PCH PLL, FDI > training and transcoder even for eDP > > commit 01cb9ea633ddf3e8770dfe7851e88610087098bc: drm/i915/dp: eDP power > sequencing fixes > > commit 869184a675662bddcdf76c5b95665272facff2b8: drm/i915/dp: use VBT provided > eDP params if available > > I've combined the parts that introduce the regression into one patch against > 2.6.37-rc1. This patch should also work for the latest intel-next tree. Tested the 2.6.37-rc1 with this patch on Dell 4310, but still the blank screen when booting without an external display. by my reading of what henk wrote, you need that patch *and* the earlier patch which extends some timeout or other; and it'll still only work if the timeout patch previously worked for you. henk's patch doesn't outright fix anything, AIUI. The earlier patch has been merged into 2.6.37-rc1. But you may need to increase the timeouts (up to 900ms). (In reply to comment #128) > by my reading of what henk wrote, you need that patch *and* the earlier patch > which extends some timeout or other; and it'll still only work if the timeout > patch previously worked for you. henk's patch doesn't outright fix anything, > AIUI. (In reply to comment #129) > The earlier patch has been merged into 2.6.37-rc1. But you may need to increase > the timeouts (up to 900ms). > > (In reply to comment #128) > > by my reading of what henk wrote, you need that patch *and* the earlier patch > > which extends some timeout or other; and it'll still only work if the timeout > > patch previously worked for you. henk's patch doesn't outright fix anything, > > AIUI. Hi Thanks for the info. I increased the udelay to 900 but it didn't have any effect. External display (via dock) gets the picture, but the laptop monitor only has the backlight on (all this on Dell 4310). (In reply to comment #130) > (In reply to comment #129) > > The earlier patch has been merged into 2.6.37-rc1. But you may need to increase > > the timeouts (up to 900ms). > > > > (In reply to comment #128) > > > by my reading of what henk wrote, you need that patch *and* the earlier patch > > > which extends some timeout or other; and it'll still only work if the timeout > > > patch previously worked for you. henk's patch doesn't outright fix anything, > > > AIUI. > > > Hi > > Thanks for the info. I increased the udelay to 900 but it didn't have any > effect. External display (via dock) gets the picture, but the laptop monitor > only has the backlight on (all this on Dell 4310). Have you tried kernel 2.6.36+patch#38868 (comment #63) (In reply to comment #125) > Created an attachment (id=40116) [details] > Patch against 2.6.37-rc1 > > After some bisecting I found out that there are three commits that introduce > the regression: > > commit c98e9dcf9023e72837c1c01251f370e2358a0de6: drm/i915: enable PCH PLL, FDI > training and transcoder even for eDP > > commit 01cb9ea633ddf3e8770dfe7851e88610087098bc: drm/i915/dp: eDP power > sequencing fixes > > commit 869184a675662bddcdf76c5b95665272facff2b8: drm/i915/dp: use VBT provided > eDP params if available > > I've combined the parts that introduce the regression into one patch against > 2.6.37-rc1. This patch should also work for the latest intel-next tree. I applied your patch both to 2.6.37-rc1 (I assume this is what comes out of http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git) and to intel-next. In both cases the patch applied cleanly, but it in my case (Dell E6510, 32 bit, Full HD display with Ubuntu Linux) it does not work always. In general, if I reboot without shutting down, it never came out cleanly - light is on but panel is off. Otherwise, it sometimes boots right and sometimes it does not. Suspend/resume has a similar behavior: sometimes it resumes cleanly and sometimes it gets stuck with panel off. Switching to console and back to X does not help. It seems to me that the intel-next (from a couple of days ago) works somehow a bit better. I have increased all four msleep() calls in intel_dp.c to 900, to no avail. What I am using now is linux-2.6.36-rc8 (from the tarball) with an exec() patch to solve some symbol problems and the two msleep(300) patch in intel_dp.c. This seems to be very reliable. Hope this helps. with 2.6.37-rc1-git8 and also above patch from henk it does appear to be working now on a e6410. Cheers ! gek (In reply to comment #131) > (In reply to comment #130) > > (In reply to comment #129) > > > The earlier patch has been merged into 2.6.37-rc1. But you may need to increase > > > the timeouts (up to 900ms). > > > > > > (In reply to comment #128) > > > > by my reading of what henk wrote, you need that patch *and* the earlier patch > > > > which extends some timeout or other; and it'll still only work if the timeout > > > > patch previously worked for you. henk's patch doesn't outright fix anything, > > > > AIUI. > > > > > > Hi > > > > Thanks for the info. I increased the udelay to 900 but it didn't have any > > effect. External display (via dock) gets the picture, but the laptop monitor > > only has the backlight on (all this on Dell 4310). > > Have you tried kernel 2.6.36+patch#38868 (comment #63) Now tried with stable 2.6.36 and the patch you mentioned and it works \o/ Boots up nicely with laptop monitor only, detects docking and hibernation works as well. Cheers for this one Henk. (In reply to comment #134) > (In reply to comment #131) > > (In reply to comment #130) > > > (In reply to comment #129) > > > > The earlier patch has been merged into 2.6.37-rc1. But you may need to increase > > > > the timeouts (up to 900ms). > > > > > > > > (In reply to comment #128) > > > > > by my reading of what henk wrote, you need that patch *and* the earlier patch > > > > > which extends some timeout or other; and it'll still only work if the timeout > > > > > patch previously worked for you. henk's patch doesn't outright fix anything, > > > > > AIUI. > > > > > > > > > Hi > > > > > > Thanks for the info. I increased the udelay to 900 but it didn't have any > > > effect. External display (via dock) gets the picture, but the laptop monitor > > > only has the backlight on (all this on Dell 4310). > > > > Have you tried kernel 2.6.36+patch#38868 (comment #63) > > Now tried with stable 2.6.36 and the patch you mentioned and it works \o/ > > Boots up nicely with laptop monitor only, detects docking and hibernation works > as well. > > Cheers for this one Henk. And by the way, I tried the drm-intel version from the git mentioned in this thread and that didn't work. would you mind sharing the exec patch you mention? (In reply to comment #132) > > I applied your patch both to 2.6.37-rc1 (I assume this is what comes out of > http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git) and to > intel-next. In both cases the patch applied cleanly, but it in my case (Dell > E6510, 32 bit, Full HD display with Ubuntu Linux) it does not work always. > > In general, if I reboot without shutting down, it never came out cleanly - > light is on but panel is off. Otherwise, it sometimes boots right and > sometimes it does not. Suspend/resume has a similar behavior: sometimes it > resumes cleanly and sometimes it gets stuck with panel off. Switching to > console and back to X does not help. It seems to me that the intel-next (from > a couple of days ago) works somehow a bit better. I have increased all four > msleep() calls in intel_dp.c to 900, to no avail. > > What I am using now is linux-2.6.36-rc8 (from the tarball) with an exec() patch > to solve some symbol problems and the two msleep(300) patch in intel_dp.c. > This seems to be very reliable. > > Hope this helps. (In reply to comment #136) > would you mind sharing the exec patch you mention? > > (In reply to comment #132) Sure: add the line EXPORT_SYMBOL(dump_write); after the function int dump_write(struct file *file, const void *addr, int nr) in fs/exec.c . If you do not do it, the kernel won't compile / link, so you will notice. I got the patch from a place which seems to be down now. It was not in the tarball for 2.6.36-rc8 but it was surely added shortly afterwards. (In reply to comment #134) > Now tried with stable 2.6.36 and the patch you mentioned and it works \o/ > > Boots up nicely with laptop monitor only, detects docking and hibernation works > as well. > > Cheers for this one Henk. Using now 2.6.36 + patch from comment#63 on a Dell E6510. The first boot worked just fine as expected. Tried then to suspend which caused some problems: - Screen went black (changed to VT) and KDE's suspend sound was played over and over again - As this didn't stop after 30secs, I tried to get out of this situation by pressing Ctrl+Alt+F7 to get back to VT 7/X. - As this didn't change anything, I pushed the power button to shut down the laptop through ACPI. - Nothing happened for some seconds, then suddenly KDE popped up for the split of a second and the laptop shut down. - Started the laptop again and the screen was just black on boot and it seems the OS was just frozen, as I couldn't even shut it down through ACPI button. - Did a hardreset, then the BIOS didn't show anything but a black screen. The first thing visible was GRUB's screen. - Boot worked just fine. - Suspending still doesn't work and the following happens: - Change to a VT (black screen + white cursor in upper left corner) - Completely black screen after ~20 seconds - Moving the mouse now etc shows, that the VT changed back to X, as the unlock dialog pops up now. - System is alive again and didn't suspend. So 2 issues are left: - It seems, that the state of the panel isn't always reset - Suspending doesn't work Tried to increase the delays (see patch)? 300ms and 500ms didn't work for me, 900ms does and it's very reliable even with multiple suspend cycles. (In reply to comment #138) > (In reply to comment #134) > > Now tried with stable 2.6.36 and the patch you mentioned and it works \o/ > > > > Boots up nicely with laptop monitor only, detects docking and hibernation works > > as well. > > > > Cheers for this one Henk. > > Using now 2.6.36 + patch from comment#63 on a Dell E6510. > > The first boot worked just fine as expected. > > Tried then to suspend which caused some problems: > - Screen went black (changed to VT) and KDE's suspend sound was played over and > over again > - As this didn't stop after 30secs, I tried to get out of this situation by > pressing Ctrl+Alt+F7 to get back to VT 7/X. > - As this didn't change anything, I pushed the power button to shut down the > laptop through ACPI. > - Nothing happened for some seconds, then suddenly KDE popped up for the split > of a second and the laptop shut down. > - Started the laptop again and the screen was just black on boot and it seems > the OS was just frozen, as I couldn't even shut it down through ACPI button. > > - Did a hardreset, then the BIOS didn't show anything but a black screen. The > first thing visible was GRUB's screen. > - Boot worked just fine. > - Suspending still doesn't work and the following happens: > - Change to a VT (black screen + white cursor in upper left corner) > - Completely black screen after ~20 seconds > - Moving the mouse now etc shows, that the VT changed back to X, as the > unlock dialog pops up now. > - System is alive again and didn't suspend. > > > So 2 issues are left: > - It seems, that the state of the panel isn't always reset > - Suspending doesn't work (In reply to comment #131) > Have you tried kernel 2.6.36+patch#38868 (comment #63) This worked for me (Dell E6510, Full HD, 32bit kernel). It does not seem to hibernate (but it may be due to other reasons), but so far it suspends and resumes fine using the acpi_sleep=s3_bios kernel option. Cheers and thanks! (In reply to comment #139) > Tried to increase the delays (see patch)? 300ms and 500ms didn't work for me, > 900ms does and it's very reliable even with multiple suspend cycles. This looks like a race between several parts of the system (kernel, gpu, etc.) I could suspect that the different behavior is due to different clock speeds. Maybe it works for me if I increase the delays even more. But it does not seem the good way to go. (In reply to comment #140) > This worked for me (Dell E6510, Full HD, 32bit kernel). It does not seem to > hibernate (but it may be due to other reasons), but so far it suspends and > resumes fine using the > acpi_sleep=s3_bios kernel option. > > Cheers and thanks! I can confirm this. After setting acpi_sleep=s3_bios, suspending works just fine. For me, all issues are resolved except of the dithering which causes really bad looking gradients. Jesse Barnes said in comment#65 that there'd be patches upstream for fixing the dithering, but it looks like neither in intel-drm-next nor in vanilla are any fixes for this problem. Does someone have further information or a bug report to point to? Where do information like 'use acpi_sleep=s3_bios' for E6510 go now? Such information used to be in 'hal-info', but as HAL is deprecated now, where should it go now? Hi All, I was redirected from this (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/600453) Ubuntu bug report. I have HP Elitebook 8440p with Intel graphic card and here are my problems: 1. Start laptop where laptop will display anything (except backlight), is in every 4-5 boot ups 2. If I get display in the end and I switch it off, I will not get it back (except back light). 3. Using Fn-F4 (switch display keys), is working in one way, by switching off laptops display ;-) 4. Connecting external display, sometimes doesn't work, because it will not switch it on, or it will switch laptops display off. So here is my configuration: Linux 2.6.35-23-generic #37-Ubuntu SMP Fri Nov 5 19:16:29 UTC 2010 x86_64 GNU/Linux xrandr -q Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192 VGA1 disconnected (normal left inverted right x axis y axis) DP1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 309mm x 174mm 1366x768 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) My external monitor is detected as VGA1 and my internal as DP1 as you can see. I can test new kernel if you can appoint me to where it is. Preferred is Ubuntu package, but it want be a problem to recompile everything (it will just take longer to do) ;-) I can also try any workarounds if you have them. Thanks Dejan Confirm same behaviour on HP Elitebook 2740p (1280x800) Ironlake IPS. Tried using drm-intel-next (2.6.37-rc2 + drm-intel) repo daily ubuntu autobuild as of the 20/11/2010 with no joy - (blank pannel, loading from conosle with i915 modeset=1 causing issue, works vesa only. Using the maverick standard (2.6.35-22-generic) kernel odly intermitantly allows loading of X with the intel driver, but oft times falls back to vesa - presume this is a result of using xorg-edgers. Happy to supply further infos, and will debug further over the comming days. Created attachment 40505 [details] [review] new patch I've trimmed down the patch to a few lines.... I still don'd know why we need the acpi_sleep option, but it seems to be stable. (In reply to comment #145) > Created an attachment (id=40505) [details] > new patch > > I've trimmed down the patch to a few lines.... > I still don'd know why we need the acpi_sleep option, but it seems to be > stable. Is this for the stable (2.6.36) line or for the .37-rc's as well? (In reply to comment #146) > (In reply to comment #145) > > Created an attachment (id=40505) [details] [details] > > new patch > > > > I've trimmed down the patch to a few lines.... > > I still don'd know why we need the acpi_sleep option, but it seems to be > > stable. > > Is this for the stable (2.6.36) line or for the .37-rc's as well? This patch is for the .37-rc as well as the drm-intel branch. You can use patch #38868 for the stable 2.6.36 kernel. henk > Patch does not work on my platform : using 2.6.37rc2 vanila commit b86db4744230c94e480de56f1b7f31117edbf193 attaching reg dump/hw info etc. Created attachment 40515 [details]
dmesg on hp2740p
Created attachment 40516 [details]
dmidecode
Created attachment 40517 [details]
regdump using nomodeset and i915.modeset=0 kernel options and vesa Xorg driver
Created attachment 40518 [details]
hp 2740p lspci
Review of attachment 40505 [details] [review]: does not fix hp2740p Review of attachment 40505 [details] [review]: does not fix hp2740p Created attachment 40543 [details]
intel_reg_dumper output in single user mode
I also have this bug, I have Dell E6510 with Intel HD graphics. Severity must critical - I cannot install ANY of distros on my lappy. (In reply to comment #156) > I also have this bug, I have Dell E6510 with Intel HD graphics. > > Severity must critical - I cannot install ANY of distros on my lappy. I installed Fedora 14 without issue using the "basic video" option which uses the VESA driver. Its not ideal by any stretch of the imagination but it works. >
> I installed Fedora 14 without issue using the "basic video" option which uses
> the VESA driver. Its not ideal by any stretch of the imagination but it works.
You are right, I should have been more clear - I cannot _use_ any of the distros.
Fedora 14 install on my laptop goes to black screen, same as CentOS, same as Ubuntu; I can boot OpenSUSE with nomodeset but that goes into 1280x1024 resolution - that is not usable for programming. It's 1080p on my laptop.
I am trying to voice the importance of this bug.
(In reply to comment #147) > (In reply to comment #146) > > (In reply to comment #145) > > > Created an attachment (id=40505) [details] [details] [details] > > > new patch > > > > > > I've trimmed down the patch to a few lines.... > > > I still don'd know why we need the acpi_sleep option, but it seems to be > > > stable. > > > > Is this for the stable (2.6.36) line or for the .37-rc's as well? > > This patch is for the .37-rc as well as the drm-intel branch. > You can use patch #38868 for the stable 2.6.36 kernel. Henk, patch #38868 for the stable 2.6.6 kernel works for me (I've been using it for the last two weeks or so). The patch you mention partially works in the drm-intel-fixes branch (commit bcf50e2775bbc3101932d8e4ab8c7902aa4163b4) of the git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel repository: it starts up right, but after suspending (to RAM) and resuming the panel stays off. Switching to VT1 and back does not help. I have a Dell e6510, 32bit kernel, full HD. (In reply to comment #147) > (In reply to comment #146) > > (In reply to comment #145) > > > Created an attachment (id=40505) [details] [details] [details] > > > new patch > > > > > > I've trimmed down the patch to a few lines.... > > > I still don'd know why we need the acpi_sleep option, but it seems to be > > > stable. > > > > Is this for the stable (2.6.36) line or for the .37-rc's as well? > > This patch is for the .37-rc as well as the drm-intel branch. > You can use patch #38868 for the stable 2.6.36 kernel. Henk, patch #38868 for the stable 2.6.6 kernel works for me (I've been using it for the last two weeks or so). The patch you mention partially works in the drm-intel-fixes branch (commit bcf50e2775bbc3101932d8e4ab8c7902aa4163b4) of the git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel repository: it starts up right, but after suspending (to RAM) and resuming the panel stays off. Switching to VT1 and back does not help. I have a Dell e6510, 32bit kernel, full HD. (In reply to comment #160) > (In reply to comment #147) > > (In reply to comment #146) > > > (In reply to comment #145) > > > > Created an attachment (id=40505) [details] [details] [details] [details] > > > > new patch > > > > > > > > I've trimmed down the patch to a few lines.... > > > > I still don'd know why we need the acpi_sleep option, but it seems to be > > > > stable. > > > > > > Is this for the stable (2.6.36) line or for the .37-rc's as well? > > > > This patch is for the .37-rc as well as the drm-intel branch. > > You can use patch #38868 for the stable 2.6.36 kernel. > > Henk, patch #38868 for the stable 2.6.6 kernel works for me (I've been using it > for the last two weeks or so). The patch you mention partially works in the > drm-intel-fixes branch (commit bcf50e2775bbc3101932d8e4ab8c7902aa4163b4) of the > git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel repository: it > starts up right, but after suspending (to RAM) and resuming the panel stays > off. Switching to VT1 and back does not help. I have a Dell e6510, 32bit > kernel, full HD. To make suspend/resume work on Ubuntu 10.10 I had to add acpi_sleep=s3_bios to the grub commandline and I had to delete /usr/lib/pm.utils/sleep.d/98video-quirck-db-handler and /usr/lib/pm.utils/sleep.d/99video. I hope this works for you as well. (In reply to comment #161) > > Henk, patch #38868 for the stable 2.6.6 kernel works for me (I've been using it > > for the last two weeks or so). The patch you mention partially works in the > > drm-intel-fixes branch (commit bcf50e2775bbc3101932d8e4ab8c7902aa4163b4) of the > > git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel repository: it > > starts up right, but after suspending (to RAM) and resuming the panel stays > > off. Switching to VT1 and back does not help. I have a Dell e6510, 32bit > > kernel, full HD. > > To make suspend/resume work on Ubuntu 10.10 I had to add acpi_sleep=s3_bios to > the grub commandline and I had to delete > /usr/lib/pm.utils/sleep.d/98video-quirck-db-handler and > /usr/lib/pm.utils/sleep.d/99video. > I hope this works for you as well. I have the acpi_sleep option since 10.04. I removed the two files you mention in 10.04 and the update to 10.10 reinstalled them again. However a patched 2.6.36 (and others, like versions from the intel-next branch) suspends and resumes wo. problems [module the occasional hiccup like not resuming from the suspension once in a week] with these two files in place. Will try removing them again. (In reply to comment #161) > To make suspend/resume work on Ubuntu 10.10 I had to add acpi_sleep=s3_bios to > the grub commandline and I had to delete > /usr/lib/pm.utils/sleep.d/98video-quirck-db-handler and > /usr/lib/pm.utils/sleep.d/99video. > I hope this works for you as well. It does with 2.6.37-rc3 (commit 698fd6a2c3ca05ec796072defb5c415289a86cdc), not with the intel-fixes branch (commit 6299f992c0491232f008028a1f40bc9d86c4c76c). FYI, I've been using 2.6.35.7 with the patch reversed that henk mentioned in comment 5. This has been working well with my Ironlake e6410. I installed the same on a Gateway nv79 that also has Ironlake. On this machine the screen would go blank just before starting X, very much like my e6410 before the reversed patch. The problem had to do with the fbcon, which is the kernel module needed for the display to work with the console. In my init script I was modprobing fbcon after starting udev, but apparently the DRM module needs some time before loading fbcon. After I removed modprobe fbcon from my init, the nv79 would boot into X everytime. So I ended up moving modprobe fbcon from my init script to .xinitrc since I only need fbcon if X has started and someone wants to use the console. Maybe I'm the only one who was doing this wrong, but I thought I'd post it in case it would help someone. (In reply to comment #161) > (In reply to comment #160) > > (In reply to comment #147) > > > (In reply to comment #146) > > > > (In reply to comment #145) > > > > > Created an attachment (id=40505) [details] [details] [details] [details] [details] > > > > > new patch > > > > > > > > > > I've trimmed down the patch to a few lines.... > > > > > I still don'd know why we need the acpi_sleep option, but it seems to be > > > > > stable. > > > > > > > > Is this for the stable (2.6.36) line or for the .37-rc's as well? > > > > > > This patch is for the .37-rc as well as the drm-intel branch. > > > You can use patch #38868 for the stable 2.6.36 kernel. > > > > Henk, patch #38868 for the stable 2.6.6 kernel works for me (I've been using it > > for the last two weeks or so). The patch you mention partially works in the > > drm-intel-fixes branch (commit bcf50e2775bbc3101932d8e4ab8c7902aa4163b4) of the > > git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel repository: it > > starts up right, but after suspending (to RAM) and resuming the panel stays > > off. Switching to VT1 and back does not help. I have a Dell e6510, 32bit > > kernel, full HD. > > To make suspend/resume work on Ubuntu 10.10 I had to add acpi_sleep=s3_bios to > the grub commandline and I had to delete > /usr/lib/pm.utils/sleep.d/98video-quirck-db-handler and > /usr/lib/pm.utils/sleep.d/99video. > I hope this works for you as well. Henk> Confirmed fix for no X with git linus 3.6.37rc3 on hp 2740p Lots of errors in mesg like : [ 790.300329] DRHD: handling fault status reg 3 [ 790.300343] DMAR:[DMA Write] Request device [00:02.0] fault addr ecc00000 [ 790.300346] DMAR:[fault reason 05] PTE Write access is not set [ 883.171662] DRHD: handling fault status reg 2 [ 883.171672] DMAR:[DMA Write] Request device [00:02.0] fault addr fe5ef000 [ 883.171674] DMAR:[fault reason 05] PTE Write access is not set [ 883.191476] DRHD: handling fault status reg 2 [ 883.191482] DMAR:[DMA Write] Request device [00:02.0] fault addr fed89000 [ 883.191482] DMAR:[fault reason 05] PTE Write access is not set [ 883.212208] DRHD: handling fault status reg 2 [ 883.212213] DMAR:[DMA Write] Request device [00:02.0] fault addr fce6d000 [ 883.212214] DMAR:[fault reason 05] PTE Write access is not set [ 906.054087] DRHD: handling fault status reg 2 [ 906.054094] DMAR:[DMA Write] Request device [00:02.0] fault addr fdaad000 [ 906.054095] DMAR:[fault reason 05] PTE Write access is not set Resume from suspend not working (natty). will try your suggestions. Posted comments on E6410 ATG that has similar issues to this forum https://bugs.launchpad.net/ubuntu/+source/linux/+bug/561802/comments/182 Working with generic Ubuntu kernels across three machines at the moment and having varying results (one machine of 3 exhibits this issue). My testing makes me think it may not be kernel related since same kernel on two E6410 ATG machines with the same display, one has blank screen issue and other does not! See above link for details. clark: if you're running a pre-2.6.34 kernel you will not be seeing this issue, please don't confuse the report. Sorry if I am confusing issues but Comment #2 (Jesse Barnes) is claimed fix against http://launchpad.net/bugs/561802 which definitely seems to affect earlier kernels. See also post #168 and #172 at bug 561802 which recommended posting here. Only interesting observation I may offer is the internal display can be started by connecting an external panel after the blank screen appears. A VGA connection or displayport connection both can used to restart the internal display just by connecting and disconnecting the external monitor cable after the blank screen appears. I have tested this pretty thoroughly but not sure how to capture the events/logs to show why this starts the display (or why it goes blank in the first place). If truly unrelated to this bug, I would appreciate if can you point me to another that is more directly related. Thanks. (In reply to comment #166) > Posted comments on E6410 ATG that has similar issues to this forum > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/561802/comments/182 > > Working with generic Ubuntu kernels across three machines at the moment and > having varying results (one machine of 3 exhibits this issue). My testing makes > me think it may not be kernel related since same kernel on two E6410 ATG > machines with the same display, one has blank screen issue and other does not! > See above link for details. Clark, I think that the hardware in the e6410 is different enough from that in the e6510 to not make the patches for one applicable to the other. Maybe you want to check https://bugs.launchpad.net/ubuntu/lucid/+source/xorg/+bug/561802 if you didn't do so already? Cheers. Bios A06 is out. Changes: 1. Fixed issue where OMCI fails to enumerate the DCIM_Doced instance. 2. Added SMBIOS support for TAA MAC address. 3. Fixed one boot sequence issue when switching between RAID and AHCI. 4. Fixed issue where touch screen stops working when system is docked. 5. Improve system POST and boot performance. 6. Improve the IDE-R support. 7. Improve AHCI HDD performance. 8. Added support for China SLIC. 9. Updated Arrandale C2-stepping Microcode to patch 0x0C. 10. Updated PCH 1.6 reference code. 11. Enabled ACPI SPCR for Serial-Over-Lan. 12. Added support to display On-Board NIC MAC address in BIOS SETUP. 13. Updated Intel Clarksfield Framework Reference Code to v1.31. 14. Updated Arrandale MRC to v1.40. 15. Improve Optical drive performance in ATA mode. 16. Fixed TDM SSO structure location. 17. Fixed issue where system hangs in PBA when running Sophos software. 18. Updated Intel Video BIOS. 19. Updated the manageability engine firmware to version 6.1.20.1059. 20. Fixed issues related to F12 one time boot menu. http://support.euro.dell.com/support/downloads/download.aspx?c=de&cs=dedhs1&l=de&s=dhs&releaseid=R288657&SystemID=LAT_E6510&servicetag=&os=BIOSA&osl=ge&deviceid=22212&devlib=0&typecnt=0&vercnt=5&catid=-1&impid=-1&formatcnt=0&libid=1&typeid=-1&dateid=-1&formatid=-1&source=-1&fileid=429589 Things are getting better. With the latest drm-intel-next we only need to comment out the reference to ironlake_fdi_link_train in intel_display.c.
patch:
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index d9b7092..61b6feb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2081,8 +2081,8 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
/* For PCH output, training FDI link */
if (IS_GEN6(dev))
gen6_fdi_link_train(crtc);
- else
- ironlake_fdi_link_train(crtc);
+// else
+// ironlake_fdi_link_train(crtc);
/* enable PCH DPLL */
reg = PCH_DPLL(pipe);
Has anyone tested this new BIOS yet? Does it have any effect on this bug (or other E6510-bugs)? (In reply to comment #170) > Bios A06 is out. Changes: > > 1. Fixed issue where OMCI fails to enumerate the DCIM_Doced instance. > 2. Added SMBIOS support for TAA MAC address. > 3. Fixed one boot sequence issue when switching between RAID and AHCI. > 4. Fixed issue where touch screen stops working when system is docked. > 5. Improve system POST and boot performance. > 6. Improve the IDE-R support. > 7. Improve AHCI HDD performance. > 8. Added support for China SLIC. > 9. Updated Arrandale C2-stepping Microcode to patch 0x0C. > 10. Updated PCH 1.6 reference code. > 11. Enabled ACPI SPCR for Serial-Over-Lan. > 12. Added support to display On-Board NIC MAC address in BIOS SETUP. > 13. Updated Intel Clarksfield Framework Reference Code to v1.31. > 14. Updated Arrandale MRC to v1.40. > 15. Improve Optical drive performance in ATA mode. > 16. Fixed TDM SSO structure location. > 17. Fixed issue where system hangs in PBA when running Sophos software. > 18. Updated Intel Video BIOS. > 19. Updated the manageability engine firmware to version 6.1.20.1059. > 20. Fixed issues related to F12 one time boot menu. > > http://support.euro.dell.com/support/downloads/download.aspx?c=de&cs=dedhs1&l=de&s=dhs&releaseid=R288657&SystemID=LAT_E6510&servicetag=&os=BIOSA&osl=ge&deviceid=22212&devlib=0&typecnt=0&vercnt=5&catid=-1&impid=-1&formatcnt=0&libid=1&typeid=-1&dateid=-1&formatid=-1&source=-1&fileid=429589 I've installed the new BIOS, but it has no effect on this bug (or any other E6510 bug, as far as I can see). (In reply to comment #172) > Has anyone tested this new BIOS yet? Does it have any effect on this bug (or > other E6510-bugs)? > > (In reply to comment #170) > > Bios A06 is out. Changes: > > > > 1. Fixed issue where OMCI fails to enumerate the DCIM_Doced instance. > > 2. Added SMBIOS support for TAA MAC address. > > 3. Fixed one boot sequence issue when switching between RAID and AHCI. > > 4. Fixed issue where touch screen stops working when system is docked. > > 5. Improve system POST and boot performance. > > 6. Improve the IDE-R support. > > 7. Improve AHCI HDD performance. > > 8. Added support for China SLIC. > > 9. Updated Arrandale C2-stepping Microcode to patch 0x0C. > > 10. Updated PCH 1.6 reference code. > > 11. Enabled ACPI SPCR for Serial-Over-Lan. > > 12. Added support to display On-Board NIC MAC address in BIOS SETUP. > > 13. Updated Intel Clarksfield Framework Reference Code to v1.31. > > 14. Updated Arrandale MRC to v1.40. > > 15. Improve Optical drive performance in ATA mode. > > 16. Fixed TDM SSO structure location. > > 17. Fixed issue where system hangs in PBA when running Sophos software. > > 18. Updated Intel Video BIOS. > > 19. Updated the manageability engine firmware to version 6.1.20.1059. > > 20. Fixed issues related to F12 one time boot menu. > > > > http://support.euro.dell.com/support/downloads/download.aspx?c=de&cs=dedhs1&l=de&s=dhs&releaseid=R288657&SystemID=LAT_E6510&servicetag=&os=BIOSA&osl=ge&deviceid=22212&devlib=0&typecnt=0&vercnt=5&catid=-1&impid=-1&formatcnt=0&libid=1&typeid=-1&dateid=-1&formatid=-1&source=-1&fileid=429589 (In reply to comment #171) > Things are getting better. With the latest drm-intel-next we only need to > comment out the reference to ironlake_fdi_link_train in intel_display.c. > > patch: > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_d > index d9b7092..61b6feb 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -2081,8 +2081,8 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc) > /* For PCH output, training FDI link */ > if (IS_GEN6(dev)) > gen6_fdi_link_train(crtc); > - else > - ironlake_fdi_link_train(crtc); > +// else > +// ironlake_fdi_link_train(crtc); > > /* enable PCH DPLL */ > reg = PCH_DPLL(pipe); I can confirm that this makes my computer (e6510, 32bits, full HD) display X on boot, and the color gradients are much better than with the 2.6.36 I am usually using. However, after suspend and resume the panel is off and I didn't find any way to switch it on. I tried with and without the files under /usr/lib/pm-utils/sleep.d Henk mentioned before in this thread to no avail. I also have the acpi_sleep=s3_bios kernel boot option. Cheers! (In reply to comment #173) > I've installed the new BIOS, but it has no effect on this bug (or any other > E6510 bug, as far as I can see). My e6510 still has Bios A03. Should I update? Is there any noticeable / advisable change in newer BIOS versions? I recently reverted back to A05 from A06, because I had some issues with suspend/resume. (In reply to comment #175) > (In reply to comment #173) > > I've installed the new BIOS, but it has no effect on this bug (or any other > > E6510 bug, as far as I can see). > > My e6510 still has Bios A03. Should I update? Is there any noticeable / > advisable change in newer BIOS versions? Created attachment 41121 [details] [review] unlock panel regs unconditionally This gets my Vaio working again, I wonder if it will work for anyone else? Patch against drm-intel-next as of yesterday. Using F-15 rawhide kernel 2.6.37-0.rc5.git2.1.fc15.x86_64 on F-14 this works for me on a Dell e6410. The hot-plug of a projector to the VGA port works fine and I'll test a DVI monitor on a docking station tomorrow. But the internal eDP port doesn't report correctly from xrandr. So its certainly improving. I've not tried suspend at all. # xrandr Screen 0: minimum 320 x 200, current 1440 x 900, maximum 8192 x 8192 (null)1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 303mm x 189mm 1440x900 60.0*+ 40.0 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) (In reply to comment #177) > Created an attachment (id=41121) [details] > unlock panel regs unconditionally > > This gets my Vaio working again, I wonder if it will work for anyone else? > Patch against drm-intel-next as of yesterday. It does not work in my Dell e6510, Full HD (boots to black screen since panel is turned on). (In reply to comment #179) > (In reply to comment #177) > > Created an attachment (id=41121) [details] [details] > > unlock panel regs unconditionally > > > > This gets my Vaio working again, I wonder if it will work for anyone else? > > Patch against drm-intel-next as of yesterday. > > It does not work in my Dell e6510, Full HD (boots to black screen since panel > is turned on). I meant panel is *not* turned on. I have made a test with the latest drm-intel-next branch (commit 3b8d8d91d51c7d15cda51052624169edf7b6dbc6) and the patches in comment #177 (https://bugs.freedesktop.org/show_bug.cgi?id=29278#c177)and comment #171 (https://bugs.freedesktop.org/show_bug.cgi?id=29278#c171). None of them seem to reliably make X work in an e6510, full HD, bios A03 boot into X. However, applying patch #171 and increasing the msleep(300) in drivers/gpu/drm/i915/intel_dp.c to msleep(900) does boot into X - but it after suspend to ram/resume the panel is not turned on. My uneducated guess is that some register / memory location is not set right when resuming, because if, with the panel off, I reboot and the laptop is *not* switched off, then the panel is not turned on on boot. However, if I switch the laptop off and reboot, then the panel is turned on. It seems to hibernate and resume, but after this the graphics seem to go very slow and sometimes to react to changes in the window's contents only when there is an event in the X input queue. I do not know what is the status of this issue, but if there is anything I can do to help with the testing, etc. I'd do. I have tested drm-intel-next 5909a77ac62cc042f94bd262016cf468a2f96022 with msleep(300) increased to msleep(900) (I suppose this is harmless and seems to be necessary for some laptops). The panel does not turn on boot. If the lines which call ironlake_fdi_link_train(crtc) in function ironlake_crtc_enable(...) are commented, as in if (IS_GEN6(dev)) gen6_fdi_link_train(crtc); // else // ironlake_fdi_link_train(crtc); then the panel is turned on on boot (Henk's recommendation). Suspension works, but after resuming the panel is not turned on. However I discovered that switching the screen off and on turns the panel (I have the suspension triggered by a key combination and closing the lid just blanks the screen, so after resuming I just have to close and open the lid). This is enough for me. However, there is a problem which appears sometimes for no apparent reason: the computer becomes very slow, and it it quite clear that it is because screen operations have become slow as well. I haven't identified a pattern for this, but it has happened when browsing the web, when editing, etc. It becomes almost unusable. However, suspending an resuming cures this, but I am not happy to have to suspend and resume every half an hour or so. My laptop: e6510, 32bits, full HD, BIOS A03. Hope this helps catch bugs. Apologies for vanishing (medical). I just built 2.6.37-rc7, and it still comes up with a (backlit) black screen. Plugging in an external monitor, I get an fb console on it. Unplugging the external monitor doesn't improve matters. (With patch 38868, 2.6.36-rc5 was mostly OK, including suspend/resume, although fooling with gnome-display-properties could crash it.) This is an e6510 with i5, 1920x1080, A03. It also has the busted Alps pad (hoping https://patchwork.kernel.org/patch/350841/ gets into 2.6.37). Other people with e6510s: can you do a full "make clean; make" kernel build without overheating? I have to watch and pause the build when the temperature goes over 103C. (In reply to comment #183) > I just built 2.6.37-rc7, and it still comes up with a (backlit) black screen. > Plugging in an external monitor, I get an fb console on it. Unplugging the > external monitor doesn't improve matters. (With patch 38868, 2.6.36-rc5 was > mostly OK, including suspend/resume, although fooling with > gnome-display-properties could crash it.) The 2.6.36 works as well quite reliably. I have been using it for some weeks now with just a couple of patches: - A Linus patch for exec (won't compile otherwise - some symbol was not exported). - A patch from Henk to add msleep() to drivers/gpu/drm/i915/intel_dp.c (just two lines). It appeared in this discussion. > This is an e6510 with i5, 1920x1080, A03. It also has the busted Alps pad > (hoping https://patchwork.kernel.org/patch/350841/ gets into 2.6.37). I didn't have that applied - thanks! > Other people with e6510s: can you do a full "make clean; make" kernel build > without overheating? I have to watch and pause the build when the temperature > goes over 103C. I can. I am a relatively heavy user and never overheated. Maybe it depends on the CPU / disk model and speed? Using drm-intel-fixes branch, 2.6.37-rc7+ (4d3024428f). Rebooting from a running 2.6.36 only a black screen (backlight on) is shown on boot (laptop in dockingstation, no external display connected). Rebooting laptop in this state (using ACPI shutdown via button + regular start afterwards), no GRUB is shown and a black screen (backlight on) is shown on boot again. Undocking laptop, removing battery for some seconds, starting it undocked again, the kernel panics obviously during reboot (blinking LEDs) while not being able to tell more details due to the still black screen on boot. Hi! I'm having the same issues, I have a e6510 with Full HD panel running Gentoo with 2.6.36 and the patches to make it work, I'll be happy to help with anything. Hooray, finally got my E6510 with the 1920x1080 panel. Things actually look good so far (i.e. the Ubuntu 10.10 installer comes up ok). Will try the latest kernel bits once I finish the install... arg, the one I received only has nvidia graphics! Ordering another one now... (In reply to comment #188) > arg, the one I received only has nvidia graphics! Ordering another one now... I can swap mine for yours :-) I was going to say that. I just built 2.6.37-rc8. It behaves the same as 2.6.37-rc7: black (but backlit) screen, external monitor shows fb image. (In reply to comment #190) > I was going to say that. > > I just built 2.6.37-rc8. It behaves the same as 2.6.37-rc7: black (but > backlit) screen, external monitor shows fb image. Did you try applying any of the patches suggested before in this thread? Also, i found out that in some recent kernels (in the drm-intel-next branch) switching off and on the screen (e.g., binding closing the lid to "blank screen" and then actually closing and opening the lid) actually works for switching the panel on. (In reply to comment #191) > > I just built 2.6.37-rc8. It behaves the same as 2.6.37-rc7: black (but > > backlit) screen, external monitor shows fb image. > > Did you try applying any of the patches suggested before in this thread? > Also, i found out that in some recent kernels (in the drm-intel-next branch) > switching off and on the screen (e.g., binding closing the lid to "blank > screen" and then actually closing and opening the lid) actually works for > switching the panel on. The patches I looked at seemed to be in already. By the way, my question about overheating should have been, "can you do a full 'make clean; make -j4' kernel build without overheating?" Are there any particular patches I should try out? (In reply to comment #192) > (In reply to comment #191) > > > I just built 2.6.37-rc8. It behaves the same as 2.6.37-rc7: black (but > > > backlit) screen, external monitor shows fb image. > > > > Did you try applying any of the patches suggested before in this thread? > > Also, i found out that in some recent kernels (in the drm-intel-next branch) > > switching off and on the screen (e.g., binding closing the lid to "blank > > screen" and then actually closing and opening the lid) actually works for > > switching the panel on. > > The patches I looked at seemed to be in already. > > By the way, my question about overheating should have been, "can you do a full > 'make clean; make -j4' kernel build without overheating?" > > Are there any particular patches I should try out? try #182 (In reply to comment #192) > By the way, my question about overheating should have been, "can you do a full > 'make clean; make -j4' kernel build without overheating?" Yes, I can. I am actually using the instructions at https://wiki.ubuntu.com/KernelTeam/GitKernelBuild. I assume that "CONCURRENCY_LEVEL=`getconf _NPROCESSORS_ONLN` fakeroot make-kpkg --initrd --append-to-version=-custom --overlay-dir=$HOME/ubuntu-package kernel_image kernel_headers" has the same effect as I am seeing the 4 cores executing in gkrellm. (In reply to comment #193) > (In reply to comment #192) > > Are there any particular patches I should try out? > > try #182 I am applying that to every new kernel in drm-intel-next and linux-2.6, but it is not making any effect from some revisions now. However, if any of you have a different experience, I'd be glad to be corrected --- I'd try again. <i>"hopefully the last 'blank screen' <a href="http://lwn.net/Articles/421654/" >regression on intel</a> graphics".</i> <p> Linus has such a droll sense of humor. <p> Just to check, I built 2.6.37. It's no better than the -rc series, at least on a 1920x1080 e6510. By the way, the screen turns off and back on again when I plug and unplug an external monitor, but that doesn't help any more. (It used to.) The problem lies in the CPU FDI TX train function. Commenting out I915_WRITE(reg, temp | FDI_TX_ENABLE); in the ironlake_fdi_link_train function in intel_display.c fixes the issue. The patch 'drm/i915: check eDP encoder correctly when setting modes' in rev 369581028e2528122cc109abacf11766ae231f01 in drm-intel-fixes fixed the blank screen on my E6410. Even suspend / resume seems to work. (In reply to comment #197) > The problem lies in the CPU FDI TX train function. > Commenting out I915_WRITE(reg, temp | FDI_TX_ENABLE); in the > ironlake_fdi_link_train function in intel_display.c fixes the issue. I have now tried that... the screen wakes up on boot, sure enough. After suspend/resume, it does not. Plugging in an external monitor, and unplugging it, restores function until the next suspend. Preparing to try the suggestion in #198... (In reply to comment #197) > The problem lies in the CPU FDI TX train function. > Commenting out I915_WRITE(reg, temp | FDI_TX_ENABLE); in the > ironlake_fdi_link_train function in intel_display.c fixes the issue. On machines with just Intel graphics, you're right, we shouldn't be enabling FDI at all. It'll cost power and may cause other trouble... Patch coming. Created attachment 41675 [details] [review] avoid enabling PCH resources on DP_A Can you guys give this patch a try? Oh, and this patch depends on some others; they're all in the edp-fixes-2 branch of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel.git (In reply to comment #199) > (In reply to comment #197) > > The problem lies in the CPU FDI TX train function. > > Commenting out I915_WRITE(reg, temp | FDI_TX_ENABLE); in the > > ironlake_fdi_link_train function in intel_display.c fixes the issue. > > I have now tried that... the screen wakes up on boot, sure enough. > After suspend/resume, it does not. Plugging in an external monitor, > and unplugging it, restores function until the next suspend. > Preparing to try the suggestion in #198... Nathan, suspend/resume might also be helped by my DP retraining patch. Posted as "drm/i915: make DP training try a little harder" on intel-gfx. The latest one is in reply to Yuanhan. (In reply to comment #203) > (In reply to comment #199) > > (In reply to comment #197) > > > The problem lies in the CPU FDI TX train function. > > > Commenting out I915_WRITE(reg, temp | FDI_TX_ENABLE); in the > > > ironlake_fdi_link_train function in intel_display.c fixes the issue. > > > > I have now tried that... the screen wakes up on boot, sure enough. > > After suspend/resume, it does not. Plugging in an external monitor, > > and unplugging it, restores function until the next suspend. > > Preparing to try the suggestion in #198... > > Nathan, suspend/resume might also be helped by my DP retraining patch. Posted > as "drm/i915: make DP training try a little harder" on intel-gfx. The latest > one is in reply to Yuanhan. Jesse, I tried your patch(es) directly from your branch, it works without modifications, at first the display's initialization is kind of ugly, with a white screen, then some noise, then the framebuffer loads, suspend/resume still doesn't work. latest drm-intel-next with patch from #197, it worked, but I have a DisplayPort to HDMI converter plugged to a Full HD monitor as second display, and it just doesn't work, tomorrow I'll be testing your branch with that configuration. One thing to note, with this patch, if I change the LCD brightness, the laptop becomes slightly unresponsive with the mouse and the keyboard for a moment. Let me know if you need to test something > Jesse, I tried your patch(es) directly from your branch, it works without > modifications, at first the display's initialization is kind of ugly, with a > white screen, then some noise, then the framebuffer loads, suspend/resume still > doesn't work. ok, the dp training patch might help that. I'll push it over to my branch. > latest drm-intel-next with patch from #197, it worked, but I have a DisplayPort > to HDMI converter plugged to a Full HD monitor as second display, and it just > doesn't work, tomorrow I'll be testing your branch with that configuration. Yeah, I'd expect the patch in #197 to break external displays, but hopefully my branch will still work. > One thing to note, with this patch, if I change the LCD brightness, the laptop > becomes slightly unresponsive with the mouse and the keyboard for a moment. Hm this patch shouldn't affect backlight processing at all afaik, maybe you can run 'perf top' while adjusting the backlight to see what sticks out? ok, just updated my edp-fixes-2 branch with all the relevant patches, please pull and try again. (In reply to comment #205) > > Jesse, I tried your patch(es) directly from your branch, it works without > > modifications, at first the display's initialization is kind of ugly, with a > > white screen, then some noise, then the framebuffer loads, suspend/resume still > > doesn't work. > > ok, the dp training patch might help that. I'll push it over to my > branch. It certainly did, now just works! > > > latest drm-intel-next with patch from #197, it worked, but I have a DisplayPort > > to HDMI converter plugged to a Full HD monitor as second display, and it just > > doesn't work, tomorrow I'll be testing your branch with that configuration. > > Yeah, I'd expect the patch in #197 to break external displays, but > hopefully my branch will still work. I'll have to wait to 8am to test this (GMT -0430) > > > One thing to note, with this patch, if I change the LCD brightness, the laptop > > becomes slightly unresponsive with the mouse and the keyboard for a moment. > > Hm this patch shouldn't affect backlight processing at all afaik, maybe > you can run 'perf top' while adjusting the backlight to see what sticks > out? I saw nothing extraordinary there, but with top gnome-power-manager gets on the way, I think there's the problem, now when I change backlight brightness it shows the little widget with the brightness level, that's what causes this lag, no idea how and why. still no good news of suspend/resume though (In reply to comment #206) > ok, just updated my edp-fixes-2 branch with all the relevant patches, please > pull and try again. Using edp-fixes-2 (75ce6f05) finally solved all my problems with Arrandale graphics so far. - Booting up works just fine without any unexpected things happening (no black screen anymore). - Suspend/Resume works way better than ever before (resuming took way longer before, no more strange focus issues with KDE's unlock dialog) - The dithering looks correct now - no more ugly gradients Thanks a lot for all the work - I'd love to see the fixes in 2.6.37.1 (In reply to comment #206) > ok, just updated my edp-fixes-2 branch with all the relevant patches, please > pull and try again. Jesse, I have been trying it for a few hours without problems: boots OK, suspends and resumes, no apparent graphic problem. Thank you very much for all the work! I haven't tested connecting an external monitor / beamer yet, but I will be able do try tomorrow. One thing which is still not working (but it is probably not related to the i915 code) is resuming after hibernating to disk: it freezes when restoring the saved image. Cheers! I did $ git pull git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel.git edp-fixes-2 and built a kernel. It boots, it runs, it displays, it suspends, it resumes, it dithers beautifully. Thanks to everyone. It's been a long haul. Will try plugging an external monitor tomorrow. I can confirm that the edp-fixes-2 branch works without any patch or modification. Thanks Jesse for all the hard work! Hi, I've been testing now with the second monitor plugged, here's the results: If I boot the computer with the monitor plugged, it runs smoothly, before on 2.6.36 it gave me IRQ conflicts and took forever to boot up. Suspend works for me, but if I wait about 30 mins or a little more and suspend, then resuming gives me black screen, does anyone have this behavior? I'll keep trying and see if I can come up with debugging info. In 2.6.36, as soon as I plugged in/out the external display, X would reconfigure itself to the change, it is not automagic anymore. I'm using a DisplayPort to HDMI converter, I can try with VGA too if anyone needs it. but overall this series of patches are way better than before, congrats Jesse (In reply to comment #212) > Hi, I've been testing now with the second monitor plugged, here's the results: > > > Suspend works for me, but if I wait about 30 mins or a little more and suspend, > then resuming gives me black screen, does anyone have this behavior? I'll keep > trying and see if I can come up with debugging info. I have it left sleep all night and resumed without problems. > In 2.6.36, as soon as I plugged in/out the external display, X would > reconfigure itself to the change, it is not automagic anymore. > > I'm using a DisplayPort to HDMI converter, I can try with VGA too if anyone > needs it. I (have to) use the VGA port often, but I've never used the DisplayPort, so I cannot comment on this. > but overall this series of patches are way better than before, congrats Jesse Yes! BTW, I have applied to the edp-2 the patches from https://patchwork.kernel.org/patch/350841/ which enable vertical scrolling on the Alps touchpad; they are working without issues so far. (In reply to comment #213) > (In reply to comment #212) > > Hi, I've been testing now with the second monitor plugged, here's the results: > > > > > > Suspend works for me, but if I wait about 30 mins or a little more and suspend, > > then resuming gives me black screen, does anyone have this behavior? I'll keep > > trying and see if I can come up with debugging info. > > I have it left sleep all night and resumed without problems. It's not the time sleeping, is the time awake before you put it to sleep. > > > In 2.6.36, as soon as I plugged in/out the external display, X would > > reconfigure itself to the change, it is not automagic anymore. > > > > I'm using a DisplayPort to HDMI converter, I can try with VGA too if anyone > > needs it. > > I (have to) use the VGA port often, but I've never used the DisplayPort, so I > cannot comment on this. > > > but overall this series of patches are way better than before, congrats Jesse > > Yes! > > BTW, I have applied to the edp-2 the patches from > https://patchwork.kernel.org/patch/350841/ which enable vertical scrolling on > the Alps touchpad; they are working without issues so far. How did you applied them? I did and all it gives me is errors in dmesg of psmouse not syncing I'm on Fedora 14 with a Latitude E6510, and I'm not sure that the problem is resolved for me. I downloaded and compiled the edp-fixes-2 kernel from git, applied the touchpad patches (which work without a problem), but I still get a blank screen on the laptop monitor when booting. An external monitor works fine (DVI through a docking station) when using the intel driver in xorg.conf, however, I'm never able to get video on the laptop screen. I'm relatively new at compiling kernels (and didn't include any Fedora specific patches), but considering the mouse works when it previously didn't, I am fairly certain that I have done so correctly. I left mine on overnight, suspended, and resumed fine. (On previous kernels I used, resume usually worked, but sometimes didn't, no pattern.) Like others', it doesn't start driving an external monitor until I use gnome-display-properties. Everything seems to work in g-d-p (although it imposes infuriating placement choices). This is an e6510 w/1920x1080, i5, A03 bios, kernel and user-space both amd64, Debian Squeeze/unstable mix. (In reply to comment #214) > (In reply to comment #213) > > I have it left sleep all night and resumed without problems. > > It's not the time sleeping, is the time awake before you put it to sleep. Ah, ok - that makes sense. I will let you later on, since it as been on for most of the day now. > > > > BTW, I have applied to the edp-2 the patches from > > https://patchwork.kernel.org/patch/350841/ which enable vertical scrolling on > > the Alps touchpad; they are working without issues so far. > > How did you applied them? I did and all it gives me is errors in dmesg of > psmouse not syncing I actually applied them hand. No problems / warnings when compiling, and no problems booting. Maybe there are e6510 models with a different touchpad? > > > I have it left sleep all night and resumed without problems. > > > > It's not the time sleeping, is the time awake before you put it to sleep. > > Ah, ok - that makes sense. I will let you later on, since it as been on for > most of the day now. I tested today, I think that if you move the mouse or do something before it awakes completely, it stays black forever, but I'm not pretty sure of what I'm saying > > I actually applied them hand. No problems / warnings when compiling, and no > problems booting. Maybe there are e6510 models with a different touchpad? I reapplied them and now it works, I guess the problem was me patching a kernel at 3 am Can you confirm that things still work after removing the delays henk added to the panel on/off code? Just remove the msleep(300); call from panel_on and panel_off for testing... (In reply to comment #219) > Can you confirm that things still work after removing the delays henk added to > the panel on/off code? Just remove the msleep(300); call from panel_on and > panel_off for testing... perfectly, I didn't disable msleep on ironlake_edp_backlight_on, according to the comments, just in ironlake_edp_panel_off and ironlake_edp_panel_on Tempting fate here: I just pushed out a couple more patches to edp-fixes-2. The first removes the delays that should no longer be necessary, and the second tries to clean up the mode setting by using VDD AUX rather than full power sequences. It makes things look a little nicer on my Vaio at least... Please pull and give them a try. (In reply to comment #221) > Tempting fate here: I just pushed out a couple more patches to edp-fixes-2. > The first removes the delays that should no longer be necessary, and the second > tries to clean up the mode setting by using VDD AUX rather than full power > sequences. It makes things look a little nicer on my Vaio at least... Please > pull and give them a try. everything works perfectly (In reply to comment #221) > Tempting fate here: I just pushed out a couple more patches to edp-fixes-2. > The first removes the delays that should no longer be necessary, and the second > tries to clean up the mode setting by using VDD AUX rather than full power > sequences. It makes things look a little nicer on my Vaio at least... Please > pull and give them a try. It boots, it displays, it suspends, it resumes. Ok, one last request before we close this 6mo old bug: can you guys try ickle's drm-intel-next, staging, and fixes branches and confirm things still work? If not, can you identify the missing patches from my edp-fixes-2 branch and let ickle know? > (In reply to comment #221)
> > Tempting fate here: I just pushed out a couple more patches to edp-fixes-2.
> > ...
> It boots, it displays, it suspends, it resumes.
I spoke too soon. It doesn't unblank after an inactivity timeout.
Switching to fb console, and then plugging an external monitor,
wakes it up. Trying with 75ce6fo...
On Thu, 6 Jan 2011 15:09:02 -0800 (PST) bugzilla-daemon@freedesktop.org wrote: > https://bugs.freedesktop.org/show_bug.cgi?id=29278 > > --- Comment #225 from Nathan Myers <ncm@cantrip.org> 2011-01-06 15:08:59 PST --- > > (In reply to comment #221) > > > Tempting fate here: I just pushed out a couple more patches to edp-fixes-2. > > > ... > > It boots, it displays, it suspends, it resumes. > > I spoke too soon. It doesn't unblank after an inactivity timeout. > Switching to fb console, and then plugging an external monitor, > wakes it up. Trying with 75ce6fo... Yeah, I realized the dpms side was still messed up; I think I fixed it in edp-fixes-2 by overwriting the last patch... (In reply to comment #225) > I spoke too soon. It doesn't unblank after an inactivity timeout. > Switching to fb console, and then plugging an external monitor, > wakes it up. Trying with 75ce6fo... Yes, 75ce6fo does wake up correctly from inactivity blanking. (In reply to comment #224) > Ok, one last request before we close this 6mo old bug: can you guys try ickle's > drm-intel-next, staging, and fixes branches and confirm things still work? If > not, can you identify the missing patches from my edp-fixes-2 branch and let > ickle know? I don't understand. When I look at what I think is ickle's page, (http://cgit.freedesktop.org/~ickle/linux-2.6/) it shows the last commit in September last year. (In reply to comment #228) > I don't understand. When I look at what I think is ickle's page, > (http://cgit.freedesktop.org/~ickle/linux-2.6/) it shows the last commit > in September last year. ickel's tree is maintained on kernel.org now: git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel, as mentioned in http://intellinuxgraphics.org/download.html. (In reply to comment #224) > can you guys try ickle's > drm-intel-next, staging, and fixes branches and confirm things still work? If > not, can you identify the missing patches from my edp-fixes-2 branch and let > ickle know? Good news, bad news, and good news. The good news is, I can "make clean; make -j4" without overheating, now, under 75ce6fo. The bad news is, ickle's drm-intel-next 834ed55 gives a blank screen under all circumstances. The good news is ickle's drm-intel-staging d6b9705 boots, displays, suspends/resumes, and even wakes up after inactivity timeout. Git claims that -staging is identical to -fixes. had a downstream report from an e4310 user that edp-fixes-2 basically works but X is shifted horizontally about 300 pixels - see video: http://www.youtube.com/watch?v=u9TQFMEYK9E I have tried a kernel from the edb-fixes-2 branch, rev 73a1fe86 on my E6410. It works perfectly when undocked (boot, suspend). :) Thanks for that. But booting the notebook docked whith closed lid and an external monitor connected (DVI) to the dock, the boot process stops somewhere: Text screen visible, kernel modeset already done, no oops on the screen, does not react on keyboard or sysrq. :( (In reply to comment #232) I managed to capture some error messages: before the KMS happened: [ 7.006993] [drm:intel_dp_init] *ERROR* failed to retrieve link info after the KMS: [ 7.576680] [drm:intel_dp_init] *ERROR* failed to retrieve link info [ 10.092828] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting [ 12.146005] [drm:pch_irq_handler] *ERROR* PCH FDI RK interrupt: FDI RXA IIR: 0x00000000, FDI RXB IIR: 0x00000001 [ 13.773433] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting The messages before and after KMS are taken from different boots and are written down from 'screenshots'. Hope this helps. (In reply to comment #221) > Tempting fate here: I just pushed out a couple more patches to edp-fixes-2. > The first removes the delays that should no longer be necessary, and the second > tries to clean up the mode setting by using VDD AUX rather than full power > sequences. It makes things look a little nicer on my Vaio at least... Please > pull and give them a try. I have been working with it for half a day now and it seems to work without problems. Could not test connecting an external monitor / beamer yet. Maybe in three hours or so. (In reply to comment #230) > The good news is ickle's drm-intel-staging d6b9705 boots, > displays, suspends/resumes, and even wakes up after inactivity > timeout. > > Git claims that -staging is identical to -fixes. I have to admit that I did not have the time to learn thoroughly git's "way of life", and so I could I have made some mistake, but I get the same state in these three branches. The last commit from Jesse there is 834ed55b8, and after that there are two other commits (7511af860b1232a8a0a0df23b5750cab727fba18 - David Müller - and 1575415a08b6e5c959967cb79c0a7c16e7cf2625 - Yuanhan Liu). Do you get a different state? I have had a glitch when connecting an external (large) monitor. It is a 60 inches LG panel connected to the VGA port. My laptop had suspended and resumed several times (I am not sure whether this has any effect, but just in case). After connecting the panel I switched the output on with the Gnome monitor preferences tool, and set it to 1360 x 768 (the maximum resolution which appeared there). I started a movie with totem. Totem's display was black, then both displays (laptop and external) froze for a moment, then the X server died. I restarted the computer, connected, connected the output with Fn-8, and it worked. I will do some more experiments later on. Ok, so staging appears to resolve this particular issue, but we have a few others we can see now: - failure to set modes when booting docked (looks like DP training trouble) - offset image in X (modetest from libdrm might help narrow down whether it's an X or KMS problem) - totem failure on VGA attached screen So please file bugs for the above, or any other specific problems you find, and I'll close this one out. Thanks everyone for your patience, I know (trust me) how frustrating these bugs can be! (In reply to comment #237) > Ok, so staging appears to resolve this particular issue, but we have a few > others we can see now: > - failure to set modes when booting docked (looks like DP training trouble) > - offset image in X (modetest from libdrm might help narrow down whether it's > an X or KMS problem) > - totem failure on VGA attached screen > > So please file bugs for the above, or any other specific problems you find, and > I'll close this one out. > > Thanks everyone for your patience, I know (trust me) how frustrating these bugs > can be! I appreciate all the hard work everyone has done. I'm really new to bugs filed against the kernel, so I was hoping someone could inform me about typically where fixes like this end up. Is it going to be in a point release of either 2.6.36 or 2.7.x, or is it something that would typically be postponed until the next release, 2.6.38? I ask because I currently have kernel updates blacklisted on my laptop (Archlinux) and am just curious when it would be safe to remove the blacklist. Thanks again! > I appreciate all the hard work everyone has done. I'm really new to bugs filed
> against the kernel, so I was hoping someone could inform me about typically
> where fixes like this end up. Is it going to be in a point release of either
> 2.6.36 or 2.7.x, or is it something that would typically be postponed until the
> next release, 2.6.38?
>
> I ask because I currently have kernel updates blacklisted on my laptop
> (Archlinux) and am just curious when it would be safe to remove the blacklist.
The fixes should end up in 2.6.37.x and 2.6.38.
(In reply to comment #238) > > - totem failure on VGA attached screen I'll make further tests to see in which cases this arises. In experiments with earlier kernels (before this bug surfaced) I found that I could get Xvideo only when I had only one screen enabled. Should I be able to use it on one of two active screens? (In reply to comment #231) > had a downstream report from an e4310 user that edp-fixes-2 basically works but > X is shifted horizontally about 300 pixels - see video: > > http://www.youtube.com/watch?v=u9TQFMEYK9E I'm the downstream reporter - here is my updated comments for a Dell E4310 A final update: 1. I've re-installed Fedora 14 from scratch 2. I've installed Jesses edp-fixes-2 kernel 3. I've deleted xorg.conf (i.e the intel x driver is used - confirmed with compiz) Result: KMS works AND X works - this is contrary to the advice I presented earlier (and in my youtube upload) If I add the xorg.conf back - it loads the VESA driver, X has the "offset" when KMS is enabled and a stranger effect when nomodeset is set. Clearly this is a new bug and a new report should be logged. Just to close my comments out, the xorg.conf in question is: Section "Device" Identifier "Videocard0" Driver "vesa" EndSection Thanks for everyone's help in this matter, its been frustrating but we've come out with a good solution - thank you Adam for working closely on this both here and upstream. Of course thanks to Jesse as well! (In reply to comment #241) > In experiments with earlier kernels (before this bug surfaced) I found that I > could get Xvideo only when I had only one screen enabled. Should I be able to > use it on one of two active screens? If I understand you well, you mean projecting video on an external screen while doing something else in the laptop screen? If so, yes, you should be able. I alwas was able to do it. Note that I was not cloning - the external screen displays a region to the right of the internal one. I do not know if cloning makes any difference. jesse: the offset X display thing turns out to be a false alarm (user was actually using vesa when that happened). (In reply to comment #243) > (In reply to comment #241) > > In experiments with earlier kernels (before this bug surfaced) I found > > that I could get Xvideo only when I had only one screen enabled. > > Should I be able to use it on one of two active screens? > > If I understand you well, you mean projecting video on an external > screen while doing something else in the laptop screen? I mean using XVideo features, e.g. totem rendering a DVD movie. When I had two screens active, totem's viewing area remained black, regardless of which screen its window was on. Turning off either screen allowed totem's movie rendering to work normally. Is this expected behavior? (In reply to comment #245) > (In reply to comment #243) > > (In reply to comment #241) > > > In experiments with earlier kernels (before this bug surfaced) I found > > > that I could get Xvideo only when I had only one screen enabled. > > > Should I be able to use it on one of two active screens? > > > > If I understand you well, you mean projecting video on an external > > screen while doing something else in the laptop screen? > > I mean using XVideo features, e.g. totem rendering a DVD movie. > When I had two screens active, totem's viewing area remained black, > regardless of which screen its window was on. Turning off either > screen allowed totem's movie rendering to work normally. Is this > expected behavior? No. This is not what I experience. Actually that never happened to me, except once, the case I reported some messages ago. After rebooting my kids could watch a movie normally in an external screen while I was working in the main panel. (In reply to comment #232) > I have tried a kernel from the edb-fixes-2 branch, rev 73a1fe86 on my E6410. > > It works perfectly when undocked (boot, suspend). :) > Thanks for that. > > But booting the notebook docked whith closed lid and an external monitor > connected (DVI) to the dock, the boot process stops somewhere: Text screen > visible, kernel modeset already done, no oops on the screen, does not react on > keyboard or sysrq. :( These problems with an external display do not exist with a kernel build from the drm-intel-staging branch. Thanks a lot for your work!! I compiled the edp-fixes-2 branch on Fedora 14 on E6410. It boots fine, but when X is started I'm experiencing the shifted display problem. It's shifted to the left and up. When I tried switching to virtual console with Alt-F2 it completely froze. Then when I restarted I logged in and tried running the KDE compositing. It froze again. Should I open a new report for this or did I do something wrong? (In reply to comment #248) > I compiled the edp-fixes-2 branch on Fedora 14 on E6410. It boots fine, but > when X is started I'm experiencing the shifted display problem. It's shifted to > the left and up. When I tried switching to virtual console with Alt-F2 it > completely froze. Then when I restarted I logged in and tried running the KDE > compositing. It froze again. Should I open a new report for this or did I do > something wrong? Some other user reported that this was due to the use of the VESA driver instead of the intel one, due to a configuration file left behind by the installation. Can you check if there the file /etc/X11/xorg.conf exists? If so, just rename it to something else and try again. if you had to use "basic graphics mode" to install F14, as is likely, then this would have created an xorg.conf specifying the VESA driver. (In reply to comment #250) > if you had to use "basic graphics mode" to install F14, as is likely, then this > would have created an xorg.conf specifying the VESA driver. It also might have put an option /etc/grub.conf to disable dri too Thanks, I had removed the grub option, but forgot about the xorg.conf. Now it works like a charm, suspend works too, haven't tried anything else though. Thanks for a great job! (In reply to comment #247) > (In reply to comment #232) > > I have tried a kernel from the edb-fixes-2 branch, rev 73a1fe86 on my E6410. > > > > It works perfectly when undocked (boot, suspend). :) > > Thanks for that. > > > > But booting the notebook docked whith closed lid and an external monitor > > connected (DVI) to the dock, the boot process stops somewhere: Text screen > > visible, kernel modeset already done, no oops on the screen, does not react on > > keyboard or sysrq. :( > > These problems with an external display do not exist with a kernel build from > the drm-intel-staging branch. > > Thanks a lot for your work!! I've downloaded, complied and installed the drm-intel-staging branch on my Fedora 14 laptop, and I still boot to a blank screen when using the intel driver. The only way I am able to get a display on the monitor is to use the vesa driver and set nomodeset when booting the kernel. Can anyone with a working kernel on Fedora 14 post an RPM? > Can anyone with a working kernel on Fedora 14 post an RPM? http://koji.fedoraproject.org/koji/buildinfo?buildID=213137 That rawhide kernel works on Fedora 14 for me on a Dell e6410. You can revert to the old F-14 kernel with no issues if you have a problem. Just remember to remove the xorg.conf and entry in /etc/grub.conf (I removed that just for the .37-2 kernel Created attachment 41830 [details]
Screenshot of the error
I said sleep worked for me, but then I put it to sleep last night and woke it up today, but I got the F logo in the blue screen, like when the Plymouth is finished, so I guessed X crashed. Then I got a screenshot of the VT-1, where the X should have been running. I don't know where I could find the log, so I just attached the screenshot.
(In reply to comment #254) > > Can anyone with a working kernel on Fedora 14 post an RPM? > Does anyone have Ubuntu 10.10 x86_64 kernel in .deb format so I can test it on HP EliteBook 8440p with Intel graphic? I have the same problems as you have on Dell. I am using Glasen's Intel Graphic driver from here: https://launchpad.net/~glasen/+archive/intel-driver which got me some functionality that I didn't have with original Ubuntu drivers. (In reply to comment #253) > (In reply to comment #247) > > (In reply to comment #232) > > > I have tried a kernel from the edb-fixes-2 branch, rev 73a1fe86 on my E6410. > > > > > > It works perfectly when undocked (boot, suspend). :) > > > Thanks for that. > > > > > > But booting the notebook docked whith closed lid and an external monitor > > > connected (DVI) to the dock, the boot process stops somewhere: Text screen > > > visible, kernel modeset already done, no oops on the screen, does not react on > > > keyboard or sysrq. :( > > > > These problems with an external display do not exist with a kernel build from > > the drm-intel-staging branch. > > > > Thanks a lot for your work!! > > I've downloaded, complied and installed the drm-intel-staging branch on my > Fedora 14 laptop, and I still boot to a blank screen when using the intel > driver. The only way I am able to get a display on the monitor is to use the > vesa driver and set nomodeset when booting the kernel. > > Can anyone with a working kernel on Fedora 14 post an RPM? Sorry, I didn't make a RPM, I just installed it using make. (In reply to comment #254) > > Can anyone with a working kernel on Fedora 14 post an RPM? > > http://koji.fedoraproject.org/koji/buildinfo?buildID=213137 > > That rawhide kernel works on Fedora 14 for me on a Dell e6410. You can revert > to the old F-14 kernel with no issues if you have a problem. Just remember to > remove the xorg.conf and entry in /etc/grub.conf (I removed that just for the > .37-2 kernel I just tried this kernel, display works fine on an external monitor, however the panel in the laptop boots to a blank screen. I've tried adjusting the config with the monitor preferences utility without successes. The system thinks the monitor is turned on and active, but I never see any output. (In reply to comment #258) > (In reply to comment #254) > > > Can anyone with a working kernel on Fedora 14 post an RPM? > > > > http://koji.fedoraproject.org/koji/buildinfo?buildID=213137 > > > > That rawhide kernel works on Fedora 14 for me on a Dell e6410. You can revert > > to the old F-14 kernel with no issues if you have a problem. Just remember to > > remove the xorg.conf and entry in /etc/grub.conf (I removed that just for the > > .37-2 kernel > > I just tried this kernel, display works fine on an external monitor, however > the panel in the laptop boots to a blank screen. I've tried adjusting the > config with the monitor preferences utility without successes. The system > thinks the monitor is turned on and active, but I never see any output. If it helps, here is my Xorg.0.log: http://pastebin.com/5xzS0KyT it would be appropriate to move the support questions somewhere else; bugzilla is a bug tracker, not a support forum. note that the rawhide kernel under discussion only has one specific patch added - check-eDP-encoder-correctly-when-setting-modes.patch . It doesn't have all the other changes Jesse added to edp-fixes-2 recently. Some of those may also be necessary to fix some systems, I guess. I tested that just the single patch is sufficient to fix the Sony Vaio Z case, but I'm not sure anyone specifically checked it on any E6410 system. (In reply to comment #260) > it would be appropriate to move the support questions somewhere else; bugzilla > is a bug tracker, not a support forum. Yes. > note that the rawhide kernel under discussion only has one specific patch added > - check-eDP-encoder-correctly-when-setting-modes.patch . It doesn't have all > the other changes Jesse added to edp-fixes-2 recently. Some of those may also > be necessary to fix some systems, I guess. I tested that just the single patch > is sufficient to fix the Sony Vaio Z case, but I'm not sure anyone specifically > checked it on any E6410 system. My understanding is that E6410 systems have a different architecture and patches may not be interchangeable with those for E6510. There is a bug thread specific for the E6410. (In reply to comment #261) > > My understanding is that E6410 systems have a different architecture and > patches may not be interchangeable with those for E6510. There is a bug thread > specific for the E6410. I think the only difference is the panel. I have an E6410 and have been following this thread since the beginning. I've been a bit put off of testing because the time involved in compiling a kernel is huge. After doing it a few times I couldn't continue. Also, I haven't used git before and am not sure how to proceed there. If someone could give clear instructions on how to easily test on my Fedora 14 e6410, I'd be glad too. (In reply to comment #262) > (In reply to comment #261) > > > > My understanding is that E6410 systems have a different architecture and > > patches may not be interchangeable with those for E6510. There is a bug thread > > specific for the E6410. > > I think the only difference is the panel. I have an E6410 and have been > following this thread since the beginning. I've been a bit put off of testing > because the time involved in compiling a kernel is huge. After doing it a few > times I couldn't continue. Also, I haven't used git before and am not sure how > to proceed there. > > If someone could give clear instructions on how to easily test on my Fedora 14 > e6410, I'd be glad too. I second those exact same sentiments, but the difference is that I'm on Arch. If anyone can give me instructions to easily test on Arch that would be great, I'd like to do my part. Right now on Arch I'm using 2.6.35 which is working, though my card reader only works with 2.6.36 and above and since I do a lot of photography, this kernel update is especially important to me. (In reply to comment #263) > (In reply to comment #262) > > (In reply to comment #261) > > > > > > My understanding is that E6410 systems have a different architecture and > > > patches may not be interchangeable with those for E6510. There is a bug thread > > > specific for the E6410. > > > > I think the only difference is the panel. I have an E6410 and have been > > following this thread since the beginning. I've been a bit put off of testing > > because the time involved in compiling a kernel is huge. After doing it a few > > times I couldn't continue. Also, I haven't used git before and am not sure how > > to proceed there. > > > > If someone could give clear instructions on how to easily test on my Fedora 14 > > e6410, I'd be glad too. > > I second those exact same sentiments, but the difference is that I'm on Arch. > If anyone can give me instructions to easily test on Arch that would be great, > I'd like to do my part. Right now on Arch I'm using 2.6.35 which is working, > though my card reader only works with 2.6.36 and above and since I do a lot of > photography, this kernel update is especially important to me. I am not an Arch user, but I guess that the instructions at https://wiki.archlinux.org/index.php/Kernel_Compilation_From_Source should help. I bet every major distro has prepared a similar set of instructions. Using the edp-fixes-2 kernel on F14 sometimes when logging out from KDE and then logging back in I get a random display flickering. Like random rows move to sides quickly. This behavior starts right after logging out into KDM and continues until restart. Can anyone confirm this? It happens randomly. Running ickle's drm-intel-staging d6b9705, I have had my machine fail to wake up after dpms inactivity-timeout blanking. It has only happened once, so is not reproducible. The machine was entirely unresponsive, so I assume that the kernel or xserver panicked. There's no certainty that dpms was involved; it could have crashed any time before I came back, or when I tried to wake it up. The machine was quiescent while I was away from it. Since this bug is specifically about boot time blank screens, and is already huge, please open a new one for your dpms issue. It would be especially helpful if you could figure out a way to reproduce it reliably. If you do, please try it on my edp-fixes-2 branch as well. Thank you so much for doing this!! I've been following this thread since I bought E6510 last November. Could you point me to a support forum where I can get help on applying his fix. Is this a patch? I am running CentOS, and I am a newb :) THX! Thank you so much for doing this!! I've been following this thread since I bought E6510 last November. Could you point me to a support forum where I can get help on applying his fix. Is this a patch? I am running CentOS, and I am a newb :) THX! I see that 2.6.36.3 was released on 01/07. Does that kernel include the fix? I am not sure how to patch a kernel in Arch so I'm probably going to wait until the fix makes it in the code, but wanted to check with you guys before I try it. Does anyone know? Could someone put the fix into RPM please. I have the same problem on a e4310. 2.6.35 works but has periodic (every couple of seconds) screen blanks. 2.6.36 upwards does not work anymore. I tried the edp2-fixes branch, but it did not compile. CHK include/linux/version.h CHK include/generated/utsrelease.h CALL scripts/checksyscalls.sh CHK include/generated/compile.h CC drivers/gpu/drm/i915/intel_overlay.o drivers/gpu/drm/i915/intel_overlay.c: In function ‘intel_overlay_print_error_state’: drivers/gpu/drm/i915/intel_overlay.c:1467: error: implicit declaration of function ‘seq_printf’ make[4]: *** [drivers/gpu/drm/i915/intel_overlay.o] Error 1 make[3]: *** [drivers/gpu/drm/i915] Error 2 make[2]: *** [drivers/gpu/drm] Error 2 make[1]: *** [drivers/gpu] Error 2 Any idea? and will this be in 2.6.37.1 or 2.6.38? Thanks These two fixes are aimed at 2.6.37.x but they haven't landed yet.
> commit 37f809755845cc3e18e8216c04525bdb885fa13b
> Author: Jesse Barnes <jbarnes@virtuousgeek.org>
> Date: Wed Jan 5 14:45:24 2011 -0800
>
> drm/i915: make DP training try a little harder
>
> commit 858bc21f0637c407601a05626854ae58b242f75d
> Author: Jesse Barnes <jbarnes@virtuousgeek.org>
> Date: Tue Jan 4 10:46:49 2011 -0800
>
> drm/i915: check eDP encoder correctly when setting modes
And this fix is still in -next, it hasn't landed in Linus's tree yet:
commit f67a559daaa0e2ba616bfe9438f202bc57bc8c72
drm/i915: skip FDI & PCH enabling for DP_A
(In reply to comment #273) > These two fixes are aimed at 2.6.37.x but they haven't landed yet. 2.6.37.x when is it going to be out? How can I apply this patch on my own? I really do not want to wait. Thank you. Bugzilla is not a support forum. Please take requests for instructions on building kernels, requests for other people to build RPMs for you, and so on, somewhere more appropriate. (In reply to comment #275) > Bugzilla is not a support forum. Please take requests for instructions on > building kernels, requests for other people to build RPMs for you, and so on, > somewhere more appropriate. I also asked what is the good place to get help on applying this patch. which branch should I use now? I've used drm-intel-next and drm-intel-fixes thinking all the problems were fixed, but the nightmare is not over, any suggestions? Now my errors are kind of random, sometimes it's all ok, sometimes when I plug a second monitor, the laptop stays black with backlight on, sometimes if I suspend, then coming back on makes me reboot (sometimes reboot doesn't work, not even DELL boot logo comes up). Any ideas? (In reply to comment #276) > (In reply to comment #275) > > Bugzilla is not a support forum. Please take requests for instructions on > > building kernels, requests for other people to build RPMs for you, and so on, > > somewhere more appropriate. > > I also asked what is the good place to get help on applying this patch. I'm also running into problems with this. I think the base is wrong for applying the patch, as I always end up with conflicts. I guess a 'clone' and a 'pull' should suffice, but obviously I'm trying with the wrong clone. On which is the patch based? Where to clone it from? I also tried the drm-intel-staging (which is supposed to already have the patches) to no avail. I still have trouble putting my E6510 to sleep and waking it up properly. I often have a 1600x1200 display attached via display port (converted to DVI), so my Ubuntu 10.10 might automatically make adjustments to this after wakeup from suspend, even if no external display was attached since last boot (just a wild guess). Alfe I finally managed to try edp-fixes-2 (cloned it today, fully up-to-date) on my E6510, intel i5 CPU and intel graphics. I think the bug is still NOT properly fixed. During boot I get a couple of flickers on the screen, but the display stays turned on. Resuming from suspend does not work reliably at all. I can see something that looks like some boot errors (sometimes it's a broken pipe error, sometimes it's the message about the graphics turbo being disabled), the display brightness gets dimmed, it goes back up and then the display goes completely black most of the time (in fact it only turned on once). The only kernel that works reliably for me so far is 2.6.36, plus henk's patches, but as I mentioned before I had to increase the delays from 300 up to 900ms. This really works like a dream, no flickers at all and with reliable suspending and hibernation. (There is the occasional kernel panic about once a month though, but I think that's not a related issue). Resuming from suspend is also really fast, when the kernel from edp-fixes-2 tries to resume it takes quite a while. I suspect that the current fixes only work for some E6510 and not for others, probably due to different types of CPU. I guess this will become clear when more people try them, as far as I can see quite a number of people with an E6510 don't know how to compile kernels from git so maybe that's why nobody has reported this so far. I'd like to hear other people's experiences. I haven't reopened the bug yet but I think that's what we should do. this bug is for failure to initialize correctly at boot. It is *not* for problems when resuming from suspend. That is a completely different problem. Please file a separate bug for that (or see if one already exists, it may well). When reporting blank-screen-at-startup problems, it appears that the screen resolution matters. Please report screen resolution. Screen resolution is 1366x768, automatically set by Gnome, I can't even change it. I know resuming from suspend is different from blank screen at boot, but I reported here because the two issues seem to be closely related. Jesse, should I open a new bug or reopen this one? (In reply to comment #281) > When reporting blank-screen-at-startup problems, it appears that the screen > resolution matters. Please report screen resolution. I tried the edp-fixes-2 kernel again today. The display was NOT turned on after boot this time, so it seems that the current fixes only work sometimes. I am reopening this bug. (In reply to comment #282) > Screen resolution is 1366x768, automatically set by Gnome, I can't even change > it. > > I know resuming from suspend is different from blank screen at boot, but I > reported here because the two issues seem to be closely related. Jesse, should > I open a new bug or reopen this one? > > (In reply to comment #281) > > When reporting blank-screen-at-startup problems, it appears that the screen > > resolution matters. Please report screen resolution. On Mon, 24 Jan 2011 08:56:15 -0800 (PST) bugzilla-daemon@freedesktop.org wrote: > I tried the edp-fixes-2 kernel again today. The display was NOT turned on after > boot this time, so it seems that the current fixes only work sometimes. I am > reopening this bug. Please file a new bug instead; sounds like you have a different model than the one (primarily) reported in this bug. Also, edp-fixes-2 is deprecated, please try drm-intel-next instead. It should have all the same fixes plus a bunch more. The pipe/turbo error messages sound completely unrelated to this bug, so it's possible that something else is broken on your system or config that's causing problems (very possibly something else in the edp-fixes-2 kernel). I also tried ickle's drm-intel-fixes branch, it always boots to a black screen. I'll try drm-intel-next later today. My hardware is E6510, intel i5 CPU, intel graphics, so I thought this was the right bug. (In reply to comment #285) > Also, edp-fixes-2 is deprecated, please try drm-intel-next instead. It should > have all the same fixes plus a bunch more. > > The pipe/turbo error messages sound completely unrelated to this bug, so it's > possible that something else is broken on your system or config that's causing > problems (very possibly something else in the edp-fixes-2 kernel). I tried ickle's drm-intel-next. What I see during boot is certainly not what I'd expect, or what I get with the fix with the delays. The screen flickers, goes white, then I see the boot text instead of the OS's splash, the screen is turned on and off twice, but finally it comes on and I see the login screen. Resuming from suspend does not work at all. So the current fixes are optimal but by no means optimal. So far I haven't opened a new bug report since my hardware really seems to be the same as other people's here. (In reply to comment #286) > I also tried ickle's drm-intel-fixes branch, it always boots to a black screen. > I'll try drm-intel-next later today. > My hardware is E6510, intel i5 CPU, intel graphics, so I thought this was the > right bug. > > (In reply to comment #285) > > Also, edp-fixes-2 is deprecated, please try drm-intel-next instead. It should > > have all the same fixes plus a bunch more. > > > > The pipe/turbo error messages sound completely unrelated to this bug, so it's > > possible that something else is broken on your system or config that's causing > > problems (very possibly something else in the edp-fixes-2 kernel). Please do, this bug is full of enough noise already. Sounds like you have two bugs now: - suspend/resume doesn't work - lots of flicker at startup New bug reports: - resuming from suspend: https://bugs.freedesktop.org/show_bug.cgi?id=33439 - flicker during boot: https://bugs.freedesktop.org/show_bug.cgi?id=33442 (In reply to comment #288) > Please do, this bug is full of enough noise already. Sounds like you have two > bugs now: > - suspend/resume doesn't work > - lots of flicker at startup I am using also a DELL 6510. I had it docked when I installed linux. External monitor works great. However when I remove it from the docking station and trying to boot, its screen remains black when attempts to enter the desktop environment. Grub2 loader boots properly and the kernel selection menu appears. I have compiled and installed the 2.6.37 kernel because I thought the new patches related to the i915 would have fixed the black screen problem. During boot I get the following messages: [10.331196] intel ips 0000:00:1f.6: failed to get i915 symbols, graphics turbo disabled and a few seconds after: [26.229576] intel ips 0000:00:1f.6: i915 driver attached, reenabling gpu turbo Nevertheless, I get no visual at the login screen. Screen remains black no matter what I do. user-E6510:~$ dmesg | grep intel [ 3.033018] intel_idle: MWAIT substates: 0x1120 [ 3.033020] intel_idle: v0.4 model 0x25 [ 3.033021] intel_idle: lapic_timer_reliable_states 0xffffffff [ 3.034795] ACPI: acpi_idle yielding to intel_idle [ 10.331101] intel ips 0000:00:1f.6: CPU TDP doesn't match expected value (found 25, expected 29) [ 10.331112] intel ips 0000:00:1f.6: PCI INT C -> GSI 18 (level, low) -> IRQ 18 [ 10.331196] intel ips 0000:00:1f.6: failed to get i915 symbols, graphics turbo disabled [ 10.331347] intel ips 0000:00:1f.6: IPS driver initialized, MCP temp limit 90 [ 11.406722] agpgart-intel 0000:00:00.0: Intel HD Graphics Chipset [ 11.406809] agpgart-intel 0000:00:00.0: detected gtt size: 524288K total, 262144K mappable [ 11.407674] agpgart-intel 0000:00:00.0: detected 32768K stolen memory [ 11.429609] agpgart-intel 0000:00:00.0: AGP aperture is 256M @ 0xe0000000 [ 20.695642] fb0: inteldrmfb frame buffer device [ 26.229576] intel ips 0000:00:1f.6: i915 driver attached, reenabling gpu turbo lefteris@lefteris-E6510:~$ uname -a Linux lefteris-E6510 2.6.37 #6 SMP Mon Jan 17 11:39:37 CET 2011 i686 GNU/Linux lefteris@lefteris-E6510:~$ lspci | grep Intel 00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 02) 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) Hope I am not missing something here and I hope this post also helped a bit. The git repository from jbarnes seems to fix my black screen on my E6510, even standby/resume works. It only seems to break dual display (xrandr --output DP1 --right-of HDMI3 --primary) which does a "clone" output using edp-fixes-2. I think you should open a new bug for the dual screen issues (and maybe post the link to the new bug here). I can't try dual screen right now because I'm travelling, but I will when I'm back home next month. (In reply to comment #291) > The git repository from jbarnes seems to fix my black screen on my E6510, even > standby/resume works. It only seems to break dual display (xrandr --output DP1 > --right-of HDMI3 --primary) which does a "clone" output using edp-fixes-2. can somebody please tell if the patches are integrated in an installable iso image from ubuntu/fedora/suse ? it could be a nightly build. i think i have to wait some weeks until i can install linux without working around the package management and compile a kernel for myself. since a half year i try to work with windows on my E6510 :( (In reply to comment #293) > can somebody please tell if the patches are integrated in an installable iso > image from ubuntu/fedora/suse ? it could be a nightly build. i think i have to > wait some weeks until i can install linux without working around the package > management and compile a kernel for myself. since a half year i try to work > with windows on my E6510 :( 2.6.38-rc2 works for me, it should be in Fedora 15 rawhide, haven't tried though. Only sometiemes X server crashes and touchpad doesn't support scrolling. This bug is not yet fixed on Dell Latitude E6510. Apparently developers got regression reports so they kept from sending the eDP patches to Linus. Should the bug be reopened until the patch is upstream? Or is it enough that it will go then to I guess 2.6.39 kernel? Note that E6410 has a slightly different problem from what I've been reported about, and this bug was originally / is about E6510. Mainline kernels don't work, including latest in Ubuntu 11.04 development version, while drm-intel-next kernels do work. f67a559daaa0e2ba616bfe9438f202bc57bc8c72 from drm-intel-next is needed to get boot working. 37f809755845cc3e18e8216c04525bdb885fa13b is also needed for suspend/resume. Created attachment 43401 [details] [review] skip FDI/PCH enabling backported to 2.6.38-rc4 Try this against Linus's tree, it's working here for me. (In reply to comment #297) > Created an attachment (id=43401) [details] > skip FDI/PCH enabling backported to 2.6.38-rc4 > > Try this against Linus's tree, it's working here for me. I have pushed test kernels for Ubuntu with this patch applied, details are at the URL below: https://bugs.launchpad.net/linux/+bug/561802/comments/199 Please test if you have the hardware. (In reply to comment #297) > Created an attachment (id=43401) [details] > skip FDI/PCH enabling backported to 2.6.38-rc4 > > Try this against Linus's tree, it's working here for me. It's working for me too. Thanks Jesse! > skip FDI/PCH enabling backported to 2.6.38-rc4
I compiled and gave a kernel with this patch only to two users, and they reported success.
They don't have a working suspend-resume, though, but if this patch should fix that too, I believe their problem is only because they've older userland.
(In reply to comment #297) > Created an attachment (id=43401) [details] > skip FDI/PCH enabling backported to 2.6.38-rc4 > > Try this against Linus's tree, it's working here for me. I have patched a 2.6.36-rc5 (from Linus' tree) and it's working for me (E6510, Full HD, 32 bits). Plus: suspend / resume is working, and output to VGA is working (external monitor automatically detected at max. resolution [1680x1050 in this case], and Fn+F8 cycles between monitor on the side - cloning - external monitor off [note that this went through some unstable moments in the drm-intel-next kernels]). I think is the best combination I have tested since J. Barnes branch in drm-intel-next -- thanks, Jesse and everyone else! > > skip FDI/PCH enabling backported to 2.6.38-rc4
I also have some positive testing results using this patch. Is this planned for 2.6.38 final?
> They don't have a working suspend-resume, though, but if this patch should fix
> that too, I believe their problem is only because they've older userland.
Correction here. Actually when not using my own kernel (possibly not perfectly compiled...) but that one from Canonical with the same patch, one E6410 user and one E6510 user reported working suspend/resume while one E6510 user still had some problem.
Hi I have still issues with this problen on my Gentoo system with kernel 2.6.37. Xorg log is fine, systems works otherwise (LAN, ...). Even when I attach a 2nd screen via Docking Station/DVI the 2nd screen comes up and works. But the Laptop pannel stays blank (just backlight is on). When I compile intel graphics for the 2.6.37 kernel as a module, then the pannel display stays up and ok until udev starts to load modules. The fix which introduces the additional delays for pannel initialization work perfectly for a 2.6.36 kernel, even with console decorations activated, but not for 2.6.37. (In reply to comment #304) > Hi I have still issues with this problen on my Gentoo system with kernel > 2.6.37. > > Xorg log is fine, systems works otherwise (LAN, ...). Even when I attach a 2nd > screen via Docking Station/DVI the 2nd screen comes up and works. But the > Laptop pannel stays blank (just backlight is on). > > When I compile intel graphics for the 2.6.37 kernel as a module, then the > pannel display stays up and ok until udev starts to load modules. > > The fix which introduces the additional delays for pannel initialization work > perfectly for a 2.6.36 kernel, even with console decorations activated, but not > for 2.6.37. Hi. If you have recently removed hal make sure to follow this exactly: http://forums.gentoo.org/viewtopic-t-858965.html If you have already done that then try a new .config (don't import existing ones, this was problematic) from pappy on 2.6.37.1 or 2.6.38 This fixed it for me. For some reason the vanilla 2.6.37 was a little buggy. I just built "v2.6.37.1" (g638) pulled from GKH's tree on my Dell E6510 i5 1920x1080. It comes up with a black backlit screen. Plugging in an external monitor, I can get a desktop there by switching between X and text console, but nothing I do (change brightness, unplug monitor, suspend/resume) activates the built-in screen. An earlier build based on 2.6.37-rc8 (g1a7ed43) works more or less OK. Arg the bug that won't die. Not all of the fixes are in 2.6.37.1, but they are upstream in drm-intel-next and will appear in 2.6.39 and wherever else people choose to backport the fixes. So. If you're having trouble with drm-intel-next, please file new bugs and they're almost certainly different problems than the ones associated with this bug (updating the summary to reflect that). Unfortunately this bug also had reports of suspend/resume and other issues that were also fixed, but it's just too much of a monster to bother with now. If you're having trouble with a stable kernel, point your distro at drm-intel-next to get things backported (Ubuntu for example has already done this). I posted in comment #164 that this was working with henk's reversed patch. And it was. I decided to upgrade my kernel and Xorg. So now I'm back to a blank screen again, just as before. :( This is with a e6410 with a i5 and ironlake graphics. Kernel 2.6.39, Xorg-server 10.1, Xf86-video-intel 2.15.0. I'll see if there's a new bug to report under before reopening this one. Also tried the module from drm-intel-next, same problem, black screen on the e6410. So then I tried 2.6.38.7 and all is well. The bugs I found listed for the e6410 and this problem have been closed as duplicates of this bug, so this bug should be reopened or a new one started. I'm happy with 2.6.38.7 so maybe someone else would want to to that. |
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.