Bug 639146 - KMS initialization fails on various eDP Dell laptops
Summary: KMS initialization fails on various eDP Dell laptops
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel
Version: 14
Hardware: x86_64
OS: Linux
low
high
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: https://fedoraproject.org/wiki/Common...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-09-30 22:29 UTC by Keith Amidon
Modified: 2018-04-11 08:26 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-16 21:44:41 UTC


Attachments (Terms of Use)
Smolt profile (7.20 KB, text/plain)
2010-09-30 22:29 UTC, Keith Amidon
no flags Details
dmesg output (blank screen after KMS enabled) (55.68 KB, text/plain)
2010-10-09 11:56 UTC, SJM
no flags Details
system log (blank screen after KMS enabled) (70.61 KB, text/plain)
2010-10-09 11:57 UTC, SJM
no flags Details
Xorg.log (blank screen after KMS enabled) (70.75 KB, text/plain)
2010-10-09 11:58 UTC, SJM
no flags Details
smoltprofle for Dell E4310 (6.79 KB, text/plain)
2010-10-09 12:01 UTC, SJM
no flags Details

Description Keith Amidon 2010-09-30 22:29:58 UTC
Created attachment 450900 [details]
Smolt profile

Description of problem:

On a Dell Lattitude E6510 when switching to KMS during boot the display panel on the laptop goes blank (black) with the backlight still on and stays that way.


Version-Release number of selected component (if applicable):

Fedora gaphics test-day live-cd image.

How reproducible:

On every boot.

Steps to Reproduce:
1. Boot from livecd with default options
  
Actual results:

Screen goes blank when switching to KMS and stays that way.

Expected results:

Continued visibility of boot progress and eventually a switch to X with the login manager.

Additional info:

I believe this is related to this bug filed at freedesktop.org:

    https://bugs.freedesktop.org/show_bug.cgi?id=29141

It may also be related to this reported Fedora bug:

    https://bugzilla.redhat.com/show_bug.cgi?id=596557

I will upload the log files and intel registers shortly after rebooting with the additional debugging parameters.

Comment 1 Keith Amidon 2010-09-30 23:22:34 UTC
I can't add the kernel dmesg logs with debugging enabled, during the failure because I haven't identified a way to log into the system remotely after the display fails when using the livecd.  I'm unfortunately unable to install to the machine at this time.

Comment 2 SJM 2010-10-07 09:28:03 UTC
I have the exact same issue on the Fedora 14 beta, intel graphics on a dell E4310.

- With modern dell Latitude notebooks (E4310; E6510 etc) with Intel graphics (and perhaps the specific type of panel) there is no display after KMS kicks in during boot. 

- This applies to later kernels included in Fedora 13 as well: See bug 629547

- For Fedora 14 beta, selecting "basic video" / or similar during booting the liveCD gives a full X session with the VESA driver.

- After installation your fresh install will have the same problem, the current workaround is to be with these parameters: xdriver=vesa nomodeset 

- The last known kernel to work is: 2.6.33.8-149.fc13.i686.PAE

Keith - this is a serious issue, my previous bug has not gained enough attention.
If you can try the above, you will at least get a graphical display, after which you can follow the recommendations for bug reporting here for bug reporting: http://fedoraproject.org/wiki/Xorg/Debugging#KMS-related_issues

I suggest you first boot with xdriver=vesa nomodeset and configure your system/network and enable ssh so you can log in remotely, then remove xdriver=vesa nomodeset and reboot to the blank screenm, hopefully you will be able to ssh in and paste some logs, I shall do the same shortly

This appears to be a problem with the intel driver in newer kernels.

Comment 3 Erik van Pienbroek 2010-10-07 21:56:53 UTC
I'm also encountering this bug on a Dell Latitude E6500. For now the only way to get the internal display working is by booting F13's 2.6.33 kernel.

Perhaps this bug can be nominated as a F14-Blocker?

Comment 4 Adam Williamson 2010-10-08 16:18:27 UTC
We discussed this at the 2010-10-08 blocker review meeting and agreed that it constitutes a blocker given the popularity of the affected hardware (we have 128 e6510s in smolt, 537 e6500s, 21 e4310s).

We really need the detailed logs mcepl requested, from as many of you as possible, as soon as possible. Thanks!

