Description of problem: Video has random pixels replaced with black Version-Release number of selected component (if applicable): kernel-3.5.x (all versions tried) Last version tried: 3.5.2-3.fc17.i686 How reproducible: always Steps to Reproduce: 1. Boot with 3.5.x kernel 2. 3. Actual results: garbage video. Also, the first 1/2" or so of the rhgb image is black instead of grey - the last pixel row being ragged. Expected results: Normal video Additional info: All kernels from Fedora 12 through Fedora 16 (2.6 - 3.4.x) worked perfectly. Only 3.5 is broken. Booting with a 3.4 kernel from Fedora 17 is the current workaround. Unfortunately, those are disappearing from repositories, and don't have security patches. (Can I use the latest kernels from F16 in F17?) Adding nomodeset to the kernel command line gets "working" video, but is 1024x768 instead of 1280x800 and slower. This was originally reported in bug#845388 (where 3.5 kernels don't boot at all without nomodeset, but all previous kernels work fine). That bug has a photo of the garbaged screen. Both bugs are in kernel mode set, are worked around with varying success with "nomodeset", and either hang trying to do the kernel mode set during boot, or the KMS doesn't fully work. Many machines are affected, not just the example in the bug report title. My theory is that KMS is what broke. There are many machines with KMS problems in 3.5 that never had a problem with previous kernels. There is a least one bisection done in bug#843826 attachment#605607 [details] that pinpoints the commit that broke KMS.
Just for grins, I tried 3.6 rc3 from F18. That causes Xorg to display a solid blue screen. Text consoles work.
kernel-3.5.3-1 from Koji still broken.
Indeed it is, and we never said that this bug was fixed in the kernel-3.5.3-1 update. We would like to get it fixed as soon as possible, but it is not making this update. In fact the fb issue is probably our top priority right now, but also very difficult to debug as it is a race condition only experienced by some. We do appreciate your testing new kernel and reporting here if it is not fixed, but giving negative karma to an update because your bug still isn't fixed when we have not said it was fixed in that update just delays other bug fixes from getting to users. The fact that this still doesn't work is not a regression from the current stable kernel in F17. Negative karma is only to be given for regressions from what is currently shipping, or to say something isn't fixed when we have stated that it is in the update. There are 46 other bugfixes included in this update that do help other people. As for using F16 kernels in F17, yes it works just fine. The only thing you might miss is some i915 power saving which doesn't exist in F16. The other workaround that works for most is making sure you remove terminal_output gfxterm from your grub2.cfg. Basically loading gfxterm forces the vesafb load to begin with, and the deadlock is in the evicting vesafb to install the correct drmfb
I was told that this bug is different than the fb bug (although I do feel intuitively they are related somehow) and to file a new bug. And it worked in 3.4, so 3.5 was clearly a regression. So you are saying that while it was a regression when this Acer went from 3.4 to 3.5.2-3 (although too late to leave karma), it is not a regression when it then tries 3.5.3? And the rule could be: karma is only for the first time you encounter a regression - not for subsequent releases when it still isn't fixed. So ideally, karma should only reflect changes from the last release - i.e. negative karma if it is worse than the last release. In some cases, an update might skip releases, however. Is that accurate?
Correct. karma is to reflect a negative change from the current stable release (3.5.2-3 at this point). Or, if we explicitly mark a bug as fixed in an update, and that fix is not correct. Filing a separate bug in this one was the correct thing to do, though the problems are somewhat related. We really are working to get these fixed. But in the meantime, upstream is also fixing things and getting them into stable releases. If everyone kept updates from pushing because their bug isn't fixed, no updates would happen, and no bugs would ever get fixed. If we could do an update and fix every single bug with the current release, we would in an instant. Unfortunately that doesn't happen, and each update fixes a few bugs here and there.
Removing terminal_output=gfxterm does not fix this bug.
Are you still seeing this with 3.7.9 or 3.8.2 in updates-testing?
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
I just got a chance to check the Acer laptop. It started working again with the 3.7 kernels. I'll see if I can them to update to 3.8 and make sure it still works.