Created attachment 19026 [details]
Linux Kernel 2.6.27-rc5-git9-6-pae
KDE 4.1.66 (KDE 4.2 >= 20080912)) "release 2.1"
Intel i845G onboard chipset with intel driver
Sceptre X20WG - Naga II (1680x1050) 20" LCD Monitor
Several weeks ago I updated, rebooted, and my xserver would no longer start. I
would (and still do) get either a blank screen or a screen with static &
Steps to Reproduce:
Simply start openSUSE 11.1a2/a3 with the intel driver.
I have tried everything one could possibly think of but the xserver simply will
not function correctly with Xorg 7.3/7.4 with the intel driver. (I get the same
result mentioned above with 7.4 that I did with 7.3).
I also tried the i810 driver but the relevant part of what it spits out is at
the end: "no screens found."
I have hacked the xorg.conf file every way imaginable to no avail.
I figured this could have been a configuration problem so i reinstalled
openSUSE 11.1a2 but the problem was still there. (I burned the DVD at the
lowest possible speed & the data was verified correct with k3b. I also did a
media check with the DVD before installing & that was fine too). So I upgraded
to 11.1a3+ but that didn't fix the problem.
The resolution/refresh rate I'm trying to get is 1680x1050 @ 60hz but I can't
I tried patching a modeline with 915resolution even though I know it is no
longer necessary with the intel driver but that didn't work either.
I have tried specifying (correct) modelines in my xorg.conf & not specifying
modelines but neither method made a difference.
I also tried booting up the latest KDE Four livecd & configuring the relevant
hardware with sax2 (gui) & saving the xorg.conf & then trying to apply the
modified livecd's xorg.conf to my 11.1a3+ install but that didn't work either.
(I figured I'd try it since the KDE Four livecd (& sax) works correctly).
Running sax2 -a from failsafe command line doesn't work as it just cycles (or
scans) through video modes & always leaves me with a blank screen that I either
have to ctrl+alt+del or hard reboot to get out of.
I am running with the vesa driver in 1024x768 resolution with 16 bit color,
which I guess is the best the vesa driver can do.
I noticed this line in particular in the Xorg.0 log but I don't know what it
means or if it is anything out of the ordinary:
(WW) intel(0): Bad V_BIOS checksum
This TOTALLY breaks the intel driver's i845G support.
Created attachment 19027 [details]
the driver is pretty new: 2.4.97.
Could you tell which version previously worked for you?
(In reply to comment #3)
> the driver is pretty new: 2.4.97.
> Could you tell which version previously worked for you?
Sorry, I don't know which version exactly, but it worked correctly about a month ago before an update.
openSUSE 11.1 beta 1 i586
Looking at the changelog of xorg-x11-driver-video, it appears that this is likely when it occurred:
- xf86-video-intel 18.104.22.168
"[...] first 2.5.0 test release. Should be about as stable
as the 2.4.1 and upcoming 2.4.2 releases, but also includes GEM
and kernel mode setting code. We haven't pushed the video
tearing fixes yet, hopefully that'll be upstream for the next
test release. Carl has made good progress on improving EXA
performance, but I think the scrolling case may still be
sub-par, but we're interested in getting feedback there. [...]"
So it would have been the last update to the intel driver in the driver-video package.
We used 2.4.1 before.
Fri Aug 15 08:35:44 CEST 2008 - email@example.com
- xf86-video-intel 2.4.1
* mostly bug and regression fixings for 2.4.0
Wed Jul 23 17:49:42 CEST 2008 - firstname.lastname@example.org
- xf86-video-intel 2.4.0
Wed Jun 18 09:05:22 CEST 2008 - email@example.com
- xf86-video-intel 2.3.2
* includes misc bug fixes and the last 2.3 branch release
Mon May 12 10:48:29 CEST 2008 - firstname.lastname@example.org
- xf86-video-intel 2.3.1
Wed Apr 23 08:30:22 CEST 2008 - email@example.com
- xf86-video-intel 2.3.0
I suggest to download, build and install 2.4.1 to verify this.
Looks like this is actually a ring hang; the "unlock when not locked" call may just be a side effect of that. According to the backtrace it looks like we tried to do a batch flush and timed out. Hoping this is a GEM bug Eric already fixed... Eric?
Does the hang happen if you set ExaNoComposite to true in your intel driver section of xorg.conf?
(In reply to comment #7)
> Does the hang happen if you set ExaNoComposite to true in your intel driver
> section of xorg.conf?
Yes. Also tried disabling DRI but that didn't make a difference either.
(In reply to comment #8)
> (In reply to comment #7)
> > Does the hang happen if you set ExaNoComposite to true in your intel driver
> > section of xorg.conf?
> Yes. Also tried disabling DRI but that didn't make a difference either.
And, the log with modedebug on, please?
I'm sorry but I couldn't do what I needed to do with a broken driver. I was forced to downgrade to openSUSE 11.0.
I can tell you that the intel driver works fine with the version I'm using now.
If anyone can tell me what command to issue to list the intel driver's specific version I can post it, if there is such a command.
(I kind of wish openSUSE's Xorg packages were packaged like Ubuntu's where there are individual packages for each driver, that way it would be easier to determine specific driver versions).
However this is the latest changelog entry in the xorg-x11-driver-video's package:
Mon 28 Jul 2008 05:00:00 AM PDT
* due to serious overall performance regressions switch back to
XAA for intel driver again (bnc #411183)
* fixed Xvideo with XAA/Composite by disabling Textured Xvideo by
default when XAA has been enabled; enable it for XAA with
Option "TexturedVideo" (bnc #411183)
(Although take this for what it is worth because as far as I can tell many, many package's changelogs aren't updated as often as the packages are).
ok. please stay with what works for you currently. I'll mark this bug as dup of other "ring hang" issue on 845G platform. thanks.
*** This bug has been marked as a duplicate of bug 17713 ***
I know that you being at Intel would know best, but I was specifically told by Stefan Dirsch to file this bug because it is a separate bug that totally destroys 845G support.
Forgive my ignorance but, and I'm not offended by it being marked as a dupe, but I'm simply curious as to why it shouldn't be kept as a separate bug. It is/would be a blocker to next version of the intel driver, correct? I want to be sure that when the intel driver gets updated to the next final version/release (through the xorg-x11-driver-video package) I'm not in the same boat again with a totally useless driver. I know intel wouldn't knowingly release a driver with that big of a flaw but bug #17713 isn't marked as a blocker...
Also, this occurs 100% of the time not some times like the title of bug #17713 says.