Comment 5 Matěj Cepl 2010-10-08 16:41:02 UTC
For everybody affected by this issue. Please add drm.debug=0x04 to the kernel command line, restart computer, and attach

* your X server config file (/etc/X11/xorg.conf, if available),
* X server log file (/var/log/Xorg.*.log)
* output of the dmesg command, and
* system log (/var/log/messages)

to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Comment 6 Erik van Pienbroek 2010-10-08 16:48:23 UTC
Unfortunately I don't have access to the notebook in question at the moment, so I'm unable to provide additional debug information for the next couple of days..

Comment 7 R P Herrold 2010-10-08 17:42:22 UTC
As to comment 2, the 'unable to harvest results' off a live CD boot:   I put together a small script take the inventory, and then to email results off a laptop I could no longer log into for #640421  -- If you want a copy so you might gather the requested items, please 'ping me'

-- Russ herrold

Comment 8 SJM 2010-10-09 11:56:22 UTC
Created attachment 452498 [details]
dmesg output (blank screen after KMS enabled)

Comment 9 SJM 2010-10-09 11:57:31 UTC
Created attachment 452499 [details]
system log (blank screen after KMS enabled)

Comment 10 SJM 2010-10-09 11:58:25 UTC
Created attachment 452501 [details]
Xorg.log (blank screen after KMS enabled)

Comment 11 SJM 2010-10-09 12:01:48 UTC
Created attachment 452502 [details]
smoltprofle for Dell E4310

Note - this bug only applies to the internal display. When docked, external monitors display ok with intel KMS (boot) and intel X driver when xorg starts

Logs attached prior include the drm.debug=0x04 boot parameter

Comment 12 Adam Williamson 2010-10-09 17:03:07 UTC
Thanks!

Comment 13 Adam Williamson 2010-10-09 18:50:04 UTC
You guys might want to try the upstream drm-intel-next tree, it has a bunch of fixes from Jesse which may address this issue (it fixes my similar bug 596557). Procedure:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git
cd drm-intel
git checkout drm-intel-next
cp /boot/config-blah ./.config [NB: use the latest config file you have available]
make
su
make modules_install
make install

reboot, and pick the newly-built kernel from the bootloader list (for me it was called 2.6.36-rc5+). See if that works.

