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.
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.
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.
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?
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!
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.
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..
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
Created attachment 452498 [details] dmesg output (blank screen after KMS enabled)
Created attachment 452499 [details] system log (blank screen after KMS enabled)
Created attachment 452501 [details] Xorg.log (blank screen after KMS enabled)
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
Thanks!
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.
(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.
Ajax, what is your take on this bug?
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
(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.
"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
This looks like the upstream: https://bugs.freedesktop.org/show_bug.cgi?id=29278 -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
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
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
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
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.
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.
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
(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?
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
I'll have this patch tried in the next ~18 hours -stand by
(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.
Thanks for testing, anyway. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
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.
(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.
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
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> 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.
I'll reply back after I try the right git repo.
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
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
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
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.
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
Kernel 2.6.35.6-46 fixes the problem for me! Now KMS works properly on my Dell E6500
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
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.
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
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.
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
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.
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?
"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
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.
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)
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?
(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
(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
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.
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
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)
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
(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.
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.
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
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.
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
(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?
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!
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
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.
This is happening for me on a Dell Latitude E5420 01. Kernel: 2.6.35.14-96.fc14.x86_64
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).
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.
(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.
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