Bug 522551

*** Bug 522744 has been marked as a duplicate of this bug. ***

If it works without mode setting, then it's actually fine; I should have made
it clearer that the nomodeset test is only really there as a fallback if
booting with modesetting doesn't work. so, if it worked OK with modesetting,
we'll close this bug as WONTFIX. could you let us know? thanks!

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

Well, the problem is that what it means that KMS "is working".
For me, with KMS X launches, however
- display gets very disturbed (bug 522763)
- Xv not working (bug 502913 comment 18)
- GL application very disturbed (noticed recently: if no one has
  never reported before, I will report this later)
These were working with xorg-x11-drv-i810, which does not exist
on Fedora anymore.

By the way, with KMS I gain text mode boot sequence (i.e. no graphical
boot sequence). Is this expected?

E.g. Intel 855GM has broken Xv when KMS(/GEM?) is enabled (current code's functionality is limited to older hardware like 855GM), so, nomodeset should be supported to enable Xv for older Intel HW.

I have the same problem with nomodeset. Searching the bugzilla at freedesktop.org I found this : https://bugs.freedesktop.org/show_bug.cgi?id=23568 
I think it's the same bug. I hope this will help.

Another info. I installed Xubuntu Beta and Xserver and Xv works perfectly with nomodeset.

Are there any possibility that Xv will be working with KMS or
nomodeset will be working with 855GM on F-12?

With KMS: From what I've seen upstream, Xorg intel driver will be ready in version 2.10 [1] - or whatever comes after 2.9 - (The code was merged right after 2.9 release.), kernel part is in Eric Anholt's drm-next git tree [2], which will be pulled by Linus someday (dunno if before 2.6.32 final, or not).

[1] http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/log/?ofs=50 (look for Daniel Vetter)
[2] http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=summary (look for the same name)

What's the "opposite" of KMS? UMS? It was removed recently, I believe.

This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 11 also seam to suffer from this.

On my Thinkpad R50e this is extremly annoying as the only way I can get suspend and resume to work is to turn off KMS

Created attachment 378091 [details]
/var/log/Xorg.0.log log file

Created attachment 378092 [details]
output of strace Xorg ":0" "vt7"

Output was saved in a file mounted with the sync option in order to minimize data loss following freeze

Created attachment 378093 [details]
/etc/X11/xorg.conf Xorg config file

I experience the same problem on an ACER TravelMate 2300 laptop. Early during the boot I read the following messages on the console:

render error detected, EIR:0x00000010
[drm: i915_handle_error] *ERROR* EIR stuck: 0x00000010, masking
render error detectd, EIR: 0x00000010

The laptop freezes on a black screen as soon as Xorg starts.

Further information:
last update date: sun, Dec 13th 2009

lspci -vs '00:02.0'
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) (prog-if 00 [VGA controller])
        Subsystem: Acer Incorporated [ALI] Device 0064
        Flags: bus master, fast devsel, latency 0, IRQ 6
        Memory at e8000000 (32-bit, prefetchable) [size=128M]
        Memory at e0000000 (32-bit, non-prefetchable) [size=512K]
        I/O ports at 1800 [size=8]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [d0] Power Management version 1

uname -a
Linux kanthaka.localdomain 2.6.31.6-166.fc12.i686 #1 SMP Wed Dec 9 11:14:59 EST 2009 i686 i686 i386 GNU/Linux

Plus the attached files: Xorg.0.log  xorg.conf  xorg.strace

1. The same issue is here. 
Asus SN300: Pentium M, Intel 855GME Extreme Graphics 2

Laptop hangs during X startup. No any messages in logs (Xorg.log, messages.log).
Hard reset is the only way out.

2. And one more weird thing happens sometimes. 

I was following instructions taken from here 
https://fedoraproject.org/wiki/Common_F12_bugs#Miscellaneous_problems_with_Intel_graphics_adapters

In the "init 3" mode I add into xorg.conf (created by system-config--display --noui) either Option "AccelMethod" "XAA" or Option "AccelMethod" "EXA"
and then I type init 5.
X freezes as usual. After that I switch off the laptop and then switch it on. It loads back into "init 3" mode and the xorg.conf file is empty, simply has zero length. I faced with this issue 3 times.

3. Additional hardware details are
lspci
00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02)
00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02)
00:00.3 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 83)
00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 03)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03)
00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 03)
01:03.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ac)
01:03.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ac)
01:03.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 04)
01:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
01:05.0 Network controller: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection (rev 05)

