Created attachment 52789 [details] X logs I'm currently trying to put linux on dell vostro 360 . It's fitted with Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz , and lspci shows 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) The issues it that as KMS starts up, the display goes blank. The system works, i can ssh into it. X11 driver does not bring the display up. Booting with nomodeset helps. I tested with most recent opensuse 11.4 kernel ( ~2.6.37.6) , also most recent 3.0 and most recent 3.1 (stable) kernels from arch linux. Also, most live distributions fail in the same way. Tested with fedora16 beta and recent archlinux. Systems without KMS drivers (opensuse 11.4 graphical installer, using vesa driver) work fine. 3.1 kernel spams dmesg with =============================================== [ 602.041127] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting [ 602.471030] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting [ 602.900936] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting [ 603.330855] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting [ 603.760647] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting (....) =============================================== I'll provide any info as necessary. i'll attach Xorg.0.log (trying to launch login manager remotely) and dmesg
Created attachment 52790 [details] dmesg output
Could you try the patches from the drm-intel-next branch, at http://cgit.freedesktop.org/~keithp/linux/log/?h=drm-intel-next ?
Also please boot your kernel with drm.debug=0xe added to your kernel bootline and attach the complete dmesg.
the old errors are gone, something new appeared now attaching dmesg.
Created attachment 52793 [details] dmesg from drm-intel-next boot i reused default archlinux config to save time. kernel versioned itself as 3.1.0-rc6-ARCH-g82d1655
i forgot to mention - still no display.
Please try drm-intel-next branch and make sure you set the kernel option drm.debug=0x0e so that we get the necessary debug messages in the kernel log.
retested i got the right kernel, it's drm-intel-next @ commit 82d165557ef094d4b4dfc05871aee618ec7102b0 Author: Adam Jackson <ajax@redhat.com> Date: Fri Oct 14 17:22:26 2011 -0400 drm/i915/dp: Fix eDP on PCH DP on CPT/PPT According to the gen6 docs, only the DP_A port (on-CPU eDP) still uses the old IBX bit shift for the link training pattern setup bits. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Keith Packard <keithp@keithp.com> rebooted with necessary debug parameters, attaching dmesg. it seems to loop after a minute or so, so i cut it to two minutes.
Created attachment 52802 [details] dmesg from intel-drm-next boot with extra debug param
it seems that dmesg i posted has only last couple of messages, so i dig out entire kernel log from boot time, that should be more complete.
yeah, looks like the dmesg ring lost the interesting boot-time bits due to the looping. Any way you can capture the dmesg soon enough after boot to get the startup sequence?
Created attachment 52803 [details] more complete dmesg
I'm attaching a new kernel log from drm-intel-next @ 9ca1d10d748e56964de95e3ed80211b192f56cf4
Created attachment 53281 [details] kernel log from intel-drm-next@9ca1d10d748e56964de95e3ed80211b192f56cf4
the messages that start at ~15 second mark start repeating in the log unchanged every second, so i cut it short.
I am interested in the bug. Same setup here. Exactly the same problem.
About this Issue i found another interesting thing: Dell named their Monitor 23" AIO! root@daphixterminal1:~# hwinfo --monitor 25: None 00.0: 10002 LCD Monitor [Created at monitor.95] Unique ID: rdCR.KZw2Np07sk4 Hardware Class: monitor Model: "23" AIO" Vendor: CHR Device: eisa 0x0608 "23" AIO" Resolution: 1920x1080@60Hz Size: 509x286 mm This results in a wrong xorg.conf: Section "Monitor" ModelName "23" AIO" You will get an error when you try to start....
i'm experiencing weird behavior on currrent intel-drm-next git KMS kicks in and it works during boot, but something goes wrong few seconds later. screen goes black, and seems to "flicker". it looks like the backlight alternates between different states or screen powers on and off constantly. i can catch a brief glimpse of console output once in a while. i'm attaching a new log in a minute.
Created attachment 53631 [details] boot log from drm-intel-next@9a10f401a401ca69c6537641c8fc0d6b57b5aee8
btw, external d-sub display works correctly - i plugged it in after system has booted to figure out the ip address and grab the logs.
I face the same problem. Black screen on Vostro 360 when using i915 driver (ubuntu 11.10). I am currently working around using vesa driver however this is quite bad as the max resolution is 1280x1024 instead of the usual 1080p. Is there anything I can provide or do to help fix this issue?
@Paulo , you could try building the drm-intel-next branch of the kernel from git://people.freedesktop.org/~keithp/linux and running it on your machine. i'm not going to have access to vostro 360 for a couple of days, maybe i have it again in my hands next week - just to keep testing perpetual as new commits roll in would help.
i've got a hold of another vostro 360, and tested drm-intel-fixes. after booting display is fine for a couple of seconds, and then it starts to turn on and off. i can see console output for a ~0.5 second, it reinitializes, shows up for ~0.5 second and the process repeats. attaching log from drm-intel-fixes@5be93ad2ebb975df8ba01f6c76b541ff4e9929f4 the problem starts at 15 seconds mark. up to this point KMS is working fine.
Created attachment 53995 [details] drm-intel-fixes@5be93ad2ebb975df8ba01f6c76b541ff4e9929f4 boot log
Created attachment 53996 [details] drm-intel-fixes@5be93ad2ebb975df8ba01f6c76b541ff4e9929f4 boot log resending in text/plain, for convenience
retested on drm-intel-fixes @ 89c488d29811e220eb29af5c8babc36963cbbc7a things are basically the same. i also updated 360's bios from A02 to A04, but that changed nothing. behavior is exactly the same.
is there any other way i can provide extra information besided testing subsequent git commits against the hardware ?
attaching log from drm-intel-next@097354eb14fa94d31a09c64d640643f58e4a5a9a behavior is similar on drm-intel-fixes at current head. i also tested semaphore parameter, which does nothing in this case.
Created attachment 54592 [details] boot log from drm-intel-next@097354eb14fa94d31a09c64d640643f58e4a5a9a
I also have this problem with a Vostro 360. X logs for Ubuntu 11.10 (i386 but same issue for amd64): 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) I will attach a kernel and Xorg dump. The only way for me to have correct resolution (1920x1080) was in using the Live CDROM of Ubuntu Maverick 10.10 which use: - kernel 2.6.35-22-generic - xserver-xorg-video-intel 2.12.0-1ubuntu5 ... but once the system installed, the black screen problem come back. I can't actually undestand the difference between the live OS and the installed one (after the installation, the kernel is slightly different; but after installing exactly the same than the one used in the live CD, the problem persist). I also tried other Ubuntu release, even the latest Ubuntu 12.04 precise (alpha version): same issue. Booting with nomodeset helps also, but lead to a low resolution.
Created attachment 55168 [details] Logs of kernel, Xorg and lspci on Ubuntu oneiric
@Jerome - interesting. did you boot the cd normally or with a safe video mode option ? is the resolution correct in live environment? i'll retest on my 360 unit with that live media in a few hours.
unfortunately, i cannot reproduce a correct boot with ubuntu 10.10 on my 360 unit. the 10.10 media has 2.6.35-22-generic kernel, as in your example. display goes black every time. booting with nomodeset makes X fail to work completely.
Hi, Well another Live distribution that work every time correctly for me is the elementary OS: - ISO used: elementaryos0.1-jupiter-amd64.iso - Web site: http://elementaryos.org/ This Live CD is based also on Ubuntu Maverick AMD64 and use: - linux-headers-2.6.35-28-generic 2.6.35-28.49 - xserver-xorg-video-intel 2:2.12.0-1ubuntu5.2 I don't understand why this live cd work and i can't manage the OS to work once installed...
Hi, Well another Live distribution that work every time correctly for me is the elementary OS: - ISO used: elementaryos0.1-jupiter-amd64.iso - Web site: http://elementaryos.org/ This Live CD is based also on Ubuntu Maverick AMD64 and use: - linux-headers-2.6.35-28-generic 2.6.35-28.49 - xserver-xorg-video-intel 2:2.12.0-1ubuntu5.2 I don't understand why this live cd work and i can't manage the OS to work once installed... PS: i did not specify any option at the boot time.
i still get a no display with elementary os. @Jerome, i think that's because you have slightly different cpu than one in mine. i have i3-2100 in all 360's i tried, your logs show i3-2120. They probably have a little different hd graphics cores, as well.
Hi, I'm coming back. Even with the Intel driver 2.17.0 and latest kernel 3.2.0-9, the problem is still present. What can i do to help ?
Created attachment 56180 [details] [review] fixup dp bpc calculations Can you please try this kernel patch?
didn't help for me. attaching boot log from current drm-intel-next-fixes with the patch applied on top.
Created attachment 56214 [details] boot log from drm-intel-fixes-next@ 6a8197121146cdad0ceb6d639676965aaffcb69a + patch
just to clarify - the KMS part works fine, for a few seconds from boot. after a short while (usually ~5 seconds after KMS changes the display resolution) display starts constantly resetting itself, going on and off, occasionally displaying output for a split second. this behavior is consistent - i've experienced it on all vostro 360 units i tested.
Patch also doesn't work in my case. Exactly same behaviour for the display. My dmesg output in attachment.
Created attachment 56328 [details] boot log with intel_dp_link_required patch applied (from comment 56180)
Hi, Yesterday I turned my Vostro 360 on again after two months on hiatus due to a quite convoluted house move. I see there are no changes to the status of the problem with the vostro, it's still a no no for linux. I am wondering if someone actually knows what the problem is with the vostro card such that it is not working or if we are just trying patches as they come out in the hope that one will fix it. Also, if I can do anything to help (including testing patches), pls let me know.
Ok so you both see the kernel log during boot (if you remove the 'quiet' boot option) but when X starts the display goes blank and doesn't come back? Or it flickers on and off? Would it be possible for you to disable gdm or lightdm, login with the console working and get a register dump using "intel_reg_dumper", then start gdm/lightdm and get another dump using ssh? We must be shutting off the panel or backlight when starting X, or otherwise breaking the eDP config. Unfortunately, I don't have an SNB eDP system to test with, but Keith does so he may be able to help too.
Oh forgot to ask the most annoying question: does this still happen on the drm-intel-next branch of Daniel's tree at git://people.freedesktop.org/~danvet/drm-intel.git?
in my case i didn't use X, except for brief testing. X or not, the display starts turning itself on and off, with occasional glimpse of console. logs were gathered without X or any login managers running. boot is as follows - standard kernel bootup, KMS kicks in and sets proper resolution. few seconds later display goes black as if powered down. turns itself on, goes blank etc. sometimes console output flashes for split second on screen. from what i can see backlight also switches on and off, as display doesn't just go blank - it goes black as when it's powered down. this continues unchanged when X is started. although X logs don't show anything useful. external display (unit has d-sub) works without glitches, when connected. i don't currently have the hardware around, when i get my hands on next batch of 360s, i'll test again.
Does http://lists.freedesktop.org/archives/intel-gfx/2012-April/016230.html help at all?
i don't think i've tested this one. i followed keith's drm-intel-next git trees, and didn't notice the more up to date drm-intel tree at http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-fixes until yesterday. if i get the hardware i'll test this.
Hello all, I have just tested a Vostro 360 with drm-intel-fixes@c291be9dba370ba696a0d482249a212cf5c15f45 from ~danvet/drm-intel. The behavior with KMS (nomodeset disabled) is slightly different. Now, backlight is switching from "almost black" (very dark) to "black" (darkest) every 1 second (fixed rate). No more randomly "short backlighting" as with 3.2. I give you: - kernel dmesg logs with drm.debug=0x0e - intel_reg_dumper output - Intel bios video dump (generated with intel-gpu-tools 1.1.0 release since 1.0.2 is broken) Hardware type is a DELL Vostro 360 with "Intel(R) Core(TM) i5-2400S CPU @ 2.50GHz" cpu and Video controller is "00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0102] (rev 09)". OS is an Ubuntu 11.10. Please let me know if I can provide any other useful info. Thanks in advance.
Created attachment 60258 [details] Kernel dmesg log with drm-intel-fixes@c291be9dba370ba696a0d482249a212cf5c15f45
Created attachment 60259 [details] Vostro 360 intel video register with drm-intel-fixes@c291be9dba370ba696a0d482249a212cf5c15f45
Created attachment 60260 [details] Vostro 360 intel video BIOS dump with drm-intel-fixes@c291be9dba370ba696a0d482249a212cf5c15f45
*** Bug 44898 has been marked as a duplicate of this bug. ***
Going out on a limb and associating these two bugs. Can one of you get the output from /sys/kernel/debug/dri/0/i915_gem_interrupt? You may need to capture it a few times to get the output I'm looking for, specifically what the "South Display Interrupt identity" field is when the hotplug occurs. I'm guessing bit 23, 22, or 21 is stuck on, but it could be one of the others. After you've gathered that, you could try this patch, which ought to shut up your hotplug interrupts at least: diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 967b92e..9b6d8ac 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -2106,6 +2106,8 @@ static int ironlake_irq_postinstall(struct drm_device *dev SDE_AUX_MASK); } + hotplug_mask = 0; + dev_priv->pch_irq_mask = ~hotplug_mask; I915_WRITE(SDEIIR, I915_READ(SDEIIR)); *** This bug has been marked as a duplicate of bug 42278 ***
The duped bug #44898 reporter said that his display works when adding drm_kms_helper.poll=0 on the kernel command line. Can you please test this?
Hello and thanks for your help. First, the output of /sys/kernel/debug/dri/0/i915_gem_interrupt is stable (except the number of received interrupts ;) ) I tried "drm_kms_helper.poll=0" option and it worked like duplicate #44898. Btw, I can confirm it works: - without applying the i915_irq.c latest patch - on a previous kernel (linux-image-3.2.0-17-generic package on Ubuntu) The startup problem is also there. How can we help more?
Created attachment 60306 [details] /sys/kernel/debug/dri/0/i915_gem_interrupt output on drm-intel-fixes@c291be9dba370ba696a0d482249a212cf5c15f45
The following register dumps might help: 1. after a lightdm restart, no more backlight 2. subsequent reboot, no backlight after starting 3. on (2) session, after lightdm restart, backlight is back I made a few reg dump for each state but they are all the same for a same state.
Created attachment 60509 [details] 1. after a lightdm restart, no more backlight
Created attachment 60510 [details] 2. subsequent reboot, no backlight after starting
Created attachment 60511 [details] 3. on (2) session, after lightdm restart, backlight is back
Hi. I've a Dell Inspiron 2310 All In One and it presents the same issues as described in this bug. Here is a bug to the kernel site: https://bugzilla.kernel.org/show_bug.cgi?id=43181 and to Ubuntu Launchpad: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/912397 I'm running Linux ubudell 3.2.0-24-generic #37-Ubuntu SMP Wed Apr 25 08:43:22 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux And Edgers PPA enabled. Hope it helps.
It's working if I turn on the PC (I mean no reboot) and start with only "drm_kms_help.poll=0". If I reboot, the screen starts to turn on and off.
Sorry: the param is "drm_kms_helper.poll=0"
Hm, I'm confused: Is this bug here and the one on the kernel bugzilla about the same machine and problem? https://bugzilla.kernel.org/process_bug.cgi
Ok, Gustavo is not the original reporter here. Gustavo, please do not cross-post on multiple bugzilla's. There's a really big chance that your bug is a different one than this one. Thanks.
I just got a vostro 360 to check this one out. I can confirm that the 3.3 kernel included in the Ubuntu 12.04 install doesn't work well; the panel flickers at boot and never syncs to an image (though occasionally you can see a flash of the desktop or boot loader). Trying the latest kernel now, if it still happens there I should be able to debug and fix things.
Created attachment 62301 [details] [review] keep HDMID off the eDP port There are a few issues here, but this seems to be the big one. When HDMID is enumerated on the eDP port, any call to its ->detect hook will use the GMBUS pins shared by DP, and potentially cause panel trouble.
Many thanks Jesse, Will take a look as soon as possible when get a hand on another Vostro.
Created attachment 62598 [details] [review] cache the EDID on eDP panels This one fixes the flicker that occurs at detect time. With both patches (the HDMID one and this one) the Vostro is behaving like it should.
commit 46c325a871d50096b312e0f7f48182f2152ee836 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Mon Jun 11 14:39:56 2012 -0400 drm/i915: don't enumerate HDMID if an eDP panel is already active on the por there's another patch for #46856 which also affects my Vostro, that one should be going in shortly.
A patch referencing this bug report has been merged in Linux v3.5-rc4: commit b708a1d5ea7880b399dbd45cacafff6ae8d73171 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Mon Jun 11 14:39:56 2012 -0400 drm/i915: don't enumerate HDMID if an eDP panel is already active on the port
I still have issues with kernel v3.5rc6 on vostro 360. It looks like everything is ok, when the computer is being powered on and is starting (then it goes to KDE ok). I don't have to use drm_kms_poll.helper=0 parameter in the grub. But as soon as I restart/reboot, the screen goes black. It seems that for some reason the screen behaves differently when it's powered on, and when it's just rebooted.. Tested on 5 different vostro 360 computers with Fedora 16/17 and kernel 3.5 rc5/rc6 Please confirm the same behavior.
In 3.7, Daniel landed the modeset-rework, which fixes a number of eDP related issues; please test.
Ping, any update on testing the latest bits?
(In reply to comment #74) > I still have issues with kernel v3.5rc6 on vostro 360. It looks like > everything is ok, when the computer is being powered on and is starting > (then it goes to KDE ok). I don't have to use drm_kms_poll.helper=0 > parameter in the grub. But as soon as I restart/reboot, the screen goes > black. It seems that for some reason the screen behaves differently when > it's powered on, and when it's just rebooted.. > > Tested on 5 different vostro 360 computers with Fedora 16/17 and kernel 3.5 > rc5/rc6 > > Please confirm the same behavior. I've just got another 360 unit and i have no problems whatsoever when using vanilla 3.6.6 kernel build on opensuse 12.2, with no i915-related boot parameters. i also tried systemrescuecd 3.1.1 livecd with "alternative kernel" boot option which boots into 3.6.4 instead of default 3.2.x kernel that this media offers. That unit, as previous ones i tried, has i3-2120 cpu. The video chip is identified as "Dell Device 0512"; with lspci -n showing it as 8086:0102 (rev 09) . Can you try using systemrescuecd media and boot into alternative kernel menu option?
*fingers closed that this was indeed resolved in 3.6 Please do take this opportunity to test and reopen the bug if we still fail to light up the 360 correctly.
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.