Comment 14 SJM 2010-10-09 22:58:40 UTC
(In reply to comment #13)
> You guys might want to try the upstream drm-intel-next tree, it has a bunch of
> fixes from Jesse which may address this issue (it fixes my similar bug 596557).
> Procedure:
> ....
> 
> reboot, and pick the newly-built kernel from the bootloader list (for me it was
> called 2.6.36-rc5+). See if that works.

Unfortunately it does not work, the kernel version is 2.6.36-rc5+ 
I see boot messages, then when KMS kicks, black light is on but the screen is blank. I'm currently in this kernel, as before booted with nomodeset and using the vesa x driver.

This is going to impact both the kernel on the installation media and of the final install! Its clearly up stream too.

Comment 15 John Poelstra 2010-10-11 17:41:00 UTC
Ajax, what is your take on this bug?

Comment 16 Adam Williamson 2010-10-12 03:38:53 UTC
ansio: if you've got a bit more time you can try the edp-fixes branch of jesse barnes' tree - git clone git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel.git , git checkout edp-fixes , then as above.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 17 SJM 2010-10-12 11:22:40 UTC
(In reply to comment #16)
> ansio: if you've got a bit more time you can try the edp-fixes branch of jesse
> barnes' tree - git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel.git , git
> checkout edp-fixes , then as above.

Short answer: It doesn;t work, additionally it causes a hardware behaviour that requires a power off / on (not ctr-alt-del reboot)

Long answer:
1. Boot into kernel, I get boot text. When KMS kicks in the monitor is BLANK *AND* backlight is OFF, after several seconds lapse the backlight comes on for a moment then blank screen. After a few more seconds the backlight remains on.

The above behaviour is different from stable kernels, however the issue remains, no display with KMS.

2. Once step 1 occurs, if I ctrl+alt+del to reboot the machine reboots, but there is no display at all, not even the POST! If I let it go, it goes all the way through to Windows (I dual boot this machine) with no display! I need to power off/on to resolve it. 

This only occurs in the edp-fixes branch at the time this reply was posted.

Interestingly point 2 doesn't exist in kernel 2.6.35.4-28.fc14, if I soft reboot I at least get a post screen as one would expect! However the KMS issue is obviously there to.

 Do we have a Dell/Intel resource that can look at this, given the popularity of the video adaptor I can only assume this bug effects those with the video adapter + a specific notebook display used by E series latitude notebooks from Dell.

So...I await suggestions.

Comment 18 Adam Williamson 2010-10-12 19:54:31 UTC
"Do we have a Dell/Intel resource that can look at this, given the popularity
of the video adaptor I can only assume this bug effects those with the video
adapter + a specific notebook display used by E series latitude notebooks from
Dell."

Yup - Jesse Barnes, whose kernel branch you tried. =) He's the Intel dev who seems to be responsible for this stuff.

It would probably be a good idea at this point to report a bug to upstream bugzilla, which in this case is freedesktop:

https://bugs.freedesktop.org

report against Product: DRI and component: DRM/Intel, and you could either CC jbarnes AT virtuousgeek DOT org or assign the bug to him. Include all the info from this report. It's probably worth checking upstream reports to see if there's one already, as I'd imagine these are fairly popular systems outside of Fedora too.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 19 Adam Williamson 2010-10-12 19:55:52 UTC
This looks like the upstream:

https://bugs.freedesktop.org/show_bug.cgi?id=29278



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 20 Adam Williamson 2010-10-12 19:56:05 UTC

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 21 Adam Williamson 2010-10-12 19:57:11 UTC
There's a patch to try in the upstream bug - https://bugs.freedesktop.org/attachment.cgi?id=39293 , but I think it's one that's in current edp-fixes already, so if you've tried that, I think you've tried the patch.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 22 Adam Williamson 2010-10-12 19:59:48 UTC
someone on the upstream bug name of 'henk' also has this dumb patch:

https://bugs.freedesktop.org/attachment.cgi?id=38750

which just extends a timeout, that apparently helps some people. It's not the 'right fix' but it's probably worth testing. (Someone reported they had to bump the timeout to 900ms to make it work).



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 23 SJM 2010-10-13 03:35:39 UTC
I applied this patch: https://bugs.freedesktop.org/attachment.cgi?id=38750
(manually as its only 2 line edits) and use a msleep value of 900.

compiled the kernel and modules (which only compiled the i915 related modules) and installed them as usual. 

The result: Blank scree, black light on. Note this was applied to drm-intel-next source I used in comment 14

Comment 24 Adam Jackson 2010-10-13 20:02:10 UTC
I'm really inclined to call this not a blocker.  eDP support in i915 is just a disaster, any case where it worked in F13 was basically an accident.  Especially since comment #2 says that vesa works.  I'm happy to pull in eDP updates after the release but it's still very much a two-steps-forward-two-steps-back kind of problem right now.

Comment 25 SJM 2010-10-13 20:51:07 UTC
I appreciate the frustration, however the market penetration of this type of hardware profile (not just Dell) will experience a rapid increase in the coming months which serves to only exacerbate this issue. For new users, they won't come here to b.r.o, they might try another distro which is bound to fail and then they will switch to another OS.

The user experience is none, a basic graphical install won't be possible; Clearly our position at the moment is to support jesse by testing and tracking upstream. Fedora it self is between a rock and a hard place in terms of blocking vs not-blocking. The impact might be bigger than we think.

Comment 26 Adam Williamson 2010-10-13 22:01:17 UTC
ansio: the thing is, it's exactly this 'type' of hardware which will increase, not this exact hardware: all eDP bugs are not the same (as we can see from experience - my Sony eDP bug is fixed in Jesse's branch but your Dell one isn't). So even if we fix this bug it doesn't mean the next eDP systems that come along will work :/

"The user experience is none, a basic graphical install won't be possible;"

if the vesa driver works, it is, you just select the 'basic graphics driver' option from the boot menu. That will be the documented workaround if we decide to downgrade this from blocker status and don't take a fix.

We can discuss downgrading this at the next blocker meeting. For now, at least the latest patch Jesse's proposed is fairly small. Ansio, could you test it and see if it works?

https://bugs.freedesktop.org/show_bug.cgi?id=29278#c101



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 27 James Laska 2010-10-14 17:16:09 UTC
(In reply to comment #26)
> ansio: the thing is, it's exactly this 'type' of hardware which will increase,
> not this exact hardware: all eDP bugs are not the same (as we can see from
> experience - my Sony eDP bug is fixed in Jesse's branch but your Dell one
> isn't). So even if we fix this bug it doesn't mean the next eDP systems that
> come along will work :/
> 
> "The user experience is none, a basic graphical install won't be possible;"
> 
> if the vesa driver works, it is, you just select the 'basic graphics driver'
> option from the boot menu. That will be the documented workaround if we decide
> to downgrade this from blocker status and don't take a fix.
> 
> We can discuss downgrading this at the next blocker meeting. For now, at least
> the latest patch Jesse's proposed is fairly small. Ansio, could you test it and
> see if it works?
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=29278#c101

awilliam, I'm not parsing the previous comment.  Do you agree with comment#24 that this issue may not be a blocker, or are there other concerns you feel need to be considered?

If I understand, you're interested in feedback from Ansio to determine whether that fix should be pulled into Fedora 14?

Comment 28 Adam Williamson 2010-10-14 17:40:26 UTC
I'm explaining ajax's reasoning against it being a blocker. I can see both sides of the issue. I'd like to see if we can get a fix anyway and then we don't have to worry.

and yes, I'd like ansio (or any other tester) to try the patch I linked to.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 29 SJM 2010-10-14 18:07:17 UTC
I'll have this patch tried in the next ~18 hours -stand by

Comment 30 SJM 2010-10-15 09:37:52 UTC
(In reply to comment #26)
For now, at least
> the latest patch Jesse's proposed is fairly small. Ansio, could you test it and
> see if it works?
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=29278#c101
> 

Applied this patch to drm-intel-next (i,e exact copy of Jesse's tree). Simple patch, one line of code insertion.

Result: No change, blank screen, blacklight on. Sigh.

Comment 31 Adam Williamson 2010-10-15 16:13:44 UTC
Thanks for testing, anyway.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 32 Erik van Pienbroek 2010-10-15 16:25:14 UTC
Just wanted to mention that I'll have access to my Dell Latitude E6500 again this coming Sunday so then I'll be to help out with testing/debugging.

Comment 33 Adam Jackson 2010-10-15 18:58:47 UTC
(In reply to comment #25)
> I appreciate the frustration, however the market penetration of this type of
> hardware profile (not just Dell) will experience a rapid increase in the coming
> months which serves to only exacerbate this issue. For new users, they won't
> come here to b.r.o, they might try another distro which is bound to fail and
> then they will switch to another OS.

That's a shame and all, but six months of graphical install needing a workaround on a subset of Intel GPUs is not the thing that's going to kill Fedora or Linux. 

> The user experience is none, a basic graphical install won't be possible;
> Clearly our position at the moment is to support jesse by testing and tracking
> upstream. Fedora it self is between a rock and a hard place in terms of
> blocking vs not-blocking. The impact might be bigger than we think.

You said vesa worked in comment #2.  That's a completely acceptable workaround.  It's sad that it's necessary, I admit, but it's not a blocker.

Comment 34 Jesse Keating 2010-10-15 19:07:08 UTC
Removing as a blocker per blocker meeting:

#agreed https://bugzilla.redhat.com/show_bug.cgi?id=639146 the codebase relevant to 639146 has changed completely since 2.6.33 so our previous evaluation of it no longer applies: now given that a fix would be dangerous we decided to change it to not-blocker status; have a documented workaround: install vesa, wait for a kernel update

Comment 35 SJM 2010-10-16 01:54:05 UTC
I'd like to be on the same page as Jesse in terms of fixes to try out.

Can someone confirm this is the url to Jesse's drm-intel branches?
git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel.git

I ask because, using the above URL and checking out drm-intel-next i see the latest commit is on Friday Oct 8:

commit 2d7b8366ae4a9ec2183c30e432a4a9a495c82bcd
Author: Yuanhan Liu <yuanhan.liu@intel.com>
Date:   Fri Oct 8 10:21:06 2010 +0100

However, Jesse says this patch https://bugs.freedesktop.org/show_bug.cgi?id=29278#c102 "is included in drm-intel-next now" but this is circa October 12/13 which is several days after the last commit as far as I can see.

Second, I cannot find evidence, in my instance of drm-intel-next, that the patch referred in the b.fd.o above has even been previously applied.

For example the intel_dp.c file (after drm-intel-next is checked out) doesn't have #include <linux/delay.h> in it, which is one of the additions of the patch.

I even re did the clone on a new working directory just in case I wasn't tracking the remote repo properly, however the latest commit remains oct 8.

Comment 36 SJM 2010-10-16 04:56:05 UTC
I'll reply back after I try the right git repo.

Comment 37 Adam Williamson 2010-10-18 21:22:22 UTC
that's the right place for drm-intel-next , yes. The significant part of the patch in question in that comment is the msleep - is that present in the intel-next tree?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 38 Fedora Update System 2010-10-19 01:16:02 UTC
kernel-2.6.35.6-45.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/kernel-2.6.35.6-45.fc14

Comment 39 Adam Williamson 2010-10-19 01:36:52 UTC
well...I'm not convinced I want to call this 'fixed', because all the update does is make it fail slightly more gracefully. But it does, indeed, do that.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 40 Fedora Update System 2010-10-19 09:11:20 UTC
kernel-2.6.35.6-45.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 41 Adam Williamson 2010-10-19 18:11:22 UTC
setting back to assigned as the bug still exists. (Ansio, can you confirm that -45 goes back to console mode after failing to initialize KMS, rather than going to a blank screen)?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 42 Erik van Pienbroek 2010-10-19 18:16:06 UTC
Kernel 2.6.35.6-46 fixes the problem for me! Now KMS works properly on my Dell E6500

Comment 43 Adam Williamson 2010-10-19 18:41:22 UTC
huh. that's interesting, though possibly not what we intended. kyle, maybe the Dells have some weird dual setup and if you just don't poke eDP at all they work? /me confused



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 44 Erik van Pienbroek 2010-10-19 18:56:26 UTC
If there's a demand for it I can publish the kernel logs.
I'll try to use this new kernel tomorrow when the notebook is docked (with 2 DVI monitors attached) to see if that works correctly as well.

Comment 45 Adam Williamson 2010-10-19 19:16:33 UTC
kernel logs (with drm.debug=14 again) would be useful, and Xorg.0.log (you didn't just switch to the vesa driver and forget you'd done it, did you?)



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 46 Erik van Pienbroek 2010-10-19 20:26:46 UTC
Hi Adam,

The problem seems to have been resolved between kernel-2.6.35.4-28.fc14 and kernel-2.6.35.5-29.fc14 so it looks like upstream kernel.org managed to fix this. The reason why I didn't notice this earlier was that the kernel which fixes this issue was added to updates-testing on Oct 9 and at that moment I didn't have access to the notebook to test it out.

On the other hand, I don't think that my Dell E6500 uses eDP so perhaps it's two different issues which are mentioned in this bugreport. This misunderstanding is probably caused by the fact that various video cards can be used in the Dell Latitude notebooks. The PCI-ID of the video card used in my E6500 is 8086 2a42.

Comment 47 Adam Williamson 2010-10-19 20:34:12 UTC
it certainly sounds like you're using a laptop that doesn't use eDP, and were hitting a different bug, yes.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 48 SJM 2010-10-20 04:23:54 UTC
Just installed -45 from koji (as it hasn't hit my updates list yet)

1. Same issue, the screen is blank, blacklight is on.
2. Adding nomodeset gives me a display.

Thus, on my E4310, the "fall back" isn't working either.

Comment 49 Adam Williamson 2010-11-02 01:18:15 UTC

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 50 SJM 2010-12-05 04:33:45 UTC
Dell have released new BIOS images 
a) version: A05: for Dell Latitude E4310
b) version: A06: for Dell Latitude E6510

Both have "Updated Video BIOS" amongst a host of "fixes". Having the E4310 I've just upgraded to version A05, unfortunately it doesn't change the situation of this bug.

The upstream bug seems to have diverged somewhat from the original report.

I'm concerned this may not get resolved in time for F15, but also acknowledge it applies to every Linux distribution. I'm wondering Jesse (at FDO) has access to the type of equipment having these issues, and if he doesn't can Dell send one to him, and if they can't (which would be unfortunate) then I'm seriously considering organising it myself.

Thoughts?

Comment 51 Adam Williamson 2010-12-06 04:44:37 UTC
"The upstream bug seems to have diverged somewhat from the original report."

Huh? I'm following it, and it hasn't. There's a lot of discussion of various potential patches and so on, but it's all focused on resolving this issue.

"I'm wondering Jesse (at FDO) has access to the type of equipment having these issues"

I believe he does, yes. (He works for Intel, BTW.)

"Thoughts?"

I don't think you need to panic. Upstream is working on this, and Fedora kernel team is well aware of the issue and in fact Kyle is regularly in contact with various people with systems with eDP issues to test various kernel builds.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 52 Peter Robinson 2010-12-08 01:01:49 UTC
Kyle: any chance of getting another rawhide kernel with the latest updates from upstream in it, there seems to be quite some improvements for a lot of cases.

Comment 53 Peter Robinson 2010-12-15 21:22:29 UTC
Using 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.

# 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)

Comment 54 SJM 2010-12-19 02:57:40 UTC
2.6.37-0.rc6.git0.1.fc15.i686.PAE does not work on Dell E4310: same issue with internal display.

Peter Robinson: are you saying that you are able to boot your internal display working with kernel mode setting enabled?

Comment 55 Peter Robinson 2010-12-19 09:12:26 UTC
(In reply to comment #54)
> 2.6.37-0.rc6.git0.1.fc15.i686.PAE does not work on Dell E4310: same issue with
> internal display.
> 
> Peter Robinson: are you saying that you are able to boot your internal display
> working with kernel mode setting enabled?

Yes. I had to make sure I took the "nomodeset" option out of grub.conf and remove the xorg.conf so it didn't try to use vesa and it just works fine now on my Dell e6410

Comment 56 SJM 2010-12-20 09:03:24 UTC
(In reply to comment #55)
> > Peter Robinson: are you saying that you are able to boot your internal display
> > working with kernel mode setting enabled?
> 
> Yes. I had to make sure I took the "nomodeset" option out of grub.conf and
> remove the xorg.conf so it didn't try to use vesa and it just works fine now on
> my Dell e6410

Lucky you! There must be a difference between e6410 and the e4310 for this bug!
Adam W: I may have access to a e6310 as well at work, so I could try this out (but Peter says it works for that model)

Just to confirm from me: 2.6.37-0.rc6.git0.1.fc15.i686.PAE = blank screen with KMS on Dell E4310

Comment 57 Claes Wallin 2010-12-23 19:09:26 UTC
Latest drm-intel-fixes as of today (http://git.kernel.org/?p=linux/kernel/git/ickle/drm-intel.git;a=commit;h=4d3024428f5c3ef5295e6f6fb257ae118b3f93a1) fixed the same symptoms for my Lenovo U160-i5. My screen would go blank, and to fix it I had to run the vesa X driver with the nomodeset kernel parameter. Now I am running the intel driver without problems, in the correct resolution.

Comment 58 Adam Williamson 2010-12-23 21:40:09 UTC
That's not the same bug. Please don't make this report any more confused than it already is.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 59 Peter Robinson 2011-01-05 14:59:14 UTC
This seems to work OK on my Dell e6410 on the latest F-14 2.6.35.10-74.fc14.x86_64 kernel too. xrandr reports the panel properly too

$ xrandr
Screen 0: minimum 320 x 200, current 2880 x 900, maximum 8192 x 8192
VGA1 disconnected (normal left inverted right x axis y axis)
DP1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 303mm x 189mm
   1440x900       60.0*+   40.0  
HDMI1 connected 1440x900+1440+0 (normal left inverted right x axis y axis) 408mm x 255mm
   1440x900       59.9*+   75.0  
   1280x1024      75.0     60.0  
   1280x800       59.8  
   1152x864       75.0  
   1024x768       75.1     70.1     60.0  
   832x624        74.6  
   800x600        72.2     75.0     60.3     56.2  
   640x480        72.8     75.0     66.7     60.0  
   720x400        70.1  
DP2 disconnected (normal left inverted right x axis y axis)
HDMI2 disconnected (normal left inverted right x axis y axis)
DP3 disconnected (normal left inverted right x axis y axis)

Comment 60 Adam Williamson 2011-01-05 18:12:56 UTC
from what I've seen on the upstream bug there certainly could be different behaviours between 6410 and 6510 at this point. there's some movement in the last couple of days on the upstream bug, btw, worth checking that out.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 61 Peter Robinson 2011-01-05 19:24:05 UTC
(In reply to comment #60)
> from what I've seen on the upstream bug there certainly could be different
> behaviours between 6410 and 6510 at this point. there's some movement in the
> last couple of days on the upstream bug, btw, worth checking that out.

I've been watching, the 2.6.37 f-15 final build killed it again unfortunately.

Comment 62 SJM 2011-01-07 09:45:26 UTC
I have interesting feedback.
I've just tried Jesse's edp-fixes-2 branch on a Dell E4310

1. KMS works!

2. X does not work, for example after deleting the xorg.conf (which explicitly loaded vesa, it should nose choose the intel driver) I get what I can describe as "dual extended monitors" on my single internal screen IF KMS is enabled.

If KMS is disabled (nomodeset) then I get a massive repetition of the screen in little squares. 

Nothing better explains it that this video I filmed: http://www.youtube.com/watch?v=u9TQFMEYK9E

Adam: Can you pass this onto the upstream bug? I can't recall my FDO passwrd and I'm not getting the lost password token for some reason.

Comment 63 Adam Williamson 2011-01-07 10:08:39 UTC
that's not 'dual extended monitors', it's just that the whole thing is somehow offset on the X axis by...oh, looks like about 300 pixels. imagine in your mind if you just shifted the whole thing 300 pixels to the left - it'd be exactly correct, right?

I've posted your video to the upstream report, thanks.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 64 SJM 2011-01-07 10:46:34 UTC
yep! thats why I put "dual..." in quotes. You're right its about 300 pixels. Note this is only with KMS enabled. With KMS disabled its much worse, like the image is repeated neatly hundreds of times.

Comment 65 Adam Williamson 2011-01-07 11:27:15 UTC
KMS disabled is never expected to work any more. usually it'll result in X falling back to the VESA driver, actually.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 66 SJM 2011-01-07 20:13:31 UTC
(In reply to comment #65)
> KMS disabled is never expected to work any more. usually it'll result in X
> falling back to the VESA driver, actually.
>
must be a late night! I knew KMS disabled should never work with intel driver.

Adam, upstream is about to close the bug, jesse is urging new reports to be created for the remaining issues (e.g. the 300 pixel offset).

Should we do the same here, do you want me to log one upstream as well?

Comment 67 SJM 2011-01-07 21:45:30 UTC
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!

Comment 68 Adam Williamson 2011-01-08 01:40:30 UTC
cool. whether to leave the bug report open sort of depends; it's not technically 'fixed' until a fixed kernel is available for f14. I believe kyle may be planning to bump f14 to 2.6.37, but I'm not 100% sure.

vesa+nomodeset combination indeed ought to work; if it doesn't, file a bug against xorg-x11-drv-vesa.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 69 Nate P. 2011-03-25 16:08:30 UTC
So does this mean this problem will be fixed in F15?  I'm still using F13 because F14 had this issue on the E6510.  Thanks.

Comment 70 Tim Wegener 2011-10-06 05:46:34 UTC
This is happening for me on a Dell Latitude E5420 01.

Kernel: 2.6.35.14-96.fc14.x86_64

Comment 71 Tim Wegener 2011-10-07 07:14:21 UTC
Note that at as a result of this problem resuming from suspend comes up as a blank screen that cannot be restored to normal (even though the nomodeset option was used).

Comment 72 Nate P. 2011-10-07 11:30:46 UTC
Tim, is it possible for you to try to reproduce this problem using F15?  I had the same issue on my Latitude E6510 until F15.

Comment 73 Tim Wegener 2011-10-11 13:57:04 UTC
(In reply to comment #72)
> Tim, is it possible for you to try to reproduce this problem using F15?  I had
> the same issue on my Latitude E6510 until F15.


I was hoping to skip F15. I tried F16 beta live CD and KMS seems to be working fine there. (But I couldn't test resuming from suspend since suspend didn't seem to be an option when running from the live CD.)

Thanks for the tip.

Comment 74 Fedora End Of Life 2012-08-16 21:44:45 UTC
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping


Note You need to log in before you can comment on or make changes to this bug.