lspci -vs '00:02.0'
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) (prog-if 00 [VGA controller])
    Subsystem: ASUSTeK Computer Inc. Device 1712
	Flags: bus master, fast devsel, latency 0, IRQ 16
	Memory at f0000000 (32-bit, prefetchable) [size=128M]
	Memory at feb00000 (32-bit, non-prefetchable) [size=512K]
	I/O ports at dc00 [size=8]
	Expansion ROM at <unassigned> [disabled]
	Capabilities: [d0] Power Management version 1
	Kernel modules: i915
				
uname -a 
Linux alioth 2.6.31.6-166.fc12.i686 #1 SMP Wed Dec 9 11:14:59 EST 2009 i686 i686 i386 GNU/Linux

My hardware is Toshiba A10 laptop with 82852/855GM intel

Exactly same experience as Eugene above.

The same behavior on Toshiba A40 (Intel 855GM).....

I have the same behaviour above with my PackardBell DotS 015 (Intel 945GME) after the kernel update. I can only boot using the "nomodeset" kernel option, otherwise the system hangs.

$ uname -r
2.6.32.9-70.fc12.i686

The boot is correct when using the previous 2.6.31 kernel.

Confirming this bug here too with what's in rawhide at the date of this message (So Fedora 13 if you like.)
It is specifically the code in the Linux kernel driver for intel chipsets.
This bug has been around for months now (Well over six) For all intel 8xx graphics chipsets and the intel developers have absolutely no intention of fixing it even after several requests and a bug report outlining the regression on kernel.org by myself before they pushed the patch that caused this regression.
I was testing it. I told them it didn't work. They pushed it anyway.

This regression causes the Linux kernel to both freeze and crash at the same time.
The display remains fixed with whatever was last in the memory buffer and there is no possible way out using any magic sysRq key combination.

An explanation of what is happening in short is that UMS support has been dropped in the intel driver without proper KMS support being created for 8xx chipsets.
See here :
https://lists.ubuntu.com/archives/ubuntu-x/2010-March/000822.html
It is the exact reason why Ubuntu will not ship this version of the intel graphics driver for the Linux kernel in their long term support release and rightly so.

Somebody needs to have words with these intel developers and tell them to stop breaking things that work by completely dropping support for certain hardware without providing the existing working code as an alternative.
The most sensible thing to do would have been to fork out the 8xx drivers but I guess that was too much like hard work...
Better to just ignore any hardware they don't own...

To say that I am angry that I bought an intel machine specifically for it's intel graphics chipset because intel graphics were the most likely to work in conjunction with the Linux kernel is an understatement.
I now have a machine stuck on a kernel that is wildly out of date, which will likely remain so unless this regression is fixed.

The last working fedora kernel version for intel 8xx graphics chipsets is 2.6.31.1-56.fc12.i686 and the intel driver code shipped with that kernel version should be used to replace whatever is being shipped now.

Pretty much all the other bugs on this bugzilla against intel 855 are attributed to no 8xx support in the current intel graphics kernel driver and using the old driver would likely cure plenty 8xx owner's misery.

The moral of the story is : Don't buy intel graphics hardware if you want to be able to run desktop Linux. I certainly won't again.

