Bug 17670

Summary: [845G] X can't start with error "DRIUnlock called when not locked"
Product: xorg Reporter: echoes <trust.no.1.xf>
Component: Driver/intelAssignee: Jesse Barnes <jbarnes>
Status: RESOLVED DUPLICATE QA Contact: Xorg Project Team <xorg-team>
Severity: critical    
Priority: high CC: eric, sndirsch
Version: 7.4 (2008.09)Keywords: NEEDINFO, regression
Hardware: x86 (IA32)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 16926    
Attachments:
Description Flags
xorg.conf
none
Xorg.0.log none

Description echoes 2008-09-19 19:16:44 UTC
Created attachment 19026 [details]
xorg.conf

Linux Kernel 2.6.27-rc5-git9-6-pae
KDE 4.1.66 (KDE 4.2 >= 20080912)) "release 2.1"
Xorg 7.3/7.4
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 &
colors.

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
achieve that.
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.
Comment 1 echoes 2008-09-19 19:20:10 UTC
Created attachment 19027 [details]
Xorg.0.log
Comment 2 Gordon Jin 2008-09-20 19:46:13 UTC
the driver is pretty new: 2.4.97.
Could you tell which version previously worked for you?
Comment 3 Gordon Jin 2008-09-20 19:46:43 UTC
the driver is pretty new: 2.4.97.
Could you tell which version previously worked for you?
Comment 4 echoes 2008-09-20 20:26:36 UTC
(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
xorg-x11-driver-video 7.4-4.3
xorg-x11-server 7.4-5

Looking at the changelog of xorg-x11-driver-video, it appears that this is likely when it occurred:
2008-08-26  sndirsch@suse.de
  - xf86-video-intel 2.4.97.0
    "[...] 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.
Comment 5 Stefan Dirsch 2008-09-20 22:09:43 UTC
We used 2.4.1 before.

Fri Aug 15 08:35:44 CEST 2008 - sndirsch@suse.de
- xf86-video-intel 2.4.1
  * mostly bug and regression fixings for 2.4.0

Wed Jul 23 17:49:42 CEST 2008 - sndirsch@suse.de
- xf86-video-intel 2.4.0

Wed Jun 18 09:05:22 CEST 2008 - sndirsch@suse.de
- 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 - sndirsch@suse.de
- xf86-video-intel 2.3.1

Wed Apr 23 08:30:22 CEST 2008 - sndirsch@suse.de
- xf86-video-intel 2.3.0

I suggest to download, build and install 2.4.1 to verify this.
Comment 6 Jesse Barnes 2008-09-22 13:18:43 UTC
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?
Comment 7 Jesse Barnes 2008-09-23 18:29:17 UTC
Does the hang happen if you set ExaNoComposite to true in your intel driver section of xorg.conf?
Comment 8 echoes 2008-09-23 19:33:42 UTC
(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.
Comment 9 Michael Fu 2008-09-25 19:00:32 UTC
(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?
Comment 10 echoes 2008-09-25 19:33:12 UTC
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.

xorg-x11 7.3-96.2
xorg-x11-driver-video 7.3-138.5
xorg-x11-server 7.3-110.9

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
sndirsch@suse.de
- xf86-video-intel-default2xaa.diff
  * due to serious overall performance regressions switch back to
  XAA for intel driver again (bnc #411183)
- xf86-video-intel-TexVideoDefaults.diff
  * 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).
Comment 11 Michael Fu 2008-09-25 19:56:15 UTC
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 ***
Comment 12 echoes 2008-09-25 20:24:28 UTC
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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.