(Note: I'm not even a Redhat user - just desperate to find a solution for this problem!)

Last week I finally decided to try and solve a small aesthetic problem with the display (each time I started Xorg, some ugly vertical bars appeared on the screen - not a selling point for Linux in the classroom).

So I decided to look to the latest xf86...intel driver and installed 2.10, with all the associated Xorg. Never had any problem updating Xorg (or Xfree86), so I counted on this being just a formality. 

First problem, 'Cannot find a mode switcher'... That's a first - need to upgrade the kernel because of Xorg? Ah, well. Compiled 2.6.31.12 and installed. Blank screen on startup. Grmmm... 2.6.33, same. 

Read some more, seems kernel enables KMS by default (dangerous thing, if the drivers aren't garanteed to work!). Setting 'nomodeset' off booted Ok. But now Xorg won't start...

So, I'm using the VESA driver, hoping that the intel (kernel) driver will be corrected at some point... 

And, instead of a tad of vertical bars, I'm now regaled with whatever was in the video memory of the laptop (colors, bars, texts, previous windows if rebooting). Quite the improvement.

John

Noticed I didn't include much info on versions:

Laptop is old Toshiba Satellite with 855GM hardware.
Tried -video-intel versions 2.10.0 and 2.8.1 (home compiled) on
kernel 2.6.33.

... and extra detail: Even with VESA, I couldn't use Xorg (no keyboard or mouse)
till I found out I had to enable AllowEmptyInput in xorg.conf

Created attachment 403600 [details]
Xorg log after system hang

Well, after upgrading to kernel-2.6.32.10-90.fc12.i686 the "nomodeset" option doesn't work anymore, and system hangs . I attach the Xorg log.

> Xorg log after system hang

Did you actually check the date/time of the log file? In my case there was simply no new log file created. So I always found the same (old) one again, till I noticed the date didn't change.

John

(In reply to comment #24)
> Did you actually check the date/time of the log file? In my case there was
> simply no new log file created. So I always found the same (old) one again,
> till I noticed the date didn't change.
> John

I'm pretty sure because the kernel is updated:
...
current Operating System: Linux myhost 2.6.32.10-90.fc12.i686 #1 SMP Tue Mar 23 10:21:29 UTC 2010 i686
...

and then:
...
==) Log file: "/var/log/Xorg.0.log", Time: Tue Mar 30 20:59:22 2010
...
i.e. the same date of the post.

Massimiliano

Hi folks,
after many searches I relized that probably my BIOS was buggy (about this and other issues). So I have updated it, and this problem has disappeared.

The bios on my machine is bang up to date. I flashed it myself. It's something to do with flushing the video card's memory or something in the driver.
Here is the upstream bug report :
http://bugs.freedesktop.org/show_bug.cgi?id=27187
Attached to that report is a patch that works against the latest 2.6.35 release candidates but to test the patch out correctly, you must also have libdrm 2.4.20 and xf86-video-intel 2.11 or greater installed.

I can confirm that the patch works here but there seems to have been no real progress by Daniel to push his patch upstream even though there have been two merge windows since I had it working.
Daniel says in the linked report that he wants to work on it more before pushing it upstream and many of the other related fixes have already gone but that patch is the big one for Intel 8xx users and it looks like nothing is really happening with it any more?

Somebody has removed all my votes for this bug due to some voting changes.
And how do we vote these days?

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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

On Fedora14 the problem above reported on comment #15 no longer occurs.

[root@kanthaka ~]# lspci -vs '0:2.0'
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) (prog-if 00 [VGA controller])
        Subsystem: Acer Incorporated [ALI] Device 0064
        Flags: bus master, fast devsel, latency 0, IRQ 6
        Memory at e8000000 (32-bit, prefetchable) [size=128M]
        Memory at e0000000 (32-bit, non-prefetchable) [size=512K]
        I/O ports at 1800 [size=8]
        Expansion ROM at <unassigned> [disabled]
        Capabilities: [d0] Power Management version 1
        Kernel driver in use: i915
        Kernel modules: i915

[alessandro@kanthaka ~]$ glxinfo | grep '^OpenGL renderer string:'
OpenGL renderer string: Mesa DRI Intel(R) 852GM/855GM GEM 20100330 DEVELOPMENT 

with xorg-x11-drv-intel-2.12.0-6.fc14.1.i686, kernel plain-vanilla 2.6.35.7 compiled from official sources.

Only issue remaining, GL performance is poor:

[alessandro@kanthaka ~]$ glxgears
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
312 frames in 5.0 seconds = 62.298 FPS
311 frames in 5.0 seconds = 62.064 FPS
310 frames in 5.0 seconds = 61.979 FPS
310 frames in 5.0 seconds = 61.975 FPS
310 frames in 5.0 seconds = 61.982 FPS

Back in september 2009, performance was like this:
[alessandro@kanthaka ~]$ cat glxgears_04092009.txt
3053 frames in 5.0 seconds = 610.404 FPS
2958 frames in 5.0 seconds = 591.579 FPS
2970 frames in 5.0 seconds = 593.982 FPS
2969 frames in 5.0 seconds = 593.674 FPS
2971 frames in 5.0 seconds = 594.146 FPS
2972 frames in 5.0 seconds = 594.205 FPS
2970 frames in 5.0 seconds = 593.998 FPS
2970 frames in 5.0 seconds = 593.909 FPS

Kernel 2.6.35 with the special patch for the 855 solves this problem nicely.
Apparently kernels 2.6.31... < 2.6.35 suffered, and a last minute error crept even into 6.35. Error was narrowly specific for the 855 chipset.

John

(In reply to comment #31)
> Kernel 2.6.35 with the special patch for the 855 solves this problem nicely.
> Apparently kernels 2.6.31... < 2.6.35 suffered, and a last minute error crept
> even into 6.35. Error was narrowly specific for the 855 chipset.

Alas, it's still happenning with kernel 2.6.36.

Not sure what other problems other folks have but with F-13 & F-14 I did not have any problems other than performance mentioned in comment #30 (but who cares with this machine about performance anyway?).

(In reply to comment #33)
> Not sure what other problems other folks have but with F-13 & F-14 I did not
> have any problems other than performance mentioned in comment #30 (but who
> cares with this machine about performance anyway?).
I do, because it makes a difference between being able to run some 3D applications (like GoogleEarth) on older machines or not being able to.
I do think it's a bug a 89.56% drop in performance in little over a year.

Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.